I meant having the new device tree bundelt with the firmware and burned on the board is better than having an efika.forth script that needs a physical disk around.
It can't be done. Well, it can, but it relies on several things; I don't want to expose firmware internals but hacking into nvramrc requires it. This implies a closed source "installer" app, plus several support tools to optimize the efika.forth script into a suitable (smaller) format to fit into nvramrc which has seemingly limited space (far less than the 6-10kb the script is progressing to be) which to be honest I don't have the time or patience to write alone.
I asked for help, got two email replies, one of them didn't ever mail me back, and the other was Gunnar, who I know is already way too busy to really help.
It's easier just to load it from disk.
I think it's a good idea to move the device tree fixups out of the linux kernel right into the firmware. this should make things easier for other operating systems, too. (if we will ever see one)
And this is why I am annoyed and can't be bothered to update it anymore; Linux moves at such a stupid pace of patching and then fixing later, that we do not have time to make a stand against any decisions the Linux developers make.
An example; the SuSE kernel maintainers do not like the idea of having an external script to maintain the firmware, but the Linux developers want fixes like this kept out of the Linux source. The SuSE kernel maintainers submitted a patch taking code right from efika.forth and embedded it into the Linux kernel device tree fixups code; and then the Linux developers accepted it for 2.6.24 without contest!
There's also the other stupid stuff like device tree bindings changing on every minor version (i2c bus handling, "fsl," markings, names and properties moving in and around). USB was arbitrarily broken on the Efika because of this (and the current efika.forth release mades it worse because I missed one of the patch submissions).
We made a suggestion when the Efika board came out, that marking every device with things like "cell-index" is redundant given that the address of every PSC and so on is fixed in the chip relative to the MBAR. You can easily derive which unit you are working on from the address information in the tree. Yet, this was rejected; cell-index is a cleaner way. Last week I saw a mail which said, cell-index is redundant, because the device index can be derived from the address in the tree. This infuriates me somewhat.
Don't even get me started on the braindead bulls**t that is the current BestComm API, which arbitrarily trashes all the firmware tasks so painstakingly added to the board for added value and ease of development. None of it is designed with a view to supporting provided information in the device tree - it is all done from the point of view of the path of least resistance to an Acked-By: line in the kernel changelog. Not to say that Sylvain did not do good work; just everyone saw the problems, Sylvain pointed them out, and 12 months later it has not been touched.
Device trees are meant to be from hardware developers to software developers, yet the device tree bindings are designed by Linux driver authors who simply want to simplify their code; moving it to the device tree makes it "not their problem". 3 kernels later, and they move it back. The device tree bindings are so unstable, it is not worth keeping track.
It's actually far more difficult to maintain efika.forth than it is to just let the Linux guys break Linux, and then fix it however they like. You seem to all be happy with that situation.
efika.forth is meant to bridge the gap between the current firmware, the Linux/device tree bindings, and the really vague possible release of a new Efika 5200B firmware build which fixes any or all of the problems; and the possibility that the next firmware build completely obseletes efika.forth would be very pleasing, except I'm not confident that it will actually keep track with Linux development, and it will still miss things that people complain about. Then we have to support more firmwares, and more fixes.
Is it really going to have to be my job to fix all this stuff? I was under the impression that we have grown and fostered a community here, but most of the people in it do not want to do anything to help. I have tried softly pushing people to fix things themselves but ended up explaining it fully a week later anyway (USB binding fix).
I don't think it is so much to ask that someone else maintain it if it is really that important. I'm happy to give up some time to explain things and help, but I cannot be the only Forth coder here, nor am I the only one concerned about keeping firmware fixes out of the Linux tree.. more and more, though, it really does feel like that.
Matt Sealey, Genesi USA Inc.
Product Development Analyst