dpf-ax Bug report - Flashing of splash image

./setsplash.sh ~/rainbow.jpg 128 128 usb0
Using ffmpeg pix_fmt rgb565be
Splashfile saved to /root/rainbow.128x128.rgb
Sending splashfile /root/rainbow.128x128.rgb to flash...
Found AX206 DPF
Got LCD dimensions: 128x128
offset: 0x30000
Erasing sector at 0x030000...
Flashing sector at 0x030000...
bulk write: Resource temporarily unavailable

The bulk write error will occur. Is this due to some code in lcdinit.s/lcdblit.s or something entirely? lcd4linux and other programs work normally. I will see most parts of the rainbow image on the frame after that.

It's normally a sign of bad USB connection.
Please try another (high quality) USB cabel, change USB port, etc.
Does "Resource temporarily unavailable" happen consistently at the same point?
As you can see in "splash2flash.py" it uses the same dpflib calls as restore.py, hackit.py, etc., so: nothing special here.

Btw: is lcd4linux running/accessing the display while you try to flash the image? There is no check for concurrent access in either dpflib nor splash2flash. It simply assumes you know what you are doing. :-)

superelchi

superelchi Wrote:
-------------------------------------------------------
> It's normally a sign of bad USB connection.
> Please try another (high quality) USB cabel,
> change USB port, etc.
> Does "Resource temporarily unavailable" happen
> consistently at the same point?

Yes, at the same point. I have tried different ports, different cables and it is the same error. It is just a minor nuisance so I guess I will leave it as it is. The bad connection didn't seem to affect the flashing of the firmware? It only affected the flashing of splash screen...

python restore.py full.bin -f
Found AX206 DPF (bootloader)
Manufacturer: Macronix
Size        : 2 MB
Erase full flash...
Flashing sector 0...
Flashing sector 1...
Flashing sector 2...
Flashing sector 3...
Flashing sector 4...
Flashing sector 5...
Flashing sector 6...
Flashing sector 7...
Flashing sector 8...
Flashing sector 9...
Flashing sector 10...
Flashing sector 11...
Flashing sector 12...
Flashing sector 13...
Flashing sector 14...
Flashing sector 15...
Flashing sector 16...
Flashing sector 17...
Flashing sector 18...
Flashing sector 19...
Flashing sector 20...
Flashing sector 21...
Flashing sector 22...
Flashing sector 23...
Flashing sector 24...
Flashing sector 25...
Flashing sector 26...
Flashing sector 27...
Flashing sector 28...
Flashing sector 29...
Flashing sector 30...
Flashing sector 31...
Executing applet..

Okay. So maybe it's you flash chip.
Some questions / homework:

Could you post the dump of the original fw?
Did you flash the fw_disp with restore.py or ProgSPI?
What type of flash does ProgSPI detect?
What type of flash does fw_disp detect (Menu->Info-Flash)?

Another way to use a custom splash would be to copy your rgb-image to the src/res folder, overwriting the existing default splash and building the fw. E.g. for a 128x128 dpf the name of the rgb-image must be "splash.128x128.rgb".

superelchi

1. Uploaded firmware
2. I flashed with restore.py, I seldom boot to Windows :)
3. m25p16
4. I will try the src/res method and report back.
5. src/res method works, no errors.



Edited 1 time(s). Last edit at 07/03/2012 09:00AM by ax206geek.

Please do me a favour - boot to Windows. :-)
I need the flash id from ProgSPI...

superelchi

Flash ID: MX25L1605A