OMG I think Ive Killed it!!!!

[leeb]

As of 2350 connector is attached, continuity checks completed and satisfactory.

At 0040, Stragulus v5 system successfully reinstalled.

At 0050, Touchscreen calibration successful, system restarted, date/time/wifi configured, weather data adjusted for Palm Springs CA.

Tomorrow I will begin removal of the current NAND and prepare for install of replacement.

 

[leeb]

As of 1700 the NAND replacement surgery is complete.

There seems to be NO shorts/solder bridges and
the device starts up with the INFOTMIC logo as expected.
Connection to USB-based IUS successful.
Device recognizes and starts SD-based IUS installation.
U0 installs and updates correctly.

The bad news...

U0 installs... u-boot does not. This is somewhat confusing as I thought u-boot was maintained in the NOR-flash. Booting of the U0 portion suggests that the NOR flash has not been adversely affected.

It is likely that the issue may be the 'lack of format' or possibly an incompatible format' on the replacement NAND...

I do NOT consider this a 'brick'... right now. I have found what appears to be a connectable TX/RX pair on the board... these may be a way to get in and test/prepare/clean/etc the NAND, and I will look into this soon.

For now, of course, the original tablet (currently running with limited storage) will remain unaltered.

Report ends 1740.

 

[leeb]

Here is what I have been able to get out of the 'new nand' tablet so far!

U-Boot 2009.08-svn587 (Jan 05 2011 - 07:20:58)Shanghai InfoTM Microelectronics Co., Ltd.

Memory type: DDRII 256 MB, E1111121112141412
***
NAND: AC95nand_get_flash_type: second ID read did not match ac,95 against 3b,3b
No NAND device found!!!
***
Using embedded environment.
Battery: 603
, AdapterIn: 0
Console devices(i/o/e): serial, serial, serial
SD driver using: IMAP_SDHCI(0)
Ethernet driver using: GMAC
Try booting from SD ...
MMC read: dev # 0, block # 1024, count 8 ...
SDHCI: Searching for SD ...
Invalid boot SD!
Boot status: U0!
Hit any key to stop autoboot:  0

Checking recovery key state ...
get boot para 7: 0xbdbeed01
Try load Image from NAND...
Read exceed NAND size!
Wrong NAND Image type!
Image is demaged, try to recover...
Read exceed NAND size!
Wrong NAND Image type!
Booting linux(normal) ...
Try load Image from NAND...
Read exceed NAND size!
Wrong NAND Image type!
Image is demaged, try to recover...
Read exceed NAND size!
Wrong NAND Image type!
Wrong Image Format for bootm command
ERROR: can't get kernel image!

[4. LookingForGroup]: ?
?       - alias for 'help'

adr     - adr (OEM implanted image burnning tool.)
autoscr - DEPRECATED - use "source" command instead
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootl   - Boot pre-burned linux.
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
cls     - clear screen
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dcache  - enable or disable data cache
echo    - echo args to console
exit    - exit script
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
go      - start application at address 'addr'
help    - print online help
icache  - enable or disable instruction cache
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
itest   - return true/false on integer compare
iuw     - iuw (InfoTM Update Wrap tools)
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls      - ls.
md      - memory display
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub system
mmcinfo - mmcinfo <dev num>-- display MMC info
mmmt    - mmmt (OEM implanted memory test tool.)
mtest   - simple RAM read/write test
mw      - memory write (fill)
nand    - NAND sub-system
nboot   - boot from NAND device
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
nor     - nor (OEM implanted nor tool.)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reginfo - print register information
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
showvar - print local hushshell variables
sleep   - delay execution for some time
source  - run script from memory
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
version - print monitor version

[4. LookingForGroup]:
&#12288;

It suggests that my nand surgery was not as successful as I believed.
It also shows that the U-Boot is not at fault here, as I believed.
I will attempt it again with another device and, since I can get 'into its head' now, I can look with extreme prejudice!


The connections are just to the left of the display connector.
One is marked TXD0 and the other is RXD0.
The next two heading toward the display connector are GND and 3V, respectively.

Will play some more!!!

 

[leeb]

According to the output seen above, the NAND is giving AC 95 as its code...
but
according to the PDF data I have, the Samsung K9GAG should be giving EC D5...

AC = 10101100 and 95 = 10011001
EC = 11101100 and D5 = 11011001

Which suggests that bit 6 (0-7) [pin 43] is grounded/unconnected. I need to recheck ALL the pins again. It might be that simple...

Beginning to wish I could find a cheap microscope!

Will not be attempting any further surgery until my weekend... with the possible exception of a connector for the end of the serial-port wires...

Stand by for updates!

 

[leeb]

Last nite, after finishing the serial-port connector, I allowed it to reload 0.6.1.5(672) and, snooping thru it, noticed that the NAND commands seemed to (want to) work... when the 586 always reverted to the help info...

It also showed different (but previously noticed) numbers for the NAND (that being 3B). It was fairly consistent but did show others as well...

Going to assume that the particular NAND is defective as well... or was 'made' that way from my playing around...

Have another one ready to try, and a couple of other sources. Wish I could find a carrier to hold these beasts (or new ones)... would make things ALOT easier!

 

[leeb]

I posted pics in another thread and it seems to be removed... so
This is the one that showed the solder-bridged touchscreen connector (the original problem!)
(deleted as duplicate in previous post)

The one below was what I used to conclude that U0 and u-boot were in the NOR flash...
View attachment 3968

The Samsung NAND has been replaced already, but apparently is bad... Will have to try again!

 

[leeb]

Ive been playing around with some of the MANY u-boot-nands that Ive downloaded... mainly snooping into them to see if I could find anything about the type of NAND devices they recognize,
and
one of them mentions the K9GAG08U0E and U0M specifically.
The others provide only the manufacturer name.

Altho the NAND I put in was a U0D, and I still believe there is 'something wrong' with it since it seems to not produce the proper ID codes (EC D5 at minimum), I think I will insert this particular U0 and see if that changes the plan as to the replacement device.

If NOT?
Lucky I happen to have a U0M that I can cannibalize for the cause!

Thus, it continues!

 

[leeb]

Well, I have had SOME success with the 8U0M...
For a short time it was recognized by the board, but
it reported many bad blocks and had a pattern to it...

I suspect that I simply did not have adequate connections to the chip... being somewhat paranoid about unwanted solder-bridges I think I went a bit too far and 'starved' them...

Taking a break (if fixing major water leaks can be considered a 'break') but will likely attempt again tomorrow.

 

[leeb]

Yesterday I dropped the 'working' pad on its face again as it had started 'locking up' again...

and destroyed the new touchscreen.

So, since I have the display/t-s from the nand-less unit, I am going to:

1) enable the serial port on the 'working' pad,
2) 'steal' the screen from the nand-less pad,

and

3) attempt a nand scrub on the 'working' pad thru the u-boot internal functions.

Once I get the serial port connection made, I will copy off the output from my efforts.

I am still 'certain' that (almost) all the installation issues Ive had are due to inadequate storage from a corrupted and/or defective NAND, and the easiest way to prove it is to scrub the dang thing squeaky-clean and THEN seeing how much of it is reported as unuseable.

LOTS of juggling to do this 'weekend'... including getting the car to start again, clearing out the limb that fell from the tree in front of the house FRI morning, attempting to do SOMETHING to fix the pool issue... etc.

franticface.jpg

 

[mid]

This thread begins to look like your personal blog. Perhaps nobody comments but a lot of us read in silence. Do continue

 

[leeb]

This thread begins to look like your personal blog. Perhaps nobody comments but a lot of us read in silence. Do continue

Thanks for the input! I guess since Im one of the few 'fools' that like dismembering things, it requires me to make note of it.

Last nite, the 'working' pad serial port was temporarily accessed. Unfortunately it seems that 'basically all' of the bad sections of the NAND would not allow erasure. Apparently this is true of all the sections of the storage that was marked bad by Samsung itself. It is pretty bad and demands an attempted replacement.

However, until I get the 'spare' unit (currently under surgery) ACCEPTABLY completed, it will stay 'in one piece'. One thing that will happen is that the serial port will be accessible even when completely assembled.

Acceptably is defined as having ONLY A FEW bad blocks. I may never see it... but I intend to try!
EDIT:
Apparently I spoke too soon... as last nite I pulled the battery for awhile which cleared the ram-based(?) bad-block table...
Tho it now shows alot fewer bad blocks, most of the 'issues' like the /local having NO free space still remain. Discouraging, but not surprising.

 

[leeb]

I am adding to this thread because:

I found a good firmware that made MOE (the 1st pad... thats what I call it now) work quite well, for a long time.
Until I attempted to use him as a guinea pig to help another pad,
( between broken and working, I now have 4... with one on the way! OctoTabletDad, I am!)
and sent him into 'braindead land'.

MOE-2 (the one with the repaired T/s connector) is still awaiting NAND replacement which will be coming 'soon'.
(Once I get enough nerve... and some Mr Magoo specs!)

The important news is:
I believe Ive found the JTAG connector on these boards, and I intend to have MOE-2 prove it.
To that end, Ive already bought the appropriate ribbon connectors for the
SUPER-ITTY-BITTY-TINY-azzed pads
it has... IF I am correct.
I have another dead board (a SP2/3/x type - DF-MID10-IX210) with 'builtin TF' that has a similarly-designed pad arrangement that IS (supposed to be) a combo serial-and-JTAG port...
I expect to be able to put one of these connectors (Digikey # 609-4305-1-ND) on MOE and convince him to reprogram his OWN NOR flash...

And THEN fix the tablet that caused his situation in the 1st place.
And THEN do a NAND-ectomy-and-insertion on his sorry... board.

What a novel idea!
I am pleased to say that I got a CWM backup of his 'thoughts' before I trashed him.

Standby for more of the walking-dead!

EDIT:
I have been able to confirm that the connector-area that I found IS IN FACT a combo JTAG-SERIAL connection. I also now have the appropriate-sized ribbon connector for it, and hope VERY SOON to have a full-scale JTAG port connector working for MOE-2, as well as the other devices that (I hope) have this 12-pin connector-pad area.

EDIT: Found it is actually a 12-pin.... only the DK-mid10 board is a 10-pin... and it is SOOOOOOO dead... not EVEN worth wasting a connector on.
I think.