Is there a "modern" seL4 manifest/configuration that is known to run on CMA34CR?
Unless I am looking in the wrong place, all the CMA34CR support was removed in https://github.com/seL4/camkes-vm/commit/aab3478acc4705a3161f5bf59625f7c96a8.... Is there something that remains? If not, what would be the best starting point to try to port a demo running on CMA34CR board from an old (early 2017) version of the sel4/camkes/etc to a recent stable release (e.g, 10.1.1)? Thanks. Aleksey CONFIDENTIALITY NOTICE: The information transmitted in this email, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential, proprietary and/or privileged material exempt from disclosure under applicable law. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this message in error, please contact the sender immediately and destroy any copies of this information in their entirety.
They were moved to camkes-vm-examples (https://github.com/sel4/camkes-vm-exampleshttps://github.com/sel4/camkes-vm-examples). You can checkout and build with the following:
repo init -u https://github.com/sel4/camkes-vm-examples-manifest
repo sync
mkdir build
cd build
../init-build.sh -DCAMKES_VM_APP=cma34cr_centos
ninja
________________________________
From: Devel
With a recent version of everything, I get the following on startup of the "CAMKES_VM_APP=cma34cr_centos"(*) build
...
Booting all finished, dropped to user space
IOMMU: DMA read page fault from 0xd0 (bus: 0x0/dev: 0x1a/fun: 0x0) on address 0x0:aae16000 with reason code 0x6
acpi_init@acpi.c:386 Failed to find rsdp
hpet_parse_acpi@hpet.c:274 arguments cannot be NULL
sel4platsupport_get_num_pmem_regions@pmem.c:23 Could not find info
...
Does this indicate problems that I should worry about? The reason for my question is that in porting some simple code (without any VMs) that worked fine on the 32-bit seL4 from ~2 years ago to a more recent version of everything, I get the following on startup:
Booting all finished, dropped to user space
IOMMU: DMA read page fault from 0xd0 (bus: 0x0/dev: 0x1a/fun: 0x0) on address 0x0:aae16000 with reason code 0x6
acpi_init@acpi.c:386 Failed to find rsdp
hpet_parse_acpi@hpet.c:274 arguments cannot be NULL
FAULT HANDLER: user exception (number 13, code 0) from time_server.time_server_0_control (ID 0x2), pc = 0x423a47, sp = 0x453cf0, flags = 0x10202
followed by some of my components failing to initialize correctly because of lwip's udp_new returning NULL, and something else also spewing two copies of "sel4platsupport_get_num_pmem_regions@pmem.c:23 Could not find info" message...
I will try to figure this out myself, but would appreciate any pointers. Thanks!
(*) I am running on a CMA34CR + CAN board, so some of the HW parameters might be slightly different from the version of the HW we all used in the previous projects. I've updated HW parameters in the cma34cr_centos.camkes accordingly, but may have missed something.
Aleksey
From: Mcleod, Kent (Data61, Kensington NSW)
The CAMKES_VM_APP=cma34cr_centos configuration still works in the mainline repositories. I went through and altered some of the error messaging to only warn in situations where the errors are expected. For other outputs: IOMMU: DMA read page fault from 0xd0 (bus: 0x0/dev: 0x1a/fun: 0x0) on address 0x0:aae16000 with reason code 0x6 This occurs sometimes when devices try to access memory but don't have access via the IOMMU. They are spurious and the kernel prints the faults for diagnostic reasons, but don't indicate any errors unless a driver is trying to communicate with the device at the same time. acpi_init@acpi.c:386 Failed to find rsdp hpet_parse_acpi@hpet.c:274 arguments cannot be NULL sel4platsupport_get_num_pmem_regions@pmem.c:23 Could not find info The acpi, hpet and pmem errors are all paths where the caller is able to handle failures so I downgraded these messages to warnings for now. FAULT HANDLER: user exception (number 13, code 0) from time_server.time_server_0_control (ID 0x2), pc = 0x423a47, sp = 0x453cf0, flags = 0x10202 This is a legitimate error, which you tracked down to be the lexicographical ordering bug.
"because of lwip’s udp_new returning NULL" I'm not sure what you mean by this but it could have been caused by cascading failures from the time server?
________________________________
From: Nogin, Aleksey
Kent,
Thanks a lot - so far, everything I tested with the latest versions worked correctly, and your startup delay improvements are very much appreciated.
Aleksey
From: Mcleod, Kent (Data61, Kensington NSW)
"because of lwip's udp_new returning NULL" I'm not sure what you mean by this but it could have been caused by cascading failures from the time server?
________________________________
From: Nogin, Aleksey
participants (2)
-
Mcleod, Kent (Data61, Kensington NSW) -
Nogin, Aleksey