Guys,The normal story here. I have a M001 which has been bricked during a firmware upgrade process.I've connected up the console port to find out that it's dead as a door nail. Some people here have found that w-load is present, but U-Boot is missing (corrupt). In my case, w-load doesn't appear to be there either. I've had a cro on the console TXD pin (and RXD), and it doesn't appear to do anything, suggesting its not a baud rate problem, or one with my hardware (using a FT232R FTDI cable).From looking at some console logs posted, and the M001 boards, it appears there is two FLASH memory parts. There is a cFeon F40-100GCP SPI Serial Flash on the CPU Daughtercard (SO8) and a TSSOP parallel flash on the back of the main motherboard.It would also appear the WM8505 is bootstrapped to boot from the SPI serial flash after looking at console logs and the MTD partitions. There appears to be no MTD partition for w-load on the SAMSUNG_K9XXG08UXM parallel flash, only the SPI Flash.I've desoldered the SPI serial flash from the CPU DaughterCard. It has markings "cFeonF40-100GCP" and would appear to be a 4 Mbit Serial Flash from EON (EN25F40-100GCP, 100MHz, 8 pin 150mil SOP, Commercial Temp, Lead Free) part.I've been unable to talk to it properly. It is not responding correctly when I issue the Read Identification command, in fact it responds with 0x00 for all commands. I was hoping on reading the contents to get an understanding on where the firmware upgrade failed.I've got a replacement ATMEL 4 Mbit SPI Flash part (which works) and I now want to program w-load and u-boot onto it, and solder it back onto the CPU daughtercard and see what happens.However my problem is the partitioning. I believe its a 4 Mbit part (524,288 bytes) but the MTD table for the SPI Flash reports 16Mbytes :Creating 6 MTD partitions on "mtdsf device": (16,777,216 bytes)0x000000000000-0x000000d00000 : "filesystem-SF" (13,631,488 bytes)0x000000d00000-0x000000f80000 : "kernel-SF" (2,621,440 bytes)0x000000f80000-0x000000fd0000 : "u-boot-SF" (327,680 bytes)0x000000fd0000-0x000000fe0000 : "u-boot env. cfg. 1-SF" (65,636 bytes)0x000000fe0000-0x000000ff0000 : "u-boot env. cfg. 2-SF" (65,536 bytes)0x000000ff0000-0x000001000000 : "w-load-SF" (65,536 bytes)Is it possible to dump the raw contents of the serial flash if so, can someone provide it as a bin file?Otherwise, does anyone know how the serial flash is formatted? At what offset is w-load?
Re-programing SPI Serial FLASH on CPU Daughtercard (De-bricking)
1 - 20 of 234 Posts
I'm sure there is someone on here who could talk to you about that advanced stuff, but I think most of us are nowhere near your level of expertise. I don't know if this site would be helpful to you, but they seem to be doing similar things...Forum: Bootloader - FriendlyARM
[quote name='cpeacock;51026]Otherwise' date=' does anyone know how the serial flash is formatted? At what offset is w-load?[/QUOTE'] I believe I have sussed it out.After consulting some documentation, it would appear the WM8505 vectors to SPI Start Addr (0xFF80 0000) + size of flash (4MB = 0x80 0000) - one sector (0x10 0000) = 0xFF87 0000.Hence w-load sits it the last sector of the SPI Flash. Immediately before it is one sector for u-boot env. cfg. 2, one sector for u-boot env. cfg. 1 and then five sectors for u-boot.Hence the memory map for a 4Mb (512kbyte) SPI Flash looks like :0x70000 w-load0x60000 u-boot env. cfg. 20x50000 u-boot env. cfg. 10x00000 u-bootI'm just about to program my new Atmel SPI Flash with w-load and u-boot at the locations above, then I'll solder it back on the CPU daughtercard and see what happens . . . .
Joined
·
255 Posts
cpeacock - well done on working that out. I'm interested to hear if it works with the alternate SPI flash. I'm guessing you don't have a logic analyser or other device handy to sniff the SPI bus and work out what the arrangement with the original SPI flash is?[quote name='tlo;51544]Why do they have to make getting a bootloader back on these things so difficult?[/QUOTE]The problem is really one step earlier. Why do the firmware authors insist on reflashing the complete bootloader with each firmware upgrade? AFAIK nothing has ever changed in u-boot' date=' but each firmware update erases and then recreates it - creating a window of opportunity for bricking. I don't see any reason for doing it that way.(On a vaguely related note, I put out a [URL=http://www.slatedroid.com/eken-m001-android-tablet-discussion/6166-wtd-dead-eken-daughterboard-experiment-common-good.html']call for a sacrifical dead board donation[/URL] last week to desolder the BGA and see if the JTAG interface goes anywhere on the board. It's a long shot, but it might make debricking slightly less impossible.
I have just prepared a binary image with w-load and uboot and programmed my Atmel SPI flash part. I get reunited with the M001 tomorrow morning, so I'll have to keep everyone in suspense to then 
What I haven't programmed is the two u-boot configuration spaces. I've just zero'ed the memory in those two sectors.w-load should come up (it doesn't have any configuration), and it should spawn u-boot. I'm hoping this is enough for it to start reading from SDcard and to recover. If not, I might have to get a copy of the u-boot config sectors, or script the creation of the environment variables in order to recover Android.I do have a logic analyser/mixed signal CRO here, I'm just more time poor than resource poor
![]()
If it fails to load w-load tomorrow, I might whack it up on the MSO and have an attempt to decode the serial flash commands and addresses.I had a colleague probe for JTAG pins. We have the BGA pin out, and from memory they are in one corner, and not that many rows deep. We were hoping they were brought out to the daughter card edge connector or test points, but we no longer believe that is the case, hence the reason why we have decided to pull the SPI flash off and tackle the problem that way.
What I haven't programmed is the two u-boot configuration spaces. I've just zero'ed the memory in those two sectors.w-load should come up (it doesn't have any configuration), and it should spawn u-boot. I'm hoping this is enough for it to start reading from SDcard and to recover. If not, I might have to get a copy of the u-boot config sectors, or script the creation of the environment variables in order to recover Android.I do have a logic analyser/mixed signal CRO here, I'm just more time poor than resource poor
Joined
·
255 Posts
[quote name='cpeacock;51994]I had a colleague probe for JTAG pins. We have the BGA pin out' date=' and from memory they are in one corner, and not that many rows deep. We were hoping they were brought out to the daughter card edge connector or test points, but we no longer believe that is the case[/QUOTE'] That's correct about the pinout, and I think you're probably right that they're not available anywhere. However, I figure the only way to be completely sure would be pull the BGA off and look at which balls are connected, and buzz them out if necessary.Congratulations again on your efforts with the SPI flash, and thanks for publishing them. Please let us know what comes of it.
![]()
.
PG, I had read your post on your blog last week that part of the problem was reinstalling u-boot with each firmware upgrade and didn't want to bring it up here, but was a bit disappointed to know that was part of the problem. Also read a guy's post on the development section of this site indicating the way around that, so hopefully that will get worked out with people rehashing firmware upgrades. Nonetheless, as always, we all take our chances with these things, so have to accept it as our own mistake. This is the first device I have ever truly bricked. But I am so used to just messing around with Linux on laptops and PCs and it was never a problem just starting from scratch when things screwed up. Took me a week to accept that it really was bricked.Will keep in mind your call for a bricked m001, but still holding out that tiny bit of hope for now and may want to follow and learn to see if I could figure out some of what you smarter cats are doing. One thing I don't understand is when they build these things in the factory, do they put the u-boot, etc on the NAND and/or daughter board before they put them in the device or do they build them first and flash them another way? Hope that question makes sense.
All fixed!I have soldered down my new pre-programmed Amtel SPI Flash and turned on the power to the M001. It immediately started booting w-load which then spawned u-boot and stopped as expected reporting Warning - bad CRC, using default environment (I had zeroed the two config spaces)
At this stage I inserted a SDcard with the firmware on, rebooted and off she went . . The M001 reflashed, fixing the config space problems and then booted up to Android.
Code:
WonderMedia Technologies, Inc.W-Load Version : 0.17.00.01W-Load loading...U-Boot 1.1.4 (Apr 26 2010 - 20:48:31)WonderMedia Technologies, Inc.WMT U-Boot Version : 0.12.01.00.16U-Boot code: 03F80000 -> 03FB8134 BSS: -> 04006544RAM [URL=Configuration:Bank]Configuration:Bank[/URL] #0: 00000000 128 MBboot from spi flash.flash: Bank1: FF800000 -- FFFFFFFF Bank2: FF000000 -- FF7FFFFFFlash: 16 MB*** Warning - bad CRC, using default environmentIn: serialOut: serialErr: serial### main_loop entered: bootdelay=3### main_loop: bootcmd="cp.b ff200000 01000000 $(rootfs_size); bootm ff000000"Hit any key to stop autoboot: 3 2 1 0 ATSMB Host 390KHz SD Card is not [URL=insertedUsage:cp]insertedUsage:cp[/URL] - memory copy## Booting image at ff000000 ...Bad Magic NumberWMT #If you have the ability to desolder (SO8 package) and reprogram the SPI flash, then here is the procedure I used to recover the M001.1. Desolder the existing SPI Flash (U4) on the BGA side of the CPU Daughter Card. It is a SO8 package and should be an EN25F40-100GCP part. To desolder you will probably need hot tweezers (my preference) or hot air (be careful not to reflow and move the passive components around it).2. Reprogram it with the following file :http://www.beyondlogic.org/wp/4Mb_spi_flash.zip(it contains w-load version 0.17.00.01 & U-Boot 1.1.4 (Apr 26 2010 - 20:48:31) / WMT U-Boot Version : 0.12.01.00.16, with zeroed config spaces)If your SPI flash doesn't reprogram, purchase a new part. I brought an Atmel AT25DF041A-SSH-B from Farnell #171-5441. (The jury is still out on if it was a hardware issue with the Flash. In my case, neither w-load nor u-boot would load. To date, I have been unable to reprogram the EN25F40) If w-load boots, but u-boot is not spawn, then it's probable your SPI flash device is fine and it was a software issue.3. Solder in place your newly programmed SPI Flash.4. Insert SDcard with firmware image.5. Turn on the power to the M001 and hopefully u-boot will execute, see your SDcard, reload the firmware, ask you to remove the SDcard, then reboot your M001 back to its former glory.Good Luck.
Joined
·
57 Posts
Uuuuhhh, a cheap piece of hardware! 859,00 euro, plus VAT!!!At this price, i prefer throw away my bricked one, and buy a new SuperStar Interstellar DeLuxe Forever China-Tablet, with Topless Girlie for freeStockmann;52543 said:
I congratulate you for what you did it!, I have a problem that many people have suffered in this forum that the M001 does not charge any firmware since the u-boot is damaged after you upgrade, you with your great knowledge would appreciate if you could guide me in the repair or if you could publish a guide on how to repair it.I did the translation on google, sorry: (
sorry......... the copy, paste didnt work and I have seen it right now.SPI FLASH PROGRAMMER AMBIT 256 / AMBIT 300 MX25L (UK) en venta en eBay.es (finaliza el 12-sep-10 16:03:58 H.Esp)Do you think this programmer could work? do you have any schematics of programmer to make it at home?Thanks again!
Can i use this chip for reprogramming?Microship 25LC256Here is the link to the datasheet:http://www.reichelt.de/?;ACTION=7;L...wQARkAACKQT1Ic32ae73bcaed1ec9338bae8cbe58dc2c
Wrong size. The chip you linked is a 256Kbit (32Kbyte) and supports a maximum clock speed of 10MHz.You need a 4Mbit (256Kbyte) that supports up to 100MHz - at least that's the specification of the EN25F40 which you are trying to replace.I checked for Reichelt, they don't have what you're looking for.25LC512 is close, but doesn't support the correct speed (will affect write/read time and, depending on the way things work in the M001, may mess things up) and doesn't have the correct page size either.While looking for a replacement, watch out for:- voltage range: 2.7-3.6V (or 1.8-5.5V)- size: 4Mbit / 512Kbyte- page size: 256 bytes- clock: 100MHz (the OP- eventually: temperature range (-40?...85? is sufficient)compare to the Atmel AT25DF041A-SSH-B the OP used:2.3V - 3.6V or 2.7V - 3.6V4MbitByte/Page Program: (1 to 256 Bytes)70 MHz Maximum Clock Frequency
1 - 20 of 234 Posts
Join the discussion
