@Raziel

Quote:

No, I just was wondering if you did.

@Raziel

Did you even re compile all the used libraries, like libvpx.so ?

And if you start the program, do you get a GR, and if yes, can you give me the generated stacktrace?

@geennaam

Quote:

If the current gas does not support it, try the binutils v2.40 (betas) , at least in the code there is something about 'DCBA', maybe they work for you.

https://kas1e.mikendezign.com/aos4/bin ... _binutils_2.40_beta01.zip

@flash

As a first report that sounds great. For the bigger files, I'm not sure where the root case for that is. If it is the ppc-amigaos specific changes, or general changes in binutils in the last years.

@all

Thanks all for the supplied information. I tried to write a documentation regarding how ppc-amigaos use Elf32.

Here is the link: Power Architecture™ 32-bit Application Binary Interface Supplement – AmigaOS.

I tried my best to get everything correct. Anyone discovering typos, faults, just plain wrong information,
in that document is welcome to correct it. Eitehr as PR, or here in this thread, etc.

@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?