[U-Boot-Users] Compressed U-Boot image

[U-Boot-Users] Compressed U-Boot image

[Terry Barnaby]

Hi,

The u-boot image is quite large.
Has anyone done any working in getting a compressed u-boot image to boot
ala the Linux kernel ?

Cheers

Terry
-- 
Dr Terry Barnaby                     BEAM Ltd
Phone: +44 1454 324512               Northavon Business Center, Dean Rd
Fax:   +44 1454 313172               Yate, Bristol, BS37 5NH, UK
Email: terry at beam.ltd.uk             Web: www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
                       "Tandems are twice the fun !"

[U-Boot-Users] Compressed U-Boot image

[Terry Barnaby]

Hi,

The u-boot image is quite large.
Has anyone done any working in getting a compressed u-boot image to boot
ala the Linux kernel ?

Cheers

Terry
-- 
Dr Terry Barnaby                     BEAM Ltd
Phone: +44 1454 324512               Northavon Business Center, Dean Rd
Fax:   +44 1454 313172               Yate, Bristol, BS37 5NH, UK
Email: terry at beam.ltd.uk             Web: www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
                       "Tandems are twice the fun !"

[U-Boot-Users] Compressed U-Boot image

[Wolfgang Denk]

In message <4188F7C5.6010303@beam.ltd.uk> you wrote:
> 
> The u-boot image is quite large.

120...240 kB is no much for a boot loader with the capabilities of U-Boot.

> Has anyone done any working in getting a compressed u-boot image to boot
> ala the Linux kernel ?

Some people did (like for the AT91RM9200), but it makes little sense,
unless you abandon very basic design principles, like doing  as  much
as  possible in standard C code, providing console output as early as
possible, making ports to new CPUs and boards as  easy  as  possible,
etc.

On the AT91RM9200 we're right now in the process of getting od of the
binary boot loader that loads a compressed U-Boot image: it's a  PITA
to  have  yet  another  piece  of  software  that needs to be ported,
debugged and maintained, and that does nothing  but  adding  lots  of
delays to the boot time.


While technically possible (and not exactly difficult)  it  makes  no
sense to me to implement such a feature.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Power is danger.
	-- The Centurion, "Balance of Terror", stardate 1709.2

[U-Boot-Users] Compressed U-Boot image

[Terry Barnaby]

Wolfgang Denk wrote:
> In message <4188F7C5.6010303@beam.ltd.uk> you wrote:
> 
>>The u-boot image is quite large.
> 
> 
> 120...240 kB is no much for a boot loader with the capabilities of U-Boot.
> 
> 
>>Has anyone done any working in getting a compressed u-boot image to boot
>>ala the Linux kernel ?
> 
> 
> Some people did (like for the AT91RM9200), but it makes little sense,
> unless you abandon very basic design principles, like doing  as  much
> as  possible in standard C code, providing console output as early as
> possible, making ports to new CPUs and boards as  easy  as  possible,
> etc.
> 
> On the AT91RM9200 we're right now in the process of getting od of the
> binary boot loader that loads a compressed U-Boot image: it's a  PITA
> to  have  yet  another  piece  of  software  that needs to be ported,
> debugged and maintained, and that does nothing  but  adding  lots  of
> delays to the boot time.
> 
> 
> While technically possible (and not exactly difficult)  it  makes  no
> sense to me to implement such a feature.
> 
> Best regards,
> 
> Wolfgang Denk
> 

In my case I was hoping to use u-boot simply as a network boot loader without
all of the debugging options. However I have only 32KByte to store the
code in ....

Is there another PPC based network boot loader you know off that would be
better at this than u-boot ?

Cheers

Terry

-- 
Dr Terry Barnaby                     BEAM Ltd
Phone: +44 1454 324512               Northavon Business Center, Dean Rd
Fax:   +44 1454 313172               Yate, Bristol, BS37 5NH, UK
Email: terry at beam.ltd.uk             Web: www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
                       "Tandems are twice the fun !"

[U-Boot-Users] Compressed U-Boot image

[Wolfgang Denk]

Dear Terry,

in message <41890987.6090107@beam.ltd.uk> you wrote:
> 
> In my case I was hoping to use u-boot simply as a network boot loader without
> all of the debugging options. However I have only 32KByte to store the
> code in ....

The boot loader still has to do a lot of things, and  32  kB  is  not
much. Just reserve more memory for the boot loader :-)

> Is there another PPC based network boot loader you know off that would be
> better at this than u-boot ?

Better than UBoot? Such a question is obviously off topic here :-) :-)

Sory - I don't know of a boot loader  small  enough  and  still  with
network  support included, but then I'm not absolutely sure about all
possible configuration options for other boot loaders.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Even historians fail to learn from history -- they repeat the same
mistakes.
	-- John Gill, "Patterns of Force", stardate 2534.7

[U-Boot-Users] Compressed U-Boot image

[Scott McNutt]

> The u-boot image is quite large.

That depends on what you are comparing it with. You
can always take out what you don't need to trim things
down.

> Has anyone done any working in getting a compressed
 > u-boot image to boot ala the Linux kernel ?

Yes, but it's difficult to support multiple platforms
without complicating the build process. I need a
u-boot __binary__ to be very small since it must fit
into a small serial flash (config) device for an FPGA
(w/Nios-II). But I also need many features (with long
help text). So, I tried a few times to come up with a
general solution ... but never really liked any of them.

In the end, it was easier to just gzip the stock u-boot.bin,
and link it in with some simple startup/decompress code.
So, I have a very compact binary ... and I avoided the
challenge of keeping Wolfgang happy with a maintainable,
general solution ;-)

Regards,
--Scott

[U-Boot-Users] Compressed U-Boot image

[VanBaren, Gerald]

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf
> Of Terry Barnaby
> Sent: Wednesday, November 03, 2004 11:39 AM
> To: Wolfgang Denk
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Compressed U-Boot image

[snip]

> In my case I was hoping to use u-boot simply as a network
> boot loader without all of the debugging options. However I
> have only 32KByte to store the code in ....
>
> Is there another PPC based network boot loader you know off
> that would be better at this than u-boot ?
>
> Cheers
>
> Terry

Hi Terry,

You have a significant challenge.  I just did a quick gzip --best check
which confirmed that my u-boot image compressed ~50% (45% but you will
need to add the decompression code).  This implies that you need an
uncompressed u-boot image smaller than 64K.  Since you have all the
source, it is do-able, it is just a question of how hard you are willing
to work and what you are willing to cut out ;-).

My advice is to...
1) Configure a minimal u-boot by turning off as many commands as
possible.
2) See how close you are.  My gut feel is that, if you are under 96K,
you have a decent chance.
3) Look in the u-boot.map file and see who the heavy hitters are.  With
some luck, you will be able to minimize or remove enough of them to get
under 64K.

As everybody has been saying, this isn't going to be easy.  The nice
thing is that you are starting from solid code.  A _lot_ of people make
the mistake of optimizing and then debugging... it is a lot easier to
debug and then optimize.

Looking at my u-boot map it is very clear how much memory each .a/.o is
taking up (3rd column in the .text section) and what it is used for.  I
see several decompression libraries (gzip, bzip2, inflate?) that you
could remove all-but-one (and possibly all if you can get u-boot to
re-use the u-boot image decompression routine that you will need to
write).  The command parser and commands make up a pretty large chunk --
obviously that can be minimized and possibly eliminated.

Some big hitters that are obviously necessary.  These add up to just
over 32K.  We're still in the game, but this isn't looking very easy.
 .text          0xff800000     0x3560 cpu/mpc8260/start.o
 .text          0xff805098     0x1bf4 net/libnet.a(net.o)
 .text          0xff806c8c      0x6b0 net/libnet.a(tftp.o)
 .text          0xff80733c      0xae0 net/libnet.a(bootp.o)
 .text          0xff808018      0x87c net/libnet.a(eth.o)
 .text          0xff80992c      0xab4 common/libcommon.a(main.o)
 .text          0xff81248c      0x96c common/libcommon.a(console.o)
 .text          0xff812fb0     0x1328 common/libcommon.a(dlmalloc.o)

Commands, most or all of which would need to be sacrificed
 .text          0xff814bb8     0x2674 common/libcommon.a(hush.o)
 .text          0xff80a3e0      0x1ec
common/libcommon.a(cmd_autoscript.o)
 .text          0xff80a5cc      0x23c common/libcommon.a(cmd_bdinfo.o)
 .text          0xff80a808       0xbc common/libcommon.a(cmd_boot.o)
 .text          0xff80a8c4     0x11e8 common/libcommon.a(cmd_bootm.o)
 .text          0xff80baac      0x1cc common/libcommon.a(cmd_cache.o)
 .text          0xff80bc78      0x120 common/libcommon.a(cmd_console.o)
 .text          0xff80bd98      0xb5c common/libcommon.a(cmd_flash.o)
 .text          0xff80c8f4      0xe18 common/libcommon.a(cmd_immap.o)
 .text          0xff80d70c      0x424 common/libcommon.a(cmd_itest.o)
 .text          0xff80db30      0x3b0 common/libcommon.a(cmd_jffs2.o)
 .text          0xff80dee0     0x1320 common/libcommon.a(cmd_load.o)
 .text          0xff80f200      0xd04 common/libcommon.a(cmd_mem.o)
 .text          0xff80ff04      0x820 common/libcommon.a(cmd_mii.o)
 .text          0xff810724       0xb0 common/libcommon.a(cmd_misc.o)
 .text          0xff8107d4      0x5b8 common/libcommon.a(cmd_net.o)
 .text          0xff810d8c      0xca8 common/libcommon.a(cmd_nvedit.o)
 .text          0xff811a34      0x178 common/libcommon.a(cmd_portio.o)

I _really hope_ that you have a development board that you can create an
analog of your compressed u-boot on and debug it before you have to go
to a severely memory starved environment.

You have an interesting challenge.  Keep us informed and good luck,
gvb

******************************************
The following messages are brought to you by the Lawyers' League of
IdioSpeak:

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] Compressed U-Boot image

[Wolfgang Denk]

In message <065ACD8E84315E4394C835E398C8D5EB9A601B@COSSMGMBX02.email.corp.tld> you wrote:
> 
...
> write).  The command parser and commands make up a pretty large chunk --
> obviously that can be minimized and possibly eliminated.

If you eliminate the command parser I wonder  why  you  don't  simply
replace  U-Boot  by  a  simple  "return" instruction - no more than 4
bytes needed for that ;-)

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I know engineers. They love to change things.             - Dr. McCoy

[U-Boot-Users] Compressed U-Boot image

[VanBaren, Gerald]

> -----Original Message-----
> From: wd at denx.de [mailto:wd at denx.de]
> Sent: Thursday, November 04, 2004 9:25 AM
> To: VanBaren, Gerald (AGRE)
> Cc: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] Compressed U-Boot image
>
> In message
> <065ACD8E84315E4394C835E398C8D5EB9A601B@COSSMGMBX02.email.corp
> .tld> you wrote:
> >
> ...
> > write).  The command parser and commands make up a pretty
> large chunk
> > -- obviously that can be minimized and possibly eliminated.
>
> If you eliminate the command parser I wonder  why  you  don't
>  simply replace  U-Boot  by  a  simple  "return" instruction
> - no more than 4 bytes needed for that ;-)
>
> Best regards,
>
> Wolfgang Denk
>
> --
> See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> I know engineers. They love to change things.             - Dr. McCoy

Hi WD, I like your .sig, very appropriate today :-)

I acknowledge the wink in your response, but my thought here is that, if
you _really_ need to fit in 32K, you may want to run "tftpboot" (or
equiv) instead of hush so that all the gutted u-boot knows how to do is
boot linux over the network.  Kind of equivalent to replacing "init" in
a linux disk image so that it runs your application directly.

There were only two requirements specified by Terry: net boot and fit in
32K.  Hopefully he is an engineer per Dr. McCoy ;-).

gvb


******************************************
The following messages are brought to you by the Lawyers' League of
IdioSpeak:

******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] Compressed U-Boot image

[Terry Barnaby]

VanBaren, Gerald (AGRE) wrote:
>>-----Original Message-----
>>From: u-boot-users-admin at lists.sourceforge.net
>>[mailto:u-boot-users-admin at lists.sourceforge.net] On Behalf
>>Of Terry Barnaby
>>Sent: Wednesday, November 03, 2004 11:39 AM
>>To: Wolfgang Denk
>>Cc: u-boot-users at lists.sourceforge.net
>>Subject: Re: [U-Boot-Users] Compressed U-Boot image
> 
> 
> [snip]
> 
> 
>>In my case I was hoping to use u-boot simply as a network
>>boot loader without all of the debugging options. However I
>>have only 32KByte to store the code in ....
>>
>>Is there another PPC based network boot loader you know off
>>that would be better at this than u-boot ?
>>
>>Cheers
>>
>>Terry
> 
> 
> Hi Terry,
> 
> You have a significant challenge.  I just did a quick gzip --best check
> which confirmed that my u-boot image compressed ~50% (45% but you will
> need to add the decompression code).  This implies that you need an
> uncompressed u-boot image smaller than 64K.  Since you have all the
> source, it is do-able, it is just a question of how hard you are willing
> to work and what you are willing to cut out ;-).
> 
> My advice is to...
> 1) Configure a minimal u-boot by turning off as many commands as
> possible.
> 2) See how close you are.  My gut feel is that, if you are under 96K,
> you have a decent chance.
> 3) Look in the u-boot.map file and see who the heavy hitters are.  With
> some luck, you will be able to minimize or remove enough of them to get
> under 64K.
> 
> As everybody has been saying, this isn't going to be easy.  The nice
> thing is that you are starting from solid code.  A _lot_ of people make
> the mistake of optimizing and then debugging... it is a lot easier to
> debug and then optimize.
> 
> Looking at my u-boot map it is very clear how much memory each .a/.o is
> taking up (3rd column in the .text section) and what it is used for.  I
> see several decompression libraries (gzip, bzip2, inflate?) that you
> could remove all-but-one (and possibly all if you can get u-boot to
> re-use the u-boot image decompression routine that you will need to
> write).  The command parser and commands make up a pretty large chunk --
> obviously that can be minimized and possibly eliminated.
> 
> Some big hitters that are obviously necessary.  These add up to just
> over 32K.  We're still in the game, but this isn't looking very easy.
>  .text          0xff800000     0x3560 cpu/mpc8260/start.o
>  .text          0xff805098     0x1bf4 net/libnet.a(net.o)
>  .text          0xff806c8c      0x6b0 net/libnet.a(tftp.o)
>  .text          0xff80733c      0xae0 net/libnet.a(bootp.o)
>  .text          0xff808018      0x87c net/libnet.a(eth.o)
>  .text          0xff80992c      0xab4 common/libcommon.a(main.o)
>  .text          0xff81248c      0x96c common/libcommon.a(console.o)
>  .text          0xff812fb0     0x1328 common/libcommon.a(dlmalloc.o)
> 
> Commands, most or all of which would need to be sacrificed
>  .text          0xff814bb8     0x2674 common/libcommon.a(hush.o)
>  .text          0xff80a3e0      0x1ec
> common/libcommon.a(cmd_autoscript.o)
>  .text          0xff80a5cc      0x23c common/libcommon.a(cmd_bdinfo.o)
>  .text          0xff80a808       0xbc common/libcommon.a(cmd_boot.o)
>  .text          0xff80a8c4     0x11e8 common/libcommon.a(cmd_bootm.o)
>  .text          0xff80baac      0x1cc common/libcommon.a(cmd_cache.o)
>  .text          0xff80bc78      0x120 common/libcommon.a(cmd_console.o)
>  .text          0xff80bd98      0xb5c common/libcommon.a(cmd_flash.o)
>  .text          0xff80c8f4      0xe18 common/libcommon.a(cmd_immap.o)
>  .text          0xff80d70c      0x424 common/libcommon.a(cmd_itest.o)
>  .text          0xff80db30      0x3b0 common/libcommon.a(cmd_jffs2.o)
>  .text          0xff80dee0     0x1320 common/libcommon.a(cmd_load.o)
>  .text          0xff80f200      0xd04 common/libcommon.a(cmd_mem.o)
>  .text          0xff80ff04      0x820 common/libcommon.a(cmd_mii.o)
>  .text          0xff810724       0xb0 common/libcommon.a(cmd_misc.o)
>  .text          0xff8107d4      0x5b8 common/libcommon.a(cmd_net.o)
>  .text          0xff810d8c      0xca8 common/libcommon.a(cmd_nvedit.o)
>  .text          0xff811a34      0x178 common/libcommon.a(cmd_portio.o)
> 
> I _really hope_ that you have a development board that you can create an
> analog of your compressed u-boot on and debug it before you have to go
> to a severely memory starved environment.
> 
> You have an interesting challenge.  Keep us informed and good luck,
> gvb
> 
> ******************************************
> The following messages are brought to you by the Lawyers' League of
> IdioSpeak:
> 
> ******************************************
> The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
> ******************************************
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_idU88&alloc_id\x12065&op?k
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

Hi,

Thanks for the info.
I may have a look at doing this, although it may be simpler for me to
create a separate simple network bootloader for this particular
special case.

Terry

-- 
Dr Terry Barnaby                     BEAM Ltd
Phone: +44 1454 324512               Northavon Business Center, Dean Rd
Fax:   +44 1454 313172               Yate, Bristol, BS37 5NH, UK
Email: terry at beam.ltd.uk             Web: www.beam.ltd.uk
BEAM for: Visually Impaired X-Terminals, Parallel Processing, Software
                       "Tandems are twice the fun !"

[U-Boot-Users] Compressed U-Boot image

[Wolfgang Denk]

In message <065ACD8E84315E4394C835E398C8D5EB9A60F3@COSSMGMBX02.email.corp.tld> you wrote:
> 
> I acknowledge the wink in your response, but my thought here is that, if
> you _really_ need to fit in 32K, you may want to run "tftpboot" (or
> equiv) instead of hush so that all the gutted u-boot knows how to do is

If you don't need hush, then just don't enable it an use  the  simple
command line parser (which is significantly smaller).

> There were only two requirements specified by Terry: net boot and fit in
> 32K.  Hopefully he is an engineer per Dr. McCoy ;-).

I'm afraid it still will not fit. 32 kB is just too small. The design
limit of U-Boot that I've always had in mind was 128 kB.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded/Electronica Munich, Nov 09 - 12, Hall A.6 Booth 513
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Landing: a controlled mid-air collision with a planet.