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.)

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.

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

On Tue, 2005-03-22 at 14:17 +0000, Matt Evans wrote: [...]

Perhaps we should start work on a 2ndstage loader? Something simple, a 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. [...]

Could this be it copying your image to DRAM, then querying it to find 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 | dg@cowlark.com | programming language in which it is the least bit | (dg@tao-group.com) | hard to write bad programs." --- Flon's Axiom +- www.cowlark.com --+