[U-Boot-Users] lkc support for U-Boot My $0.02 worth

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] lkc support for U-Boot My $0.02 worth

Rod Boyce
All,

I know progress is a thing that cannot be stopped and change is sometimes
positive.  But my preference is that we stick with the make file
configuration approach.  It is small easy to add new configurations of
either boards or CPUs.  What is more when starting out it is easy to follow
what is going on with a make file I maybe an old dog who doesn't like change
but...

                                if it isn't broken why fix it?


Regards,
Rod Boyce



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] lkc support for U-Boot My $0.02 worth

Wolfgang Denk
In message <8D7C5F56B409554D9D46AC22195807F3061B3B at exchwenz01.dmcwave.co.nz> you wrote:
>
> I know progress is a thing that cannot be stopped and change is sometimes
> positive.  But my preference is that we stick with the make file
> configuration approach.  It is small easy to add new configurations of
> either boards or CPUs.  What is more when starting out it is easy to follow
> what is going on with a make file I maybe an old dog who doesn't like change
> but...
>
> if it isn't broken why fix it?

Because U-Boot claims to be easily portable. And I can understand the
argument that a configuration menu that guides you  through  all  the
questions might be useful.

One of my definitive requiterementes is that  the  Makefile  approach
must  not  change  significantly;  only  the  way  how we get a board
specific config header file will change.


Well, I don;t need such a change  for  myself  -  I'm  probably  much
faster  to  clone an existent port - we've done enough of them that I
will always find one close enough :-) But this does not mean I should
reject new ideas.

I still see technical issues; for example, I have not  the  slightest
idea how longish definitions like:

#define CONFIG_EXTRA_ENV_SETTINGS                                               \
        "kernel_addr=40040000\0"                                                \
        "ramdisk_addr=40100000\0"                                               \
        "magic_keys=#3\0"                                                       \
        "key_magic#=28\0"                                                       \
        "key_cmd#=setenv addfb setenv bootargs \\$(bootargs) console=tty0\0"    \
        "key_magic3=24\0"                                                       \
        "key_cmd3=echo *** Entering Test Mode ***;" \
                "setenv add_misc setenv bootargs \\$(bootargs) testmode\0"      \
        "nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath)\0"
\
        "ramargs=setenv bootargs root=/dev/ram rw\0"                            \
        "addfb=setenv bootargs $(bootargs) console=ttyS1,$(baudrate)\0"         \
        "addip=setenv bootargs $(bootargs) "                                    \
                "ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname)::off "
\
                "panic=1\0"                                                     \
        "add_wdt=setenv bootargs $(bootargs) $(wdt_args)\0"                     \
        "flash_nfs=run nfsargs addip add_wdt addfb;"            \
                "bootm $(kernel_addr)\0"                                        \
        "flash_self=run ramargs addip add_wdt addfb;"           \
                "bootm $(kernel_addr) $(ramdisk_addr)\0"                        \
        "net_nfs=tftp 100000 /tftpboot/pImage.lwmon;"           \
                "run nfsargs addip add_wdt addfb;bootm\0"       \
        "rootpath=/opt/eldk/ppc_8xx\0"                                          \
        "load=tftp 100000 /tftpboot/u-boot.bin\0"                               \
        "update=protect off 1:0;era 1:0;cp.b 100000 40000000 $(filesize)\0"     \
        "wdt_args=wdt_8xx=off\0"                                                \
        "verify=no"


can be handled in a readable way, if at all. Things like that.  Also,
I  fear  that  adding new features will become much harder, as you'll
have to continually extend  the  config  setup.  And  finally  -  has
anybody  benchmarked the speed of such a new config scheme? Running a
MAKEALL over all PPC and ARM boards takes a considerable time already
now. I don't really want to add to build time...

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
See us @ electronica 2002 in Munich, Nov 12-15, Hall A3, Booth A3.325



Reply | Threaded
Open this post in threaded view
|

[U-Boot-Users] lkc support for U-Boot My $0.02 worth

Holger Schurig
> I still see technical issues; for example, I have not  the  slightest
> idea how longish definitions like:

Not at all. However, I have the feeling that they are not that common. Only
some board has this here and then.


But those long stuff could stay in the *.h file, if needed.

config EXTRA_ENV_SETTINGS
   char "kernel environment settings"
   depends !SPECIAL_BOARD

and in include/config/special_board.h

#undef CONFIG_EXTRA_ENV_SETTINGS
#define CONFIG_EXTRA_ENV_SETTINGS \
  "ten " \
  "thousand " \
  "lines"


> Also,
> I  fear  that  adding new features will become much harder, as you'll
> have to continually extend  the  config  setup.

For me it looks EASIER. A complete description of what is configurable is in
the config.in files. Right now, I have to do things like

grep '^#if' `find -name '*.c'` | sort | unique

to find out what is actually configurable. And then it's only slightly
documented, and dependencies are not laid out clearly.



> And  finally  -  has
> anybody  benchmarked the speed of such a new config scheme?

I doubt there is much difference...   once you've run make
config|xconfig|oldconfig|menuconfig, you have to files. One is includeable by
"Makefile"s, the other one into C programs.

You simply include this and that's it. I can't see why this should slowdown
the compilation process.

One thing that might be a little time difference is the

cp board/<boardname>/def-configs .config
make oldconfig.

However, running "make oldconfig" on the current Bitkeeper tree of
www.openzaurus.org is negligible:

/usr/src/buildroot-oz# touch packages/config.in
/usr/src/buildroot-oz# touch .config
/usr/src/buildroot-oz# times make oldconfig
0.22user 0.09system 0:00.32elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (5351major+2500minor)pagefaults 0swaps

But then again the combined length of all config.in of this project is only
754 lines with now only 202 configurable variables (I have an 850 MHz AMD
with 1967 bogomips and the hard disk cache was "warm").


Greetings, Holger