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.
>> 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?
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
