JH with linux 4.0-rc7 on bananapi

[Philipp Rosenberger]

Hi,

I try to start jailhouse from linux 4.0-rc7 on bananapi. But i get the
following error:

Page pool usage after cell creation: mem 30/16368, remap 32/32768
Unhandled data read at 0x1c20c28(4)
FATAL: unhandled trap (exception class 0x24)
pc=0xc02f15c0 cpsr=0x60030193 esr=0x93800007
r0=0x00000000 r1=0x00000006 r2=0x00000006 r3=0xf004ec00
r4=0x0007dc0a r5=0x00000000 r6=0x000011e0 r7=0x00000000
r8=0xc0546540 r9=0x00000000 r10=0xc054cf40 r11=0xee6c5d34
r12=0xc0546508 r13=0xc0546508 r14=0xc0546508
Parking CPU 0 (Cell: "Banana-Pi")

It seems the linux kernel tries to access the TMR1_CUR_VALUE_REG
register. With linux 3.19-rcX I get it running. All linux kernel.org
vanilla without 3rd party patches.

Best regards
Philipp Rosenberger

[Jan Kiszka]

Hi Philipp,

Hmm, I'm still on rc1 with the Banana Pi here. Maybe some later patch
changed the usage patterns of the kernel.

Are you using a kernel config identical to or derived from the what we
have in ci/kernel-config-banana-pi?

The mid-term answer to this can be found in TODO under Misc: generic
sub-page access filtering. That would allow to grant access to, say,
TMR1 to the root cell while given the cell access to unrelated units on
the same MMIO page.

Jan

--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

[Philipp Rosenberger]

Hi Jan,

On 09.04.2015 16:39, Jan Kiszka wrote:
> Hi Philipp,
>
> On 2015-04-09 11:21, Philipp Rosenberger wrote:
>> Hi,
>>
>> I try to start jailhouse from linux 4.0-rc7 on bananapi. But i get the
>> following error:
>>
>> Page pool usage after cell creation: mem 30/16368, remap 32/32768
>> Unhandled data read at 0x1c20c28(4)
>> FATAL: unhandled trap (exception class 0x24)
>> pc=0xc02f15c0 cpsr=0x60030193 esr=0x93800007
>> r0=0x00000000 r1=0x00000006 r2=0x00000006 r3=0xf004ec00
>> r4=0x0007dc0a r5=0x00000000 r6=0x000011e0 r7=0x00000000
>> r8=0xc0546540 r9=0x00000000 r10=0xc054cf40 r11=0xee6c5d34
>> r12=0xc0546508 r13=0xc0546508 r14=0xc0546508
>> Parking CPU 0 (Cell: "Banana-Pi")
>>
>> It seems the linux kernel tries to access the TMR1_CUR_VALUE_REG
>> register. With linux 3.19-rcX I get it running. All linux kernel.org
>> vanilla without 3rd party patches.
>
> Hmm, I'm still on rc1 with the Banana Pi here. Maybe some later patch
> changed the usage patterns of the kernel.
>
> Are you using a kernel config identical to or derived from the what we
> have in ci/kernel-config-banana-pi?

I'm using the sunxi_defconfig from my linux kernel. I tried with
ci/kernel-config-banana-pi but got the same result.

> The mid-term answer to this can be found in TODO under Misc: generic
> sub-page access filtering. That would allow to grant access to, say,
> TMR1 to the root cell while given the cell access to unrelated units on
> the same MMIO page.

Ok, this seems to be a bigger pile of work.

The devicetree and the driver for the timer are also included in the
3.19 kernel. I think I will try to bisect down when the braking change
was introduced into the kernel.

Regards
Philipp

[Henning Schild]

Just "git blame" the source behind the pc. If you are lucky its just a
kernel feature you can remove from your 4.0 .config.
If it cannot be turned off you can still grant Linux access to the
whole page. Assuming this page contains critical control registers,
that might not be what you want in the long run.

Henning

[Jan Kiszka]

I don't know yet what brought this problem forward, but a patch analogue
to 6e20602032 (clocksource/drivers/sun5i: Fix cpufreq interaction with
sched_clock()) makes Linux leave the register alone again.

From a first glance, it's always the last registered sched_clock that is
used (your boss can surely confirm this ;) ). So maybe something
reordered the sun4i vs. arm_arch_timer registration, thus caused the
former to become active. If you have time, you could check with upstream
if the reason provided in 6e20602032 also applies to sun4i_timer.

Jan

[Philipp Rosenberger]

Hi Jan,

Thanks for the hint. I upgraded to v4.0 today which contains the patch
you mentioned. Now the indeed leaves the register alone. Now I get a new
unhandled data read at 0x1c25014 wich is TP_INT_FIFOS. I added the page
@0x01c25000 as memregion to the config/bananapi.c file. Now the
hypervisor starts without errors.

now when I try to run "jailhouse cell create
configs/bananapi-uart-demo.cell" I get the unhandled read at 0x1c20c28
again. If I understand right what is done than at this state this access
could only come from linux or from the hypervisor. As the "cell create"
command only creates the cell but no guest/inmate is running inside the
new cell?

Best Regards

Philipp

PS: I should give you regards from Benedikt Spranger.
--
Phone: +49 7556 91 98 91; Fax.: +49 7556 91 98 86

Firmensitz: 88690 Uhldingen, Auf dem Berg 3
Registergericht: Amtsgericht Freiburg i. Br., HRB 700 806;
StNr. 87007/07777; Ust-Id Nr.: DE252739476
Geschäftsführer: Heinz Egger, Thomas Gleixner

[Jan Kiszka]

Perfect!

> unhandled data read at 0x1c25014 wich is TP_INT_FIFOS. I added the page
> @0x01c25000 as memregion to the config/bananapi.c file. Now the
> hypervisor starts without errors.

OK. That's the touch screen. My device here is headless. But a patch to
add it would be fine.

>
> now when I try to run "jailhouse cell create
> configs/bananapi-uart-demo.cell" I get the unhandled read at 0x1c20c28
> again. If I understand right what is done than at this state this access
> could only come from linux or from the hypervisor. As the "cell create"
> command only creates the cell but no guest/inmate is running inside the
> new cell?

The access can only come from Linux. The hypervisor would cause a fault,
not a vmexit with such a report.

Cell creation means access right revocation for Linux: resources you
list in the cell config are taken from Linux (provided they were given
to it initially). But the output should tell you that the cell
"Banana-Pi", i.e. the root cell, caused this.

Can you correlate the PC reported with code in the Linux kernel? This is
how I found out that sched clock was involved.

>
> Best Regards
>
> Philipp
>
> PS: I should give you regards from Benedikt Spranger.
>

Send some back!

[Henning Schild]

On Tue, 14 Apr 2015 14:42:05 +0200
Philipp Rosenberger <i...@linutronix.de> wrote:

> now when I try to run "jailhouse cell create
> configs/bananapi-uart-demo.cell" I get the unhandled read at 0x1c20c28
> again. If I understand right what is done than at this state this
> access could only come from linux or from the hypervisor. As the
> "cell create" command only creates the cell but no guest/inmate is
> running inside the new cell?

Yes that access is coming from Linux. The message also says which cell
is to blame, in your case probably again

>> Parking CPU 0 (Cell: "Banana-Pi")

Henning

[Philipp Rosenberger]

Hi Jan,

after I removed the equivalent lines of this commit 6e20602032 from
sun4i_timer.c I got it running. Thanks for your help.

Best regards
Philipp

[Jan Kiszka]

On 2015-04-16 12:08, Philipp Rosenberger wrote:
> Hi Jan,
>

> after I removed the equivalent lines of this commit 6e20602032 from
> sun4i_timer.c I got it running. Thanks for your help.

Hmm, but that means 37b8b003c doesn't help you?

[Philipp Rosenberger]

Hi Jan,

On 16.04.2015 13:47, Jan Kiszka wrote:
> Hmm, but that means 37b8b003c doesn't help you?

I tried the patch from 37b8b003c which also works fine.

Regards
Philipp