How do I do use the VPU on OS other than Linux or Android?

[忍松本]

We are running on i.MX6Q the T-Kernel.
Order to use the VPU, we are porting the driver from Linux, but the problem has occurred.
This timing, is CPU crashes and no response.

--- vpu_lib.c L.443 ---
BitIssueCommand(NULL, FIRMWARE_GET);
-----------------------

Additional Information (Nov.22.2013):

  - i.MX6Q have four cores, but we are using only a single core.

  - Our environment

      imx-lib version : imx-lib-12.09.01

      board : Collage-MX6Q (Sohwa & Sophia Technologies)

Thanks in Advance.

Shinobu MATSUMOTO

[jack_mao]

Hi Sir,

         Could you give more information to track this issue?

         1>  what's the ltib release version? 

          2> what did you do to make the system crash?

          3> please provide the crash log, VPU firmware version.

        By the way, in your question description, what's the meaning about  "

--- vpu_lib.c L.443 ---

BitIssueCommand(NULL, FIRMWARE_GET);  "

best regards

Jack

[忍松本]

Hi Jack,

I answer the following statement.

>    1>  what's the ltib release version?

    ltib 9.1.1 ($Revision: 1.445.6.1 $)

    BSP Version : L3.0.35_12.09.01.01

    (We use BIT firmware included in this BSP.)

>    2> what did you do to make the system crash?

    I wrote a value of the contents of the attached file to the BIT control registor.
    (Offset of 0x90000000 is added to the write address for MMU)

>    3> please provide the crash log, VPU firmware version.

    Attachment is all of the log up to the crash.
    I don't know VPU firmware version because the information is not disclosed.

>       By the way, in your question description, what's the meaning about  "
> --- vpu_lib.c L.443 ---
> BitIssueCommand(NULL, FIRMWARE_GET);  "

    CPU crash occurs at the timing of executing this command.
    However I think this instruction is not the cause.

Best regards

Shinobu MATSUMOTO

[jack_mao]

Hi Shinobu ,

     sorry for late reply,  from your answer and description, you port our VPU driver, does that means you don't use linux? The other question is why you need add 0x90000000 offset? I still don't get a full picture about your issue, because on our reference board&BSP, never happen this kind of issue, if you port to another system, please make sure the driver and firmware are all ported correctly.    By the way, please use my full name, then the system will send a email to inform me that the question is updated. Thanks!

best regards

Jack

[忍松本]

Hi Junping Mao ,

I ported VPU driver on T-Kernel (http://en.wikipedia.org/wiki/T-Kernel).

T-Kernel uses an address of 0x00000000... for multi-processing.
Therefore I set an offset of 0x90000000 using MMU.

I ported VPU driver (vpu-lib & mxc-vpu) and BIT firmware.

I sent log file by a former reply. Will you confirm whether it is right in this procedure?

By the way, would you offer the reference manual of the BIT processor and a related document to me?

Best regards
Shinobu MATSUMOTO

[jack_mao]

Hi Shinobu MATSUMOTO,

       To port VPU, you need port mxc-vpu & VPU lib, use firmware directly, that will be enough, VPU lib should be in user space.  by the way, the vpu documents can't share.

best regards

Jack

[忍松本]

Hi Junping Mao ,

Thank you for your support.

I ported VPU driver by a method same as your saying.
(of course VPULib locates in the user space.)

Did you confirm log file? and is this procedure right?

In addition, if there is a probable cause, please inform me.
(e.g., timing to write data)

Best regards

Shinobu MATSUMOTO

[忍松本]

Hi Junping Mao ,

I'm in trouble due delivery time of my customers is imminent.

So, could you give me the answer to today(29 Nov)?

> Did you confirm log file? and is this procedure right?
>
> In addition, if there is a probable cause, please inform me.
> (e.g., timing to write data)

Thanks for your cooperation.
Shinobu MATSUMOTO

[jack_mao]

Hi Shinobu MATSUMOTO,

       what's the log file? Do you mean that one "

VREAD: addr=92040018 data=00000000

VWRITE: addr=92040100" I can't get more information from that, if not, I haven't seen any other log file. Due to different OS, I have no idea why it doesn't work.

could you try to access the VPU in kernel mode to see if the firmware and vpu interface works?

best regards

Mao junping

[忍松本]

Hi Junping Mao ,

Please let me ask you again.

Did you confirm log file? and is this procedure right?

read this as the log.

  > VREAD: addr=92040018 data=00000000
  value = *(0x92040018);
  if (value == 0x00000000) {
    // pass through here;
  }

  > VWRITE: addr=92040100 data=00000000
  *(0x92040100) = 0x00000000;

Did you understand?

Because it might not read the file maybe, and attach again.
(out_log.txt (2129 lines))

I have access in kernel mode to VPU now.
And, vpu_lib has been used in user mode,
I have to transfer the values to the kernel mode.
I have to communicate with the kernel every time vpu_lib writes once.
In every communication, is being written by 4 bytes.

Is there a problem with this access method?

Could you give me the answer to today(29 Nov)?

best regards.

Shinobu MATSUMOTO

[jack_mao]

Hi Shinobu MATSUMOTO,

     Your procedure is ok, but you should make sure the base address is right, in linux the base address in vpu_lib is come from mmap, another you should make sure the VPU has been initialized correctly, are you access the PC register and buffer register?

best regards

Mao junping

[忍松本]

Hi Junping Mao ,

Base address has been confirmed that it is correct. (0x02040000 + 0x90000000)

and I can access the PC register.(0x02040018 + 0x90000000)

but what is buffer register?

Although not listed in the manual (IMX6DQRM), please teach me.

best regards

Shinobu MATSUMOTO

[jack_mao]

Hi Shinobu MATSUMOTO

           0x2040100 should be a buffer register.  from your access way I can't see any problem, so you write/read many times, and then the system crash, right? I don't know if there is any limitation, I will get the Firmware engineer support next week, today he is not in office, so if you give a detail description, what's your test purpose,  how many times you write/read to VPU,  about which time it will crash,  collect the enough data, it will helpful 

[忍松本]

Hi Junping Mao ,

The system will crash at the end of the LOG file.
I do not have access to the VPU with the contents other than those listed in the log file.

Thank you again next week.

Shinobu MATSUMOTO

[jack_mao]

Hi Shinobu MATSUMOTO ,

      could you paste here your test code segement include the printf code, that's will help us to understand your test procedure, then I will discuss your code with the firmware engineer.

Mao junping

[daisuketsuchiya]

Hello Junping Mao,

    Please let me confirm your request.

The reason why you are asking the test code to us is to know why the access to VPU is so frequent?  Or, do you need a driver code that is accessing the VPU actually?  We are using GStreamer, not the test code, so GStreamer is done "our test procedure" that you say.

    Still do you need our code?  If so, we have a problem to provide our code.  I can not paste our code to this community because it is confidential.  Is there a way to send the code directly to you.

Thank you.
Daisuke TSUCHIYA

[jack_mao]

Hi Daisuke TSUCHIYA,

   I have just discussed your issue and log with our firmware engineer,it seems that your firmware has been downloaded to VPU,

   "VREAD: addr=92040160 data=00000000

   VREAD: addr=92040018 data=00000020"  show it run successfully.  Please make sure you follow vpu_lib.c vpu_init routine to do initialization.

Hi Karina Valencia Aguilar

   please ask Yang Hongzhang to provide deep support, he is the VPU owner

[karina_valencia]

HongzhangYang can you help on this case?

[daisuketsuchiya]

Hello Junping Mao,

I am Daisuke TSUCHIYA and Shinobu's colleagues.  I will reply instead of Shinobu.

We are using GStreamer and our log is equivalent to the output from VpuReadReg() and VpuWriteReg() of vpu_io.c.

I think that it will not help you to give you our code, because it has changed from Linux to T-Kernel.  However I will be prepare it.
Since the T-Kernel does not support mmap, we have created a driver that implements the mmap.

If there is no problem with the procedure of us, I want to know other causes can be considered.  eg Linux intialize routine is operating the VPU.

And if possible, I would like to have a telephone conference with you.

Thanks for your cooperation.
Daisuke TSUCHIYA

[HongzhangYang]

Daisuke,

Their VPU init procedure is exactly correct except they use 8 byte alignment for 3 buffers. We suggest to use 4K alignment but this will not cause a problem during VPU init.

However, after VPU init completed (BASE_0160=0), the PC register (BASE_0018=20) is not correct. Should be B9 or BB.

I advise them to make more experiments:

1. Write and read test of BASE_0160

Write 0x1234 to BASE_0160, and read it to check if it contains correct value

2. Add a dead loop checking BASE_0160 and BASE_0018 after BASE_0000=1

3. Check whether VPU clock was enabled before they get version

VREAD: addr=92040018 data=00000000

[Hongzhang]: check 1

VWRITE: addr=92040100 data=00000000

... ...

VWRITE: addr-92040000 data=00000001

[Hongzhang]: check 2.

VREAD: addr=92040160 data=00000000

VREAD: addr=92040018 data=00000000

[Hongzhang]: check 3.

VWRITE: addr=920401C0 data=00000000

Regards,

Hongzhang

[daisuketsuchiya]

Hello Hongzhang Yang,

Thank you for advice.

I attach the result of the check.

check1: It has been able to read correctly. (check1_log.txt)

     VREAD: addr=92040018 data=00000000

     check1

     VWRITE: addr=92040160 data=00001234

     VREAD: addr=92040160 data=00001234

check2 and check3: BASE_0018 is 0xBB and VPU clock was enabled (0x020C_8140 has 0x0000_3E00).

(check2-3_log.txt)

     VWRITE: addr=92040000 data=00000001

     check2

     VREAD: addr=92040160 data=00000000

     VREAD: addr=92040018 data=000000B9

     check3

     VREAD: addr=920C8140 data=00483E12

     VREAD: addr=92040160 data=00000000

And I tried 3 cases.

I have removed a dead loop,  I could not get the version. (log_no-dead-loop.txt)

     VWRITE: addr=92040000 data=00000001

     check2

     VREAD: addr=92040160 data=00000000

     VREAD: addr=92040018 data=000000BB

     check3

     VREAD: addr=920C8140 data=00483E12

     VREAD: addr=92040160 data=00000000

     VREAD: addr=92040018 data=000000B9

     VWRITE: addr=920401C0 data=00000000

     VWRITE: addr=92040160 data=00000001

     VWRITE: addr=92040168 data=00000020

     VWRITE: addr=9204016C data=00000000

     VWRITE: addr=92040178 data=00000000

     VWRITE: addr=92040164 data=0000000F

     VREAD: addr=92040160 data=00000000

     VREAD: addr=920401C0 data=00000000

     VREAD: addr=920401C4 data=00000000

When I have removed all check routine, CPU has crashed and no response. (log_no-delay.txt)

     VWRITE: addr=92040000 data=00000001

     VREAD: addr=92040160 data=00000000

     dbg0: (please ignore this)

     VREAD: addr=92040018 data=00000000

When I put a delay of 1ms after the Read and Write of register,  BASE_0018=20 and I could not get the version info.

     VWRITE: addr=92040000 data=00000001

     VREAD: addr=92040160 data=00000000

     VREAD: addr=92040018 data=00000020

     VWRITE: addr=920401C0 data=00000000

     VWRITE: addr=92040160 data=00000001

     VWRITE: addr=92040168 data=00000020

     VWRITE: addr=9204016C data=00000000

     VWRITE: addr=92040178 data=00000000

     VWRITE: addr=92040164 data=0000000F

     VREAD: addr=92040160 data=00000000

     VREAD: addr=920401C0 data=00000000

     VREAD: addr=920401C4 data=00000000

Is there any timing issue?  Because it seems that the behavior changes when I put the delay.

Best Regards,

Daisuke TSUCHIYA