grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Leif Lindholm
Subject: Re: [PATCH 4/7] Support for ARM/U-Boot platforms
Date: Tue, 9 Apr 2013 10:26:13 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Apr 08, 2013 at 12:47:48PM +0200, Vladimir '??-coder/phcoder' 
Serbinenko wrote:
> >> Why so small heap?
> >  
> > I copied ieee1275 HEAP_MIN_SIZE to begin with, and it was always enough.
> > (Since U-Boot doesn't provide any memory mapping service, kernel and
> > initrd are not going on the heap.)
> 
> On x86 we reuse heap for kernels as well
 
This might be difficult to combine with the intersection of U-Boot and
the defined ARM Linux boot process.

> > I could increase it?
> 
> If we want to support any kind of graphics (gfxterm, gfxmenu) on arm as well, 
> we'll need more heap

OK.
 
> >> Is it from uboot? You need to check for its availability
> >  
> > Yes.
> 
> the header is trivial. I added it to grub-mkimage (patch at the bottom).

Neat, thanks :)

> 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.

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

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

> 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.

/
    Leif



reply via email to

[Prev in Thread] Current Thread [Next in Thread]