Andy Green wrote: > The fact they aren't afraid of it isn't really telling us it is > "generally useful for production device" though.
Are we targetting the fetters and shackles faction now ? I thought they were happy enough with the iPhone ;-) > It leaves open > different kernels and so on, but we can nuke them too and then our > situation is deterministic. Same applies for the boot parameter line. Call it /boot/uImage.param if you want, then you can rm /boot/uImage.* > Obviously there is no technical difficulty to do it for NAND or SD. I > am trying to avoid the whole class of behaviour-changing variable hidden > in the device though. It's exactly as much hidden or not as the kernel proper. The problem with how these things are with u-boot is that they live in different domains, e.g., it's hard to access or even change the boot parameter line from the kernel. It's actually sufficiently messy to do even within u-boot. No surprise this causes problems. > Is there any benefit to that? Less knowledge about how the system is supposed to behave in qi. In GTA03, this would basically reduce it to only a small set of devices with a standard configuration. (Yep, you're right, I2C has there as well.) Maybe 2/3 of the GPIOs can remain at their reset default. So when we move GPIOs around in the future, you don't need to add yet another board variant to qi, only because something has changed that qi doesn't care about anyway. - Werner
