x1000 onboard network opensource driver in progress

@All
Find out that on my x1000, when i connect router to the onboard NIC and then power on machine, then the leds both on router and on the NIC are green. All fine. Then, if i do "reset" by reset button on tower, they go to offline, and never come up even after OS4 loads up again. So , to make link again to work, i had to do exactly power off / power on.

Can somebody confirm if it only my x1000 acts like this, or all of them ?

Thanks!

@kas1e

I tested, and the lights always start to flicker. On the router it is green when I connect to the internal ethernet port, while it is orange if I connect the cable to the Realtek 8139 ethernet card. The router senses automatically the connection speed. 1000Mbit = green 10/100Mbit = orange.

Test:

1. disconnect eth-cable from RLT8139
2. connected to internal X1000 ethernet port
-> internal LEDs of X1000 ethernet port flicker
3. pressed "reset" button on X1000 case
4. Waited for AmigaOS4.1 FEu3 to fully boot
-> internal LEDs of X1000 ethernet port flicker

New test:
1. Turned off X1000
2. waited 1 minute
3. verified ETH-cable connected to X1000 port
4. boot AmigaOS
-> LEDs flicker
5. reset of OS via software (Workbench menu)
6. Waited OS to fully boot
-> LEDs flicker
7. reset system via software (Workbench menu)
8. Waited for OS to fully boot
-> LEDs flicker
9. Pressed Reset button on case
10. Waited for OS to fully boot
-> Leds flicker.

Maybe it is because I have RTL-8139 card installed?

However, I am not a lucky one to have driver for the internal X1000 ethernet device. Never released to the public as far as I know.

So even if the lights flicker (modem and internal LEDs on X1000) I can not use the port. I tried to manually select pa6t_eth.device in internet wizard, but it can not open device. (error sound and does not let me "continue" set up wizard)

Hope this helps your quest.

@Tuvok
Thanks for tests !

So it looks like just my x1000 acts like this .. Maybe some power issues or so ..

My X1000 also act a bit strange : not always re-startup (i mean just to X1000 logo) after reset, and i should doing another one. Like it not fully initialized. I remember Raziel (user who were here some time ago) report same ..Do you have this kind of issue ? On serial when i can't boot i usually have:



And that all. Then again reboot (power off/poweron) and it starts. But that another problem anyway ..


Quote:
I do not have one either, all i know is that it was done, but have race condition bug : debug version works fine and can transfer gigabytes of data, but release version crash/freeze soon or later, so it was some race-condition bug which author weren't able to find and fix. Also it was (if i remember correctly, but can be very wrong, so don't take this for granted) a paid job for aeon, so you can imagine it all can ends up with nothing..

Anyway, because of that i trying to wrote open-source version now, and so far come to the point that i can ping myself, i can even connect via telnet to router outside (so basics works), but when i tried to load up welcome page from router is just end up loosing packets, etc.. so debug and one more debug.. There is for now:

(click open in new tab for fullsize):

Current progress:

(click open in new tab for fullsize):



So can ping, telnet, and even something loadup in browser, but, still have some problem with whole thing, awfull pings (sometime good enough like 0.5ms, sometime 1000(!) ms), and so all the data load up like "load fast -> stall for a while -> load fast".


@all
Checked x1000's net driver sources for linux, and find out that dma_alloc_coherent() is used all over the places for the all ring descriptors and stuff, but i currently just use AllocVecTags(MEMF_SHARED) just like Neil's prism and atheros5000 drivers do. But as we have no datasheet for pasemi seems so, and linux driver were written by PA-Semi itself (so kind of same datasheet) it mean that if they use dma_alloc_coherent() all over place, then i should for os4 do same too so setup MMU, etc ? I mean dma_alloc_coherent() on amigaos4 mean IMMU->SetMemoryAttrs(MEMATTRF_CACHEINHIBIT) which we can't call from user space (right ?).

I just find it strange that Neil's drivers didn't worry about, and all fine, but there with Pa-Semi on linux they use it a lot ..

I just get strange result for now when packets stalls like busy with something , i.e. ping can be 0.5ms for few times, and then 1000ms few times, same for any other data , it start loads, then stalls for long, then back again. So thinking what can it be ..

just in case original linux source code of x1000 driver here:

https://raw.githubusercontent.com/torv ... /include/asm/pasemi_dma.h
https://raw.githubusercontent.com/torv ... ernet/pasemi/pasemi_mac.c
https://raw.githubusercontent.com/torv ... ernet/pasemi/pasemi_mac.h
https://raw.githubusercontent.com/torv ... semi/pasemi_mac_ethtool.c
https://raw.githubusercontent.com/torv ... latforms/pasemi/dma_lib.c
https://raw.githubusercontent.com/torv ... /platforms/pasemi/setup.c
https://raw.githubusercontent.com/torv ... tforms/pasemi/gpio_mdio.c
https://raw.githubusercontent.com/torv ... /platforms/pasemi/iommu.c
https://raw.githubusercontent.com/torv ... pc/platforms/pasemi/pci.c
https://raw.githubusercontent.com/torv ... c/platforms/pasemi/misc.c

@kas1e
Quote:
If it hangs on DRAM did you check if memory is good? What is printed after that when it boots? Maybe check that too,
Quote:
To answer that you may first need to understand what dma_alloc_coherent() does, in other word what coherence refers to here and why would that be needed.
Quote:
Maybe it does not matter as long as you only use one core. Coherence may refer to cache coherence between cores but maybe also be for PCI as was the case with graphics cards. That's why you have to find out the above first to get an answer.
Quote:
If this is AI generated code then who knows, could be anything and nobody could guess without trying to make sense of the code.

@kas1e

Quote:

Sometimes mine stops booting too or it just opens a shell and then I have to "reboot fast sync". I can't remember this to happen before update 3. But then I have connected a new SSD and can't go back to previous config to check it.

I will connect the x1000 with 0-modem cable and let you know.

Cool!

@Tuvok
Are you referring to being dumped in an AmigaDOS shell?
If you're using a KVM switch it may be the KVM switch reporting false initial state of mouse buttons. That may lead AmigaOS to think you're holding down mouse buttons to either enter Early Startup or "Boot Without Startup-Sequence". I have that on my ATEN KVM sometimes.
The bootmouse driver has a bios environment variable, "use_mouse_btn_check" you can set to "0" or "no" to disable initial reading of mouse buttons to avoid this specific problem.

@balatonQuote:

How to check memory?
There is memtester on os4depot but it I wonder if the test itself is any good as it can not test the whole memory I suppose. At least not the part already used by the OS and Kickstart.

There is some memory test in CFE, but I never really understand how to make it work for all the installed memory. it just hangs.

@graff

Thanks for the hint.

I am using a KVM, yes but the issue appeared after installing update 3. I was using the same kvm with update 2.

However, I will try your suggestion.

@kas1e

I have to mention this: You did check your cell battery, right?

Sorry if of course you already checked this, but so often problems similar to yours are caused by a slightly (or more) worn out battery.

BTW, my X1000 also does not show this problem, although it is connected to a switch, not directly to the router, but that's probably not relevant.

Best regards,

Niels

@balaton
Quote:

Yeah, will have to check all this while i am at it..

But it's not only this : when i hit reset one time then with 100% case NIC led didn't fire up, then i hit again reset (or 2 more times) and then connection from onboard internet fire up. I.e. 2 problems: 1). Not everytime boot, so no x1000 logo, 2). Sometime even if boot to logo, no onboard ethernet boot up.

Quote:

At least that can explain why it uses on linux much : they utilize both cores of x1000, while os4 only one, so maybe there no sense to worry, but sure i need do dig in.

Quote:

Of course that all with help of AI: it creates skeletons quite fast, how else i can come to even transfer something for just 2 days :) But then it still need understanding in end to deal everything right. For me were important to know if my onboard network works at all (it is), and if it can transfer data at all (as all those issues with onboard driver there for many years already).

So, talking about which, if you (and joerg :) ) have time , can you plz light me up on this and fix if i talk bull:

As far as i understand, when x1000 (on any amigaos4) hw) boot up, it doing some PCI mapping from physical to virtual called ECAM, and for x1000 (found by tests on real x1000 hw) the start address of ECAM are 0xE0000000.

Next, we have there whole PCI(e) three, which include IOB (first , right at the 0xE0000000, then come other stuff like L2, and then on 0xe00a3000 (00:14.3) we had Ethernet, after which come XAUI, and then at 0xe00d0000 (00:1a.0) DMA engine, and then things go further with SMBus, Serial, etc, etc.

Now, what i also found is that some devices have BAR, some have none at all. The IOB, MAC, DMA, L2, few internal to soc PCIe Bridges have no BAR at all, GetResourceRange() just return NULL for them. While others ones (which also part of SOC) still have BARs : SB600, SMBus, Serial, etc. And of course all external devices have BARs too.

Then, as i see it, for BAR devices we use GetResourceRange() + ReadConfigLong/WriteConfigLong() (or we can directly (volatile ULONG *)r->BaseAddress; just take care byteswapping). For NOBAR devices (our onboard network as one of them), we just use ECAM address+offset, and then again, then same ReadConfigLong/WriteConfigLong() or direct "(volatile ULONG *)0xE0000000;".


Next, we can 2 ways to wrote driver :

1. polling/busywait one , so no interrupts, and probably on real hardware no go ? Currently that the way i use with beta driver.

2. interrupt driven one : this one probably way to go on x1000, but then , currently i didn't get for now full picture of how i should operate with. I.e. this can't be not just simple AddIntServer,like done in the atheros5000 driver by Neils like PCI interrupt path → AddIntServer(MapInterrupt(), handler) , but totally different we should compute ourselfs with usage of DMA_engine where interrupts are, etc ?


Did i get everything right till that point ? Because AI of course helps, but offten generate unlogical crap, so had to sort it all before moving to the next steps..

Thanks!

@kas1e
thanks for effort!
It will be great to have ( finally ) driver for X1000 NIC!

@kas1eQuote:

2 years ago I tried AROS x86 in qemu with it's rtl8139 driver. It showed similiar behaviour. I did not have much clue about networking stuff, but I looked in the driver source and it had a "TODO:" comment about "wrapped buffers".

I managed to do a quick fix and the bad behaviour (load fast, stall, load fast, ...) disappeared.

The issue was that a packet in the rx buffer for whatever reason (maybe not happening on real hw) can end up being partly put at the end of the rx buffer, and the rest of it (parts which did not fit) wrapped over and was put at the beginning of the rx buffer.

So the quick fix was to allocate the rx buffer 2 times as big, and when a wrap over was detected ("if (ring_offset + rx_size > np->rx_buf_len)" copy the overspilled part from the beginning to
"rx_buffer + rx_buf_len".

Without this (I think) ~broken packets (only parts of them valid, because not fully/correctly copied) ended up going through network stack.