I’m trying to build a ubootV2 that has a few more functions that the one that is in the default config that Nishanth put together here:
http://nishanthmenon.blogspot.com/2008/12/towards-creating-beagleboard-nand.html
I’ve successfully sent his tiny ubootV2 (28K) via the “pusb” tool to the beagle and had it work to kermit down ubootV1, so that part seems to be working. But I’d like to skip the secondary step, and just have more commands in the initial ubootV2. I’d especially like to get nand commands working.
I can build an image that is less than 64K (barely), but when I send it down via pusb, I get an error. It detects the beagleboard (“Hoorrah!!! found!!!” message), and starts sending data, but I get an error:
send_file:371:DDump:Expected to write 4096, actual write -19 No such device
I’m guessing that even though the OMAP has 64K of on-chip ram, using all of it for the loader is a bad idea, and at some point I’m overwriting some stack space or something else the ROM loader is using.
Does anyone know the absolute maximum size of an app that can be pushed down via the ROM Loader?
Thanks,
Brett
Hi Brett,
I'm trying to build a ubootV2 that has a few more functions that the one
that is in the default config that Nishanth put together here:
Nishanth' tech rambles: Towards creating a beagleboard NAND recovery script
Cool.. glad to see it of use 
I've successfully sent his tiny ubootV2 (28K) via the "pusb" tool to the
beagle and had it work to kermit down ubootV1, so that part seems to be
working. But I'd like to skip the secondary step, and just have more
commands in the initial ubootV2. I'd especially like to get nand commands
working.
we can.. only thing is that the written image should be page aligned
for ecc handling to work properly.. i had written an align app to do
just that.. never pushed to u-boot-utils.. since i never got flashing
from u-boot-v2 working fine.. i hit a bad block handling bug in
u-boot-v2.. 
I can build an image that is less than 64K (barely), but when I send it down
via pusb, I get an error. It detects the beagleboard ("Hoorrah!!! found!!!"
message), and starts sending data, but I get an error:
send_file:371:DDump:Expected to write 4096, actual write -19 No such device
I think you might be overwriting the interrupt vectors on the higher end sram..
I had a defconfig on my home machine somewhere (gotta look it up)
which kind of reduced image size to around 56 odd k, however ran into
an nand erase bug.. I can try and duplicate my results over the
weekend..
I'm guessing that even though the OMAP has 64K of on-chip ram, using all of
it for the loader is a bad idea, and at some point I'm overwriting some
stack space or something else the ROM loader is using.
Does anyone know the absolute maximum size of an app that can be pushed down
via the ROM Loader?
yep, as explained above - i think 60K might be a safe limit -
u-boot-v2 uses sdram for stack and heap - so you should not have an
issue with that.
Regards,
Nishanth Menon
>
> I've successfully sent his tiny ubootV2 (28K) via the "pusb" tool to the
> beagle and had it work to kermit down ubootV1, so that part seems to be
> working. But I'd like to skip the secondary step, and just have more
> commands in the initial ubootV2. I'd especially like to get nand commands
> working.
we can.. only thing is that the written image should be page aligned
for ecc handling to work properly.. i had written an align app to do
just that.. never pushed to u-boot-utils.. since i never got flashing
from u-boot-v2 working fine.. i hit a bad block handling bug in
u-boot-v2..
Well, I'll give it a try, though I'm not sure I'll make much progress. I'm doing some coding for a beagle-derivative board that does not have an MMC slot, so I need to get the code onto it, preferably without having to use JTAG to write to flash.
>
> I can build an image that is less than 64K (barely), but when I send it down
> via pusb, I get an error. It detects the beagleboard ("Hoorrah!!! found!!!"
> message), and starts sending data, but I get an error:
> send_file:371:DDump:Expected to write 4096, actual write -19 No such device
I think you might be overwriting the interrupt vectors on the higher end sram..
I had a defconfig on my home machine somewhere (gotta look it up)
which kind of reduced image size to around 56 odd k, however ran into
an nand erase bug.. I can try and duplicate my results over the
weekend..
I'd appreciate any help you can give.
>
> I'm guessing that even though the OMAP has 64K of on-chip ram, using all of
> it for the loader is a bad idea, and at some point I'm overwriting some
> stack space or something else the ROM loader is using.
>
> Does anyone know the absolute maximum size of an app that can be pushed down
> via the ROM Loader?
yep, as explained above - i think 60K might be a safe limit -
u-boot-v2 uses sdram for stack and heap - so you should not have an
issue with that.
That's good to know. I'll see if I can trim things down and get it to at least load the code, even if it doesn't update flash yet. Thanks for the info.
Brett
Nishanth Menon said the following on 01/20/2009 07:37 PM:
I can build an image that is less than 64K (barely), but when I send it down
via pusb, I get an error. It detects the beagleboard ("Hoorrah!!! found!!!"
message), and starts sending data, but I get an error:
send_file:371:DDump:Expected to write 4096, actual write -19 No such device
I think you might be overwriting the interrupt vectors on the higher end sram..
I had a defconfig on my home machine somewhere (gotta look it up)
which kind of reduced image size to around 56 odd k, however ran into
an nand erase bug.. I can try and duplicate my results over the
weekend..
Apologies, but it's been a while since I played around with u-boot-v2. Looking at addition by mtd layer, it is around 20 odd K of extra size... adding loadb seems to kick it off the 64k radar
the changes I did was for nand boot.. attached patch for the same.. (in the hope that i could use this to replace x-loader :D)..
a) with a minimal "nand support" (just erase,write): 63160 bytes (nand-minimal.defconfig)
b) "x-loader" like image 59000 bytes (nand-xload.defconfig - needs bootable patch - attached)
c) peripheral mode bootloader 38960bytes(arch/arm/configs/omap3530_beagle_per_uart_defconfig) -just loadb support
Looking at size usage of nand addition:
arm-none-eabi-size drivers/nand/*.o
text data bss dec hex filename
25027 2868 0 27895 6cf7 drivers/nand/built-in.o
13998 984 0 14982 3a86 drivers/nand/nand_base.o
6729 492 0 7221 1c35 drivers/nand/nand_bbt.o
804 0 0 804 324 drivers/nand/nand_ecc.o
821 1184 0 2005 7d5 drivers/nand/nand_ids.o
911 104 0 1015 3f7 drivers/nand/nand.o
1764 104 0 1868 74c drivers/nand/nand_omap_gpmc.o
kind of a big chunk of nand_base.... enabling loadb adds a little more..
arm-none-eabi-size commands/loadb.o
text data bss dec hex filename
3482 0 95 3577 df9 commands/loadb.o
forcing the net result to reach 67336 bytes..
short story -> in the current nand_base configuration, we probably will find 64k limit tight.. we should probably discuss this on u-boot mailing list with sascha hauer on optional strategies we might like to follow.. (there are modules that we could enable in u-boot - but it ends up enabling all symbols and resultant binary is bloated..
Regards,
Nishanth Menon
files.tgz (3.63 KB)