Hi Stefano,
On 17/12/2019 18:28, Stefano Stabellini wrote:
Then I tried to passthrough the eMMC, but I got the following
error:
(XEN) DOM1: [ 0.879151] sdhci-esdhc-imx 4005d000.usdhc: can't request region
for resource [mem 0x4005d000-0x4005dfff]
(XEN) DOM1: [ 0.891137] sdhci-esdhc-imx 4005d000.usdhc: sdhci_pltfm_init
failed -16
(XEN) DOM1: [ 0.900249] sdhci-esdhc-imx: probe of 4005d000.usdhc failed with
error -16
Where 0x4005d000 is the physical address of the uSDHC(eMMC) node in the DT.
It seems that the DomU1 kernel does not have access to that memory zone.
It looks like drivers/mmc/host/sdhci-pltfm.c:sdhci_pltfm_init failed,
but I cannot see a simple reason why it would. As Julien mentioned the
device tree snippet would be useful. Also the domU config and the full
device tree would be useful. i.e. did you add "xen,passthrough;" under
the related uSDHC node on the host device tree?
The only purpose of "xen,passthrough" is to mark the device as disabled
in Dom0 DT. It will not affect how device will be passthrough to a guest.
In this case, I don't believe the problem is DT related because Linux is
able to find the regions. If the region were not mapped to the guest,
then it would be likely result to a data abort later on.
Looking at Andrei's e-mail again, he doesn't mention anything about the
1:1 mapping. So I assume, he is still using the guest memory layout. The
physical address 0x4005d000 which is roughly 372KB into the first RAM
bank for the guest.
I'm trying to passthrough the eMMC in order to mount DomU1's root
on a SDCard partition, because I couldn't get to DomU1's Linux prompt
when I tried to boot with a ramdisk module. I always get this error:
(XEN) DOM1: [ 1.544199] RAMDISK: Couldn't find valid RAM disk image starting
at 0.
Could this be because the ramdisk is too big? The smallest I've tried with
Is approximately 60MB in size. What size are the ramdisks that you
are using in your dom0less booting demos?
I don't think so, I could boot with ramdisk 120MB in size or even
larger. It is probably an address calculation error: it is easy to make
a small mistake in the addresses so that they end up overlapping.
Sometimes it is even U-Boot that causes the overlaps.
I would suggest to use ImageBuilder to create the U-Boot boot script to
load all the binaries and boot the system. Have a look at
uboot-script-gen in particular:
https://gitlab.com/ViryaOS/imagebuilder/blob/master/scripts/uboot-script-gen
Nice script, but it seems to contain hardcoded value (see offset and
memaddr override), does not take into account reserved region and assume
where U-boot/ATF may be loaded. So it may require some work before it
can be used on NXP board...
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
