Qi for S3C2410

Andy Green andy at openmoko.com
Tue Nov 11 20:29:45 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
|>> and both are themselves canned actions.
|> There is a set of common canned solutions, such as changing the
|> loglevels, adding or removing consoles, increasing the dmesg buffer,
|> or overriding init, but there's no telling what happens in the next
|> iteration of debugging.
|> E.g., if some people have problems with the SD driver and you add
|> an option to vary the timing, that's probably something you can't
|> easily predict. And if your rootfs is on SD, handling this when
|> user space is up may not be an option either.
| That's why I think it would be a nice debug feature to have when that
| special need comes. The defaults should work for most cases, but when
| debugging why limit the developer to only append new settings?

Because it basically ends up same as U-Boot environment... at least by
inheriting the commandline from the bootloader we can exercise a light
touch in this append file to only set exactly those "debug features" for
"special need" that is required, without doing stuff like making the
filesystem image itself fragile to whether it runs from NAND or SD, and
which partition, etc.

I'd like to implement these features now, but it makes sense to take
your patches first I think: when are you planning to send them?

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list