Subject: [E3-hacking] Nearly there

From: David Given <[email-masked]>
Date: Tue, 22 Mar 2005 00:30:21 +0000

Well, I've finally worked out how to bend the E2's flash to my will.

The secret to reflashing it is directive 06, which erases the flash
chip. It took a while to find because the parameters are different.

	0600AAAA AAAABBBB BBBBCCCC
	AAAAAAAA = offset of start of area
	BBBBBBBB = length of area
	CCCC = flash chip to erase

Unlike directive 0E, which reprograms the flash, 06 *doesn't* want a
pseudoaddress in the range 80010000 and up. So, to reprogram the first
8kB page, you need:

	06000000 00000020 00000100

It might be possible to use this directive to erase the NOR flash, but I
don't even want to go *near* that --- JTAGless as I am, if I trash that
I've bricked the whole thing.

Once the flash has been erased it can be reprogrammed with 0E.

I've added flash erasure to pblq; it happens automatically when you try
to write to the flash. The average speed of the combined operation, at
115200 bps using 8kB data packets, is 6400 Bps. Not brilliant, but
better than some dev boards I've had to deal with. (Gen 2 M-Core
development board. 150 Bps, with a 2/5 chance of it crashing half-way
through a 4MB download, DIEDIEDIEDIE. Cough.)

Incidentally, as part of my test procedure, I erased the first megabyte
of flash --- the Amstrad firmware no longer boots. Hurray. When you boot
it, it fails to find the initial boot block (that I trashed last time),
blinks its lights rapidly at me, sit there for about ten seconds as it
tried to find another boot block, and then gives up and repeats.

...

The next step is to (a) create an image, (b) fix the checksum, (c)
persuade the E2 to run it, and (d) port a reasonable OS. Well, (a), (b)
and some of (c) are done.

It turns out that PBL *does* check the checksum of the boot chunk after
all (I'd mistaken a bne for a beq), and doing the maths to find out the
magic value to force the checksum to be zero is... slightly more complex
than I thought! When I'm less tired I'll try and do it properly, but for
now I'm brute-forcing it. As a result, PBL now sees my image as being
valid and tries to run it... and falls over:

PBL V3.1 Build:1277
PBL Exception at PC=EAFFFFFAh CPSR=600000D7h(Abort) SPSR=600000D3h(SVC)
 R0=00040074h  R1=00410090h  R2=00040090h  R3=FFFFFFFFh
 R4=00550000h  R5=00410000h  R6=00030000h  R7=00040000h
 R8=FFFF4C00h  R9=000141CCh R10=00000000h R11=FFFF4000h
R12=00000000h

That program counter looks awfully strange.

But, anyway, this means that I'm *this close* to running code. This
current bug is probably really simple, but I'm amazingly tired and need
to go to bed, and so I'll tackle it tomorrow.

Do we have anywhere where I can upload my shiny new version of pblq
(v0.2), which now has the ability to write to DRAM and flash, and has a
built-in serial terminal?

-- 
+- David Given --McQ-+ "I love the way Microsoft follows standards. In
|  [email-masked]    | much the same manner that fish follow migrating
| ([email-masked]) | caribou." --- Paul Tomblin
+- www.cowlark.com --+

---

From: Matt Evans <[email-masked]>
Date: Tue, 22 Mar 2005 14:17:43 +0000

Hola David,

Well done again :)

I've got a ton of space on my webserver so if you want me to put pblq 
up there then email it to me.

Perhaps we should start work on a 2ndstage loader?  Something simple, a 
bit like bootldr (well, more simple) or YAMON etc.

(i.e. switch on & it loads our loader (could easily fit into the first 
couple of K of NAND); this gives a friendly banner & shell, and allows 
something quick like ZMODEM download to DRAM (and then a 'program NAND 
from DRAM addresses X->Y')?  Also a default action that'll load a 
kernel from NAND to DRAM then jump would be lovely, too.  What do ppl 
think about this sort of thing?  It would make the old "download a 
kernel, boot, see what happens" development cycle much much faster than 
including a program-to-flash step.)

> That program counter looks awfully strange.

Could this be it copying your image to DRAM, then querying it to find 
out its start address, then jumping there?  The PC value there would 
cause the abort exception of course...  Do you know where it gleans the 
entry address from?  (And to where in DRAM it loads the chunk from 
NAND?)

Anyhow, well done!  I should have some hacking time this week, also 
hope to get JTAG going to have a play.  I think a bootloader would be 
useful for further tinkering/dev so will make a start on one.

Cheers,

Matt

---

From: Ralph Corderoy <[email-masked]>
Date: Tue, 22 Mar 2005 14:30:39 +0000

Hi,

> That program counter looks awfully strange.

It's a branch instruction, forward 0x03FFFFF0 I think.

Sorry for the lack of replies.  Busy at the moment due to end of fiscal
year.  I am planning on going through the backlog of email soon.

Cheers,

Ralph.

---

From: David Given <[email-masked]>
Date: Tue, 22 Mar 2005 15:11:17 +0000

On Tue, 2005-03-22 at 14:17 +0000, Matt Evans wrote:
[...]
> bit like bootldr (well, more simple) or YAMON etc.

I actually have another project, called PCPM --- Portable CP/M. It's a
single-tasking OS designed to be simple to port; in it's simplest
incarnation, all you need are three functions to read, write and poll
the console, and that's it. It doesn't even need interrupts.

I mention this because it'd make a rather good boot loader. You could
probably fit the kernel in the NOR flash, but as I said, I'm not
touching that.

[...]
> out its start address, then jumping there?

D'oh! Now I'm less tired, the reason it's crashing is obvious --- I must
be missing a dereference somewhere. (I'm putting the first instruction
where the address of the first instruction should be.) I'll try it again
this evening.

...

Incidentally, what would be a good OS to run on this? Not having an MMU
rules out Linux or one of the BSDs; they'd be a bad choice anyway,
because 8MB of RAM is really not a lot. ucLinux is an option, but again,
it's rather large (and I just don't *like* ucLinux).

There's always a traditional embedded OS like eCos, but, well, yuck. (I
work for a company that makes one. No thanks.)

One OS that keeps coming to mind is Minix. Simple, BSD licensed, has a
tiny footprint, segmented rather than paged so we could actually get
some memory protection on the ARM7TDMI, provides a decent set of Unix
semantics...

-- 
+- David Given --McQ-+ "There does not now, nor will there ever, exist a
|  [email-masked]    | programming language in which it is the least bit
| ([email-masked]) | hard to write bad programs." --- Flon's Axiom
+- www.cowlark.com --+