e3-hacking

e3-hacking@earth.li

395 discussions

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

03 Apr '06

> -----Original Message----- > From: Tolly Nelson [mailto:tolly@bigredshed.co.uk] > > PS, why is the E3 used on The Apprentice? Unless you've hacked one up, > it can't do digital switching/multiplexing, so its not very useful for > office use, so Alan and his secretary use it?? It's known in the trade as "product placement" I think ;-) By the way someone ought to tell our in house PABX about the Gamma/Delta usage limitations in an office. I think about 100+ desks here have either a Gamma or a Delta on them and AFAIK they all work just fine?!? 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

RE: [E3-hacking] OpenEmbedded and the E3
by Cliff Lawson 03 Apr '06

03 Apr '06

> -----Original Message----- > From: David Ford [mailto:e3@slarti.org.uk] > > I've also had a quick look at getting OPIE working, and have got it > building, however the colours don't work properly. It > certainly gets as > far as the calibration screen though. When we run OPIE re usually do it on top of a kernel where the video driver has been modified to do the more traditional 5:6:5 encoding of R:G:B rather than the actual ?:4:4:4 that we use. At the end of the day there are STILL just four bits for each colour in 5:6:5 so the bottom 1:2:1 are don't care bits as the passive mode LCD controller in the OMAP cannot go beyond 4 bit colour and, in fact, it isn't even 4,096 colours either as 1110 and 1111 are the same colour intensity - there's only 15 distinct levels for R, G and B so you actually get 3,375 colours. 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 03 Apr '06

03 Apr '06

> -----Original Message----- > From: Jasmine Strong [mailto:jasmine@electronpusher.org] > > ...hints for those of us not in the UK? www.amstrad.com/amsface :-) 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

OpenEmbedded and the E3
by David Ford 01 Apr '06

01 Apr '06

Hello, I've made a first attempt at getting OpenEmbedded working on the E3. I've got to the point where it will boot into a ramdisk, and I can get a shell via both Serial and the console. Dropbear sshd also seems to work. Patches, and files that have been built are at http://hu.gs/pub/E3 I've also had a quick look at getting OPIE working, and have got it building, however the colours don't work properly. It certainly gets as far as the calibration screen though. Thanks David

1 1

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 29 Mar '06

29 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

← Newer
1
...
22
23
24
25
26
27
28
...
40
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

e3-hacking