Re: [Xenomai] xeno_16550A driver install problems.

Re: [Xenomai] xeno_16550A driver install problems.

[Cédric]

Hello,
I want also use the xeno_16550A with a Beaglebone,
I have the same kernel (  Debian 3.8.13-bone64) and the same xenomai 2.6.4.
Actually I have:
- disable CONFIG_SERIAL_OMAP in kernel configuration
- disable CONFIG_SERIAL_8250
- xeno_16550A as loadable module and patch with your patch


First :

setserial -g /dev/ttyS*
/dev/ttyS0, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS1, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS2, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS3, UART: unknown, Port: 0x0000, IRQ: 0

Second :
modprobe xeno_16550A mem=0x48024000 irq=74 baud_base=115200 tx_fifo=64
regshift=2 regwidth=2 start_index=1

result of dmesg:
[ 2706.679850] Unhandled fault: external abort on non-linefetch (0x1028) at
0xfa024008
[ 2706.680024] Internal error: : 1028 [#1] SMP THUMB2
[ 2706.680106] Modules linked in: xeno_16550A(+) 8250_core g_multi
libcomposite omap_rng omap_serial rtc_bq32k gpio_pca953x can_raw can_dev can
[ 2706.680382] CPU: 0    Not tainted  (3.8.13-bone67 #8)
[ 2706.680490] PC is at rt_16550_reg_in+0x25/0x54 [xeno_16550A]
[ 2706.680595] LR is at init_module+0xee/0x1a3 [xeno_16550A]
[ 2706.680687] pc : [<bf85f5ce>]    lr : [<bf8640ef>]    psr: 80000033
[ 2706.680687] sp : dd9dbe28  ip : dd9dbd38  fp : bf8614bc
[ 2706.680844] r10: 00000000  r9 : bf86149c  r8 : decd9b80
[ 2706.680920] r7 : 00000001  r6 : fa024000  r5 : 00000000  r4 : bf861438
[ 2706.681013] r3 : 00000002  r2 : 00000008  r1 : fa024008  r0 : 00000001
[ 2706.681104] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb
Segment user
[ 2706.681222] Control: 50c5387d  Table: 9ebac019  DAC: 00000015
[ 2706.681305] Process modprobe (pid: 643, stack limit = 0xdd9da240)
[ 2706.681392] Stack: (0xdd9dbe28 to 0xdd9dc000)
[ 2706.681460] be20:                   c08c0ce4 c08c0ce4 00000000 00400100
bf8612dc bf8612d0
[ 2706.681573] be40: dd9da000 bf861318 c09068c0 bf864001 00000000 c0008807
c08bf7b4 002a0029
[ 2706.681688] be60: 00000000 dd9da000 002a002a c05016f9 c08bf7b0 c00499f5
00000000 00000007
[ 2706.681800] be80: 00000000 00400100 bf8612dc bf8612d0 dd9da000 bf861318
deaab940 00000001
[ 2706.681915] bea0: 00000124 c006bd19 bf8612dc 00007fff c006901d dd9dbf04
00000124 bf8612dc
[ 2706.682030] bec0: dd9da000 b6fcb288 bf861424 c0886b0c bf8612d0 dd9dbef4
dd9dbf1c c07d4a54
[ 2706.682148] bee0: dd9da000 c0501975 e0d88000 b6dd7000 00000273 00000000
00000000 00000000
[ 2706.682272] bf00: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[ 2706.682391] bf20: 00000000 00000000 00000000 00000000 20000033 000062f3
b6dd1000 b6fcb288
[ 2706.682505] bf40: 00000080 c000cb68 dd9da000 00000000 00000000 c006c15b
e0d82000 000062f3
[ 2706.682618] bf60: e0d857d8 e0d85685 e0d87b28 00002520 000031f0 00000000
00000000 00000000
[ 2706.682734] bf80: 00000022 00000023 00000017 0000001b 0000000f 00000000
00000000 b6fcb2f0
[ 2706.682847] bfa0: b6fcb228 c000c961 00000000 b6fcb2f0 b6dd1000 000062f3
b6fcb288 00000002
[ 2706.682960] bfc0: 00000000 b6fcb2f0 b6fcb228 00000080 00000000 b6fcb288
000062f3 00000000
[ 2706.683073] bfe0: 00040000 beb1d384 b6f82b07 b6f0dfd4 80000010 b6dd1000
9fefe821 9fefec21
[ 2706.683225] [<bf85f5ce>] (rt_16550_reg_in+0x25/0x54 [xeno_16550A]) from
[<bf8640ef>] (init_module+0xee/0x1a3 [xeno_16550A])
[ 2706.683397] [<bf8640ef>] (init_module+0xee/0x1a3 [xeno_16550A]) from
[<c0008807>] (do_one_initcall+0xc7/0x120)
[ 2706.683544] [<c0008807>] (do_one_initcall+0xc7/0x120) from [<c006bd19>]
(load_module+0x1251/0x1630)
[ 2706.683675] [<c006bd19>] (load_module+0x1251/0x1630) from [<c006c15b>]
(sys_init_module+0x63/0x90)
[ 2706.683806] [<c006c15b>] (sys_init_module+0x63/0x90) from [<c000c961>]
(ret_fast_syscall+0x1/0x46)
[ 2706.683932] Code: 4b0c 6c1b 409a 1851 (880b) f3bf
[ 2706.690140] ---[ end trace 781415ad731ff6a1 ]---


Do you have the same problem ?

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

Cédric wrote:
> Do you have the same problem ?

Yes, this is a know issue, the 16550A on BeagleBone has the same register
layout as others 16550A except that its registers offsets must be
multiplied by 4. The Beaglebone driver also access the registers using 16
bits
acccesses, although I suspect this would work as well with 32 bits accesses,
but it probably does not work with byte accesses.

Another problem is that to get that driver working you probably also need to
enable some clocks.

I said I would look into it, but have other things on my plate. Any patch to
fix this will be welcome.

Regards.

-- 
                    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Fri, Dec 05, 2014 at 04:25:22PM +0100, Cédric wrote:
> Question : On startup, in omap-serial.c, the function "serial_omap_probe"
> initializes the gpio mux, I don't find initialization of gpio mux in
> 16550A.h.  Is this normal?

Yes, pinmuxing and selecting gpios is purely specific to the
platform, and would have nothing to do in a generic driver like 16550A.

> Two observation:
> 1 : module bug at line 1162, when read LSR

For the third time: the patch is not sufficient, you need to enable
the clocks.

> 2: your patch at read/write with regwith but:
>  - in read, you don't return value , and return type is u8
>  - in write, you write a  u8 type value, in omap-serial, the write value
> type is int.

I do not remmeber the details, but I am almost sure I used the right
function (readb, readw, readl, writedb, writew, writel) to perform
the read or the write with the right width to the hardware register.
This is what matters. Other than that, only 8 bits are useful in the
registers, so you can safely use u8 as arguments of the functions.

Please do not top post. Please stay on the list.

Regards.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Lennart Sorensen]

On Thu, Nov 13, 2014 at 08:44:58AM +0000, Terje Frøysa wrote:
> Sorry Gilles,
> Still crashing....
> 
> First I booted OK with irq=0,0,0
> Verified all (other) parameters:
> 
> debian@beaglebone:/sys/module/xeno_16550A/parameters$ ls
> baud_base  irq  mem  regshift  regwidth  start_index  tx_fifo
> mem = 1208098816,1208107008,1209696256,0,0,0,0,0
> irq = 0,0,0,0,0,0,0,0
> regshift = 2
> regwiddth = 2
> baud_base = 115200,115200,115200,0,0,0,0,0
> tx_fifo = 64,64,64,0,0,0,0,0
> start_index = 1
> 
> Then setting 
>        xeno_16550A.irq=73,74,45 \
> 
> Rebooted and crashed:
> 
> [    2.491980] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa022008

An external abort is often (almost always in my experience) what happens
when you try to access a register on something that is either not powered
on, or does not have clocks enabled.

So you may unfortunately need to get into clock setup.

-- 
Len Sorensen

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Thu, Nov 13, 2014 at 08:44:58AM +0000, Terje Frøysa wrote:
> Sorry Gilles,
> Still crashing....
> 
> First I booted OK with irq=0,0,0
> Verified all (other) parameters:
> 
> debian@beaglebone:/sys/module/xeno_16550A/parameters$ ls
> baud_base  irq  mem  regshift  regwidth  start_index  tx_fifo
> mem = 1208098816,1208107008,1209696256,0,0,0,0,0
> irq = 0,0,0,0,0,0,0,0
> regshift = 2
> regwiddth = 2

It is regwidth = 2, not regwiddth. Please make sure that both are
set correctly.

Also, could you try to only try one UART, the one you want to test?
There is no need to enable the other ones.

And in fact, I would test the one with the serial console, since it
is known to work.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Sorry Gilles,
Still crashing....

First I booted OK with irq=0,0,0
Verified all (other) parameters:

debian@beaglebone:/sys/module/xeno_16550A/parameters$ ls
baud_base  irq  mem  regshift  regwidth  start_index  tx_fifo
mem = 1208098816,1208107008,1209696256,0,0,0,0,0
irq = 0,0,0,0,0,0,0,0
regshift = 2
regwiddth = 2
baud_base = 115200,115200,115200,0,0,0,0,0
tx_fifo = 64,64,64,0,0,0,0,0
start_index = 1

Then setting 
       xeno_16550A.irq=73,74,45 \

Rebooted and crashed:

[    2.491980] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa022008
[    2.499996] Internal error: : 1028 [#1] SMP THUMB2
[    2.505001] Modules linked in:
[    2.508195] CPU: 0    Not tainted  (3.8.13-bone67 #16)
[    2.513569] PC is at rt_16550_init+0x120/0x270
[    2.518216] LR is at _raw_read_unlock+0x7/0x8
[    2.522767] pc : [<c0884ff0>]    lr : [<c0531c33>]    psr: 60000033
[    2.522767] sp : de871f20  ip : ffffffff  fp : c0926a88
[    2.534744] r10: fa022000  r9 : c0926a88  r8 : 00000000
[    2.540188] r7 : c0a09e8c  r6 : dd944380  r5 : c0a09f10  r4 : 00000000
[    2.546990] r3 : fa022008  r2 : 00000002  r1 : 48022fff  r0 : fa022000
[    2.553805] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment kernel
[    2.561614] Control: 50c5387d  Table: 9d958019  DAC: 00000015
[    2.567605] Process swapper/0 (pid: 1, stack limit = 0xde870240)
[    2.573868] Stack: (0xde871f20 to 0xde872000)
[    2.578499] 1f20: 00000000 c08903fc de870000 c0934440 00000000 c0884ed1 0000010e c08a490c
[    2.587086] 1f40: 00000000 c000873f 00000006 00000006 c08eb998 c08903f8 c08903fc 00000006
[    2.595710] 1f60: c08903dc c0934440 c08661c9 c08a490c 00000000 c08666b3 00000006 00000006
[    2.604285] 1f80: c08661c9 c0e27d00 00000000 c0527fc1 00000000 00000000 00000000 00000000
[    2.612847] 1fa0: 00000000 c0527fc7 00000000 c000cb5b 00000000 00000000 00000000 00000000
[    2.621399] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.629958] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 2d0f018e 33384541
[    2.638529] [<c0884ff0>] (rt_16550_init+0x120/0x270) from [<c000873f>] (do_one_initcall+0x1f/0xf8)
[    2.647924] [<c000873f>] (do_one_initcall+0x1f/0xf8) from [<c08666b3>] (kernel_init_freeable+0xc7/0x15c)
[    2.657857] [<c08666b3>] (kernel_init_freeable+0xc7/0x15c) from [<c0527fc7>] (kernel_init+0x7/0x98)
[    2.667337] [<c0527fc7>] (kernel_init+0x7/0x98) from [<c000cb5b>] (ret_from_fork+0x13/0x38)
[    2.676110] Code: 20c4 fa03 f302 4453 (881a) f3bf
[    2.681178] ---[ end trace 2d6d11674edfbfca ]---
[    2.686083] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    2.686083]

-----Original Message-----
From: Xenomai [mailto:xenomai-bounces@xenomai.org] On Behalf Of Terje Frøysa
Sent: 13. november 2014 09:32
To: Gilles Chanteperdrix
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

Ah... sorry,
Trying again....

Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 13. november 2014 09:30
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Thu, Nov 13, 2014 at 08:25:46AM +0000, Terje Frøysa wrote:
> Ah.. like this?:
> cmdline=xeno_16550A.mem=0x48022000,0x48024000,0x481a8000 \
>         xeno_16550A.irq=73,74,45 \
>         xeno_16550A.baud_base=115200,115200,115200 \
>         xeno_16550A.tx_fifo=64,64,64 \
>         xeno_16550A.regshift=2,2,2
>         xeno_16550A.regwidth=2,2,2
>         xeno_16550A.start_index=1

No, they are not arrays, just xeno_16550A.regshift=2 xeno_16550A.regwidth=2

-- 
					    Gilles.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Ah... sorry,
Trying again....

Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 13. november 2014 09:30
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Thu, Nov 13, 2014 at 08:25:46AM +0000, Terje Frøysa wrote:
> Ah.. like this?:
> cmdline=xeno_16550A.mem=0x48022000,0x48024000,0x481a8000 \
>         xeno_16550A.irq=73,74,45 \
>         xeno_16550A.baud_base=115200,115200,115200 \
>         xeno_16550A.tx_fifo=64,64,64 \
>         xeno_16550A.regshift=2,2,2
>         xeno_16550A.regwidth=2,2,2
>         xeno_16550A.start_index=1

No, they are not arrays, just xeno_16550A.regshift=2 xeno_16550A.regwidth=2

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Thu, Nov 13, 2014 at 08:25:46AM +0000, Terje Frøysa wrote:
> Ah.. like this?:
> cmdline=xeno_16550A.mem=0x48022000,0x48024000,0x481a8000 \
>         xeno_16550A.irq=73,74,45 \
>         xeno_16550A.baud_base=115200,115200,115200 \
>         xeno_16550A.tx_fifo=64,64,64 \
>         xeno_16550A.regshift=2,2,2
>         xeno_16550A.regwidth=2,2,2
>         xeno_16550A.start_index=1

No, they are not arrays, just xeno_16550A.regshift=2 xeno_16550A.regwidth=2

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Sorry Gilles,
Still crashing:

cmdline=xeno_16550A.mem=0x48022000,0x48024000,0x481a8000 \
        xeno_16550A.irq=73,74,45 \
        xeno_16550A.baud_base=115200,115200,115200 \
        xeno_16550A.tx_fifo=64,64,64 \
        xeno_16550A.regshift=2,2,2
        xeno_16550A.regwidth=2,2,2
        xeno_16550A.start_index=1

[    2.495368] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa022002
[    2.503382] Internal error: : 1028 [#1] SMP THUMB2
[    2.508387] Modules linked in:
[    2.511580] CPU: 0    Not tainted  (3.8.13-bone67 #16)
[    2.516953] PC is at rt_16550_init+0x10c/0x270
[    2.521602] LR is at _raw_read_unlock+0x7/0x8
[    2.526151] pc : [<c0884fdc>]    lr : [<c0531c33>]    psr: 60000033
[    2.526151] sp : de871f20  ip : ffffffff  fp : c0926a88
[    2.538129] r10: fa022000  r9 : c0926a88  r8 : 00000000
[    2.543580] r7 : c0a09e8c  r6 : dd944380  r5 : c0a09f10  r4 : 00000000
[    2.550390] r3 : 00000000  r2 : 00000002  r1 : 48022fff  r0 : fa022000
[    2.557194] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment kernel
[    2.565002] Control: 50c5387d  Table: 9d958019  DAC: 00000015
[    2.570993] Process swapper/0 (pid: 1, stack limit = 0xde870240)
[    2.577260] Stack: (0xde871f20 to 0xde872000)
[    2.581806] 1f20: 00000000 c08903fc de870000 c0934440 00000000 c0884ed1 0000010e c08a490c
[    2.590342] 1f40: 00000000 c000873f 00000006 00000006 c08eb998 c08903f8 c08903fc 00000006
[    2.598875] 1f60: c08903dc c0934440 c08661c9 c08a490c 00000000 c08666b3 00000006 00000006
[    2.607406] 1f80: c08661c9 c0e27d00 00000000 c0527fc1 00000000 00000000 00000000 00000000
[    2.615938] 1fa0: 00000000 c0527fc7 00000000 c000cb5b 00000000 00000000 00000000 00000000
[    2.624482] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.633017] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 2d0f018e 33384541
[    2.641581] [<c0884fdc>] (rt_16550_init+0x10c/0x270) from [<c000873f>] (do_one_initcall+0x1f/0xf8)
[    2.650945] [<c000873f>] (do_one_initcall+0x1f/0xf8) from [<c08666b3>] (kernel_init_freeable+0xc7/0x15c)
[    2.660861] [<c08666b3>] (kernel_init_freeable+0xc7/0x15c) from [<c0527fc7>] (kernel_init+0x7/0x98)
[    2.670309] [<c0527fc7>] (kernel_init+0x7/0x98) from [<c000cb5b>] (ret_from_fork+0x13/0x38)
[    2.679029] Code: f8d7 30c4 fa02 f203 (f81a) 3002
[    2.684066] ---[ end trace c896c3049d02efa9 ]---
[    2.689160] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 13. november 2014 09:23
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Thu, Nov 13, 2014 at 08:20:16AM +0000, Terje Frøysa wrote:
> Ok Gilles,
> 
> Worked until enabled xeno_16550A by kernel parameters.
> Can you see anything wrong here?

You need to pass regshift and regwidth parameter, regshift=2 and
regwidth=2 

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Ah.. like this?:
cmdline=xeno_16550A.mem=0x48022000,0x48024000,0x481a8000 \
        xeno_16550A.irq=73,74,45 \
        xeno_16550A.baud_base=115200,115200,115200 \
        xeno_16550A.tx_fifo=64,64,64 \
        xeno_16550A.regshift=2,2,2
        xeno_16550A.regwidth=2,2,2
        xeno_16550A.start_index=1

Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 13. november 2014 09:23
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Thu, Nov 13, 2014 at 08:20:16AM +0000, Terje Frøysa wrote:
> Ok Gilles,
> 
> Worked until enabled xeno_16550A by kernel parameters.
> Can you see anything wrong here?

You need to pass regshift and regwidth parameter, regshift=2 and
regwidth=2 

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Thu, Nov 13, 2014 at 08:20:16AM +0000, Terje Frøysa wrote:
> Ok Gilles,
> 
> Worked until enabled xeno_16550A by kernel parameters.
> Can you see anything wrong here?

You need to pass regshift and regwidth parameter, regshift=2 and
regwidth=2 

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Ok Gilles,

Worked until enabled xeno_16550A by kernel parameters.
Can you see anything wrong here?
Am I bound for clock-work programming now?

Terje
------- epicrisis: -------
System up-and-go without ttyO[1,2,4] and ttyS[0-4]
/sys/module/xeno_16550A present.
New parameters regshift (0) and regwidth (1) in place:

debian@beaglebone:/sys/module/xeno_16550A/parameters$ ls -l
total 0
-r-------- 1 root root 4096 Nov 13 08:09 baud_base
-r-------- 1 root root 4096 Nov 13 08:09 irq
-r-------- 1 root root 4096 Nov 13 08:09 mem
-r-------- 1 root root 4096 Nov 13 08:09 regshift
-r-------- 1 root root 4096 Nov 13 08:09 regwidth
-r-------- 1 root root 4096 Nov 13 08:09 start_index
-r-------- 1 root root 4096 Nov 13 08:09 tx_fifo

Next, enter kernel parameters for uarts in uEnv.txt:
#                         UART1      UART2      UART4
cmdline=xeno_16550A.mem=0x48022000,0x48024000,0x481a8000 \
        xeno_16550A.irq=73,74,45 \
        xeno_16550A.baud_base=115200,115200,115200 \
        xeno_16550A.tx_fifo=64,64,64,64 \
        xeno_16550A.start_index=1

rebooted, but crashed:
[    2.487429] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa022002
[    2.495446] Internal error: : 1028 [#1] SMP THUMB2
[    2.500451] Modules linked in:
[    2.503642] CPU: 0    Not tainted  (3.8.13-bone67 #16)
[    2.509015] PC is at rt_16550_init+0x10c/0x270
[    2.513667] LR is at _raw_read_unlock+0x7/0x8
[    2.518215] pc : [<c0884fdc>]    lr : [<c0531c33>]    psr: 60000033
[    2.518215] sp : de871f20  ip : ffffffff  fp : c0926a88
[    2.530193] r10: fa022000  r9 : c0926a88  r8 : 00000000
[    2.535650] r7 : c0a09e8c  r6 : dd948380  r5 : c0a09f10  r4 : 00000000
[    2.542464] r3 : 00000000  r2 : 00000002  r1 : 48022fff  r0 : fa022000
[    2.549284] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment kernel
[    2.557093] Control: 50c5387d  Table: 9d958019  DAC: 00000015
[    2.563086] Process swapper/0 (pid: 1, stack limit = 0xde870240)
[    2.569349] Stack: (0xde871f20 to 0xde872000)
[    2.573896] 1f20: 00000000 c08903fc de870000 c0934440 00000000 c0884ed1 0000010e c08a490c
[    2.582430] 1f40: 00000000 c000873f 00000006 00000006 c08eb998 c08903f8 c08903fc 00000006
[    2.590963] 1f60: c08903dc c0934440 c08661c9 c08a490c 00000000 c08666b3 00000006 00000006
[    2.599504] 1f80: c08661c9 c0e27d00 00000000 c0527fc1 00000000 00000000 00000000 00000000
[    2.608031] 1fa0: 00000000 c0527fc7 00000000 c000cb5b 00000000 00000000 00000000 00000000
[    2.616570] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.625109] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 2d0f01ce 33384541
[    2.633669] [<c0884fdc>] (rt_16550_init+0x10c/0x270) from [<c000873f>] (do_one_initcall+0x1f/0xf8)
[    2.643041] [<c000873f>] (do_one_initcall+0x1f/0xf8) from [<c08666b3>] (kernel_init_freeable+0xc7/0x15c)
[    2.652962] [<c08666b3>] (kernel_init_freeable+0xc7/0x15c) from [<c0527fc7>] (kernel_init+0x7/0x98)
[    2.662413] [<c0527fc7>] (kernel_init+0x7/0x98) from [<c000cb5b>] (ret_from_fork+0x13/0x38)
[    2.671131] Code: f8d7 30c4 fa02 f203 (f81a) 3002
[    2.676175] ---[ end trace a0b515cf6079f46f ]---
[    2.681263] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b


-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 13. november 2014 09:02
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Thu, Nov 13, 2014 at 08:56:16AM +0100, Gilles Chanteperdrix wrote:
> On Thu, Nov 13, 2014 at 07:53:13AM +0000, Terje Frøysa wrote:
> > Thanks Gilles,
> > 
> > Patch ran without problems now. Checked source and found it correctly patched.
> > 
> > I am going to compile a new kernel.
> > I have three UARTS.
> > I am tempted to do as follows:
> > 
> > 1. Disable the 8250 (It is not applicable anyhow in current version) 
> > 2. Enable omap_uart on UART 1 3. Install xeno_16550A in kernel.
> > 4. Apply kernel parameters for UART 2 and 4 for the xeno_16550A.
> > 5. If successful, try the cross-link between UART 2 and 4.
> > 
> > If you see some caveats regarding my plan, please tell.
> 
> Well, this is risky, I would:
> - enable neither omap_uart nor 8250 in kernel configuration
> - plug UART2 to the PC with a USB-serial cable if the PC does not have 
> a serial port.

And first test the PC <-> board serial link with a kernel with a working omap-serial, with UART2 plugged to the PC. To be sure that the PC side is working.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Thu, Nov 13, 2014 at 08:56:16AM +0100, Gilles Chanteperdrix wrote:
> On Thu, Nov 13, 2014 at 07:53:13AM +0000, Terje Frøysa wrote:
> > Thanks Gilles,
> > 
> > Patch ran without problems now. Checked source and found it correctly patched.
> > 
> > I am going to compile a new kernel.
> > I have three UARTS.
> > I am tempted to do as follows:
> > 
> > 1. Disable the 8250 (It is not applicable anyhow in current version)
> > 2. Enable omap_uart on UART 1
> > 3. Install xeno_16550A in kernel.
> > 4. Apply kernel parameters for UART 2 and 4 for the xeno_16550A.
> > 5. If successful, try the cross-link between UART 2 and 4.
> > 
> > If you see some caveats regarding my plan, please tell.
> 
> Well, this is risky, I would:
> - enable neither omap_uart nor 8250 in kernel configuration
> - plug UART2 to the PC with a USB-serial cable if the PC does not
> have a serial port.

And first test the PC <-> board serial link with a kernel with a
working omap-serial, with UART2 plugged to the PC. To be sure that
the PC side is working.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Ok Gilles,

I have the debug-port connected to the PC via a separate serial-to-USB converter.
I'll try out your suggested configuration, then with xeno_16550A on all (1,2,4) UARTs.

Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 13. november 2014 08:56
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Thu, Nov 13, 2014 at 07:53:13AM +0000, Terje Frøysa wrote:
> Thanks Gilles,
> 
> Patch ran without problems now. Checked source and found it correctly patched.
> 
> I am going to compile a new kernel.
> I have three UARTS.
> I am tempted to do as follows:
> 
> 1. Disable the 8250 (It is not applicable anyhow in current version) 
> 2. Enable omap_uart on UART 1 3. Install xeno_16550A in kernel.
> 4. Apply kernel parameters for UART 2 and 4 for the xeno_16550A.
> 5. If successful, try the cross-link between UART 2 and 4.
> 
> If you see some caveats regarding my plan, please tell.

Well, this is risky, I would:
- enable neither omap_uart nor 8250 in kernel configuration
- plug UART2 to the PC with a USB-serial cable if the PC does not have a serial port.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Thu, Nov 13, 2014 at 07:53:13AM +0000, Terje Frøysa wrote:
> Thanks Gilles,
> 
> Patch ran without problems now. Checked source and found it correctly patched.
> 
> I am going to compile a new kernel.
> I have three UARTS.
> I am tempted to do as follows:
> 
> 1. Disable the 8250 (It is not applicable anyhow in current version)
> 2. Enable omap_uart on UART 1
> 3. Install xeno_16550A in kernel.
> 4. Apply kernel parameters for UART 2 and 4 for the xeno_16550A.
> 5. If successful, try the cross-link between UART 2 and 4.
> 
> If you see some caveats regarding my plan, please tell.

Well, this is risky, I would:
- enable neither omap_uart nor 8250 in kernel configuration
- plug UART2 to the PC with a USB-serial cable if the PC does not
have a serial port.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Thanks Gilles,

Patch ran without problems now. Checked source and found it correctly patched.

I am going to compile a new kernel.
I have three UARTS.
I am tempted to do as follows:

1. Disable the 8250 (It is not applicable anyhow in current version)
2. Enable omap_uart on UART 1
3. Install xeno_16550A in kernel.
4. Apply kernel parameters for UART 2 and 4 for the xeno_16550A.
5. If successful, try the cross-link between UART 2 and 4.

If you see some caveats regarding my plan, please tell.

Terje


-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 13. november 2014 08:21
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Thu, Nov 13, 2014 at 07:18:00AM +0000, Terje Frøysa wrote:
> Hello Gilles,
> 
> Tried out the patch, but got an error message from patch (see between ---- lines below).
> I have copied your patch in both a Windows and Ubuntu environment to assure there are no line-terminating problems.
> I am not an experienced "patcher", hence I have difficulties with pinpointing the problem.

Ok, sending it as attachment.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Thu, Nov 13, 2014 at 07:18:00AM +0000, Terje Frøysa wrote:
> Hello Gilles,
> 
> Tried out the patch, but got an error message from patch (see between ---- lines below).
> I have copied your patch in both a Windows and Ubuntu environment to assure there are no line-terminating problems.
> I am not an experienced "patcher", hence I have difficulties with pinpointing the problem.

Ok, sending it as attachment.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: text/x-diff
Size: 1722 bytes
Desc: the patch
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20141113/0c38b1dc/attachment.diff>

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Hello Gilles,

Tried out the patch, but got an error message from patch (see between ---- lines below).
I have copied your patch in both a Windows and Ubuntu environment to assure there are no line-terminating problems.
I am not an experienced "patcher", hence I have difficulties with pinpointing the problem.

Terje
---------------------------------
debian@beaglebone:~/disk/xenomai-2.6.4$ patch -p1 < ./xeno_16550A.patch
patching file ksrc/drivers/serial/16550A_io.h
patch: **** malformed patch at line 14: @@ -164,7 +171,19 @@ rt_16550_reg_in(io_mode_t io_mode, unsigned long base, int off)
---------------------------------

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 12. november 2014 16:13
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Wed, Nov 12, 2014 at 02:52:54PM +0000, Terje Frøysa wrote:
> Ok Gilles,
> 
> Thanks!
> 
> Terje

Please try the (completely untested, not even compiled) following patch. It should add two parameter to the xeno_16650 module, allowing to change the register shift and register width. For omap-serial, you want regshift=2 and regwidth=2

diff --git a/ksrc/drivers/serial/16550A_io.h b/ksrc/drivers/serial/16550A_io.h index 92d21a5..bf05498 100644
--- a/ksrc/drivers/serial/16550A_io.h
+++ b/ksrc/drivers/serial/16550A_io.h
@@ -33,6 +33,13 @@ static unsigned long mem[MAX_DEVICES];  static void *mapped_io[MAX_DEVICES];  compat_module_param_array(mem, ulong, MAX_DEVICES, 0400);  MODULE_PARM_DESC(mem, "I/O memory addresses of the serial devices");
+static unsigned regshift = 0;
+module_param(regshift, uint, 0400);
+MODULE_PARM_DESC(regshift, "Register shift to be used"); static 
+unsigned regwidth = 1; module_param(regwidth, uint, 0400); 
+MODULE_PARM_DESC(regwidth, "Register width to be used (1, 2 or 4)");
+
 #endif /* CONFIG_XENO_DRIVERS_16550A_MMIO || CONFIG_XENO_DRIVERS_16550A_ANY */
 
 #ifdef CONFIG_XENO_DRIVERS_16550A_PIO
@@ -164,7 +171,19 @@ rt_16550_reg_in(io_mode_t io_mode, unsigned long base, int off)
 	case MODE_PIO:
 		return inb(base + off);
 	default: /* MODE_MMIO */
-		return readb((void *)base + off);
+		switch (regwidth) {
+		case 1:
+			readb((void *)base + (off << regshift));
+			break;
+		case 2:
+			readw((void *)base + (off << regshift));
+			break;
+		case 4:
+			readl((void *)base + (off << regshift));
+			break;
+		default:
+			BUG();
+		}
 	}
 }
 
@@ -176,7 +195,19 @@ rt_16550_reg_out(io_mode_t io_mode, unsigned long base, int off, u8 val)
 		outb(val, base + off);
 		break;
 	case MODE_MMIO:
-		writeb(val, (void *)base + off);
+		switch (regwidth) {
+		case 1:
+			writeb(val, (void *)base + (off << regshift));
+			break;
+		case 2:
+			writew(val, (void *)base + (off << regshift));
+			break;
+		case 4:
+			writel(val, (void *)base + (off << regshift));
+			break;
+		default:
+			BUG();
+		}
 		break;
 	}
 }


-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Thanks again Gilles,

You are, of course, right.
I used the prepare-kernel.sh and  at my kernel source I find the files symbolically linked to the xenomai environment.
lrwxrwxrwx 1 debian   1002    58 Oct 28 10:34 16550A_io.h -> /home/debian/xenomai-2.6.4/ksrc/drivers/serial/16550A_io.h

You have made it very clear!
Thank you!

Beest regards
Terje


-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 12. november 2014 21:39
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Wed, Nov 12, 2014 at 08:33:41PM +0000, Terje Frøysa wrote:
> Hello again Gilles,
> 
> Before patching, I just have to check:
> 
> The batch below refers to a path in the xenomai-2.6.4 directory:
>  /ksrc/drivers/serial/16550A_io.h
> 
> There also exist a corresponding source at the Linux kernel directory:
> bb-kernel/KERNEL/drivers/xenomai/serial/16550A_io.h
> 
> Since the xeno_16550A is enabled in the kernel make menuconfig or 
> included as a loadable module in the kernel, I would assume that the patch is to be applied in the kernel source?
> (and then rebuild the kernel?)


If you have used prepare-kernel.sh to generate the kernel sources, the second is a symbolic link to the first, so you just patch the first, recompile the kernel, and try and boot it. If it is not a symbolic link, then yes, you need to apply the patch to the kernel sources, patch will not find the file and tell you to enter the file name manually.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 08:35:00PM +0000, Terje Frøysa wrote:
> Thanks Gilles,
> 
> Old hardware/firmware man ;-)
> Terje

Ok, a more recent reference:
http://www.tldp.org/HOWTO/Serial-HOWTO.html

more user/administrator oriented than programmer oriented.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 08:33:41PM +0000, Terje Frøysa wrote:
> Hello again Gilles,
> 
> Before patching, I just have to check:
> 
> The batch below refers to a path in the xenomai-2.6.4 directory:
>  /ksrc/drivers/serial/16550A_io.h
> 
> There also exist a corresponding source at the Linux kernel directory:
> bb-kernel/KERNEL/drivers/xenomai/serial/16550A_io.h
> 
> Since the xeno_16550A is enabled in the kernel make menuconfig or included as a loadable module in the kernel,
> I would assume that the patch is to be applied in the kernel source?
> (and then rebuild the kernel?)


If you have used prepare-kernel.sh to generate the kernel sources,
the second is a symbolic link to the first, so you just patch the
first, recompile the kernel, and try and boot it. If it is not a
symbolic link, then yes, you need to apply the patch to the kernel
sources, patch will not find the file and tell you to enter the file
name manually.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Thanks Gilles,

Old hardware/firmware man ;-)
Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 12. november 2014 21:31
To: Terje Frøysa
Cc: Lennart Sorensen; Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Wed, Nov 12, 2014 at 07:51:36PM +0000, Terje Frøysa wrote:
> I have also been searching for a user's manual or some c-code examples 
> utilizing the omap_uart in a more elevated fashion, but I find only novice examples or python scripts.

You are searching the wrong way. omap-serial is a serial driver, and all serial drivers support the same API. The reference for Linux serial drivers is here:

http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Hello again Gilles,

Before patching, I just have to check:

The batch below refers to a path in the xenomai-2.6.4 directory:
 /ksrc/drivers/serial/16550A_io.h

There also exist a corresponding source at the Linux kernel directory:
bb-kernel/KERNEL/drivers/xenomai/serial/16550A_io.h

Since the xeno_16550A is enabled in the kernel make menuconfig or included as a loadable module in the kernel,
I would assume that the patch is to be applied in the kernel source?
(and then rebuild the kernel?)

I need an advice.

Best regards
Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 12. november 2014 16:13
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Wed, Nov 12, 2014 at 02:52:54PM +0000, Terje Frøysa wrote:
> Ok Gilles,
> 
> Thanks!
> 
> Terje

Please try the (completely untested, not even compiled) following patch. It should add two parameter to the xeno_16650 module, allowing to change the register shift and register width. For omap-serial, you want regshift=2 and regwidth=2

diff --git a/ksrc/drivers/serial/16550A_io.h b/ksrc/drivers/serial/16550A_io.h index 92d21a5..bf05498 100644
--- a/ksrc/drivers/serial/16550A_io.h
+++ b/ksrc/drivers/serial/16550A_io.h
@@ -33,6 +33,13 @@ static unsigned long mem[MAX_DEVICES];  static void *mapped_io[MAX_DEVICES];  compat_module_param_array(mem, ulong, MAX_DEVICES, 0400);  MODULE_PARM_DESC(mem, "I/O memory addresses of the serial devices");
+static unsigned regshift = 0;
+module_param(regshift, uint, 0400);
+MODULE_PARM_DESC(regshift, "Register shift to be used"); static 
+unsigned regwidth = 1; module_param(regwidth, uint, 0400); 
+MODULE_PARM_DESC(regwidth, "Register width to be used (1, 2 or 4)");
+
 #endif /* CONFIG_XENO_DRIVERS_16550A_MMIO || CONFIG_XENO_DRIVERS_16550A_ANY */
 
 #ifdef CONFIG_XENO_DRIVERS_16550A_PIO
@@ -164,7 +171,19 @@ rt_16550_reg_in(io_mode_t io_mode, unsigned long base, int off)
 	case MODE_PIO:
 		return inb(base + off);
 	default: /* MODE_MMIO */
-		return readb((void *)base + off);
+		switch (regwidth) {
+		case 1:
+			readb((void *)base + (off << regshift));
+			break;
+		case 2:
+			readw((void *)base + (off << regshift));
+			break;
+		case 4:
+			readl((void *)base + (off << regshift));
+			break;
+		default:
+			BUG();
+		}
 	}
 }
 
@@ -176,7 +195,19 @@ rt_16550_reg_out(io_mode_t io_mode, unsigned long base, int off, u8 val)
 		outb(val, base + off);
 		break;
 	case MODE_MMIO:
-		writeb(val, (void *)base + off);
+		switch (regwidth) {
+		case 1:
+			writeb(val, (void *)base + (off << regshift));
+			break;
+		case 2:
+			writew(val, (void *)base + (off << regshift));
+			break;
+		case 4:
+			writel(val, (void *)base + (off << regshift));
+			break;
+		default:
+			BUG();
+		}
 		break;
 	}
 }


-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 07:51:36PM +0000, Terje Frøysa wrote:
> I have also been searching for a user's manual or some c-code examples utilizing the omap_uart in a more elevated fashion, 
> but I find only novice examples or python scripts.

You are searching the wrong way. omap-serial is a serial driver, and
all serial drivers support the same API. The reference for Linux
serial drivers is here:

http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 08:08:10PM +0000, Terje Frøysa wrote:
> Thanks a lot for you support Gilles,
> 
> I have not have time to do any practical sw work since I received your patch.
> If the patched xeno_16550A does not require further labor in providing UART clocks it is of great interest.

Well, even if you need to enable the clocks, it just means writing a
few bits to a few registers, this is not very complicated, of
course, the layers of generic software around it make it a bit more
complicated than that, but not much more.

As for testing the patch, it should have taken less than 5 minutes.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Thanks a lot for you support Gilles,

I have not have time to do any practical sw work since I received your patch.
If the patched xeno_16550A does not require further labor in providing UART clocks it is of great interest.

I have spent far more hours than estimated for this work so I have to discuss the further strategy with my colleagues.

Best regards
Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 12. november 2014 21:01
To: Terje Frøysa
Cc: Lennart Sorensen; Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Wed, Nov 12, 2014 at 07:51:36PM +0000, Terje Frøysa wrote:
> Hello Len,
> 
> Thanks for your input.
> I have already considered using standard Linux serial drivers.
> The Debian 3.8.13-bone67 is currently supporting the omap_uart driver while the 8250 is parked on a side-track.
> According to R.C.Nelson it is not straight forward to switch driver (see his comments below).
> I don't know if the 8250-serial driver is the same as the 8250-omap 
> you are referring, but if you have succeeded with the (an) 8250-omap driver I am very interested in learning how you did it.

Have you tried the patch I sent? Because without this patch the xeno_16550A can not work on omap: omap serial uses 2 bytes wide reads on 4 bytes wide registers (I think 4 bytes wide reads work just as well, and maybe byte access, but the point is, each registers occupies 4 bytes, so the offsets must be multiplied by 4), whereas xeno_16550A uses byte access to invalid offsets, and cause the abort you observe.

If you start using xeno_16550A, you will not have to care about omap-serial or 8250.

> 
> I have also been searching for a user's manual or some c-code examples 
> utilizing the omap_uart in a more elevated fashion, but I find only 
> novice examples or python scripts.

The xeno_16550A ioctl API is documented here:
http://www.xenomai.org/documentation/xenomai-head/html/api/group__rtserial.html

This is not very complicated.


-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 07:51:36PM +0000, Terje Frøysa wrote:
> Hello Len,
> 
> Thanks for your input.
> I have already considered using standard Linux serial drivers.
> The Debian 3.8.13-bone67 is currently supporting the omap_uart driver while the 8250 is parked on a side-track.
> According to R.C.Nelson it is not straight forward to switch driver (see his comments below).
> I don't know if the 8250-serial driver is the same as the 8250-omap you are referring,
> but if you have succeeded with the (an) 8250-omap driver I am very interested in learning how you did it.

Have you tried the patch I sent? Because without this patch the
xeno_16550A can not work on omap: omap serial uses 2 bytes wide
reads on 4 bytes wide registers (I think 4 bytes wide reads work
just as well, and maybe byte access, but the point is, each
registers occupies 4 bytes, so the offsets must be multiplied by 4),
whereas xeno_16550A uses byte access to invalid offsets, and cause
the abort you observe.

If you start using xeno_16550A, you will not have to care about
omap-serial or 8250.

> 
> I have also been searching for a user's manual or some c-code
> examples utilizing the omap_uart in a more elevated fashion, but I
> find only novice examples or python scripts.

The xeno_16550A ioctl API is documented here:
http://www.xenomai.org/documentation/xenomai-head/html/api/group__rtserial.html

This is not very complicated.


-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Hello Len,

Thanks for your input.
I have already considered using standard Linux serial drivers.
The Debian 3.8.13-bone67 is currently supporting the omap_uart driver while the 8250 is parked on a side-track.
According to R.C.Nelson it is not straight forward to switch driver (see his comments below).
I don't know if the 8250-serial driver is the same as the 8250-omap you are referring,
but if you have succeeded with the (an) 8250-omap driver I am very interested in learning how you did it.

I have also been searching for a user's manual or some c-code examples utilizing the omap_uart in a more elevated fashion, 
but I find only novice examples or python scripts.

Best regards
Terje Froysa

Quoting Robert C Nelson:
"To utilize the 8250 driver, you will also need to change the *.dts file.
Search: http://www.spinics.net/lists/linux-omap/
You'll find all the patches required to make it work on mainline, so you'll also have lots of fun backporting that those.."


-----Original Message-----
From: Lennart Sorensen [mailto:lsorense@csclub.uwaterloo.ca] 
Sent: 12. november 2014 20:17
To: Terje Frøysa
Cc: Gilles Chanteperdrix; Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Wed, Nov 12, 2014 at 02:32:40PM +0000, Terje Frøysa wrote:
> Thanks for your quick reply Gilles,
> 
> - Changing omap-serial driver is not a tempting solution.
> - I'll try out your 8250 suggestion.
> - I have not figured out how to " arrange for the clocks to be started", would that be writing a kernel module that initiates the UART clock systems?
> 
> If not the 8250 suggestion works, I begin to believe that I have to abandon the xeno_1650A driver.
> Do you know anybody that have succeeded in running the xeno_16550A driver under such circumstances?

We just switched from using omap-serial to 8250-omap, and find it much more stable.  I wonder if that would also allow doing what you are trying to do.  I believe it just got merged to go into 3.19, but I applied it with minimal other patched needed to 3.14 and with a few more patches to 3.12.

Being a core 8250 driver would after all likely make doing 16550 stuff easier.

--
Len Sorensen

Re: [Xenomai] xeno_16550A driver install problems.

[Lennart Sorensen]

On Wed, Nov 12, 2014 at 02:32:40PM +0000, Terje Frøysa wrote:
> Thanks for your quick reply Gilles,
> 
> - Changing omap-serial driver is not a tempting solution.
> - I'll try out your 8250 suggestion.
> - I have not figured out how to " arrange for the clocks to be started", would that be writing a kernel module that initiates the UART clock systems?
> 
> If not the 8250 suggestion works, I begin to believe that I have to abandon the xeno_1650A driver.
> Do you know anybody that have succeeded in running the xeno_16550A driver under such circumstances?

We just switched from using omap-serial to 8250-omap, and find it much
more stable.  I wonder if that would also allow doing what you are trying
to do.  I believe it just got merged to go into 3.19, but I applied it
with minimal other patched needed to 3.14 and with a few more patches
to 3.12.

Being a core 8250 driver would after all likely make doing 16550 stuff
easier.

-- 
Len Sorensen

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 02:52:54PM +0000, Terje Frøysa wrote:
> Ok Gilles,
> 
> Thanks!
> 
> Terje

Please try the (completely untested, not even compiled) following
patch. It should add two parameter to the xeno_16650 module,
allowing to change the register shift and register width. For
omap-serial, you want regshift=2 and regwidth=2

diff --git a/ksrc/drivers/serial/16550A_io.h b/ksrc/drivers/serial/16550A_io.h
index 92d21a5..bf05498 100644
--- a/ksrc/drivers/serial/16550A_io.h
+++ b/ksrc/drivers/serial/16550A_io.h
@@ -33,6 +33,13 @@ static unsigned long mem[MAX_DEVICES];
 static void *mapped_io[MAX_DEVICES];
 compat_module_param_array(mem, ulong, MAX_DEVICES, 0400);
 MODULE_PARM_DESC(mem, "I/O memory addresses of the serial devices");
+static unsigned regshift = 0;
+module_param(regshift, uint, 0400);
+MODULE_PARM_DESC(regshift, "Register shift to be used");
+static unsigned regwidth = 1;
+module_param(regwidth, uint, 0400);
+MODULE_PARM_DESC(regwidth, "Register width to be used (1, 2 or 4)");
+
 #endif /* CONFIG_XENO_DRIVERS_16550A_MMIO || CONFIG_XENO_DRIVERS_16550A_ANY */
 
 #ifdef CONFIG_XENO_DRIVERS_16550A_PIO
@@ -164,7 +171,19 @@ rt_16550_reg_in(io_mode_t io_mode, unsigned long base, int off)
 	case MODE_PIO:
 		return inb(base + off);
 	default: /* MODE_MMIO */
-		return readb((void *)base + off);
+		switch (regwidth) {
+		case 1:
+			readb((void *)base + (off << regshift));
+			break;
+		case 2:
+			readw((void *)base + (off << regshift));
+			break;
+		case 4:
+			readl((void *)base + (off << regshift));
+			break;
+		default:
+			BUG();
+		}
 	}
 }
 
@@ -176,7 +195,19 @@ rt_16550_reg_out(io_mode_t io_mode, unsigned long base, int off, u8 val)
 		outb(val, base + off);
 		break;
 	case MODE_MMIO:
-		writeb(val, (void *)base + off);
+		switch (regwidth) {
+		case 1:
+			writeb(val, (void *)base + (off << regshift));
+			break;
+		case 2:
+			writew(val, (void *)base + (off << regshift));
+			break;
+		case 4:
+			writel(val, (void *)base + (off << regshift));
+			break;
+		default:
+			BUG();
+		}
 		break;
 	}
 }


-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Ok Gilles,

Thanks!

Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 12. november 2014 15:51
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Wed, Nov 12, 2014 at 02:32:40PM +0000, Terje Frøysa wrote:
> Thanks for your quick reply Gilles,
> 
> - Changing omap-serial driver is not a tempting solution.
> - I'll try out your 8250 suggestion.
> - I have not figured out how to " arrange for the clocks to be started", would that be writing a kernel module that initiates the UART clock systems?
> 
> If not the 8250 suggestion works, I begin to believe that I have to abandon the xeno_1650A driver.
> Do you know anybody that have succeeded in running the xeno_16550A driver under such circumstances?

I just had a quick look at the omap-serial.c driver and:
- it does not do anything that I can see to enable its clocks
- it does NOT  use byte access but word access, that is, its registers are 16 bits wide.

Unfortunately, as far as I can tell, the xeno_16550A driver only supports byte access. So, if you want it to work, you have to modify the driver to accept a "regshift" parameter applied to all offsets and use the corresponding readw if regshift is 2 or readl if regshift is 4.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 02:32:40PM +0000, Terje Frøysa wrote:
> Thanks for your quick reply Gilles,
> 
> - Changing omap-serial driver is not a tempting solution.
> - I'll try out your 8250 suggestion.
> - I have not figured out how to " arrange for the clocks to be started", would that be writing a kernel module that initiates the UART clock systems?
> 
> If not the 8250 suggestion works, I begin to believe that I have to abandon the xeno_1650A driver.
> Do you know anybody that have succeeded in running the xeno_16550A driver under such circumstances?

I just had a quick look at the omap-serial.c driver and:
- it does not do anything that I can see to enable its clocks
- it does NOT  use byte access but word access, that is, its registers
are 16 bits wide.

Unfortunately, as far as I can tell, the xeno_16550A driver only
supports byte access. So, if you want it to work, you have to modify
the driver to accept a "regshift" parameter applied to all offsets
and use the corresponding readw if regshift is 2 or readl if
regshift is 4.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 02:32:40PM +0000, Terje Frøysa wrote:
> Thanks for your quick reply Gilles,
> 
> - Changing omap-serial driver is not a tempting solution.
> - I'll try out your 8250 suggestion.
> - I have not figured out how to " arrange for the clocks to be started", would that be writing a kernel module that initiates the UART clock systems?

That would be look at omap-serial.c to see how it does it, and do
the same thing in a piece of code which registers a phony DT driver
matching the same string as omap-serial. It does not need to be a
kernel module, it can be put in the kernel itself.

> If not the 8250 suggestion works, I begin to believe that I have
> to abandon the xeno_1650A driver.

As you wish, but any of the three proposition takes one day maximum,
this is not a lot of work.

> Do you know anybody that have succeeded in running the xeno_16550A
> driver under such circumstances?

I have no idea.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Thanks for your quick reply Gilles,

- Changing omap-serial driver is not a tempting solution.
- I'll try out your 8250 suggestion.
- I have not figured out how to " arrange for the clocks to be started", would that be writing a kernel module that initiates the UART clock systems?

If not the 8250 suggestion works, I begin to believe that I have to abandon the xeno_1650A driver.
Do you know anybody that have succeeded in running the xeno_16550A driver under such circumstances?

Best regards
Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 12. november 2014 14:46
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Wed, Nov 12, 2014 at 12:50:20PM +0000, Terje Frøysa wrote:
> I have now carefully checked your suggestions and other suggestions I received from Charles Steinkuehler at beagleboard forum.
> 
> The UARTs appears to be byte accessible and the UART clock system is running:

It makes sense that the clocks are running when the omap_serial driver is running. My question was to know whether they were running without the driver.

> 
> 
> 
> •                    I have checked that the UART dtbo are loaded at boot-time (by uEnv.txt)
> 
> •                    I have built  (and booted) the kernel with the xeno_16550A as loadable module.
> 
> •                    I have checked the functionality of the /dev/ttyOx by running physical loop-back data traffic.
> The sudo cat /proc/tty/driver/OMAP-SERIAL reports the correct amount of traffic and the sent data is echoed correctly in another terminal window.
> 
> •                    I have crawled the /proc/device-tree/ocp/serial* and cannot find any discrepancies.
> 
> 
> 
> Everything seem correct.
> 
> But the UARTs are now occupied by the omap_serial driver.
> 
> According to Xenomai (http://xenomai.org/serial-16550a-driver/) the driver should now be disabled by the setserial command.
> 
> I can't get this command working. It reports the serial port but changing it results in error (regardless of the ttyO -number):
> 
> 
> 
> debian@beaglebone:~$ setserial /dev/ttyO2
> 
> /dev/ttyO2, UART: undefined, Port: 0x0000, IRQ: 74
> 
> 
> 
> debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none
> 
> Cannot set serial info: Invalid argument
> 
> 
> 
> Consequently, I cannot load the xeno_16550A.ko module by modprobe.
> 
> I have browsed the net for the same problem, but have not found relevant subjects.

At first sight, I would say that the omap_serial driver does not implement the necessary support (probably some ioctls), for what setserial is trying to do.

I see several ways out:
- implement the missing support in omap serial so that you can use the "setserial none" command;
- try and use the 8250 driver instead of the omap_serial driver, since the omap serial devices are 8250 compatible, this driver supports the necessary ioctls for the "setserial none" command to work. At some point in time, I know using this serial driver for the kernel console worked, but I do not know if it was by chance (u-boot enables the clock, so the driver does not have to enable it), and if it still works;
- do not enable any uart in the kernel configuration, neither omap_serial, nor 8250, and arrange for the clocks to be started before loading the xeno_16550a driver.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Wed, Nov 12, 2014 at 12:50:20PM +0000, Terje Frøysa wrote:
> I have now carefully checked your suggestions and other suggestions I received from Charles Steinkuehler at beagleboard forum.
> 
> The UARTs appears to be byte accessible and the UART clock system is running:

It makes sense that the clocks are running when the omap_serial driver
is running. My question was to know whether they were running
without the driver.

> 
> 
> 
> •                    I have checked that the UART dtbo are loaded at boot-time (by uEnv.txt)
> 
> •                    I have built  (and booted) the kernel with the xeno_16550A as loadable module.
> 
> •                    I have checked the functionality of the /dev/ttyOx by running physical loop-back data traffic.
> The sudo cat /proc/tty/driver/OMAP-SERIAL reports the correct amount of traffic and the sent data is echoed correctly in another terminal window.
> 
> •                    I have crawled the /proc/device-tree/ocp/serial* and cannot find any discrepancies.
> 
> 
> 
> Everything seem correct.
> 
> But the UARTs are now occupied by the omap_serial driver.
> 
> According to Xenomai (http://xenomai.org/serial-16550a-driver/) the driver should now be disabled by the setserial command.
> 
> I can't get this command working. It reports the serial port but changing it results in error (regardless of the ttyO -number):
> 
> 
> 
> debian@beaglebone:~$ setserial /dev/ttyO2
> 
> /dev/ttyO2, UART: undefined, Port: 0x0000, IRQ: 74
> 
> 
> 
> debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none
> 
> Cannot set serial info: Invalid argument
> 
> 
> 
> Consequently, I cannot load the xeno_16550A.ko module by modprobe.
> 
> I have browsed the net for the same problem, but have not found relevant subjects.

At first sight, I would say that the omap_serial driver does not
implement the necessary support (probably some ioctls), for what
setserial is trying to do.

I see several ways out:
- implement the missing support in omap serial so that you can use
the "setserial none" command;
- try and use the 8250 driver instead of the omap_serial driver,
since the omap serial devices are 8250 compatible, this driver
supports the necessary ioctls for the "setserial none" command to
work. At some point in time, I know using this serial driver for the
kernel console worked, but I do not know if it was by chance (u-boot
enables the clock, so the driver does not have to enable it), and if
it still works;
- do not enable any uart in the kernel configuration, neither
omap_serial, nor 8250, and arrange for the clocks to be started
before loading the xeno_16550a driver.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

I have now carefully checked your suggestions and other suggestions I received from Charles Steinkuehler at beagleboard forum.

The UARTs appears to be byte accessible and the UART clock system is running:



•                    I have checked that the UART dtbo are loaded at boot-time (by uEnv.txt)

•                    I have built  (and booted) the kernel with the xeno_16550A as loadable module.

•                    I have checked the functionality of the /dev/ttyOx by running physical loop-back data traffic.
The sudo cat /proc/tty/driver/OMAP-SERIAL reports the correct amount of traffic and the sent data is echoed correctly in another terminal window.

•                    I have crawled the /proc/device-tree/ocp/serial* and cannot find any discrepancies.



Everything seem correct.

But the UARTs are now occupied by the omap_serial driver.

According to Xenomai (http://xenomai.org/serial-16550a-driver/) the driver should now be disabled by the setserial command.

I can't get this command working. It reports the serial port but changing it results in error (regardless of the ttyO -number):



debian@beaglebone:~$ setserial /dev/ttyO2

/dev/ttyO2, UART: undefined, Port: 0x0000, IRQ: 74



debian@beaglebone:/boot$ sudo setserial /dev/ttyO2 uart none

Cannot set serial info: Invalid argument



Consequently, I cannot load the xeno_16550A.ko module by modprobe.

I have browsed the net for the same problem, but have not found relevant subjects.

There are no shared irq's in my problem (closest subject I found).



Do you have any idea for a solution?



Best regards

Terje Froysa



-----Original Message-----
From: Terje Frøysa
Sent: 11. november 2014 15:12
To: 'Gilles Chanteperdrix'
Cc: Xenomai@xenomai.org
Subject: RE: [Xenomai] xeno_16550A driver install problems.



Good question Gilles,



I have been studying the URL’s below and just copied the recipes as they (especially the last one) indicates that the installation is feasible on a bbb.

When removing one driver (serial8259) and adding another (xeno_16550A) I saw no indications that this would affect the clock support for the UARTS.

Can the lack of clock enable for the interface domain result in the boot-crash?

(The console UART works though, so at least the clock common to the UARTS is enabled).



Terje



URL's:

http://xenomai.org/serial-16550a-driver/

https://www.marshut.net/ihwimw/fail-to-load-the-xeno-16550a-real-time-serial-port-driver-on-beaglebone-black.html





-----Original Message-----

From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org]

Sent: 11. november 2014 15:03

To: Terje Frøysa

Cc: Xenomai@xenomai.org<mailto:Xenomai@xenomai.org>

Subject: Re: [Xenomai] xeno_16550A driver install problems.



On Tue, Nov 11, 2014 at 01:31:33PM +0000, Terje Frøysa wrote:

> Dear forum,

>

> I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work.

>

> I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13.

> Self-developed RTDM driver is working satisfactory.

> But installing the xeno_16550A driver (kernel install) is giving me a headache.

>

> First a fight to find the correct syntax for the uEnv.txt kernel parameters (example show setting of only one parameter):

> cmdline=xeno_16550A.mem=0x48022001,0x48024000,0x481a6000,0x481a8000,0x481aa000 \

>         xeno_16550A.irq=73,74,44,45,46 \

>         xeno_16550A.baud_base=115200,115200,115200,115200,115200 \

>         xeno_16550A.tx_fifo=64,64,64,64,64 \

>         xeno_16550A.start_index=1

> The kernel parameters is correctly stored in the /sys/module/xeno_16550A/parameters.

> The Debian boots as long as the irq=0,0,0,0,0

>

> BUT, at the moment I specify correct irq numbers, the boot-process crashes (see boot-log below).

>

> I have disabled the CONFIG_SERIAL_OMAP without result.

> I have disabled the serial8250 driver that occupies the ttySx UARTS, but the kernel still crashes as soon as the irq is set <> 0.



Another question: usually, each device requires its "interface clock" to be enabled in order to access its registers, is the interface clock for the serial device you want to use enabled?



--

                                                                                    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Thanks Gilles,

I'll check out your suggestions.

Terje

-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 11. november 2014 15:16
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Tue, Nov 11, 2014 at 02:12:25PM +0000, Terje Frøysa wrote:
> Good question Gilles,
> 
> I have been studying the URL’s below and just copied the recipes as 
> they (especially the last one) indicates that the installation is 
> feasible on a bbb. When removing one driver (serial8259) and adding 
> another (xeno_16550A) I saw no indications that this would affect the 
> clock support for the UARTS.

With the move to DT and everything I have no idea if the clocks are enabled by DT, or if there is code in the driver to do that. You would have to check

> Can the lack of clock
> enable for the interface domain result in the boot-crash?

Yes.

> (The console UART works though, so at least the clock common to the 
> UARTS is enabled).

I would believe each UART has its own interface clock. 

Also note that the interface clock is not the only clock needed, you also need the "functional clock" for the device to work correctly.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Tue, Nov 11, 2014 at 02:12:25PM +0000, Terje Frøysa wrote:
> Good question Gilles,
> 
> I have been studying the URL’s below and just copied the recipes
> as they (especially the last one) indicates that the installation
> is feasible on a bbb. When removing one driver (serial8259) and
> adding another (xeno_16550A) I saw no indications that this would
> affect the clock support for the UARTS.

With the move to DT and everything I have no idea if the clocks are
enabled by DT, or if there is code in the driver to do that. You
would have to check

> Can the lack of clock
> enable for the interface domain result in the boot-crash?

Yes.

> (The console UART works though, so at least the clock common to the
> UARTS is enabled).

I would believe each UART has its own interface clock. 

Also note that the interface clock is not the only clock needed, you
also need the "functional clock" for the device to work correctly.

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Good question Gilles,

I have been studying the URL’s below and just copied the recipes as they (especially the last one) indicates that the installation is feasible on a bbb.
When removing one driver (serial8259) and adding another (xeno_16550A) I saw no indications that this would affect the clock support for the UARTS.
Can the lack of clock enable for the interface domain result in the boot-crash?
(The console UART works though, so at least the clock common to the UARTS is enabled).

Terje

URL's:
http://xenomai.org/serial-16550a-driver/
https://www.marshut.net/ihwimw/fail-to-load-the-xeno-16550a-real-time-serial-port-driver-on-beaglebone-black.html


-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 11. november 2014 15:03
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Tue, Nov 11, 2014 at 01:31:33PM +0000, Terje Frøysa wrote:
> Dear forum,
> 
> I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work.
> 
> I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13.
> Self-developed RTDM driver is working satisfactory.
> But installing the xeno_16550A driver (kernel install) is giving me a headache.
> 
> First a fight to find the correct syntax for the uEnv.txt kernel parameters (example show setting of only one parameter):
> cmdline=xeno_16550A.mem=0x48022001,0x48024000,0x481a6000,0x481a8000,0x481aa000 \
>         xeno_16550A.irq=73,74,44,45,46 \
>         xeno_16550A.baud_base=115200,115200,115200,115200,115200 \
>         xeno_16550A.tx_fifo=64,64,64,64,64 \
>         xeno_16550A.start_index=1
> The kernel parameters is correctly stored in the /sys/module/xeno_16550A/parameters.
> The Debian boots as long as the irq=0,0,0,0,0
> 
> BUT, at the moment I specify correct irq numbers, the boot-process crashes (see boot-log below).
> 
> I have disabled the CONFIG_SERIAL_OMAP without result.
> I have disabled the serial8250 driver that occupies the ttySx UARTS, but the kernel still crashes as soon as the irq is set <> 0.

Another question: usually, each device requires its "interface clock" to be enabled in order to access its registers, is the interface clock for the serial device you want to use enabled?

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Thanks for your quick reply Gilles,

The AM335X UARTS are 16550 compliant and as far as I can tell from the TRM, the registers accommodates  byte accesses.
The address map is modulo 4 bytes though, as in a typical 32-bit environment.


-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org] 
Sent: 11. november 2014 14:50
To: Terje Frøysa
Cc: Xenomai@xenomai.org
Subject: Re: [Xenomai] xeno_16550A driver install problems.

On Tue, Nov 11, 2014 at 01:31:33PM +0000, Terje Frøysa wrote:
> Dear forum,
> 
> I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work.
> 
> I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13.
> Self-developed RTDM driver is working satisfactory.
> But installing the xeno_16550A driver (kernel install) is giving me a headache.
> 
> First a fight to find the correct syntax for the uEnv.txt kernel parameters (example show setting of only one parameter):
> cmdline=xeno_16550A.mem=0x48022001,0x48024000,0x481a6000,0x481a8000,0x481aa000 \
>         xeno_16550A.irq=73,74,44,45,46 \
>         xeno_16550A.baud_base=115200,115200,115200,115200,115200 \
>         xeno_16550A.tx_fifo=64,64,64,64,64 \
>         xeno_16550A.start_index=1
> The kernel parameters is correctly stored in the /sys/module/xeno_16550A/parameters.
> The Debian boots as long as the irq=0,0,0,0,0
> 
> BUT, at the moment I specify correct irq numbers, the boot-process crashes (see boot-log below).
> 
> I have disabled the CONFIG_SERIAL_OMAP without result.
> I have disabled the serial8250 driver that occupies the ttySx UARTS, but the kernel still crashes as soon as the irq is set <> 0.
> 

The xeno_16550A driver uses byte access, have you checked the AM33xx TRM to check that this is valid?

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Tue, Nov 11, 2014 at 01:31:33PM +0000, Terje Frøysa wrote:
> Dear forum,
> 
> I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work.
> 
> I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13.
> Self-developed RTDM driver is working satisfactory.
> But installing the xeno_16550A driver (kernel install) is giving me a headache.
> 
> First a fight to find the correct syntax for the uEnv.txt kernel parameters (example show setting of only one parameter):
> cmdline=xeno_16550A.mem=0x48022001,0x48024000,0x481a6000,0x481a8000,0x481aa000 \
>         xeno_16550A.irq=73,74,44,45,46 \
>         xeno_16550A.baud_base=115200,115200,115200,115200,115200 \
>         xeno_16550A.tx_fifo=64,64,64,64,64 \
>         xeno_16550A.start_index=1
> The kernel parameters is correctly stored in the /sys/module/xeno_16550A/parameters.
> The Debian boots as long as the irq=0,0,0,0,0
> 
> BUT, at the moment I specify correct irq numbers, the boot-process crashes (see boot-log below).
> 
> I have disabled the CONFIG_SERIAL_OMAP without result.
> I have disabled the serial8250 driver that occupies the ttySx UARTS, but the kernel still crashes as soon as the irq is set <> 0.

Another question: usually, each device requires its "interface
clock" to be enabled in order to access its registers, is the
interface clock for the serial device you want to use enabled?

-- 
					    Gilles.

Re: [Xenomai] xeno_16550A driver install problems.

[Gilles Chanteperdrix]

On Tue, Nov 11, 2014 at 01:31:33PM +0000, Terje Frøysa wrote:
> Dear forum,
> 
> I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work.
> 
> I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13.
> Self-developed RTDM driver is working satisfactory.
> But installing the xeno_16550A driver (kernel install) is giving me a headache.
> 
> First a fight to find the correct syntax for the uEnv.txt kernel parameters (example show setting of only one parameter):
> cmdline=xeno_16550A.mem=0x48022001,0x48024000,0x481a6000,0x481a8000,0x481aa000 \
>         xeno_16550A.irq=73,74,44,45,46 \
>         xeno_16550A.baud_base=115200,115200,115200,115200,115200 \
>         xeno_16550A.tx_fifo=64,64,64,64,64 \
>         xeno_16550A.start_index=1
> The kernel parameters is correctly stored in the /sys/module/xeno_16550A/parameters.
> The Debian boots as long as the irq=0,0,0,0,0
> 
> BUT, at the moment I specify correct irq numbers, the boot-process crashes (see boot-log below).
> 
> I have disabled the CONFIG_SERIAL_OMAP without result.
> I have disabled the serial8250 driver that occupies the ttySx UARTS, but the kernel still crashes as soon as the irq is set <> 0.
> 

The xeno_16550A driver uses byte access, have you checked the AM33xx
TRM to check that this is valid?

-- 
					    Gilles.

[Xenomai] xeno_16550A driver install problems.

[Terje Frøysa]

Dear forum,

I have struggled for 4 days and I am out of ideas/suggestions on how to make this xeno_16550A driver work.

I have successfully installed the Xenomai 2.6.4 and the Debian 3.8.13.
Self-developed RTDM driver is working satisfactory.
But installing the xeno_16550A driver (kernel install) is giving me a headache.

First a fight to find the correct syntax for the uEnv.txt kernel parameters (example show setting of only one parameter):
cmdline=xeno_16550A.mem=0x48022001,0x48024000,0x481a6000,0x481a8000,0x481aa000 \
        xeno_16550A.irq=73,74,44,45,46 \
        xeno_16550A.baud_base=115200,115200,115200,115200,115200 \
        xeno_16550A.tx_fifo=64,64,64,64,64 \
        xeno_16550A.start_index=1
The kernel parameters is correctly stored in the /sys/module/xeno_16550A/parameters.
The Debian boots as long as the irq=0,0,0,0,0

BUT, at the moment I specify correct irq numbers, the boot-process crashes (see boot-log below).

I have disabled the CONFIG_SERIAL_OMAP without result.
I have disabled the serial8250 driver that occupies the ttySx UARTS, but the kernel still crashes as soon as the irq is set <> 0.


Please advise.
Best regards
Terje Froysa

Boot log:

U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)
reading args
spl_load_image_fat_os: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)

I2C:   ready
DRAM:  512 MiB
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

Net:   <ethaddr> not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
reading uEnv.txt
760 bytes read in 6 ms (123 KiB/s)
gpio: pin 55 (gpio 55) value is 1
Loaded environment from uEnv.txt
Importing environment from mmc ...
Checking if uenvcmd is set ...
gpio: pin 56 (gpio 56) value is 1
Running uenvcmd ...
2428 bytes read in 105 ms (22.5 KiB/s)
5874704 bytes read in 405 ms (13.8 MiB/s)
2866282 bytes read in 274 ms (10 MiB/s)
26098 bytes read in 115 ms (220.7 KiB/s)
Kernel image @ 0x82000000 [ 0x000000 - 0x59a410 ]
## Flattened Device Tree blob at 88000000
   Booting using the fdt blob at 0x88000000
   Loading Ramdisk to 9f36d000, end 9f628c6a ... OK
   Using Device Tree in place at 88000000, end 880095f1

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.8.13-bone67 (debian@beaglebone) (gcc version 4.6.3 (Debian 4.6.3-14) ) #2 SMP Tue Oct 28 15:34:54 UTC 2014
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] AM335X ES2.1 (l2cache sgx neon )
[    0.000000] PERCPU: Embedded 11 pages/cpu @c0e29000 s23616 r8192 d13248 u45056
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792
[    0.000000] Kernel command line: console=tty0 console=ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN capemgr.enable_partno=BB-SPIDEV1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait xeno_16550A.mem=0x48022001,0x48024000,0x481a6000,0x481a8000,0x481aa000 xeno_16550A.irq=73,74,44,45,46 xeno_16550A.baud_base=115200,115200,115200,115200,115200 xeno_16550A.tx_fifo=64,64,64,64,64 xeno_16550A.start_index=1
[    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] __ex_table already sorted, skipping sort
[    0.000000] allocated 1048576 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] Memory: 511MB = 511MB total
[    0.000000] Memory: 504464k/504464k available, 19824k 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 : 0xbf800000 - 0xbfe00000   (   6 MB)
[    0.000000]       .text : 0xc0008000 - 0xc08687f4   (8578 kB)
[    0.000000]       .init : 0xc0869000 - 0xc08aec40   ( 280 kB)
[    0.000000]       .data : 0xc08b0000 - 0xc0938600   ( 546 kB)
[    0.000000]        .bss : 0xc0938600 - 0xc0a18a80   ( 898 kB)
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
[    0.000000] NR_IRQS:0 nr_irqs:0 0
[    0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[    0.000000] Total of 128 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[    0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[    0.000000] I-pipe, 24.000 MHz clocksource
[    0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[    0.000000] Interrupt pipeline (release #4)
[    0.000000] Console: colour dummy device 80x30
[    0.000000] console [tty0] enabled
[    0.001245] Calibrating delay loop... 993.47 BogoMIPS (lpj=969728)
[    0.029185] pid_max: default: 32768 minimum: 301
[    0.029341] Security Framework initialized
[    0.029410] Mount-cache hash table entries: 512
[    0.035691] Initializing cgroup subsys cpuacct
[    0.035740] Initializing cgroup subsys memory
[    0.035790] Initializing cgroup subsys blkio
[    0.035890] CPU: Testing write buffer coherency: ok
[    0.036295] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[    0.036365] Setting up static identity map for 0x80537700 - 0x8053774c
[    0.037425] Brought up 1 CPUs
[    0.037453] SMP: Total of 1 processors activated (993.47 BogoMIPS).
[    0.038411] devtmpfs: initialized
[    0.047740] omap_hwmod: wd_timer2: _wait_target_disable failed
[    0.100030] pinctrl core: initialized pinctrl subsystem
[    0.100189] rstctl core: initialized rstctl subsystem
[    0.100495] regulator-dummy: no parameters
[    0.100809] NET: Registered protocol family 16
[    0.101582] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.107418] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[    0.108025] platform 49000000.edma: alias fck already exists
[    0.108055] platform 49000000.edma: alias fck already exists
[    0.108077] platform 49000000.edma: alias fck already exists
[    0.108822] OMAP GPIO hardware version 0.1
[    0.111521] gpio-rctrl rstctl.4: loaded OK
[    0.114965] No ATAGs?
[    0.114988] hw-breakpoint: debug architecture 0x4 unsupported.
[    0.116336] cpsw.0: No hwaddr in dt. Using d0:39:72:44:f1:35 from efuse
[    0.116375] cpsw.1: No hwaddr in dt. Using d0:39:72:44:f1:37 from efuse
[    0.125804] bio: create slab <bio-0> at 0
[    0.132328] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[    0.132649] vmmcsd_fixed: 3300 mV
[    0.134308] SCSI subsystem initialized
[    0.134584] usbcore: registered new interface driver usbfs
[    0.134712] usbcore: registered new interface driver hub
[    0.134915] usbcore: registered new device driver usb
[    0.136167] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[    0.137231] input: tps65217_pwr_but as /devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/input/input0
[    0.138578] DCDC1: at 1500 mV
[    0.139466] vdd_mpu: 925 <--> 1325 mV at 1325 mV
[    0.140310] vdd_core: 925 <--> 1150 mV at 1125 mV
[    0.141203] LDO1: at 1800 mV
[    0.142034] LDO2: at 3300 mV
[    0.143633] LDO3: 1800 mV
[    0.144519] LDO4: at 3300 mV
[    0.145284] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[    0.145762] omap_i2c 44e0b000.i2c: unable to select pin group
[    0.146273] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz
[    0.147771] omap_i2c 4819c000.i2c: unable to select pin group
[    0.147942] media: Linux media interface: v0.10
[    0.148025] Linux video capture interface: v2.00
[    0.148104] pps_core: LinuxPPS API ver. 1 registered
[    0.148121] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.148633] Advanced Linux Sound Architecture Driver Initialized.
[    0.149257] NetLabel: Initializing
[    0.149281] NetLabel:  domain hash size = 128
[    0.149293] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.149372] NetLabel:  unlabeled traffic allowed by default
[    0.149738] Switching to clocksource ipipe_tsc
[    0.182826] NET: Registered protocol family 2
[    0.183568] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.183665] TCP bind hash table entries: 4096 (order: 4, 81920 bytes)
[    0.183756] TCP: Hash tables configured (established 4096 bind 4096)
[    0.183833] TCP: reno registered
[    0.183854] UDP hash table entries: 256 (order: 1, 12288 bytes)
[    0.183887] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes)
[    0.184139] NET: Registered protocol family 1
[    0.184563] RPC: Registered named UNIX socket transport module.
[    0.184591] RPC: Registered udp transport module.
[    0.184606] RPC: Registered tcp transport module.
[    0.184620] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.184870] Trying to unpack rootfs image as initramfs...
[    0.383130] Freeing initrd memory: 2796K
[    0.383647] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[    0.383937] CPU PMU: attempt to register multiple PMU devices!
[    0.383969] arm-pmu: probe of arm-pmu failed with error -28
[    0.384385] omap2_mbox_probe: platform not supported
[    0.543108] I-pipe: head domain Xenomai registered.
[    0.543167] Xenomai: hal/arm started.
[    0.544239] Xenomai: scheduling class idle registered.
[    0.544288] Xenomai: scheduling class rt registered.
[    0.548687] Xenomai: real-time nucleus v2.6.4 (Jumpin' Out) loaded.
[    0.548709] Xenomai: debug mode enabled.
[    0.549114] Xenomai: starting native API services.
[    0.549136] Xenomai: starting POSIX services.
[    0.549279] Xenomai: starting RTDM services.
[    0.550165] VFS: Disk quotas dquot_6.5.2
[    0.550437] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.551243] NFS: Registering the id_resolver key type
[    0.551331] Key type id_resolver registered
[    0.551348] Key type id_legacy registered
[    0.551612] fuse init (API version 7.20)
[    0.552030] Btrfs loaded
[    0.552252] msgmni has been set to 990
[    0.553965] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[    0.554005] io scheduler noop registered
[    0.554020] io scheduler deadline registered
[    0.554062] io scheduler cfq registered (default)
[    0.555258] tps65217-bl tps65217-bl: no platform data provided
[    0.555301] tps65217-bl: probe of tps65217-bl failed with error -22
[    0.555836] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.557255] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[    0.557562] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 72) is a OMAP UART0
[    1.390704] console [ttyO0] enabled
[    1.395070] [drm] Initialized drm 1.1.0 20060810
[    1.407517] brd: module loaded
[    1.414853] loop: module loaded
[    1.418264] at24 0-0050: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.425515] at24 1-0054: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.432757] at24 1-0055: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.439996] at24 1-0056: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.447224] at24 1-0057: 32768 byte 24c256 EEPROM, writable, 1 bytes/write
[    1.461156] bone-capemgr bone_capemgr.9: Baseboard: 'A335BNLT,00A5,5002BBBK3600'
[    1.468931] bone-capemgr bone_capemgr.9: compatible-baseboard=ti,beaglebone-black
[    1.476804] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMI
[    1.485414] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# BB-BONELT-HDMIN
[    1.524838] bone-capemgr bone_capemgr.9: slot #0: No cape found
[    1.561944] bone-capemgr bone_capemgr.9: slot #1: No cape found
[    1.599053] bone-capemgr bone_capemgr.9: slot #2: No cape found
[    1.636163] bone-capemgr bone_capemgr.9: slot #3: No cape found
[    1.642392] bone-capemgr bone_capemgr.9: slot #4: specific override
[    1.648975] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 4
[    1.656992] bone-capemgr bone_capemgr.9: slot #4: 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[    1.667072] bone-capemgr bone_capemgr.9: slot #5: specific override
[    1.673651] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 5
[    1.681666] bone-capemgr bone_capemgr.9: slot #5: 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[    1.691651] bone-capemgr bone_capemgr.9: slot #6: specific override
[    1.698229] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 6
[    1.706259] bone-capemgr bone_capemgr.9: slot #6: 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[    1.716439] bone-capemgr bone_capemgr.9: enabled_partno part_number 'BB-SPIDEV1', version 'N/A', prio '0'
[    1.726454] bone-capemgr bone_capemgr.9: slot #7: generic override
[    1.732927] bone-capemgr bone_capemgr.9: bone: Using override eeprom data at slot 7
[    1.740954] bone-capemgr bone_capemgr.9: slot #7: 'Override Board Name,00A0,Override Manuf,BB-SPIDEV1'
[    1.750859] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI
[    1.760426] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMIN
[    1.770256] bone-capemgr bone_capemgr.9: loader: before slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.779113] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.787888] bone-capemgr bone_capemgr.9: initialized OK.
[    1.793470] bone-capemgr bone_capemgr.9: loader: before slot-7 BB-SPIDEV1:00A0 (prio 0)
[    1.801855] bone-capemgr bone_capemgr.9: loader: check slot-7 BB-SPIDEV1:00A0 (prio 0)
[    1.811576] OneNAND driver initializing
[    1.816521] usbcore: registered new interface driver cdc_ether
[    1.822707] usbcore: registered new interface driver rndis_host
[    1.828980] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    1.837745] bone-capemgr bone_capemgr.9: loader: after slot-7 BB-SPIDEV1:00A0 (prio 0)
[    1.846100] usbcore: registered new interface driver cdc_ncm
[    1.852059] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'BB-SPIDEV1-00A0.dtbo
[    1.862872] usbcore: registered new interface driver cdc_acm
[    1.868818] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    1.877198] Initializing USB Mass Storage driver...
[    1.882324] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 'BB-SPIDEV1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[    1.896017] usbcore: registered new interface driver usb-storage
[    1.902306] USB Mass Storage support registered.
[    1.907180] bone-capemgr bone_capemgr.9: slot #7: dtbo 'BB-SPIDEV1-00A0.dtbo' loaded; converting to live tree
[    1.917678] musb-hdrc: version 6.0, ?dma?, otg (peripheral+host)
[    1.924153] bone-capemgr bone_capemgr.9: slot #7: #2 overlays
[    1.930439] musb-hdrc musb-hdrc.0.auto: pdev->id = 0
[    1.935692] musb-hdrc musb-hdrc.0.auto: drivers/usb/musb/musb_dsps.c:480 dsps_musb_init: OK
[    1.952723] edma-dma-engine edma-dma-engine.0: allocated channel for 0:45
[    1.960102] musb-hdrc musb-hdrc.0.auto: *** mode=3
[    1.965164] musb-hdrc musb-hdrc.0.auto: *** power=250
[    1.970530] edma-dma-engine edma-dma-engine.0: allocated channel for 0:44
[    1.978250] musb-hdrc musb-hdrc.1.auto: pdev->id = 1
[    1.983492] musb-hdrc musb-hdrc.1.auto: drivers/usb/musb/musb_dsps.c:480 dsps_musb_init: OK
[    1.992868] musb-hdrc musb-hdrc.1.auto: *** mode=1
[    1.997930] musb-hdrc musb-hdrc.1.auto: *** power=250
[    2.003256] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[    2.015872] edma-dma-engine edma-dma-engine.0: allocated channel for 0:43
[    2.023420] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 1
[    2.031758] edma-dma-engine edma-dma-engine.0: allocated channel for 0:42
[    2.039067] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.046187] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.053754] usb usb1: Product: MUSB HDRC host driver
[    2.058955] usb usb1: Manufacturer: Linux 3.8.13-bone67 musb-hcd
[    2.065244] usb usb1: SerialNumber: musb-hdrc.1.auto
[    2.071383] bone-capemgr bone_capemgr.9: slot #7: Applied #2 overlays.
[    2.078290] bone-capemgr bone_capemgr.9: loader: done slot-7 BB-SPIDEV1:00A0 (prio 0)
[    2.086526] bone-capemgr bone_capemgr.9: loader: check slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    2.095918] hub 1-0:1.0: USB hub found
[    2.099989] hub 1-0:1.0: 1 port detected
[    2.105065] mousedev: PS/2 mouse device common for all mice
[    2.110940] bone-capemgr bone_capemgr.9: loader: after slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    2.121437] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[    2.128946] bone-capemgr bone_capemgr.9: slot #4: Requesting firmware 'cape-bone-2g-emmc1.dtbo' for board-name 'Bone-LT-eMMC-2G', version '00A0'
[    2.142548] 44e3e000.rtc: already running
[    2.146962] i2c /dev entries driver
[    2.151666] pps_ldisc: PPS line discipline registered
[    2.157032] bone-capemgr bone_capemgr.9: slot #4: dtbo 'cape-bone-2g-emmc1.dtbo' loaded; converting to live tree
[    2.167801] Driver for 1-wire Dallas network protocol.
[    2.174441] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[    2.181927] bone-capemgr bone_capemgr.9: slot #4: #2 overlays
[    2.188454] device-mapper: ioctl: 4.23.1-ioctl (2012-12-18) initialised: dm-devel@redhat.com
[    2.197958] bone-capemgr bone_capemgr.9: slot #4: Applied #2 overlays.
[    2.204887] bone-capemgr bone_capemgr.9: loader: done slot-4 BB-BONE-EMMC-2G:00A0 (prio 1)
[    2.214366] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed
[    2.221587] omap_hsmmc mmc.5: Failed to get rstctl; not using any
[    2.228267] edma-dma-engine edma-dma-engine.0: allocated channel for 0:25
[    2.235474] edma-dma-engine edma-dma-engine.0: allocated channel for 0:24
[    2.242765] mmc.5 supply vmmc_aux not found, using dummy regulator
[    2.249657] omap_hsmmc mmc.5: pins are not configured from the driver
[    2.282910] gpio-rctrl rstctl.4: gpio_rctrl_request eMMC_RSTn
[    2.289077] omap_hsmmc mmc.11: Got rstctl (gpio:#0 name eMMC_RSTn) label:eMMC_RSTn
[    2.297058] gpio-rctrl rstctl.4: gpio_rctrl_deassert eMMC_RSTn
[    2.303398] edma-dma-engine edma-dma-engine.0: allocated channel for 0:3
[    2.310492] edma-dma-engine edma-dma-engine.0: allocated channel for 0:2
[    2.317939] mmc.11 supply vmmc_aux not found, using dummy regulator
[    2.324604] omap_hsmmc mmc.11: pins are not configured from the driver
[    2.359100] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8
[    2.370780] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22
[    2.378073] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single
[    2.387020] leds-gpio gpio-leds.8: pins are not configured from the driver
[    2.394993] ledtrig-cpu: registered to indicate activity on CPUs
[    2.401596] edma-dma-engine edma-dma-engine.0: allocated channel for 0:36
[    2.408817] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
[    2.416329] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
[    2.422593] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5
[    2.429760] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6
[    2.439868] usbcore: registered new interface driver usbhid
[    2.445789] usbhid: USB HID core driver
[    2.449863] mmc0: host does not support reading read-only switch. assuming write-enable.
[    2.459284] ashmem: initialized
[    2.462780] mmc0: new high speed SDHC card at address 0007
[    2.468807] logger: created 256K log 'log_main'
[    2.474113] mmcblk0: mmc0:0007 SD4GB 3.70 GiB
[    2.479071] logger: created 256K log 'log_events'
[    2.484863] logger: created 256K log 'log_radio'
[    2.489866]  mmcblk0: p1 p2
[    2.493305] logger: created 256K log 'log_system'
[    2.499398] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa022003
[    2.507432] Internal error: : 1028 [#1] SMP THUMB2
[    2.512440] Modules linked in:
[    2.515634] CPU: 0    Not tainted  (3.8.13-bone67 #2)
[    2.520916] PC is at rt_16550_init+0x106/0x198
[    2.525557] LR is at rt_16550_init+0xeb/0x198
[    2.530109] pc : [<c0888616>]    lr : [<c08885fb>]    psr: 60000033
[    2.530109] sp : de871f18  ip : ffffffff  fp : c0a10410
[    2.542086] r10: c0a1034c  r9 : fa022001  r8 : 00000000
[    2.547537] r7 : c0a10370  r6 : dd948380  r5 : 00000001  r4 : 00000000
[    2.554348] r3 : 00000000  r2 : 00000001  r1 : fa022001  r0 : 00000001
[    2.561165] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment kernel
[    2.568974] Control: 50c5387d  Table: 9d95c019  DAC: 00000015
[    2.574970] Process swapper/0 (pid: 1, stack limit = 0xde870240)
[    2.581243] Stack: (0xde871f18 to 0xde872000)
[    2.585788] 1f00:                                                       00000000 c08a7ef8
[    2.594334] 1f20: 00000000 c08939a4 de870000 c0938600 00000000 c0888511 00000115 c08a7efc
[    2.602873] 1f40: 00000000 c000873f 00000006 00000006 c08ef998 c08939a0 c08939a4 00000006
[    2.611418] 1f60: c0893984 c0938600 c08691c9 c08a7efc 00000000 c08696b3 00000006 00000006
[    2.619963] 1f80: c08691c9 c0e2dd00 00000000 c0529d69 00000000 00000000 00000000 00000000
[    2.628499] 1fa0: 00000000 c0529d6f 00000000 c000cb5b 00000000 00000000 00000000 00000000
[    2.637040] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[    2.645581] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 2d0f018e 33384541
[    2.654145] [<c0888616>] (rt_16550_init+0x106/0x198) from [<c000873f>] (do_one_initcall+0x1f/0xf8)
[    2.663517] [<c000873f>] (do_one_initcall+0x1f/0xf8) from [<c08696b3>] (kernel_init_freeable+0xc7/0x15c)
[    2.673428] [<c08696b3>] (kernel_init_freeable+0xc7/0x15c) from [<c0529d6f>] (kernel_init+0x7/0x98)
[    2.682888] [<c0529d6f>] (kernel_init+0x7/0x98) from [<c000cb5b>] (ret_from_fork+0x13/0x38)
[    2.691622] Code: 782b f3bf 8f4f e00f (f899) 3002
[    2.696669] ---[ end trace 5c14e778816ca166 ]---
[    2.701698] usb usb1: usb wakeup-resume
[    2.705798] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[    2.705798]

Smail: Terje Frøysa, SINTEF ICT (Information and Communication Technology), N-7465 Trondheim, Norway.
Email: terje.froysa@sintef.no<blocked::mailto:terje.froysa@sintef.no> <mailto:terje.froysa@sintef.no<blocked::mailto:terje.froysa@sintef.no>>
Phone: +47 930 03603,
Company: Independent R&D, see <http://www.sintef.no/<blocked::http://www.sintef.no/>