Dear Roy,
in message 000f01c49233$69cee290$030aa8c0@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