x1000 onboard network opensource driver in progress

@balaton
Quote:

Spend 5 hours to learn how install a stub and make it works (that was not easy) , so in end i just run "mce_stub" and it install stub, i then jump on 0x200, and when reboot, on address 0x7f000000 i have all the info i need. I even wrote simple external command which call the 0x200 , when my stub in : yes, stub works, and write data i need. I was so happy that now yes, i will see something which will point on , but then bah, THAT ISN'T MCE !

CPU died, soft-int died, hardware interrupts died, and this is not MCE too. Then what to check next ? I mean, BUS lockup ? Busy-wait ?



Quote:

Not with IOB on x1000, they ECAM, so direct physical writing, no translation/remapping there.

Quote:

At least in unix sources it shown clear : for network they use "5" (same as me).

Quote:

As usual need to clean mess, some ai-cruft and then will upload on github in a day or two.

@kas1e
Quote:
Did you check ME bit in MSR so MCE is not disabled? (Without a CPU manual it may be hard to know which bit is that exactly but maybe it's documented somewhere in the ISA version PA6T follows.)

Quote:
I don't understand these acronyms. What do you mean?

Quote:
Ask dma.resource author if you have contact what channels that can use and what are reserved for network if any. It may not be the same as on Linux and using a channel without reserving it in dma.resource might lead to clashes with other things using DMA. Is it possible to disable DMA usage in AmigaOS so you can be sure only your driver accesses it? Or get a channel from dma.resource and use that.

One more thought: you mentioned the DMA list wrapping around when the driver is stress tested. Is it possible the driver doesn't properly handle the situation where the DMA list wraps around?

Maybe try using a very small number of descriptors (like two) so that this condition is reached easily and you can examine the behaviour.

@kas1e
Quote:

Maybe unlikely, but one possibility is some missing protection when a List is modified by more tasks (or task(s) and interrupt).
IIRC I did see cases in some other OS where it did cause funny things like a loop in the List (node->ln_Succ == node). If someone then traversed this List while in Disabled() state you would get a lockup like the one you see (no ints happening, etc.)

Or broken protection in the sense of mismatch between lock (forbid/Disable/...) and unlock (permit/enable) calls. Or only lock call, but forgetten unlock call. This once upon a time in another OS caused funny and hard to reproduce disappearing-task problem (disappeared from taskready/taskwait/thistask). Because every so often when the locking nest count - because of overflow/wrappingback - reached the unlocked-value, things were done in a unlocked state, when they shouldn't have been and in the source it did not look like that because the LOCK was there, but missing/mismatched UNLOCK screwed things up.

@balaton
Quote:

You mean when OS4 loaded up ?

On https://en.wikipedia.org/wiki/PWRficient says "Power ISA v.2.04" so same as others, and that mean bit 12 of MSR are ME bit. Then when OS running , i by mfmsr found that MSR = 0xB030. 0xB030 in binary = 1011 0000 0011 0000 - bit 12 is set, mean MCE enabled.


Quote:

Again some of this are new for me too, and i can say some bull, but i understand this that way : there are old (CAM) and new (ECAM) strandards of PCI/PCIe meaning "Configuration Access Mechanism" for CAM and Extendend Configuration Access Mechanism for ECAM.

What it mean is that it's CPU chip dictate in hardware by PCI/PCIe protocol (CAM/ECAM) where placed configuration space registers. Now, when computer (be it x1000, or PC or any) boots, it's already known which address is a start of the PCI devices (from datasheets on CPUs probably, and in our case i take it from linux kernel code port to X1000, as we have no datasheet). So in our case with X1000 its 0xE0000000, so all PCI starts here physically. The way how they placed in are old (CAM) and new (ECAM).

Now, some devices have BAR, some have not (host bridges, pci-to-pcie bridge, integrated devices like our IOC, MAC, DMA, etc, where not need lots of memory like for graphics card,etc). After computer boots, firmware start to check PCI devices, and discover : if there NOBAR devices, simple skip it. This will be accessed directly. if there is BAR devices it then write an address of device to BAR, and then, when OS boots, it then do MMU mapping of this address, while NOBAR ones still untouched as it, just MMU mapped whole region of 0xE0000000 so we can access them from OS, but individual devices which have no BARs are not MMU mapped.

Now, when i say "those are ECAMS", i mean that those addresses of IOB/DMA/MAC do not go the individual MMU-mapping route by OS, and then GetResourceRange() return NULL for them as search for BARs. You can only access them directly by ECAM standard. Which (both and old CAM and ECAM) have a formulas to calculate an address of device. In our case its ECAMs one :



I can't be 100% sure without datasheet on PA6T CPU that it exactly that statdard, but i can with 100% sure say that the caclulation formula of ECAM standard fits very well on PA6T, and indeed found IOB/DMA and MAC where they are on X1000, so, this probably ECAM standard used indeed (and what else it can be: all in all its same PC, just with PPC cpu and CFE).


Quote:

X1000 do have pasemi_dma.resource, but i not use it. I do everything from scratch , so to avoid possible issues other ones step in when trying to create onboard driver. Still it's in the system, and probably used by something else, but i can try to simple comment it out to not boot, to see how OS will works without and if it will , and lockup will still be there, it mean this resource not to blame.

But to be honest i not very well understand why pasemi_dma.resource should allocate anything about network, if it's work of network device, which can (or can not) use this pasemi_dma.resource ?

@kas1e
Quote:

Aren't this pasemi dma channels ~general purpose things? Meaning there is no specific reserved channels (by cpu/hardware itself) for network or other specific things?

Maybe AOS on X1000 accelerates (big) memcpys with this dma-stuff and uses pasemi_dma.resource to dynamically/on-demand allocate channels (more tasks can be doing this memcpys at the same time), so it's not the resource itself allocating channels but users of the resource request allocations.

@kas1e
Make sure you check the right bit for MSR[ME] as PPC docs count bits from the other end than everybody else normally does.
You keep talking about writing register addresses in the memory mapped PCIe config space or BARs but what I was talking about is if the card needs transfer descriptor structs in memory like USB controllers or rtl8139 does then you should make sure the addresses you write in those descriptors are correct and that these are written to memory before you tell the card to read them which may need a cache flush or memory mapped non-cachable. But I don't know how this works so not sure this applies.
I only know DMA on Sam460EX and A1222 that I had experience emulating but X1000 probably works the same. AmigaOS uses the DMA engine for blitter ops or memory moves and this seems to be coordinated by dma.resource. The Sam460ex is simple as it has only one DMA channel but on A1222 I noticed not all channels are used. Then I was told some channels may be reserved for audio or network that's why not all channels are claimed by dma.resource. If the driver goes through dma.resource to alloc a channel then you could make sure nothing else will use that. Otherwise you may need to use the channel reserved for it but I don't know which is that or is there any. The author of the dma.resource for the X1000 should be able to tell. If you pick a channel that dma.resource can also use then it could be the kernel would also try to use that and break your settings.