-----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