Hi,

Am Samstag, den 30.06.2007, 11:40 +0200 schrieb Robert Schwebel:

We'll do soon. The idea behind that activities (at the moment codenamed

Fine to hear that you guys work on it ;-) I asked about two week ago on this list, if there is any on-going project. And as I didn't get any answer, I simply did my own experiments.

I ported kconfig and modified the U-Boot sources to use it. Most time I spent on just grouping options in a kconfig tree. I tried to apply my changes in a way compatible with the existing U-Boot sources. You can now use the old, the new or a mixture of both system (strongly discouraged).

My own U-Boot target is using kconfig already, and porting further platforms from the old to the new system should be straight forward - just start 'make menuconfig' and answer all question from top down (No it's nmot complete yet... but easy to extend now.) And you can always switch back in case it doesn't work.

While doing these modification I found many 'problems' with the existing build system, which either need to be worked around (CFG_ style defines) or to be fixed the real way. There are also many things which could be simplified with kconfig. Although this will take some time, it is possible to migrate the current U-Boot configuration this way.

The other way is to recreate a new sourctree and throw away everything no longer needed, reorganize structure and so on - much easier. And after my review of the U-Boot source I tend to use the second way. But this would be basically a new project, and merging changes between both projects might become more difficult. Something I tried to avoid

From the list of features I got the impression, that u2boot used the

second way and is mostly done. And the described features and changes should solve most or all of the issues I found.

So when can we access a first draft of u-boot-ng? I would like to have a look on it. Maybe there is some way to allow users of u-boot to migrate smoothly to the new system.

It would be a pitty to have two bootloader projects covering the same targets. People would start to work on the one or other project, instead of focusing their efforts on a single solution.

Regards Carsten

Hi Wolfgang,

Sounds good - what about showing what you have? If you want, we can create a branch for this stuff...

It's already prepared. I created a page on my personal wiki for this issue. http://www.vahanus.net/~csc/wiki/index.php/U-Boot I will collect all related ideas on this page as some kind of issue digest.

I also reworked my patches and pushed everything to my public repository: http://www.vahanus.net/~csc/scm/u-boot.git kconfig-001

Forget the old patches I posted before - they are screwed up.

Can you please explain what these problems were? It would be nice if the new config system could keep the concept of different levels of configuration options (CONFIG_ being selections that can be made more or less as you like, I. e. things to select or deselect features or to change behaviour or defaults, while CFG_ are supposed to be settings needed to adapt (port) U-Boot to that specific hardware platform, I. e. these should never be touched by a "normal" user, but only by the board maintainer that understands the underlying hardware.

Right, the basic idea is fully ok. Unfortunately the standard kconfig system just creates CONFIG_* defines - there is no way foreseen to create different prefixes (yet :-) ). Also I got the impression, that this naming scheme is not used consistently. I currently rework the problem with some auxiliary header file (autoconf_glues.h), which translates from CONFIG_* to CFG_* defines. It also does the magic for the special defines like CONFIG_POST and similiar. This is just a temporary solution until a common agreement for whatever problem is found.

I would like to know how you delt for example with situations where a config file setting refers to other config options or even inline code, for example like these:

#define CONFIG_SYS_CLK_FREQ ((in8(CFG_BCSR_BASE + 3) & 0x80) ? \ 33333333 : 33000000) ...

Again, kconfig doesn't allow for plain defines (yet :-) ). But I would strongly discourage the use of such 'plain' macros, as they can cause difficult to detect problems and broken code. Maybe it's even the reason why kconfig doesn't support that...

The better way would be to have kconfig configuration options for this. You can select a plain const value like #define CONFIG_SYSCLK_FREQ 33000 or to choose some additional option, which allows you to change the define into something like #define CONFIG_SYSCLK_FREQ <boardname>_GetSysClock()

#define CFG_PCI_MEMBASE 0x80000000 /* mapped pci memory */ #define CFG_PCI_MEMBASE1 CFG_PCI_MEMBASE + 0x10000000 #define CFG_PCI_MEMBASE2 CFG_PCI_MEMBASE1 + 0x10000000 #define CFG_PCI_MEMBASE3 CFG_PCI_MEMBASE2 + 0x10000000

You would specify these values as plain hexvalues in kconfig. Normally these values never change - the use of a baseaddress macros and offset for the other membases is just good C programming practice.

For absolute addresses you can try this with my git branch with the DRAM or Flash settings - just define more banks to see the effect. This will define sets of base address and size defines. Of course if this is more useful, we can also use a base address + offset approach.

[Examples taken from include/configs/sequoia.h]

Yes, there are many examples for creative use of macros in the board headers :-) But I'm also very creative in finding solution for such interesting problems :-) There are already some solutions for problematic macros in my git branch - e.g. CONFIG_COMMANDS is fixed in cmd_confdef.h. Ok, that's still some easy example.

So without changes to the makefiles and headers it surely won't work. But everything can be fixed in small steps - and with a good search&replace tool all references and uses to a specific define can be changed easily.

Even if these efforts get merged somehow later, there is a pretty big danger of wasting resources by duplicating efforts.

I fully agree on this and everything you said here and in the previous mail.

Regards Carsten

____________ Virus checked by G DATA AntiVirusKit Version: AVKA 17.257 from 28.06.2007 ____________ Virus checked by G DATA AntiVirus Version: AVKB 17.283 from 02.07.2007 Virus news: www.antiviruslab.com

Hi Wolfgang,

On Sun, Jul 01, 2007 at 11:17:15AM -0400, Wolfgang Denk wrote:

Hi Robert & Sascha,

...

...

It would be nice if you could disclose what you are working on and discuss it here in public, before the design is cast in stone, so others can contribute ideas and/or code, give hints and comments and/or raise their concerns.

We'll do soon. The idea behind that activities (at the moment codenamed "u2boot", but we'll definitely aim at contributing that work into the u-boot community as a proposal for next-generation) is that, due to

Please don't wait too long with that. Remember to release early & often. I think it would be good if you shared your ideas without further delay - you see that there are activities going on elsewhere which address some of these topics, too, and it would be sad if anybody was wasting resources by duplicating efforts.

Also, it is much easier to come to an agreement about design criteria and approaches for the implementation if discussed early. It will be much more difficult if you throw a full-grown thingy at us - I really appreciate your contribution and would like to avoid getting into a "use it or lose it but it's too late to change the design" situation.

There's a lot of new stuff so I had to make design decisions, but nothing is set in stone yet. We can still change things and in fact I expect this stuff to be unstable for a longer time. Much work has been gone into splitting unrelated things apart and reorder them in a clean way. Many things do not use global variables anymore and generally use more abstraction. So even if we come to the conclusion that I made wrong design decisions and things must be rewritten again, we still have a relatively clean tree to identify these things and to see what other parts a change will affect.

...

u-boot's very impressive long term stability and maintenance politics, it is relatively difficult to change fundamental things in a clean way, because you cannot do this while ensuring that all boards do still work.

I see no problem with starting a new line of development in a separate branch if this should make sense.

...

So here's a short and incomplete list of what Sascha has implemented so far:

That's an awful lot, and I feel that you should have come out with this stuff much, much earlier.

Yes, you're right. Hacking without discussing it just gave me the possibility to clean up things and see how they evolve before other people can say 'doing this breaks board xy'. When I started this I did not know if the ideas I had were even implementable.

Please consider using git instead of SVN...

...

• Kconfig configuration system, stolen from Linux.

We don't steal code. It's Free Software. Please avoid such terminoloy - we understand what you mean, but others might not and quote you out of context.

...

Plus more goodies all over the place.

All this sounds fantastic, but please don't do this any longer behind clodes doors and without interaction with the community.

...

So please be patient for some days - I'll promise you that it's definitely worth it :-)

Can you please specify what "some days" means? 2? 5? 20? 50? 200?

Zero days. Last weekend I cleaned up my mess and have something to upload. Could you provide an upload account? (right at the moment I'm trying to find out how git-svnimport or git-svn are supposed to work, this can take some time ;)

Sascha

On Mon, Jul 02, 2007 at 01:22:43PM -0400, Jerry Van Baren wrote:

Sascha Hauer wrote:

...

Hi,

I just prepared a git repository for our U-Boot-NG proposal. Do a

git clone http://iocaste.extern.pengutronix.de/git/U-Boot-NG.git

(no native git support at the moment)

There is also a tarball snapshot available here:

http://pengutronix.de/software/ptxdist/temporary-src/U-Boot-NG-20070702.tar....

This is only a temporary place for the source, further development should probably either be done on Wolgangs server or some other dedicated server. The tree is based on vanilla U-Boot-1.2.0.

As a starting point I've included the README in this mail. It's also included in the source tree under README.u2. Further documentation can be found under Documentation/ and of course in the code ;)

Regards, Sascha Hauer

Hi Sascha,

This is very, very interesting. One stupid ;-) question, what sort of trade-offs are we looking at, other than the lack of backwards support of various boards? In particular, how does the memory footprint compare for an equivalently configured target?

Hi Jerry,

The image space needed has not significantly changed. On Arm it's slightly bigger if you enable the same features. But on Arm you do not need zlib, which is configurable now. This saves you around 15k. The PowerPC images got smaller than before. The code is not position independent anymore, this saves around 10% of binary space. Console support has been rewritten. Together with the list implementation which was only used for console this gained 5k. The environment support was very complicated with the serial functions used on startup. With these fixes and many other ones enough space was available to implement filesystem support without increasing the image size.

My current Arm image (for the scb9328) is 85k, it includes hush parser, networking and nor flash support. With cramfs enabled (zlib) it has 97k The PowerPC image (MPC5200, Phytec Phycore board) has 127k with hush parser, cramfs and oftree support.

I think that big U-Boot images will get smaller because there is more infrastructure you can use. Small images may get bigger because the infrastructure is still in place

I did not look at RAM usage, but I think that is no matter for most boards since they have orders magnitude more RAM than U-Boot needs.

Sascha

On Tue, Jul 03, 2007 at 01:39:29AM +0200, Wolfgang Denk wrote:

In message 20070702184259.GA2533@pengutronix.de you wrote:

...

bigger if you enable the same features. But on Arm you do not need zlib, which is configurable now. This saves you around 15k.

You don't? How do you uncompress an image then?

On Arm by default zImages are used to generate the uImage, so the kernel decompresses itself.

...

The PowerPC images got smaller than before. The code is not position independent anymore, this saves around 10% of binary space.

The code has never been position independent; it gets relocated.

The code itself would have been position independent because it was compiled with -fPIC.

Do you mean you don't relocate the code any more?

It still gets copied from the address U-Boot starts (Flash) to RAM, but pointer offsets are not recalculated. This means that you must not use statically initialized pointers during startup since the code is not running at its link address. The Arm part has done this for years. On PowerPC we have the luxury of having SRAM, so we can setup a stack and do SDRAM initialization in C before jumping to RAM.

Regards Sascha

On Mon, Jul 02, 2007 at 07:46:38PM -0600, Grant Likely wrote:

On 7/2/07, Sascha Hauer s.hauer@pengutronix.de wrote:

...

On Tue, Jul 03, 2007 at 01:39:29AM +0200, Wolfgang Denk wrote:

...

Do you mean you don't relocate the code any more?

It still gets copied from the address U-Boot starts (Flash) to RAM, but pointer offsets are not recalculated. This means that you must not use statically initialized pointers during startup since the code is not running at its link address.

And this is a bug. Statically initialized pointers are supposed to be fixed up during relocation. I've got a big patch set which I'll be posting this evening (and would have already posted if I wasn't having SMTP problems) that solves this for 5xx, 5xxx, 82xx & 83xx.

If you do not use statically initialized pointer on startup and running at the link address after startup, you do not need to fixup anything.

I think the intent of relocation is that the u-boot image can always put itself at the end of SDRAM, regardless of how much ram is on the board. Not important for ports that have soldered down chips, but useful if the board has expandable memory.

When you can make use of this additional memory, ok. But I think on U-Boot this is hardly the case.

Regards, Sascha

In message fa686aa40707030836r565db1e8hc2beead79034828e@mail.gmail.com you wrote:

...

If you do not use statically initialized pointer on startup and running at the link address after startup, you do not need to fixup anything.

... assuming that the u-boot design goal is changed to use a static relocation address instead of the detected end of RAM.

No, this has not been changed, and I will fight hard to keep this. Actually I'm trying hard to get this fixed for the non-conforming architectured (ARM, MIPS, ...) which I consider broken.

It's not a matter of making use of all the additional memory; it's more a matter of not having an unaccessable region in the middle of the RAM block. There are a *lot* of different board configurations and a lot of different complex systems that load more than just a linux kernel.

ACK. And there are even systems which don't run Linux at all.

Best regards,

Wolfgang Denk

In message 20070704083514.GM25364@pengutronix.de you wrote:

On Tue, Jul 03, 2007 at 09:36:03AM -0600, Grant Likely wrote:

...

...

If you do not use statically initialized pointer on startup and running at the link address after startup, you do not need to fixup anything.

... assuming that the u-boot design goal is changed to use a static relocation address instead of the detected end of RAM.

Can you elaborate the use case for that scenario?

Assume you have a board that comes with either 32 or 64 MB of RAM. At the moment, U-Boot always relocates to the end of the RAM, i. e. you have some 31+ resp. 63+ MB free contiguous RAM to load an OS and application images etc.

If you use a static link address you would always relocate U-Boot below the 32 MB limit.

Now explain to a customer with a 64 MB RAM configuration why he cannot load a ramdisk image of 33 MB...

Best regards,

Wolfgang Denk

In message fa686aa40707021846vb09da41g6d0d9e7212cb484f@mail.gmail.com you wrote:

I think the intent of relocation is that the u-boot image can always put itself at the end of SDRAM, regardless of how much ram is on the board. Not important for ports that have soldered down chips, but useful if the board has expandable memory.

Also extremely useful for boards that have soldered down chips, but are available in several configurations as this saves the board manufacturer from the maintenance nightmare of having to select the correct out of so many different U-Boot binary images.

Best regards,

Wolfgang Denk

On Tue, Jul 03, 2007 at 09:22:29AM +0200, Wolfgang Denk wrote:

In message 20070703000910.GA15081@pengutronix.de you wrote:

...

...

You don't? How do you uncompress an image then?

On Arm by default zImages are used to generate the uImage, so the kernel decompresses itself.

For the Linux kernel, maybe. But there are many more things than just Linux. Think for example about FPGA images, etc.

That's why it's configurable.

...

...

Do you mean you don't relocate the code any more?

It still gets copied from the address U-Boot starts (Flash) to RAM, but pointer offsets are not recalculated. This means that you must not use statically initialized pointers during startup since the code is not running at its link address.

Are you doing this for all architectures now?

PowerPC was the only architecture compiling with -fPIC.

...

The Arm part has done this for years. On PowerPC we have the luxury of

Yes, and this is my major critique to the ARM (and the MIPS, and maybe other) ports. We should fix this. Like on PowerPC, U-Boot should always be copied to the upper end of RAM instead of a precalculated address, as this cannot cope with different RAM sizes.

If you insist on going to the upper end of RAM, yes. But why do you want to go there? On PowerPC you could go to the upper end of the smallest available RAM, which leaves enough space for U-Boot. Or you could link to 4MB or something in RAM and put the malloc area behind that. 4MB in RAM leaves enough space for copying kernel images to 0.

...

having SRAM, so we can setup a stack and do SDRAM initialization in C before jumping to RAM.

Not all PowerPC processors have on-chip or other static RAM; in some cases we use (for example) the data cache as memory. Similar techniqes should be possible on all architectures.

Not on Arm, as far as I know. At least I have not seen any examples. But on Arm you have the 'naked' attribute allowing it to run C code from the reset vector on. Apex does this.

Regards, Sascha

On 7/2/07, Sascha Hauer s.hauer@pengutronix.de wrote:

The tree is based on vanilla U-Boot-1.2.0.

$ git diff -B -M -C --stat U-Boot-1_2_0..HEAD [...] 3628 files changed, 50350 insertions(+), 755286 deletions(-)

Wow. You certainly got rid of some old cruft (hopefully it's _only_ cruft ;-)

$ make ARCH=avr32 CROSS_COMPILE=avr32-linux- menuconfig Makefile:394: /Users/hskinnemoen/work/git/U-Boot-NG/arch/avr32/Makefile: No such file or directory make: *** No rule to make target `/Users/hskinnemoen/work/git/U-Boot-NG/arch/avr32/Makefile'. Stop. $ ls arch/ arm linux ppc

Ok, not only old cruft then :-P

There seems to be a lot of nice stuff in there though -- I hope we'll see at least some of it in mainline. It's probably going to take some work to get everything split up into nice and small logical steps; especially getting all existing architectures and boards moved into the new directory structure all at once is probably going to hurt...

I'd be happy to help porting the avr32 stuff over if/when we decide to go for this.

Btw, I couldn't help but notice there's a "new" cfi flash driver in there. How is it different from the existing one?

Håvard

On 7/2/07, Sascha Hauer s.hauer@pengutronix.de wrote:

On Mon, Jul 02, 2007 at 08:25:35PM +0200, Håvard Skinnemoen wrote:

...

There seems to be a lot of nice stuff in there though -- I hope we'll see at least some of it in mainline. It's probably going to take some work to get everything split up into nice and small logical steps; especially getting all existing architectures and boards moved into the new directory structure all at once is probably going to hurt...

It's actually less work than you might think. Especially avr32 seems to be very small. Just add arch/avr32, add a Makefile and a clocksource driver, through away most parts of your config.h and you're half way there. There is a README.porting under Documentation.

I'll give it a try as soon as I can find a few spare hours. There's been a few quite intrusive (and important) changes in the avr32 code since 1.2.0, so I'll probably backport the code from latest git rather than move the 1.2.0 stuff around.

Håvard

On Mon, Jul 02, 2007 at 10:37:26PM +0200, Carsten Schlote wrote:

Hi Sascha,

Am Montag, den 02.07.2007, 21:26 +0200 schrieb Sascha Hauer:

...

I'm too using ld-2.17: GNU ld (GNU Binutils for Debian) 2.17.50.20070426

Here (debian/etch): GNU ld version 2.17 Debian GNU/Linux

Maybe one of your patch levels introduced CONSTANT as glue to support different pagesizes with the same linker script?

...

gcc version is 4.1.2.

Here: gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

...

with 'ld --verbose'. Maybe a diff between yours and the one used in U-Boot can give some light?

...

ld --verbose

... . = ALIGN (0x1000) - ((0x1000 - .) & (0x1000 - 1)); . = DATA_SEGMENT_ALIGN (0x1000, 0x1000); ...

This is the line causing the problem. As you can see, my ld uses hardwired constants, not CONSTANT(...).

As CONSTANT() is not documented on the sourceware.org/binutils pages I presume it's a non-mainstream extension.

Maybe we can distinguish between ia64 and i386 targets and set defines appropriately in u-boot.lds.h? Or use only mainstream LD builtins for our links scripts.

I first used a linker script from um-linux, but there were some linux specific things in it, so I switched to the one from ld. On x86-64 the image size is around 2MB, so maybe the one from the kernel was the better choice

Regards Sascha

On 7/3/07, Carsten Schlote c.schlote@konzeptpark.de wrote:

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.

I actually think we should go a step farther. I think we should split u-boot into two linked images; a setup wrapper and u-boot proper (in the same way that the linux kernel is wrapped by a zImage wrapper). The sole purpose of the setup wrapper is to configure RAM and copy the u-boot proper image to location at the end of RAM. The u-boot proper image starts with the assembler routines to setup the C environment and fixup the relocation symbols before jumping into main.

The goal should be to get into the u-boot wrapper C environment as soon as possible. The wrapper shouldn't do anything other than initialize RAM, copy code, and provide a little bit of debug output. As much as possible should be deferred to u-boot proper.

The advantage of this approach is that it makes it easier to handle weird booting arrangements. As long as something sets up ram and copies u-boot proper; then u-boot can run (which is very similar to what some ARM and one of my Xilinx Virtex ports already does. It also allows a single u-boot image to be used for booting from both RAM and ROM (which I think is helpful). It would also make it trivial to turn dynamic relocation into a configuration option.

The disadvantage is that the setup wrapper cannot use the full facilities of u-boot proper. Every routine used by both the setup wrapper and u-boot proper will exist in both images. If it weren't for the desire to have console output before relocation, I think this approach would be the clear winner. However, the requirements as I understand them are for the boot code to fetch the console configuration out of the environment and spit out some boot info. This of course complicates things because it means the wrapper needs more functionality.

I see a few approaches to handle this: 1. eliminate console output from the wrapper. (by far the easiest, but provides no clues when RAM configuration fails). 2. cut down wrapper functionality in the wrapper (this is just early boot after all). Eliminate printf() support in the wrapper and make due with puts(). Reduce the wrapper console driver to output only. The problem still remains that the env needs to be read to know how to configure the console. 3. Same as two; but don't read the environment. Use a static console config instead.

Other approaches probably exist.

Regardless of the approach, the choice of which to use can be made per-board, which is a suitable tradeoff between size and functionality. My gut feel is that for most boards, the boot wrapper will be very small, but I need to do some experiments to know for sure.

Cheers, g.

On 7/3/07, Ulf Samuelsson ulf@atmel.com wrote:

The AT91-Bootstrap used by AT91SAM926x is less than 4 kB, and supports console output as well as loading u-Boot from the precompiled flash memory into SDRAM.

You only support booting from a single flash type in each binary, which is stored inside that memory.

There is no interactive communication with the user, so this starts when u-boot is loaded.

It does not read the environment, since it should be useable to load any application into SDRAM, not just U-Boot.

It is GPL, so I guess that it can be used as a base for this.

Cool; yes this is exactly the approach I'm thinking about.

g.

On 7/3/07, Sascha Hauer s.hauer@pengutronix.de wrote:

...

I see a few approaches to handle this:

1. eliminate console output from the wrapper. (by far the easiest,

but provides no clues when RAM configuration fails). 2. cut down wrapper functionality in the wrapper (this is just early boot after all). Eliminate printf() support in the wrapper and make due with puts(). Reduce the wrapper console driver to output only. The problem still remains that the env needs to be read to know how to configure the console. 3. Same as two; but don't read the environment. Use a static console config instead.

Do we really need console output before U-Boot has initialised SDRAM? For debugging some simple PUTC() and PUTHEX() macros would be sufficient. Of course they have to be disabled on systems designed to have a quiet console.

I think it is a good idea to at least default to spitting out *something* on boot. Just in case RAM is hooped.

g.

On 7/3/07, Rune Torgersen runet@innovsys.com wrote:

...

I think it is a good idea to at least default to spitting out *something* on boot. Just in case RAM is hooped.

Console output before RAM is initialized is EXTREMELY important. I thin on our boards, 90% of the output on boot is before RAM is initalized. And when you try to bring up a new board, you definetly need it.

Hmmm.... okay, so what does that output consist of? I can be convinced that pre-RAM output is necessary, but why is it 90%?

g.

On 7/3/07, Rune Torgersen runet@innovsys.com wrote:

...

-----Original Message----- From: Grant Likely Hmmm.... okay, so what does that output consist of? I can be convinced that pre-RAM output is necessary, but why is it 90%?

Okay, so it's closer to 50-60% than 90... On our other board without PCI, we're talking about 6 lines after and 25 lines before RAM is initailized.

Other than effort required; any objection to changing that approach?

g.

On 7/3/07, Rune Torgersen runet@innovsys.com wrote:

...

From: Grant Likely On 7/3/07, Rune Torgersen runet@innovsys.com wrote: Other than effort required; any objection to changing that approach?

I personally believe that the terminal output capabilities of U-Boot (ie having serial or other output almost as soon as you can run C code) is one of the biggest strong points of u-boot, and are very useful when doing a board bringup or debugging non-working boards. Changing that would be a mistake on my opinion (even for reducing code size/complexity).

Sorry; let me be more specific; any objection to moving device initialization to *after* relocation to RAM. I'm not asking about removing console output.

g.

On 7/3/07, Rune Torgersen runet@innovsys.com wrote:

...

From: Grant Likely Sorry; let me be more specific; any objection to moving device initialization to *after* relocation to RAM. I'm not asking about removing console output.

Most devices are fine to init after RAM. Exceptions being FPGA's and I2C. FPGA's because on a lot of boards they control enough stuff that you may not be able to init memory witout them. (On ours it could be deffered without problems). I2C is necessary to read the info off of the SDRAM modules when memory is NOT soldered down.

On Freescale CPU's that means all IO-pin setup and CPM reset has to be done before memory init also.

Okay, good.

g.

Grant Likely wrote:

On 7/3/07, Rune Torgersen runet@innovsys.com wrote:

...

...

From: Grant Likely On 7/3/07, Rune Torgersen runet@innovsys.com wrote: Other than effort required; any objection to changing that approach?

I personally believe that the terminal output capabilities of U-Boot (ie having serial or other output almost as soon as you can run C code) is one of the biggest strong points of u-boot, and are very useful when doing a board bringup or debugging non-working boards. Changing that would be a mistake on my opinion (even for reducing code size/complexity).

Sorry; let me be more specific; any objection to moving device initialization to *after* relocation to RAM. I'm not asking about removing console output.

Initialization of some devices could even be deferred until they are really used like PCMCIA/IDE or DTT.

Wolfgang.

In message fa686aa40707031221y7f30c01n38f0b13be9600ebc@mail.gmail.com you wrote:

Sorry; let me be more specific; any objection to moving device initialization to *after* relocation to RAM. I'm not asking about removing console output.

Yes, I *do* object. Please see previous messages.

You know how much I'm fighting over a few bytes memory footprint here and there, but this is something that is so vitally important for porting U-Boot to green hardware that I am happy to "waste" whatever it needs in terms of memory for this feature.

Best regards,

Wolfgang Denk

In message fa686aa40707031559x4d9c3af8t92dacad96681e1f@mail.gmail.com you wrote:

...

...

Sorry; let me be more specific; any objection to moving device initialization to *after* relocation to RAM. I'm not asking about removing console output.

Yes, I *do* object. Please see previous messages.

You know how much I'm fighting over a few bytes memory footprint here and there, but this is something that is so vitally important for porting U-Boot to green hardware that I am happy to "waste" whatever it needs in terms of memory for this feature.

But why does this affect device initialization? To get to running in RAM; there needs to be three things: RAM initialized correctly, code copied and basic console output for progress metering. Why do devices not related to these three things matter? Why can't they be deferred until after relocation to RAM?

Sorry, I misread your statement above (didn't see the "I'm not asking about removing console output." part of it.).

I say don't get distracted with non-essential peripherals when the first priority is to get into RAM.

I agree 100%. What I would like to have in a new version is that devices only get initialized before they are actually used in U-Boot, and get deiniztialized (shut down completely) after being used (not doing the latter is a continuing PITA in the current code).

Best regards,

Wolfgang Denk

On 7/3/07, Andrew Dyer amdyer@gmail.com wrote:

I would like to see the 'second stage' of u-boot be made more modular. I imagine a set of basic code (console, environment, loader, storage driver) would get loaded first and additional commands and drivers could be stored as compressed uImages and loaded as needed and chained onto the list of valid commands/functions. This shouldn't be allowed to get too out of hand (no automatic dependency resolution, autoloading, or anything like that :-)

Doesn't this already kind of exist in the form of u-boot applications?

It might be nice to have something like tinderbox - a machine churning through building all of the supported platforms based on a top of git stable and/or testing branch and have a web status. It would make it easier to test system wide changes if the developer doesn't have all of the toolchains on their machines and would help keep platforms code from getting 'stale'.

I agree 100%. The biggest problem here is not having anyone interested and with enough time to write and maintain it. Also, since there are so many board ports involved, the tinderbox should be somewhat distributed so that the builds can also be tested on the various boards developer have scattered about the globe. (ie. ideally it should be dead easy for someone to volunteer time on one of their boards to be part of the tinderbox process)

Is u-boot big enough to have a 'janitor'?

Yes, are you volunteering? :-D

Cheers, g.

On 7/3/07, Grant Likely grant.likely@secretlab.ca wrote:

On 7/3/07, Andrew Dyer amdyer@gmail.com wrote:

...

I would like to see the 'second stage' of u-boot be made more modular. I imagine a set of basic code (console, environment, loader, storage driver) would get loaded first and additional commands and drivers could be stored as compressed uImages and loaded as needed and chained onto the list of valid commands/functions. This shouldn't be allowed to get too out of hand (no automatic dependency resolution, autoloading, or anything like that :-)

Doesn't this already kind of exist in the form of u-boot applications?

Yes, but I'm proposing that more of the /u-boot/ functionality be made application-like so things that get used only occasionally don't have to be in the main boot flash.

On Wednesday 04 July 2007, Sascha Hauer wrote:

...

I agree 100%. What I would like to have in a new version is that devices only get initialized before they are actually used in U-Boot, and get deiniztialized (shut down completely) after being used (not doing the latter is a continuing PITA in the current code).

My tree already has a device structure containing the usual probe function. This should only make sure that the device is registered and can be used, but actual initialization can be defered. The thing currently missing is a tree structure for devices. They are all in one simple linked list, so you cannot make sure that the devices get de-initialized in the correct order.

btw I know one exception to the only-initialized-when-used rule. We often need to initialize the MAC Address in ethernet devices, even when they are not used.

My crystal ball just told me, that there will be a remark from Wolfgang about this statement. ;-)

Best regards, Stefan

===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

In message 200707041353.17753.sr@denx.de you wrote:

...

btw I know one exception to the only-initialized-when-used rule. We often need to initialize the MAC Address in ethernet devices, even when they are not used.

My crystal ball just told me, that there will be a remark from Wolfgang about this statement. ;-)

Actually I tended to ignore that here to keep the discussion focussed on more vital things, but you left me no choice ;-)

Best regards,

Wolfgang Denk

In message fa686aa40707040839x5622694apd6e49b6a4d2028a5@mail.gmail.com you wrote:

And wd takes the bait. What else can you get him to do Stefan? :-D

Drink beer?

Best regards,

Wolfgang Denk

Grant Likely wrote:

On 7/3/07, Rune Torgersen runet@innovsys.com wrote:

...

...

I think it is a good idea to at least default to spitting out *something* on boot. Just in case RAM is hooped.

Console output before RAM is initialized is EXTREMELY important. I thin on our boards, 90% of the output on boot is before RAM is initalized. And when you try to bring up a new board, you definetly need it.

Hmmm.... okay, so what does that output consist of? I can be convinced that pre-RAM output is necessary, but why is it 90%?

g.

Maybe because the remaining 10% is really, really small? ;-)

One technique I've used in the past that has worked well is to output successive characters at critical points in the code. (It became known around here as "alphabet soup.") If the board stopped spitting out characters prematurely, you have a clue what is wrong.

I also attempted to dump the registers on an error (test result information being held in the registers). Depending on the error, this might not be successful, but if it is successful, you can glean quite a bit of information from the registers and what test was running at the time of the failure.

Advantages: * Still helpful identifying problems * Minimal start up delay (generally don't have to wait for the UART since you are throwing out single characters with tests in between) * Only need a very simple character put routine (plus a slightly more elaborate register dump if supported). In this concept, putchar() is good, puts() is acceptable, and printf() is evil.

Disadvantages: * Cryptic - need a secret decoder ring to figure out what test was being run and what the registers are telling you. * Depending on how cryptic the output is, it may be totally useless for certain classes of misconfigurations

I would assert, with no proof to back that assertion, that most of the current text output could be deferred to after RAM was initialized. For instance, we don't really need to know what processor version and mask before RAM is initialize, do we?

From Rune's email with my 0.02 cents interspersed ...

U-Boot 1.1.4 (Apr 17 2007 - 13:30:37)

Defer to after RAM reloc

MPC8260 Reset Status: External Soft, External Hard

Can be represented with a single character and a secret decoder ring

MPC8260 Clock Configuration

• Bus-to-Core Mult 4.5x, VCO Div 2, 60x Bus Freq 22-65 , Core Freq

100-300

• dfbrg 0, corecnf 0x17, busdf 5, cpmdf 1, plldf 0, pllmf 5
• vco_out 597196800, scc_clk 149299200, brg_clk 149299200
• cpu_clk 447897600, cpm_clk 298598400, bus_clk 99532800
• pci_clk 49766400

One or two of these may be useful, but even that is debatable. * Some of these, if wrong, will cause complete board failure and the above won't be printed anyway. * Most can be deferred till after RAM reloc

CPU: MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz Board: Innovative Systems AP2, CPU1 Build: $SvnTreeRevision: 89 $

Defer till after RAM reloc

   Watchdog enabled

Single character

UPMs: Configured

Single character

FPGA: (cfgaddr 0xff810000)............ Status = OK Altera ID: 0x110b

Single character

I2C: ready

Single character

DRAM: DIMM socket probe: Slot1 = 1, Slot2 =1

Single character

    SDRAM configuration read from SPD

Single character

    Size per side = 256MB
    Organization: 4 sides, 4 banks, 10 Columns, 13 Rows, Width = 64

bits Refresh rate = 13, CAS latency = 2, Using Page Based interleave EAMUX = 0 Total size: 1024 MB

This is very useful information and where I would expect most misconfiguration failures to show up.

If RAM doesn't work and the "alphabet soup" identifies that RAM is where things stopped working, manufacturing typically debugs these types of problems by simply replacing the RAM DIMM regardless of how detailed your printed information is. :-/

If RAM works enough (and it often does work enough), a summary could be printed before relocation to RAM and full information printed after relocation.

!!! Skipping Memtest (SkipMemtest env varable set) !!!

Single character

Now running in RAM - U-Boot at: 0ff97000

We are running! Start spewing the detailed information!

Best regards, gvb

In message fa686aa40707031117l7ba9226cu7a606b06d39f8e40@mail.gmail.com you wrote:

Hmmm.... okay, so what does that output consist of? I can be convinced that pre-RAM output is necessary, but why is it 90%?

The important thing for me is to follow the principle of printing "Do foo..." before and "done" after doing "foo" (not necessarily exactly with these words), so you can always see exactly which initialization step was failing.

This includes things like clock setup (printing, for example, _measured_ clock frequencies instead of configured ones whenever possible), memory setup, etc.

Best regards,

Wolfgang Denk

In message 20070703175856.GB8839@pengutronix.de you wrote:

Do we really need console output before U-Boot has initialised SDRAM?

Yes, we do. This is one of the things I definitely want to keep as it saved me lots of hours before. I won't give this up lightly.

It's important for board bringup, and it's also very useful that you always see it when booting - if U-Boot hangs because a RAM or a flash or a XXX error, you always KNOW it because the last thing you see on the console is "RAM" or "FLash" or "XXX". This is a very important feature.

I guess I should write some design principles for U-Boot...

Best regards,

Wolfgang Denk

Hi Sascha,

On Wednesday 04 July 2007, Sascha Hauer wrote:

...

Yes, we do. This is one of the things I definitely want to keep as it saved me lots of hours before. I won't give this up lightly.

I don't understand what's so damn complicated about setting up SDRAM. This is one of the most basic things during lowlevel development.

You seem to never have dealt with a complex DDR2 setup with DIMM modules (and optionally with ECC support). Please take a look at cpu/ppc4xx/44x_spd_ddr2.c). It is pretty hard to come up with a common (cpu platform) code that can be used by several boards supporting a variety of DIMM modules. Here some debug printf's come in very handy.

Usually this part is about 20 lines in my bdi config. Transfering this into some lines Assembler

I thought those days were over. I will never ever go back to having to setup a SDRAM controller in assembler.

or C code is a piece of cake.

Ah, ok. At least C.

If you have to read some i2c data to get initialization settings, you have to do some bits more and I understand that one wants to have some putc/puthex to check if sane values are read. But again, this is lowlevel work and once it's running can forget about this.

No, you can't. Since the user might replace another DIMM module. Or even the board manufacturer.

Relocation is tricky, yes. But this is well reviewed code common for each SoC, or maybe (with some common code merge) even common for PPC. You won't have problems in this area on a production board.

All this has _nothing_ to do with production boards. Here the SDRAM initialization and relocation just work. If not, you're doomed anyway. After relocation everyone can begin to setup things as he likes. I first print a hello world on the console, others might look in the device tree first to get console information.

At the moment (PPC-)U-Boot does 90% of the whole initialization while running from Flash. All these serial read functions for the environment are just a pain. Do you really want to do the same thing for the device tree? Setting up things in SRAM and then copy them to SDRAM, possibly with relocation fixups is a pain. Setting up a preliminary environment in flash and relocate this complex thing afterwards with all this global_data handling is what I would call complicated and error prone.

Doing this is not a design criteria, it is one main design flaw in U-Boot. If you insist on doing it, we don't need to talk about a redesign, just leave everything like it is.

Note that in my tree there is one single entrypoint for all architectures, and the only thing needed to enter it is working RAM.

That's good.

This is straight forward: Everyone should be able to provide working RAM. If not, again you're doomed. If you need some debugging output to get to that point, well that's fine, but these are putc/puthex and _not_ printf. They are not compiled in in production code and therefore do not need quiet console checking.

On the setup mentioned above, the printf's (or at least some serial output) is really a great benefit. It would be a pity to loose this in this new U-Boot version.

Don't make things more complicated as they are. The earlier you enter a common entry point in U-Boot the more you can actually trust the code, since from there on it's common for _all_ architectures and the code will be best reviewed.

ACK.

Best regards, Stefan

===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

On Wednesday 04 July 2007, Sascha Hauer wrote:

...

You seem to never have dealt with a complex DDR2 setup with DIMM modules (and optionally with ECC support). Please take a look at cpu/ppc4xx/44x_spd_ddr2.c).

I just did. The information this file outputs can easily be transfered to puts/puthex.

Yes, this could be done. I just wanted to make a point, that not all SDRAM configuration are "easy" and fit into a few lines of code.

I'm not against early consoles in general, they are a good thing. But you have to decide: Either you can provide a serial port suitable for this kind of output, or you can't because this port is normally occupied by a modem or something, but putting the information about this in such a complicated thing as the environment or even the device tree is just the wrong way.

...

It is pretty hard to come up with a common (cpu platform) code that can be used by several boards supporting a variety of DIMM modules. Here some debug printf's come in very handy.

...

Usually this part is about 20 lines in my bdi config. Transfering this into some lines Assembler

I thought those days were over. I will never ever go back to having to setup a SDRAM controller in assembler.

I understand that you don't want to do such complicated things as done in spd_sdram.c in assembler (and I don't want other people to do it in assembler, that would be sadistic ;)

Yep. ;-)

But there is the other end aswell: On Arm it's really simple like that. You do not even have SRAM to use as a stack pointer (at least not as a general feature).

If you want output before SDRAM init, lets do it in form of a _simple_ console. Reading device tree contents or environment before the general entry point is just bloated and imho cannot be done in a way everybody is happy.

I'm still a little undecided, if a "simple" output mechanism is enough. Of course you can life with a hardwired baudrate on most systems, so that you don't have to read the environment. But there will be some systems where the user configured a different baudrate and the outputs from the DDR2 init routine will not be readable.

But you are right: Making this step hardcoded makes the overall design much more simple. So that would be a "Good Thing" (TM).

Even netconsole was already mentioned somewhere. This can simply not be implemented on other architectures than powerpc because of the lack of SRAM.

Yes, something like netconsole has to be initializes quite late in the bootup process.

I once wondered why it takes _so_ long to get a prompt on my MPC5200 board. The solution was simple: U-Boot was busy reading the environment from EEPROM several times.

Yes. That is one of the reasons, why it is strongly discouraged to use I2C EEPROM for environment storage.

Once for the checksum, once again for std* settings and then for the baudrate setting. I was unable to fix it though because my only chance was to #ifdef all around the place and completely change the startup prodedure for my $SPECIAL_BOARD

...

...

or C code is a piece of cake.

Ah, ok. At least C.

...

If you have to read some i2c data to get initialization settings, you have to do some bits more and I understand that one wants to have some putc/puthex to check if sane values are read. But again, this is lowlevel work and once it's running can forget about this.

No, you can't. Since the user might replace another DIMM module. Or even the board manufacturer.

Board manufactures should be able to buy DIMM modules which are compatible with the board or have some 'verbose early debug U-Boot' in place which they can use when testing new DIMMs.

That's the way it *should* be. But unfortunately this is not always the case. At least we have seen it happen before, that not supported modules were shipped. :-(

And when I buy new DIMMs for my PC the 'no memory' beep tells me that this module is not compatible. I do not need more information (I could not make use of it anyway).

If no output on the serial console always means: "problem with memory", than this would be an easy indication for SDRAM problems. But I have seen lots of other errors, that lead to a hangup in the very early boot stage. Most of the time *before* SDRAM is initialized.

Don't get me wrong. I generally like this 2 stage approach. For example it fits the NAND booting support (see nand_spl/*) where a small (4k on 4xx) first stage loader is needed. I'm just a little hesitant about dropping the full featured printf in early boot stages.

Best regards, Stefan

===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

Hi Robert,

On Wednesday 04 July 2007, Robert Schwebel wrote:

...

I'm still a little undecided, if a "simple" output mechanism is enough. Of course you can life with a hardwired baudrate on most systems, so that you don't have to read the environment. But there will be some systems where the user configured a different baudrate and the outputs from the DDR2 init routine will not be readable.

Let's look at the PC architecture, which is really supposed to be customized by dummy users. It just makes BEEEP if the memory init goes wrong. People designed it this way on purpose. I know that there are brain damaged hardware designs in the industry, but please don't let us make strategic design decisions based on crappy hardware instead of the 95% case. I recognize that it is a good feature for these cases, but it's not a good excuse for transferring a straight forward, simple and maintainable design into a can of worms.

AFAIK the PC at least supports some kind of beep morse code to differentiate between different error sources.

...

If no output on the serial console always means: "problem with memory", than this would be an easy indication for SDRAM problems. But I have seen lots of other errors, that lead to a hangup in the very early boot stage. Most of the time *before* SDRAM is initialized.

Because lots of things are done before the SDRAM is initialized. All these would be done later in our design and thus would have access to the console.

You're only partly right here. On some platforms there has to happen quite a lot before you can begin with the SDRAM setup. Something like TLB setup, GPIO-setup, I2C setup comes to my mind right now.

...

Don't get me wrong. I generally like this 2 stage approach. For example it fits the NAND booting support (see nand_spl/*) where a small (4k on 4xx) first stage loader is needed. I'm just a little hesitant about dropping the full featured printf in early boot stages.

I assume the way we do the discussion now is really right - we throw in "it can be soooooo easy" ideas, you tell us the corner cases and then we iterate until everybody is happy :-)

Yes. Let's continue this way... :-)

Best regards, Stefan

===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

On Wed, Jul 04, 2007 at 04:02:43PM +0200, Wolfgang Denk wrote:

...

Let's look at the PC architecture, which is really supposed to be customized by dummy users. It just makes BEEEP if the memory init goes wrong. People designed it this way on purpose. I know that there are

Excellent example.

You have a better overview than I - can you estimate how many of the platforms u-boot supports are "embedded system like", i.e. SoC cpu, soldered RAM & NAND/NOR flash, vs. "PC like", i.e. you-need-to-initi- alize-the-north-and-southbridge-first-before-you-get-access-to-ttyS0?

When I look at the ports we did so far (about 20 different hardware platforms), they all fall into the first category.

Now please answer: how many people do you know who can use a BIOS for board bringup, software development and product customization in even a remotely similar way as you can do with U-Boot?

How many engineers do you how like to use a BIOS?

We agree on the fact that it is a pretty good feature to have early debugging, even before anything else works. It's just that, at the moment, it has the implication that the whole inner mechanics of u-boot cannot follow a simple device model, as proposed by our v2 code.

Take the time and play with it; we may even want to do a telco during the next days and Sascha can show you some of the goodies. The longer one plays with the code, the more one gets the impression that it is simply plain elegant. It just makes POFF! and most of the spagetti code implodes into something which looks nice and natural. At least that was the impression we got here at Pengutronix when Sascha first showed the results of his experiments. It resolves so many of the same old problems which came over and over again during the last years.

It would be a pita if the whole design wouldn't work just because of this early printk issue. So I hope we find a solution anybody can live with.

...

If a hardware manufacturer does so, surely nobody will blame the u-boot provider for that. If somebody forgets to solder the flash chips onto his board, nobody expects u-boot to print out a proper warning as well :-)

Yes, I do. Or if a flash chip falls of, etc.

So let's hope it is not the flash chip containing u-boot, or the CPU itself :-)

...

I assume the way we do the discussion now is really right - we throw in "it can be soooooo easy" ideas, you tell us the corner cases and then we iterate until everybody is happy :-)

Define "corner case".

Use cases which obviously never happened here but seem to be common to you.

Robert

On Wed, Jul 04, 2007 at 09:36:55PM +0200, Wolfgang Denk wrote:

I wouldn't go as far as to say that. Maybe if the one-size-fits-all approach does not work (at least not without hurting), then there is still potential for a _compatible_ second approach? Who says the "first step" *must* be as small as 4 kB, and *must* be in a separately linked image, and *must* not link higher level functions from the "real" U-Boot? Maybe both is possible, so everybody can select the config he likes and be happy?

v2 was designed in a way to make exactly that choice possible, in a quite flexible way.

The thing is that there are many requirements which are pretty complicated and sometimes contradicting:

• systems booting from NAND or dataflash etc. may require a very small primary bootstrap loader
• systems with very limited resources may need a primary bootstrap loader that unpacks the compressed U-Boot image

Should be no problem with Sascha's design.

• dynamic switching of the console device may require early access to the device tree
• allowing for a configurable console baudrate or for software- adjustable CPU clock rates may require early access to the environment

These ones are problematic.

What I would like to acchieve is an open discussion where none of these requirements gets excluded just because it does not fit into the currently preferred design model. Until a few days ago we had only one code base to complain about. Now - thanks to Saschas excellent work - we have two different implementations which we can compare. This is an excellent chance to evaluate positions, to find out what's good in one design or the other, and what should be avoided.

That's the idea, yes.

If any feature is possible in the old design but leads to ugly code or other issues, we should not simply drop it, but instead discuss how it could be adapted for the other esign based on clean and beautiful (TM) code.

Yep, agreed. Please go ahead and make suggestions.

I agree with that. And as far as I remember the previous discussion, nobody ever raised any concerns or whatever.

Yes, we noticed. So either nobody read the code, or it must be really good :-)

Agreed. The printf() thingy is just a problem that needs a solution, it is not a killing point.

Could you elaborate on how these pluggable-ram boards are used in real life? For all of our boards it would surely be enough to have a compile time switch which declares one of the serial ports the early-debug console, plus hardcode a baudrate on it. That would be configurable, so somebody who wants to have it switched on in a production system has the choice, and someone who doesn't need it because a shipped board is never changing again could configure it off.

It is not the only one - as mentioned above, there are other things which I see difficult to implement in the new code,

Let's identify the problematic cases. At the moment I see these:

- pluggable memory -> should be fixable by more intelligent ram probing code

- debug-output-before-sdram

- debug-output-before-sdram-on-console-taken-from-$COMPLICATED_DEVICE

not to mention the huge effort that will be needed just to port a small fraction of the currently actively used boards. But it wouldn't be software if all was easy and just working ;-)

Well, that's easy. Everybody who wants to have his board supported in v2 just sends a patch. Everybody who doesn't care, does not, and it doesn't matter, because if he does not care, why should the community do the work instead? v1 would still be available for reference, if somebody decides later to go the v2 way.

Please note that what you seem to consider corner cases are real problems for some of our customers.

Well, I learned that one of the most important things in this business is to tell customers that if they do braindamaged decisions, it has implications. So if somebody designs a board with pluggable ram but without beeper, it could have the implication that one doesn't see anything. If a board can only initialize it's RAM without loading an FPGA from software, it's doomed anyway. My very personal decision is that there are projects out there who are so painful that it's probably better if somebody else does them, because I don't want to let my team feel the pain and I don't want to leave the customer with the bad feeling that we didn't do a high quality solution for him.

But I surely understand your argument.

Note that, if these special cases are really rare, there's also the possibility that, for features where there's no good solution, the people continue to use v1.

And I have seen more than enough casesmyself when a board stopped after printing "RAM: " (very often!) or "Flash: " (still quie frequently). Please blieve me that I don't want to discuss this to deat by raising artifical arguments. I am serious.

Sorry, our experience is different.

Ok, so let's stop the discussion here, I assume I've understood your arguments. Please let's continue with the "problematic cases" list above and try to find solutions.

Robert

On Thursday 05 July 2007, Ulf Samuelsson wrote:

Do we really want to have a common bootstrap source code base, or do we just define what the bootstrap needs to do before U-Boot is loaded into SDRAM?

From my experience, the first stage bootloader (bootstrap) can't be done platform independent. It will mostly consist of CPU-initialization and SDRAM-setup. And this is platform or even board dependent. We should describe what needs to be done in this bootstrap code, and perhaps come up with a general infrastructure on where this code should be located in the source tree.

Best regards, Stefan

===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

On Thursday 05 July 2007, Ulf Samuelsson wrote:

Do we really want to have a common bootstrap source code base, or do we just define what the bootstrap needs to do before U-Boot is loaded into SDRAM?

From my experience, the first stage bootloader (bootstrap) can't be done

platform independent. It will mostly consist of CPU-initialization and SDRAM-setup. And this is platform or even board dependent. We should describe what needs to be done in this bootstrap code, and perhaps come up with a general infrastructure on where this code should be located in the source tree.

==> CONFIG_BOOTSTRAP_DIR=bootstrap/atmel/at91-bootstrap make <parameters> -C $(CONFIG_BOOTSTRAP_DIR)

would work for me.

Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57

On Wednesday 04 July 2007, Sascha Hauer wrote:

...

...

I once wondered why it takes _so_ long to get a prompt on my MPC5200 board. The solution was simple: U-Boot was busy reading the environment from EEPROM several times.

Yes. That is one of the reasons, why it is strongly discouraged to use I2C EEPROM for environment storage.

I know it is, and it was the customers decision to so, but I think using an I2C eeprom _should_ be no problem. It's just like any other memory device.

ACK.

...

If no output on the serial console always means: "problem with memory", than this would be an easy indication for SDRAM problems. But I have seen lots of other errors, that lead to a hangup in the very early boot stage. Most of the time *before* SDRAM is initialized.

Don't have the boards where DIMMs can be changed some kind of beeper or LED telling you about memory problems?

Some have some don't.

...

Don't get me wrong. I generally like this 2 stage approach. For example it fits the NAND booting support (see nand_spl/*) where a small (4k on 4xx) first stage loader is needed. I'm just a little hesitant about dropping the full featured printf in early boot stages.

I think we have little choice if we want 4k boot block support, early console output _and_ a maintainable tree.

Yes. The current nand_spl implementation has no serial output at all. And when problems occurred (which has already happened and *not* in the SDRAM init process, just CPU setup which can be quite complicated and can not be deferred to after SDRAM init), I would have really liked this output. I once had a version with such a hardcoded serial output, but dropped it after everything was working. I should have kept it in the source via some "debug" functions.

Best regards, Stefan

===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================

In message 20070704122621.GM3361@leda.ptxnet.pengutronix.de you wrote:

Might be the case, but I can think of more cases where a user simply has a broken environment and won't see anything because of this. What does a user see when he configured a different baudrate but somehow his environment got scratched? #f32#f23##fwfdas#f32#d

He gets regular output at the default baudrate configured for this board.

I know it is, and it was the customers decision to so, but I think using an I2C eeprom _should_ be no problem. It's just like any other memory device.

It is no problem, it is just slow ;-)

Note that there are *real* problems with using I2C connected EEPROMs; see the doc/s.

I think we have little choice if we want 4k boot block support, early console output _and_ a maintainable tree.

Maybe there is a chance to provide both? So far, Stefan's NAND boot code managed to do pretty well in this respect.

Best regards,

Wolfgang Denk

In message 200707041356.32051.sr@denx.de you wrote:

I'm still a little undecided, if a "simple" output mechanism is enough. Of course you can life with a hardwired baudrate on most systems, so that you don't have to read the environment. But there will be some systems where the user configured a different baudrate and the outputs from the DDR2 init routine will not be readable.

But you are right: Making this step hardcoded makes the overall design much more simple. So that would be a "Good Thing" (TM).

This is a pretty important point. We've come a long way in U-Boot to make it such flexible and configurable - note: run-time configurable by the user. Many of us have too many times before been p*ssed off by some stupid loader which was hardwaired to 115 kbps when you just had an old terminal server or modem that maxed out at 38 kbps, etc. The flexibility that is built into current U-Boot may be one of the causes for it's complexity, but it is also a very strong point.

Instead of simply throwing such things over board I ask for constructive discussion how to adapt them to a new, better design.

Best regards,

Wolfgang Denk

Hi,

I followed the on-going discussion. Everyone seems to have lots of experiences and/or ideas for a cleaned up and shiny new U-Boot 2.0 release :-)

So the question is how we want to proceed.

I had a look on Saschas u-boot 2.0 draft - the new make and config system perfectly solves a lot of problems. I really like this frame work, and would support adoption of this framework as a basement for the 2.x tree. The custodian repository u-boot-v2 is still empty/unaccessible.

Maybe it could help to commit a stripped down version of your tree to this repository, so that we start to talk about the same thing?

Just a proper directory and konfig option tree - and everything stripped down to resetcode, relocator and C runtime setup. The relocated code should just print "Hallo world!" and loop forever. The only 'board' available would be the sandbox target, and (maybe) a generic target for each arch/cpu (Are there _simple_ boards suitable for such a reference in the 1.x tree?)

This gives a good starting point to * port (not just copy) arch/cpu reset and early init code from 1.x tree. * find out, what parts are common, and what needs to be configurable * compile and link code, and examine results. * write a working relocator for all targets and adapt GCC/bintuils to store relocation info or similiar in the binary. * start with a minimum set of kconfig options, which should whenever possible be shared between all architectures (where possible).

This helps to get rid of old code and other unwanted inheritages from 1.x tree. As the tree is empty we can talk about and decide on any issue (early debug output, complicated DRAM setups, ...) and fill in the code after such an common agreement.

The CONFIG defines for 2.x should follow a cannonical naming scheme. The corresponding CONFIG/CFG define in the 1.x tree should be renamed to match the new name.

This approach splits 'stage 1' of the bootloader apart from the common code available for all targets. It also gives us more time to develope a proper configuration tree for and to improve the internal APIs of the common code (e.g. improved _initcode scheme, common entry points, ...)

Most important: We should use the wiki to write down all these design considerations and requirements. So we can check the results of work above against a requirements list on the wiki.

In parallel people might start working with the sandbox target on a separate branch and just think about the common part (stage 2). These people won't care about stage 1 and just assume a working C environment and some configuration parameters provided by stage 1 (e.g. Address/Size of system memory an the relocated code & data segment. Or funktions provided by the board specific code).

Ok, just an proposal. But however we might continue - we are talking about a lot of work to get things clean and proper again. So it might be worth the effort to start from 'scratch' and focus all efforts on the 2.x branch.

I really like to contribute some work for this 2.x project. But I need a main-stream version as a reference for my patches first :-)

Regards Carsten

____________ Virus checked by G DATA AntiVirusKit Version: AVKA 17.260 from 03.07.2007

In message 20070704093242.GI3361@leda.ptxnet.pengutronix.de you wrote:

I don't understand what's so damn complicated about setting up SDRAM.

I could reply that I don't understand this either, but that would be simply arrogant. Just go back through the U-Boot mailing list archives for some time and you will see that 90% or more of the fundamental problems where U-Boot is not running at all, or where U-Boot or Linux are crashing randomly are caused by incorrectly initialized memory and/or memory controllers.

This is one of the most basic things during lowlevel development.

It may be basic, but it is still not trivial.

Usually this part is about 20 lines in my bdi config. Transfering this into some lines Assembler or C code is a piece of cake. If you have to

This depends highly on which sort of processor and memory controller you are dealing with. Correctly setting up the memory controller even on a CPU as old and simple as the MPC8xx is something I definitely don't want to do in assembler, and I bet you don't either if you tried.

read some i2c data to get initialization settings, you have to do some bits more and I understand that one wants to have some putc/puthex to check if sane values are read. But again, this is lowlevel work and once it's running can forget about this.

Again, I disgree. We have to support the whole lifetime of the product, from board bring-up through field service. It makes a huge difference whether a board simply sits there as a brick or whether you can see that it startedworking and stops at step N.

All this has _nothing_ to do with production boards. Here the SDRAM initialization and relocation just work. If not, you're doomed anyway.

They may work, or they may not work. Board break, chips die. Supporting the field service guys with useful diagnostics is important to me.

At the moment (PPC-)U-Boot does 90% of the whole initialization while running from Flash. All these serial read functions for the environment are just a pain. Do you really want to do the same thing for the device tree? Setting up things in SRAM and then copy them to SDRAM, possibly with relocation fixups is a pain. Setting up a preliminary environment in flash and relocate this complex thing afterwards with all this global_data handling is what I would call complicated and error prone.

So what is your suggestion when it comes to the request of being able to use exactly the same binary image of U-Boot on a set of differenty configured boards? OK, some things might be dealt with by probing, but there will always be situations where probing doesn't work. For example to find out if the attached LCD display is color or b/w, or if the orientation is landscape or portrait. We had a discussion about this on IRC before, and there was kind of a consensus that it makes sense to use the device tree for such run-time configuration.

Which solution do you suggest instead?

Doing this is not a design criteria, it is one main design flaw in U-Boot. If you insist on doing it, we don't need to talk about a redesign, just leave everything like it is.

Come on.

Note that in my tree there is one single entrypoint for all architectures, and the only thing needed to enter it is working RAM.

You have the big advantage of starting with a minimal set of similar boards in more or less trivial configuration. Things will become more difficult if you add more boards and support for more features.

This is straight forward: Everyone should be able to provide working RAM. If not, again you're doomed.

Agreed.

If you need some debugging output to get to that point, well that's fine, but these are putc/puthex and _not_ printf. They are not compiled in in production code and therefore do not need quiet console checking.

Please try to accept that this is not only debug output, and that early output if production systems is important.

Don't make things more complicated as they are. The earlier you enter a common entry point in U-Boot the more you can actually trust the code, since from there on it's common for _all_ architectures and the code will be best reviewed.

Agreed.

Best regards,

Wolfgang Denk

In message fa686aa40707030952v27a9ac98of1c5c1d33f3b9ae4@mail.gmail.com you wrote:

I actually think we should go a step farther. I think we should split u-boot into two linked images; a setup wrapper and u-boot proper (in the same way that the linux kernel is wrapped by a zImage wrapper). The sole purpose of the setup wrapper is to configure RAM and copy the u-boot proper image to location at the end of RAM. The u-boot proper image starts with the assembler routines to setup the C environment and fixup the relocation symbols before jumping into main.

I started with such a design in PPCBoot a long, long time ago. The problem is that memory setup is tricky, and you want to be able to use C to implement it, and you want to have debug output on the serial console as well. Which means you will have to include a *lot* of library functions in the "setup wrapper", which in some cases nearly doubles the flash memory footprint for U-Boot.

The goal should be to get into the u-boot wrapper C environment as soon as possible. The wrapper shouldn't do anything other than initialize RAM, copy code, and provide a little bit of debug output. As much as possible should be deferred to u-boot proper.

Yes, but "provide a little bit of debug output" means printf() and friends, plus console drivers, which in turn means reading the environment (for the console baudrate) and probably the device tree (for the hardware configuration of the console port), etc.

I see a few approaches to handle this:

1. eliminate console output from the wrapper. (by far the easiest,

but provides no clues when RAM configuration fails).

No, please don't. Don't!

2. cut down wrapper functionality in the wrapper (this is just early

boot after all). Eliminate printf() support in the wrapper and make

Remember that U-Boot is not only a tool needed by the end users, it's also a tool used by ourselfs in the board bring up. Don't make our own lifes even more miserable when you have to deal with the next green board.

due with puts(). Reduce the wrapper console driver to output only.

Puts() is not sufficient. I definitely want to be able to print register contents and the like.

Regardless of the approach, the choice of which to use can be made per-board, which is a suitable tradeoff between size and functionality. My gut feel is that for most boards, the boot wrapper will be very small, but I need to do some experiments to know for sure.

Assume something like a MPC8xx with console on SMC1 or SMC2, depending on that the device tree says...

Best regards,

Wolfgang Denk

Dear Sascha,

in message 20070703223156.GD8839@pengutronix.de you wrote:

...

Yes, but "provide a little bit of debug output" means printf() and friends, plus console drivers, which in turn means reading the environment (for the console baudrate) and probably the device tree (for the hardware configuration of the console port), etc.

I think you're talking about two different things here. The debug output

No, actually I'm not.

you want to see has nothing to do with the output in normal use. When bringing up a green board I would not ask the environment for the baudrate, because there is none.

You are right as far as dedicated debug output is concerned, which is normally not active or even present in the code of a release version. But please see my other messages: I still want to be able to *see* what's going on in my system and where it eventually might get stuck, including in the release versions of the code.

Thinking about this U-Boot already has this. Only the way it is done became very messy over the years. Not only this mailing list but also the code looks like a struggling between the people who want early debug output and the people who want to configure their console in the environment, possibly disabling it completely. People with multiple serial ports not to mention...

Please be aware that work is going on to make hardware features (including the console port) configurable at runtime by interpreting information passed in a device tree image. This is a requirement that makes things even more complicated here. And one that cannot be dropped easily as it solves a real problem for a couple of users.

The console thing is symptomatic for other cases in U-Boot aswell. This is why I think we need to start with a cleaner codebase where a driver or board support only enters after it works with a to be defined API.

Well, then we have to make sure that console driver can be entered very, very early. Ideally, it is the first thing U-Boot should do.

...

Assume something like a MPC8xx with console on SMC1 or SMC2, depending on that the device tree says...

Sounds like calling the president for turning on the lights. Please do

I'm not sure what you mean here.

not forget that there are also other people. None of our customers ever asked for a even configurable console. 115200 port0 seems to fit everyone. Instead we have to deal with Booting from small boot sectors.

I never said that U-Boot was a trivial thing, and I am very well aware that we have a wide range of requirements, which sometimes may even be conflicting.

We are discussing these things here so that you understand our requirements, as we understand yours. Then lets together find a solution which works for everybody.

Best regards,

Wolfgang Denk

Scott Wood wrote:

4. Include full console functionality in the wrapper, but only for debug

builds. A simple printf() really shouldn't be that big, anyway. This also eliminates the need to get console information from the environment, since you can hardcode it for debugging purposes.

IMHO for board bring up, the very first thing a bootloader should do is some pin toggling! (ideally there is a LED connected to a pin...) to see if the board at least comes out of reset and starts at our code. And then to put out a counter, every time some initialization was finished until a console is initialized.

I guess most of you came in contact with the Port 0x80 and beep POST codes: http://en.wikipedia.org/wiki/Power-on_self-test This would help all those without hardware debuggers connected to their board.

Best regards,

On 7/3/07, Sascha Hauer s.hauer@pengutronix.de wrote:

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

Yes, that's correct; but I think it makes the start.S fixups benign. It shouldn't be necessary to #ifdef around them because the GOT sections will be empty.

g.

On Wed, Jul 04, 2007 at 04:16:56PM +0200, Wolfgang Denk wrote:

Dear Sascha,

in message 20070702164755.GC3361@leda.ptxnet.pengutronix.de you wrote:

...

I just prepared a git repository for our U-Boot-NG proposal. Do a

git clone http://iocaste.extern.pengutronix.de/git/U-Boot-NG.git

...

...

The tree is based on vanilla U-Boot-1.2.0.

I would like to import your tree into a coresponding custodian repository, but this does not work, as "based on vanilla U-Boot-1.2.0" is not good enough. What we need is a tree that really branches off from some exactly know version. The root of your tree is definitely not U-Boot-1.2.0. Eventually something went wrong when exporting your SVN repository, as the first commit I can see in your git tree is this one:

Commit: 9b8460998f0f3a2dce296ba241eba221271a3244 Author: sha sha@9b15bb43-e3fe-45f6-9e9a-4a91e4a92388 Mon, 21 May 2007 13:26:02 +0000

git-svn-id: https://iocaste/svn/u2boot/u2boot-trunk@122 9b15bb43-e3fe-45f6-9e9a-4a91e4a92388

It seems this is already SVN commit # 122? And actually it looks as if the files in this commit are indeed already modified by you - they somewhat resemble the U-Boot-1.2.0 state, but already with some 250+ files changed...

I started on a vanilla 1.2.0. At commit #122 I had the bad idea to rename the repository to u2boot. I shouldn't have done it, because the git-svn tools do not track this rename properly. Let me have a look at this this evening.

Regards, Sascha

I can't reach the links in my network, what a pity, are they still valid?

2007/7/3, Sascha Hauer s.hauer@pengutronix.de:

Hi,

I just prepared a git repository for our U-Boot-NG proposal. Do a

git clone http://iocaste.extern.pengutronix.de/git/U-Boot-NG.git

(no native git support at the moment)

There is also a tarball snapshot available here:

http://pengutronix.de/software/ptxdist/temporary-src/U-Boot-NG-20070702.tar....

This is only a temporary place for the source, further development should probably either be done on Wolgangs server or some other dedicated server. The tree is based on vanilla U-Boot-1.2.0.

As a starting point I've included the README in this mail. It's also included in the source tree under README.u2. Further documentation can be found under Documentation/ and of course in the code ;)

Regards, Sascha Hauer

U2Boot

This is u2boot, our proposal for a next generation of the famous U-Boot bootloader. U-Boot offers an excellent choice as a bootloader for today's embedded systems, seen from a user's point of view. Nevertheless, there are quite some design flaws which turned out over the last years and we think that they cannot be solved in a production tree. So this tree tries to do several things right - without caring about losing support for old boards.

General features include:

• A posix based file API inside U-Boot the usual open/close/read/write/lseek functions are used. This makes it familiar to everyone who has programmed under unix systems.

• usual shell commands like ls/cd/mkdir/echo/cat,...

• The environment is not a variable store anymore, but a file store. It has currently some limitations, of course. The environment is not a real read/write filesystem, it is more like a tar archive, or even more like an ar archive, because it cannot handle directories. The saveenv command saves the files under a certain directory (by default /env) in persistent storage (by default /dev/env0). There is a counterpart called loadenv,

too.

• Real filesystem support The loader starts up with mounting a ramdisk on /. Then a devfs is mounted on /dev allowing the user (or shell commands) to access devices. Apart

from these two filesystems there is currently one filesystem ported: cramfs. One can mount it with the usual mount command.

• device/driver model Devices are no longer described by defines in the config file. Instead there are devices which can be registered in the board .c file or dynamically allocated. Drivers will match upon the devices automatically.

• clocksource support Timekeeping has been simplified by the use of the Linux clocksource API. Only one function is needed for a new board, no [gs]et_timer[masked]() or reset_timer[masked]() functions.

• Kconfig and Kernel build system Only targets which are really needed get recompiled. Parallel builds are no problem anymore. This also removes the need for many many ifdefs in the code.

• simulation target U-Boot can be compiled to run under Linux. While this is rather useless in real world this is a great debugging and development aid. New features can be easily developped and tested on long train journeys and started under gdb. There is a console driver for linux which emulates a serial device and a tap based ethernet driver. Linux files can be mapped to devices under U-Boot to emulate storage devices.

• device parameter support Each device can have a unlimited number of parameters. They can be

accessed on the command line with <devid>.<param>="...", for example 'eth0.ip=192.168.0.7' or 'echo $eth0.ip'

• initcalls hooks in the startup process can be archieved with *_initcall() directives in each file.

• getopt There is a small getopt implementation. Some commands got really complicated (both in code and in usage) due to the fact that U-Boot only allowed positional parameters.

• editor Scripts can be edited with a small editor. This editor has no features except the ones really needed: moving the cursor and typing characters.

Building U-Boot

U-Boot uses the Linux kernel's build system. It consists of two parts: the makefile infrastructure (kbuild), plus a configuration system (kconfig). So building U-Boot is very similar to building the Linux kernel.

For the examples below, we use the User Mode U-Boot implementation, which is a port of U-Boot to the Linux userspace. This makes it possible to test drive the code without having real hardware. So for this test scenario, ARCH=linux is the valid architecture selection. This currently only works on ia32 hosts and partly on x86-64.

Selection of the architecture and the cross compiler can be done in two ways. You can either specify it using the environment variables ARCH and CROSS_COMPILE, or you can create the soft links cross_arch and cross_compile pointing to your architecture and compiler. For ARCH=linux we do not need a cross compiler so it is sufficient to specify the architecture:

# ln -s linux cross_arch

In order to configure the various aspects of U-Boot, start the U-Boot configuration system:

# make menuconfig

This command starts a menu box and lets you select all the different options available for your architecture. Once the configuration was finished (you can simulate this by using the standard demo config file with 'make linux_defconfig'), there is a .config file in the toplevel directory of the sourcode.

Once U-Boot is configured, we can start the compilation

# make

If everything goes well, the result is a file called uboot:

# ls -l uboot -rwxr-xr-x 1 rsc ptx 114073 Jun 26 22:34 uboot

U-Boot usually needs an environment for storing the configuation data. You can generate an environment using the example environment contained in examples/environment:

# ./scripts/ubootenv -s examples/environment/ env.bin

To get some files to play with you can generate a cramfs image: # mkcramfs somedir/ cramfs.bin

The U-Boot image is a normal Linux executable, so it can be started just like every other program:

# ./uboot -e env.bin -i cramfs.bin

U-Boot 2.0.0-trunk (Jun 26 2007 - 22:34:38)

loading environment from /dev/env0 uboot> /

Specifying -[ie] <file> tells U-Boot to map the file as a device under /dev. Files given with '-e' will appear as /dev/env[n]. Files given with '-i' will appear as /dev/fd[n]. If U-Boot finds a valid configuration sector on /dev/env0 it will load it to /env. It then executes /env/init if it exists. If you have loaded the example environment U-Boot will show you a menu asking for your settings.

If you have started U-Boot as root you will find a new tap device on your host which you can configure using ifconfig. Once you configured U-Boots network settings accordingly you can do a ping or tftpboot.

If you have mapped a cramfs image try mounting it with

# mkdir /cram # mount /dev/fd0 cramfs /cram

Memory can be examined as usual using md/mw commands. They both understand the -f <file> option to tell the commands that they should work on the specified files instead of /dev/mem which holds the complete address space. Note that if you call 'md /dev/fd0' (without -f) U-Boot will segfault on the host, because it will interpret /dev/fd0 as a number.

Directory layout

Most of the directory layout is based upon the Linux Kernel:

arch/*/ -> contains architecture specific parts arch/*/mach-*/ -> SoC specific code

drivers/serial -> drivers drivers/net drivers/...

include/asm-* -> architecture specific includes include/asm-*/arch-* -> SoC specific includes

fs/ -> filesystem support and filesystem drivers

lib/ -> generic library functions (getopt, readline and the like)

common/ -> common stuff

commands/ -> many things previously in common/cmd_*, one command per file

net/ -> Networking stuff

scripts/ -> Kconfig system

Documentation/ ->

There is still the old directory layout in the tree which of course should be merged in one way or the other:

lib_*/ -> currently unused cpu/* -> currently unsused post/ -> untouched nand_spl/ -> untouched dtt/ -> untouched disk/ -> untouched documentation/ -> untouched

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

---

This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

Sascha Hauer wrote:

On Fri, Jul 06, 2007 at 02:39:29PM +0800, Songmao Tian wrote:

...

I can't reach the links in my network, what a pity, are they still valid?

Sorry, our DNS server is down. you can still get the repositories here:

git clone http://iocaste.penguin/git/U-Boot-NG.git git clone http://iocaste.penguin/git/U-Boot-NG-wdimport.git

The first one is the one originally posted, but outdated since it does not contain a clean starting point. The second one is the one likely to be moving to the custodian page soon.

Regards,

Sascha

---

This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

Thanks, but there's still some problem.

loongson@debian:~/project/u-boot/ng$ git clone http://iocaste.penguin/git/U-Boot-NG-wdimport.git Initialized empty Git repository in /home/loongson/project/u-boot/ng/U-Boot-NG-wdimport/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? loongson@debian:~/project/u-boot/ng$ git clone http://iocaste.penguin/git/U-Boot-NG.git Initialized empty Git repository in /home/loongson/project/u-boot/ng/U-Boot-NG/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there?

Tian

In message 468E3EF3.7030005@lemote.com you wrote:

...

git clone http://iocaste.penguin/git/U-Boot-NG.git git clone http://iocaste.penguin/git/U-Boot-NG-wdimport.git

...

Thanks, but there's still some problem.

Try ...penguin.de/ instead.

Best regards,

Wolfgang Denk