Re: [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf
Dear Graeme Russ, In message you wrote: > > > My current implementation is to do a memory dump by using the uboot, > > while uboot's only task is to compress and write the memory to the sd card. > > For the compress and write part need a lot of heap, 350k+, if still keep the > > env buf in the stack, it would increase the total memory touched by uboot... > > > > As dump usage need uboot touch the least memory, so this is the purpose > > I submit this patch... Reuse the heap area at its best, and don't increase > > stack > > much in the runtime... > > Ah, so with the env buffer on the stack, the bottom of the stack is being > pushed into the memory you want to dump and corrupting it - Makes sense to > me now that you would resort to moving the env buffer to the heap. No, this makes zero sense, as there is only a single time when the environment buffers are allocated on the stack, and this is very early in the initialization, and then the buffers are released and will never be used again - they are gone without any trace when Lei Wen can run any of his code. On the other hand, it sounds as if he ad a huge malloc arena, which is statically reserved and thus unusable for other pruposed for the whole U-Boot run time. > There are probably a number of other areas in u-boot where large buffers > are put on the stack while the malloc pool is relatively empty with the > end result being that u-boot is using more memory than strictly required. > > It would be an interesting profiling excercise Indeed there is probably potential for optimization - but usually it's the other way round: using buffers on the stack is frequently what results in smaller code and a smaller overall memory footprint; not to mention the issue of memory leaks when using malloc(). I seriously doubt that Lei Wen as able to show any improvement of the memory footprint by his code. In the best case, he already has reserved a huge malloc arena so the environment buffers can be allocated there. In this case, the overall effect of his patch is the increased code size which _reduces_ the free memory on his system. He does NOT save any memory on the stack, because the env_relocate_spec() simply never ever gets called when he is running his 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: w...@denx.de Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf
Dear Lei Wen, In message you wrote: > > > I mentioned this before: the stack can temporarily use arbitrary > > amounts of storage, whil still allowing you to use a maximum of free > > RAM at other times. > > > > I don't really care how much memory is needed on the stack for > > environment buffers when importing or exporting the environment > > from/to external storage, because this memory is freed again and > > usable for other purposes when I need it, for example to load some big > > OS and/or file system images. With malloc(), such memory is permantly > > reseverd, and thus permantly lost. > > I am a little confused here... Why the malloc would make the memory permantly > reserved and lost... In this patch, I just temp malloc one buffer, then free > it > after I use it... Yes, you free it, so it becomes usable for other malloc() calls (eventually - in real life fragmentation might play a role, too), but you sneed to reserve the full emount of buffer space in the malloc arena, for the whole like time of U-Boot. On the othern hand, when using buffers on the stack, then these buffers are only temporarily used, when the functions are actually being called. In this specific case (keep in mind that we are talking about env_relocate_spec() this happens exactlky once, very early in the system initialization, i. e. long before you are able to run any user commands. > My current implementation is to do a memory dump by using the uboot, > while uboot's only task is to compress and write the memory to the sd card. > For the compress and write part need a lot of heap, 350k+, if still keep the > env buf in the stack, it would increase the total memory touched by uboot... This statement makes no sense at all. The environment buffers are only used once, long before you are able to run any user commands. Wehn you can start doing your stuff, they are long gone, and all of it's memory has been reclaimed. > As dump usage need uboot touch the least memory, so this is the purpose > I submit this patch... Reuse the heap area at its best, and don't increase > stack > much in the runtime... But it statically increases the size of the malloc areane, so you are just shifting the memory from location A to B. For the last time I repeat my question: can you please explain how your patch is supposed to reduce the memory footprint of your system, and document your acchievments with actual measurements? I would expect that the time when the environment buffers need space on the stack is NOT the time when you need so much of memory? 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: w...@denx.de Generally speaking, there are other ways to accomplish whatever it is that you think you need ... - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf
On Mon, Feb 7, 2011 at 3:38 PM, Lei Wen wrote: > Hi Wolfgang, > > On Mon, Feb 7, 2011 at 12:08 AM, Wolfgang Denk wrote: >> Dear Lei Wen, >> >> In message >> you wrote: >>> > My current implementation is to do a memory dump by using the uboot, > while uboot's only task is to compress and write the memory to the sd card. > For the compress and write part need a lot of heap, 350k+, if still keep the > env buf in the stack, it would increase the total memory touched by uboot... > > As dump usage need uboot touch the least memory, so this is the purpose > I submit this patch... Reuse the heap area at its best, and don't increase > stack > much in the runtime... > Ah, so with the env buffer on the stack, the bottom of the stack is being pushed into the memory you want to dump and corrupting it - Makes sense to me now that you would resort to moving the env buffer to the heap. There are probably a number of other areas in u-boot where large buffers are put on the stack while the malloc pool is relatively empty with the end result being that u-boot is using more memory than strictly required. It would be an interesting profiling excercise Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] BeagleBoard-xM: Ethernet over USB supported ?
On Sat, Feb 5, 2011 at 7:35 PM, Alexander Holler wrote: > Hello, > > Am 05.02.2011 14:18, schrieb Olivier Martin: >> I am trying to enable boot from tftp for a BeagleBoard-xM. >> The BeagleBoard-xM has an integrated Ethernet port over USB. > > Currently there is no support for omap-ehci in u-boot. That means only > the MUSB (OTG) USB port is usable. > > Regards, > > Alexander There was some work done on getting EHCI working - I'll see if I can poke the chaps that worked on it and get that posted here. However, in addition to the omap-ehci support, won't we need a driver for the SMSC LAN9514 ethernet controller on the board? It sure would be useful to have this - the pandaboard also has the same chip, so it would be useful there as well. - Anand ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf
Hi Wolfgang, On Mon, Feb 7, 2011 at 12:08 AM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message you > wrote: >> >> > malloc arena and stack are adjacent. If you have enough free room in >> > the malloc arena for the environment buffers, but cannot afford to >> > have them on your stack, then this means your malloc arena has lots of >> > unused space. Decrease the size of your malloc arena by the size of >> > the environment buffer, and you reach the same goal as with your >> > patch - actually you save more memory, as the code size of u-boot >> > shrinks. >> >> Em, what you said is also right for my case. >> But I think making the malloc heap area large while limit the stack usage >> could benefit those function use malloc, while keep user in mind how many >> memory he is using on that board. For now, uboot just print uboot >> self-reserved, >> malloc size, board info, global data size for the uesr. For the stack usage, >> user is not quite aware of. >> >> Just like the env case, if that ENV_SIZE goes too large, user may not notice >> the memory usage just from the debug info. > > We should pay attention to use the correct terms here. The "user", > i. e. the end user running the U-Boot image on some system, will most > probably not bother at all wether you use space on the stack or in the > malloc arena, or how much. The only thing that concerns him is that > the thing "just works". > Sorry for the wrong using of "user" term here... > It is our, the developer's, task, to make sure his expectations are > met. And from the robustness and reliability, but also from the > memory footprint point of view, may favours go clearly with automatic > variables on the stack over manual allocation. > > I mentioned this before: the stack can temporarily use arbitrary > amounts of storage, whil still allowing you to use a maximum of free > RAM at other times. > > I don't really care how much memory is needed on the stack for > environment buffers when importing or exporting the environment > from/to external storage, because this memory is freed again and > usable for other purposes when I need it, for example to load some big > OS and/or file system images. With malloc(), such memory is permantly > reseverd, and thus permantly lost. I am a little confused here... Why the malloc would make the memory permantly reserved and lost... In this patch, I just temp malloc one buffer, then free it after I use it... > > In my opinion this is a clear disadvantage of the malloc() based > approach. > >> My ram is big, 512MB. But for my case, I need uboot use the minimum memory >> as it can. The debug output is same, for this patch don't change the > > Can you please explain your requirements in a bit more detail, and > especially, how your patch is supposed to help? I would expect that > the time when the environment buffers need space on the stack is NOT > the time when you need so much of memory? > My current implementation is to do a memory dump by using the uboot, while uboot's only task is to compress and write the memory to the sd card. For the compress and write part need a lot of heap, 350k+, if still keep the env buf in the stack, it would increase the total memory touched by uboot... As dump usage need uboot touch the least memory, so this is the purpose I submit this patch... Reuse the heap area at its best, and don't increase stack much in the runtime... Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot 1.1.3 and ADS Graphics Client Plus (No Ethernet)
On Feb 6, 2011, at 11:25 PM, Wolfgang Denk wrote: > > You cannot change the tool chain (software, cheap or free, basicly > zero ecological footprint), but you can change the hardware > (expensive in many aspectes)? Weird... The ADS hardware is very old, thats also why i prefer using the old u-boot, i know the newer versions would properly work better, but i know it was working. Its more a "it has to work, if you understand" old hardware, old toolchain, old parts :) Regards Ronni ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot 1.1.3 and ADS Graphics Client Plus (No Ethernet)
Dear =?iso-8859-1?Q?Ronni_H=F8mpler?=, In message <8f9c8a81-52b6-48f5-9f10-c3266b2b5...@edesigns.dk> you wrote: > > Updating my toolchain is not an option, and i know it did work with the > old u-boot 1.1.3, but duo to bad timing the project was dropped for a > few years. ... > Im out of ideas, maybe its time to scrap that ADS board, and get > something that has support. You cannot change the tool chain (software, cheap or free, basicly zero ecological footprint), but you can change the hardware (expensive in many aspectes)? Weird... 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: w...@denx.de A Chairman was as necessary to a Board planet as the zero was in mathematics, but being a zero had big disadvantages... - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot 1.1.3 and ADS Graphics Client Plus (No Ethernet)
On Feb 6, 2011, at 10:47 PM, Wolfgang Denk wrote: > > No surprize that old tools won't work with current code. > > So this requires a two-step solution. In the first step, update your > tool chain. > > Hi. Sorry about that. Updating my toolchain is not an option, and i know it did work with the old u-boot 1.1.3, but duo to bad timing the project was dropped for a few years. Maybe the problem is not u-boot but the network hardware im using, ive tried with wireshark on the server to listen to the network interface while asking u-boot to get an ip using dhcp, no traffic at all. Im out of ideas, maybe its time to scrap that ADS board, and get something that has support. Regards Ronni___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] u-boot-mpc83xx - couple of minor fixes
Dear Kim Phillips, In message <20110205172435.405b1f20.kim.phill...@freescale.com> you wrote: > Wolfgang Denk, > > Please pull a couple of minor fixes for 83xx: > > The following changes since commit f69b980d108b5f15ca7dd3f4284d5a66488c3625: > > Merge branch 'master' of git://git.denx.de/u-boot-nand-flash (2011-02-04 > 21:44:46 +0100) > > are available in the git repository at: > > git://git.denx.de/u-boot-mpc83xx.git master > > Joakim Tjernlund (1): > mpc83xx: Use correct register to calculate clocks. > > Leo Liu (1): > mpc83xx: fix pcie configuration space read/write > > arch/powerpc/cpu/mpc83xx/pcie.c | 19 ++- > arch/powerpc/cpu/mpc83xx/speed.c | 15 --- > include/mpc83xx.h|7 +++ > include/pci.h|2 ++ > 4 files changed, 35 insertions(+), 8 deletions(-) Applied, thanks. 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: w...@denx.de It is easier to write an incorrect program than understand a correct one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-usb
Dear Remy Bohmer, In message you wrote: > The following changes since commit f69b980d108b5f15ca7dd3f4284d5a66488c3625: > > Merge branch 'master' of git://git.denx.de/u-boot-nand-flash > (2011-02-04 21:44:46 +0100) > > are available in the git repository at: > > git://git.denx.de/u-boot-usb.git master > > Alexander Holler (2): > USB: Fix device stati for removable and powerctrl (typo) > USB: Change the necessary defines to get debug output > > common/usb.c |9 + > 1 files changed, 5 insertions(+), 4 deletions(-) Applied, thanks. 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: w...@denx.de It's not an optical illusion, it just looks like one. -- Phil White ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] lease pull u-boot-mpc85xx.git
Dear Kumar Gala, In message you wrote: > Some bug fix and errata fixes. > > - k > > The following changes since commit 42d44f631c4e8e5359775bdc098f2fffde4e5c05: > > Prepare v2011.03-rc1 (2011-02-02 22:37:32 +0100) > > are available in the git repository at: > git://git.denx.de/u-boot-mpc85xx.git master > > Kumar Gala (3): > powerpc/85xx: Enable ESDHC111 Erratum on P2010/P2020 SoCs > fsl_esdhc: Add the workaround for erratum ESDHC-A001 (enable on P2020) > powerpc/8xxx: Fix possible compile issue related to P1013 > > York Sun (5): > powerpc/85xx: Remove unnecessary polling loop from DDR init > powerpc/85xx: Enable Errata command on MPC8572DS > powerpc/85xx: Rename MPC8572 DDR erratum to DDR115 > powerpc/mpc85xx: implement workaround for errata DDR111 and DDR134 > powerpc/85xx: Enable ECC on MPC8572DS > > arch/powerpc/cpu/mpc85xx/Makefile |2 +- > arch/powerpc/cpu/mpc85xx/cmd_errata.c | 11 +++- > arch/powerpc/cpu/mpc85xx/ddr-gen3.c | 111 +++- > arch/powerpc/include/asm/config_mpc85xx.h |6 ++ > arch/powerpc/include/asm/fsl_ddr_sdram.h |5 ++ > drivers/mmc/fsl_esdhc.c |5 ++ > include/configs/MPC8572DS.h |3 +- > 7 files changed, 136 insertions(+), 7 deletions(-) Applied, thanks. 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: w...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment
On 2/6/11 12:41 PM, Grant Erickson wrote: > I recently updated my TI AM37x EVM from U-Boot 2010.09 to 2010.12 and noticed > that, in doing so, saveenv / env save no longer seems to work. The following > example demonstrates [ELIDED]: I subsequently found the following patch and commit: http://www.mail-archive.com/u-boot@lists.denx.de/msg46834.html http://git.denx.de/?p=u-boot.git;a=commitdiff;h=920a5dd2325438a82b6ac8102c5a 5e0c43276fd;hp=42d44f631c4e8e5359775bdc098f2fffde4e5c05 However, it's not clear how this patch can reasonably work outside of random chance: // Allocate a new environment on the stack. The environment structure is // whatever random data is already on the stack. env_tenv_new; ... // At this point, the data field will be initialized; however, crc and // flags are still random data. res = (char *)&env_new.data; len = hexport_r(&env_htab, '\0', &res, ENV_SIZE); // The crc field is now set. env_new.crc = crc32(0, env_new.data, ENV_SIZE); // Preincrement random data. ++env_new.flags; /* increase the serial */ Unfortunately, preincrementing random data won't replicate the behavior of 2010.09, where the flags field was referenced through a global env_ptr such that flag manipulation was handled (more) coherently as the environment was read and written. Best, Grant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment
Dear Grant Erickson, In message you wrote: > I recently updated my TI AM37x EVM from U-Boot 2010.09 to 2010.12 and > noticed that, in doing so, saveenv / env save no longer seems to work. The > following example demonstrates: See git commit 920a5dd 2011-02-02 16:14:08 -0600 NAND: Fix saving of redundand environment 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: w...@denx.de Heavier than air flying machines are impossible. -- Lord Kelvin, President, Royal Society, c. 1895 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot 1.1.3 and ADS Graphics Client Plus (No Ethernet)
Dear =?iso-8859-1?Q?Ronni_H=F8mpler?=, In message you wrote: > > First off im sorry if this ends up the wrong place. This is the perfectly right place... ...but U-Boot 1.1.3 is so old that you will not find many people here that still remember. I recommend to update and use somewhat current code instead. Use v2010.09 (i. e. a version before the great earthquake). 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: w...@denx.de I perceive a possibility of an immediate chronological sequence of events which includes a violence. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment
I recently updated my TI AM37x EVM from U-Boot 2010.09 to 2010.12 and noticed that, in doing so, saveenv / env save no longer seems to work. The following example demonstrates: => version U-Boot 2010.12 (Feb 04 2011 - 16:12:51) => env print foo ## Error: "foo" not defined => env set foo bar => env save Saving Environment to NAND... Erasing redundant NAND... Erasing at 0x3a -- 100% complete. Writing to redundant NAND... done => env print foo foo=bar => reset resetting ... ... Hit any key to stop autoboot: 0 => env print foo ## Error: "foo" not defined However, I can successfully read and write NAND, for example, updating u-boot. Anyone else noticed this on OMAP-based boards? With NAND? With NOR? Running a few more experiments, I find that I can entirely whack the environment, set a variable once thereafter, but never again: => printenv resetenv resetenv=nand erase 0x34 0x1000 && nand erase 0x3a 0x1000 => run resetenv NAND erase: device 0 offset 0x34, size 0x1000 Erasing at 0x34 -- 100% complete. OK NAND erase: device 0 offset 0x3a, size 0x1000 Erasing at 0x3a -- 100% complete. OK => reset resetting ... ... *** Warning - bad CRC, using default environment ... Hit any key to stop autoboot: 0 => saveenv Saving Environment to NAND... Erasing redundant NAND... Erasing at 0x3a -- 100% complete. Writing to redundant NAND... done => setenv foo bar => printenv foo foo=bar => saveenv Saving Environment to NAND... Erasing NAND... Erasing at 0x34 -- 100% complete. Writing to NAND... done => printenv foo foo=bar => reset resetting ... ... Hit any key to stop autoboot: 0 => printenv foo foo=bar => env delete foo Not implemented yet => setenv foo => printenv foo ## Error: "foo" not defined => saveenv Saving Environment to NAND... Erasing redundant NAND... Erasing at 0x3a -- 100% complete. Writing to redundant NAND... done => printenv foo ## Error: "foo" not defined => reset resetting ... ... Hit any key to stop autoboot: 0 => printenv foo foo=bar -- Principal Nuovations 998 Alpine Terrace Suite 3 Sunnyvale, CA 94086-2469 US T +1-408-749-0495 F +1-205-449-0495 M +1-408-489-5710 gerick...@nuovations.com http://www.nuovations.com/ Best, Grant ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot 1.1.3 and ADS Graphics Client Plus (No Ethernet)
Hey. First off im sorry if this ends up the wrong place. I have been trying for the last 4 days to get u-boot to work on my old ADS board, but without any luck. u-boot is flashed to the board, and does start up, my env looks like this: ADS GCPlus # printenv bootdelay=3 baudrate=38400 autoload=n ethaddr=00:60:0C:00:16:7A gatewayip=192.168.0.25 netmask=255.255.255.0 ipaddr=192.168.0.205 loadkernel=tftp c000 uImage loadramdisk=tftp c080 ramdisk.gz serverip=192.168.0.25 hostname=arm bootfile=uImage bootcmd=tftp;bootm bootargs=console=ttySA0 mem=16m@0xc000 rw root=/dev/nfs nfsroot=192.168.1.20:/nfs nfsaddrs=192.168.0.205:192.168.0.20:192.168.0.254:255.255.255.255.0: noinitrd stdin=serial stdout=serial stderr=serial It should be correct, but i can't get the ethernet to work, no matter what i try, it just times out and start spitting errors, something with ARP Request timed out, i can get the correct error if necessary. The server is tested, and working perfect, so is the cable, and the ethernet card on the ADS board also works fine when linux is first booted, but not in the u-boot loader. What have i missed here, hoping for help. U-Boot was configured with make gcplus_config and then make all Regards Ronni Ps, Sorry for my bad english. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf
Dear Lei Wen, In message you wrote: > > > malloc arena and stack are adjacent. Â If you have enough free room in > > the malloc arena for the environment buffers, but cannot afford to > > have them on your stack, then this means your malloc arena has lots of > > unused space. Decrease the size of your malloc arena by the size of > > the environment buffer, and you reach the same goal as with your > > patch - actually you save more memory, as the code size of u-boot > > shrinks. > > Em, what you said is also right for my case. > But I think making the malloc heap area large while limit the stack usage > could benefit those function use malloc, while keep user in mind how many > memory he is using on that board. For now, uboot just print uboot > self-reserved, > malloc size, board info, global data size for the uesr. For the stack usage, > user is not quite aware of. > > Just like the env case, if that ENV_SIZE goes too large, user may not notice > the memory usage just from the debug info. We should pay attention to use the correct terms here. The "user", i. e. the end user running the U-Boot image on some system, will most probably not bother at all wether you use space on the stack or in the malloc arena, or how much. The only thing that concerns him is that the thing "just works". It is our, the developer's, task, to make sure his expectations are met. And from the robustness and reliability, but also from the memory footprint point of view, may favours go clearly with automatic variables on the stack over manual allocation. I mentioned this before: the stack can temporarily use arbitrary amounts of storage, whil still allowing you to use a maximum of free RAM at other times. I don't really care how much memory is needed on the stack for environment buffers when importing or exporting the environment from/to external storage, because this memory is freed again and usable for other purposes when I need it, for example to load some big OS and/or file system images. With malloc(), such memory is permantly reseverd, and thus permantly lost. In my opinion this is a clear disadvantage of the malloc() based approach. > My ram is big, 512MB. But for my case, I need uboot use the minimum memory > as it can. The debug output is same, for this patch don't change the Can you please explain your requirements in a bit more detail, and especially, how your patch is supposed to help? I would expect that the time when the environment buffers need space on the stack is NOT the time when you need so much of memory? 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: w...@denx.de The night sky over the planet Krikkit is the least interesting sight in the entire Universe. - Douglas Adams _Life, the Universe, and Everything_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-BOOT] [PATCH] env: reduce the stack footprint for the env buf
Hi Wolfgang, On Sat, Feb 5, 2011 at 4:30 PM, Wolfgang Denk wrote: > Dear Lei Wen, > > In message you > wrote: >> >> > In which way do you think this will save any memory? >> >> This patch is not intend to save memory... > > Then I don't understand at all what the benefit of that patch would > be. > >> One of our project need to confine the ddr usage of uboot in the smallest >> case, >> not to pollute other area. So for us, the small stack is good one... > > So it is still about saving memory... Yes, it also be deemed as saving memory... > >> For now the uboot is relocated to the end of the dram, and malloc area is >> almost a fix value, uboot would live happily in this area. But for env case, >> it allocate a range which could be large, due to the CONFIG_ENV_SIZE >> could be a big one, in the stack range. Because the stack is grown downwards, >> so it takes more memory range than it is allocated in the malloc method. > > malloc arena and stack are adjacent. If you have enough free room in > the malloc arena for the environment buffers, but cannot afford to > have them on your stack, then this means your malloc arena has lots of > unused space. Decrease the size of your malloc arena by the size of > the environment buffer, and you reach the same goal as with your > patch - actually you save more memory, as the code size of u-boot > shrinks. Em, what you said is also right for my case. But I think making the malloc heap area large while limit the stack usage could benefit those function use malloc, while keep user in mind how many memory he is using on that board. For now, uboot just print uboot self-reserved, malloc size, board info, global data size for the uesr. For the stack usage, user is not quite aware of. Just like the env case, if that ENV_SIZE goes too large, user may not notice the memory usage just from the debug info. > > Can you please provide exact numbers? How big is your RAM? What is > the debug output of arch/*/lib/board.c without and with this patch on > your system? How big is your environment resp. the environment > sectors? > My ram is big, 512MB. But for my case, I need uboot use the minimum memory as it can. The debug output is same, for this patch don't change the heap or other part's size. My env is configured as 0x2, as one nand block size. Best regards, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme
Le 06/02/2011 13:03, Magnus Lilja a écrit : > Hi all > > On 01/14/2011 07:33 PM, Fabio Estevam wrote: >> Hi Stefano, >> >> On 1/13/2011 11:38 AM, Stefano Babic wrote: >>> On 01/12/2011 01:49 PM, Fabio Estevam wrote: Hi, >>> >>> Hi Fabio, >>> I am trying to make the new relocation scheme to work on the mx31pdk board. With this patch applied the mx31pdk build works, but not able to get a U-boot prompt yet. >>> >>> I have tried to imagine some issues, but I cannot find a clear reason. >>> Building with your patch I checked that nand_spl is still less than 2KB >>> code, and that matches the NAND page, as required by i.MX31 - so it is >>> not a problem. >>> >>> Have you tried to disable the relocation, just to check if the >>> relocation is an issue with CONFIG_SKIP_RELOCATE_UBOOT ? This is not a >>> solution, but only to check what happens. > > I've done some testing now and ended up comparing start.S for ARM1136 with > ARM926EJS since > the latter is used on the Karo TX25 board which seems to have been updated and > also boots from NAND. > > The result is that applying the following patch on top of Fabios patch makes > the i.MX31 PDK > boot from NAND. Booting Linux from TFTP works nicely. However the first few > lines of output > from U-boot is missing, only the "NAND: 256 MB" line is shown. I haven't > tried to understand > how booting works nowadays and why these changes work, perhaps someone with > more insight > in the mechanisms can figure out the correct assembler code. > > I have no idea if this breaks other boards but at least it's start for > further work. I tried > it on the imx31 litekit (which boots from NOR) but that board doesn't seem to > boot even before applying Fabios patch, > I'll see if I can figure out why that board is broken now. Don't know when > though. > > Regards, Magnus Lilja > > diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S > index 12545c2..7d75ecf 100644 > --- a/arch/arm/cpu/arm1136/start.S > +++ b/arch/arm/cpu/arm1136/start.S > @@ -163,6 +163,9 @@ call_board_init_f: > bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ > ldr r0,=0x > > +#if 1 > + bl board_init_f > +#else > #ifdef CONFIG_NAND_SPL > bl nand_boot > #else > @@ -172,6 +175,7 @@ call_board_init_f: > bl board_init_f > #endif /* CONFIG_ONENAND_IPL */ > #endif /* CONFIG_NAND_SPL */ > +#endif > > > /*--*/ > > @@ -266,11 +270,19 @@ clbss_l:str r2, [r0]/* clear > loop...*/ >* initialization, now running from RAM. >*/ > #ifdef CONFIG_NAND_SPL > +#if 1 > + ldr r0, _nand_boot_ofs > + mov pc, r0 > + > +_nand_boot_ofs: > + .word nand_boot > +#else > ldr r0, _nand_boot_ofs > adr r1, _start > add pc, r0, r1 > _nand_boot_ofs: > .word nand_boot - _start > +#endif > #else > jump_2_ram: > ldr r0, _board_init_r_ofs > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot Can you repost the diff without those pesky '#if 1...#else...#endif' additions? Just take the current master code, do the changes needed to make it work without trying to keep the old lines around, then do the diff. I'll be easier for all to see the changes. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme
Hi all On 01/14/2011 07:33 PM, Fabio Estevam wrote: > Hi Stefano, > > On 1/13/2011 11:38 AM, Stefano Babic wrote: >> On 01/12/2011 01:49 PM, Fabio Estevam wrote: >>> Hi, >> >> Hi Fabio, >> >>> >>> I am trying to make the new relocation scheme to work on the mx31pdk board. >>> >>> With this patch applied the mx31pdk build works, but not able to get a >>> U-boot prompt yet. >> >> I have tried to imagine some issues, but I cannot find a clear reason. >> Building with your patch I checked that nand_spl is still less than 2KB >> code, and that matches the NAND page, as required by i.MX31 - so it is >> not a problem. >> >> Have you tried to disable the relocation, just to check if the >> relocation is an issue with CONFIG_SKIP_RELOCATE_UBOOT ? This is not a >> solution, but only to check what happens. I've done some testing now and ended up comparing start.S for ARM1136 with ARM926EJS since the latter is used on the Karo TX25 board which seems to have been updated and also boots from NAND. The result is that applying the following patch on top of Fabios patch makes the i.MX31 PDK boot from NAND. Booting Linux from TFTP works nicely. However the first few lines of output from U-boot is missing, only the "NAND: 256 MB" line is shown. I haven't tried to understand how booting works nowadays and why these changes work, perhaps someone with more insight in the mechanisms can figure out the correct assembler code. I have no idea if this breaks other boards but at least it's start for further work. I tried it on the imx31 litekit (which boots from NOR) but that board doesn't seem to boot even before applying Fabios patch, I'll see if I can figure out why that board is broken now. Don't know when though. Regards, Magnus Lilja diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index 12545c2..7d75ecf 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -163,6 +163,9 @@ call_board_init_f: bic sp, sp, #7 /* 8-byte alignment for ABI compliance */ ldr r0,=0x +#if 1 + bl board_init_f +#else #ifdef CONFIG_NAND_SPL bl nand_boot #else @@ -172,6 +175,7 @@ call_board_init_f: bl board_init_f #endif /* CONFIG_ONENAND_IPL */ #endif /* CONFIG_NAND_SPL */ +#endif /*--*/ @@ -266,11 +270,19 @@ clbss_l:str r2, [r0]/* clear loop...*/ * initialization, now running from RAM. */ #ifdef CONFIG_NAND_SPL +#if 1 + ldr r0, _nand_boot_ofs + mov pc, r0 + +_nand_boot_ofs: + .word nand_boot +#else ldr r0, _nand_boot_ofs adr r1, _start add pc, r0, r1 _nand_boot_ofs: .word nand_boot - _start +#endif #else jump_2_ram: ldr r0, _board_init_r_ofs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
