Am 10.01.2017 um 13:13 schrieb Alexander Graf: > On 01/10/2017 12:51 PM, Andreas Färber wrote: >> Am 10.01.2017 um 00:04 schrieb Alexander Graf: >>> On 09/01/2017 21:20, Frank Kunz wrote: >>>> Am 08.01.2017 um 22:29 schrieb Alexander Graf: >>>>>>> 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? >>>> I modified the initrd init/include scripts to print the device names >>>> that were used for the search run, and the mmcblk0 is there, and some >>>> value is read out. So the driver seems to be ok. The value read from >>>> /boot/mbrid is a different value. >>> That sounds to me like something is messing with the MBR after it got >>> created. >> He's calling parted in uboot-image-install.in: >> >> https://build.opensuse.org/package/rdiff/home:frank_kunz:branches:openSUSE:Factory:ARM/JeOS?opackage=JeOS&oproject=openSUSE%3AFactory%3AARM&rev=19 >> >> >> (Any reason for that placement of the hunk instead of adding in the >> bottom?) >> >> You may need to save and restore mbrid as done some lines up. > > Ah, that explains the missing mbrid, yes :). > > I see two potential options according to the boot documentation: > > https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an709.pdf > > > 1) Use raw offset > > According to the documentation you can not use a partition table when > using the raw format. Maybe you can trick around with abusing the first > 440 bytes for the boot loader and leave the actual partition table and > MBRID intact: > > https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout > > Maybe there's some way to use Preloader 1 instead of 0?
Good idea. It is possible. The rom loader first checks for a partition 0xa2. From there it tries to load the spl, where there is one and three backups. If that fails it tries to load in raw mode from sector 0 and does the same. If the loading and crc check of spl from offset 0 fails, it automatically continues at sector offset 0x80 with the first backup spl. So when copy the spl+uboot image to the disk by dd if=u-boot-with-spl.sfp of=/dev/sdX bs=64k skip=1 seek=1 the rom loader loads the spl from preloader 1 location in raw mode and starts it. But the spl has a bug to load the attached uboot from the location 0x200 then. So I need to prepare some upstream patches for uboot to get that fixed and enabled in the defconfig (let us see if it will be accepted). Anyway the environment does not have the distro_boot variables in place, so I will upstream that as well. By that no special partition is needed anymore then, but the "hole" between partition table and first partition needs to be big enough to store the spl images and the uboot (approx. 700kiB). Br, Frank -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
