On 08/01/2017 21:30, Frank Kunz wrote:
Hello Andreas,
thanks for your feedback.
firmware="ofw" sounds wrong? The soc first stage bootloader (ROM) reads the first sector of the SD card and scans the partition table for a partition with the ID 0xa2. If this is found it loads a header + spl loader from that partition. The upstream u-boot spl configuration for that board expects the uboot also copied to that special partition and it expects that it needs to be the first partition. firmware="ofw" creates a small extra partition at the beginning of the partition table. This is used for header+spl+uboot. The uboot install script is adjusting the partition type and copies the spl with uboot into it.
Better check for file presence than for image name (think "sockit"). The file is not present since it is not copied by KIWIBoot.pm sub copyBootCode { ... KIWIQX::qxx ("mv $dest/boot/*.bin $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.dat $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.img $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.imx $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.elf $target &>/dev/null"); ... } The header+spl+uboot image file name is u-boot-with-spl.sfp and that pattern is not copied. Therefore I used the image name instead of the file presence. The file is copied by
cp /usr/src/packages/KIWIROOT-oem/boot/u-boot-with-spl.sfp boot/
in the uboot install script, which is just a hack. The clean solution would be a upstream patch for kiwi.
We basically moved away from copying random files magically within kiwi to explicitly moving things around inside the u-boot-install/setup scripts. It's much more maintainable that way. So if you already do it inside the u-boot-install script, that sounds like a perfectly valid solution.
For the gfx command line you may want to add a second console=tty or so? That did not help so far so solve my login problem. In the mean time I started to modify the initrd that the /boot/mbrid file does not match. But no idea yet what could be wrong. I haven't found out where it is set during the image build process, how to debug that?
The mbrid file gets generated by kiwi when it writes the MBR ID field in the MBR of the target device. So they really should be in sync. If they are not, something goes wrong in the u-boot-install/setup scripts. Also, have you verified that the target device is actually visible from within the kiwi initrd? Maybe the module is missing? To verify, just boot with kiwidebug=1 as kernel parameter and you should get into a shell after kiwi failed to find its boot device.
Does EFI not work yet or have you not tried? No, I have not tried yet. Not sure if that will work.
EFI booting makes it much easier to modify things like the kernel command line. It also allows you to install and select multiple kernel versions in parallel. To make use of it, all you need is a valid "$fdtfile" variable in the U-Boot default environment. Then set the respective define in the Images.kiwi.in file for your board and you should be set. You might need to convert the GPT that kiwi generates to an MBR. See existing snippets in the u-boot scripts for that. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org