@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!
Edited by kas1e on 2026/3/9 17:04:43 Edited by kas1e on 2026/3/9 17:17:42
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)
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:
[HELO][DRAM]
And that all. Then again reboot (power off/poweron) and it starts. But that another problem anyway ..
Quote:
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.
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:
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:
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:
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 ?).
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:
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 ..
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:
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 ..
If this is AI generated code then who knows, could be anything and nobody could guess without trying to make sense of the code.
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:
[HELO][DRAM]
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.
@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.
balaton wrote:@kas1e [quote]when i can't boot i usually have:
[HELO][DRAM]
If it hangs on DRAM did you check if memory is good? What is printed after that when it boots? Maybe check that too,
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.
If it hangs on DRAM did you check if memory is good? What is printed after that when it boots? Maybe check that too,
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:
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. 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.
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:
If this is AI generated code then who knows, could be anything and nobody could guess without trying to make sense of the code
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..
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".
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.
My DMA-based network drivers assume there is no cache coherency. They use Exec cache-related commands (wrapped in macros for compatibility) to flush caches before and after DMA transfers.
I wasn't aware of the MEMATTRF_CACHEINHIBIT flag until now, so I can't say for sure if that could be used instead.
It is strange to me that the two on-board NICs enumerated by PCI don't have BARs (is the one that's actually connected to the RJ45 port the 1 Gb or 10 Gb one?). Normally, driver code just gets the virtual address from the BAR and doesn't need to care about the offsets etc. you mentioned.
However, the PCI entries do have interrupt numbers, so why shouldn't AddIntServer() work with them?
I also second what Niels said about the battery: a low voltage can have strange effects, as I found out recently: my X1000 wouldn't turn off!
It is strange to me that the two on-board NICs enumerated by PCI don't have BARs (is the one that's actually connected to the RJ45 port the 1 Gb or 10 Gb one?). Normally, driver code just gets the virtual address from the BAR and doesn't need to care about the offsets etc. you mentioned.
From TRM found that:
Quote:
A single CPU SerDes channel is configured for SGMII protocol and this is connected to a Vitesse VSC8221 Gigabit Ethernet PHY. This is wired in turn to an RJ45 uplink connector at the rear
And on architecture diagram this Vitesse Gigabit PHY comes to Quad 5 Line 3 of CPU.
As for BARS: at least from tests i do it looks like they (MAC,DMA,IOB) have no BARs (at least GetResourceRange surely return NULL for, and test code should be correct : i in loop checked all pci devices, many of which have BARs and return it OK).
Quote:
However, the PCI entries do have interrupt numbers, so why shouldn't AddIntServer() work with them?
There is how i understand it all and how i did it for now (correct me if i wrong somewhere):
It looks like when you use some external card , chip of this card handle everything at one interrupt : be it DMA events, or MAC wire events , etc. In your prism/atheros you just did AddIntServer(((struct PCIDevice *)card)->MapInterrupt()", and have in return an interrupt number installed handler for which can cover everything: recv, send, DMA, link stats, errors, when fire interrupt after which N packets, etc, you just read/set config registers.
Now when it come to onboard, we have 3 different PCIs : MAC, DMA (moving data) and IOB (handle interrupts).
MAC: just single device-level interrupt: link,state, errors, flow, i.e. wire level only, currently i skip it completely as interrupt, but, we still use config registers of course (i do so to completely mimic as on linux done), i.e. write some stuff right on initialization stage as linux driver did, but most important there is : DMA channel routing bit, so to say to which dma-channel sends packets.
DMA: it have one device-level interrupt: not of big use by itself (fires for start/stop of whole engine,etc) and we also didn't install handler on it, but its actual number of big use to know from where to start calculating offsets to the DMA channels we need and then install interrupts on them only. From linux code i see that DMA engine have 64 RX channels and 20 TX ones. And their vectors calculate by formula:
RX = base + num_txch + rx_chno. TX = base + tx_chno.
And then they just installs 2 interrupts for 2 channels rx and tx.
BOOL ok = IExec->AddIntServer(base->irq_number, &base->irq_handler);
Tx i completely ignore for now, doing "fire and forget".
Now, after i set correct (as on Linux) values for MAC and point on correct DMA channel, then install interrupt on RX, which, when generated (with it's DMA channel config registers) didn't provide necessary info, only some bits like where it in memory, is it working, but says nothing if packet arrive, if many pending, should cpu interrupt : this is done by IOB
IOB: And this third one we setup at initial state a bit, and then in the handler which we set for DMA-channel 5, we do our job : one IOB read (may be optional) and one IOB write (to say wath for next interrupt).
So, looks a bit complicated of course, and i do not know, if i can get rid of some steps there and replace with StartDMA() / EndDMA() for example somehow..
But keep invistigated, at this moment i still have good 0.5ms ping for router , stable, no packet loss, but when i do try load over TCP in browser something, then it stalls for long time like 30 seconds after random loading, and then continue again. And again stalls.. So trying hard to mimic what linux does to understand what happens.
All in all, it looks just like network stop send packets. Not like i have broken or missed return, etc...
--------------------
Btw, may i ask why in your driver you use EmulateTags() copy for RX/TX/etc ? Just for having same code working for os3/os4 , or there were other reasson for ?
Also can we call ReadConfigLong() from IRQ context ? Probably not ?
@all Oh my ... I just attached rtl8139 to my x1000, and tried to go on the same router page, and it give me the SAME DAMN STALL !!! For about 30-60 seconds !!! Which mean i two days fight not with issues in driver, damn... But good news maybe it works then, i just need to test it not on router's welcome page then. Dunno what is it.. When i debug onboard driver this "Stall" looks like issues with TCP-recv size or something. Just after some 300-400kb download from router server just stop sending data. From side of driver everything were clear. Changing roadshow's tcp.recvspace to bigger values didn't help. Not sure wtf is that.. Need to test on other browser, but more of it i need just to DL 100MB test file over network and that will be better that router's page.
@all So, attached internet to router, and were able to test it for real. It works !
(click open in new tab for full size):
There you see i run "tcpdump" and it in realtime show all the ip/tcp/upd/etc data, an Odyssey going to wiki.amigaos, how driver looks like in Ranger, and of course PDF opened !
At least, it was worth to throw away 3 full days (and half of nights) to understand how it all should work.
Of course there are bugs, so plz, those who will test report all the issues until i am on it. It surely can be not fast enough, or stable enough, that all need to test and compare with others. But at least ping speed looks correct (like on my windows machine to external addresses) and ping of the router's ip give 0.5ms as expected too. Download wise i tried to download debian ISO from cdimage.debian.org, it give 1.7mb/s for me. Another download of big iso were from one of "mint" servers, and it was 2.1mb/s.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
