* add support for OF version 01.01.17 in mkamsboot
* introduce and implement oled_brightness function
* configure voltage CVDD2 to 2.8V (like the OF does)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@30831 a1c6a512-1295-4272-9138-f99709370657
Merge the various arrays holding model specific information into a
structure and give it a distinct name. Avoids problems when linking with
Rockbox Utility.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29177 a1c6a512-1295-4272-9138-f99709370657
These models are restricted to OF >= v02.3.31, probably because of a
hardware change
The OF checks a version string located between 0x0 and 0x200 in the
firmware block, so let's keep this part unmodified
We put our dualboot code at 0x200, and insert a branch + vectors at 0x0
That way our patched file will present the OF version to the fuzev2 OF
patching it, and we only waste 512 bytes on other models
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@27441 a1c6a512-1295-4272-9138-f99709370657
The field we thought was representative of the model is not, it has
changed in the past for fuzev1 and fuzev2.
For example the value 0x23 is found in 2 old fuzev1 OF versions, and in
the c200v2 OF
The only reliable way to detect the model of a given OF is by using the
built-in list of md5sums.
Modify mkamsboot and rbutilqt to load the rockbox bootloader first, and
then check if the model in the bootloader corresponds to the model of
the known md5sum of the given OF.
That way we can continue to present the user with a list of known OF
versions in case the OF is unknown to mkamsboot
Also explicit the dependency of main.c on mkamsboot.h in case the
prototypes change
Correct the header's description not updated in r21648
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@26248 a1c6a512-1295-4272-9138-f99709370657
We checked if the new firmware block (bootloader+ucl function+packed
bootloader & OF) fit in the OF file, but not if it would run properly.
For example the Clipv2 OF is bigger than 0x50000 bytes uncompressed, but
it fitted in this space when packed and concatenated to a packed
bootloader + ucl function and dualboot code (but we use 1MB of RAM and
not 0x50000 anyway).
Now we check that both bootloader and OF are small enough to be unpacked
at runtime: the unpacked data must be smaller than available memory and
not overlap with ucl function and packed data (although the unpacked and
packed data could probably overlap a bit, I don't know how to calculate
this and this could be quite complex).
total_size() is replaced by check_sizes() which will perform all the
checks and set an error string if the firmware can't be patched.
(both mkamsboot and rbutilqt modified accordingly)
The second problem is that dualboot.S assumed r3 and r5 were left
untouched in the device specific checks. This was undocumented and very
error prone when modifying these checks.
r3 is the last byte of packed copy (bootloader or OF)
r5 is the entry point of uclunpack function derived from r3, so move r5
calculation after the device specific code.
Even if r3 is currently unused in the device specific code, we store it
in memory after copying the ucl function, when it points to the last byte
of packed data (not yet copied at this point since we didn't chose if we
boot the OF or the bootloader), and restore it just before using it so no
restriction is placed on registers usage in device specific code.
Add a new variable ucl_dest in dualboot.S set by mkamsboot.c, which
represents the last bound of buffer where we copy the ucl function, and
then the packed data (bootloader or OF).
RAM_SIZE definition is moved from dualboot.S to mkamsboot.c new
model_memory_size(), where it is a bit better documented.
Tested on e200v2 and Clip+
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@24772 a1c6a512-1295-4272-9138-f99709370657
Dualboot works on the sansa clip+ by holding either the left "|<<" or home buttons.
The USB pin is still undiscovered at this point and should replace the home button when found.
By including the home button for dualboot we avoid bricking due to a single button failure.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@24561 a1c6a512-1295-4272-9138-f99709370657
UNTESTED, could ver well brick your Clip+
If it works, booting should just be delayed by a small delay (perhaps
not noticeable)
Hopefully the Clipv2 checks will work for Clip+ and then we'll be able
to test the other Clipv2 code (LCD/button)
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@24219 a1c6a512-1295-4272-9138-f99709370657
- split out standalone functions to a separate file.
- adjust and clean up Makefile.
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@23520 a1c6a512-1295-4272-9138-f99709370657
- Bump version to 1.0
- Add Clipv2 target
- Make mkamsboot work as a library (work by domonoky : FS#10185, with a few modifications by me)
. Use a macro with variadic arguments for error cases in functions which might error.
. Add detailed descriptions to functions exported by the library (in the header file)
- modify bin2c.c to produce only one pair of .c/.h files with several files embedded in it
- move files needing to be built by an ARM cross compiler into dualboot/
- commit produced .c/.h files (containing nrv2e_d8.S and dualboot.S built for Clip, Fuze, e200v2, c200v2, m200v4, Clipv2)
- Write a real README file
- cosmetics: indent dualboot.S properly, remove trailing spaces, limit lines to 80 characters
- comments: add/correct comments in dualboot.S and mkamsboot.c
- move back extract_fw.c to utils/AMS/hacking
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@21118 a1c6a512-1295-4272-9138-f99709370657
Error out if firmware md5sum isn't known, and leave the current code #if 0'ed for easier testing
git-svn-id: svn://svn.rockbox.org/rockbox/trunk@21073 a1c6a512-1295-4272-9138-f99709370657
