Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
kugel.:
You said "low usage", not unused. And even if there's an unused part, the second problem is still there. You want to boot into an environment prepared for another piece of software.
atomikpunk:
Well I showed calculation of the unused space in a particular library block so I thought it was obvious I wasn't thinking about overwriting the OF code ::)
As for the "prepared environment", I don't see why we wouldn't be able to do so, in the first or second "stage" of our bootloader ???
Bagder:
--- Quote from: atomikpunk on September 02, 2008, 10:49:52 AM ---As for the "prepared environment", I don't see why we wouldn't be able to do so, in the first or second "stage" of our bootloader ???
--- End quote ---
I agree and this is done on a few other targets with success. If we do this for a known OF version we can learn what it sets up for us and not.
And of course over time we make the Rockbox code setup things as good as possible on its own so that we get less and less reliable on the OF init.
Either way, there's nothing saying that a first "ugly" approach can't be done first to get something going and then it can be improved later on. Iterative development is the key to success.
funman:
I don't understand in which way you want to do it:
- In the bootloader insert a call to the routine which loads library blocks in memory, and then branch to that location.
- In a studied library block, insert a branch in the same way we do it for now in OF with mkamsboot, which will branch to the code we inserted at the end (in the padding)
- Voodoo
atomikpunk:
Ok maybe I wasn't clear at all after all, so here are my thoughts on this.
* We keep the actual code that hijacks the boot sequence
* If a particular button is pressed/held/whatever, we continue in a so-called "first stage bootloader", else we simply get back to the OF
* The first stage bootloader loads the second stage bootloader from ROM to RAM and branch to it
* The second stage reads the NAND and find the rockbox firmware
* Launch the rockbox firmware
Using this approach we don't rely at all on the OF be it for initialization or anything else because anyway, I don't think they anything we can't do! :)
There is a bit of development to do to get there, but nothing huge and in fact it can be quite easy and straightforward...
First stage bootloader
The first stage would be located in the firmware block, after the used part (that is after the code and the variable initialization sections). It needs to be as small as possible to fit every possible OF files. If we find out that we can increase the firmware block size, then we are in luck. If not, we may need an alternative location for that. I assume that we will a) have enough space in the OF file without modification, or b) we will be able to increase the firmware block size.
Its job is:
* Intercept a particular signal (a button or something), and if not set, boot back to the OF (its job end up here in this case)
* Find (or maybe it should already know) the second stage bootloader
* Copy it from ROM to RAM
* Jump to it
Second stage bootloader
It would be located in a library block with enough free/unused space to hold it. The best place to put it would be in the "DEADBEEF" area, which is in fact junk in the clip firmware. (reminder: each library block contains: a header, a code section, a variable initialization section, 0xFF padding up to the next 0x200 border, DEADBEEF padding up to the end of the library block). Once loaded into RAM, the first stage bootloader jumps to it.
Its job is:
* Read the NAND flash
* Locate the filesystem
* Read the filesystem and find the firmware file
* Read the firmware file into RAM
* Jump to it
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version