* Andy Green <[email protected]> [090304 09:56]: > Somebody in the thread at some point said: > | * Andy Green <[email protected]> [090302 15:55]: > |> Somebody in the thread at some point said: > |> | * Andy Green <[email protected]> [090302 15:21]: > |> |> Somebody in the thread at some point said: > |> |> | Dear Andy, > |> |> | > |> |> | Andy Green wrote (ao): > |> |> |> Otherwise, they will simply propose people keep using U-Boot and > |> not Qi > |> |> |> as their "fix". To the extent we pull some extra current until > GSM is > |> |> |> turned on, Qi is then compatible with old and new kernels. So > it's the > |> |> |> best path right now AFAICT. > |> |> | > |> |> | Would it be too inconvenient to have a 'correct' Qi and a > |> |> | 'backwards compatible' Qi? > |> | > |> |> It's not inconvenient if it can choose what to do at runtime, > based on a > |> |> sign from the U-Boot header that the kernel it's going to run can cope > |> |> with the right thing. > |> | what does this mean when booting from SD? No u-boot header involved > |> | there, no? > | > |> There is the same U-Boot header on our kernels no matter where you're > |> booting it from. > | > |> And it is a fixed-length (64 byte) header. > | So... in the end you decided to just revert it?
> Reverting it has made a solution no worse than U-Boot, I got halfway > through a version-checking patch and more urgent things have come up. > So don't worry, I will try to optimize power in those few seconds > between boot and GSM being turned on by initscript for you. ok, thanks :-) > -Andy Klaus 'mrmoku' Kurzmann
