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: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org