Rockbox mail archive
Subject: Re: Need help with UART boot
From: Andreas Stemmer (groovingandi_at_gmx.de)
> > > Don't forget to patch in your h/w mask, 2 bytes at offset 0xFC and
> > > else you may get some funny behaviour.
> > Ah, good to know. I thought your uart_boot program would handle that.
> No, the tool is very basic and powerful. A hacker tool, not intended for a
> wide audience. It just flashes what you give it, no more, no less. For
> example, how should it know the mask value if you just soldered in a blank
Good point. But the hardware mask value was already the right one.
> > Yes,
> > uart_boot -p COM1 -r -f firmware_rec.bin
> > followed by
> > uart_boot -p COM1 -r -d firmware_dump.bin
> > results in a firmware_dump.bin file which is completely different from
> > firmware_rec.bin
> This indeed should not happen. Do you see a pattern for the differences?
> Like, failed to set the bits high or low.
> You could do some testing with a file that contains all 0 or all 0xFF.
I tried erasing the flash (by giving uart_boot a zero byte file) and I got
only 0xFF afterwards, as expected. I can successfully flash files containing
only 0x00, 0xFF, 0x55. One thing I noticed: Why does the uart_boot tool
return a 512kb flash dump? The flash chip is supposed to have 256k x 8 =
256kb, or am I wrong?
For my tests, I replaced the whole content of firmware_rec.bin with 0x55,
resulting in a 178.134 byte file. I flashed it and dumped the contents of
the flash chip afterwards. The dump file contains 512kb of 0x55! Strange?
If I try to flash sensible data, like firmware_rec.bin, I still get complete
garbage, but I'll try to find out the system. So far, I have the impression
that all 0x00 bytes are flashed correctly, but not the rest...
> How is your new chip exactly called? Maybe it's not really compatible to
> our bus.
It's a SST39VF020, should be the right one I hope.
Page was last modified "Jan 10 2012" The Rockbox Crew