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

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

[Wolfgang Denk]

Dear Sascha,

Robert mentioned that you were working on a "U-Boot Next  Generation"
project,  and  that  you  were actually pretty far with this. He also
said that you were addressing a few issues where  discussions  and/or
actual   work  is  going  on,  like  using  some  configuration  tool
(Kconfig?) or creating a more generic device driver interface.

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.

Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I find this a nice feature but it is not according to  the  documen-
tation. Or is it a BUG?"   "Let's call it an accidental feature. :-)"
                       - Larry Wall in <6909@jpl-devvax.JPL.NASA.GOV>

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

[Robert Schwebel]

Hi Wolfgang,

On Fri, Jun 29, 2007 at 10:08:50PM -0400, Wolfgang Denk wrote:
> Robert mentioned that you were working on a "U-Boot Next  Generation"
> project,  and  that  you  were actually pretty far with this. He also
> said that you were addressing a few issues where  discussions  and/or
> actual   work  is  going  on,  like  using  some  configuration  tool
> (Kconfig?) or creating a more generic device driver interface.

Yes, that's right.

> 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
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.

The idea would be that u2boot is a technology playground for new u-boot
backend mechanics; existing board supports would have to be ported to
the new code base, to make sure the new code isn't cluttered by things
from the past. Nevertheless, u2boot is based on the u-boot code and
re-uses quite a lot of it. Think of it like "u-boot without the
problems".

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

- Kbuild makefiles, including parallel build support:

  rsc at octopus:~/work-octopus/svn/u2boot/u2boot-trunk> time make -j 16
  [...]
  GEN     .version
  LD      uboot
  objcopy -O binary uboot uboot.bin
  objdump -d uboot > uboot.S
  SYSMAP  System.map

  real    0m1.819s
  user    0m5.020s
  sys     0m1.664s

- Kconfig configuration system, stolen from Linux.

- Clean arch/{arm,powerpc,...} hardware abstraction, also stolen
  from linux.

- Driver model, also stolen from you-know-where, but much simpler
  because of the no-interrupts policy. All "things" live in devices and
  drivers, have an abstract concept of "properties". This makes it
  possible to throw away all that special cases for multiple devices,
  like ethaddr vs. eth1addr.

- File system concept: wanna access scripts? Put them into a filesystem. 
  As we are living on a very small environment, filesystems can be as
  simple as a linear list in memory, but they follow the driver model.

- Wanna edit your favourite script on the device? No problem, there is
  an integrated full screen editor.

- user-mode-uboot: you can build for arch/linux, resulting in a normal
  Linux binary which can be started on the command line, to test
  U-Boot's functionality. It can cope with tun/tap network devices,
  so it even can do things like tftp etc...

- Follows a "posix-god-where-is-the-difference" and
  "everything-is-a-file" politics. Wanna do scripting? No need to
  mis-use an environment for that. Do it the natural way - with scripts
  which live in a file system. Nevertheless, the concept of environment
  for parameters is still there, but in a more sophisticated way.

- Follows an "ifdefs-are-evil" politics; do things abstract and do them
  in centralized places.

Plus more goodies all over the place.

All that does already work; what we'll have to do before a first public
RFC on this list is to clean up the code (it is not obvious which part
of the code is old and which one is new), do some auditing for
non-operational commands, add some README and review the initial code
base for coding style.

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

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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

[Carsten Schlote]

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

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

[Wolfgang Denk]

Hi Robert & Sascha,

in message <20070630094023.GH25364@pengutronix.de> you wrote:
> 
> > 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.

> 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. But that cannot be changed any more.
But please do not delay this any further. There are lots of other
activities going on, including bigger structural changes (like making
U-Boot run-time configurable by using a device tree approach), so
let's cooperate to make sure things converge and don't drift apart
more and more.

>   rsc at octopus:~/work-octopus/svn/u2boot/u2boot-trunk> time make -j 16

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?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We want to create puppets that pull their own strings.   - Ann Marion

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

[Wolfgang Denk]

Dear Carsten,

in message <1183243336.3233.90.camel@loki> you wrote:
> 
> 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. 

THanks!

> 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.

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

> While doing these modification I found many 'problems' with the existing
> build system, which either need to be worked around (CFG_ style defines)

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.

> 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.

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)
...
#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
...
#define CFG_ENV_SECT_SIZE       0x20000 /* size of one complete sector          */
#define CFG_ENV_ADDR            ((-CFG_MONITOR_LEN)-CFG_ENV_SECT_SIZE)
#define CFG_ENV_SIZE            0x2000  /* Total Size of Environment Sector     */
...
#define CFG_ENV_ADDR_REDUND     (CFG_ENV_ADDR-CFG_ENV_SECT_SIZE)
#define CFG_ENV_SIZE_REDUND     (CFG_ENV_SIZE)

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

> 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.

That would be indeed appreciated.

> 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.

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I think animal testing is a terrible idea; they get all  nervous  and
give the wrong answers.

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

[Carsten Schlote]

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

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

[Sascha Hauer]

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

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

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

[Carsten Schlote]

Hi Sascha,

> 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 ;)

You only need to setup a public GIT repository somewhere, where you
store your branch. Everyone can pull it and have a look on it. So an
upload account shouldn't be required. There is a nice GIT Quickstart
Manual on the net explain how to setup things.

git-svn* tools are nice to synchronize changes and most important log
entries with your internal SVN repository. 

But for now I could life with a plain snapshot of your work available on
your public GIT repository. You can setup a proper branch with all your
subversion revisions transformed into git commits later :-) 

Don't let us wait :-)

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

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

[Sascha Hauer]

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.gz

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

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

[Jerry Van Baren]

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.gz
> 
> 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?

Thanks,
gvb

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

[Håvard Skinnemoen]

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

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

[Sascha Hauer]

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.gz
> > 
> > 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

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

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

[Sascha Hauer]

On Mon, Jul 02, 2007 at 08:25:35PM +0200, H?vard Skinnemoen wrote:
> 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 ;-)

I'm sure I broke enough things people need aswell ;)

> 
> $ 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...

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'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?

It's not really a new driver. It's still the old one, but I started to
split the AMD/Intel extensions apart from the driver and make them
independently configurable. I thought doing this would reduce binary
space, but that was not the case, so I stopped working on this.
I just left it there for reference.

Sascha

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

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

[Carsten Schlote]

Hi Sascha,

Am Montag, den 02.07.2007, 18:47 +0200 schrieb Sascha Hauer:
> git clone http://iocaste.extern.pengutronix.de/git/U-Boot-NG.git

Ich checkout and tried to compile the 'linux' arch. Everything is fine,
but ld 2.17 (debian etch) doesn't like your link script?

What version of GCC do you use?

Regards
  Carsten

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

[Sascha Hauer]

On Mon, Jul 02, 2007 at 09:02:51PM +0200, Carsten Schlote wrote:
> Hi Sascha,
> 
> Am Montag, den 02.07.2007, 18:47 +0200 schrieb Sascha Hauer:
> > git clone http://iocaste.extern.pengutronix.de/git/U-Boot-NG.git
> 
> Ich checkout and tried to compile the 'linux' arch. Everything is fine,
> but ld 2.17 (debian etch) doesn't like your link script?

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

gcc version is 4.1.2.
The linker script is a nearly unmodified linker script version from a
x86-64 ld. You can output the linker script the linker normally uses
with 'ld --verbose'. Maybe a diff between yours and the one used in
U-Boot can give some light?

The 64 bit version of the linker script mainly increases some
alignments and changes the link address to 0x400000.

Here's the diff to the original linker script I used:

--- lds.orig	2007-07-02 21:16:41.000000000 +0200
+++ u-boot.lds.S	2007-07-02 17:44:25.000000000 +0200
@@ -1,16 +1,9 @@
-GNU ld (GNU Binutils for Debian) 2.17.50.20070426
-  Supported emulations:
-   elf_x86_64
-   elf_i386
-   i386linux
-using internal linker script:
-==================================================
-/* Script for -z combreloc: combine and sort reloc sections */
-OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
-	      "elf64-x86-64")
-OUTPUT_ARCH(i386:x86-64)
+#include <asm-generic/u-boot.lds.h>
+
+OUTPUT_FORMAT(ELF_FORMAT)
+OUTPUT_ARCH(ELF_ARCH)
 ENTRY(_start)
-SEARCH_DIR("/usr/x86_64-linux-gnu/lib64"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/x86_64-linux-gnu/lib"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
+
 SECTIONS
 {
   /* Read-only sections, merged into text segment: */
@@ -76,6 +69,16 @@
   {
     KEEP (*(.fini))
   } =0x90909090
+
+  . = ALIGN(64);
+  __u_boot_initcalls_start = .;
+  __u_boot_initcalls : { INITCALLS }
+  __u_boot_initcalls_end = .;
+  . = ALIGN(64);
+  __u_boot_cmd_start = .;
+  __u_boot_cmd : { U_BOOT_CMDS }
+  __u_boot_cmd_end = .;
+
   PROVIDE (__etext = .);
   PROVIDE (_etext = .);
   PROVIDE (etext = .);
@@ -224,5 +227,3 @@
   /DISCARD/ : { *(.note.GNU-stack) }
 }
 
-
-==================================================

> 
> What version of GCC do you use?
> 
> Regards
>   Carsten
> 
> 

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

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

[Håvard Skinnemoen]

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

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

[Carsten Schlote]

Hi,

and just the first patch for NG :-) When I tried to compile the linux
sandbox, LD aborted with an error.

The cause is the use of CONSTANT( x ) in the linker script. This isn't a
built-in of LD, at least not for 2.17 on debian/etch. I grep-ed the
sources and found nothing, which handles the issue.

So I tweaked u-boot.lds.h a bit. Now it links and loads. I just guessed
some values for the pagesizes - no idea what value they should have. Did
you forget something to commit?

Regards
  Carsten


 include/asm-generic/u-boot.lds.h |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/linux/lib/u-boot.lds.S b/arch/linux/lib/u-boot.lds.S
diff --git a/include/asm-generic/u-boot.lds.h
b/include/asm-generic/u-boot.lds.h
index e8e9ce1..931074a 100644
--- a/include/asm-generic/u-boot.lds.h
+++ b/include/asm-generic/u-boot.lds.h
@@ -9,4 +9,8 @@
        *(.initcall.6)                  \
        *(.initcall.7)

+#define MAXPAGESIZE 0x10000
+#define COMMONPAGESIZE 4096
+#define CONSTANT( x ) x
+
 #define U_BOOT_CMDS    *(SORT_BY_NAME(.u_boot_cmd*))

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

[Carsten Schlote]

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.

Regards
  Carsten

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

[Sascha Hauer]

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

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

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

[Wolfgang Denk]

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?

> 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.

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

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Four thousand throats may be cut in one night by a running man.
	-- Klingon Soldier, "Day of the Dove", stardate unknown

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

[Sascha Hauer]

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

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

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

[Grant Likely]

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.

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.

Cheers.
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Wolfgang Denk]

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.

> > 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? 

> 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.

> 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If God had a beard, he'd be a UNIX programmer.

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

[Sascha Hauer]

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

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

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

[Sascha Hauer]

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

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

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

[Sascha Hauer]

On Mon, Jul 02, 2007 at 09:54:47PM +0200, Carsten Schlote wrote:
> Hi,
> 
> and just the first patch for NG :-) When I tried to compile the linux
> sandbox, LD aborted with an error.
> 
> The cause is the use of CONSTANT( x ) in the linker script. This isn't a
> built-in of LD, at least not for 2.17 on debian/etch. I grep-ed the
> sources and found nothing, which handles the issue.
> 
> So I tweaked u-boot.lds.h a bit. Now it links and loads. I just guessed
> some values for the pagesizes - no idea what value they should have. Did
> you forget something to commit?

No, the scripts work here, but I did not find where MAXPAGESIZE and
COMMONPAGESIZE are defined, they must come from the linker.

> 
> Regards
>   Carsten
> 
> 
>  include/asm-generic/u-boot.lds.h |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/linux/lib/u-boot.lds.S b/arch/linux/lib/u-boot.lds.S
> diff --git a/include/asm-generic/u-boot.lds.h
> b/include/asm-generic/u-boot.lds.h
> index e8e9ce1..931074a 100644
> --- a/include/asm-generic/u-boot.lds.h
> +++ b/include/asm-generic/u-boot.lds.h
> @@ -9,4 +9,8 @@
>         *(.initcall.6)                  \
>         *(.initcall.7)
> 
> +#define MAXPAGESIZE 0x10000
> +#define COMMONPAGESIZE 4096
> +#define CONSTANT( x ) x

Do you need to define MAXPAGESIZE and COMMONPAGESIZE aswell or only
CONSTANT? I would prefer hardcoding the values directly in the linker
script. They are needed only for the sandbox target, but u-boot.lds.h
is included for all architectures.

btw I just read your wiki and 'sandbox' really is the better name for
this target ;)

Regards,
  Sascha


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

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

[Carsten Schlote]

Hi Sascha,

> No, the scripts work here, but I did not find where 
> MAXPAGESIZE and COMMONPAGESIZE are defined, they must come 
> from the linker.

That was, what I meant. It's somewhere hacked into LD. 

> Do you need to define MAXPAGESIZE and COMMONPAGESIZE aswell 
> or only CONSTANT? I would prefer hardcoding the values 
> directly in the linker script. They are needed only for the 
> sandbox target, but u-boot.lds.h is included for all architectures.

So it is better to use the hard-coded values in the linker script. At
least as long as it takes for main-stream LD to support this fine
extension.

> btw I just read your wiki and 'sandbox' really is the better 
> name for this target ;)

A simulation sandbox with a real GDB and host OS is really some kind of
'must have' :-) Most high-level stuff can be developed with it, and just
the final tests need to be done on the target. And with some tweaking
the 'sanbox' target should compile and run on all POSIX platforms, not
just Linux. So calling it 'arch=linux' would be somehow limiting.

The relocation issue:

For the real targets U-Boot should be relocateable. Why? Simply because
I might want to run something else than Linux on a target. U-Boot
shouldn't occupy IRQ Vectors in RAM, nor should it be located in the
middle of available RAM - simply because my 'OS' might want to use it as
a single large block.

On most CPU architectures the IRQ/Except vectors can be placed into RAM
- most times at address 0 and up. Most operating systems also link and
load to the bootom of memory. The only place, which is rarely used by
other code, is the top of memory. That's why U-Boot should relocate to
this location whenever possible.

Regards
  Carsten




____________
Virus checked by G DATA AntiVirusKit
Version: AVKA 17.259 from 02.07.2007
____________
Virus checked by G DATA AntiVirus
Version: AVKB 17.285 from 03.07.2007
Virus news: www.antiviruslab.com

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

[Grant Likely]

On 7/3/07, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > 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.

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

> > 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.

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.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Grant Likely]

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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Ulf Samuelsson]

tis 2007-07-03 klockan 10:52 -0600 skrev Grant Likely:
> 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.


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.
-- 
Best Regards,
Ulf Samuelsson

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

[Sascha Hauer]

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

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

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

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

Regards
   Sascha

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

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

[Sascha Hauer]

On Tue, Jul 03, 2007 at 10:52:23AM -0600, Grant Likely wrote:
> 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.

I think for most cases this is not needed. As long as you do not use
static pointers C code should run anywhere in address  space. Currently
I do this on the mpc5200 board. U-Boot is linked to 0x1000000, but can
be started from anywhere in RAM.

> 
> 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.

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.

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

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

[Grant Likely]

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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Grant Likely]

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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Grant Likely]

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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Rune Torgersen]

> -----Original Message-----
> From: Grant Likely
> > 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.

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.

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

[Grant Likely]

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.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Rune Torgersen]

> -----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.

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

MPC8260 Reset Status: External Soft, External Hard

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

CPU:   MPC8280 (HiP7 Rev 14, Mask 1.0 1K49M) at 447.897 MHz
Board: Innovative Systems AP2, CPU1
Build: $SvnTreeRevision: 89 $
       Watchdog enabled
UPMs:  Configured
FPGA:  (cfgaddr 0xff810000)............ Status = OK Altera ID: 0x110b
I2C:   ready
DRAM:  DIMM socket probe: Slot1 = 1, Slot2 =1
        SDRAM configuration read from SPD
        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
!!! Skipping Memtest (SkipMemtest env varable set) !!!
Now running in RAM - U-Boot at: 0ff97000
FLASH:  8 MB
PCI:    Scanning...
        00  11  1095  3124  0180  00
        01  00  104c  b000  0000  00
        01  01  104c  b000  0000  00
        01  02  104c  b000  0000  00
        01  03  104c  b000  0000  00
        00  12  104c  ac28  0604  00
IDE controller @ 0x00000000
In:    serial
Out:   serial
Err:   serial
Initializing system supervisor... OK
Initializing Ethernet switch
Device: 0x0d15, revision 1

Ethernet switch initialized
Board revision:  2.0 (02)
Net:   FCC2 ETHERNET, FCC3 ETHERNET [PRIME]
Hit any key to stop autoboot:  0

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

[Sascha Hauer]

On Tue, Jul 03, 2007 at 01:09:36PM -0500, Rune Torgersen wrote:
> > -----Original Message-----
> > From: Grant Likely
> > > 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.
> 
> 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.

Perhaps because the comment before board_init_f() does not tell the
truth:

 *
 * The main purpose is to provide a (serial) console interface as
 * soon as possible (so we can see any error messages), and to
 * initialize the RAM so that we can relocate the monitor code to
 * RAM.

In fact 90% of the init process happen here. This function does not even
exist in my approach.

Regards
   Sascha


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

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

[Grant Likely]

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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Rune Torgersen]

> 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).

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

[Jerry Van Baren]

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

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

[Grant Likely]

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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Rune Torgersen]

> 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.

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

[Grant Likely]

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, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Rune Torgersen]

> -----Original Message-----
> From: Grant Likely
> 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.
> Okay, good.

I don't remember if netconsole can be used before RAM relocation....
That could necessitate initializing quite a bit of stuff to make
work.... (ethernet interface, any onboard ethernet switches etc...,
environment...)

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

[Wolfgang Grandegger]

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.

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The moral of the story is: "Don't stop to  tighten  your  shoe  laces
during the Olympics 100m finals".
                             - Kevin Jones in <DEJo68.K1t@bri.hp.com>

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Der Irrtum wiederholt sich immerfort in der Tat.  Deshalb mu? man das
Wahre unerm?dlich in Worten wiederholen.                     - Goethe

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The question of whether a computer can think is no more  interesting
than the question of whether a submarine can swim"
                                                - Edsgar W.  Dijkstra

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Killing is wrong.
	-- Losira, "That Which Survives", stardate unknown

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

[Wolfgang Denk]

In message <468AA145.8090404@smiths-aerospace.com> you wrote:
>
> 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.

This is definitely useful for debugging. We often do similar  things;
like  ust  writing  characters  or  a  counter  to some static memory
location for post mortem analysis with a debugger.

> > 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.

I consider it very useful.  We  had  several  cases  where  customers
reported  on  strange problems, and by just checking the printed data
we wre able to see that they either used a wrong board  configuration
for U-Boot, or that the syctem clock was off, or ...

> * 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

No, it cannot, because then you might never  see  these  messages  at
all.

> > 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

NO! Please, please DON'T!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"He only drinks when he gets depressed." "Why does he get depressed?"
"Sometimes it's because he hasn't had a drink."
                                     - Terry Pratchett, _Men at Arms_

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A conservative is a man with two perfectly good legs  who  has  never
learned to walk.                              - Franklin D. Roosevelt

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

[Wolfgang Denk]

In message <468AAA8E.8000601@grandegger.com> you wrote:
>
> Initialization of some devices could even be deferred until they are 
> really used like PCMCIA/IDE or DTT.

This should indeed be a general goal for a redesign.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are three principal ways to lose money: wine, women, and engi-
neers. While the first two are more pleasant, the third is by far the
more certain."                           - Baron Rothschild, ca. 1800

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

[Sascha Hauer]

On Tue, Jul 03, 2007 at 10:48:06PM +0200, Wolfgang Denk wrote:
> 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 think you're talking about two different things here. The debug output
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.
We should create two entries to the console. One regular, with asking the
environment about baudrate and the like. The other one as simple as
possible. In this case I really only want to pass a base address and a
hardcoded baudrate.

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...
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.

> 
> > 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.

Add a Puthex(), then we're complete.

> 
> > 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...

Sounds like calling the president for turning on the lights. Please do
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.

Regards,
  Sascha

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

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is is no reason for any individual to have a computer in  their
home.      -- Ken Olsen (President of Digital Equipment Corporation),
              Convention of the World Future Society, in Boston, 1977

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are three principal ways to lose money: wine, women,  and  en-
gineers.  While  the first two are more pleasant, the third is by far
the more certain."                      -- Baron Rothschild, ca. 1800

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

[Grant Likely]

On 7/3/07, Wolfgang Denk <wd@denx.de> wrote:
> 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.

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?

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

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Scott Wood]

On Tue, Jul 03, 2007 at 10:52:23AM -0600, Grant Likely 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.

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.

5. Export common code as a jump table for the second-stage code to call.

The three main advantages I can see with a two-stage approach are:

1. Devices with very small flash could ditch the second-stage u-boot
altogether and put something custom there.

2. Changes to code in the second-stage could be tested without needing to
use JTAG to reflash if it doesn't work, by using some software-readable
switch (or possibly warm-boot v. cold-boot) to tell the wrapper which
stage-2 to use.  I've seen several boards that have software switches but
no alternate-boot-location switch.

3. It enforces a certain amount of clean separation between the two
components, making it easier to alter the stage-2 layer.  For example,
stage-2 may be much easier to port to a new board than stage-1, and thus
it'd be easier to get improvements to things like device-tree handling on
a board that has been unmaintained for a while.

-Scott

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A mouse is an elephant built by the Japanese.

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

[Andrew Dyer]

A few comments -

I very much like the separation of first and second stage and
relocation of u-boot.  The idea of 'get to ram first' makes a lot of
sense to me.

For the first stage loader, it seems like a printf is overkill.  If I
can print strings, 32-bit hex numbers and maybe decimals that should
be enough.

One of the things I like about eCos/RedBoot is the way they divide up
code into architecture, variant, and platform.  I think u-boot would
benefit from making these distinctions clearer.

In eCos they allow the variant to override the architecture and the
platform can override either variant or architecture.  The thing I
hate about eCos is the configtool and preprocessor nightmare they use
to achieve this.  It sounds like we could achieve similar things with
weak functions.

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 :-)

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'.

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


-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

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

[Grant Likely]

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.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Robert Schwebel]

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?

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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

[Sascha Hauer]

On Tue, Jul 03, 2007 at 10:55:36PM +0200, Wolfgang Denk wrote:
> 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.

I don't understand what's so damn complicated about setting up SDRAM.
This is one of the most basic things during lowlevel development.
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
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.
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.
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.

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.

Regards,
  Sascha


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

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

[Clemens Koller]

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,
-- 
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra?e 45/1
Linhof Werksgel?nde
D-81379 M?nchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Sascha Hauer]

On Wed, Jul 04, 2007 at 12:06:18PM +0200, Stefan Roese wrote:
> 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). 

I just did. The information this file outputs can easily be transfered
to puts/puthex. 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 ;) 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. Even netconsole was already mentioned somewhere. This can
simply not be implemented on other architectures than powerpc because of
the lack of SRAM.

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. 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.
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).


> 
> > 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.

Ack

> 
> > 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 at denx.de
> =====================================================================
> 

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

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

[Sascha Hauer]

On Wed, Jul 04, 2007 at 01:13:03AM +0200, Wolfgang Denk wrote:
> 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).

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.

Regards,
  Sascha

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

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Sascha Hauer]

On Wed, Jul 04, 2007 at 01:53:17PM +0200, Stefan Roese wrote:
> 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. ;-)

You must be using the same model as I do ;)

Regards,
  Sascha

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

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

[Robert Schwebel]

On Wed, Jul 04, 2007 at 01:56:31PM +0200, Stefan Roese wrote:
> 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.

Not easy, but early :-)

> 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.

> 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. :-(

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
:-)

> 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.

> 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 :-)

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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

[Sascha Hauer]

On Wed, Jul 04, 2007 at 01:56:31PM +0200, Stefan Roese wrote:
> 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.

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

> 
> 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.

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.

> 
> 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?

> 
> 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.

Regards,
  Sascha

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

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

[Stefan Roese]

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 at denx.de
=====================================================================

[U-Boot-Users] U-Boot 2.0 - How to proceed...? (was RE: U-Boot-NG ?)

[Carsten Schlote]

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

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Carsten Schlote]

Hi,

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

Yes. I fully agree.

So my opinion:

Stage 1:
* I can live with hardcoded, fixed-baud puts() and puthex() in stage 1. 
  It's normally disabled, and for production code I would prefer
LED/Buzzer
  feedback. (Dear customer, can you tell me how many times the LED is
blinking?)
* board specific code (BSC) could supply code to use beepers or LEDs to
  report on early errors. (No customer has terminals connected... Or has
no
  glue how to do so...)
* Move everything except of resetinit, relocator and C stack setup to
stage 2.
  C stack setup might require DRAM setup || use of CACHE/SRAM memory.
* Provide some way to provide BSC to be inserted at defined points in
the
  stage 1 code. So you can do additional setups required for some
boards.
  (e.g. FPGA stuff if required for DRAM setup)

Stage 2:
* Complete the C stack setup (move from CACHE/SRAM to real RAM) if
needed.
* Setup the real serial driver 
* ... tbd ... 

Regards
  Carsten



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

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Due to lack of disk space, this fortune database has been discontinued.

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

[Wolfgang Denk]

In message <fa686aa40707032234q1ab88d31le2598fe281aadeb9@mail.gmail.com> you wrote:
>
> > 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'.

We are working on this.  Some parts of this are visible on our web
site - see http://www.denx.de/wiki/DUTS/DUTSDocs and 
http://www.denx.de/cgi-bin/gitweb.cgi?p=duts.git;a=summary

> 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)

Again, we are woking on this. Yes, we don't have access to all boards
either, but some 80+ or so, number growing...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There are three principal ways to lose money: wine, women,  and  en-
gineers.  While  the first two are more pleasant, the third is by far
the more certain."                      -- Baron Rothschild, ca. 1800

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I used to think that the brain was the most wonderful  organ  in  my
body. Then I realized who was telling me this."        - Emo Phillips

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

[Wolfgang Denk]

In message <20070704114659.GK3361@leda.ptxnet.pengutronix.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.

No, you don't. That problem should be fixed where it happens. i. e. in
the Linux drivers. See the FAQ.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
                  Nail here --X-- for new monitor.

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I don't document something, it's usually either for a good reason,
or a bad reason.  In this case it's a good reason.  :-)
                 - Larry Wall in <1992Jan17.005405.16806@netlabs.com>

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Out of register space (ugh)"
- vi

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

[Wolfgang Denk]

In message <20070704122101.GO25364@pengutronix.de> you 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.

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?

> 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.

It's trivial to provide such a basic diagnostic mode built in, so why
drop it?

> 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".

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One essential to success is that you desire be an all-obsessing  one,
your thoughts and aims be co-ordinated, and your energy be concentra-
ted and applied without letup.

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There is nothing new under the sun, but there are lots of old things
we don't know yet."                                  - Ambrose Bierce

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

[Sascha Hauer]

On Wed, Jul 04, 2007 at 03:34:45PM +0200, Wolfgang Denk wrote:
> 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.

Ack

> 
> > 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?

Well, after passing the common entry point you are free to do what you
want. You can read the device tree then, register devices according to
it, whatever. Before passing this entry point you cannot. It's not
portable. 

> 
> 
> > 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.

I know that things will get more difficult. This is a reason more why
should strictly draw a line between a stage 1 (no sdram, no printf, no
environment) and a fully sophisticated stage 2.

> 
> > 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.

I do. How about this?
Specify _one_ early console. hardcoded port, hardcoded baudrate. This is
used for early output and - if requested - for debugging purposes. Delay
all the rest after passing the common entry point.
There is only one thing we had to tell customers: Either you want early
console in which case you cannot connect a modem/other fancy device to
this port, or you do not want early console, in which case you are blind
when the board does not start.

Regards,
  Sascha

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

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

[Wolfgang Denk]

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 at 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...


Can you please check and  eventually  re-export  the  *complete*  SVN
history of changes?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
    \|/ ____ \|/                                     \|/ ____ \|/
     @~/ ,. \~@                                       @~/ ,. \~@
    /_( \__/ )_\                                     /_( \__/ )_\
       \__U_/                                           \__U_/

[U-Boot-Users] U-Boot 2.0 - How to proceed...? (was RE: U-Boot-NG ?)

[Wolfgang Denk]

In message <46597312D56D2A47A3A6E9C1D0D9B7AEB0C508@kpladc0001.konzeptpark.intra> you wrote:
> 
> 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? 

I tried to do this, but failed, as Sascha's tree  seems  to  branched
off somewhere in the middle.

> 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 :-) 

Sure. I do what I can, but I need Sascha's help first.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In theory, there is no difference between  theory  and  practice.  In
practice, however, there is.

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

[Stefan Roese]

On Wednesday 04 July 2007, Wolfgang Denk wrote:
> > 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.

This is a bad example. The 4k NAND bootloader (in nand_spl/*) doesn't do any 
serial output at all. It's really like the here described first stage 
bootloader. Just setup the CPU as much as needed, setup the SDRAM (in a 
limited way - you can't support this I2C SPD probing in the 4k) and load 
the "real" U-Boot from NAND into SDRAM and start it. The first serial output 
is from the "real" U-Boot and not from the NAND loader.

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 at denx.de
=====================================================================

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

[Sascha Hauer]

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 at 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


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

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

[Wolfgang Denk]

Dear Sascha,

in message <20070704144328.GO3361@leda.ptxnet.pengutronix.de> you wrote:
> 
> 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.

Yes, SVN is a PITA. There is a reason they invented git ;-)

If everything else fails, it would be sufficient if you could provide
this early part of the history in a separate repo; I  guess  I  might
have  to  go through the pain of format-patch/apply-patch anyway; I'm
not sure if git will really detect the common ancestor.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Memories of you remind me of you.                   - Karl Lehenbauer

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

[Grant Likely]

On 7/4/07, Robert Schwebel <r.schwebel@pengutronix.de> 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?

Not all boards have a fixed amount of RAM.  Some boards have a DIMM
slot, and some boards have variants with differing RAM sizes.  U-boot
is designed to always exist at the end of available RAM, so with those
boards u-boot calculates where the end of ram is, relocates itself
there and fixes up the pointer references to point to the new
location.  To do this, u-boot must be compiled as position independent
code (-fPIC) and with with relocation tables.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Grant Likely]

On 7/4/07, Stefan Roese <sr@denx.de> wrote:
> 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.

Then let's defer that discussion.  I'd like to drop printf; but there
are some pretty light printf implementations out there.  Or, we could
easily use a cutdown printf which only supports %i and %x if need be.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Grant Likely]

On 7/4/07, Wolfgang Denk <wd@denx.de> wrote:
> 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 ;-)

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

g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

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

[Andrew Dyer]

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.

-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

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

[Robert Schwebel]

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 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.

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

[Wolfgang Denk]

Dear Robert,

in message <20070704184312.GI25364@pengutronix.de> you wrote:
>
> 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?

In terms of board configurations most of them are "embedded" type. In
terms vof number of shipping systems the embedded ones outnumber  the
others by a really, really huge factor.

> 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.

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?

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
- 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
etc. etc.

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.

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.


> 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

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

> 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.

Agreed. The printf() thingy is just a problem that needs a  solution,
it  is  not  a  killing  point. It is not the only one - as mentioned
above, there are other things which I see difficult to  implement  in
the new code, 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 ;-)

> > Define "corner case".
> 
> Use cases which obviously never happened here but seem to be common to
> you. 

Please note that what you seem to  consider  corner  cases  are  real
problems  for some of our customers. 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Veni, Vidi, VISA:
        I came, I saw, I did a little shopping.

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

[Robert Schwebel]

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
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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

[Ulf Samuelsson]

> in message <20070704184312.GI25364@pengutronix.de> you wrote:
>>
[snip]
> 
>> 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.
> 
> 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?
> 
> 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
> - 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
> etc. etc.
> 


Size can be one of the more important parameters.
The AT91SAM9260 BootROM loads the bootstrap into internal SRAM,
and this is limited to 4 kB.

If I look through the code, I see that this contains a lot of AT91 specific
stuff, and not so much generic stuff.

The bootstrap should avoid loading a non working image.
In the AT91 bootstrap the exception vector table is disassembled
and only if 7 out of 8 vectors contain branch/jump instructions,
is the image considered valid.

This is not going to work on a non-arm target.

Personally I do not see a need to reconfigure the BAUD rate for AT91 at least.
The bootrom will set the BAUD rate to 115,200 and you will not be able
to program the device over the serial port if you do not support this baud rate
in your host. If you do, there is no reason not to use 1152000.

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?


Best Regards
Ulf Samuelsson

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

[Stefan Roese]

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 at denx.de
=====================================================================

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

[Robert Schwebel]

On Thu, Jul 05, 2007 at 08:04:21AM +0200, Stefan Roese wrote:
> 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.

This is basically the old minimum vs. maximum approach discussion;
u-boot always followed a maximum approach, i.e. have a sophisticated
bootloader which can do a lot of things, whereas other bootloaders
always only initialized cpu+memory and gave the control over to linux.

What v2 tries to do is to separate u-boot internally into a minimum
first stage plus a driver model based second stage.

So regarding Ulf's comments: yes, the initialization is platform
dependend and will always be. But we are not talking about platform
dependend vs. independend here, but about sane abstractions. With the
abstractions done right, it doesn't matter if one platform has special
needs, because it is independend of other things.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

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

[Ulf Samuelsson]

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 at 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

[U-Boot-Users] 回复: [U-Boot-Users] U-Boot-NG ?

[Songmao Tian]

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.gz
>
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

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

[Sascha Hauer]

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

[U-Boot-Users] 回复: [U-Boot-Users] U-Boot-NG ?

[Songmao Tian]

what's the trick to use d-cache as memory?

2007/7/3, Wolfgang Denk <wd@denx.de>:
> 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.
>
> > > 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?
>
> > 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.
>
> > 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.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> If God had a beard, he'd be a UNIX programmer.
>
> -------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>

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

[Songmao Tian]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
>   
Thanks, but there's still some problem.

loongson at 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 at 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

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

[Sascha Hauer]

On Fri, Jul 06, 2007 at 09:09:07PM +0800, Songmao Tian wrote:
> 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 at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/u-boot-users
> >
> >
> >   
> Thanks, but there's still some problem.
> 
> loongson at 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 at 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?
> 

Hm, quite nonsaying error message for "could not resolve host". The
tld is missing, the correct servername is iocaste.penguin.de

Sascha

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every revolutionary idea - in science, politics, art, or  whatever  -
evokes three stages of reaction in a hearer:
  1. It is completely impossible - don't waste my time.
  2. It is possible, but it is not worth doing.
  3. I said it was a good idea all along.

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

[Songmao Tian]

Wolfgang Denk wrote:
> 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
>
>   
cloning:)

fun, fun, fun...u-boot community is much more active. I am excited and 
can't wait to see u-boot 2.0:)

Tian