[Xenomai] Raspberry Pi 2 patch - BCM2709

[Xenomai] Raspberry Pi 2 patch - BCM2709

[Mathieu]

Some status on RPI2: kernel is now booting with CONFIG_IPIPE (only) (at 
least passing the interrupt issue).

The part I was missing is the interrupt binding in 
arch_irq_handler_default().

I also used the system timer instead of the arm timer.
I am not sure the reason but I have the feeling it is because ipipe 
needs a oneshot timer.

I also got the rpi2 connected to a jtag and debugging using eclipse but 
it did not help much for this particular issue (and it is rather slow 
and not really stable).

There is a (major) issue: the mmc can not get the clock.
[    4.108224] mmc-bcm2835 3f300000.mmc: could not get clk

I am guessing this is due to the switch from ARM timer to system timer.
I will have to fix this eventually (any suggestion welcome).

The next step is to enable CONFIG_XENOMAI.

Thanks,
-- 
Mathieu

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Gilles Chanteperdrix]

On Tue, Aug 04, 2015 at 06:30:57AM -0700, Mathieu wrote:
> Some status on RPI2: kernel is now booting with CONFIG_IPIPE (only) (at
> least passing the interrupt issue).
> 
> The part I was missing is the interrupt binding in
> arch_irq_handler_default().
> 
> I also used the system timer instead of the arm timer.

The arm architected timer is used on cortex A15 Processors. So, it
can definitely work.

> I am not sure the reason but I have the feeling it is because ipipe needs a
> oneshot timer.

I-pipe does not need a timer. Xenomai does. The ARM architected
timer is a oneshot timer, so can be used by Xenomai (and once again,
is used on cortex A15). And a periodic timer is not an issue either,
provided that you reprogram it at every shot.

For details about timers and clocks, once again, see the porting guide.

> 
> I also got the rpi2 connected to a jtag and debugging using eclipse but it
> did not help much for this particular issue (and it is rather slow and not
> really stable).

Yes, in theory JTAG is great, in practice, debug tools are always
buggy. Note however that you may have better chances using gdb
directly than using eclipse.

> 
> There is a (major) issue: the mmc can not get the clock.
> [    4.108224] mmc-bcm2835 3f300000.mmc: could not get clk
> 
> I am guessing this is due to the switch from ARM timer to system timer.
> I will have to fix this eventually (any suggestion welcome).

Probable wrong guess. The clock referred to here is a hardware clock
(in the sense, an electronic wire which gives a periodic signal),
and has nothing to do with the system timer.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Mathieu Rondonneau]

On 15-08-04 06:48 AM, Gilles Chanteperdrix wrote:
> On Tue, Aug 04, 2015 at 06:30:57AM -0700, Mathieu wrote:
>> Some status on RPI2: kernel is now booting with CONFIG_IPIPE (only) (at
>> least passing the interrupt issue).
>>
>> The part I was missing is the interrupt binding in
>> arch_irq_handler_default().
>>
>> I also used the system timer instead of the arm timer.
>
> The arm architected timer is used on cortex A15 Processors. So, it
> can definitely work.
>
>> I am not sure the reason but I have the feeling it is because ipipe needs a
>> oneshot timer.
>
> I-pipe does not need a timer. Xenomai does. The ARM architected
> timer is a oneshot timer, so can be used by Xenomai (and once again,
> is used on cortex A15). And a periodic timer is not an issue either,
> provided that you reprogram it at every shot.
>
> For details about timers and clocks, once again, see the porting guide.
>
>>
>> I also got the rpi2 connected to a jtag and debugging using eclipse but it
>> did not help much for this particular issue (and it is rather slow and not
>> really stable).
>
> Yes, in theory JTAG is great, in practice, debug tools are always
> buggy. Note however that you may have better chances using gdb
> directly than using eclipse.
>
>>
>> There is a (major) issue: the mmc can not get the clock.
>> [    4.108224] mmc-bcm2835 3f300000.mmc: could not get clk
>>
>> I am guessing this is due to the switch from ARM timer to system timer.
>> I will have to fix this eventually (any suggestion welcome).
>
> Probable wrong guess. The clock referred to here is a hardware clock
> (in the sense, an electronic wire which gives a periodic signal),
> and has nothing to do with the system timer.
>

Hi Gilles,
Sorry for the delay, I just wanted to thank you for taking the time to 
reply and give feedback.

I will look more into it once I get more time.

--
Mathieu

Re: [Xenomai] Raspberry Pi 2 - ipipe patch - BCM2709

[Mathieu Rondonneau]

On 15-08-25 08:07 PM, Mathieu Rondonneau wrote:
> Some progress using the ARM timer since I made some progress lately.
>
> it is stuck waiting for the response (mailbox) from the videocore
> regarding power settings request (always ON).
>
> I have to find out if the interrupt has triggered or not (maybe masked
> by ipipe?).
>
> Looks like there is still some work to do on the interrupt binding level.
>
> on the bright side, if I comment out the power settings (that triggers
> the read to the mailbox) then it gets really close to the prompt!
>
> -Mathieu
>
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0xf00
> [    0.000000] Initializing cgroup subsys cpuset
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Initializing cgroup subsys cpuacct
> [    0.000000] Linux version 3.18.16-v7+ (mathieu@mathieu-X58A-UD3R)
> (gcc version 4.9.3 20150113 (prerelease) (Linaro GCC 4.9-2015.01-3) )
> #125 SMP PREEMPT Mon Aug 24 20:03:52 PDT 2015
> [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
> cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] Machine model: Raspberry Pi 2 Model B
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] debug: ignoring loglevel setting.
> [    0.000000] cma: Reserved 8 MiB at 0x3a800000
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] On node 0 totalpages: 241664
> [    0.000000] free_area_init_node: node 0, pgdat 804da300, node_mem_map
> ba093000
> [    0.000000]   Normal zone: 1888 pages used for memmap
> [    0.000000]   Normal zone: 0 pages reserved
> [    0.000000]   Normal zone: 241664 pages, LIFO batch:31
> [    0.000000] [bcm2709_smp_init_cpus] enter (87c0->f3003010)
> [    0.000000] [bcm2709_smp_init_cpus] ncores=4
> [    0.000000] PERCPU: Embedded 12 pages/cpu @ba059000 s17664 r8192
> d23296 u49152
> [    0.000000] pcpu-alloc: s17664 r8192 d23296 u49152 alloc=12*4096
> [    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 239776
> [    0.000000] Kernel command line: dma.dmachans=0x7f35
> bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa21041
> bcm2709.serial=0x5c7e0cd1 smsc95xx.macaddr=B8:27:EB:7E:0C:D1
> bcm2708_fb.fbswap=1 bt
> [    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
> bytes)
> [    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
> bytes)
> [    0.000000] Memory: 944268K/966656K available (3361K kernel code,
> 267K rwdata, 1096K rodata, 212K init, 608K bss, 22388K reserved)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
> [    0.000000]     vmalloc : 0xbb800000 - 0xff000000   (1080 MB)
> [    0.000000]     lowmem  : 0x80000000 - 0xbb000000   ( 944 MB)
> [    0.000000]     modules : 0x7f000000 - 0x80000000   (  16 MB)
> [    0.000000]       .text : 0x80008000 - 0x804628bc   (4459 kB)
> [    0.000000]       .init : 0x80463000 - 0x80498000   ( 212 kB)
> [    0.000000]       .data : 0x80498000 - 0x804daf48   ( 268 kB)
> [    0.000000]        .bss : 0x804daf48 - 0x805732f4   ( 609 kB)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [    0.000000] Preemptible hierarchical RCU implementation.
> [    0.000000] NR_IRQS:608
> [    0.000000] Architected cp15 timer(s) running at 19.20MHz (virt).
> [    0.000000] I-pipe, 19.200 MHz clocksource, wrap in 960767920505705 ms
> [    0.000000] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps
> every 3579139424256ns
> [    0.000430] Switching to timer-based delay loop, resolution 52ns
> [    0.000783] Interrupt pipeline (release #3)
> [    0.001021] Console: colour dummy device 80x30
> [    0.001263] Calibrating delay loop (skipped), value calculated using
> timer frequency.. 38.40 BogoMIPS (lpj=192000)
> [    0.001817] pid_max: default: 32768 minimum: 301
> [    0.002076] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> [    0.002432] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
> bytes)
> [    0.002868] Initializing cgroup subsys memory
> [    0.003105] Initializing cgroup subsys devices
> [    0.003346] Initializing cgroup subsys freezer
> [    0.003587] Initializing cgroup subsys blkio
> [    0.003820] CPU: Testing write buffer coherency: ok
> [    0.004113] CPU0: update cpu_capacity 1024
> [    0.004336] CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
> [    0.004646] [bcm2709_smp_prepare_cpus] enter
> [    0.004881] Setting up static identity map for 0x336060 - 0x336094
> [    0.059345] [bcm2709_boot_secondary] cpu:1 started (0) 17
> [    0.059371] CPU1: Booted secondary processor
> [    0.059371] [bcm2709_secondary_init] enter cpu:1
> [    0.059374] CPU1: update cpu_capacity 1024
> [    0.059375] CPU1: thread -1, cpu 1, socket 15, mpidr 80000f01
> [    0.079345] [bcm2709_boot_secondary] cpu:2 started (0) 18
> [    0.079367] CPU2: Booted secondary processor
> [    0.079367] [bcm2709_secondary_init] enter cpu:2
> [    0.079369] CPU2: update cpu_capacity 1024
> [    0.079369] CPU2: thread -1, cpu 2, socket 15, mpidr 80000f02
> [    0.099347] [bcm2709_boot_secondary] cpu:3 started (0) 18
> [    0.099360] CPU3: Booted secondary processor
> [    0.099360] [bcm2709_secondary_init] enter cpu:3
> [    0.099361] CPU3: update cpu_capacity 1024
> [    0.099362] CPU3: thread -1, cpu 3, socket 15, mpidr 80000f03
> [    0.100643] Brought up 4 CPUs
> [    0.100804] SMP: Total of 4 processors activated (153.60 BogoMIPS).
> [    0.101138] CPU: All CPU(s) started in SVC mode.
> [    0.101436] devtmpfs: initialized
> [    0.102819] VFP support v0.3: implementor 41 architecture 2 part 30
> variant 7 rev 5
> [    0.103285] pinctrl core: initialized pinctrl subsystem
> [    0.103976] DMA: preallocated 4096 KiB pool for atomic coherent
> allocations
> [    0.104401] bcm2709.uart_clock = 3000000
> [    0.104747] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4
> watchpoint registers.
> [    0.105174] hw-breakpoint: maximum watchpoint size is 8 bytes.
> [    0.105488] mailbox: Broadcom VideoCore Mailbox driver
> [    0.105768] bcm2708_vcio: mailbox at f300b880
> [    0.106018] bcm_power: Broadcom power driver
> [    0.106248] bcm_power_open() -> 0
> [    0.106427] bcm_power_request(0, 8)
>
>

[Xenomai] Raspberry Pi 2 patch - BCM2709

[Mathieu]

Mobin,
The timer part of your patch in bcm2709.c is under a #ifdef SYSTEM_TIMER 
and SYSTEM_TIMER is not defined (commented out at line 74) so it is 
useless and if you define it, you will see it will likely not compile 
because the structure name you used are not the same as the one in the 
parameters of register function (there are mix and match of bcm2709 and 
bcm2708).
Anyway this is not the problem because the ARM timer is used instead.

Others,
I get similar issue (described by Mobin) where it does not boot when 
CONFIG_IPIPE is enabled (I have added the earlyprintk output console 
below for information).
Like stated in the doc 
(http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/), 
pointed by Gilles, it does look like a GIC init issue.

My next step is to connect a JTAG to see where the cpu is locked and 
start from there. Sometimes, it encounters a bad pointers like it seems 
to do in this crash below.

In the mean time, I was wondering is anybody else succeed to get this 
working or has any pointers on anything obvious missing.

My patch is similar to the one mobin has. it is pretty much a copy/past 
from the old xenomai patch you can find from the mailing list + a 
tentative of porting to rpi2.

Thanks,
--
Mathieu

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0xf00
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.18.16-v7+ (mathieu@mathieu-X58A-UD3R) 
(gcc version 4.8.3 20140303 (prerelease) (crosstool-NG 
linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) ) #23 SMP PREE5
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), 
cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[    0.000000] Machine model: Raspberry Pi 2 Model B
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] cma: Reserved 8 MiB at 0x3a800000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 241664
[    0.000000] free_area_init_node: node 0, pgdat 80683f40, node_mem_map 
ba093000
[    0.000000]   Normal zone: 1888 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 241664 pages, LIFO batch:31
[    0.000000] [bcm2709_smp_init_cpus] enter (8820->f3003010)
[    0.000000] [bcm2709_smp_init_cpus] ncores=4
[    0.000000] PERCPU: Embedded 12 pages/cpu @ba058000 s18176 r8192 
d22784 u49152
[    0.000000] pcpu-alloc: s18176 r8192 d22784 u49152 alloc=12*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on. 
Total pages: 239776
[    0.000000] Kernel command line: dma.dmachans=0x7f35 
bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa21041 
bcm2709.serial=0x5c7e0cd1 smsc95xx.macaddr=B8:27:EB:7t
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 
bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 
bytes)
[    0.000000] Memory: 942520K/966656K available (4617K kernel code, 
315K rwdata, 1448K rodata, 260K init, 650K bss, 24136K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xbb800000 - 0xff000000   (1080 MB)
[    0.000000]     lowmem  : 0x80000000 - 0xbb000000   ( 944 MB)
[    0.000000]     modules : 0x7f000000 - 0x80000000   (  16 MB)
[    0.000000]       .text : 0x80008000 - 0x805f464c   (6066 kB)
[    0.000000]       .init : 0x805f5000 - 0x80636000   ( 260 kB)
[    0.000000]       .data : 0x80636000 - 0x80684e60   ( 316 kB)
[    0.000000]        .bss : 0x80684e60 - 0x8072774c   ( 651 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:608
[    0.000000] Architected cp15 timer(s) running at 19.20MHz (virt).
[    0.000000] I-pipe, 19.200 MHz clocksource, wrap in 960767920505705 ms
[    0.000010] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps 
every 3579139424256ns
[    0.008261] Switching to timer-based delay loop, resolution 52ns
[    0.015012] Interrupt pipeline (release #3)
[    0.020240] Unable to handle kernel paging request at virtual address 
55755134
[    0.027701] Unable to handle kernel paging request at virtual address 
55555575
[    0.035148] Unable to handle kernel paging request at virtual address 
55555575

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Miguel Rubio-Roy]

On 30 July 2015 at 05:37, Mathieu <mathieu_rondonneau@hotmail.com> wrote:

> In the mean time, I was wondering is anybody else succeed to get this
> working or has any pointers on anything obvious missing.
>

I was stuck at the same point. I've been able to go a bit further (but not
solve the original problem) by setting:
CONFIG_DEBUG_PAGEALLOC=y
CONFIG_DEBUG_MEMORY_INIT=y

Then I see:

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0xf00
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.18.12-v7+ (mrubioroy@llrmrr) (gcc version
4.7.1 20120402 (prere5
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] Machine: BCM2709
[    0.000000] debug: ignoring loglevel setting.
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: Reserved 8 MiB at 0x3a800000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] On node 0 totalpages: 241664
[    0.000000] free_area_init_node: node 0, pgdat 8074f1c0, node_mem_map
b9fa7000
[    0.000000]   Normal zone: 2124 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 241664 pages, LIFO batch:31
[    0.000000] mminit::memmap_init Initialising map node 0 zone 0 pfns 0 ->
241664
[    0.000000] [bcm2709_smp_init_cpus] enter (8b00->f3003010)
[    0.000000] [bcm2709_smp_init_cpus] ncores=4
[    0.000000] PERCPU: Embedded 13 pages/cpu @b9f6e000 s22400 r8192 d22656
u53248
[    0.000000] pcpu-alloc: s22400 r8192 d22656 u53248 alloc=13*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] mminit::zonelist general 0:Normal = 0:Normal
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 239540
[    0.000000] Kernel command line: dma.dmachans=0x7f35
bcm2708_fb.fbwidth=656 bcm2708_fb.fbhet
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes)
[    0.000000] Memory: 940468K/966656K available (5171K kernel code, 366K
rwdata, 1524K rodata)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xbb800000 - 0xff000000   (1080 MB)
[    0.000000]     lowmem  : 0x80000000 - 0xbb000000   ( 944 MB)
[    0.000000]     modules : 0x7f000000 - 0x80000000   (  16 MB)
[    0.000000]       .text : 0x80008000 - 0x80691e44   (6696 kB)
[    0.000000]       .init : 0x80692000 - 0x806fa000   ( 416 kB)
[    0.000000]       .data : 0x806fa000 - 0x80755bd4   ( 367 kB)
[    0.000000]        .bss : 0x80755bd4 - 0x80842180   ( 946 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Preemptible hierarchical RCU implementation.
[    0.000000] NR_IRQS:608
[    0.000000] Architected cp15 timer(s) running at 19.20MHz (virt).
[    0.000000] I-pipe, 19.200 MHz clocksource, wrap in 960767920505705 ms
[ 5875.515258] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every
3579139424256ns
[ 5875.515258] Switching to timer-based delay loop, resolution 52ns
[ 5875.515259] Interrupt pipeline (release #2)
[    0.000003] Console: colour dummy device 80x30
[ 5875.515261] Calibrating delay loop (skipped), value calculated using
timer frequency.. 38.4)
[ 5875.515259] pid_max: default: 32768 minimum: 301
[ 5875.515258] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000002] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
bytes)
[ 5875.515259] Initializing cgroup subsys memory
[ 5875.515259] Initializing cgroup subsys devices
[ 5875.515258] Initializing cgroup subsys freezer
[ 5875.515258] Initializing cgroup subsys net_cls
[ 5875.515259] Initializing cgroup subsys blkio
[ 5875.515258] CPU: Testing write buffer coherency: ok
[ 5875.515259] ftrace: allocating 17387 entries in 51 pages
[ 5875.515260] missing device node for CPU 0
[ 5875.515258] missing device node for CPU 1
[ 5875.515258] missing device node for CPU 2
[ 5875.515260] missing device node for CPU 3
[ 5875.515259] CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
[ 5875.515262] [bcm2709_smp_prepare_cpus] enter
[ 5875.515259] calling  trace_init_flags_sys_exit+0x0/0x28 @ 1
[ 5875.515261] initcall trace_init_flags_sys_exit+0x0/0x28 returned 0 after
0 usecs
[ 5875.515258] calling  trace_init_flags_sys_enter+0x0/0x28 @ 1
[ 5875.515260] initcall trace_init_flags_sys_enter+0x0/0x28 returned 0
after 0 usecs
[ 5875.515259] calling  init_static_idmap+0x0/0x12c @ 1
[ 5875.515261] Setting up static identity map for 0x4ab020 - 0x4ab054
[ 5875.515259] initcall init_static_idmap+0x0/0x12c returned 0 after 0 usecs
[ 5875.515261] calling  spawn_ksoftirqd+0x0/0x30 @ 1

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[张立鑫]

I also used the raspberry Pie 2, can share some experience?



2015-07-30 19:21 GMT+08:00 Miguel Rubio-Roy <mrubioroy@gmail.com>:

> On 30 July 2015 at 05:37, Mathieu <mathieu_rondonneau@hotmail.com> wrote:
>
> > In the mean time, I was wondering is anybody else succeed to get this
> > working or has any pointers on anything obvious missing.
> >
>
> I was stuck at the same point. I've been able to go a bit further (but not
> solve the original problem) by setting:
> CONFIG_DEBUG_PAGEALLOC=y
> CONFIG_DEBUG_MEMORY_INIT=y
>
> Then I see:
>
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0xf00
> [    0.000000] Initializing cgroup subsys cpu
> [    0.000000] Initializing cgroup subsys cpuacct
> [    0.000000] Linux version 3.18.12-v7+ (mrubioroy@llrmrr) (gcc version
> 4.7.1 20120402 (prere5
> [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7),
> cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] Machine: BCM2709
> [    0.000000] debug: ignoring loglevel setting.
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] cma: Reserved 8 MiB at 0x3a800000
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] On node 0 totalpages: 241664
> [    0.000000] free_area_init_node: node 0, pgdat 8074f1c0, node_mem_map
> b9fa7000
> [    0.000000]   Normal zone: 2124 pages used for memmap
> [    0.000000]   Normal zone: 0 pages reserved
> [    0.000000]   Normal zone: 241664 pages, LIFO batch:31
> [    0.000000] mminit::memmap_init Initialising map node 0 zone 0 pfns 0 ->
> 241664
> [    0.000000] [bcm2709_smp_init_cpus] enter (8b00->f3003010)
> [    0.000000] [bcm2709_smp_init_cpus] ncores=4
> [    0.000000] PERCPU: Embedded 13 pages/cpu @b9f6e000 s22400 r8192 d22656
> u53248
> [    0.000000] pcpu-alloc: s22400 r8192 d22656 u53248 alloc=13*4096
> [    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
> [    0.000000] mminit::zonelist general 0:Normal = 0:Normal
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 239540
> [    0.000000] Kernel command line: dma.dmachans=0x7f35
> bcm2708_fb.fbwidth=656 bcm2708_fb.fbhet
> [    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
> [    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
> bytes)
> [    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
> bytes)
> [    0.000000] Memory: 940468K/966656K available (5171K kernel code, 366K
> rwdata, 1524K rodata)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xffe00000   (2048 kB)
> [    0.000000]     vmalloc : 0xbb800000 - 0xff000000   (1080 MB)
> [    0.000000]     lowmem  : 0x80000000 - 0xbb000000   ( 944 MB)
> [    0.000000]     modules : 0x7f000000 - 0x80000000   (  16 MB)
> [    0.000000]       .text : 0x80008000 - 0x80691e44   (6696 kB)
> [    0.000000]       .init : 0x80692000 - 0x806fa000   ( 416 kB)
> [    0.000000]       .data : 0x806fa000 - 0x80755bd4   ( 367 kB)
> [    0.000000]        .bss : 0x80755bd4 - 0x80842180   ( 946 kB)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [    0.000000] Preemptible hierarchical RCU implementation.
> [    0.000000] NR_IRQS:608
> [    0.000000] Architected cp15 timer(s) running at 19.20MHz (virt).
> [    0.000000] I-pipe, 19.200 MHz clocksource, wrap in 960767920505705 ms
> [ 5875.515258] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every
> 3579139424256ns
> [ 5875.515258] Switching to timer-based delay loop, resolution 52ns
> [ 5875.515259] Interrupt pipeline (release #2)
> [    0.000003] Console: colour dummy device 80x30
> [ 5875.515261] Calibrating delay loop (skipped), value calculated using
> timer frequency.. 38.4)
> [ 5875.515259] pid_max: default: 32768 minimum: 301
> [ 5875.515258] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> [    0.000002] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
> bytes)
> [ 5875.515259] Initializing cgroup subsys memory
> [ 5875.515259] Initializing cgroup subsys devices
> [ 5875.515258] Initializing cgroup subsys freezer
> [ 5875.515258] Initializing cgroup subsys net_cls
> [ 5875.515259] Initializing cgroup subsys blkio
> [ 5875.515258] CPU: Testing write buffer coherency: ok
> [ 5875.515259] ftrace: allocating 17387 entries in 51 pages
> [ 5875.515260] missing device node for CPU 0
> [ 5875.515258] missing device node for CPU 1
> [ 5875.515258] missing device node for CPU 2
> [ 5875.515260] missing device node for CPU 3
> [ 5875.515259] CPU0: thread -1, cpu 0, socket 15, mpidr 80000f00
> [ 5875.515262] [bcm2709_smp_prepare_cpus] enter
> [ 5875.515259] calling  trace_init_flags_sys_exit+0x0/0x28 @ 1
> [ 5875.515261] initcall trace_init_flags_sys_exit+0x0/0x28 returned 0 after
> 0 usecs
> [ 5875.515258] calling  trace_init_flags_sys_enter+0x0/0x28 @ 1
> [ 5875.515260] initcall trace_init_flags_sys_enter+0x0/0x28 returned 0
> after 0 usecs
> [ 5875.515259] calling  init_static_idmap+0x0/0x12c @ 1
> [ 5875.515261] Setting up static identity map for 0x4ab020 - 0x4ab054
> [ 5875.515259] initcall init_static_idmap+0x0/0x12c returned 0 after 0
> usecs
> [ 5875.515261] calling  spawn_ksoftirqd+0x0/0x30 @ 1
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://xenomai.org/mailman/listinfo/xenomai
>

[Xenomai] Raspberry Pi 2 patch - BCM2709

[mobin Motallebizadeh]

HiCan anybody provide some information about making a patch for Raspberry Pi 2 ?The patches : xenomai-2.6.4/ksrc/arch/arm/patches/raspberryand the both `pre` and `post` patch need some changes to be applicable for rpi2 and 3.18 kernel.Specially in : https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bcm2709/bcm2708_gpio.c
Thanx in advance 		 	   		  

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Paul]

On Monday 08 June 2015, mobin Motallebizadeh wrote:
> HiCan anybody provide some information about making a patch for
> Raspberry Pi 2 ?The patches :
> xenomai-2.6.4/ksrc/arch/arm/patches/raspberryand the both `pre` and
> `post` patch need some changes to be applicable for rpi2 and 3.18
> kernel.Specially in :
> https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bc
>m2709/bcm2708_gpio.c Thanx in advance


There are two separate development paths for the Raspberry kernel.

1) The "official" Raspberry Pi Foundation (RPF) work which is found 
under mach-bcm2708 - This is what is targeted by the pre/post patches 
you refer to. 

2) The "official" Linux support is to be found in the mach-bcm2709 tree. 
This is still "work in progress", but looks to be at the stage where it 
is usable - I've not been following developments too closely, is it in 
the mainline kernel yet ?


If the RPF kernel runs on the RPi2 board, it wouldn't take much to 
update the pre/post patches to 3.18.

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[mobin Motallebizadeh]

> From: paul_c@tuxcnc.org
> To: xenomai@xenomai.org
> Date: Mon, 8 Jun 2015 12:11:15 +0100
> Subject: Re: [Xenomai] Raspberry Pi 2 patch - BCM2709
> 
> On Monday 08 June 2015, mobin Motallebizadeh wrote:
> > HiCan anybody provide some information about making a patch for
> > Raspberry Pi 2 ?The patches :
> > xenomai-2.6.4/ksrc/arch/arm/patches/raspberryand the both `pre` and
> > `post` patch need some changes to be applicable for rpi2 and 3.18
> > kernel.Specially in :
> > https://github.com/raspberrypi/linux/blob/rpi-3.18.y/arch/arm/mach-bc
> >m2709/bcm2708_gpio.c Thanx in advance
> 
> 
> There are two separate development paths for the Raspberry kernel.
> 
> 1) The "official" Raspberry Pi Foundation (RPF) work which is found 
> under mach-bcm2708 - This is what is targeted by the pre/post patches 
> you refer to. 
> 
> 2) The "official" Linux support is to be found in the mach-bcm2709 tree. 
> This is still "work in progress", but looks to be at the stage where it 
> is usable - I've not been following developments too closely, is it in 
> the mainline kernel yet ?
never heard of it! and couldn't find it on Google. can you provide the link?

> If the RPF kernel runs on the RPi2 board, it wouldn't take much to 
> update the pre/post patches to 3.18.
> 

yes.This is what I tried to do but the gpio driver  [above link] the  `bcm2708_gpio_interrupt` function needs to be reviewed by an expert. 		 	   		  

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Paul]

On Monday 08 June 2015, mobin Motallebizadeh wrote:
> > 2) The "official" Linux support is to be found in the mach-bcm2709

Warning: I may be mistaken here, it could be the mach-bcm2835 tree. It 
has been a while since I've done anything with the RPi kernels. Having 
three (sub)trees for Broadcom devices is confusing...

> > tree. This is still "work in progress", but looks to be at the
> > stage where it is usable - I've not been following developments too
> > closely, is it in the mainline kernel yet ?
>
> never heard of it! and couldn't find it on Google. can you provide
> the link?

Google "rpi mainline" gives 46,100 hits, top of the list is: 
http://elinux.org/RPi_Upstreaming

A little further down the list is:
https://www.raspberrypi.org/forums/viewtopic.php?f=71&t=12504 which 
provides a link to the mailing list where development is discussed: 
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[mobin Motallebizadeh]

> On Jun 9, 2015, at 4:57 AM, Paul <paul_c@tuxcnc.org> wrote:
> 
> On Monday 08 June 2015, mobin Motallebizadeh wrote:
>>> 2) The "official" Linux support is to be found in the mach-bcm2709
> 
> Warning: I may be mistaken here, it could be the mach-bcm2835 tree. It 
> has been a while since I've done anything with the RPi kernels. Having 
> three (sub)trees for Broadcom devices is confusing...
> 
>>> tree. This is still "work in progress", but looks to be at the
>>> stage where it is usable - I've not been following developments too
>>> closely, is it in the mainline kernel yet ?
>> 
>> never heard of it! and couldn't find it on Google. can you provide
>> the link?
> 
> Google "rpi mainline" gives 46,100 hits, top of the list is: 
> http://elinux.org/RPi_Upstreaming
> 
> A little further down the list is:
> https://www.raspberrypi.org/forums/viewtopic.php?f=71&t=12504 which 
> provides a link to the mailing list where development is discussed: 
> http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

They're all about bcm3845 and old rpi and there are ipipe patches for it.
None of them talk about rpi 2 which is from another architecture.

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Gilles Chanteperdrix]

On Tue, Jun 09, 2015 at 09:01:52PM +0430, mobin Motallebizadeh wrote:
> None of them talk about rpi 2 which is from another architecture.

That is simply not true. rpi2 processor has an ARM core, just like rpi.

-- 
					    Gilles.

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Lennart Sorensen]

On Tue, Jun 09, 2015 at 06:40:46PM +0200, Gilles Chanteperdrix wrote:
> On Tue, Jun 09, 2015 at 09:01:52PM +0430, mobin Motallebizadeh wrote:
> > None of them talk about rpi 2 which is from another architecture.
> 
> That is simply not true. rpi2 processor has an ARM core, just like rpi.

Yes armv6 and armv7 are not different architectures, just different
generations, and given apparently the pheripherals of the two bcm chips,
they should be fairly compatible, although I suppose one being quad core
and having probably a different IRQ controller could cause some work to
need to be done (almost certainly, although it might be a standard
arm gic, I haven't looked at that part of the pi 2 yet, given when I got
one, my wife immediately took it and I haven't got to touch it since.
Apparently I should have gotten two.).

-- 
Len Sorensen

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Adam Vaughan]

> Although I suppose one being quad core and having probably a different
> IRQ controller could cause some work to need to be done (almost
> certainly, although it might be a standard arm gic

Some specifics about the RPi 2 interrupt implementation are available here:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf

On Tue, Jun 9, 2015 at 10:41 AM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> On Tue, Jun 09, 2015 at 06:40:46PM +0200, Gilles Chanteperdrix wrote:
>> On Tue, Jun 09, 2015 at 09:01:52PM +0430, mobin Motallebizadeh wrote:
>> > None of them talk about rpi 2 which is from another architecture.
>>
>> That is simply not true. rpi2 processor has an ARM core, just like rpi.
>
> Yes armv6 and armv7 are not different architectures, just different
> generations, and given apparently the pheripherals of the two bcm chips,
> they should be fairly compatible, although I suppose one being quad core
> and having probably a different IRQ controller could cause some work to
> need to be done (almost certainly, although it might be a standard
> arm gic, I haven't looked at that part of the pi 2 yet, given when I got
> one, my wife immediately took it and I haven't got to touch it since.
> Apparently I should have gotten two.).
>
> --
> Len Sorensen
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Lennart Sorensen]

On Tue, Jun 09, 2015 at 01:41:38PM -0400, Lennart Sorensen wrote:
> Yes armv6 and armv7 are not different architectures, just different
> generations, and given apparently the pheripherals of the two bcm chips,
> they should be fairly compatible, although I suppose one being quad core
> and having probably a different IRQ controller could cause some work to
> need to be done (almost certainly, although it might be a standard
> arm gic, I haven't looked at that part of the pi 2 yet, given when I got
> one, my wife immediately took it and I haven't got to touch it since.
> Apparently I should have gotten two.).

Well the documentation does say that the Pi 2 has an arm GIC and uses
the same timer as the Cortex-A15, so at least a lot of the support work
should already exist for ipipe/xenomai to work.

-- 
Len Sorensen

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[mobin Motallebizadeh]

> From: lsorense@csclub.uwaterloo.ca
> Date: Tue, 9 Jun 2015 13:41:38 -0400
> To: gilles.chanteperdrix@xenomai.org
> CC: mobin.seven@live.com; xenomai@xenomai.org
> Subject: Re: [Xenomai] Raspberry Pi 2 patch - BCM2709
> 
> On Tue, Jun 09, 2015 at 06:40:46PM +0200, Gilles Chanteperdrix wrote:
> > On Tue, Jun 09, 2015 at 09:01:52PM +0430, mobin Motallebizadeh wrote:
> > > None of them talk about rpi 2 which is from another architecture.
> > 
> > That is simply not true. rpi2 processor has an ARM core, just like rpi.
> 
> Yes armv6 and armv7 are not different architectures, just different
> generations, and given apparently the pheripherals of the two bcm chips,
> they should be fairly compatible, although I suppose one being quad core
> and having probably a different IRQ controller could cause some work to
> need to be done (almost certainly, although it might be a standard
> arm gic, I haven't looked at that part of the pi 2 yet, given when I got
> one, my wife immediately took it and I haven't got to touch it since.
> Apparently I should have gotten two.).
> 
> -- 
> Len Sorensen

I've made some patches [see attachments]. I've just modified  ipipe patch for 3.18.12 and raspberry related patches to match RPi repo [https://github.com/raspberrypi/linux] which is 3.18.14 .
the resulting kernel img boots without IPIPE and XENOMAI configs successfully(of course!) but with IPIPE doesn't boot.(so I haven't netconsole working)
any suggestion to make it work will be appreciated. 		 	   		  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipipe-core-3.18.14-arm.patch
Type: application/octet-stream
Size: 728647 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150610/45d8899d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipipe-core-3.18.14-raspberry-post.patch
Type: application/octet-stream
Size: 6556 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150610/45d8899d/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipipe-core-3.18.14-raspberry-pre.patch
Type: application/octet-stream
Size: 552 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150610/45d8899d/attachment-0002.obj>

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Gilles Chanteperdrix]

mobin Motallebizadeh wrote:
>> From: lsorense@csclub.uwaterloo.ca
>> Date: Tue, 9 Jun 2015 13:41:38 -0400
>> To: gilles.chanteperdrix@xenomai.org
>> CC: mobin.seven@live.com; xenomai@xenomai.org
>> Subject: Re: [Xenomai] Raspberry Pi 2 patch - BCM2709
>>
>> On Tue, Jun 09, 2015 at 06:40:46PM +0200, Gilles Chanteperdrix wrote:
>> > On Tue, Jun 09, 2015 at 09:01:52PM +0430, mobin Motallebizadeh wrote:
>> > > None of them talk about rpi 2 which is from another architecture.
>> >
>> > That is simply not true. rpi2 processor has an ARM core, just like
>> rpi.
>>
>> Yes armv6 and armv7 are not different architectures, just different
>> generations, and given apparently the pheripherals of the two bcm chips,
>> they should be fairly compatible, although I suppose one being quad core
>> and having probably a different IRQ controller could cause some work to
>> need to be done (almost certainly, although it might be a standard
>> arm gic, I haven't looked at that part of the pi 2 yet, given when I got
>> one, my wife immediately took it and I haven't got to touch it since.
>> Apparently I should have gotten two.).
>>
>> --
>> Len Sorensen
>
> I've made some patches [see attachments]. I've just modified  ipipe patch
> for 3.18.12 and raspberry related patches to match RPi repo
> [https://github.com/raspberrypi/linux] which is 3.18.14 .
> the resulting kernel img boots without IPIPE and XENOMAI configs
> successfully(of course!) but with IPIPE doesn't boot.(so I haven't
> netconsole working)
> any suggestion to make it work will be appreciated.

See:
http://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/

-- 
                    Gilles.

Re: [Xenomai] Raspberry Pi 2 patch - BCM2709

[Lennart Sorensen]

On Wed, Jun 10, 2015 at 03:24:51AM +0000, mobin Motallebizadeh wrote:
> I've made some patches [see attachments]. I've just modified  ipipe patch for 3.18.12 and raspberry related patches to match RPi repo [https://github.com/raspberrypi/linux] which is 3.18.14 .
> the resulting kernel img boots without IPIPE and XENOMAI configs successfully(of course!) but with IPIPE doesn't boot.(so I haven't netconsole working)
> any suggestion to make it work will be appreciated. 		 	   		  
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: ipipe-core-3.18.14-arm.patch
> Type: application/octet-stream
> Size: 728647 bytes
> Desc: not available
> URL: <http://xenomai.org/pipermail/xenomai/attachments/20150610/45d8899d/attachment.obj>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: ipipe-core-3.18.14-raspberry-post.patch
> Type: application/octet-stream
> Size: 6556 bytes
> Desc: not available
> URL: <http://xenomai.org/pipermail/xenomai/attachments/20150610/45d8899d/attachment-0001.obj>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: ipipe-core-3.18.14-raspberry-pre.patch
> Type: application/octet-stream
> Size: 552 bytes
> Desc: not available
> URL: <http://xenomai.org/pipermail/xenomai/attachments/20150610/45d8899d/attachment-0002.obj>

Do you have earlyprintk enabled?  I find it is often helpful for crashes
early in boot to get an idea where to look.  This assuming you have
a serial console (and if you don't, I would try to get one, they are
really helpful early on).

-- 
Len Sorensen