[U-Boot-Users] How to specify the size of bin?
Howdy, I know it is a newbie question. Any hint from you are welcome. In default, u-boot 1.1.5, "make walut_config && make all" will generate a 256KB bin. The last 4 bytes of the bin is a jump instruction to the entry point of u-boot.Is that right? But my ppc405GP walnut board has 512KB flash for holding u-boot. I wonder how to build a 512KB bin? Is there any OPTION/SETTING targeting this problem? Anything else I should take care? Thank you! --- ShenLei
On Friday 16 May 2008, 甜瓜 wrote:
I know it is a newbie question. Any hint from you are welcome.In default, u-boot 1.1.5, "make walut_config && make all" will generate a 256KB bin. The last 4 bytes of the bin is a jump instruction to the entry point of u-boot.Is that right?
Yes, this is correct.
But my ppc405GP walnut board has 512KB flash for holding u-boot.
All Walnut boards have 512k of NOR FLASH. Do you really have an original IBM/AMCC Walnut or a different custom 405GP board?
I wonder how to build a 512KB bin?
Generally this is possible. You need to change CONFIG_MONITOR_LEN & CFG_MONITOR_BASE in include/configs/walnut.h. And TEXT_BASE in board/amcc/walnut/config.mk.
Is there any OPTION/SETTING targeting this problem? Anything else I should take care?
But please don't forget that the environment is also stored in the NOR FLASH. And by changing the U-Boot size to 512k you leave no space for the environment.
So why exactly do you want to change the U-Boot image size?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
2008/5/16 Stefan Roese sr@denx.de:
On Friday 16 May 2008, 甜瓜 wrote:
I know it is a newbie question. Any hint from you are welcome.In default, u-boot 1.1.5, "make walut_config && make all" will generate a 256KB bin. The last 4 bytes of the bin is a jump instruction to the entry point of u-boot.Is that right?
Yes, this is correct.
But my ppc405GP walnut board has 512KB flash for holding u-boot.
All Walnut boards have 512k of NOR FLASH. Do you really have an original IBM/AMCC Walnut or a different custom 405GP board?
Yes, my board is a custom board DHT-Walut with 32MB SDRAM and 512k of boot flash AMD 29LV040B. Details are listed in: http://elinux.org/DHT-Walnut
I wonder how to build a 512KB bin?
Generally this is possible. You need to change CONFIG_MONITOR_LEN & CFG_MONITOR_BASE in include/configs/walnut.h. And TEXT_BASE in board/amcc/walnut/config.mk.
Thank you very much. That's exact what I need!
Is there any OPTION/SETTING targeting this problem? Anything else I should take care?
But please don't forget that the environment is also stored in the NOR FLASH. And by changing the U-Boot size to 512k you leave no space for the environment.
Do you mean that environment settings (eg: ip_addr, ethaddr...) are stored sperately from the bin? In my mind (with guess :p), env should be defined in bin code or data section, and it will be compiled together with other codes to form a single bin.
So why exactly do you want to change the U-Boot image size?
Well. The reason is: 1. Both default config of u-boot and a DHT-Walut-patched config generate 256KB bin, but the flash on board is 512KB. So I think I should get a 512KB bin for flash writing. 2. The contents in the flash on my board is totally corrupted by accident. It means the important last-4-bytes should be rewritten to a proper state. 3. Currenly, I have to use special hardware to write bin into flash. Therefore 256KB bin will only overwrite the first half. The last-4-bytes in the end of flash is still the old value. Booting will definitely fail.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Thank you for your reply. --- ShenLei
In message cdb837ea0805152231w72340d28r4ee31ee5d4d51654@mail.gmail.com you wrote:
- Both default config of u-boot and a DHT-Walut-patched config
generate 256KB bin, but the flash on board is 512KB. So I think I should get a 512KB bin for flash writing.
Why?
Do you think on devices with 128 MB flash memory we should have a 128MB U-Boot image?
Do you see any problem with having a U-Boot image that is smaller than your flash device?
- The contents in the flash on my board is totally corrupted by
accident. It means the important last-4-bytes should be rewritten to a proper state.
Agreed.
- Currenly, I have to use special hardware to write bin into flash.
Therefore 256KB bin will only overwrite the first half. The last-4-bytes in the end of flash is still the old value.
That's your problem, tehn. Most people use a noremal JTAG debugger which can prgram the image to any address in the flash.
You got to add 256k of ramdom data in front of the 256 k image, then [memory filled with 0xFF recommended].
Best regards,
Wolfgang Denk
2008/5/16 Wolfgang Denk wd@denx.de:
In message cdb837ea0805152231w72340d28r4ee31ee5d4d51654@mail.gmail.com you wrote:
- Both default config of u-boot and a DHT-Walut-patched config
generate 256KB bin, but the flash on board is 512KB. So I think I should get a 512KB bin for flash writing.
Why?
Do you think on devices with 128 MB flash memory we should have a 128MB U-Boot image?
Do you see any problem with having a U-Boot image that is smaller than your flash device?
- The contents in the flash on my board is totally corrupted by
accident. It means the important last-4-bytes should be rewritten to a proper state.
Agreed.
- Currenly, I have to use special hardware to write bin into flash.
Therefore 256KB bin will only overwrite the first half. The last-4-bytes in the end of flash is still the old value.
That's your problem, tehn. Most people use a noremal JTAG debugger which can prgram the image to any address in the flash.
You got to add 256k of ramdom data in front of the 256 k image, then [memory filled with 0xFF recommended].
haha! Great minds seem alike. Actually, if no solution, I will try this method. Well. As you mentioned, using JTAG we can put bin in any place of flash. Does it means we should manually set the last-4-bytes? How to determine the exact entry point of bin? I can only see the hex value of last-4-bytes, and it definitely does not simply jump to the beginning of bin. It should jump to some location like "start:" in, for example, start.asm. Therefore the JTAG user should translate "jmp start+offset" to machine code by hand. Am I right?
Last, let me tell you why I cannot use JTAG. The recommend method by u-boot is using BDI2000. But it is really expensive. I don't have enough money. hehe. I have tried many home-made wiggler JTAG connectors with OCD commander, but all failed. Finally I give up for finding low-cost PPC JTAG. Currently I give the precompiled bin to some one with special flash writer, and let them burn.
Best regards, -- ShenLei
In message cdb837ea0805152326o58185f02g13d68a65f416c800@mail.gmail.com you wrote:
haha! Great minds seem alike. Actually, if no solution, I will try this method. Well. As you mentioned, using JTAG we can put bin in any place of flash. Does it means we should manually set the last-4-bytes? How to determine
Urgh. No, of course not. You just program the "u-boot.bin" image to the last 256 kB of your flash memory, as Stefan already explained.
Last, let me tell you why I cannot use JTAG. The recommend method by u-boot is using BDI2000. But it is really expensive. I don't have enough money. hehe. I have tried many home-made wiggler JTAG connectors with OCD commander, but all failed. Finally I give up for finding low-cost PPC JTAG. Currently I give the precompiled bin to some one with special flash writer, and let them burn.
You will reconsider buying a BDI3000 when you need a debugger...
Best regards,
Wolfgang Denk
On Friday 16 May 2008, 甜瓜 wrote:
All Walnut boards have 512k of NOR FLASH. Do you really have an original IBM/AMCC Walnut or a different custom 405GP board?
Yes, my board is a custom board DHT-Walut with 32MB SDRAM and 512k of boot flash AMD 29LV040B. Details are listed in: http://elinux.org/DHT-Walnut
OK.
I wonder how to build a 512KB bin?
Generally this is possible. You need to change CONFIG_MONITOR_LEN & CFG_MONITOR_BASE in include/configs/walnut.h. And TEXT_BASE in board/amcc/walnut/config.mk.
Thank you very much. That's exact what I need!
Noooo! Please wait.
Is there any OPTION/SETTING targeting this problem? Anything else I should take care?
But please don't forget that the environment is also stored in the NOR FLASH. And by changing the U-Boot size to 512k you leave no space for the environment.
Do you mean that environment settings (eg: ip_addr, ethaddr...) are stored sperately from the bin?
Most of the boards do it this way, yes.
In my mind (with guess :p), env should be defined in bin code or data section, and it will be compiled together with other codes to form a single bin.
This can be done too. But its not the case on Walnut.
So why exactly do you want to change the U-Boot image size?
Well. The reason is:
- Both default config of u-boot and a DHT-Walut-patched config
generate 256KB bin, but the flash on board is 512KB. So I think I should get a 512KB bin for flash writing.
No. You definitely don't need a 512k image for this setup. You just need to flash the image at the "end" of the FLASH chip. So starting at 256k:
0...256k: Free and environment 256k...512k: U-Boot image
- The contents in the flash on my board is totally corrupted by
accident. It means the important last-4-bytes should be rewritten to a proper state. 3. Currenly, I have to use special hardware to write bin into flash. Therefore 256KB bin will only overwrite the first half. The last-4-bytes in the end of flash is still the old value. Booting will definitely fail.
See above. Don't increase the image size, but flash it with an offset of 256k.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
participants (3)
-
Stefan Roese -
Wolfgang Denk -
甜瓜