21.11.2015 23:39, Andreas Färber пишет:
> Am 21.11.2015 um 18:48 schrieb Matwey V. Kornilov:
>> 21.11.2015 15:47, Andreas Färber пишет:
>>> Am 21.11.2015 um 06:49 schrieb Matwey V. Kornilov:
>>>> 21.11.2015 01:08, Andreas Färber пишет:
>>>>> Am 20.11.2015 um 20:09 schrieb Matwey V. Kornilov:
>>>>>> The flavor of dtb (dtb file) is to be specified in
>>>>>> /etc/sysconfig/bootloader
>>>>>
>>>>> That shouldn't be necessary, U-Boot is supposed to provide $fdtfile.
>>>>> In my testing I didn't need to specify a dtb file in extlinux.conf, only
>>>>> the dtb directory.
>>>>
>>>> That is great news, but I think it is better to provide optional
>>>> possibility to set the file manually. Let me describe use-case.
>>>>
>>>> BeagleBone Black supports the capes, and the kernel still doesn't have
>>>> an user-space API for overlays. So, to enable my specific hardware I
>>>> will modify am335x-beaglebone.dts and compile new version, say
>>>> am335x-beaglebone-with-geiger-counter-cap.dtb. Sure, when I will deploy
>>>> this to my production, I will make a package
>>>> dtb-am335x-with-geiger-counter-%{version}.rpm (Please, see above,
>>>> imagine, new kernel update has been issued and my build service has not
>>>> rebuild this package yet, so I'll receive an updated kernel and will not
>>>> receive and updated dtb package)
>>>>
>>>> How should u-boot guess what I want now? So, please, let the user some
>>>> freedom.
>>>
>>> Maybe your statement above was ambiguous - for me "is to be specified"
>>> reads as "must be specified". To that I objected.
>>>
>>> You're free to add an optional mechanism to override it, of course. But
>>> I would prefer to get the current pull sorted out and tested before we
>>> investigate such extra features.
>>
>> Sure, I've missed that fdtdir and fdt are mutually exclusive, I will
>> handle this shortly and then update the pull-request.
>>
>>>
>>> I do wonder whether there is a better way, changing fdtfile in U-Boot's
>>> environment rather than FDT in extlinux.conf, for instance.
>>> Unfortunately extlinux.conf is read before boot.scr, otherwise you
>>> could've overridden it there and called sysboot from the script. And
>>> uEnv.txt is only read by a handful of boards, so not a general solution,
>>> but I believe Matthias reported such an error on BBB?
>>
>> Yes, it can be a great solution.
>> An environment should be fixed if we want to implement fallback booting
>> finally.
>
>> Unfortunately, I've heard nothing about issues with uEnv.txt on
>> BBB.
>
> No real issue, just a report that U-Boot was complaining about not
> finding uEnv.txt (because we don't supply any AFAICS). Which would in
> turn imply that it can read info from there if we provide it.
>
>>> Do you actually need a different filename though? If you want to have a
>>> side-by-side installation you would really also need two extlinux.conf
>>> entries per kernel to switch easily. Otherwise you could just leave the
>>> .dtb filename the same for your modified package, needing no
>>> modifications to extlinux.conf.
>>
>> Why can't I have two entries with the same kernel and different dtb's?
>> There are cases when editing of dts is safe and does not require
>> recompiling the kernel. For instance, enabling some disabled-by-default
>> node.
>
> I'm not saying you can't, just that automating this is somewhat
> problematic: When I install dtb-foo then it contains multiple .dtb files
> usually, but I don't want boot menu entries for all other boards, just
> the one (two when counting failsafe) determined by $fdtfile. In your
> case I imagine it would be both the default for $fdtfile plus an entry
> per cape dtb. The unanswered question is what correlation between extra
> dtb package and menu entries we might arrive at, i.e. would you have a
> package just for Geiger Cape that would add the entry as %post or would
> you have a package with several cape DTBs that you do not all want in
> your menu automatically.
>
> A solution might be to extend your /etc/sysconfig/bootloader option
> suggestion to allow specifying multiple (e.g., space-delimited) dtb file
> names and generating a menu entry for each.
And here you are right. Moreover may "Failsafe" entries want to have dtb
file different from default?
>
>>> BTW I thought that months ago we had enabled DT overlays in the kernel
>>> on your request. What's missing to make overlays work? I don't have any
>>> capes/hats/shields/etc.
>>
>> DT overlays is a technique to change device tree on the fly, it is great
>> that it is compiled and does not crashes. Unfortunately, there is
>> currently still no interface to ask the kernel: "ok, lets change the
>> device tree in the specific manner".
>
> So was that the proposed conditional sections for multiple BBB revisions
> in one .dts? Or is there a location like /boot/overlays/ in the RPi case
> that the kernel searches overlay files to be merged as-is? Or just an
> internal API?
>
>> See https://lkml.org/lkml/2015/5/13/157 for instance
>
> Do you have a quick summary? :) I see a BBB-specific sysfs interface
> that gets info via EEPROM, which I guess means I2C. Does this need
> anything from our side in terms of .dtb files, or does it get everything
> from the cape EEPROM?
No, it only reads cape type and version from the cape's EEPROM and
requests appropriate dtbo file from user-space.
>For instance if the part-number is BB-BONE-SERL-03 and the version is 00A1
>the firmware file requested will be BB-BONE-SERL-03-00A1-00A1.dtbo
>It will be located by the in-kernel firmware
>loader in the usual place, i.e. /lib/firmware/`uname -r`,
/lib/firmware etc.
>
> Regards,
> Andreas
>
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
