> Am 10.01.2017 um 22:08 schrieb Frank Kunz <[email protected]>: > >> 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).
That is always the case, as parted aligns partitions to at least MB boundaries. Please double-check where the GPT contains values and that none of them are beyond 64kb. You will want to make this GPT future proof ;) Alex > > Br, > Frank > -- > To unsubscribe, e-mail: [email protected] > To contact the owner, e-mail: [email protected] > -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
