Not an update (I can hear you all sighing) but, a little forum for discussion here as I would like to hear your comments on the issue.

In the event that a new efika.forth script is released (which it will be, eventually) I was wondering how best you guys could install it. Rather than slave away on something very clever, I have decided to keep it simple; editing one line into nvramrc to boot the script, like David Woodhouse's Fedora instructions tell you.

So, you'd get efika.forth installed somewhere on a USB stick or disk, and making sure the device will always be there for you (this is the bit I hate to impose on users), you add
To your nvramrc. You may also set boot-file and boot-device and auto-boot? true, and an appropriate timeout, and this will be executed *after* efika.forth runs, so you needn't edit the bottom of the efika.forth script.

My problem is, how do you get it there? If it was on every distribution CD, that's fine, but then does it get installed to the disk? Can we use efika.forth - and edit the last line appropriately - to make booting into your new Linux easier, after install?

I'm simply curious as to how you guys think it is better for you.

On another issue, how would you take Genesi putting it's foot down and submitting a patch which removed all support for fixing the device tree from the Linux kernel, and relied totally on the efika.forth script?
Personally I would love this, with a simple check in the Kernel source which looks at the firmware revision and makes sure it's at a certain supported level (if it does not match or is too low, then you have a problem :)

I am also going to ditch support for the original firmware, and rely on the 20070122 Firmware Update for setting up AC97 properly. I hope you don't mind.

Does anyone also have any requests for updates or functionality they would like to see in it?

_________________
Matt Sealey

please release firmware updates instead of efika.forth scripts. it's the better solution IMHO.

BIOS manufacturers do it, so can you. 8)

The argument about "it's easier to leave a device in an unuseable status with firmware updates" is valid, but with well tested firmware files it can be minimized.

Please talk to support@efika.de about new firmware.

I guess nobody cares, so.. project abandoned.

Well done, everyone.

_________________
Matt Sealey

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.

Currently things *just work* so people don't care. They will care if things begin to break.

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)

Hi Markus, don't mind Matt. He is a little edgy because we have dealt with a bunch of complaints and difficulties over the last 15 months as it relates to the EFIKA firmware. Matt has been the focus of the problem and not the hardware designers. Matt has his own opinions about the situation. The technical lead has another.

We have three new designs coming. Two are very closely related and the other is something else. Ideally, what we would like to do is develop a common interface at the firmware level between all the operating systems that target the next generation hardware. That is the goal. We continue to see too much energy wasted trying to keep up with the latest Linux kernel releases.

We see two ways to break out of the cycle, either define a new platform in the Linux tree (outside of CHRP) or just start "EFIKA Linux."

Matt's effort here seeks to collect feedback to help us understand developer/user desires and expectations better. Answers that we may not agree with still are answers and we appreciate them.

Thanks for your feedback.

R&B :)

_________________
http://bbrv.blogspot.com

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.
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

You must admit that being part of a community is one part. Having a real life is another one.

That USB binding fix you explained to me by the way.

I agree that it's a shame what came out of the dozens and dozens of efikas you gave away for free - including my not yet finished project... All I did so far is building those shiny net-install images. That ain't much..

Let's try to analyze why so few people actually got useful software up and running:

- people are lazy
- people like free stuff
- people can't write FORTH
- the linux kernel ain't easy to understand if you don't have a degree of any kind. that's why many software packages coming from the community are written in python/ruby/etc. look at KDE's plasma plugins for example. most of them aren't written in c++.

I myself am studying Electrical Engineering and now after 5 semesters I begin to understand the complexity of hardware! Well, now that I completed my basic studies my knowledge seems to grow exponentially. :roll:

- last but not least even if I wanted to fix the firmware I wouldn't be able to, because it's closed source.

What I would like to see for future products from bplan is an open source firmware on hardware that is easy to "unbrick" if the non-professional programmer messed around with the firmware and failed.

But I guess this won't happen because bplan seems to have licensed the firmware from another company.

And yes, in my opinion people should delegate "more power to the firmware". In general this means: if you can make the OS simpler if you fix the firmware then do so.

This is a quick write down and isn't meant to be a rebuke saying that everything bad and evil. Resume: Development ain't an easy task for everyone! And people are lazy if they are pre-payed (getting the hardware for free).

Regards,

-markus

I'm sorry but if you guys can't learn Forth you'll have no chance fixing Open Firmware whether it's Open Source or not.

No amount of firmware source code will make the fixes more forthcoming (pun very much intended). The fact that you want non-professional, possibly beginner programmers to tinker with the firmware and even potentially brick boards even with an easy way to undo the mistake.. well.. this is exactly why we have a closed source firmware, written by talented, well-experienced programmers.

_________________
Matt Sealey