Subject: [E3-hacking] Success!

From: David Given <[email-masked]>
Date: Wed, 16 Mar 2005 00:17:30 +0000

My line level converter works! Woohoo! (It turns out that it helps if
you look at the *right* diagram on the datasheet, make sure that you
correctly work out which wire of the cable is connected to which pin,
and generally don't do a bunch of really embarassing stuff. On the plus
side, it turns out that MAX232 chips are much more robust than I
thought.)

What's more, pblq has now turned into a reasonably generalised mechanism
for communicating with PBL, complete with the ability to suck down data
using one-byte checksum packets. Currently it's running at 9600 baud,
which means it maxes out at 16 bytes per second --- that's a bit over an
hour to download PBL, and six *days* for the main flash --- so I've only
downloaded fragments. Here's a log; do the checksums match your boards?

$ ./pblq 
Attempting handshake...
Connected.
PBL V3.1 build 1277
Maximum packet length is 8208
Checksum of 00000000+10000: 00A828D0
Checksum of 80010000+550000: 349F8B09
Downloadng: ################

$ objdump -D -b binary -m arm7tdmi output.img 

output.img:     file format binary

Disassembly of section .data:

0000000000000000 <.data>:
   0:   ea000054        b       0x158
   4:   ea000055        b       0x160
   8:   ea00005e        b       0x188
   c:   ea000054        b       0x164
  10:   ea000054        b       0x168
  14:   00000000        andeq   r0, r0, r0
  18:   ea001eb2        b       0x7ae8
  1c:   ea001e86        b       0x7a3c
  20:   00000000        andeq   r0, r0, r0
  24:   00007740        andeq   r7, r0, r0, asr #14
...etc...

I'll get it doing a bit more, polish the interface a bit --- in order to
change options, you have to recompile it, which isn't good --- and post
it somewhere in a couple of days, if people think it would be useful...

-- 
+- David Given --McQ-+ 
|  [email-masked]    | "Home is where, when you have to go there, they
| ([email-masked]) | have to take you in." --- Cordelia Naismith
+- www.cowlark.com --+

---

From: David Given <[email-masked]>
Date: Wed, 16 Mar 2005 00:23:11 +0000

On Wed, 2005-03-16 at 00:17 +0000, David Given wrote:
[...]
> using one-byte checksum packets.

I completely forgot to say:

Ralph, your PBL protocol chart is *spot on*. Wonderful job. Thank-you.
Without JTAG, I wouldn't have been able to get this far without it...

-- 
+- David Given --McQ-+ 
|  [email-masked]    | "Never attribute to malice what can be adequately
| ([email-masked]) | explained by stupidity." --- Nick Diamos
+- www.cowlark.com --+

---

From: Matt Evans <[email-masked]>
Date: Wed, 16 Mar 2005 00:35:29 +0000

Yay!  Well done David.

The disassembly you posted is interesting - what address did you grab 
that from?  It looks like the running exception vectors from DRAM - 
that's not what they are in the PBL ROM, it copies itself into DRAM 
then repatches various things like IRQ vec to to to real routines.

When PBL is running it remaps DRAM to 0 and the boot flash to 80000000:

I haven't got my mental image of the Sharp segmented memory scheme in 
clarity yet but it seems to set up segments such that:
s0	00000000+64K readonly
s1	00000000+8MB rw  SDRAM
s4	40000000+8MB rw  SDRAM
s5	80000000+64K rw  Flash
s6	a0000000+32K rw  Ext bus
s7	ffff0000+64K rw  Int periphs

Hm, that's not good; I didn't think of that- if they're checked in 
order it looks like it's write-protected the first 64K.  Ralph, what's 
your take on the memory map?  (I'm hoping that's wrong, or overridden 
in another order such that addr 0 is writable...)

So maybe try dumping from address 0x80000000 if possible?

I'd be interested in trying your pblq prog.  Hmmm... any CVS available 
to us? ;)  Seems like we're all hacking on different things;  I'd quite 
like a cmdline util to provide a crap shell to send commands (whilst 
sending nop packets while I think so it doesn't time out) - extensible 
to do higher-level things like "dump RAM to/from file"..  Sounds like 
pblq does stuff aiming along those lines eh?  Do post it, would be 
good.

Cheers,

Matt

---

From: David Given <[email-masked]>
Date: Wed, 16 Mar 2005 10:26:21 +0000

On Wed, 2005-03-16 at 00:35 +0000, Matt Evans wrote:
[...]
> When PBL is running it remaps DRAM to 0 and the boot flash to 80000000:

Yes, that corroborates the flash table, which says that the NAND flash
starts at 80010000. (I don't know yet whether it actually *starts*
there, or whether it's mapped at 80000000 and the bottom 64kB are masked
by the NOR flash... if so, there might be something interesting there.
I'm thinking of the BBC MOS, where if you looked in the section of the
MOS ROM that was masked by the I/O area, there were the author's
credits.)

[...]
> So maybe try dumping from address 0x80000000 if possible?

First thing I want to try setting the baud rate a bit higher --- I don't
have all week!

[...]
> to do higher-level things like "dump RAM to/from file"..

Yeah, that's what it's for. (I wrote a very similar program a few years
ago to talk to the SingleStep monitor. Trust me, PBL is easy in
comparison.)

hri.sourceforge.net has CVS, doesn't it?

-- 
+- David Given --McQ-+ "If you're up against someone more intelligent
|  [email-masked]    | than you are, do something insane and let him think
| ([email-masked]) | himself to death." --- Pyanfar Chanur
+- www.cowlark.com --+

---

From: Matt Evans <[email-masked]>
Date: Thu, 17 Mar 2005 10:49:00 +0000

Hi David,

Thanks for the pblq posting, I'll try that out.. umm.. (. o O ( Tonight 
= Guinness..)) sometime ;)

I'm not sure what it means by "NAND flash is *at* 80010000";  
physically NAND flash is not memory-mapped.  It looks more like a block 
device, you request sectors of 512 bytes and At Some Point it comes 
back (a bit like SDRAM reading a row).  The memory regions (set up by 
the Sharp) also aren't big enough to provide some sort of memory 
map-to-block conversion in the CPLD and since its latency differs 
sometimes this prob. isn't sensible for NAND flash.

Of course PBL may provide some sort of software abstraction to 
'convert' reads to a certain offset to a sector fetch & read from 
/that/.

Am interested to know if PBL does this, if you manage to read any of 
the main ROM then let us know :)

> hri.sourceforge.net has CVS, doesn't it?

OOh good idea...

Cheers,

Matt

---

From: David Given <[email-masked]>
Date: Thu, 17 Mar 2005 13:19:07 +0000

On Thu, 2005-03-17 at 10:49 +0000, Matt Evans wrote:
[...]
> 'convert' reads to a certain offset to a sector fetch & read from 

According to the PBL API it does --- I need to investigate the
disassembly and find out what's going on. (Ralph, I don't suppose you
have your annotator script handy, do you?)

> the main ROM then let us know :)

Even at 100 Bps it would take just under 24 hours to download it all,
and I was seeing 66 Bps when PBL was (attempting to) access the NAND
flash --- which makes it 35 hours --- so I don't think I'll try that
just yet. What I would like to do is to download the 8kB page containing
the startup code, which will give me some space to play with custom
code.

Provided I can work out how to reflash it, of course.

-- 
+- David Given --McQ-+ "Feminism encourages women to leave their
|  [email-masked]    | husbands, kill their children, practice withcraft,
| ([email-masked]) | destroy capitalism and become lesbians." --- Rev.
+- www.cowlark.com --+ Pat Robertson

---

From: Matt Evans <[email-masked]>
Date: Thu, 17 Mar 2005 14:35:13 +0000

> Even at 100 Bps it would take just under 24 hours to download it all,

"any" was the operative word in that sentence ;-)

-Matt