Am 16.01.2014 13:06, schrieb Alexander Graf: > On 16.01.2014, at 12:56, Marcus Schäfer <[email protected]> wrote: > >>>> firmware="vboot" loader="berryboot" >>> >>> Shouldn't loader be u-boot? After all, we need to run the normal uboot >>> setup scripts, no? >> >> yes but it's kind of both isn't it ? there is this berryboot "thing" >> reading config.txt and running a kernel which in our case is the >> real bootloader u-boot. Somehow I have to create the configs so that > > To me the "berryboot" part is the same level as MLO or SPL on other > platforms. It's just some random binary blob required to actually get into > u-boot. There's no need to have kiwi involved. > >> uboot is called. The loader="berryboot" information would be the >> trigger to do that. berryboot is also the name I found when looking >> up the boot capabilities of the raspberry devices. Thus I found >> the name ok because it's about loading raspberry... somehow :-) >> >> The scripts as part of the descriptions in the buildservice will >> most probably only fiddle around with the contents of the boot.scr >> as we do it for all boards. >> >> I think the setup so that u-boot is called is pretty generic and can >> be done by kiwi so you don't need to care for this in any script >> >>> Exactly, we should leave the current uboot script magic alive, but just >>> change the gpt to be either an mbr or a synced gpt :). For partition types >>> we should be able to fix things up in the scripts like we do for the >>> chromebook. >> >> yep it will be that way and in order to not break e.g the chromebook >> description I'd like to distinguish it by the loader setup > > I think it'd make sense to test whether the chromebook would be happy with a > sync'ed MBR. Then we wouldn't bloat the number of combinations too heavily.
According to http://archlinuxarm.org/platforms/armv7/samsung/odroid-xu the ODROID-XU also needs some special partitioning scheme. I haven't tried Linux yet, but my Android SD card looks like this: Device Boot Start End Blocks Id System /dev/sdb1 6982800 15377339 4197270 c W95 FAT32 (LBA) /dev/sdb2 136620 2246639 1055010 83 Linux /dev/sdb3 2246640 6451499 2102430 83 Linux /dev/sdb4 6451500 6982799 265650 83 Linux Note: no FAT partition, "free space" before block 136620 (70 MB) If you have ideas how to investigate this magic free space, do let me know. Anyway, just pointing out that the RPi may be special wrt its config.txt etc. but more than just the two boards may want a three-partition layout, with all sorts of variations. I'll try to test a sync'ed GPT tonight. But I also noticed that the Raspberry Pi bootloader files (bootcode.bin, *.elf) end up on both partitions when they would only be necessary on the FAT partition. Is that fixable in our JeOS scripts? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
