[U-Boot-Users] Customizing U-boot

Wolfgang Denk wd at denx.de
Sat Sep 4 14:27:06 CEST 2004


Dear Roy,

in message <000f01c49233$69cee290$030aa8c0 at t> you wrote:
> 
> U-boot is made to suport many referense boards, but that the use of that?

No, this is not correct. U-Boot was designed to be  ported  on  _any_
hardware.  Actually  "reference  boards" are only a small fraction of
all supported systems - the majority is custom designs.

> it looks more like small OS than bootloader. It finaly must be customized to

This sounds as if this was a bad  thing?  I  think  this  is  one  of
U-Boot's  big  advantages  over other boot loaders: you can configure
just the functionality you need, but this includes a  lot  of  things
and options to select from.

> support some specific design only.

Would you prefer a small, dumb boot loader which does not need to  be
configured?  Then you're wrong on this list. There are many such dumb
solutions - chose something else.

> But I have some problems with this. Can someone tell boot functions
> sequence? they are highly scattered between c modules.

Just follow the flow of control out of reset. And  read  the  mailing
list archive. Your very question has been answered just yesterday (by
T. Michael Turney).

> it taked very long even to find reset vector. u-boot source is not very
> clear.

Ummmm... Maybe you didn't spend much time yet  working  with  U-Boot?
U-Boot  is  a  BIG  project.  There  is  about  800,000 lines of code
(including C, assembler and header files). You  don't  really  expect
that you will dig into this without a certain amount of work, do you?

> why random pars are in assembler and others in  C ?

Because some things are easier to implement in Assembler than  in  C.
And  because  you  need  a  certain runtime environment for C (like a
writable stack) which may not exist at certain stages of initialization.

> When init.S from /board/walnut405 directory is used?
> seems it is dublicated in /board/walnut405/walnut405.c but now in c
> language.

Please check again. There is no common code  (not  a  single  routine
with similar function name or purpose).

> when I dissasembled the compiled image I was unable to find anything from
> init.S

Really? You must have done something wrong, then.

When I check,  I  can  for  example  easily  find  the  code  of  the
ext_bus_cntlr_init() function in the U-Boot image:

Proof 1:

	-> nm u-boot | grep ext_bus_cntlr_init
	fff826e0 T ext_bus_cntlr_init

Proof 2:

	-> ppc_4xx-gdb u-boot
	GNU gdb Yellow Dog Linux (5.2.1-4b_4)
	Copyright 2002 Free Software Foundation, Inc.
	GDB is free software, covered by the GNU General Public License, and you are
	welcome to change it and/or distribute copies of it under certain conditions.
	Type "show copying" to see the conditions.
	There is absolutely no warranty for GDB.  Type "show warranty" for details.
	This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux"...
	(gdb) disassemble ext_bus_cntlr_init
	Dump of assembler code for function ext_bus_cntlr_init:
	0xfff826e0 <ext_bus_cntlr_init>:        mflr    r4
	0xfff826e4 <ext_bus_cntlr_init+4>:      bl      0xfff826e8 <ext_bus_cntlr_init+8>
	0xfff826e8 <ext_bus_cntlr_init+8>:      mflr    r3
	0xfff826ec <ext_bus_cntlr_init+12>:     mtlr    r4
	0xfff826f0 <ext_bus_cntlr_init+16>:     li      r4,14
	0xfff826f4 <ext_bus_cntlr_init+20>:     mtctr   r4
	0xfff826f8 <ext_bus_cntlr_init+24>:     icbt    r0,r3
	0xfff826fc <ext_bus_cntlr_init+28>:     addi    r3,r3,32
	0xfff82700 <ext_bus_cntlr_init+32>:     bdnz+   0xfff826f8 <ext_bus_cntlr_init+24>
	0xfff82704 <ext_bus_cntlr_init+36>:     lis     r3,0
	0xfff82708 <ext_bus_cntlr_init+40>:     ori     r3,r3,40960
	0xfff8270c <ext_bus_cntlr_init+44>:     mtctr   r3
	0xfff82710 <ext_bus_cntlr_init+48>:     bdnz-   0xfff82710 <ext_bus_cntlr_init+48>
	0xfff82714 <ext_bus_cntlr_init+52>:     li      r4,16
	0xfff82718 <ext_bus_cntlr_init+56>:     mtdcr   18,r4
	0xfff8271c <ext_bus_cntlr_init+60>:     lis     r4,-25855
	0xfff82720 <ext_bus_cntlr_init+64>:     ori     r4,r4,21632
	0xfff82724 <ext_bus_cntlr_init+68>:     mtdcr   19,r4
	0xfff82728 <ext_bus_cntlr_init+72>:     li      r4,0
	0xfff8272c <ext_bus_cntlr_init+76>:     mtdcr   18,r4
	0xfff82730 <ext_bus_cntlr_init+80>:     lis     r4,-15
	0xfff82734 <ext_bus_cntlr_init+84>:     ori     r4,r4,32768
	0xfff82738 <ext_bus_cntlr_init+88>:     mtdcr   19,r4
	0xfff8273c <ext_bus_cntlr_init+92>:     blr
	End of assembler dump.
	(gdb) 

> cpu/start.S does similar stuff and by some reason attempts to intialize some
> unknnown FPGA which is clearly unrelated to cpu at all, and should be moved

You got to learn to read the code. Did you  see  that  this  part  is
bracketed  by a "#ifdef CONFIG_BUBINGA405EP" ? So even if the FPGA is
unknown to you, it may be known and probably important to others.

If this is a good place for this part of code is a different issue.

> basicaly I would like to completely rewrite initialization procedure, and

May I suggest that you try to get a better understanding of the  code
and it's design principles first?

> put it all in one source file.

This is most definitely not a good idea.

> probably the best would be to discard all exsisting initialization source
> and write new one.

Please go on and do it. Just make sure that your need code  does  not
need  more  resources than the existing one, and - most of all - that
it still works on ALL supported systems.

> but I need boot function sequence for that.
> and point where the low level initialization is finished.

I think if you're going to rewrite everything from scratch you should
not bother about the existing crap.


> I need to make custom initialization for ram ,rom, blink leds on gpio.
> and mainly remove al pnp stuff, like spd. probably no real board will ever
> use spd for sram.

Oops. Seems I've seen a  lot  of  unreal  boards  then.  Seems  board
manufaturers don;t know what they are doing.

> also removing everyhing unnesecary is required, flash is not hdd aftreall.
> I need it for linuxAP the board is with single ppc405gp cpu with 1mb flash
> and 8mb ram, uart1 pins, and probably pci interface.
> so I need to fit uboot in something like 16kb or less, but first I need to
> make it run at least.

U-Boot was not designed to run in 16 kB, and not even in 64 kB.

> (that 1mb must fit kernel , rootfs, cfgdata, and bootloader) with 486 type
> cpu it is not big problem
> 
> Maybe someone know how much  u-boot can be stripped?

I'm afraid you're on the wrong list.  U-Boot  is  not  what  you  are
looking for. There are many simple boot loaders without all the fancy
stuff we appreciate in U-Boot, chose one of those instead.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
By the way, ALL software projects are done by iterative  prototyping.
Some companies call their prototypes "releases", that's all.




More information about the U-Boot mailing list