@hans @balaton

I don't have trouble getting the low level part setup. I have the device setup:



And I even setup a request in the queue:



The "only" thing is, I cannot signal the device like described in chapter 4.1.4.4.1. I calculate the address, but writing any kind of value into that address location, results in nothing. No error message from qemu, no processing of the virtqueue entries. And yes the PCI command register has bit 2 set.

So that's is where I need help, or least some kind of debug output telling my what qemu thinks is wrong.

And yes I will contact Matthew. But I already had my code, a long time before the virtio.library was made public known.

@balaton

The BAR mapping looks good, as long I understand everything.

I test all the options suggested. During the run of my test, no output was giving. Which makes me wonder because using "-trace enable="pci*"" only gives output during startup of the OS. But if I start my test, and it read in the pci configuration space. No additional message were written by this option.

Yeah, we should work together, but except Hans who is the third person? Any my code is just at the moment a hack done, to see how everything works.

Anyone having experience writing a AOS4 driver for a pci device? I'm trying to write a virtio-... device driver.
Currently palying around with block device. So I'm setting up a simple test to write data. It seems from the
qemu monitor everything is fine. But I'm struggling with kicking of the write request to the device. From the
documentation, is should be quiet simple, just write a value to a specific address in the BAR region. I have that
address, I know the value to write. But writing to that address, nothing happens.

Is there a trick form the AmigaOS side, and is there a way to debug/monitor that from the qemu side.

@joerg

Quote:

So the best solution would be to always have .rodata section in its own segment ,
regardless of the type (executable, sjobs). This the elf.library allocate straight a head memory as described by the segments. No fancy splitting needed. And sjobs works, too.

Quote:

Yes, but in this case I‘m not developing a sobj, but a foo.library. Which again doesn’t have a .plt section. So no m6ik code in sobj. BTW can foo.library use sjobs ?

@Futaura

I think I understand, that the loading of elf files differs form the standard, is because of the fact that
calling m68k should/must work, for normal executable. And the same loading behavior is applied to sobjs.
And to workaround that .plt and .text section gets ripped apart, the solution is to have .rodata in its own
segment.

But must sobjs loading actually be handled like normal executable? Of course it is easier to have the same
loading code for both.

What I'm thinking of is, if it is possible for an sobj to have any m68k code? Sobjs are for ppc only, so the only
way to "include" m68k code is to call it. In the Migration Guide are all? cases listed how to call m68k code:

* m68k library: needs generated stubs, which are realizes as separate disk-resident file. So no m68k code in the sobjs
* m68k Hook function: Theoretically possible, but why should I setup an m68k hook, if I currently developing for ppc. Maybe only used in a bizarre scenario
* m68k interrupts: Same as m68k hook. Why use m68 code, if developing happens on ppc
* calling emulator: Probably use case, which can happen. But the m68k code would normally be loaded from another file and not be as read only data. In later case the developer could just again use ppc instead of m68k during development.

I think, there aren't any sobjs files having m68k code. And if there are some, than they are very rare and
probably do other stuff, which isn't correct programming. I would like to know if someone can prove it wrong.
Because if this assumption is valid, sobjs could just be loaded as described by elf. No special handling
of .rodata is needed.

On the other hand, the question must be answered if it worth the effort to have two loading mechanism in
the elf.library, and if the elf.library knows if its loading an sobj file. If the later is not possible,
this all is just an mind game.

@Futaura

That would be very nice, if you could put together an example. What ever times it takes you. I'm in no hurry.

@Oliver

Around line 9345 the "magically" patch is made.

@Futaura

The changes elfpipe did to support 0 value for the relocs were made because
to support Template function argument changes address btw main exe and
from inside shared object.

As somewhere mention in the thread you referred to, it basically should go like that.
If the value isn't 0 used that, else perform function address resolution. Lazy or not
doesn't matter. How it should be done is even briefly/abstract described in the ABI.
So you may "need" to read it to understand the code changes from elfpipe.

@Futaura

See chapter 4.3.3 of e500 PPC ABI. Where information is written about dynamic linking of function addressee (st_value = 0)

So from my point of view the zero in st_value is correct.

@Futaura

Oh no It does even overlap! I see now that the Virtual addresses
aren't "recalculated". I have to investigate that.

@Futaura

Ok, that was obviously. But it even output the debug message for other circumstances, where
no overlap is (as long i can see, maybe i have a blind spot on this) and the .rodata section
isn't in the segment like this from this debug output:



and the segment / section stuff:



So it must be something else which triggers even the debug output

Quote:

even that it doesn't overlap and no rodata section is present?

Currently we are trying to put the .newlib_version section even add the end with .rodata together
to see if we get other debug output for segment two.

@Futaura

Thanks for the hint with the debug output for the elf.library. It gives more information, but still
the picture isn't as clear as wanted.

Because the message

Quote:

Is even issued for program headers/segments which don't contain a .rodata section. So it must be more than
just having a .rodata section in the segment, that the segment is handled differently.

See we have the following segments/sections



And this is the beginning of the elf.library debug output with two times the message



Even that the second output of the message can be explained with, what you sad: a .rodatas section in segment.
The first message have been triggered by another condition.

Could peek in the source of the elf.library and see if you find another/additional explaination?

@Hans

Yeap that made the trick:



Now i get other stuff than zeros!

@Hans

Quote:

I think that could be what I'm missing. At least this I never read/heard of yet, compared to what balaton, jeorg etc wrote. That
all I knew from the virtio spec etc.

Another topic which comes to my mind. do I have take care of the cpu caches? Maybe I just writing/reading into/from the cache and the real memory isn't updated?

I checked the address which i retrieved with the address from Ranger etc. This seems to be correct. And even running my test on a real machine, gives me even. nore zero values. I'm not sure what I'm doing wrong.

It might even be that on qemu the virtio device isn't yet correctly configure and this not data present. There might be issue with the synchronization between cpu and memory of the device. There are so many pitfalls.

Is there anywhere an simple example how to drive a device device? especially reading from the BAR memory? Or a tool known to work, which dumps BAR memory?

@balaton

I read multiple times what you wrote and even found bit and pieces in the source of bboot.
But I still no clue who and where to adopt the bar truncation in my setup with bboot and
initrd Kickstart.zip file. Any example anywhere (expect as Hans mention buried deep done
in the mention thread)

@all

A lot of information, which I currently cannot sort in.

@Hans @joerg

I'm using the Pegasos 2 emulation with bboot. I'm added the virtio devices as following to the working qemu call:



I had the thought that qemu knows that "-m pegasos2" is 32bit, thus the virto devices will be 32bit too?

So what do I have to tinker to get them mapped correctly? What kind of boot script?

@geennaam

I hope that the virtio-xx-pci devices are correctly emulated

At least all vendor specific capabilities etc I find, and can read. These have the following structure:



And all values I retrieve for them looks correct (and even don't consist only out of zeros)



Just that the bar memory is zeroed on qemu.

@geennaam

Even using BaseAddress doesn't result in other values but zeros. But I think my problem is that i running under qemu.

Dumping memory on a real X5020 dumps even values other than zero.

BTW in which case you have to use the physical instead of the base address? (Even that they are most of time the same?)

Does anyone know how to read out the memory of an PIC device defined via a BAR?

I find my PCI device and call on that the GetResourceRange, and dumps the memory like this:



But regardless which PCI device and matching bar I choose. I always only read zeros.
And at least for some device I know there must be some values presents.

What am I missing?