Schnoogle
Posts: 145
Joined: Sun Feb 11, 2018 4:47 pm

RPi3 - VCHIQ help required

Fri Jul 17, 2020 4:47 pm

Hi there,

I'm in the phase of implementing a VCHIQ "driver" in Rust. I was able to manage to setup the SlotZero structure and fill it with the correct data and pass its memory address via mailbox property interface to the VideoCore. This initial handshake works fine.

The VC part of the VCHIQ interface immediately puts a "CONNECT" message into the first slot "owned" by the VC and I was able to send a "CONNECT" message to the VC from the ARM side. However, it seems I'm stuck here. As soon as I'm sending additional messages - eg. to open a service the VC does not seem to process the same.

The remote shared structure from the SlotZero indicates that I've successfull triggerd the corresponding event and the VC side has armed this event. So when ringing the VC doorbell the VC should pickup the work and process the next message the ARM side has put into the slots. But this seems not to be the case. The debug-structure of the remote side indicates that the slot_handler has been called only once and the slot_handler line is 1851. Without knowning the source code of the VCHIQ side it's hard to tell what's in that line but my assumption would be some kind of mutex/semaphore that could not be aquired and therefore the slot_handler keeps sitting at this position.

The beginning of the remote shared state:

Code: Select all

SharedState {
    initialized: 1,
    slot_first: 2,
    slot_last: 32,
    slot_sync: 1,
    trigger: Event {
        armed: 1,
        fired: 1,
        event: "0xf49ac78",
    },
    tx_pos: 8,
    recycle: Event {
        armed: 1,
        fired: 0,
        event: "0xf49ac7c",
    },
    slot_queue_recycle: 31,
    sync_trigger: Event {
        armed: 1,
        fired: 0,
        event: "0xf49ac80",
    },
    sync_release: Event {
        armed: 0,
        fired: 0,
        event: "0xf49ac84",
    },
and the debug info:

Code: Select all

debug: [
        11,
        1,
        1851,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
        0,
    ],
Any one here who might be able to help here a bit ?
I'm kind of stuck as I've no clue why VC does not pick up the work. I'd assume that the slot_handler_count number in the debug info would increase if the VC would process the trigger event.

Thanks in advance

valc
Posts: 60
Joined: Mon Oct 21, 2019 10:17 pm

Re: RPi3 - VCHIQ help required

Thu Feb 25, 2021 10:27 pm

So how did you beat this one?

Schnoogle
Posts: 145
Joined: Sun Feb 11, 2018 4:47 pm

Re: RPi3 - VCHIQ help required

Mon Mar 01, 2021 3:53 pm

Hi,

well finally it turned out that it was a caching issue. Even though I updated the memory position from the ARM side it just hit the cache. The VC assumes/expects the memory region to be used to be uncached. After properly setting up the MMU and configure the memory region to be used for the exchange between ARM and VC the issue was gone and everything worked as expected.

cleverca22
Posts: 3576
Joined: Sat Aug 18, 2012 2:33 pm

Re: RPi3 - VCHIQ help required

Mon Mar 01, 2021 8:31 pm

Schnoogle wrote:
Mon Mar 01, 2021 3:53 pm
Hi,

well finally it turned out that it was a caching issue. Even though I updated the memory position from the ARM side it just hit the cache. The VC assumes/expects the memory region to be used to be uncached. After properly setting up the MMU and configure the memory region to be used for the exchange between ARM and VC the issue was gone and everything worked as expected.
yeah, you either need it uncached, or cached/writecached and do a cache flush

i suspect writecached would speed up the writing, and also minimize the time spent on flush, same reason /dev/fb0 is mapped write cached

Schnoogle
Posts: 145
Joined: Sun Feb 11, 2018 4:47 pm

Re: RPi3 - VCHIQ help required

Wed Mar 03, 2021 9:42 pm

Well, I did not managed anything to get working with cache active and flushing, thus I’d recommend to switch of caching for the region (pages) of the shared memory. Cache flushes from ARM side always seem to mess with the memory the VC did see in my attempts, but maybe I did something wrong :oops:

cleverca22
Posts: 3576
Joined: Sat Aug 18, 2012 2:33 pm

Re: RPi3 - VCHIQ help required

Wed Mar 03, 2021 10:55 pm

if its fully cached (read and write)
you need to keep in mind, that both L1 and L2 must be flushed AND discarded
and you must not attempt to read it until after the vpu has modified things

but i think you mentioned there is a separate buffer for both arm->vpu and vpu->arm, and only one party writes to each buffer?

for the arm->vpu buffer, i would use write-caching, and then do a full L1 and L2 flush, and memory barrier, then hit the doorbell
for the vpu->arm buffer, i would maybe use read caching, but issue a cache discard when i expect changes to have occurred

but you also need to be careful of alignments, so when you discard a cache-line in the vpu->arm buffer, there is no un-commited data the arm was writing, in the same cache-line, so the buffer must be cache-line aligned, and a cache-line multiple in size, and the arm must never write to that buffer

in theory, that would give you better performance, since you wont be getting a full miss on every single access, but it would need testing to confirm it all

kkj9018
Posts: 4
Joined: Thu Nov 26, 2020 8:16 am

Re: RPi3 - VCHIQ help required

Thu Apr 22, 2021 4:32 am

Hi,can your camera work normally in a bare metal environment now?

Return to “Bare metal, Assembly language”