Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
116 user(s) are online (71 user(s) are browsing Forums)

Members: 0
Guests: 116

more...

Support us!

Headlines

Forum Index


Board index » All Posts (MigthyMax)




Re: Tracing
Just popping in
Just popping in


@kas1e

I think I know why your Tracing crashes
In your CallHookPt you are Freeing the message after PutMsg, before the receiver had time to process it.

Go to top


Re: binutils 2.40 first native(!) beta tests !
Just popping in
Just popping in


@Raziel

Quote:
I need to recompile *all* used dependancies???


No, I just was wondering if you did.

Go to top


Re: binutils 2.40 first native(!) beta tests !
Just popping in
Just popping in


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

Go to top


Re: x5000 benchmarks / speed up
Just popping in
Just popping in


@geennaam

Quote:
DCBA is actually still supported by the e5500 ( see e5500 rm). But, depending on a bit in the l1 cache control register,
it works on half or full cache lines. The new opcode e5500 dcbal opcode works always on full cachelines.
But again not recognized by gcc.


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

Go to top


Re: binutils 2.40 first native(!) beta tests !
Just popping in
Just popping in


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

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


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

Go to top


Re: PCI virtio driver development
Just popping in
Just popping in


@hans @balaton

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

(qemuinfo virtio-status /machine/peripheral-anon/device[3]/virtio-backend
/machine/peripheral-anon/device[3]/virtio-backend:
  
device_name:             virtio-blk 
  device_id
:               2
  vhost_started
:           false
  bus_name
:                (null)
  
broken:                  false
  disabled
:                false
  disable_legacy_check
:    false
  started
:                 true
  use_started
:             true
  start_on_kick
:           false
  use_guest_notifier_mask
true
  vm_running
:              true
  num_vqs
:                 1
  queue_sel
:               0
  isr
:                     0
  endianness
:              big
  status
:
    
VIRTIO_CONFIG_S_ACKNOWLEDGEValid virtio device found,
    
VIRTIO_CONFIG_S_DRIVERGuest OS compatible with device,
    
VIRTIO_CONFIG_S_FEATURES_OKFeature negotiation complete,
    
VIRTIO_CONFIG_S_DRIVER_OKDriver setup and ready
  Guest features
:

  
Host features:
    
VIRTIO_RING_F_EVENT_IDXUsed availevent fields enabled,
    
VIRTIO_RING_F_INDIRECT_DESCIndirect descriptors supported,
    
VIRTIO_F_RING_RESETDriver can reset a queue individually,
    
VIRTIO_F_VERSION_1Device compliant for v1 spec (legacy),
    
VIRTIO_F_ANY_LAYOUTDevice accepts arbitrary desclayouts,
    
VIRTIO_F_NOTIFY_ON_EMPTYNotify when device runs out of availdescson VQ
    VHOST_USER_F_PROTOCOL_FEATURES
Vhost-user protocol features negotiation supported,
    
VIRTIO_BLK_F_CONFIG_WCECache writeback and writethrough modes supported,
    
VIRTIO_BLK_F_FLUSHFlush command supported,
    
VIRTIO_BLK_F_WRITE_ZEROESWrite zeroes command supported,
    
VIRTIO_BLK_F_DISCARDDiscard command supported,
    
VIRTIO_BLK_F_TOPOLOGYTopology information available,
    
VIRTIO_BLK_F_BLK_SIZEBlock size of disk available,
    
VIRTIO_BLK_F_GEOMETRYLegacy geometry available,
    
VIRTIO_BLK_F_SEG_MAXMax segments in a request is seg_max
  Backend features
:


And I even setup a request in the queue:

(qemuinfo virtio-queue-element /machine/peripheral-anon/device[3]/virtio-backend 0 0
Desc next is 768
/machine/peripheral-anon/device[3]/virtio-backend:
  
device_namevirtio-blk
  index
:   0
  desc
:
    
descs:
        
addr 0x471ad70 len 1 (writenext),
        
addr 0x4709ca0 len 7 (next),
        
addr 0x471ad60 len 16 (next)
  
avail:
    
flags0
    idx
:   0
    ring
:  0
  used
:
    
flags0
    idx
:   256
(qemu)


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.

Go to top


Re: PCI virtio driver development
Just popping in
Just popping in


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

Go to top


PCI virtio driver development
Just popping in
Just popping in


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.

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


@joerg

Quote:

Another reason .rodata should be separated from .text (and .plt) is the way (non-)execuable memory is allocated in AmigaOS 4.x. At least on some CPUs you can't change it after allocation from executable to non-executable, or the other way round.


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:

If you are developing a PPC library (AmigaOS foobar.library, not libfoobar.a or libfoobar.so) which also exists in a AmigaOS 3.x/m68k version and uses Hooks you will get m68k Hook functions from AmigaOS 3.x/m68k executables using the PPC version of the library on AmigaOS 4.x.
The same is theoretically possible for m68k interrupts as well, but unlikely to be used.


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 ?

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


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

Go to top


Re: can anybody explain about current situation with BREL Relocations ?
Just popping in
Just popping in


@Futaura

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

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


@Oliver

Around line 9345 the "magically" patch is made.

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


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

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


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

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


@Futaura

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

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


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

[Elf32_LoadSectionOn Entry SectionIndex 37 Filename Work:1/test_dyn
[Elf32_LoadSectionsec 0x60C11000
[Elf32_LoadProgramHeadersFileWork:1/test_dyn
[Elf32_LoadProgramHeadersProgram Header offset0x00000034
[Elf32_LoadProgramHeadersProgram Header entrysize32
[Elf32_LoadProgramHeadersProgram Header array size6
[Elf32_LoadProgramHeadersProgHeader 0Type 6
[Elf32_LoadProgramHeaders]      Virtual0x01000034
[Elf32_LoadProgramHeaders]      MemSize0x000000C0
[Elf32_LoadProgramHeaders]      Flags:   0x00000004
[Elf32_LoadProgramHeadersProgHeader 1Type 3
[Elf32_LoadProgramHeaders]      Virtual0x010000F4
[Elf32_LoadProgramHeaders]      MemSize0x00000011
[Elf32_LoadProgramHeaders]      Flags:   0x00000004
[Elf32_LoadProgramHeadersProgHeader 2Type 1
[Elf32_LoadProgramHeaders]      Virtual0x01000000
[Elf32_LoadProgramHeaders]      MemSize0x000050B0
[Elf32_LoadProgramHeaders]      Flags:   0x00000005
[Elf32_LoadProgramHeadersIgnoring this program header because we have an .rodata segment
[Elf32_LoadProgramHeadersProgHeader 3Type 1
[Elf32_LoadProgramHeaders]      Virtual0x01010000
[Elf32_LoadProgramHeaders]      MemSize0x00000130
[Elf32_LoadProgramHeaders]      Flags:   0x00000006
[Elf32_LoadProgramHeadersAllocated 304 bytes for segment 0 at 0x60D907C0
[Elf32_LoadProgramHeadersProgHeader 4Type 2
[Elf32_LoadProgramHeaders]      Virtual0x01010010
[Elf32_LoadProgramHeaders]      MemSize0x000000B8
[Elf32_LoadProgramHeaders]      Flags:   0x00000006
[Elf32_LoadProgramHeadersProgHeader 5Type 1
[Elf32_LoadProgramHeaders]      Virtual0x01005000
[Elf32_LoadProgramHeaders]      MemSize0x000000A5
[Elf32_LoadProgramHeaders]      Flags:   0x00000004
[Elf32_LoadProgramHeadersIgnoring this program header because we have an .rodata segment


and the segment / section stuff:

Segment Sections...
   
00
   01     
.interp
   02     
.interp .hash .dynsym .dynstr .rela.bss .rela.plt .text .plt .__newlib_version
   03     
.ctors .dtors .dynamic .data .got .sbss .bss
   04     
.dynamic
   05     
.rodata


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

Quote:
Ignoring this program header because we have an .rodata segment


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.

Go to top


Re: gcc 9 and 10
Just popping in
Just popping in


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

Ignoring this program header because we have an .rodata segment


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

Program Headers:
  
Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x01000034 0x01000034 0x000c0 0x000c0 R   0x4
  INTERP         0x0000f4 0x010000f4 0x010000f4 0x00011 0x00011 R   0x1
      
[Requesting program interpreter: /usr/lib/ld.so.1]
  
LOAD           0x000000 0x01000000 0x01000000 0x050b0 0x050b0 R E 0x10000
  LOAD           0x015000 0x01005000 0x01005000 0x000a5 0x000a5 R   0x10000
  LOAD           0x020000 0x01010000 0x01010000 0x000d8 0x00130 RW  0x10000
  DYNAMIC        0x020010 0x01010010 0x01010010 0x000b8 0x000b8 RW  0x4

 Section to Segment mapping
:
  
Segment Sections...
   
00
   01     
.interp
   02     
.interp .hash .dynsym .dynstr .rela.bss .rela.plt .text .plt .__newlib_version
   03     
.rodata
   04     
.ctors .dtors .dynamic .data .got .sbss .bss
   05     
.dynamic


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

[Elf32_LoadSectionOn Entry SectionIndex 37 Filename Work:2/test_dyn
[Elf32_LoadSectionsec 0x5FFE9000
[Elf32_LoadProgramHeadersFileWork:2/test_dyn
[Elf32_LoadProgramHeadersProgram Header offset0x00000034
[Elf32_LoadProgramHeadersProgram Header entrysize32
[Elf32_LoadProgramHeadersProgram Header array size6
[Elf32_LoadProgramHeadersProgHeader 0Type 6
[Elf32_LoadProgramHeaders]      Virtual0x01000034
[Elf32_LoadProgramHeaders]      MemSize0x000000C0
[Elf32_LoadProgramHeaders]      Flags:   0x00000004
[Elf32_LoadProgramHeadersProgHeader 1Type 3
[Elf32_LoadProgramHeaders]      Virtual0x010000F4
[Elf32_LoadProgramHeaders]      MemSize0x00000011
[Elf32_LoadProgramHeaders]      Flags:   0x00000004
[Elf32_LoadProgramHeadersProgHeader 2Type 1
[Elf32_LoadProgramHeaders]      Virtual0x01000000
[Elf32_LoadProgramHeaders]      MemSize0x000050B0
[Elf32_LoadProgramHeaders]      Flags:   0x00000005
[Elf32_LoadProgramHeadersIgnoring this program header because we have an .rodata segment
[Elf32_LoadProgramHeadersProgHeader 3Type 1
[Elf32_LoadProgramHeaders]      Virtual0x01005000
[Elf32_LoadProgramHeaders]      MemSize0x000000A5
[Elf32_LoadProgramHeaders]      Flags:   0x00000004
[Elf32_LoadProgramHeadersIgnoring this program header because we have an .rodata segment
[Elf32_LoadProgramHeadersProgHeader 4Type 1
[Elf32_LoadProgramHeaders]      Virtual0x01010000
[Elf32_LoadProgramHeaders]      MemSize0x00000130
[Elf32_LoadProgramHeaders]      Flags:   0x00000006
[Elf32_LoadProgramHeadersAllocated 304 bytes for segment 0 at 0x61DCF040
[Elf32_LoadProgramHeadersProgHeader 5Type 2
[Elf32_LoadProgramHeaders]      Virtual0x01010010
[Elf32_LoadProgramHeaders]      MemSize0x000000B8
[Elf32_LoadProgramHeaders]      Flags:   0x00000006
[_elf32_ElfLoadSegEntry
[Elf32_LoadSectionOn Entry SectionIndex 35 Filename Work:2/test_dyn
[Elf32_LoadSectionehdr->e_shstrndx 37shdr->sh_name 1


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?

Go to top


Re: PCI device memory from BAR under qemu alwys zero
Just popping in
Just popping in


@Hans

Yeap that made the trick:

pciDevice->WriteConfigWordPCI_COMMAND,0x002 pciDevice->ReadConfigWordPCI_COMMAND ) );


Now i get other stuff than zeros!

Go to top


Re: PCI device memory from BAR under qemu alwys zero
Just popping in
Just popping in


@Hans

Quote:

If it's the latter, then check whether the master and memory enable bits are set in the PCI_COMMAND register (enable I/O accesses
too if you have an I/O BAR). You need to enable those bits in order to access the memory.


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?

Go to top



TopTop
(1) 2 3 4 ... 8 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project