Subject: RE: [E3-hacking] E3 Memory Map?

From: Cliff Lawson <[email-masked]>
Date: Tue, 16 May 2006 11:12:41 +0100

> -----Original Message-----
> From: Jasmine Strong [mailto:[email-masked]]
> 
> 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

---

From: Matt Evans <[email-masked]>
Date: Tue, 16 May 2006 11:18:28 +0100

> Linux or perhaps even uBoot or anything your heart desires.

This is almost what Jonathan is doing - PBL loading littleLDR which  
loads uBoot.  I seem to remember he tried the simpler form of getting  
PBL to load a chunk containing uboot directly (Jonathan, was that  
with a LINUX-named chunk or some other PBL loadable?) but ran into a  
size limit.

If we could have PBL load uboot directly then that would be  
preferable - Cliff, what does PBL expect from a LINUX block, any  
checksumminess or compression we have to worry about?  (Although  
Jonathan's pre-uboot load shim seems to work now so it's probably  
moot anyway.)

Cheers,

Matt

---

From: Matt Callow <[email-masked]>
Date: Tue, 16 May 2006 11:19:10 +0100

> name "LINUX" in the module header.
Hmm, I though PBL loaded and executed a block called 'LDR' and then that 
loaded a block called 'LINUX' ?

Matt

---

From: Jasmine Strong <[email-masked]>
Date: Tue, 16 May 2006 12:19:36 +0200

On 16 May 2006, at 12:12, Cliff Lawson wrote:

> Methinks you missed the point.

Um, no, I didn't.  The point David was making was orthogonal to the
one you were making.

The reason we have not successfully booted 2.6 from PBL is that
for some reason DEBUG_MUTEXES breaks 2.6 booting from PBL
NAND (but not from a serial load).  Therefore, to boot from PBL to
date we have needed to use 2.4, which is obsolete and therefore
not cool.

-J.

---

From: David Given <[email-masked]>
Date: Tue, 16 May 2006 11:27:26 +0100

Jasmine Strong wrote:
[...]
> date we have needed to use 2.4, which is obsolete and therefore

If the problem is that PBL has left some piece of hardware in a state
that is confusing Linux, then simply booting Linux via littleLDR and
uBoot won't help; unless something touches and resets that same piece of
hardware, Linux will still fail.

Why not simply build a kernel without DEBUG_MUTEXES?

- --
+- David Given --McQ-+ "Preacher, don't the Bible have some pretty
|  [email-masked]    | specific things to say about killing?" "Quite
| ([email-masked]) | specific. It is, however, somewhat fuzzier on the
+- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War Stories_

---

From: Jasmine Strong <[email-masked]>
Date: Tue, 16 May 2006 12:31:07 +0200

> Why not simply build a kernel without DEBUG_MUTEXES?

No reason.  That's what I'm doing.

-J.

---

From: Jonathan McDowell <[email-masked]>
Date: Tue, 16 May 2006 11:31:30 +0100

> Why not simply build a kernel without DEBUG_MUTEXES?

That's what I did. Longer term I'd like to figure out why it doesn't
work obviously.

With regards to using LDR and putting u-boot in a LINUX block I confess
I didn't think of that originally, but I'd rather be running code that
we understand rather than having to spend more time reverse engineering
the Amstrad block format and where things need to go in the NAND to make
it happy.

I have a solution that seems to work (except for u-boot being quite slow
to read from NAND; need to sort the ready bit support out) and as soon
as I get over the cold I've been dying of all weekend I'll sort out a
release for people.

J.

--