Can't get ethernet connected on rpi400.

I’ve got my Raspberry pi 400 connected to a WiFi extender with an ethernet cable, this works perfectly fine in Raspbian (with the Raspberrys wifi turned off obviously) and in the firmware of the Raspberry while booting.

However, just as soon as RISC OS takes over and start DHCP discovery the indicator light for the wired connection on the extender turns off and RISC OS doesn’t get any IP.
Checking the network config in RISC OS tells me that it finds a “Broadcom GENET interface”, but it just won’t acknowledge the connection.
The status window gives me red crosses for “OK” and “Full duplex”, but “Active” and “Polarity” gets green checkmarks, no errors, no received frames but some transmit frames.

I’ve tested both RISC OS Pi 5.28 (16-Dec-20) and RISC OS Direct (January 21).

I’ve seen loads, well, two YouTube videos of people having no trouble at all getting a network connection on the Pi 400 in RISC OS so I’m probably doing something stupid, but what gets me is that it works perfectly in both Raspbian and the firmware boot process of the Raspberry.

Any ideas what might be at fault?

Everything works perfectly on both a Raspberry Pi 1b+ and a Pi 4b, using the same ethernet cable/WiFi extender (also, the same SD-cards for the Pi 4b and the 400), so there seems to be some hickup in the ege driver on the 400.

Is there anyone out there with a Pi 400 with working ethernet?

From memory, that build is just pre-Pi 400 support. There’s a specific Pi 400 build, but you’d now be better off with the latest Pi release, which includes Pi 400 support.

https://www.riscosopen.org/content/downloads/raspberry-pi
https://www.riscosopen.org/news/articles/2020/12/23/pi-400-coming-in-to-land

I have just tried fresh installs of both of ROOL’s RPi400 images and both worked. DHCP DHCP’d and the boots completed to the desktop.

The two images are similar, the RPi400 version has a keymap tweak to make PrtScr act as Break and a particularly purple backdrop.

I don’t know what is going wrong above. Perhaps DHCP, via EtherGENET, is timing out too soon for that router or network.

I have just tried fresh installs of both of ROOL’s RPi400 images and both worked.

Yes, that’s what I recommended above. Both will work. Fredrik’s ROM is from 16th Dec 2020 which I don’t believe had proper Pi 400 support at that point. The builds here: https://www.riscosopen.org/content/downloads/raspberry-pi do.

Very strange indeed, I’ve tried a few different RISC OS images but nothing gets the ethernet working on the 400.

However, when I move the sd-card and ethernet cable over to the 4b, ethernet is working.

Well, I’ll just use the 4b instead.

Thank you both for your help.

Fredrik’s ROM is from 16th Dec 2020 which I don?t believe had proper Pi 400 support at that point.

16-Dec-20 is the 5.28 RPi400 aware ROM as running here on my RPi400.

The builds here: https://www.riscosopen.org/content/downloads/raspberry-pi do.

That is the same link as in my post!

BTW, I’ve been trying these images:

RISCOSPi.5.28.zip with md5sum dc74a1fc03a22d3b7a80ec4cae4bd77d
Pi400.5.28.zip with md5sum a6ea5311ded2e441a11f9d3c8c03835a
RISCOS_DIRECT_528_Jan_21_a.zip with md5sum a812ace7f0b390274fdcc5538843324f

Reverified the md5sums to ensure that I haven’t used old downloads by mistake.

16-Dec-20 is the 5.28 RPi400 aware ROM as running here on my RPi400.

I just wanted to be sure he is using one of the 400-supported ROMs. Pi 400 support was only added in builds of RISC OS 5.29 (15 November 2020 onwards), before it reached 5.28. https://www.riscosopen.org/wiki/documentation/show/Raspberry%20Pi%204%20port%20status There’s a short period where it might be confusing whether he has a supported ROM or not. Going by the date of a RISC OS Direct distro may be misleading too. But, going by the above post, he’s using the latest builds.

That is the same link as in my post!

I know, and I had already posted the link prior to your initial post! :-)

I don’t know what is going wrong above. Perhaps DHCP, via EtherGENET, is timing out too soon for that router or network.

Is there a simple way to increase the timeout?

Is there a simple way to increase the timeout?

No. If slow DHCP is the issue then the workaround would be to configure networking with manually set IP address, gateway address and DNS servers. This is in the User Guide which can be downloaded from a link at the bottom of this page. This might help but I get the feeling there is something else going on here, but I don’t know what. Why does the RPi4 work but not the RPi400???

Is there a simple way to increase the timeout?

Not sure, David may know. But *DHCPExecute (after hitting F12) should force it to have another try. Failing that, maybe you could try assigning it a static IP, taking DHCP out of the equation.

Edit: beaten by David.

But *DHCPExecute (after hitting F12) should force it to have another try.

I have seen DHCP fail to complete, once only, and it might have been RO Direct, but a reboot sorted that.

Perhaps a little paranoia might be in order, but if this is a new RPi400 has something changed.

Not sure, David may know. But *DHCPExecute (after hitting F12) should force it to have another try. Failing that, maybe you could try assigning it a static IP, taking DHCP out of the equation.

Neither suggestion did anything… I’m thinking David might be right in that there might be some changes in the hardware. It’s a Nordic (Swedish) Pi 400, maybe they changed more than the keycaps. :-D

Oh, and let’s not forget that “OK” and “Full duplex” in the status dialogue is crossed out, also it says “Activity at 10Mbps”.

Perhaps a little paranoia might be in order, but if this is a new RPi400 has something changed.

It was bought as new, and I haven’t done any modifications to it.

However, I did take it apart last night to take some pictures of the board.
pi400.png

It seems there is a Microchip 9131rnxc instead of a Broadcom BCM54213PE, that may be the source of my problems. :-/

It seems there is a Microchip 9131rnxc instead of a Broadcom BCM54213PE

Bizarre! I can’t find any reference to this change, but that’ll certainly be the issue.

It seems there is a Microchip 9131rnxc instead of a Broadcom BCM54213PE, that may be the source of my problems.

What luck, a later version!

See this tear down which underneath to Pi logo shows a 2020 board as opposed to 2021.

See this tear down which underneath to Pi logo shows a 2020 board as opposed to 2021.

A quick glance says that there only seems to be the ethernet adapter that has been changed.

Using Raspberry Pi OS does pinout show any changed revision info. This is from mine bought when it was first released.

Raspberry Pi 400 Rev 1.0

Revision           : c03130

Raspberry Pi 400 Rev 1.1

Revision           : c03131

At least we now know there is a new revision and how to detect that from the outside. Any driver update may take some time.

If you need any betatester in the future, I’ll be happy to help out.

At least we now know there is a new revision and how to detect that from the outside. Any driver update may take some time.

Except for the LED setup (which is usually a vendor specific set of registers), the other PHY settings are pretty generic IEEE registers, so it’s odd that something doesn’t happen. To inch the worldly knowledge forward could someone try RMLoading this debug version and report back what it says – perhaps the Microchip PHY isn’t being spotted at all and so gives up as faulty?

If this thread is anything to go by, you may need to update the firmware (fixup4.dat, start4.elf) as well.