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

Re: [microblaze-uclinux] bootstrap code



Hi Jozsef,

jozsef imrek wrote:

>>The critical one is the same problem that most uClinux systems face with
>>elf bootloaders.  That is, the romfs filesystem is copied into the
>>kernel elf image (post-linking) with the following bit of shell script:
>>
>>         mb-objcopy --add-section=.romfs=$(ROMFSIMG) \
>>           --adjust-section-vma=.romfs=$${ADDR} --no-adjust-warnings \
>>           --set-section-flags=.romfs=alloc,load,data   \
>>           $(ROOTDIR)/$(LINUXDIR)/linux $(ELFIMAGE)
>>
>>I've never got a straight answer, but it's either a bug in objcopy, or a
>>"bug" (feature?) in elf loaders, that this new romfs section is not
>>allocated into a segment, and most elf loaders don't "see it".
> 
> exactly: the problem is that the program heders does not get updated, so
> the elf loader does not even know about the romfs. i think it should not
> be considered as a bug in the elf loader: an elf loader should do what the
> program headers say.

So it's a bug/feature of objcopy?  When you run objcopy again with the 
-O binary flag, it detects the orphaned .romfs section and correctly 
outputs it to the resultant binary file..

> nevertheless you can solve the problem by creating correct program
> headers. surely there is a way to do it in post-link, but i had no time
> to create a linker script for that, so i modified the kernel
> link script instead.
> 
> you just have to wrap the romfs into elf format and link this elf with the
> kernel using the appropiate linker sript.

[snip]

This is the way I used to do it, however was a bit dissatisfied with 
doing a double-link on the kernel, seemed pretty wasteful.  I changed 
over to the objcopy approach based on the ColdFire/Snapgear targets, and 
using binary rather than elf images for booting.

> 
> i'm sorry for not providing you with nice patches instead of this lousy
> semi-tutorial. :(

It's ok, as I said I've been there before, and retreated in search of a 
cleaner solution.

To be honest I'd still prefer to tweak the bootlaoder to act a bit more 
like objcopy - I should just look at the objcopy/BFD sources and see 
what it does.  Clearly if "objcopy -O binary" can work correctly, there 
must be enough information about the .romfs section for it to be given a 
size, load address and flags etc..

> with some more tweaking on the linking you can remove the entire
> mach_early_init(): this function copies the romfs into the right
> place (solved above), zeroes out the bss and sbss data sections (done by
> the loader code if a bug i left in it gets corrected :), and sets up the
> reset, interrupt, etc vectors at 0x00000000 (you just have to modify the
> linker script to put .intv section into LMB instead of OPB). some might
> want to play around with the tricks mentioned in the head of mbvanilla.ld
> too. :)

Yes, this would be a very positive side-effect of using your elf loader 
vs the flat binary format.

Regards,

John
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/