AW: Running Linux 3.14 as a Genode VM
nico at ...286...
Thu Jan 15 13:03:53 CET 2015
Thanks for your response.
I can boot the Linux kernel with my device tree without Genode on the hardware and it boots fine.
I tried setting the lpj on the commandline, but it seems that gets ignored. If I set them at the start of calibrating_delay() the output switches to "Calibrating delay loop (skipped), preset value.." but it hangs. I think you are right with the "missing" interrupt but how can I prevent Linux from using the same timer as Genode?
I think it gets initialized in linux/arch/arm/mach-imx/time.c in mxc_clocksource_init() but if I comment that out it doesn't work either. I also know that the clocks are initialized by linux in linux/arch/arm/mach-imx/clk-imx51-imx53.c in mx5_clocks_common_init() and mx53_clocks_init(). But those look nothing like https://github.com/skalk/linux/blob/270ba1e8fb95e8b16e423e6a1bbbc9291276e35e/arch/arm/mach-mx5/clock.c#L4774 probably because of the device tree. This is my first time doing kernel hacking, so I don't really know what everything is doing yet (and my whole approach is trial-and-error)
I will try to provide you with the repositories.
Von: Stefan Kalkowski
Gesendet: Mittwoch, 14. Januar 2015 17:51
An: Genode OS Framework Mailing List
Betreff: Re: Running Linux 3.14 as a Genode VM
On 01/14/2015 04:16 PM, Nico Weichbrodt wrote:
> I'm a student at TU Braunschweig and I inherited a Genode project from another student.
> He used Genode on an i.MX53 Quick Start Board to boot a Linux 2.6.35 kernel (this one: https://github.com/skalk/linux) as a VM with TrustZone support. This works fine.
> For my task I need a newer kernel, so I'm currently trying to upgrade to kernel 3.14. Since this kernel requires dtbs I modified Genode to load the dtb instead of ATAGs. I had to modify my dtb so the memory layout matches and to set the bootargs. My kernel now boots but hangs very soon at this point:
> Uncompressing Linux... done, booting the kernel.
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Initializing cgroup subsys cpu
> [ 0.000000] Initializing cgroup subsys cpuacct
> [ 0.000000] Linux version 3.14.15-00329-gaed2dee-dirty (envy at ...287...) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-41) ) #40 Wed Jan 14 16:06:19 CET 2015
> [ 0.000000] CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] Machine model: Freescale i.MX53 Quick Start-R Board
> [ 0.000000] bootconsole [earlycon0] enabled
> [ 0.000000] Memory policy: Data cache writeback
> [ 0.000000] On node 0 totalpages: 131072
> [ 0.000000] free_area_init_node: node 0, pgdat c05b36e8, node_mem_map dfbf9000
> [ 0.000000] Normal zone: 1024 pages used for memmap
> [ 0.000000] Normal zone: 0 pages reserved
> [ 0.000000] Normal zone: 131072 pages, LIFO batch:31
> [ 0.000000] CPU: All CPU(s) started in SVC mode.
> [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [ 0.000000] pcpu-alloc:  0
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048
> [ 0.000000] Kernel command line: console=ttymxc0,115200 earlyprintk loglevel=10
> [ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> [ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> [ 0.000000] Memory: 513696K/524288K available (4039K kernel code, 219K rwdata, 1384K rodata, 198K init, 123K bss, 10592K reserved, 0K highmem)
> [ 0.000000] Virtual kernel memory layout:
> [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
> [ 0.000000] vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
> [ 0.000000] lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
> [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
> [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
> [ 0.000000] .text : 0xc0008000 - 0xc0553f8c (5424 kB)
> [ 0.000000] .init : 0xc0554000 - 0xc0585bbc ( 199 kB)
> [ 0.000000] .data : 0xc0586000 - 0xc05bcda0 ( 220 kB)
> [ 0.000000] .bss : 0xc05bcda0 - 0xc05dba2c ( 124 kB)
> [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> [ 0.000000] NR_IRQS:16 nr_irqs:16 16
> [ 0.000000] TrustZone Interrupt Controller (TZIC) initialized
> [ 0.000000] CPU identified as i.MX53, silicon rev 2.1
> [ 0.000000] Switching to timer-based delay loop
> [ 0.000009] sched_clock: 32 bits at 33MHz, resolution 29ns, wraps every 128849015778ns
> [ 0.008364] Console: colour dummy device 80x30
> [ 0.012925] Calibrating delay loop (skipped), value calculated using timer frequency..
> If I add some debug statements to linux/init/calibrate.c before the pr_info("Calibrating delay loop (skipped) ..."); then those get printed as well, but the "Calibrating..." text is not. I also added a loop at the top of the calibrate_delay() function which just prints an incrementing counter but this loop only prints once and then hangs.
> Now I have two assumptions: Either the serial driver is hanging or it has something to do with the clocks/timer because the highest time passed number I got was 0.016800-ish.
Well it might be that your Linux kernel's version uses the same timer
like Genode's "hw kernel" is using for scheduling purposes. If so, the
interrupt is probably set as being secure, and timer interrupts are
always delivered to the secure Genode side.
Another possiblity when using the vanilla Linux sources: there were
known bugs at least in the past according to this thread:
Did you tested your kernel and device tree on the hardware without
A possible workaround is to set the lpj (loops per jiffies) value on the
command line instead of calculating it dynamically. When running Linux
in a virtualized fashion this might be adviseable anyway, because when
world switches take place during the calibrating loop, you might get
> I have not yet replayed the TrustZone commits from Stefan Kalkowski for Linux 2.6.35 but because I set all devices as unsecure inside Genode (genode/repos/base-hw/src/core/include/spec/imx53/trustzone/csu.h) this should not be necessary, right?
Well, as already addressed: you'll run into trouble as soon as the guest
OS (Linux) touches hardware already used by the kernel, like the timer.
Another problem arises when it re-initializes all clocks and power
domains. This works like a device reset (e.g. for the timer) and
probably leads to a non-working secure side's kernel.
If that doesn't help you further, you might provide your Genode and
Linux branch you are working with, as well as detailed instructions how
to reproduce your scenario from that.
> If you have any pointers/ideas/suggestions for me, this would be very helpful.
> Nico Weichbrodt
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> genode-main mailing list
> genode-main at lists.sourceforge.net
http://www.genode-labs.com/ · http://genode.org/
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
genode-main mailing list
genode-main at lists.sourceforge.net
More information about the users