SDG800 recovering from a hosed u-boot
I managed to hose the u-boot on my SDG-805. It’s actually pretty easy to do as if you put an SD in the internal slot and boot the device it’ll hose the whole flash before looking for an updated u-boot on the SD card and failing to find it.
I tried to build a new u-boot from source, but was unable to get it working. My notes on this are at the end of the post. I asked around looking for someone who might have extract them from the Siglent firmware update images and janekivi on the eevblog forums really made my day my posting some image dumps (thanks janekivi!).
This wasn’t quite the end of the road, the image dump contains u-boot however the SPL is in MLO format. The MLO files have a “GP header” prepended to the file. Looking at the filesizes I figured out this was a 520 byte header and stripped it off.
The spl can now be sent over xmodem (I used minicom 115200 8N1). Once you’ve send the spl you can then send the uboot.img using ymodem and are greeted with the uboot prompt. Yay! From here I’ll need to restore the internal flash bit by bit. But this should be relatively easy. Here are the files that worked for me:
Once booted you can write the spl and uboot to NAND flash as follows:
# U-boot SPL and GP header
loady (then send MLO)
nand erase 0 100000
nand write 0x82000000 0 100000
# U-boot
loady (then send uboot_working.img)
nand erase 0x80000 1000000
nand write 0x82000000 0x80000 1000000
This was enough to get me to a working u-boot prompt on the device, you need to mash the keyboard at boot or it’ll try and load the system image. Next I’ve tried upload the kernel and rootfs:
# uImage
loady (send uImage)
nand erase 0x3080000 2875392
nand write 0x82000000 0x3080000 2875392
# rootfs
loady (send rootfs.img)
nand erase 0x580000 0x980000
nand write 0x82000000 0x580000 0x980000
# Datafs
loady (send datafs.img)
nand erase 0x9a80000 0x6580000
nand write 0x82000000 0x9a80000 0x6580000
The system will now boot to a bash prompt. The GUI should also load (note previous version said it didn’t but the ribbon cable wasn’t connected that’s all!). Interestingly, after all this the device still seems to know it’s a SDG805. Either that or it’s falling back to a 5MHz limit. I see reference to an SPI EEPROM, so I guess it’s possible there’s one on the board somewhere (I think more likely it’s just reverting to 5MHz as the firmware0/1 partition is missing).
After this process I decided up upgrade to the latest version using SDG800 V100R008B01D01P12R2.ADS. Along the way I also upgraded it to an SDG830…
Before I ran the update, using the shell available when the above files are flash I changed the characters that read SDG805 to SDG830 in sys_info (which is knocking around in the root file system). While this didn’t upgrade the unit, I think it must have used them when it recreated the firmware1 partition. I have full flash dumps in the next blog post, you’re welcome to use them.
By updating to the latest version you lose the shell that’s present in the above files, as the login shell now loads instead.
NOTES ON XMODEM FAIL: Note, if you flash the spl file, the SDG800 will fail to boot, and will no longer accept an SPL over xmodem. I think the TI ROM detects a blank flash and only enters this recover mode then. If you short out pins (I think 9 and 10? around here anyway) on the flash IC while powering up the system you can get the device to error out into recover mode again and upload over xmodem as before.
U-boot build notes
I wasn’t able to get u-boot working. Siglent also refused to send me their modified source (which they are legally required to do as it’s GPL). I think it’s mostly likely and issue with the DDR memory. I used the u-boot source included in the TI SDK for the AM335x processors. Then followed the guide for configuring the DDR for the k4b1g164gg used in my SDG800 (I believe it varies from model to model). The K4B1G164GG is very similar to a part that’s already in ddr_config.h so I copied those settings. I also modified the code so it would bring up the TPS65910 PMIC. This PMIC is controlled over I2C.
The TI SDK u-boot source contains a bunch of beaglebone and TI EVM specific stuff. In particular it checks for settings from an on board EEPROM. I commented this could out so it would setup the TPS65910. It also brings up a GPIO pin which is commented as enabling the DDR memory. This worries me, and I’m guessing it might be why my u-boot doesn’t work, it’s possible the Siglent used a different GPIO pin to enable the DDR memory (or some other required part of the system) on their board. Anyway, hopefully those notes might be of use to someone else trying to get a source built Uboot up.
Other notes:
Nice notes in russian: http://tqfp.org/webkirov/obzor-siglent-sdg805.html
DDR Memory datasheets:
DS_K4B2G1646Q-BY_Rev101 (config already present in ddr_config.h)
K4B1G0446C_datasheet (used in this device)
Flash: 29f2g08abaea (NAND)
Partition layout (from previous kernel output at boot):
Creating 12 MTD partitions on “omap2-nand.0”:
[ 1.175373] 0x000000000000-0x000000020000 : “SPL”
[ 1.181701] 0x000000020000-0x000000040000 : “SPL.backup1”
[ 1.188660] 0x000000040000-0x000000060000 : “SPL.backup2”
[ 1.195612] 0x000000060000-0x000000080000 : “SPL.backup3”
[ 1.202551] 0x000000080000-0x000000260000 : “U-Boot”
[ 1.209661] 0x000000260000-0x000000280000 : “U-Boot Env”
[ 1.216451] 0x000000280000-0x000000580000 : “Manufacturedata”
[ 1.224889] 0x000000580000-0x000003080000 : “rootfs”
[ 1.249110] 0x000003080000-0x000003680000 : “kerneldata”
[ 1.258369] 0x000003680000-0x000006880000 : “firmdata0”
[ 1.285793] 0x000006880000-0x000009a80000 : “firmdata1”
[ 1.313229] 0x000009a80000-0x000010000000 : “datafs”
RSS