Another interesting thing I noticed is that the older U-Boot can't cope with data being pasted into the terminal whereas the newer versions can.

I don't have an ICEbear. It was your post I was referring to at the end of my first post. I have only tried this newer U-Boot temporarily with...

tftp 0x1000000 u-boot.bin
go 0x1000000

This page tells me that I can write it permamently to the EEPROM like this...

tftp 0x1000000 u-boot.ldr
eeprom write 0x1000000 0x0 $(filesize)

I don't think this requires an ICEbear, right? I am very new to this but my understanding was that serenissimo couldn't use this method because he set bootdelay to 0.

I think that perhaps you are confusing the serial console with the JTAG. The Blackfin JTAG is a debugging interface that can also be used to load the u-boot. Once the u-boot has been loaded you can then use the serial console to load the software image via tftp.

Given that the IP02 does not have a JTAG interface if something goes wrong with the u-boot upgrade you will have totally bricked your IP02. As I understand it the only way to recover from this would be to unsolder the SPI flash chip, reprogram it using a programmer and then resolder it. Personally I question the logic of omitting the JTAG connector.

So before you attempt to upgrade the u-boot I'd wait for one of the gurus to provide you with the definitive step by step upgrade instructions as you'll only get one chance to get this right..

Andy

Hi Guys,

Yes Atcom did very good job updating the uboot.

In Switchfin we are using U-Boot 1.1.5 sources. At the time we have started BF1 project (few years ago) u-boot had no dm9000 support. Ivan Danov colleague of mine has integrated the dm9000 driver in u-boot 1.1.5. Since then we are using this version unchanged.
From what I see now the recent u-boot has dm9000 support and we can easily  migrate to it as Atcom has done.

The new u-boot has lot of good things and indeed is quicker.
For those with an old u-boot we recommend for now to tftp/eeprom the uboot image (from Atcom web site) as it was mentioned before in this thread

Best regards
Dimitar

Hi James,

Thanks for the uboot patch.
Yes I'll fix it for the other targets.

In some of the new nand flash chips they have expanded the Out Of Band (OOB) area to 128 bits. Not sure you are talking about this?

Best Regards
Dimitar

No reply yet from David Rowe. I have made an interesting discovery though.

First I noticed that the mtd1 "boot loader(spi)" partition in /proc/mtd is actually 128KB. That got me thinking that maybe the binary does need to be smaller.

But then I copied /dev/mtd1 and /dev/mtd2 from the box with the newer U-Boot and found that this U-Boot binary actually straddles the partition boundary. It was easy to see because this part of the binary holds the string messages and one of the messages was cut in half by the boundary. Maybe the binary doesn't need to be less than 128KB after all.

I'm not sure what the mtd2 "linux kernel(spi)" partition is supposed to be for. I guess some space is needed to hold the U-Boot environment variables but 384KB seems a bit much. I know that this partition table isn't actually read from the SPI but is hardcoded in package/uClinux-dist/vendors/Rowetel/IP04/pre_config/ip04.c, which explains why it doesn't match what I'm finding on this box. I think the table is only used by the flashupdate script to update U-Boot. I doubt it would allow you to write a file larger than 128KB but if it did, it would probably get truncated and then you'd be in real trouble. It would probably be safer to simply present the SPI as one 512KB partition rather than make assumptions about the size of U-Boot.

I also noticed that this hardcoded partition table depends on CONFIG_MTD_M25P80, which is enabled for the IP04. My IP02s actually don't have this SPI. They have the Winbond W25X40 as I mentioned above. I don't think this is specific to the IP02. Maybe ATCOM simply started using a different SPI. Evidently it is still able to read the data anyway so maybe this isn't really an issue.

If there was a size difference then I think autodetection would be important. I see that you're right about the M25P80 being 8Mbit/1Mbyte but the hardcoded partition table only covers 512KB. Maybe only half of it was used? That would explain why they switched to a different one.

admin wrote:

Currently in Switchfin we don't mount those partitions for something useful.

#define CONFIG_ENV_OFFSET       0x30000

#define CONFIG_ENV_SIZE         0x10000

I think this means it will store an environment of size 64KB at offset 192KB. Presumably this means that the U-Boot binary can be up to 192KB. But I still don't want to test that theory in a hurry! Still no word from David. Does he usually reply to such e-mails?

admin wrote:

At the moment the uboot environment is in the second spi partition at offset 0x10000.

Hi James,

Very good news!
Currently I am kind of a busy with other things but I will try to put your changes in Switchfin and will test with other targets as soon as possible.

Cheers
Dimitar