i've opened a new topic here...
that's right, there is no PHY* for this nic.
A new Pegasos Device Tree Supplement could not resolve this issue.
that's from my box with 2.6.28 vanilla:

_________________
acrux _at_ linuxmail _dot_ org

Right but I just realised, there are two ports, and it's weirdly connected port 0 to the gigabit riser and port 1 to the back of the system. So port 0 will always fail.

It looks like the driver initializes fine, but then just doesn't work.

How on earth did you get it to work on yours then? Or did you not?
Well, there are two ways to look at it

1) this specific problem could not be fixed with a device tree fix
2) the general problem - that the PHY is "not detected" and it does not know what type it is and the SRAM address is hardcoded in the driver - should be stuff in the device tree (check out what Linux or efika.forth does to add one to the Efika).

Basically there should be an ethernet node in /built-in which properly describes the Marvell ethernet, and only one port, the reason it tries both right now is because.. well.. the ethernet node is really terrible and I don't think it formats it the way a driver would want to see it, plus there is no special information about it.

An ethernet node that is disabled could be engineered too so it doesn't even check.

But anyway, eth1 should work for you? Or it doesn't? What is the exact behaviour? I need to tell Lennert something about what is wrong, not just "it doesn't work" or he will not know what to look for..

_________________
Matt Sealey

I've been bisecting the problem today and the regression is indeed with one of Lennert's changes, but I would certainly not have bet on the innocent looking "mv643xx_eth: use longer DMA bursts" patch (git commit identifier cd4ccf76bfd2c36d351e68be7e6a597268f98a1a).

With this commit reverted, Gb ethernet is working again with kernel 2.6.27 on Pegasos.

Could you post the "reverse patched" mv643xx_eth source here ?

BTW: There's a known problem with gigabit on Peg2:
If you boot into linux after a powercut, gigabit shows up with a strange MAC, which confuses udev. Rebooting the system will bring back a stable MAC again..

It's not quite ready. There are a couple of other bugs that turned up. It will be posted when it is ready, and no doubt sent to the linux networking list and linuxppc-dev at the same time or before.
Something like 00:2b:2fad:01? :)

It's a known bug in the firmware and the fix is to force the MAC address - on SuSE and Fedora, edit /etc/sysconfig/network/ifcfg-ethX (where ethX is whatever your interface is named. I called my mv0) and add a line

LLADDR='00:0b:2f:aa:bb:cc'

Where the last 3 tuples are anything you like really (the above is also valid :) depending on what other bplan hardware you have around or if you know what the MAC address SHOULD be (00:0b:2f is bplan's OUID)

Since this is done after udev you will have to fiddle around with /etc/udev.d/70-persistent-net.rules somehow too.

_________________
Matt Sealey

Sounds like you've seen the same effect:
On coldboot, gigabit has this MAC:

00:0b:2f:79:ce:11

( I made some stupid script with rmmod and insmod and ifconfig .. which manages to get the network up without reboot.)

All the next reboots gibt me this MAC, which then remains stable..

00:2B:2F:DE:AD:01

Try this on SUSE or Fedora. I am not sure about what happens on Debian.. what are you running?

Edit /etc/udev/rules.d/70-persistent-net.rules

Add the lines: Add /etc/sysconfig/network/ifcfg-mv0 and /etc/sysconfig/network/ifcfg-vr0: Get rid of any ifcfg-eth* scripts or back them up.

That seems to work for me.. I didn't test it much though as I don't use Marvell ethernet.

_________________
Matt Sealey

Latest, never officially released bPlan firmware update (dated 20061215 or so, IIRC) fixes this problem, among others. I think this firmware was only released as "internal beta" for testers, and for some users, who have explicitly asked for it. Since i have it in my board, GBit eth runs just fine, w/o any MAC quirks on reboots. Note the same board had the problem before i installed this firmware.

Of course, one could still use one of the workarounds, like the one Matt recommended.

Where did you get that from?
Not could, SHOULD. I'd recommend you downgrade..

_________________
Matt Sealey

I hacked bPlan site, and stole it. (Stupid question, stupid answer.)
Indeed, how smart idea is to play with the firmware of a machine which works 24/7, without a single problem for 1,5 years... Right.

Any *real* reasons, apart from the fact that in your opinion i shouldn't have this specific version?

You should not, but I did. Different usage scenario. See below.
I do a lot of software testing and user support, where relying on the improved features of the beta firmware (and different selection of bugs) is a huge disadvantage. You also do some user support, but from the 27/4 I guess, this machine runs as a server, where the fixes are more important than having the same firmware as the rest of the world.

_________________
CzP
http://czanik.blogs.balabit.com/

What a strange argumentation !

I bought 3 PEG2 and dedicated one to a backup&network server. Unfortunately the OF behaviour (HD and NIC related) was so annoying, that I contacted bplan, which promised a fix with a future firmware.

Not finding any fixed firmware for years, I now started thinking to replace the backup-server with an intel machine to get a relyable solution.

Reading about the existence of a fixed firmware, which is somewhat kept secret, really makes me angry.
This is a information and support policy I cannot stand.

When will be the official release of the fixed OF ?
In 5 years ?

Unfortunately for you it is based on quality assurance and available time.

Each, even minor, change to the firmware needs to be validated and put through a long-winded test suite on EVERY hardware revision to make sure it did not introduce any serious regressions.

Even something very minor like changing the font could cause probems on different framebuffers, different graphics cards (even within the same chipset), different PCI buses.

The simple fact is that given the number of revisions of Pegasos II (4 public) and Efika (1 public) plus all other support contracts, the number of boards which need to be tested is too large to simply offer someone a simple fix for this.

We don't give out the "fixed" firmware because it NEVER got run through those tests. At bplan for 6 months (Sven coming once a month) and a group of us played with the firmware code and made many, many changes. Only the official fixes ever went through testing but this firmware never leaves the office.. it's not ready.

The experimental firmware which seems to have been released was just to see if we COULD do things. As a mere side effect it rolled in the official firmware fixes. There can and will be several, possibly several hundred, weird effects which it may evoke on any hardware revision. I can think of a bunch;

* ISO filesystems may not work under certain circumstanes (also outputs a huge amount of debug code)
* FAT filesystems may not work under certain circumstances
* ATA disks may not detect properly as the timeouts were fudged (by me)
* weird USB problems
* FFS/SFS support may be broken

The idea was to flash that firmware to the Pegasos, see if anyone had problems or if it fixed or broke a specific feature (for instance change to the filesystem code) and then flash it BACK to the original version which was always supplied at exactly the same time.

If you're running it, you forfeited all support for your board, so you can't complain about not liking it.

You may never see an official firmware fix, although the plan is to at least publish the Aura firmware at least for the Efika, PERHAPS for Pegasos, but given the Pegasos is end-of-life and not produced or sold for some 3 years.. I think you would understand why we might not.

In the end this is just a simple MAC address problem which can be easily fixed. It may even POSSIBLY be able to do it with a small script in nvramrc;
NOTE: THIS CODE COMES WITHOUT WARRANTY EXPRESS OR IMPLIED AND NO SUPPORT IS OFFERED OTHER THAN ITS PROVISION ON THIS WEBSITE. GENESI DISCLAIMS RESPONSIBILITY FOR RENDERING HARDWARE INOPERABLE AS A RESULT OF THIS CODE.

You've been warned. I'm not really going to work on this further. I have some other ideas for removing the arch/powerpc/platforms/chrp/pegasos_eth.c file and making it generic against device trees but this requires some significant thought (and a generic SRAM driver and some extra magic) which I don't have time to go into right now..

(Edit: note I removed the long code fix as it was broken. I have a better way. Will publish later).

_________________
Matt Sealey

I just tested this and it works. Who needs a firmware update? Just add these two lines into nvramrc (nvedit, ctrl+c to finish, nvstore) and replace the first value on each line with your MAC when the Pegasos boots the first time. For instance mine says 00:0b:2f:60:bb:35 so the code to fix my Pegasos is;
In other news 3 patches were just posted to the Linux netdev mailing list which fix all the problems with Pegasos ethernet. Until a patch hits LinuxPPC-dev which fixes the port0/port1 problem (Gabriel already wrote it, it just doesn't enable port0 in the platform code) it might act weird but you can use udev tricks to work around it until then.

I had a thought about a bit of a device-tree hack to fix some extra entries in the device-tree, and add a generic SRAM driver which will allow automatically allocating RX/TX buffers in the Marvell driver itself based on an OF platform device. I might publish it later this month, or February.

_________________
Matt Sealey

Hi,

I just tried your nv-script but the result was different to my expectations(Firmware 1.2):

The MAC-part of "0x000b2f60 0xf1002818 l!" showed up in the MAC-address in endianes-changed-order. The other line's data was zero-filled.

So I got a MAC like 60:2f:0b:00:00:00 ..reported by kernel and ifconfig.


BTW: There's nothing wrong about your argumentation about regression tests to prove a level of quality. Nevertheless, the PEGs & Efikas were not designed to serve in airborne or life support applications. The real customers are computer geeks, willing to take part in some development process. Most of the routers, gfxcards, computers I flashed, survived at the end. So if I'd kill my system because of using beta firmware, I'd never come up with the idea to ask for free support.