RE: [E3-hacking] E3 Memory Map?
-----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
On 16 May 2006, at 11:12, Cliff Lawson wrote:
-----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.
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
Cliff Lawson wrote:
-----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.
Hmm, I though PBL loaded and executed a block called 'LDR' and then that loaded a block called 'LINUX' ? Matt
On 16 May 2006, at 12:12, Cliff Lawson wrote:
-----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.
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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jasmine Strong wrote: [...]
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.
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 | dg@cowlark.com | specific things to say about killing?" "Quite | (dg@tao-group.com) | specific. It is, however, somewhat fuzzier on the +- www.cowlark.com --+ subject of kneecaps." --- Firefly, _War Stories_ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEaakOf9E0noFvlzgRAqUyAKC4I+X7sYTm5Q6Q2O7jvheUcLX9yACfc0qK YBvla+QbsDvhmxhB459bjMw= =x+tu -----END PGP SIGNATURE-----
On Tue, May 16, 2006 at 11:27:26AM +0100, David Given wrote:
Jasmine Strong wrote: [...]
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.
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?
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. --
participants (6)
-
Cliff Lawson -
David Given -
Jasmine Strong -
Jonathan McDowell -
Matt Callow -
Matt Evans