[U-Boot-Users] U-Boot-NG ?

[Sascha Hauer <s.hauer@pengutronix.de>]

On Tue, Jul 03, 2007 at 05:35:27PM +0200, Carsten Schlote wrote:
> Hi Sascha,
> 
> > No, the scripts work here, but I did not find where 
> > MAXPAGESIZE and COMMONPAGESIZE are defined, they must come 
> > from the linker.
> 
> That was, what I meant. It's somewhere hacked into LD. 
> 
> > Do you need to define MAXPAGESIZE and COMMONPAGESIZE aswell 
> > or only CONSTANT? I would prefer hardcoding the values 
> > directly in the linker script. They are needed only for the 
> > sandbox target, but u-boot.lds.h is included for all architectures.
> 
> So it is better to use the hard-coded values in the linker script. At
> least as long as it takes for main-stream LD to support this fine
> extension.
> 
> > btw I just read your wiki and 'sandbox' really is the better 
> > name for this target ;)
> 
> A simulation sandbox with a real GDB and host OS is really some kind of
> 'must have' :-) Most high-level stuff can be developed with it, and just
> the final tests need to be done on the target. 

Yes, it's really nice. I developped large parts of my tree with it. NULL
pointer derefs or writing to nirvana crashes instantly and gdb shows you
where we were. Some things even worked accidently on powerpc since it has
memory at location 0.

> And with some tweaking
> the 'sanbox' target should compile and run on all POSIX platforms, not
> just Linux. So calling it 'arch=linux' would be somehow limiting.
> 
> The relocation issue:
> 
> For the real targets U-Boot should be relocateable. Why? Simply because
> I might want to run something else than Linux on a target. U-Boot
> shouldn't occupy IRQ Vectors in RAM, nor should it be located in the
> middle of available RAM - simply because my 'OS' might want to use it as
> a single large block.
> 
> On most CPU architectures the IRQ/Except vectors can be placed into RAM
> - most times at address 0 and up. Most operating systems also link and
> load to the bootom of memory. The only place, which is rarely used by
> other code, is the top of memory. That's why U-Boot should relocate to
> this location whenever possible.

If thats what people want, so be it. I for myself prefer smaller binary
images. How about making it configurable? Would that be an option?
If I understand Grants lds patches right, they make the various
bin_reloc functions unnecessary anyway. The only things left are -fPIC
or not to the compiler and an ifdef around the GOT fixups in start.S

Regards
   Sascha

-- 
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de