On Tue, Dec 9, 2008 at 7:47 PM, Stefan Schmidt
<[EMAIL PROTECTED]> wrote:
>> This is more a bootloader issue than kernel issue. We need a
>> bootloader that resumes to PSPR instead of using a fixed memory
>> position for the resume address. I have this ready here, but im afraid
>> to test it on one of my phones. Anybody with a "semi-bricked"
>> a780/e680 can help us on the initial testing. For gen2 this will be a
>> little harder, as there is no source code for the gen2 MBM, i can hack
>> the asm to resume to PSPR, but its more dangerous than on gen1.
>
> Let resume depend on a newly flashed bootloader makes it a showstopper for a
> lot
> of people.
>
> Using gen-blob for all kind of stuff that the flashed blob gets wrong for init
> the hardware is great and easy to do as we can leave the first bootloader in
> place.
>
> On the other hand we have to rely on the first bootloader for the resume. And
> frankly, I see no way around this when we like to reach an audience bigger
> then
> three people that are brave enough for flashing a new bootloader.
Hundreds of people flash their ezx boot loader every day. Hundreds
flash the signed
BP code groups, which is even more dangerous than flashing the ap boot loader.
> I hope I have the facts still right in my mind, so please correct me here if
> I'm
> wrong. With the standard bootloader Moto uses the approach to write a special
> bit muster into the first ram page, the bootloader checks this pages and
> resumes, instead of completely re-init, the machine.
Correct.
> Problem is that such a reserved first-page is not really loved in the kernel
> community.
Correct.
> I hope this was all right so far. While there are some machines inside the
> kernel that have such a mechanism it is not very likely that we can push it in
> for our machine, too.
>
> We still can have such a patch locally. I know, merging all in the kernel is
> the
> goal, and you guys know that I'm in favour of this like you are. But being
> realistic it is also unlikely that we will be able to push all stuff upstream.
> There will always be some sort of small patches that we need, but get not
> accepted mainline.
I don't agree. Everything can be written on the right way and pushed mainline.
> If I balance the facts that we a) keep a local hack or b) only have resume for
> people with a newly flashed bootloader, I go for a without doubt.
Once the boot loader is proven working, there is no greater risk. It
can be flashed
on a million of devices and it will work.
I don't plan to replace the original blob with anything fancy like
gen-blob, my plans
are to do only the minimum that we need for resume. Fancier stuff can be left to
a safer place on flash.
Let me introduce some technical stuff, to explain better what i want
to do, and what
i have accomplished so far...
Blob itself is split into 2 "code groups".
The _second_ one is written in C, runs on RAM and is responsible for the USB
driver/downloader and for loading the kernel to RAM.
The _first_ one is written in ASM, runs directly from FLASH, and does basic
hardware initialization and loads the second blob code group to RAM.
We need to change only the _first_ group, the one that runs directly from flash.
The second group can be reused, we don't need to change anything on it. We build
the first group, and append the second group from the original firmware.
The needed change is:
/* for exit sleep/user off */
+ /* PSPR */
+ ldr r1, =0x40f00008
+ ldr r2, [r1]
+ cmp r2, #0
+ beq check_ezx
+
+ /* OpenEZX */
+ ldr pc, [r1]
+
+check_ezx:
+ /* Motorola EZX*/
ldr r1, =FLAG_ADDR
5 instructions were inserted on the code, compatibility with the original
firmware is kept. AFAIK this code is correct, but maybe someone else
can confirm this to us. (Harald?)
Of course, people (me included) are afraid to do anything that can brick
their phones, but once the code is proven working, the risk goes to 0,
and it is as safe as flashing any other area on flash.
If you are really paranoid, note that:
1. With the right EOC register values, and enough charging time, in
theory, we can cause an a1200 battery to explode;
2. With some PCAP register values (and again, enough time), we can
burn the PXA core by over voltage;
3. With some PCAP/EOC register values, we can even burn your PC USB
port by draining too much current from it.
You know the risk, and you use OpenEZX anyway because people tested
it and proved it is safe, same with the boot loader, once proven safe, people
will use it!
As a side note, if you write 0x5a5a5a5a to 0xa000000c (this is on RAM),
and blob reads this at boot (you reboot fast and memory gets preserved)
you will also end with a "bricked" phone, try yourself, I've already bricked
mine this way. All i did was a 32bit write to _RAM_ followed by a
reboot. This should be safe! ;)
--
Daniel Ribeiro
