e3-hacking May 2006

e3-hacking@earth.li

12 participants
19 discussions

RE: [E3-hacking] E3 Memory Map?
by Cliff Lawson 16 May '06

16 May '06

> -----Original Message----- > From: David J. Singer [mailto:doc@deadvirgins.org.uk] > > I'll be more specific: Where does the Amstrad firmware sit > in the NAND flash? The point of our named modules system is that it doesn't actually matter where or how big modules are as long as they can be found by name (always on a page boundary to make searching quicker). Then the module header includes info such as how big the lumps are. So expect to find them anywhere. There are some limits such as the PBL only reading 300KB of NAND before it looks for MEM and then only reading the MEM value 1 amount of NAND before it looks for LDR. And LDR just scans that same amount of RAM copied data (it doesn't read NAND itself) looking for LINUX and PARMS 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] E3 Memory Map?
by Cliff Lawson 16 May '06

16 May '06

> -----Original Message----- > From: David Given [mailto:dg@cowlark.com] > > So far there's no (released) way of booting a Linux kernel > out of the NAND > flash, Except the Amstrad implementation that boots Montavista Pro 3 (2.4.18) ? ;-) As long as you have a module header called "LINUX" then the PBL will load it out to its RAM load address and enter it, it'll even pass into it the text of a module called "PARMS" so I don't see why this can't be used to boot other flavours of Linux? Or, of course, the thing that you *call* "LINUX" could actually be a copy of Das uBoot so that you have PBL in NOR as a Primary Boot Loader and then uBoot acts as an SBL (Secondary Boot Loader) and is loaded out to RAM and executed and IT then goes on to load your favourite flavour of Linux 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

4 3

RE: [E3-hacking] E3 Memory Map?
by Cliff Lawson 16 May '06

16 May '06

> -----Original Message----- > From: Jasmine Strong [mailto:jasmine@electronpusher.org] > > Because 2.4 is obsolete and basing new projects on it is a very bad > idea. Methinks you missed the point. What I'm saying is PBL is happy to load a block of NAND out to a place in SDRAM at a location specified in that images module header and then jump to it's entry point if it happens to have the name "LINUX" in the module header. I've actually written completely standalone LCD demo programs using this technique and called them "LINUX" and then the PBL has loaded/executed them. That image could be a self extracting 2.4 or 2.6 or, when available 2.8 Linux or perhaps even uBoot or anything your heart desires. You also have the added advantage that it passes the text found within a module called PARMS as command line parameters to the thing it is executing. If it's a self extracting Linux image this may be useful, if it's uBoot or an LCD demo program this may well still occur but the chances are PARMS text will be ignored. So the point was simply that the emailer has a perfectly good "load and go" system so why bother to reinvent the wheel. The fact we use it to load and go with 2.4.18 simply shows that it works! 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

6 6

RE: [E3-hacking] E3 Memory Map?
by Cliff Lawson 16 May '06

16 May '06

> -----Original Message----- > From: Matt Callow [mailto:mc-lists@tesco.net] > > Hmm, I though PBL loaded and executed a block called 'LDR' > and then that > loaded a block called 'LINUX' ? Oh yeah, I forgot LDR (I actually split the load that way cos PBL can never be changed in the field (except we later did!)) but the Linux loading process was subject to change so I added in a secondary level to the process so it could be more easily changed than the very risky strategy of changing the NOR (which risks bricking phones if it screws up!) So if you had something that you want to load but don't want any of the PARMS nonsense then just fixup the block of binary with an "LDR" header and it will be loaded and executed but it is LDR that contains the stuff that goes hunting for PARMS and then fashions it into the format that Linux likes to see and then finds LINUX and executes that passing it the parm block. SO if you want command line parms leaver LDR intact and call the module LINUX As for size limits that's what MEM is all about, It's a module whose body only contains a couple of numbers. One is the "end copying here" address and then other is the "end app, start of adverts" address. At the moment I think the MEM you have has the first number set to something like just 2MB so the PBL itself only copies 2MB of NAND out to RAM and then does the search for LDR within this. LDR then runs and reuses this copied block to search for PARMS and LINUX (latest, valid versions - there's usually two of each). So if you can't squeeze the LINUX you want into this space make a new MEM with a bigger first number so the PBL will copy more or, if MEM is not found (or just corrupted) the PBL copies 16MB of NAND to flash anyway. The idea behind MEM was that we were trying to get the "boot to splash screen" time to be the minimum possible so rather than hard coding copy sizes in the PBL this allowed us to vary the copy size and fine tune it. 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

E3 Memory Map?
by David J. Singer 15 May '06

15 May '06

Is the E3's memory map documented anywhere? I've had a quick look back through the list archives and it doesn't appear on the Wiki anywhere... I guess before I get too ambitious with the E3 I'd like to know what lives where. Is it possible, for example, to wipe out the PBL boot loader by mistake? And where does the Amstrad firmware fit in to all of this? I'm still using the example 'linux.pbl' file (or a derivative thereof) from http://the.earth.li/pub/e3/2.6.15/ . Is it possible to wipe out the Amstrad firmware to gain more space for custom stuff? -- David J. Singer doc(a)deadvirgins.org.uk "Time flies like an arrow, fruit flies like a banana"

2 1

e3-hacking- making it work overseas
by Alena 14 May '06

14 May '06

Did anyone one of you succeed in hacking e3 to work overseas. Appreciate if you can give some info...that will greatly help people like me. Alena

1 0

Re: [E3-hacking] JTAG/Anyone got a broken E3?
by David J. Singer 11 May '06

11 May '06

Matt Callow wrote: > But TMS and TCK are not at the edge of the BGA, so the same method can't > be used to find them. It would seem sensible to assume that they appear > as more of the 8 pads labeled R40, but I've found that 3 appear to be > connected to Vss, 1 to Vdd and the other 2 are connected together! Ah, but notice that R40 isn't an 8-pin connector, it's an unpopulated 8-pin, 4-way resistor pack. I guess it's there to provide the necessary pull-ups and pull-downs on the JTAG pins, hence the reason that the pads on the left hand side are connected to the power rails. I'd hazard a guess that the JTAG "TAP" port, if it exists, is somewhere else on the board. A viable approach to finding it might be to look for candidate connectors/pads and check for continuity with the TDI and TDO pins on R40 you already know. Chances are, if you find such a "connector", it'll have the remaining JTAG pins on it too and it might then just be a case of trial and error with suitable JTAG hardware... -- David J. Singer "Time flies like an arrow, fruit flies like a banana"

1 0

JTAG/Anyone got a broken E3?
by Matt Callow 05 May '06

05 May '06

I've been trying to find the JTAG pins on the E3 again (with limited success). I'm pretty sure I've found TDI and TDO and I can probably find nTRST (if it's connected) but finding TCK and TMS is proving more difficult. TDI and TDO appear as 2 of the 8 pads labeled R40 (see http://mcallow.pwp.blueyonder.co.uk/e3/img_1986.jpg). I found these by using a multimeter to test connectivity between the board pads and the CPU pins. This is possible with TDI, TDO and possibly nTRST because they appear at the edge of the CPU BGA (i.e. U17, U16 and U15) and I was able to poke a very thin piece of wire between the CPU and the board to make contact to those pins, one at a time. But TMS and TCK are not at the edge of the BGA, so the same method can't be used to find them. It would seem sensible to assume that they appear as more of the 8 pads labeled R40, but I've found that 3 appear to be connected to Vss, 1 to Vdd and the other 2 are connected together! So, I've been looking on the web at how other people find JTAG pins and it seems that one way is to remove the CPU with a heat gun and then trace the PCB that way (at least that's the way it was found for the NSLU2). So, this brings me to the topic of my post: Does anyone have a broken E3 that they could remove the CPU from and trace the board? I know it seems like a brutal approach, but It's probably the most reliable unless anyone else has any better ideas? Matt

2 2

kernel compilaton question.
by David J. Singer 01 May '06

01 May '06

I'm having a little problem getting a hand-rolled kernel onto my E3 and wonderded if someone could just point me in the right direction. I've downloaded the linux-2.6.16 sources, applied all the patches from http://the.earth.li/pub/e3/2.6.16/ (aside: 07-ams-delta-defconfig fails for some reason so I had to do that one by hand!) then done a: make ams_delta_defconfig && make uImage The 'uImage' that's produced has a load address of '0x10008000' and results in "Verifying Checksum ... Bad Data CRC" error when I try and flash the E3. I suspect this load address is wrong. The pre-built kernel from the above URL has a load address of '0x11d00000'. What am I doing wrong!? Regards, -- David J. Singer doc(a)deadvirgins.org.uk "Time flies like an arrow, fruit flies like a banana"

2 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

e3-hacking May 2006