Can't get ethernet connected on rpi400.

@Sprow – unfortunately I’m not in the UK. Greetings from Sydney, Australia.

Thanks for the offer of an exchange unit, but the postage will be rather pricey.

For now I’m happily using the machine using a USB→ethernet dongle, but hopeful we can find a fix for the motherboard ethernet.

I did wonder though whether *RMLoading the test module after getting into the desktop might be too late (for whatever reason). Would it be possible to insert it into the !Boot sequence pre-desktop and over-ride the ROM-based module? And if so how?

Have a look at $.!Boot.Choices.Boot.PreBoot to see if you have DeepKeys (may be prefixed with a few exclamation points). If so, that’ll show you how to load a module at the start of boot.

Essentially you make a subdirectory in that location, put the module in there, and create an Obey file to RMLoad it. I’d give a better description, but I’m at work right now (break time, yay!).

Tested this evening … with the ROM version of the module, EtherGENET fails to pick up DHCP, and the network light on the wireless extender goes out before the DHCP process aborts and the desktop appeared. That’s the original reported behaviour.

After *unplug EtherGENET, and dropping @Sprow’s EtherGENETD into $.!Boot.Choices.Boot.Predesk (alongside DeepKeys etc), on reboot the test module spat out the register dump, but still failed to pick up DHCP. However, the network light remained ON throughout the boot process. All else remained the same.

Register dump:

Address  :   9 8   B A   D C   F E   1 0   3 2   5 4   7 6   9 8   B A   D C   F E   1 0   3 2   5 4   7 6
FA207D78 :  1000  7949  0022  1642  0DE1  0000  0064  2001  0000  0300  00FF  0000  0000  0000  0000  2000
FA207D98 :  0000  00F0  0000  B478  5002  0000  8021  1000  0000  0000  4000  002F  2400  0000  F800  0300

@Sprow – unfortunately I’m not in the UK. Greetings from Sydney, Australia.
Thanks for the offer of an exchange unit, but the postage will be rather pricey.

@Sprow If you’re unable to switch the complete unit with someone, we could switch motherboards. Let’s call it Plan B, since I imagine postage would be a bit higher.

Thanks both, posting from Australia or Sweden is an airmail stamp intensive solution. In the meantime I’ve gone on a hunch that the non-UK Pi 400’s which are out of stock would be more likely to have the non-Broadcom PHYs so have ordered one of those speculatively. Due w/c 7th March (slipped) 14th March so not long now… (slipped) 4th Jan 2023 Oh dear Fredrik’s loaned me his…in progress 14th April.

However, the network light remained ON throughout the boot process. All else remained the same.

I think that’s just due to the manufacturer specific registers controlling the LED clashing (I removed that from the debug version just in case it was significant).

@Sprow

Are you still waiting for a new unit?
If so, maybe I can just send you my one, since I can easily get it replaced. (Actually already got one extra.)

I ordered an out-of-stock-at-the-time US layout on the grounds that it was out of stock so when it comes back in stock it must be the ‘new’ layout with the problem PHY. Although the due date is quoted today at 18th April, what’s actually happening is it slips 1 week per week so I contacted them and asked what the real due date is: 4th Jan 2023.

The UK one I got (which was in stock) was the normal Broadcom PHY.

So if I can borrow/buy yours that’d be far quicker, drop me an email (on the home page of the site hosting the test driver, above). Thanks!

@Chris James For now I’m happily using the machine using a USB→ethernet dongle, but hopeful we can find a fix for the motherboard ethernet.

Can you tell me the model of the USB→ethernet dongle you use to get it working? So that I can also try to get one as a workaround.

I just bought a PI400 with German Keyboard layout and I also did not get the onboard ethernet connector to work when using Riscos (tried the latest Riscos direct image v2 based on 5.28 that claims to support the PI400).
Using exactly the same setup (same cable etc pp.) works like a thread when switching to Raspbian as OS witch suggest the driver in Riscos can not handle the used ethernet chip.

Executing command “pinout” under Raspbian showed it is also a Rev 1.1 board.

It just happen that I found an old Ethernet-USB-Adapter in the house that works as a workaround and I got my Riscos direct v2 (5.28) connected to the network with otherwise the exact same setup as before.

It was this Delock USB-2.0 adapter here in case someone else runs into the same issue with its PI400.
https://www.delock.com/produkt/61147/merkmale.html

After pluging the dongle into the PI it is shown in the Riscos network setup options as additional USB Interface that just needs to be enabled there and after a reboot the internet finally works. :)

Fingers crossed that Riscos will support the PI400 Rev 1.1 internal ethernet chip sometime in the future so that we don’t need this extra dongle workaround anymore.

Can you tell me the model of the USB→ethernet dongle you use to get it working? So that I can also try to get one as a workaround.

The device I bought was a UGREEN 20254. I had read somewhere that the chipset used in this device – ASIX AX88772A – was supported.

Thanks for mentioning the model name of your adapter. This could help others with the same problem to pick a working adapter.

I also tried to find out the chipset name for the Delock adapter I used. According to the amazon page where they sold them in the past (unfortunately this model is no longer available) it has a ASIX MCS7830 chipset.

The name of the chipset is given in the product description which the link above shows up. At the second bullet point under Specification the name of the chipset is given as ASIX MCS7830.

Having one of these Pi 400 Rev 1.1, which doesnt connect. I also tried nightly beta 5.29 image and replaced start4.elf and fixup4.dat. Up to not I didnt find a solution. Any ideas besides buying a dongle?

@Sprow or others: Do you have still a need for an PI400 rev 1.1 box to test?

@Sprow or others: Do you have still a need for an PI400 rev 1.1 box to test?

Fredrik kindly loaned his, and I started to look at it. I found a pullup resistor configuration problem previously masked by the rev 1.1 board being missing from the HAL. Then I’m afraid I ran out of desk space and needed to work on some other things so not much happened, it’s back near the top of the pile again after several months buried!

@Sprow many thanks for your feedback, I look forward. If you need external testers let me know.

I’m assuming, as there’s been nothing recent here and the download says “Raspberry Pi 400 1.0”, that the 1.1s ethernet is still non-functional?

I’m assuming, as there’s been nothing recent here and the download says “Raspberry Pi 400 1.0”, that the 1.1s ethernet is still non-functional?

Unfortunately when I next had desk space to look at it I’d obviously had my Weetabix and destroyed the spring mechanism on the SD card socket on Fredrik’s loan Pi400 which made it unusable. A couple of weeks ago I got a new socket from Digikey and have now repaired it so hopefully it can be investigated again (more gently).

Oooh unfortunate. No problem, I was more curious than determined to run RISC OS on the 400, the cobbled “laptop” is still fine.

Turns out when in January 2022 I said…

Anyway, another roll of the dice is here since the Broadcom LED control register happens to be the Micrel auto MDI-X control register, which might be an issue. The other 3 writes are all to IEEE standard ones.

…we were just millimetres away from the key to unlocking the mystery. When I commented out the Broadcom LED control code in the test module, what I’d not taken into account is that the copy in ROM had already done the fatal write during startup, and by chance the LED control bits resulted in the MDI-X being set to “manual and reversed”.

That’s why there was never a link up, because the cable was in effect wired backwards. Doh! Having corrected that (by *UNPLUGing the ROM module) the PHY now reports the link state and speed correctly, and packets can be received. Transmit seems to be a bit broken, but various murmurings suggest that’s because the delay trims need setting up (rather than the PCB layout having wiggly tracks to ensure the signals arrive on time).

So hopefully only a couple of PHY pokes from having Pi 400 and rev 1.1 boards working.

Progress! I like that.

Me, and some of my colleagues, are guilty of that sort of thing all the time. Usually it involves copying the wrong binary to a VM, then wondering why nothing changes.

So hopefully only a couple of PHY pokes from having Pi 400 and rev 1.1 boards working.

All pokes poked, this test ROM removed, now in ROOL’s nightly ROM downloads from 5th September 2023 onwards should get net-working on a rev 1.1 Pi 400 (and still work on the earlier ones and a normal Pi 4 too). There’s a minor HAL fix in there too, hence you need to swap out the ROM and power cycle.

Just wanted to pop in here and thank Sprow for the patched ROM image. This issue was driving me crazy, and the patched image has resolved it.

Anyone know if this fix will be rolled into the next official image released?