On Wed, Jun 30, 2021 at 8:12 PM Robert Reid <[email protected]> wrote: > > Hi everyone > > Summary - trying to get util_libs/libplatsupport going for a HardKernel > ODROID-C4, using the camkes serialserver_polling app - but not having any > luck with mapping the UART. I'd welcome any explanations of what you think > is happening here. The background and my progress follows. > > I thought I'd dive into the seL4 world and do some experimenting. I > thought a good place to start would be the UNSW AOS project (17 years after > I first did it) - but with no more ODROID-C2, got a hold of an ODROID-C4 > and figured that would be a good project in itself (and well timed with a > Sydney lockdown). > > So - good news: The peripheral devices we need are all very similar to a > C2, so by getting a new DTS file and updating a few addresses it starts off > fairly happily. sel4-test builds and runs (All is well...); so does the > camkes adder app; and with some mods to provide enough slots (maybe because > it has 4GB rather than 2GB) I have got the AOS milestone 0 stub to run > (including the uart initialisation). (More work to actually finish m0 and > keep going, but a job for later) > > But then: I moved onto the util_libs / libplatsupport project to try and > port over as much of the device settings as possible; and using the camkes > app serialserver_polling, under the hood using SerialServer, I can't get > the uart to initialiise (or more strictly can't get the uart address to > map). chardev_map / ps_io_map fails, returning a vaddr of 0. > > I've added a bunch of debug prints to the process; and for comparison also > run it on QEMU emulating a Sabre board. > > On odroidc4 hardware: > ## Starting application at 0x01080000 ... > > ELF-loader started on CPU: ARM Ltd. Cortex-A55 r1p0 > paddr=[95e000..d5710f] > No DTB passed in from boot loader. > Looking for DTB in CPIO archive...found at a86de8. > Loaded DTB from a86de8. > paddr=[23f000..24afff] > ELF-loading image 'kernel' to 0 > paddr=[0..23efff] > vaddr=[ffffff8000000000..ffffff800023efff] > virt_entry=ffffff8000000000 > ELF-loading image 'capdl-loader' to 24b000 > paddr=[24b000..563fff] > vaddr=[400000..718fff] > virt_entry=408e48 > Enabling MMU and paging > Jumping to kernel-image entry point... > > Bootstrapping kernel > Booting all finished, dropped to user space > [email protected]:501 About to init port, io_ops=0x487cf0 > [email protected]:46 About to init_fn 3 > [email protected]:47 dev_defn[3].paddr: 0xff803000, size 1000 > [email protected]:51 about to chardev_map: dev=0x473948, defn->id=3, > defn->padd > r=0xff803000 > [email protected]:26 ops->io_mapper=0x487be0 &(ops->io_mapper)=0x442728 > dev- > >paddr=0xff803000 dev->size=0x1000 > [email protected]:56 chardev_map mapped page_vaddr 0 > [email protected]:64 Failed to initialise character device > [email protected]:65 PS_SERIAL_DEFAULT: 3 >
It could be that the capability to the mmio frame isn't being given to the serialserver camkes component. The serialserver component's CAmkES definition picks the serial device referred to by the stdout-path property of the chosen node in the platform device tree. In the build directory there will be a generated file "serialserver_polling.cdl". This file contains all of the capabilities that will be created during system initialization. If you search this file for the physical address of the MMIO you are trying to have mapped you can check whether it is being given to the SerialServer component. If it has been declared correctly in this generated file, then the chardev_init in libplatsupport should be able to correctly request and map it in. libplatsupport currently uses a platform specific header file to pick which serial device it initializes by default, so if the definition of PS_SERIAL_DEFAULT doesn't refer to the same device as the stdout-path property in the device tree the driver could be trying to initialize a different serial device than the one camkes allocated resources for. > On Sabre QEMU: > ./simulate: qemu-system-arm -machine sabrelite -nographic -serial null > -serial mon:stdio -m size=1024M -kernel images/capdl-loader-image- > arm-imx6 > ELF-loader started on CPU: ARM Ltd. Cortex-A9 r0p0 > paddr=[106fc000..10aa98e3] > No DTB passed in from boot loader. > Looking for DTB in CPIO archive...found at 107fe33c. > Loaded DTB from 107fe33c. > paddr=[1003d000..10047fff] > ELF-loading image 'kernel' to 10000000 > paddr=[10000000..1003cfff] > vaddr=[e0000000..e003cfff] > virt_entry=e0000000 > ELF-loading image 'capdl-loader' to 10048000 > paddr=[10048000..10300fff] > vaddr=[10000..2c8fff] > virt_entry=187f8 > Enabling MMU and paging > Jumping to kernel-image entry point... > > Bootstrapping kernel > Warning: Could not infer GIC interrupt target ID, assuming 0. > Booting all finished, dropped to user space > [email protected]:501 About to init port, io_ops=0x69cf0 > [email protected]:45 About to init_fn 1 > [email protected]:46 dev_defn[1].paddr: 0x21e8000, size 1000 > [email protected]:224 about to chardev_map: dev=0x7f8c8, defn->id=1, > defn->paddr=0x21e8000 > [email protected]:26 ops->io_mapper=0x69cf0 &(ops->io_mapper)=0x1f328 > dev->paddr=0x1f654 dev->size=0x4ebc4 > [email protected]:226 chardev_map mapped vaddr 0xbb000 > pollcli: Hello Serial Server! > pollcli: abc > > This has me confused - it's good it works, but I can't follow in the flow > how the paddr gets changed from the value supplied to chardev_map (ie > 0x21e80000 becomes 0x1f654), yet in that case it works. Or is it a > complication of using QEMU? > > A similar kind of test with AOS on odroidc4 - particularly the success > of "*[email protected]:35 > Mapped uart paddr:ff803000 size:1000 vaddr:b0000000*" > ## Starting application at 0x01080000 ... > > ELF-loader started on CPU: ARM Ltd. Cortex-A55 r1p0 > paddr=[88a000..c2b10f] > No DTB passed in from boot loader. > Looking for DTB in CPIO archive...found at 9f3068. > Loaded DTB from 9f3068. > paddr=[247000..252fff] > ELF-loading image 'kernel' to 0 > paddr=[0..246fff] > vaddr=[ffffff8000000000..ffffff8000246fff] > virt_entry=ffffff8000000000 > ELF-loading image 'sos' to 253000 > paddr=[253000..48cfff] > vaddr=[400000..639fff] > virt_entry=4172e0 > Enabling MMU and paging > Jumping to kernel-image entry point... > > Bootstrapping kernel > Booting all finished, dropped to user space > > SOS Starting... > <<seL4(CPU 0) [handleInterruptEntry/52 T0xffffff803fff8400 "SOS:root" > @400630]: > Spurious interrupt!>> > <<seL4(CPU 0) [handleInterruptEntry/52 T0xffffff803fff8400 "SOS:root" > @400630]: > Spurious interrupt!>> > <<seL4(CPU 0) [handleInterruptEntry/52 T0xffffff803fff8400 "SOS:root" > @400630]: > Spurious interrupt!>> > <<seL4(CPU 0) [handleInterruptEntry/52 T0xffffff803fff8400 "SOS:root" > @400630]: > Spurious interrupt!>> > <<seL4(CPU 0) [handleInterruptEntry/52 T0xffffff803fff8400 "SOS:root" > @400630]: > Spurious interrupt!>> > <<seL4(CPU 0) [handleInterruptEntry/52 T0xffffff803fff8400 "SOS:root" > @400630]: > Spurious interrupt!>> > <<seL4(CPU 0) [handleInterruptEntry/52 T0xffffff803fff8400 "SOS:root" > @400630]: > Spurious interrupt!>> > [email protected]:35 Mapped uart paddr:ff803000 size:1000 vaddr:b0000000 > SOS Started! > [email protected]:59 Test cspace > [email protected]:174 Root CSpace test passed! > [email protected]:59 Test cspace > [email protected]:182 Single level cspace test passed! > [email protected]:59 Test cspace > [email protected]:335 Cspace is full! > > [email protected]:195 Double level cspace test passed! > [email protected]:199 DMA test passed! > [email protected]:203 Frame table test passed! > Network init > dwmac.b0002000 Waiting for PHY auto negotiation to complete........ done > Speed: 1000, full duplex > Protocol ethernet registered (layer: 2). > Protocol ipv4 registered (layer: 3). > Protocol ipv6 registered (layer: 3). > Protocol icmp4 registered (layer: 4). > Protocol icmp6 registered (layer: 4). > Protocol igmp registered (layer: 4). > Protocol udp registered (layer: 4). > Protocol tcp registered (layer: 4). > Assigned ipv4 0.0.0.0 to device sos picotcp > DHCP client: update link > Assigned ipv4 192.168.200.125 to device sos picotcp > DHCP client: renewal time (T1) 43200 > DHCP client: rebinding time (T2) 75600 > DHCP client: lease time 86400 > DHCP client: netmask 255.255.255.0 > DHCP client: gateway 192.168.200.4 > Timer init > Start first process > Starting ttytest at 0x4001c8 > > SOS entering syscall loop > aos: Error attempting syscall 29 > task: Hello world, I'm tty_test! > [email protected]:128 Unknown syscall 1 > > <<seL4(CPU 0) [receiveIPC/148 T0xffffff803fff8400 "SOS:root" @407a48]: > Reply obj > ect already has unexecuted reply!>> > > In this case it has worked, sos_map_device works as expected (although the > spurious interrupts are another task to figure out). But trying to > understand what's really going on underneath ps_io_map and ultimately why > libplatsupport won't work for me has got me confused. Any ideas would be > appreciated. > > Regards > Rob > _______________________________________________ > Devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
