On 16.01.2014, at 12:56, Marcus Schäfer <[email protected]> wrote: > Hi, > >>> 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. Alex -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
