[RobBrownNZ]

Quote

(btw from ur nick i surmise ur names robert brown and ur from New Zealand . how smart am i

You might also deduce that I'm very unimaginative when it comes to choosing nicks. And you'd be right .

Do you know any names of people who have bricks? It's about time we looked into resurrecting those.

[docnas]

Hmm there are a few but i recommend start with davidr as hes not a newbie and knows his stuff.

also theres gnarlyc
mac1_131 also had some issues
and galcv2

Il post in their threads and ask them to check in here

http://www.slatedroi...?topic=14914.15 (this is davidr 's thread)

[geebekazoo]

davidr, mac1_131, galcv2, pworcester, Art5 and probably a few more that I haven't read about yet.

[galcv2]

Quote

Quote

(btw from ur nick i surmise ur names robert brown and ur from New Zealand . how smart am i

You might also deduce that I'm very unimaginative when it comes to choosing nicks. And you'd be right .

Do you know any names of people who have bricks? It's about time we looked into resurrecting those.

I have a nice looking WPDN 7" brick and don't mind experimenting with it... and I'm ready for a trip to Radio Shack
Obi Wan RobBrownNZ you are our only hope!

[davidr]

Quote

davidr, mac1_131, galcv2, pworcester, Art5 and probably a few more that I haven't read about yet.

Prior to talking to Pandigital, I decided to visit with my local BBB where I had bought the Novel and tell them of my problem. They very generously offered to trade it out, so I am back in business and therefore don't have a bricked unit to utilize in the experiment.. I sure hope it works out.. It is a badly needed capability.

[panengineer]

Great to have you back davidr! BBB seems to be pretty good about exchanges.

[jackbox]

Quote

Quote

Quote

(btw from ur nick i surmise ur names robert brown and ur from New Zealand . how smart am i

You might also deduce that I'm very unimaginative when it comes to choosing nicks. And you'd be right .

Do you know any names of people who have bricks? It's about time we looked into resurrecting those.

I have a nice looking WPDN 7" brick and don't mind experimenting with it... and I'm ready for a trip to Radio Shack
Obi Wan RobBrownNZ you are our only hope!

Call PD and tell them an update from their website bricked your unit. They might offer to swap it for a new one.

[RobBrownNZ]

Quote

Call PD and tell them an update from their website bricked your unit. They might offer to swap it for a new one.

Awww... now where's the challenge in that?!

[RobBrownNZ]

I've done some more experiments to confirm pin 12 as TDI and pin 13 as TMS, but haven't had a chance to connect up an actual JTAG adapter yet. Once I've done that, I'll hopefully be able to find DBGSEL by looking at which pin affects the JTAG scan chain. I don't have much data on the S3C6410, though, so I don't really understand what DBGSEL does apart from connecting JTAG to either the memory interface or the CPU core (and I'm not even sure about that). Does anyone else have any more information?

Also, pin 16 is really interesting. In my experiments, I manually stepped to RESET state, and then to SHIFT-DR or SHIFT-IR. Pin 16 floats initially, until I get to SHIFT-DR/IR, and then starts driving as though an output enable has been set. Once set, it seems to stay set until I power down. This is unlike any other JTAG interface I've seen. Could it be that the S3C6410 itself behaves like this, or has Pandigital connected some funky output driver to it? Again, I'd appreciate advice from anyone with information.

[gnarlyc]

Count me in as a brick recovery tester. Can we get this worked out BEFORE I tell my wife? ;)

I flashed a bad recovery.img and the system wasn't in a good state yet, so I have no where to go but here. 'adb shell' does not work, so I can't 'flash_image'...

So... I'm really interested in this thread. I'm spinning this as a good learning experience all the way around. Maybe I'll learn a little more hardware level stuff or at least how to un-brick the thing. And I learned that I can save my self a big headache if I will just double check the file size of any recovery.img's before flashing. That wouldn't always save me, but it would have this time... (Or don't flash any modded recovery.img's. Anyway. Moving along. No time machine here.)

[JPdonnel]

Rob

I�m far from a JTAG expert but pulled out my books on the S3C6410 and here is what I got:

1. DBGSEL is JTAG interface call select signal,

2. The DBGSEL signal determines which device to access:
When the power level of DBGSEL is high, the JTAG interface provides access to the S3C6410 in-chip peripherals; when the power level of DBGSEL is low, the JTAG interface provides access to the core

3. The S3C6410 Board is equipped with a JTAG
interface for downloading program code into the external flash, internal controller RAM or for debugging programs currently executing.

4. Via configuring the signal DBGSEL the user can select to operate external Flash or internal controller RAM, below is the detail configuration of signal DBGSEL.
When DBGSEL is set as high level, JTAG connects internal controller RAM and can call on the address of internal controller SRAM.

When DBGSEL is set as low level, JTAG connects external flash for debugging programs.

Hope this helps

[RobBrownNZ]

Thanks for that JPdonnel. I've surfed until my fingers are raw and come up with not much more than what you've posted. A couple of things though, one is that I've seen some designs that just tie DBGSEL high and don't allow it to be changed. Also the BSDL file is available from Samsung's Digital World (http://www.samsung.c...infinicores.com) and it says that "to enable compliance to IEEE Std 1149.1", DBGSEL should be high.

Actually I think I'm getting the picture here. With DBGSEL high, you access the Samsung part which (according to the BSDL file) has an IDCODE of 0x00EB509D or similar. With DBGSEL low, you access the ARM 1176 core, which has a different appearance entirely (the ARM technical reference manual says that the IDCODE should be 0x07B76F0F). That should be enough to identify DBGSEL.

Oh, the pain of being stuck at work when I'd rather be at home tinkering!

[RobBrownNZ]

Some good news, but it almost poses more questions than it answers...

The JTAG interface works, so the pins I've posted previously are correct:
[pre]Info : device: 4 "2232C"
Info : deviceID: 364511236
Info : SerialNumber: FTQ47CBEA
Info : Description: Olimex OpenOCD JTAG TINY A
Info : clock speed 20 kHz
Info : JTAG tap: s3c6410.etb tap/device found: 0x2b900f0f (mfg: 0x787, part: 0xb900, ver: 0x2)
Info : JTAG tap: s3c6410.cpu tap/device found: 0x07b76f0f (mfg: 0x787, part: 0x7b76, ver: 0x0)
Info : found ARM1176
Info : s3c6410.cpu: hardware has 6 breakpoints, 2 watchpoints
Warn : ETMv2+ support is incomplete
Info : ETM v3.2[/pre]
However, this is talking to the ARM11 core, not the S3C6410 boundary scan. I don't know if this is a good thing or not! I've tried all combinations of high and low on the remaining unidentified inputs (pins 5, 6, 19, 20) and I couldn't get a different IDCODE so I have to assume that DBGSEL isn't on CON4 at all. I have no idea what those other 4 inputs do.

The biggest issue though, is that it seems OpenOCD doesn't actually support programming OneNAND memory. So, I'm not sure where this leaves us for unbricking units. Anyone have any ideas? It seems to me that the best way to access the OneNAND is by using U-Boot, through the serial interface on CON4. That depends of course on U-Boot being intact in the bricked units, and I don't know if we can rely on that (have people been overwriting the bootloader?). I've seen a comment that one way to handle OneNAND is to program U-Boot into RAM using JTAG, and then use U-Boot's serial interface to program the memory; but the U-Boot site specifically says that this can't be done.

It's late and I can't make sense of all this. Anyone got any thoughts?

[gnarlyc]

Quote

The biggest issue though, is that it seems OpenOCD doesn't actually support programming OneNAND memory. So, I'm not sure where this leaves us for unbricking units. Anyone have any ideas? It seems to me that the best way to access the OneNAND is by using U-Boot, through the serial interface on CON4. That depends of course on U-Boot being intact in the bricked units, and I don't know if we can rely on that (have people been overwriting the bootloader?). I've seen a comment that one way to handle OneNAND is to program U-Boot into RAM using JTAG, and then use U-Boot's serial interface to program the memory; but the U-Boot site specifically says that this can't be done.

It's late and I can't make sense of all this. Anyone got any thoughts?

We do overwrite the bootloader, however it's small and we have yet to figure out how to extract it to modify it. So, it should flash very quickly and leave very little time for us to mess up the flash, and we can't mess it up by changing it. My thinking is that the bootloader is going to be ok more often than not. (But there have been a few cases mentioned where people flashed another bootloader to bring their devices back to life, so it's not unheard of.)

Can we get into u-boot by hacking a serial adapter to the thing or will this require the purchase of some extra hardware? And I assume we have to purchase the JTAG debugger to use JTAG?

Thanks for looking at this.

[RobBrownNZ]

I'll put together a guide for using serial and JTAG over the next couple of days, hopefully we can get some more people playing with this and find ways to make it useful. I mean, we now have serial and JTAG access, so that's gotta be a good thing!

Hooking up a serial link is very easy. You need a ribbon cable and breakout board as zrbarnes posted at the start of this thread, a USB-serial adapter like this: http://www.sparkfun.com/products/718, a 3.3k resistor (5c at Radio Shack), some wire and a little bit of soldering ability. About $30 all up.

If your bootloader is intact, then you can definitely unbrick your unit through the serial link. If your bootloader is fried, then you need JTAG and we need to figure out how use JTAG to re-program (at least) the bootloader.

The CON4 pinout, just for completeness:
Pin 1 - 3.3V supply
Pin 2 - 3.3V supply
Pin 3 - GND
Pin 4 - 3.3V supply
Pin 5 - Unknown input
Pin 6 - Unknown input
Pin 7 - RTCK
Pin 8 - GND
Pin 9 - serial terminal Tx from PDN
Pin 10 - serial terminal Rx into PDN
Pin 11 - nReset (SRST)
Pin 12 - TDI
Pin 13 - TMS
Pin 14 - GND
Pin 15 - TCK
Pin 16 - TDO, should use a pullup (15k will do).
Pin 17 - nReset (SRST)
Pin 18 - GND
Pin 19 - Unknown input
Pin 20 - Unknown input

[rebthor]

Thanks for all the hard work you did on this Rob.

This is really cool.

[RobBrownNZ]

I've been looking at various bits of code today, and it looks like there's enough information around to get OneNAND flashing through JTAG working. U-Boot does it of course, but it's interesting that mainline U-Boot doesn't support S3C6410. There are other branches of U-Boot that do support the 6410, though.

Right now I'm downloading the Samsung Galaxy Spica i5700 source code from their open source site. The download rate is pretty slow, and the file is 2GB(!), so it will take a few hours yet. It'll be interesting to see what's in there though.

[gnarlyc]

Quote

I'll put together a guide for using serial and JTAG over the next couple of days, hopefully we can get some more people playing with this and find ways to make it useful. I mean, we now have serial and JTAG access, so that's gotta be a good thing!

Hooking up a serial link is very easy. You need a ribbon cable and breakout board as zrbarnes posted at the start of this thread, a USB-serial adapter like this: http://www.sparkfun.com/products/718, a 3.3k resistor (5c at Radio Shack), some wire and a little bit of soldering ability. About $30 all up.

If your bootloader is intact, then you can definitely unbrick your unit through the serial link. If your bootloader is fried, then you need JTAG and we need to figure out how use JTAG to re-program (at least) the bootloader.

The CON4 pinout, just for completeness:
Pin 1 - 3.3V supply
Pin 2 - 3.3V supply
Pin 3 - GND
Pin 4 - 3.3V supply
Pin 5 - Unknown input
Pin 6 - Unknown input
Pin 7 - RTCK
Pin 8 - GND
Pin 9 - serial terminal Tx from PDN
Pin 10 - serial terminal Rx into PDN
Pin 11 - nReset (SRST)
Pin 12 - TDI
Pin 13 - TMS
Pin 14 - GND
Pin 15 - TCK
Pin 16 - TDO, should use a pullup (15k will do).
Pin 17 - nReset (SRST)
Pin 18 - GND
Pin 19 - Unknown input
Pin 20 - Unknown input

Thanks for this and all of the work you guys are doing. This is awesome and will solve most of the issues with hacking the PDN. I'll try and gather the things that I need and get started with the un-bricking! It's really nice to have some hardware folks here.

[rapmv]

Quote

I've been looking at various bits of code today, and it looks like there's enough information around to get OneNAND flashing through JTAG working. U-Boot does it of course, but it's interesting that mainline U-Boot doesn't support S3C6410. There are other branches of U-Boot that do support the 6410, though.

Right now I'm downloading the Samsung Galaxy Spica i5700 source code from their open source site. The download rate is pretty slow, and the file is 2GB(!), so it will take a few hours yet. It'll be interesting to see what's in there though.

Looking through some docs about S3C6410, there is a way to actually have the iROM load the bootloader from a SD card. There is apparently a jumper or switch (I do not know) on the board which dictates this. More information is available in this application note.

http://blogimg.china...00812183724.pdf

It talks about GPN[15:13] boot device selection pin and also about where the ROM would look for a bootloader on a SD/SDHC card.
Since you are well versed with the hardware side of things, this might be easier for you to figure out than I have been so far

Thanks.

[RobBrownNZ]

To be honest, I don't like the idea of actually attacking my PDN's circuit board with a soldering iron! Also I don't know how we could identify the XEINT pins (my workplace has an x-ray machine, but even so, x-raying multi-layer boards to trace connections is unreliable). Looking at the pictures of the circuit board in the "guts of the novel pics" thread (http://www.slatedroi...hp?topic=3732.0), there could be some boot selection resistors to the right of the CPU above the battery, but who knows?

Personally I think that since U-Boot can handle booting kernels etc from SD card, there's no real need to change the hardware.