Re: [Xen-users] i2c pass-through in mpsoc

[Jesús Lázaro <jesus.lazaro@xxxxxxx>]

Hi Andre,


On 26/10/17 23:05, Andre Przywara wrote:
> Hi Jesús,
...

> Xen can't, because only the Dom0 clock driver knows how. We are hitting 
> this thing more often now, and I will raise this problem on some Linux 
> list ASAP. We would like to have something where we can specify 
> *certain* clocks that should stay enabled, short of the 
> clk_ignore_unused sledge hammer. Then Xen could just list those clocks 
> in some DT node.
> Another solution would be to let Dom0 explicitly enable the clocks, but 
> this has to be done in the kernel and I am not aware of an interface to 
> userland to trigger that from the Xen tool side.
> So if you somehow can find the register that enables this clock and 
> manipulate this in U-Boot, then pass clk_ignore_unused, it should work. 
> I did a similar thing in the past (using md.l and mw.l on the U-Boot 
> prompt).
I have tried to have i2c running before Dom0 is launched. In the mpsoc, 
there is a fist stage bootloader that is in charge of configuring hw 
related parts. This FSBL should have all the clocks running. I have 
accessed all relevant registers from uboot and they look fine. If I try 
to access the other i2c core (which is disabled) uboot hangs.
From within Dom0, I have tried to use devmem to read the i2c registers. 
Here I have two different results. If i2c is enabled in the DT, linux 
hangs. If disabled and with the passthrough I have the following error:
Unhandled fault: ttbr address size fault (0x92000000) at 0x0000007f875b6000

If trying to access the disabled i2c, it always hangs.

So I think that the I2C core I want to passthrough is active, has clock 
and is operational. But Dom0 thinks that the clock is disabled (possibly 
because reading the DT that clock is not used and the kernel does not 
check all the internal registers to find out what is on or off).
If I change the clocks in the DT for the I2C (without xen) and point 
them to a clock that is stopped, the driver complains about irq not 
functioning. But when doing a passthorugh it does not complain. The 
message is the same as when not having any active i2c device in the DT.
...


> In this example we get somewhat lucky, because this network device does 
> not need any clock to be specified in the DT. There is probably a clock, 
> but it's always on.
I have tried the networking example by Xilinx and I think that it does 
not work. Without doing the uboot modification for the DMA, the result 
is the same as for I2C. No module is loaded. If doing the DMA 
modifications, kernel panic when launching Dom0
(XEN) GICv2: Adjusting CPU interface base to 0xf902f000
(XEN) GICv2: 192 lines, 4 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Bad mode in Error handler detected
(XEN) ESR=0xbf000000:  EC=2f, IL=1, ISS=1000000
(XEN) ----[ Xen-4.8.1-pre  arm64  debug=n   Not tainted ]----
(XEN) CPU:    0
(XEN) PC:     00000000002823a8 start_xen+0x8e0/0xbd0
(XEN) LR:     00000000002823a0
(XEN) SP:     00000000002afe20
(XEN) CPSR:   00000249 MODE:64-bit EL2h (Hypervisor, handler)
...
(XEN) Xen call trace:
(XEN)    [<00000000002823a8>] start_xen+0x8e0/0xbd0 (PC)
(XEN)    [<00000000002823a0>] start_xen+0x8d8/0xbd0 (LR)
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) bad mode
(XEN) ****************************************


Regards,
Jesús

--
-------------------------------------------------------------------------
Jesús Lázaro Arrotegui Universidad del País Vasco
Tecnología Electrónica
Departamento de Tecnología Electrónica
Escuela de Ingeniería de Bilbao
Email: jesus.lazaro@xxxxxxx
WWW:   det.bi.ehu.eus/~apert
Pl. Ingeniero Torres Quevedo 1     Tel.: 34 - 94 - 601 73 44
48013 BILBAO (SPAIN)                   Fax.: 34 - 94 - 601 39 07
-------------------------------------------------------------------------

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users