It looks like the libplatsupport drivers do this enabling as well. Though it appears there's a typo in the transmit enable: https://github.com/seL4/util_libs/blob/master/libplatsupport/src/plat/zynq70... I've created a pull request to fix that as well. https://github.com/seL4/util_libs/pull/5 -Andrew On Tue, Dec 6, 2016 at 6:46 PM, Andrew Gacek <andrew.gacek@gmail.com> wrote:
Ok thanks. I've created a pull request for this change:
https://github.com/seL4/seL4_tools/pull/2
-Andrew
On Tue, Dec 6, 2016 at 5:58 PM, <Alexander.Kroh@data61.csiro.au> wrote:
Hi Andrew,
Nice find! U-boot obviously performs some initialisation of the UART on our behalf, hence we have not had problems when testing on real hardware.
The correct place would be here: https://github.com/seL4/seL4_tools/blob/2.0.x-compatible/elfloader-tool/src/...
But, it should call out to a dedicated init function in sys_fputc.c
The call to platform_init() would also need to occur a few lines earlier, before the first printf: https://github.com/seL4/seL4_tools/blob/2.0.x-compatible/elfloader-tool/src/...
- Alex
On Tue, 2016-12-06 at 16:35 -0600, Andrew Gacek wrote:
I've found the problem. First, the default UART for zynq7000 is the second one, so I need to run qemu like this:
qemu-system-arm -M xilinx-zynq-a9 -kernel images/capdl-loader-experimental-image-arm-zynq7000 -m size=512M -monitor none -nographic -serial /dev/null -serial stdio
Second, the Zynq7000 uart needs to be explicitly enabled. This is done by clearing bit 5 and setting bit 4 of the control register. It looks like seL4 and related tools are not doing this. For now I've done this by modifying
tools/elfloader/src/arch-arm/plat-zynq7000/sys_fputc.c
to add
uint32_t v = *UART_REG(UART_CONTROL); v |= (1 << 4); v &= ~(1 << 5); *UART_REG(UART_CONTROL) = v;
to the __fputc function.
This clearly isn't the right spot for it. Where should such initial configuration be done?
-Andrew
On Tue, Dec 6, 2016 at 3:33 PM, Andrew Gacek <andrew.gacek@gmail.com> wrote:
If I suspend the execution in QEMU, the program counter is at 0xe00108ec. In the kernel, that is the <idle_thread> method. So perhaps the system is running, but I'm just not able to see any output from the elfloader, kernel, etc.
-Andrew
On Tue, Dec 6, 2016 at 2:49 PM, Andrew Gacek <andrew.gacek@gmail.com> wrote:
Thanks Alex. That fixes the crash. Now the system runs but just seems to hang without doing anything. I don't get any output at all (whereas the kzm version spews out a ton of messages). In 'top' I can see it's using about 3% cpu so it's something, though it's not clear what. It's hard for me to tell. Perhaps the UART for the console isn't working correctly?
-Andrew
On Tue, Dec 6, 2016 at 2:46 PM, <Alexander.Kroh@data61.csiro.au> wrote:
Hi Andrew,
It could be because QEMU does not know how much RAM is available. Could you try adding "-m size=512M" to your arguments?
- Alex
________________________________________ From: Devel <devel-bounces@sel4.systems> on behalf of Andrew Gacek <andrew.gacek@gmail.com> Sent: Wednesday, December 7, 2016 2:23 AM To: devel@sel4.systems Subject: [seL4] seL4 on Zinq7000 on QEMU
I'm trying to build and emulate a version of seL4 for the zinq7000 platform, but it crashes immediately.
I've started by taking the camkes tutorial and building it for zinq7000:
repo init -u https://github.com/seL4/camkes-manifest.git repo sync make arm_simple_defconfig make menuconfig # change seL4 platform to zinq7000 make
When I try to emulate it, it crashes right away:
qemu-system-arm -M xilinx-zynq-a9 -nographic -kernel images/capdl-loader-experimental-image-arm-zynq7000
qemu: fatal: Trying to execute code outside RAM or ROM at 0x10000000
R00=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=00000000 R14=00000000 R15=10000000 PSR=400001d3 -Z-- A svc32 s00=00000000 s01=00000000 d00=0000000000000000 s02=00000000 s03=00000000 d01=0000000000000000 s04=00000000 s05=00000000 d02=0000000000000000 s06=00000000 s07=00000000 d03=0000000000000000 s08=00000000 s09=00000000 d04=0000000000000000 s10=00000000 s11=00000000 d05=0000000000000000 s12=00000000 s13=00000000 d06=0000000000000000 s14=00000000 s15=00000000 d07=0000000000000000 s16=00000000 s17=00000000 d08=0000000000000000 s18=00000000 s19=00000000 d09=0000000000000000 s20=00000000 s21=00000000 d10=0000000000000000 s22=00000000 s23=00000000 d11=0000000000000000 s24=00000000 s25=00000000 d12=0000000000000000 s26=00000000 s27=00000000 d13=0000000000000000 s28=00000000 s29=00000000 d14=0000000000000000 s30=00000000 s31=00000000 d15=0000000000000000 s32=00000000 s33=00000000 d16=0000000000000000 s34=00000000 s35=00000000 d17=0000000000000000 s36=00000000 s37=00000000 d18=0000000000000000 s38=00000000 s39=00000000 d19=0000000000000000 s40=00000000 s41=00000000 d20=0000000000000000 s42=00000000 s43=00000000 d21=0000000000000000 s44=00000000 s45=00000000 d22=0000000000000000 s46=00000000 s47=00000000 d23=0000000000000000 s48=00000000 s49=00000000 d24=0000000000000000 s50=00000000 s51=00000000 d25=0000000000000000 s52=00000000 s53=00000000 d26=0000000000000000 s54=00000000 s55=00000000 d27=0000000000000000 s56=00000000 s57=00000000 d28=0000000000000000 s58=00000000 s59=00000000 d29=0000000000000000 s60=00000000 s61=00000000 d30=0000000000000000 s62=00000000 s63=00000000 d31=0000000000000000 FPSCR: 00000000 Aborted
Is there something I'm doing wrong?
Thanks, Andrew
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel