Neo, uboot, and Bricks
celeber2 at gmail.com
Tue Sep 11 05:44:19 CEST 2007
> Not having a debug board, I've been very careful to stay away from
> anything concerning uboot. I've never connected to my Neo while in
> uboot mode until the "nand erase blah blah" command needed to be used
> to flash the 2007.2 images. Now there seems to be a problem with a
> UART switching modes between a console and gsm and the current
> workaround is to remove the console=/dev/ttySAC... from the
> bootargs_env. This workaround does indeed get my Neo running again
> after setting it and performing a saveenv afterwards. All this leads
> to my question(s).
> Can my Neo be bricked my messing around with the settings in uboot
> mode and writing them to flash? What dangers are there in playing
> around with some of the settings in uboot mode?
> Finally, how will I eventually add the console=/dev/tty... back to
> bootargs_env? By going into and editing it again - and possibly risk
> bricking it? Or does reflashing the kernel bring it back again?
> I'm not normally afraid to experiment - I just don't want to brick my
> Neo and would like to know the dangers involved here.
I suggest Neo should have 2 loaders(or 2 parts), one is in charge of
console, update and essential hardware initialization, it will never be
updated, another is in charge of phone relative hardware initializations
and functions, and then loading linux kernel, it can be updated safely.
If so, I think we don't worry anymore about bricking our phone when we
are updating. :)
I don't think it's hard to implement but may take some times because we
should re-design uboot. :)
More information about the device-owners