[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