e3-hacking March 2005

e3-hacking@earth.li

11 participants
17 discussions

previous amstrad emailer
by paul＠e3.sbrk.co.uk 17 Apr '05

17 Apr '05

I haven't got an e3 yet, but since they've just come down in price I might get a pair. However, I do have a couple of the previous versions of the emailer which I just use as normal phones. I did have a bit of a look at the emailer to stop it having to dial up to premium rate numbers which annoyed me a bit. What I did was configure the emailer to dial another modem instead of the premium rate number by using a cheap 4 port pbx. This, as someone else mentioned dials up and authenticates via CHAP. By prompting the emailer for authentication, I learned its username and password. You then see the amstrad try to connect to various servers and request configuration files over HTTP amongst other things. I configured my box to respond to all IP addresses and learnt what it was requesting. You could then use the above info to request the config files from the real server. If you look in the retrieved gamma_a_live.config you see things like redial intervals, next advert collect time and stuff that you can alter to more reasonable values and feed to the emailer. I never registered the second emailer at all and it works fine. Interestingly, the previous version had a config option: CameraSupport=0 so I presume the process is very similar, if not identical for the e3. Paul

5 16

E3 - can a daily reset keep video functionality free?
by Rahim Nathwani 30 Mar '05

30 Mar '05

I know this may be slightly off-topic but, having read a few articles about this beast (along with a few posts on this list, which I found just a few minutes ago), it seems like the E3 would be a really nice device to have around as long as it could be kept functional for voice/video without making non-geographic calls at night. Am I right in thinking one could do something like the below? 1) Buy an E3 (duh!). 2) Plug the E3 into an Orchid dialler (LCR box), configured to block any calls not to 01/02 numbers. 3) Use the phone until the lack of a connection to Amstrad, Thus or whoever means that it stops. 4) Reset it.* * I've seen a procedure for resetting the E2, but not the E3. Is there one? Rahim.

4 5

E3's In-store at The Link for GBP49.99.
by Ralph Corderoy 23 Mar '05

23 Mar '05

Hi, Ian Johnson has emailed me to say that _The Link_ is selling E3's in-store, but not online, for GBP49.99. Thought it may be on interest. If others confirm it would be nice to hear on the list. Cheers, Ralph.

2 1

ARM compilers
by David Given 22 Mar '05

22 Mar '05

I don't suppose anyone knows where I can get a debian binary package of gcc-arm-elf for current 'unstable', do they? I can't get the blasted thing to compile on my system. I'm currently using tcc, which has the advantage of being small and very fast, but produces code that can charitably be described as really lousy. The other toolchain I have access to, ACK, produces duff code for the ARM. Oh, yeah, I'm now running C on the E2... is there any useful information I can find out from it? I'm currently attempting to probe the segment registers but I need to print out the appropriate slab from the manual to make reasonable sense of the results. -- +- David Given --McQ-+ "Feminism encourages women to leave their | dg(a)cowlark.com | husbands, kill their children, practice withcraft, | (dg(a)tao-group.com) | destroy capitalism and become lesbians." --- Rev. +- www.cowlark.com --+ Pat Robertson

1 0

...and we're booting!
by David Given 22 Mar '05

22 Mar '05

Hurrah! My E2 emailer is now printing 'Hello, world!' at roughly 20 second intervals, as the watchdog timer reboots it! I attach the gas source that produces the bootable image. It turns out I'd misread the disassembly of the boot process, again... here, for reference, is the updated and corrected document of the boot image's magic: +0000: magic1, 0x3B513B51 +0008: length of chunk +0014: magic2, 0x00544F42 ("BOT") +0064: address of boot vector after relocation +0068: magic3, 0xB513B513 +006c: relocation destination +0070: image type: 0 == plain 2 == compressed (won't go into the details of this now) The boot vector is: +0000: unknown, unused +0004: start address after relocation The maximum length of the boot chunk is 0x30000 bytes, 192kB. The standard firmware gets relocated to 0x40000, so that's the address I've used. To produce a bootable image from the attached source, do this: arm-linux-as -o test-e2.o test-e2.s arm-linux-ld --section-start .text=0x40000 -o test-e2.img test-e2.o arm-linux-objcopy -O binary test-e2.img test-e2.pbl pblq bless test-e2.pbl Yeah, it's a bit convoluted --- blame GNU. The last stage uses pblq to fix the checksum in the boot image, without which PBL will refuse to touch it. You can then upload it with: pblq writeflash test-e2.pbl 0 And then do: pblq term , power cycle it, and watch the fun! You can get pblq from my Amstrad Hacking page here: http://www.cowlark.com/amstrad.html Be gentle to my web server --- it's not very big. -- +- David Given --McQ-+ "Opportunity is missed by most people because it's | dg(a)cowlark.com | dressed in overalls and looks like work." --- | (dg(a)tao-group.com) | Thomas Edison +- www.cowlark.com --+

2 5

Nearly there
by David Given 22 Mar '05

22 Mar '05

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 | dg(a)cowlark.com | much the same manner that fish follow migrating | (dg(a)tao-group.com) | caribou." --- Paul Tomblin +- www.cowlark.com --+

3 3

re: Small update
by Otaku 19 Mar '05

19 Mar '05

> I've figured out how to get PBL to program the NAND flash, and have > added the appropriate stuff to pblq to make it all work... it's > request 0E, of course, except it behaves rather oddly until you > realise that it only works on 8kB chunks. > > Unfortunately, it will only *program* the flash, not *erase* it. > Which means that it can change a 1 to a 0, but not back to a 1 > again... and since my test file consisted of about 70kB of zeros, > this means that at least part of my flash is empty. > > (Interestingly, the Amstrad firmware still boots --- except without > the splash screen. Obviously, that first chunk simply contains the > splash screen code, and chains on to the next chunk, which must take > some time to decompress. Now I've overwritten the magic in the first > chunk, PBL is skipping on ahead.) > > So if anyone can figure out how to make PBL erase a flash sector, all > the tools we need will be in place to actually run stuff! > Nice work.. I'm playing with an alternative approach on the E3 - it looks to me as if the programming sequence used via the modem (which is a YModem download of an lz compressed image ) might actually be accessible via the serial port too.. If anyone knows different, I'd appreciate the heads-up.. :) I'm guessing that a lot of the code is common between the emaillers.. > Incidentally, would it be worth setting up a wiki or hieraki or > something for the project? Hrmm - I'm going to have takingthingsapart.org up and running next week sometime.. I'm planning to shove up all the stuff I've got on the E3 there, along with some other projects.. Y'all are welcome to use that space for E2 stuff too.. Cheers Jake

1 0

Small update
by David Given 19 Mar '05

19 Mar '05

I've figured out how to get PBL to program the NAND flash, and have added the appropriate stuff to pblq to make it all work... it's request 0E, of course, except it behaves rather oddly until you realise that it only works on 8kB chunks. Unfortunately, it will only *program* the flash, not *erase* it. Which means that it can change a 1 to a 0, but not back to a 1 again... and since my test file consisted of about 70kB of zeros, this means that at least part of my flash is empty. (Interestingly, the Amstrad firmware still boots --- except without the splash screen. Obviously, that first chunk simply contains the splash screen code, and chains on to the next chunk, which must take some time to decompress. Now I've overwritten the magic in the first chunk, PBL is skipping on ahead.) So if anyone can figure out how to make PBL erase a flash sector, all the tools we need will be in place to actually run stuff! Incidentally, would it be worth setting up a wiki or hieraki or something for the project? -- +- David Given --McQ-+ | dg(a)cowlark.com | Quidquid latine dictum sit, altum viditur. | (dg(a)tao-group.com) | +- www.cowlark.com --+

1 0

Re: The boot process, revealed!
by Otaku 19 Mar '05

19 Mar '05

Hi David. >+0000: magic1, 0x3B513B51 >+0008: headerlength >+0014: magic2, 0x00544F42 ("BOT") >+0064: execaddress >+0068: magic3, 0xB513B513 >+006c: destination (0x04000000) >+0070: imagetype > 0 == plain > 2 == compressed >+0074: compressedlength > > > Aye - that pretty much matches whats on the E3.. only the header runs from 0x3B513B51 to 0xB513B513. The rest is image specific. fyi : in the E3 theres over a hundred of these sections - bits containing wavs, images, etc... magic2 is the "filename" - theres also a description string in there somewhere - fixed length/zero filled.. Theres also a simple image crc system there too - you crc the file and if the result is 0 then its a good image - theres a fix-up byte that must be introduced to make sure of the zero result.. Once you work out where that is ( or you can just hack the description :P ), you can either edit the existing image ( simpler under the e3 ), or reflash completely. >I've included what I think is a decompilation of the boot logic at the >end (because it's big and antisocial). Basically, PBL supports both >compressed and uncompressed images; the data is copied or decompressed >to the target destination and the execution address called. Couldn't be >simpler (although the code took me several hours to decipher... god, >this stuff is hard. I couldn't have done it without Ralph's crib sheet). > > > What crib sheet ? >This should be dead easy to write code for. > >Next order of business is to try and figure out how to reflash it, and >then I can give it a try... > > > Does it do similar keypress checks to the E3 on boot ? I've a list of about 8 "special function" keys - Only 2 of which I can activate, so I'm assuming the others require some sort of special circumstance to be available - I'm still working through the disassembly on this.. Cheers Jake

3 2

The boot process, revealed!
by David Given 19 Mar '05

19 Mar '05

Well, I've managed to hack pblq into downloading the NAND flash. Some of it, at least. The secret is that PBL's checksum routine is very, very stupid, and while it can checksum the flash, it can only checksum from the *beginning* of the flash. This means you can calulate the checksum of byte 0; or bytes 0 to 1; or bytes 0 to 2; etc. Fortunately, I can work out byte n by calculating the checksum of bytes 0..n and subtracting the checksum of bytes 0..(n-1). Unfortunately this means the E2 is doing huge amounts of work, and the further into the flash you want to read, the slower it gets. Initial download speed: 66 Bps. Not brilliant. Average download speed after reading 16kB: 40 Bps. Pathetic. It would appear that the only way of getting an image of the flash would be to download a custom program; and the only way to do that is to reflash it. At least now I have two pages to play with. This is what the first 128 bytes looks like: 00000000 51 3B 51 3B 00 00 71 16 6C 34 01 00 02 00 02 00 Q;Q;..q.l4...... 00000010 01 00 34 00 42 4F 54 00 00 00 00 00 00 00 00 00 ..4.BOT......... 00000020 00 00 00 00 40 28 23 29 42 4F 54 20 56 32 2E 30 ....@(#)BOT V2.0 00000030 20 42 75 69 6C 64 3A 30 30 35 32 00 00 00 00 00 Build:0052..... 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060 00 00 00 00 7C 00 04 00 13 B5 13 B5 00 00 04 00 ....|........... 00000070 02 00 00 00 DC 07 01 00 00 00 00 00 62 00 00 02 ............b... The code that deals with this is in PBL near 0x25c0. After loading at least some of the image at 0x410000 (I don't know how much yet), it examines the following significant fields that I've found so far: +0000: magic1, 0x3B513B51 +0008: headerlength +0014: magic2, 0x00544F42 ("BOT") +0064: execaddress +0068: magic3, 0xB513B513 +006c: destination (0x04000000) +0070: imagetype 0 == plain 2 == compressed +0074: compressedlength I've included what I think is a decompilation of the boot logic at the end (because it's big and antisocial). Basically, PBL supports both compressed and uncompressed images; the data is copied or decompressed to the target destination and the execution address called. Couldn't be simpler (although the code took me several hours to decipher... god, this stuff is hard. I couldn't have done it without Ralph's crib sheet). This should be dead easy to write code for. Next order of business is to try and figure out how to reflash it, and then I can give it a try... ---snip--- int16_t checksum(byte* start, offset) { byte checksum1 = 0; byte checksum2 = 0; while (offset--) /* not sure about this */ { b = *start++; checksum1 += b; checksum2 += checksum1; } return (checksum1<<8) | (checksum); } if ((magic1 != 0x3B513B51) || (magic3 != 0xB513B513) || (magic2 != 0x00544F42)) /* PBL uses strcmp for this one */ goto error; if (headerlength == 0) goto error; if (imagetype != plain) { /* If this is a compressed image, validate the compressed data by checksumming it. I think. */ if (value1 > 0x30000) goto error; if (checksum(0x410000, value1) != 0) { /* This can never happen, surely? */ if (imagetype == plain) goto error; if (compressedlength > 0x30000) goto error; if (checksum(0x410000, compressedlength) != 0) goto error; } } if (imagetype == plain) { memcpy(destination, 0x410000, headerlength); } else if (imagetype == compressed) { memcpy(destination, 0x410000, 0x7c); decompress_rx_packet(0x410000, destination+0x7c, compressedlength-0x7C); } execaddress(); ... error: /* I believe this might keep retrying every 8kB throughout the flash until it finds a valid boot block. Useful if the first page on the flash chip has died. */ ---snip--- -- +- David Given --McQ-+ "I don't like the thought of her hearing what I'm | dg(a)cowlark.com | thinking." "*No-one* likes the thought of hearing | (dg(a)tao-group.com) | what you're thinking." --- Firefly, _Objects in +- www.cowlark.com --+ Space_

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

e3-hacking March 2005