Re: [PATCH 4/7] Support for ARM/U-Boot platforms

[Vladimir 'φ-coder/phcoder' Serbinenko]

>> Trouble is that grub-install now rightfully warns about the lack of

>> platform-specific install.
>> What do we have to do to register the image at u-boot?
>> Put it in specific location?
> 
> EFI provides three very nice things:
> - Standardised partition and filesystem type for bootloaders.
> - Standardised runtime services for updating selected boot image.
> - Standardised "removable media" bootloader path.
> 
> U-Boot has neither, and different platforms use different mechanisms to
> affect boot images - some "prime" the enviroment with a uEnv.txt, some
> search around a predefined set of filesystems for boot scripts, some
> require you to manually "setenv" from within U-Boot.

Is environment stored in flash?

> 
> Debian use a special package called flash-kernel to abstract these things
> away.
> 

Can we use it?

> So in short, I think the only sane thing grub-install can do for arm-uboot,
> is what I already have it do - generate an image with the required modules
> embedded.

If that's the only thing we do, then the warning should be kept.

> Now, maybe it shouldn't be grub/arm-uboot/core.img, but that was
> what I ended up using.
> 

I'd prefer to keep this file and make a copy if necessarry.

>> Also you spoke about relocatable image but AFAICT header always
>> specifies load address. Do you have a way around it?
> 
> Well, it's not so much a way around it as somthing that almost ampounts
> to a new port (certainly a new image type).
> The proper fix would be to generate it as an ELF image _instead_, and use
> U-Boot's ELF loader support to load it properly.
> 

It's not really a new port. We already have ports using several image
formats, e.g. i386-pc, sparc64-ieee1275, mips-loongson.
Doesn't U-boot terminate services if it loads an ELF? How good is its
ELF support? Does it handle relocations correctly? If it doesn't we can
use -fPIC for kernel.

signature.asc
Description: OpenPGP digital signature