No Ethernet driver found with RISC OS 5.28

Having copied in the current HardDisc4 files and the new ROM V5.28, I get an error message about network/internet not set up with “Possible reasons: a) No Ethernet driver found; b) Freeway is not running”. Doing a reboot of the Pandaboard with the restart option has cured this. Once, the Pandaboard connected to the network as normal from power on. From either power on or restart, the screen text says the usual line about trying to connect via DHCP; but (in the failure cases) gets no further with the cursor flashing ‘forever’.
So, is it a timing problem or what?

I have never bothered to include the preEnv.txt file in the bootloader ‘partition’ – is that relevant?

From either power on or restart, the screen text says the usual line about trying to connect via DHCP; but (in the failure cases) gets no further with the cursor flashing ‘forever’.
So, is it a timing problem or what?

Yes.
Standard DHCP clients (out in the real world) will do this kind of thing if the OS hasn’t fully settled when the network DHCP sequence runs – however on most¹ of those clients the DHCP DORA sequence repeats not only three times at that point but also has a failback to trying the last recorded IP and awaiting a negative/positive response and (possibly) failing to an alternate IP or APIPA allocation.
Then for good measure the client will try again after about 15 minutes.

There’s an element of the retry in the DHCP utility the R-Comp include with the ARMBook etc.

Since most of these issues derive from the speed that the base network setup starts I have wondered whether the driver selection method is delaying things.
If you look in !Boot.Resources.Configure.!InetSetup.AutoSense you see a collection of small BASIC files that sense the presence of a NIC. They do this by querying, individually and sequentially, whether a particular SWI (or similar) works.

I see the potential for the individual load times of those AutoSense files to cumulatively delay the NIC/network/DHCP start.
There is also the missing potential to specify multiple active NIC’s in a specific order

If there was one file that read an ordered list of possible NIC’s then a configurable parameter could mark the interface as primary, secondary, tertiary…
Further, the user could enable and disable any interface(s) so on startup the system only looks for a response from one potential NIC instead of the six I count in the directory now.

Yes, I’m aware that BASIC runs fast in human terms but the systems aren’t human so perhaps we could replace all those sense routines with one and a set of parameters = query and expected response listed in an easy to edit text file. Build the sense routine in C and we have (possibly) a faster routine, but even combining the multiple files is likely to improve things.

Looking in the AutoSense directory, there are 5 files: EtherCPSW, EtherGENET, EtherK, EtherUSB and EtherY. Previously, that is, before 5.28 update, there was only one, EtherK. Funnily enough, the two EtherKs have slightly different datestamps, differing only by the hour of the day (27/02/2006) not even the minutes and seconda, but very different sizes. The new one is 1887 bites and the previous one 2342 bites. Seems suspicious. I am being called for dinner. To be continued…

I am being called for dinner.

Quite clearly needed: “The new one is 1887 bites and the previous one 2342 bites.” as opposed to 2342 bytes… :)

The larger file will be the one with the Castle license text at the top, the smaller file has the apache license.

Drop the two files onto SideDiff (Miss H. Bazley) and check the lines that differ shown.

Otherwise the content is identical.
BTW. The content of that directory is gradually increasing as new NICs are supported.

Yes, looking at the files was next. I was thinking that the time difference of exactly 1 hour on the date stamps of the two versions could be due to the difference between BST and GMT, but the month was February.

The Autosense directory on my ARMX6 has EtherTH, but not EtherGENET, with the other 4 files the same.

Perhaps having just the EtherK file in Autosense, as previously, will be more reliable from what you say.

Perhaps having just the EtherK file in Autosense, as previously, will be more reliable from what you say.

Certainly gives fewer files to run load and through before running the one that actually does something useful for that system.