Fuzix Wiznet W5500 networking

[Ed Brindley]

Hi there!

I'm trying to get networking working on a SC111 + SC119 + Wiznet W5500 setup.

I've built a platform-rcbus-z180 image with the default config which looks to have w5500 enabled.

I've connected the W5500 module to the CSIO header on the SC111 and also connected the reset line to the bus.

How do I bring the network up? I found this video of Fuzix on a different platform https://www.youtube.com/watch?v=pGChpkBgHD4 but I don't have the /dev/eth device or usr/bin/netd-eth

Any assistance appreciated!

Cheers,

Ed

[Alan Cox]

On Tue, 18 Apr 2023 at 23:12, Ed Brindley <ed.br...@gmail.com> wrote:
>
> Hi there!
>
> I'm trying to get networking working on a SC111 + SC119 + Wiznet W5500 setup.
>
> I've built a platform-rcbus-z180 image with the default config which looks to have w5500 enabled.
>
> I've connected the W5500 module to the CSIO header on the SC111 and also connected the reset line to the bus.

What about the chip select ? The current code expects the chip select
to be SC126 style on the GPIO so I am not sure how it will behave
without that.

If it detects it should let you ifconfig eth0 and set an address etc
(no DHCP right now)

[Ed Brindley]

What about the chip select ? The current code expects the chip select
to be SC126 style on the GPIO so I am not sure how it will behave
without that.

If it detects it should let you ifconfig eth0 and set an address etc
(no DHCP right now)

Thanks.

I've grounded chip select on the board now. I'd also connected the interrupt pin on the wiznet to the /int2 pin on the header so I've removed that

I get:

# ifconfig eth0
ifconfig: networking not enabled.

Does this indicate the w5500 hasn't been detected?

[Alan Cox]

> I've grounded chip select on the board now. I'd also connected the interrupt pin on the wiznet to the /int2 pin on the header so I've removed that

It looks like it ought to work on the hardware side if it's the only
device on the CSIO. The other problem will be this

discard.c:void device_init(void)

if (systype == 10) { /* Has SD glue */
sd_init();
#ifdef CONFIG_NET
netdev_init();
#endif

so you probably need to comment that out partly so netdev_init gets
run but not sd_init (or the sd probe will almost certainly muck up the
5500 config if cs is pinned low).


Alan

[Ed Brindley]

I'm wondering if netdev_init is dependent on some initialisation in sd_init?

With this code:

void device_init(void)
{
kputs("ide_probe\n");
ide_probe();
kputs("sd_init\n");
sd_init();
#ifdef CONFIG_NET
kputs("netdev_init\n");
netdev_init();
kputs("netdev_init finished\n");
#endif

}

I get

Enabling interrupts ... ok.
ide_probe
0000 : SAMSUNG CF/ATA                           - OK
0001 :  - no response
hda: hda1 hda2 (swap)  
sd_init
netdev_init
netdev_init finished
bootdev: hda1
Mounting root fs (root_dev=1, ro): OK

However if I remove the call to sd_init, netdev_init never completes - the "netdev_init finished" line is never printed. (I tried with and without the w5500 connected and it hangs in both cases)

Out of time this evening but will try and investigate further tomorrow.

 

[Alan Cox]

> However if I remove the call to sd_init, netdev_init never completes - the "netdev_init finished" line is never printed. (I tried with and without the w5500 connected and it hangs in both cases)

There is code to ensure that the SD and W5500 don't try and talk at
the same time but that seems ok. There isn't any code I can see for
the w5500 only case that sets up the CSIO clock so that may be the
problem. It's not a setup I've tried.

If I get a bit of time I'll try it on the emulator (the emulator
supports plugging real SPI hardware into a bus pirate) and see if I
can work out what is going on.

Possibly calling sd_spi_fast() in the setup or before it will help -
and uncommenting the kprintf calls in sd_spi_transmit/receive_byte
might also be informative.

Alan

[Ed Brindley]

On Thursday, 20 April 2023 at 12:48:29 UTC+1 Alan Cox wrote:

If I get a bit of time I'll try it on the emulator (the emulator
supports plugging real SPI hardware into a bus pirate) and see if I
can work out what is going on.

Thanks for you work/ commit yesterday the wiznet is now detected!

bootdev: hda1 wiznet
Wiznet 5500 detected.

Tantalisingly close to it working, however I'm getting some strange behaviour. After a reset the device is pingable on 192.168.0.1 from my PC, until I run e.g. ifconfig eth0, or telnet 192.168.0.2 at which point the LEDs on the RJ45 socket go off and the link drops until I reset again.

ifconfig prints what you might expect

# ifconfig eth0
eth0    : up broadcast running  mtu 1500
ether: c0:ff:ee:c0:ff:ee  (Ethernet)
inet 192.168.0.1  netmask 255.255.255.0  broadcast 192.168.0.255  gateway 192.168.0.254  

<link drops>

Then I shutdown, reset, login, etc again

# telnet 192.168.0.2
connect: Address already in use

 <link drops>

An outbound ping produces this (and doesn't cause the link to drop), but I don't know if that is to be expected.

# ping 192.168.0.2
socket: Protocol not supported

Perhaps I should try the Wiznet on an arduino and see if that works... one for tomorrow. I just bought the cheapest one on aliexpress so it might be a dud!

Cheers,

Ed

[Alan Cox]

> Tantalisingly close to it working, however I'm getting some strange behaviour. After a reset the device is pingable on 192.168.0.1 from my PC, until I run e.g. ifconfig eth0, or telnet 192.168.0.2 at which point the LEDs on the RJ45 socket go off and the link drops until I reset again.

Think I know why - the RJ45 light may have gone off but my little light went on

"In VDM Mode, the SCSn must be controlled with SPI Frame unit by
the External Host. (Refer to the Figure 4)"
(2.2.2 in the manual)

[VDM is variable length data mode - you can send/receive 1,2,4 or
'until you drop CS' bytes]

So to work without a chip select actually requires you alter
platform/wiznet.c not to use VDM transactions. Right now it uses them
for all the block transfers so presumably once the first transaction
using VDM happens life gets weird because every following transaction
is treated as a copy into the next register/memory offset.

So spi_transaction() and spi_transaction_u() in that case would need
to split block transfers into 4/2/1 byte transactions and send a
series of them. So if called with ctrl bits set for VDM

while(len >= 4) {
send offset
send ctrl | 3
send 4 bytes data
offset += 4;
len -= 4;
}
if (len & 2) {
.. | 2
}
if (len & 1)

etc


I'd forgotten about that bit of the 5500 stuff.

Alan

[Ed Brindley]

On Friday, 21 April 2023 at 11:08:04 UTC+1 Alan Cox wrote:

So to work without a chip select actually requires you alter
platform/wiznet.c not to use VDM transactions.

Ahh OK, I see! I'll have a crack at making it do FDM. I note the datasheet says "It is not recommended to use the FDM mode unless you are in inevitable status." :-D

It's also tempting to recreate the chip select logic of the SC126, but at the moment I don't have any need for other SPI devices.

Ed

 

[Ed Brindley]

On Friday, 21 April 2023 at 21:54:42 UTC+1 Ed Brindley wrote:

On Friday, 21 April 2023 at 11:08:04 UTC+1 Alan Cox wrote:

So to work without a chip select actually requires you alter
platform/wiznet.c not to use VDM transactions.

Ahh OK, I see! I'll have a crack at making it do FDM. I note the datasheet says "It is not recommended to use the FDM mode unless you are in inevitable status." :-D

Hi Alan,

Thanks for the guidance, gave it a shot tonight and it worked!

Trying to think of a way of reducing the duplication a bit as I've done it in a really basic way and it's made those functions quite long - had to undef all the config_rtc stuff to make it fit.

Cheers,

Ed

[Ed Brindley]

Change is here. Will try and improve it.. https://github.com/electrified/FUZIX/commit/3edd5cd8e1c235003f8b110b3e3480a5fbfc6845

[Alan Cox]

> Trying to think of a way of reducing the duplication a bit as I've done it in a really basic way and it's made those functions quite long - had to undef all the config_rtc stuff to make it fit.

My first thought would be something like

while(len) {
uint16_t n = bitcode[len & 3];
spi_send(off >> 8);
spi_send(off);
spi_send(ctrl | (n >> 2));
n &= 0x3;
do {
len--;
spi_send(*p++);
} while(len--);
}

bitcode[] = { 12 + 3, 4 + 0, 8 + 1, 8 + 1 };

but you might have to look how the compiler handles that. In asm
that's roughly how I'd tackle it except I'd pass the function to call
in the loop as well as a helper.



Alan

[Ed Brindley]

Finally got back to this. Thanks - this approach worked.

I've raised a PR https://github.com/EtchedPixels/FUZIX/pull/992

Cheers,

Ed