[OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

Andre McCurdy armccurdy at gmail.com
Thu Aug 23 07:19:38 UTC 2018


On Thu, Aug 23, 2018 at 12:08 AM, Ryan Harkin <ryan.harkin at linaro.org> wrote:
> On 23 August 2018 at 07:39, Martin Hundebøll <martin at geanix.com> wrote:
>>
>> May I suggest using the '-r, --relative' flag from 'ln':
>>
>>        -r, --relative
>>               create symbolic links relative to link location
>>
>> My life felt considerably better after discovering that feature :)
>
> Thanks Martin Hundebøll! Yes, that works for me.
>
> So, Martin Jansa, I could make this change:
>
> -       ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
> +      ( ln -sfr
> ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
> ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt)

This is kind of crazy - you are giving an absolute path and then
asking ln to convert it into a relative path for you... but the
conversion process is trivial: just remove the entire path! You don't
need to ask ln to do that for you.

> Of course, if I'm not going to "cd" into the firmware repo, I'll have to use
> absolute paths on both sides of the "ln" command anyway. So I could drop the
> 'r' param and it should still work. Eg:
>
> -       ( cd ${D}${nonarch_base_libdir}/firmware/brcm/ ; ln -sf
> brcmfmac43430-sdio.MUR1DX.txt brcmfmac43430-sdio.txt)
> +      ( ln -sf
> ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
> ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt)

This will create a symlink which points to the target using an
absolute path. ie it's not equivalent to the other examples given so
far.

> I'm still not sure this is any neater, though, as it involves using the path
> twice. Is there a maintainer here who has a preference?
>
> FWIW, the TI line that I copied was added by Koen Kooi, who I've added to
> the CC:
>
> 8c7adb6  2011-10-09  linux-firmware: update, merge in OE classic updates,
> fix p..       [Koen Kooi]

If you mean this line:

  ( cd ${D}/lib/firmware ; ln -sf ti-connectivity/* . )

then it's doing something quite different to what you're now trying to
do. It's creating multiple symlinks, not one.

>>
>> // Martin
>>
>> On 23/08/2018 08.12, Ryan Harkin wrote:
>>>
>>>
>>>
>>> On 22 August 2018 at 23:55, Andre McCurdy <armccurdy at gmail.com
>>> <mailto:armccurdy at gmail.com>> wrote:
>>>
>>>     On Wed, Aug 22, 2018 at 2:56 PM, Ryan Harkin <ryan.harkin at linaro.org
>>>     <mailto:ryan.harkin at linaro.org>> wrote:
>>>      > On Wed, 22 Aug 2018, 21:42 Andre McCurdy, <armccurdy at gmail.com
>>>     <mailto:armccurdy at gmail.com>> wrote:
>>>      >> On Wed, Aug 22, 2018 at 1:10 PM, Ryan Harkin
>>>     <ryan.harkin at linaro.org <mailto:ryan.harkin at linaro.org>>
>>>      >> wrote:
>>>      >> > On Wed, 22 Aug 2018, 20:02 Martin Jansa,
>>>     <martin.jansa at gmail.com <mailto:martin.jansa at gmail.com>> wrote:
>>>      >> >>
>>>      >> >> Your 1st parameter is wrong, compare again with the example I
>>>     gave you
>>>      >> >> (don't include "brcm/" path in 1st param, because you want
>>>     the symlink
>>>      >> >> to
>>>      >> >> point to just brcmfmac43430-sdio.AP6212.txt like you did in
>>>     the version
>>>      >> >> after cd).
>>>      >> >
>>>      >> > That doesn't work either. I tried it with the same result, but
>>>     didn't
>>>      >> > send a
>>>      >> > log of it. That works for you?
>>>      >>
>>>      >> Martin's example is correct so maybe check your tests again for
>>>     typos.
>>>      >> It it still doesn't work then please do send a log.
>>>      >>
>>>      >> The link will point to whatever you define via the first
>>>     parameter, so
>>>      >> if you changed the first parameter it shouldn't be possible to
>>> get
>>>      >> "the same result".
>>>      >>
>>>      >>   $ mkdir foo
>>>      >>   $ ln -sf test_target foo/test1
>>>      >>   $ ln -sf brcm/test_target foo/test2
>>>      >>   $ ls -l foo
>>>      >>
>>>      >>   lrwxrwxrwx 1 andre andre 11 Aug 22 13:35 test1 -> test_target
>>>      >>   lrwxrwxrwx 1 andre andre 16 Aug 22 13:35 test2 ->
>>> brcm/test_target
>>>      >
>>>      > Yes, that's essentially the same as what I'm getting.
>>>      >
>>>      > Now try "cat foo/test1" and what happens?
>>>      >
>>>      > There is no file called test_target in the foo directory. And
>>>     neither is
>>>      > there a file called brcm/test_target in the foo directory.
>>>
>>>     Correct. The above was just an example to show that you can * create
>>>     symlinks * in the foo directory without cd'ing into the foo directory
>>>     first.
>>>
>>>     If you'd like the symlinks in the example to point to valid targets
>>>     then you need to create the targets too, e.g.
>>>
>>>        $ mkdir -p foo/brcm
>>>        $ echo hello > foo/test_target
>>>        $ echo hello2 > foo/brcm/test_target
>>>
>>>     But note that the process of creating a symlink is always the same,
>>>     regardless of whether the symlink points to a valid target or not (so
>>>     you can run these extra commands to create the targets before or
>>> after
>>>     you create the symlinks).
>>>
>>>
>>> So that doesn't work for me how I expect it to work. I must be missing
>>> something fundamental here.
>>>
>>> The recipe is trying to create a soft link from a file in the current
>>> directory to a file in the sub-directory. On my system, your example creates
>>> links from a file in the sub-directory to the another file in the
>>> sub-directory.
>>>
>>> So, to copy your example, but creating the file "test_target" from the
>>> start:
>>>
>>> $ mkdir -p /tmp/test
>>> $ cd /tmp/test
>>> $ mkdir foo
>>> $ echo 1 > test_target
>>> $ ln -sf test_target foo/test1
>>> $ ln -sf brcm/test_target foo/test2
>>> $ ls -l foo
>>> total 0
>>> lrwxrwxrwx 1 ryan ryan 11 Aug 23 06:54 test1 -> test_target
>>> lrwxrwxrwx 1 ryan ryan 16 Aug 23 06:54 test2 -> brcm/test_target
>>> $ cat test_target
>>> 1
>>> $ cat foo/test1
>>> cat: foo/test1: No such file or directory
>>> $ cat foo/test2
>>> cat: foo/test2: No such file or directory
>>> $ echo hello > foo/test_target
>>> $ echo hello2 > foo/brcm/test_target
>>> bash: foo/brcm/test_target: No such file or directory
>>> $ cat foo/test1
>>> hello
>>> $ cat foo/test2
>>> cat: foo/test2: No such file or directory
>>> $ cat test_target
>>> 1
>>> $ tree
>>> .
>>> ├── foo
>>> │   ├── test1 -> test_target
>>> │   ├── test2 -> brcm/test_target
>>> │   └── test_target
>>> └── test_target
>>>
>>> 1 directory, 4 files
>>>
>>> So, neither test1 nor test2 are linked to /tmp/test/test_target. test1 is
>>> linked to /tmp/test/foo/test_target and test2 is linked to
>>> /tmp/test/brcm/test_target, which doesn't exist.
>>>
>>> AFAIK, when creating a softlink, you have to give it either an absolute
>>> path, or a path relative to the link being created. The path cannot be
>>> relative to the original file that you want to link to.
>>>
>>> So, this will work:
>>>
>>> $cd /tmp/test
>>> $ ln -sf ../test_target foo/test3
>>> $ cat foo/test3
>>> 1
>>> $ cat /tmp/test/foo/test3
>>> 1
>>>
>>> But that is a strange way to create the soft link, IMO.
>>>
>>> AFAICT, for the recipe, to get rid of the "cd", I'd have to specify an
>>> absolute path to the original file:
>>>
>>> +do_install_append_bcm43430-nvram-mur1dx() {
>>> +       ( ln -sf ${PWD}/brcmfmac43430-sdio.MUR1DX.txt
>>> ${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt)
>>>
>>> ... assuming PWD is available to the recipe. There will be a proper Yocto
>>> variable I can use, of course, but I can't think of it right now.
>>>
>>> Either way, Martin's example doesn't work for me. And adding the absolute
>>> path of the original file doesn't seem any neater or clearer than following
>>> the TI example from the do_install a few lines up in the recipe. But I'm
>>> happy to do it either way, so long as it works.
>>>
>>
>> --
>> Kind regards,
>> Martin Hundebøll
>> Embedded Linux Consultant
>>
>> +45 61 65 54 61
>> martin at geanix.com
>>
>> Geanix IVS
>> https://geanix.com
>> DK39600706
>
>



More information about the Openembedded-core mailing list