e3-hacking March 2006

e3-hacking@earth.li

18 participants
36 discussions

RE: [E3-hacking] keypad layout
by Cliff Lawson 03 Apr '06

03 Apr '06

Shades of reinventing the wheel here - I already did the Linux keyboard layouts with sensible key code returns to Linux (IMHO). I'm about to bugger off home for the weekend but if someone gives me a nudge on Monday you're welcome the to files I have already (I spent AGES trying to come up with the best layout and it'd be a shame to see this go to waste!) By the way, if you want a good belly laugh, I'd highly recommend folks watch Jonathan Ross at 10:35pm, BBC1 tonight for an interview with Alan about The Apprentice and a quite "interesting" piece of Atmel AVR ATMega16 based electronics I threw together! Cliff > -----Original Message----- > From: Jonathan McDowell [mailto:noodles@earth.li] > Subject: Re: [E3-hacking] keypad layout This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries. For further information on Amstrad Plc please visit our website: www.amstrad.com Amstrad Plc. Brentwood House 169 Kings Road Brentwood Essex CM14 4EF Registered in England : No. 955321

8 7

Modem Patch
by Matt Callow 03 Apr '06

03 Apr '06

Hi, attached is a patch to enable the modem on the e3. The patch should be applied after Jonathans patches. It is then accessable as /dev/ttyS1. I use micrcom to talk to it. So far, I've managed to get it connected to the phone line as a speaker phone, but I can't get any sound through the handset. Matt Index: linux-2.6/include/asm-arm/arch-omap/serial.h =================================================================== --- linux-2.6/include/asm-arm/arch-omap/serial.h (revision 370) +++ linux-2.6/include/asm-arm/arch-omap/serial.h (working copy) @@ -34,4 +34,9 @@ __ret; \ }) +#if defined(CONFIG_MACH_AMS_DELTA) +#define AMS_DELTA_MODEM_CLK 1843200 +#define AMS_DELTA_MODEM_LINE 1 #endif + +#endif Index: linux-2.6/arch/arm/mach-omap1/board-ams-delta.c =================================================================== --- linux-2.6/arch/arm/mach-omap1/board-ams-delta.c (revision 379) +++ linux-2.6/arch/arm/mach-omap1/board-ams-delta.c (working copy) @@ -15,7 +15,11 @@ #include <linux/kernel.h> #include <linux/init.h> #include <linux/platform_device.h> +#include <linux/serial.h> +#include <linux/serial_core.h> +#include <asm/arch/gpio.h> + #include <asm/hardware.h> #include <asm/mach-types.h> #include <asm/mach/arch.h> @@ -31,6 +35,23 @@ static u8 ams_delta_latch1_reg; static u16 ams_delta_latch2_reg; +static struct uart_port delta_serial_ports[] = { + { + .membase = (char*)AMS_DELTA_MODEM_VIRT, // remapped locn + .mapbase = AMS_DELTA_MODEM_PHYS, + .irq = OMAP_GPIO_IRQ(2), + .flags = UPF_SKIP_TEST | + UPF_BOOT_AUTOCONF | + UPF_BUGGY_UART, /* not sure if the UART really is buggy, */ + /* but without this LSR safety check is engaged on 2nd open */ + .iotype = UPIO_MEM, + .regshift = 1, + .uartclk = AMS_DELTA_MODEM_CLK, + .line = AMS_DELTA_MODEM_LINE, + .type = PORT_16550A + } +}; + void ams_delta_latch1_write(u8 mask, u8 value) { ams_delta_latch1_reg &= ~mask; @@ -50,6 +71,8 @@ omap1_init_common_hw(); omap_init_irq(); omap_gpio_init(); + // set IRQ triggering for modem + set_irq_type(OMAP_GPIO_IRQ(2),IRQT_RISING); } static struct map_desc ams_delta_io_desc[] __initdata = { @@ -98,6 +121,45 @@ { OMAP_TAG_USB, &ams_delta_usb_config }, }; + +/*--------------------------------------------------------------------------- +** Purpose: +** +** Returns: Nothing. +** +*/ +void AMS_DELTA_MDM_Enable(__u8 state) +{ + if(state) + { + //Enable modem + printk("modem enable %lu\n\r", jiffies); + ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_NRESET, + AMS_DELTA_LATCH2_MODEM_NRESET); + ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, + AMS_DELTA_LATCH2_MODEM_CODEC); + } + else + { + //Disable Modem + printk("modem disable %lu\n\r", jiffies); + ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_NRESET, 0); + ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC, 0); + } +} + +static void __ams_delta_modem_init(void) +{ + + printk("ams_delta_modem_init\n\r"); + + AMS_DELTA_MDM_Enable(1); + + if (early_serial_setup(&delta_serial_ports[0]) != 0) { + panic("Could not register ttyS1/Amstrad Modem!"); + } +} + static void __init ams_delta_init(void) { iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc)); @@ -108,11 +170,13 @@ /* Clear latch2 (NAND, LCD, modem enable) */ ams_delta_latch2_write(~0, 0); + __ams_delta_modem_init(); } - static void __init ams_delta_map_io(void) { omap1_map_common_io(); + printk("ams_delta_map_io\n\r"); + } MACHINE_START(AMS_DELTA, "Amstrad E3 (Delta)") @@ -129,3 +193,5 @@ EXPORT_SYMBOL(ams_delta_latch1_write); EXPORT_SYMBOL(ams_delta_latch2_write); +EXPORT_SYMBOL(AMS_DELTA_MDM_Enable); + Index: linux-2.6/drivers/serial/8250.c =================================================================== --- linux-2.6/drivers/serial/8250.c (revision 374) +++ linux-2.6/drivers/serial/8250.c (working copy) @@ -1529,7 +1529,16 @@ serial_outp(up, UART_EFR, UART_EFR_ECB); serial_outp(up, UART_LCR, 0); } + +#ifdef CONFIG_MACH_AMS_DELTA + if (up->port.line == AMS_DELTA_MODEM_LINE) + { + extern void AMS_DELTA_MDM_Enable(__u8 state); + AMS_DELTA_MDM_Enable(1); + } +#endif + #ifdef CONFIG_SERIAL_8250_RSA /* * If this is an RSA port, see if we can kick it up to the @@ -1694,6 +1703,15 @@ serial_out(up, UART_LCR, serial_inp(up, UART_LCR) & ~UART_LCR_SBC); serial8250_clear_fifos(up); +#if defined(CONFIG_MACH_AMS_DELTA) + if (port->line == AMS_DELTA_MODEM_LINE) + { + extern void AMS_DELTA_MDM_Enable(__u8 state); + AMS_DELTA_MDM_Enable(0); // disable modem + } +#endif + + #ifdef CONFIG_SERIAL_8250_RSA /* * Reset the RSA board back to 115kbps compat mode.

2 2

Re: Re: [E3-hacking] PBL and flash access on the E3
by Matt Callow 31 Mar '06

31 Mar '06

> Correction: EMAIL is backspace. > > Do we have any documentation for this yet? The source shows: + KEY(1, 0, KEY_DELETE), /* Delete */ + + KEY(0, 6, KEY_ENTER), /* Video */ + + KEY(4, 0, KEY_SLASH), /* Home */ + KEY(4, 1, KEY_BACKSLASH), /* Office */ + KEY(4, 2, KEY_MINUS), /* Mobile */ + KEY(7, 7, KEY_APOSTROPHE), /* Mobile Msg */ + KEY(5, 7, KEY_BACKSPACE), /* Email */ + + KEY(0, 7, KEY_LEFTSHIFT), /* Vol up */ + KEY(3, 7, KEY_LEFTCTRL), /* Vol down */ + Matt

3 3

RE: [E3-hacking] keypad layout
by Cliff Lawson 31 Mar '06

31 Mar '06

Oh right! I assumed (dangerous I know) that you had both working. The buttons on the top are really a bit pointless for the purposes of Linux use (though I guess they're easy to read ;-) Sadly the way PS/2 works is that the keyboard controller itself, not the main ARM is the clock master and it does comms at something like 70K so the interrupt handler needs to be fairly responsive to not risk missing a pulse when it is "talking". In the end we had to apply FIQ patches to the kernel and do the PS/2 on a FIQ handler to get it reliable enough so it would interwork with the modem interrupts which also need fairly fast response as well. Cliff This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries. For further information on Amstrad Plc please visit our website: www.amstrad.com Amstrad Plc. Brentwood House 169 Kings Road Brentwood Essex CM14 4EF Registered in England : No. 955321

1 0

RE: [E3-hacking] keypad layout
by Cliff Lawson 31 Mar '06

31 Mar '06

> -----Original Message----- > From: Jonathan McDowell [mailto:noodles@earth.li] > > *) The keypad setup as a primary input device, with the aim of being > able to use it for the console. Personally I'm doing most of > my prodding > over the serial port at present, but I get the impression > this is what a > number of people want? Nope that's the way I've done it. I can happily run a Delta as a little Linux computer with nothing more than the LCD screen and PS/2 keyboard as the "console" (in fact I do it quite often). I've also arranged for the matrix keys on top of the phone to duplicate the functionality of the similarly named PS/2 keys (so qwerty can be used on top of phone as well if you're a masochist with pointy fingers). The unique matrix keys generate their own unique keycodes too. Cliff This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries. For further information on Amstrad Plc please visit our website: www.amstrad.com Amstrad Plc. Brentwood House 169 Kings Road Brentwood Essex CM14 4EF Registered in England : No. 955321

2 1

PBL and flash access on the E3
by David Given 30 Mar '06

30 Mar '06

Hurrah! I have my shiny new E3 up and running, and am getting pblq back up to speed. It would appear that the reason pblq doesn't work on the E3 is primarily due to the NOP packet not working (it appears to cause pbl to hit an assertion and go into an infinite loop). There are also a few other gotchas that cause the handshaking procedure to go wrong. I've fixed these, mostly by copying the relevant bits of logic from pbltool --- ta. Next thing is to try and get the flash code up and running; but I'm a little hesitant to play because I don't want to overwrite anything crucial and brick the device. *Is* there anything crucial in the NAND flash? I notice that the MTD partition table has a chunk marked 'Amstrad Block'. Does it matter if I overwrite this? Plus, am I right in that the e3's NAND flash pseudoaddress is 0x400000, instead of the e2's 0x8001000? I've also got Jonathon's prebuilt kernel running, which appears to work nicely --- at least, it produces a palette-mangled penguin and vast numbers of error messages (in pink) as the JFFS driver fails miserably to find a JFFS filesystem on the flash. I need to try a filesystem on a compact flash device and see if that works. But it's definitely getting somewhere! -- +- David Given --McQ-+ "If you're up against someone more intelligent | dg(a)cowlark.com | than you are, do something insane and let him think | (dg(a)tao-group.com) | himself to death." --- Pyanfar Chanur +- www.cowlark.com --+

3 6

RE: [E3-hacking] PBL and flash access on the E3
by Cliff Lawson 29 Mar '06

29 Mar '06

> -----Original Message----- > From: David Given [mailto:dg@cowlark.com] > > Thanks to Cliff for the detailed explanation of how the flash metadata > works. From that, it seems to me that the view of the flash that PBL > sees (after bad-block remapping) is *not* the same as the view that > Linux sees (talking directly to the chip). Which means that while I'm > safe and won't be able to trash the metadata using PBL, I > *will* be able > to trash the metadata using Linux --- and if I trash the metadata, I > won't be able to use PBL to boot from the flash. > > Could the strange issues at the end of the flash be this metadata? Indeed, Remember: { FSH_ALGORITHM_SMART_MEDIA, PBL_FLASH_DATA_BUS_WIDTH_8BIT, PBL_VPP_CALLBACK_NULL, 0x00400000UL, 0x01000000UL - (0x00400000UL + MFS_RESERVED_BAD_BLOCKS), 0x00000000UL, 0x00000000UL } well the 00400000 in there is the "base" address of the Nand and the 0x01000000UL - (0x00400000UL + MFS_RESERVED_BAD_BLOCKS) in there is the length the PBL considers it has to play with as a "data" area. This is because the end of the device is reserved for re-map sectors. That is: /* ** Reserve 192KB * 4 for bad blocks (assumes 32MB part). */ #define MFS_RESERVED_BAD_BLOCKS ((192 * 1024UL) * 4U) Oh I forgot to mention (cos I'd forgotten!) that unlike Gamma, Delta actually has TWO file systems in it and two MD/bad block systems. The bottom 4MB of the device has our old BSI/Gamma type FFS (Flash File System) while the rest of the device is controlled by MFS (Mini File System) and this includes the area where the code lives from 4MB onwards. FFS has it's MDs in the very first sectors of the device while MFS has it's MDs in the very last sectors of the device. Cliff This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries. For further information on Amstrad Plc please visit our website: www.amstrad.com Amstrad Plc. Brentwood House 169 Kings Road Brentwood Essex CM14 4EF Registered in England : No. 955321

1 0

RE: [E3-hacking] PBL and flash access on the E3
by Cliff Lawson 29 Mar '06

29 Mar '06

> -----Original Message----- > From: David Given [mailto:dg@cowlark.com] > > Next thing is to try and get the flash code up and running; but I'm a > little hesitant to play because I don't want to overwrite > anything crucial > and brick the device. *Is* there anything crucial in the NAND flash? I > notice that the MTD partition table has a chunk marked > 'Amstrad Block'. > Does it matter if I overwrite this? Plus, am I right in that > the e3's NAND > flash pseudoaddress is 0x400000, instead of the e2's 0x8001000? { FSH_ALGORITHM_SMART_MEDIA, PBL_FLASH_DATA_BUS_WIDTH_8BIT, PBL_VPP_CALLBACK_NULL, 0x00400000UL, 0x01000000UL - (0x00400000UL + MFS_RESERVED_BAD_BLOCKS), 0x00000000UL, 0x00000000UL } So, yes, 0x00400000UL As for whether there's anything "crucial" in it or not the answer is yes and no. On the one hand the 37K PBL lives in a completely separate NOR flash (it has to so it is address/data accessible to the CPU at boot time - unlike Nand which is just serially accessed) so you can blitz the entire Nand if you like and then put it back afterwards using the PBL. So you can't "brick" the thing. However there is something in the Nand that I'd call "crucial" myself - bad block info. When the manufacturer makes Nand they don't guarantee all sectors in the device (apart from boot block sectors at the start or end). But what they do is factory profile each device and any "unusable" sectors in it have a special pattern of a sea of 0xFFs interspersed with the odd 0x01. That's how the device comes from the factory. On the very first occasion that the PBL tries to mount it, it looks at the sectors near 0 for a "media descriptor" that we might previously have put there if the device has already been used. If it finds a media descriptor and validates it then it continues on to provide r/w access to the device. If neither of two possible copies of MD marked "valid" (check summed and stuff) is present then the device is considered "virgin" and the PBL therefore goes into a "format" routine. The purpose of this is to scan every sector and look for those with the sparse 01's in FF's signature. As it finds them it builds a bad block map which is written into the MD sector (as with most of the important stuff in flash (MD, Block Allocation Map (BAM), directories) we keep two alternating copies of these things to provide power-removal protection during writing. A new copy is written to the "other" position and then the final "alive" byte is only written once the rest of the write has succeeded - so the MD can be found in one of two places. When the device is mounted a copy of the bad block table is loaded to RAM and, for each entry, a "remap" sector from an area towards the end of the device is used to replace it. When the PBL writes to Nand it does the writes via bad block remapping so you may think you are writing a continuous 4MB file to adjacent sectors but odd ones are actually located out of sequence in the remap area (and those sectors themselves could be bad and will also have been remapped to other sectors!) So if you take a complete image of the device including the bad sectors and then put it back later you should be OK. But if you just wipe the device and start writing to random sectors you may be writing to bad blocks. Now we don't ever write to the bad sectors ourselves (cos we know they are bad!!) so they will still have the factory pattern which could be scanned for but if you just loop through the device doing 0x60 commands to erase sector1, erase sector 2 then you might just wipe all know all knowledge of where the bad blocks are. If OTOH you use the PBL "erase" command then it, of course, DOES know to avoid the bad ones. So it kind of depends on what you are planning to do. If it's to use a Linux MTD driver that "knows" the Nand then I'm guessing that it has a strategy for locating the bad blocks when it first initialises the device too so should know about the FF-01 sectors and as long as it gets access to the device while they're still there then everything should hopefully be hunky-dory. You may wonder what happens to flash devices that have been "used" and stored user data that includes sparse 01 in FF data - we know from experience that the PBL sees these as more bad blocks (and if you keep running software that writes such data and then re-"format" the flash the amount seen a bad increases So the idea with Nand is that you only really should "format" it the once - scan it for bad, build your avoidance tables and then never repeat the process. Cliff This e-mail and any attachments are confidential and intended exclusively for the addressee. If you are not the intended recipient please delete it from your system and notify the sender immediately. This message is attributed to the sender and may not necessarily reflect the views of Amstrad Plc or its subsidiaries. For further information on Amstrad Plc please visit our website: www.amstrad.com Amstrad Plc. Brentwood House 169 Kings Road Brentwood Essex CM14 4EF Registered in England : No. 955321

1 0

Greetings - and two questions
by David J. Singer 29 Mar '06

29 Mar '06

Hi all. Just picked up an E3 on ebay for £20. I'm really impressed with the progress that's been made so far on hacking this puppy. I have experience with Linux, embedded systems and hardware design, so am looking forward to having a play! I've had a look through the archives, and on the web, so apologies if these questions have obvious answers, but: 1. Is it possible to save the original firmware image so as to return the phone to "factory defaults" should it ever be necessary... 2. Is there a "howto", or any step by step documentation covering the current state of play as regards getting new builds onto the device, etc. I'm having little trouble figuring out what's what from the various sources of information. Keep up the good work :) -- David J. Singer "Time flies like an arrow, fruit flies like a banana"

1 0

PBL 5.1
by Otaku 27 Mar '06

27 Mar '06

Could someone with an E3 running this version of PBL possibly do me a favour : Send a command 0x15 ( I don't think it takes any params ), and let me know what the response is : it should be 4 bytes.. Cheers Jake

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

e3-hacking March 2006