Hello. On Tue, 2008-12-09 at 21:59, Daniel Ribeiro wrote: > 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.
Well, people know that I'm not a fan of this modder scene. This is only possible if you get a Motorola firmware image from somewhere. I get your point, but it does not change my mind. > > 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. High hopes for such an highly integrated system like a smartphone. Future will tell. > > 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. As long as there is no easy, save and legal way to do this. > 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?) To make it clear. I don't have doubt that you will find a way to make it work with minimal changes to blob. I'm talking about making it harder for people to get the system fully running. > 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. Of course it is still different in that it is a real brick if anything fails while flashing the bootloader. Power failure due to empty battery is a nice and often then option here. If that happens for other code groups you can just start a reflash. When your bootloader is dead you need JTAG. I know that other people flash it already, but I also know that a lot people exclude it from flashing to avoid the remaining risk. > 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. I'm doing with different smartphones and prototypes of it that I'm well aware of this. Would not be the first device I see making some magic smoke. :) Again my point is just that we should not give potential users another problem to worry about. > 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! I use it because it is fun hacking on it and it was my way into linux on smartphones. If I kill a device while doing this it is not nice but not dramativ either. For a user that just likes to have an alternative system running on his device this is another story. If OpenEZX would like to come out of the toys-for-developer corner we need to offer the user something. Most of them do not care about having a 2.6 kernel. They ask what else we can offer. And if we like to be a solid base for stuff like Qt Extended, Android or FSO, we need to make compromises from time to time. (Yeah, I had to learn such lessons myself) > 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! ;) Nice idea from moto. ;) Back to the topic that shows me that you are not interested in having such a patch. I'm well aware that you are the driving force in OpenEZX for a long time while myself is getting in-active more and more. That leaves me two options a) let the issue open or b) kick my ass and prepare such a patch myself. I think you would not have a problem with such a patch as long as it lifes in his own branch which ezx/current has no default dep on? regards Stefan Schmidt
