Stuck getting DTS working for a new kirkwood board

Stuck getting DTS working for a new kirkwood board

[Dashie]

Hi all,

I'm a very beginner in the DTS and ARM kernel world and trying to get a
DTS working for my new toy.

I've done some tests using mainlineLinux and arcNumber and i remember to
got some things working (PCI-e, Intel eth) but only two drives and no
fan/sensor using arcNumber for "00000b1e    HP t5325 Thin Client       
                        2846".

I've since started to use a DTS, copied the guruplug-server-plus (IIRC)
and done some changes, actually i can get working :
    - temp sensor
    - fan control (off, middle, full)
    - integrated marvell eth
    - the four disks are detected and seems working

But can't get the PCI-e working (and then the intel ethernet), also
sensor path seems to change every reboot (i need to do more tests).
Also i've SATA power reg enabled in the DTS but it doesn't seems to have
any (to be confirmed, the original firmware seems to have the ability to
shutdown unaccessed drives) and i will remove them, anyway i don't know
the GPIO, if any.

I still miss some GPIOS for : Led (r/g) power, func led, the four sata
leds, maybe some triggers for hdds, and the power and func buttons.
(already tried gpio export and out direction and "1" in value, but
nothing blink)
Reset button sends things in /dev/input/input0 so it seems to works.

The current DTS is joined to this mail, i've actually the NAS with me
and can test things. I can provide too : original dmesg (from original
firmware), current dmesg using DTS, lspci -vvv (from kernel with arcNumber).

I'm currently using a stock 3.12.9 debian kernel and doesn't have
anymore access to the original firmware.

Regards,
Dashie.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kirkwood-verbatim-powerbay.dts
Type: audio/vnd.dts
Size: 5323 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140220/e2cc16f6/attachment-0001.dts>

Stuck getting DTS working for a new kirkwood board

[Jason Cooper]

Dashie,

+ other mvebu maintainers.  Please Cc us in the future.

Your timing is fortuitous.  :)  We were just discussing this board and
the few others that haven't been converted yet.

On Thu, Feb 20, 2014 at 10:22:35PM +0100, Dashie wrote:
> Hi all,
> 
> I'm a very beginner in the DTS and ARM kernel world and trying to get a
> DTS working for my new toy.

I was there a couple years ago.  No problem.

> I've done some tests using mainlineLinux and arcNumber and i remember to
> got some things working (PCI-e, Intel eth) but only two drives and no
> fan/sensor using arcNumber for "00000b1e    HP t5325 Thin Client       
>                         2846".

Let's focus on converting this board file to devicetree.  which means
you'll be setting mainlineLinux to true and arcNumber to 0xffffffff.
(means booting via devicetree).  

> I've since started to use a DTS, copied the guruplug-server-plus (IIRC)
> and done some changes, actually i can get working :
>     - temp sensor
>     - fan control (off, middle, full)
>     - integrated marvell eth
>     - the four disks are detected and seems working

That's a good start.

> But can't get the PCI-e working (and then the intel ethernet), also
> sensor path seems to change every reboot (i need to do more tests).
> Also i've SATA power reg enabled in the DTS but it doesn't seems to have
> any (to be confirmed, the original firmware seems to have the ability to
> shutdown unaccessed drives) and i will remove them, anyway i don't know
> the GPIO, if any.
> 
> I still miss some GPIOS for : Led (r/g) power, func led, the four sata
> leds, maybe some triggers for hdds, and the power and func buttons.
> (already tried gpio export and out direction and "1" in value, but
> nothing blink)
> Reset button sends things in /dev/input/input0 so it seems to works.
> 
> The current DTS is joined to this mail, i've actually the NAS with me
> and can test things. I can provide too : original dmesg (from original
> firmware), current dmesg using DTS, lspci -vvv (from kernel with arcNumber).
> 
> I'm currently using a stock 3.12.9 debian kernel and doesn't have
> anymore access to the original firmware.

It would be helpful if you could build a kernel from the git repos.
Have you done that before?

thx,

Jason.

Stuck getting DTS working for a new kirkwood board

[Dashie]

On 02/21/2014 02:34 AM, Jason Cooper wrote:
> Dashie,
>
> + other mvebu maintainers.  Please Cc us in the future.
>
> Your timing is fortuitous.  :)  We were just discussing this board and
> the few others that haven't been converted yet.
That's exactly what motivated me to post ;)

>
> On Thu, Feb 20, 2014 at 10:22:35PM +0100, Dashie wrote:
>> Hi all,
>>
>> I'm a very beginner in the DTS and ARM kernel world and trying to get a
>> DTS working for my new toy.
> I was there a couple years ago.  No problem.
>
>> I've done some tests using mainlineLinux and arcNumber and i remember to
>> got some things working (PCI-e, Intel eth) but only two drives and no
>> fan/sensor using arcNumber for "00000b1e    HP t5325 Thin Client       
>>                         2846".
> Let's focus on converting this board file to devicetree.  which means
> you'll be setting mainlineLinux to true and arcNumber to 0xffffffff.
> (means booting via devicetree).
Actually i've unset mainlineLinux and arcNumber, so the DTB is used.
In fact the t5325 device is the only one which the pci-e works, but it
use old -setup.c files and then i'm lost with that.

>
>> I've since started to use a DTS, copied the guruplug-server-plus (IIRC)
>> and done some changes, actually i can get working :
>>     - temp sensor
>>     - fan control (off, middle, full)
>>     - integrated marvell eth
>>     - the four disks are detected and seems working
> That's a good start.
>
>> But can't get the PCI-e working (and then the intel ethernet), also
>> sensor path seems to change every reboot (i need to do more tests).
>> Also i've SATA power reg enabled in the DTS but it doesn't seems to have
>> any (to be confirmed, the original firmware seems to have the ability to
>> shutdown unaccessed drives) and i will remove them, anyway i don't know
>> the GPIO, if any.
>>
>> I still miss some GPIOS for : Led (r/g) power, func led, the four sata
>> leds, maybe some triggers for hdds, and the power and func buttons.
>> (already tried gpio export and out direction and "1" in value, but
>> nothing blink)
>> Reset button sends things in /dev/input/input0 so it seems to works.
>>
>> The current DTS is joined to this mail, i've actually the NAS with me
>> and can test things. I can provide too : original dmesg (from original
>> firmware), current dmesg using DTS, lspci -vvv (from kernel with arcNumber).
>>
>> I'm currently using a stock 3.12.9 debian kernel and doesn't have
>> anymore access to the original firmware.
> It would be helpful if you could build a kernel from the git repos.
> Have you done that before?
I've built a kernel from the 3.12.9 debian sources but can't get it to
boot, i got nothing after "Uncompressing Linux... done, booting the
kernel.".
I've used the debian's kernel config file, but i can try the
kirkwood_defconfig make target and checking everything is activated (DTB
append, SATA PMP, etc.)
Which git repos i could try to build then ?

>
> thx,
>
> Jason.

Stuck getting DTS working for a new kirkwood board

[Jason Cooper]

On Fri, Feb 21, 2014 at 08:39:08AM +0100, Dashie wrote:
> On 02/21/2014 02:34 AM, Jason Cooper wrote:
> > On Thu, Feb 20, 2014 at 10:22:35PM +0100, Dashie wrote:
> >> I've done some tests using mainlineLinux and arcNumber and i remember to
> >> got some things working (PCI-e, Intel eth) but only two drives and no
> >> fan/sensor using arcNumber for "00000b1e    HP t5325 Thin Client       
> >>                         2846".
> >>
> > Let's focus on converting this board file to devicetree.  which means
> > you'll be setting mainlineLinux to true and arcNumber to 0xffffffff.
> > (means booting via devicetree).
> >
> Actually i've unset mainlineLinux and arcNumber, so the DTB is used.
> In fact the t5325 device is the only one which the pci-e works, but it
> use old -setup.c files and then i'm lost with that.
> 
> >
> >> I've since started to use a DTS, copied the guruplug-server-plus (IIRC)
> >> and done some changes, actually i can get working :
> >>     - temp sensor
> >>     - fan control (off, middle, full)
> >>     - integrated marvell eth
> >>     - the four disks are detected and seems working
> > That's a good start.
> >
> >> But can't get the PCI-e working (and then the intel ethernet), also
> >> sensor path seems to change every reboot (i need to do more tests).
> >> Also i've SATA power reg enabled in the DTS but it doesn't seems to have
> >> any (to be confirmed, the original firmware seems to have the ability to
> >> shutdown unaccessed drives) and i will remove them, anyway i don't know
> >> the GPIO, if any.
> >>
> >> I still miss some GPIOS for : Led (r/g) power, func led, the four sata
> >> leds, maybe some triggers for hdds, and the power and func buttons.
> >> (already tried gpio export and out direction and "1" in value, but
> >> nothing blink)
> >> Reset button sends things in /dev/input/input0 so it seems to works.
> >>
> >> The current DTS is joined to this mail, i've actually the NAS with me
> >> and can test things. I can provide too : original dmesg (from original
> >> firmware), current dmesg using DTS, lspci -vvv (from kernel with arcNumber).
> >>
> >> I'm currently using a stock 3.12.9 debian kernel and doesn't have
> >> anymore access to the original firmware.
> >>
> > It would be helpful if you could build a kernel from the git repos.
> > Have you done that before?
> >
> I've built a kernel from the 3.12.9 debian sources but can't get it to
> boot, i got nothing after "Uncompressing Linux... done, booting the
> kernel.".

Check that you have 'earlyprintk' in your commandline, and that you set

Kernel hacking
  -> Kernel low-level debugging functions
  -> Kernel low-level debugging port (Kernel low-level debugging via 8250 UART)
  -> (0xf1012000) Physical base address of debug UART
  -> (0xfde12000) Virtual base address of debug UART
  -> (2) Register offset shift for the 8250 debug UART
  -> Early printk

Also make sure you have set 'console=ttyS0,115200n8' on the commandline
as well.

> I've used the debian's kernel config file, but i can try the
> kirkwood_defconfig make target and checking everything is activated (DTB
> append, SATA PMP, etc.)
> Which git repos i could try to build then ?

We'll have you work with two repos.  Linus' mainline repo:

$ cd
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ git config --add user.name "first and last"
$ git config --add user.email "dashie at sigpipe.me"

And we'll add our repo as another remote:

$ git remote add mvebu git://git.infradead.org/linux-mvebu.git
$ git remote update --prune mvebu

First you should try v3.14-rc1

$ git checkout -b t5325 v3.14-rc1

Now, add your dts file and commit the result.  Build, boot, report back.

I wold also do kirkwood_defconfig with the above that I mentioned.

hth,

Jason.

Stuck getting DTS working for a new kirkwood board

[Dashie]

On 02/21/2014 04:15 PM, Jason Cooper wrote:
> On Fri, Feb 21, 2014 at 08:39:08AM +0100, Dashie wrote:
>> On 02/21/2014 02:34 AM, Jason Cooper wrote:
>>> On Thu, Feb 20, 2014 at 10:22:35PM +0100, Dashie wrote:
>>>> I've done some tests using mainlineLinux and arcNumber and i remember to
>>>> got some things working (PCI-e, Intel eth) but only two drives and no
>>>> fan/sensor using arcNumber for "00000b1e    HP t5325 Thin Client       
>>>>                         2846".
>>>>
>>> Let's focus on converting this board file to devicetree.  which means
>>> you'll be setting mainlineLinux to true and arcNumber to 0xffffffff.
>>> (means booting via devicetree).
>>>
>> Actually i've unset mainlineLinux and arcNumber, so the DTB is used.
>> In fact the t5325 device is the only one which the pci-e works, but it
>> use old -setup.c files and then i'm lost with that.
>>
>>>> I've since started to use a DTS, copied the guruplug-server-plus (IIRC)
>>>> and done some changes, actually i can get working :
>>>>     - temp sensor
>>>>     - fan control (off, middle, full)
>>>>     - integrated marvell eth
>>>>     - the four disks are detected and seems working
>>> That's a good start.
>>>
>>>> But can't get the PCI-e working (and then the intel ethernet), also
>>>> sensor path seems to change every reboot (i need to do more tests).
>>>> Also i've SATA power reg enabled in the DTS but it doesn't seems to have
>>>> any (to be confirmed, the original firmware seems to have the ability to
>>>> shutdown unaccessed drives) and i will remove them, anyway i don't know
>>>> the GPIO, if any.
>>>>
>>>> I still miss some GPIOS for : Led (r/g) power, func led, the four sata
>>>> leds, maybe some triggers for hdds, and the power and func buttons.
>>>> (already tried gpio export and out direction and "1" in value, but
>>>> nothing blink)
>>>> Reset button sends things in /dev/input/input0 so it seems to works.
>>>>
>>>> The current DTS is joined to this mail, i've actually the NAS with me
>>>> and can test things. I can provide too : original dmesg (from original
>>>> firmware), current dmesg using DTS, lspci -vvv (from kernel with arcNumber).
>>>>
>>>> I'm currently using a stock 3.12.9 debian kernel and doesn't have
>>>> anymore access to the original firmware.
>>>>
>>> It would be helpful if you could build a kernel from the git repos.
>>> Have you done that before?
>>>
>> I've built a kernel from the 3.12.9 debian sources but can't get it to
>> boot, i got nothing after "Uncompressing Linux... done, booting the
>> kernel.".
> Check that you have 'earlyprintk' in your commandline, and that you set
>
> Kernel hacking
>   -> Kernel low-level debugging functions
>   -> Kernel low-level debugging port (Kernel low-level debugging via 8250 UART)
>   -> (0xf1012000) Physical base address of debug UART
>   -> (0xfde12000) Virtual base address of debug UART
>   -> (2) Register offset shift for the 8250 debug UART
>   -> Early printk
>
> Also make sure you have set 'console=ttyS0,115200n8' on the commandline
> as well.
All good, also checked for DTB append.
>> I've used the debian's kernel config file, but i can try the
>> kirkwood_defconfig make target and checking everything is activated (DTB
>> append, SATA PMP, etc.)
>> Which git repos i could try to build then ?
> We'll have you work with two repos.  Linus' mainline repo:
>
> $ cd
> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> $ cd linux
> $ git config --add user.name "first and last"
> $ git config --add user.email "dashie at sigpipe.me"
>
> And we'll add our repo as another remote:
>
> $ git remote add mvebu git://git.infradead.org/linux-mvebu.git
> $ git remote update --prune mvebu
>
> First you should try v3.14-rc1
>
> $ git checkout -b t5325 v3.14-rc1
>
> Now, add your dts file and commit the result.  Build, boot, report back.
>
> I wold also do kirkwood_defconfig with the above that I mentioned.
Well, with kirkwood_defconfig it doesn't find the SATA PHY and panic.
So i've used my debian config, make oldconfig, built and ... the toy is
booting.

Since i've checkout the mvebu branch, i think it's better to start from
kirkwood_defconfig and activate things that starting from the debian
config, right ?

Anyway, going to play with an initrd to get rootfs on usb working.

I've attached the current dmesg to this mail.
>
> hth,
>
> Jason.
Thanks,
Dashie.
-------------- next part --------------
Bytes transferred = 8833880 (86cb58 hex)
## Booting image at 02000000 ...
   Image Name:   3.x-git-t5325__4
   Created:      2014-02-21  19:06:59 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1996116 Bytes =  1.9 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 03000000 ...
   Image Name:   initramfs--3.12-1-kirkwood
   Created:      2014-02-08  17:55:26 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    8833816 Bytes =  8.4 MB
   Load Address: 03000000
   Entry Point:  03000000
   Verifying Checksum ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.14.0-rc1+ (dashie at soarin) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-33) ) #2 Fri Feb 21 20:01:33 CET 2014
[    0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine model: Verbatim PowerBay
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] Memory policy: Data cache writeback
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
[    0.000000] Kernel command line: mtdparts=orion_nand:0x000e0000 at 0x00000000(u-boot)ro,0x1d73c0 at 0x000e0000(uImage),0x86cb58 at 0x2b73c0(uInitrd),- at 0xb23f18(rootfs) console=ttyS0,115200n8 verbose mem=256M root=/dev/ram ip=off earlyprintk
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] allocated 524288 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.000000] Memory: 244644K/262144K available (3774K kernel code, 319K rwdata, 1308K rodata, 194K init, 416K bss, 17500K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc04feb4c   (5083 kB)
[    0.000000]       .init : 0xc04ff000 - 0xc052f884   ( 195 kB)
[    0.000000]       .data : 0xc0530000 - 0xc057fc40   ( 320 kB)
[    0.000000]        .bss : 0xc057fc40 - 0xc05e7e00   ( 417 kB)
[    0.000000] NR_IRQS:114
[    0.000032] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474836475ns
[    0.000292] Console: colour dummy device 80x30
[    0.004856] Calibrating delay loop... 1191.93 BogoMIPS (lpj=2383872)
[    0.034901] pid_max: default: 32768 minimum: 301
[    0.039689] Security Framework initialized
[    0.043884] Yama: becoming mindful.
[    0.047521] Mount-cache hash table entries: 512
[    0.054163] Initializing cgroup subsys memory
[    0.058651] Initializing cgroup subsys devices
[    0.063187] Initializing cgroup subsys freezer
[    0.067718] Initializing cgroup subsys net_cls
[    0.072251] Initializing cgroup subsys blkio
[    0.076607] Initializing cgroup subsys perf_event
[    0.081460] CPU: Testing write buffer coherency: ok
[    0.086766] Setting up static identity map for 0x391050 - 0x39108c
[    0.094569] devtmpfs: initialized
[    0.099398] pinctrl core: initialized pinctrl subsystem
[    0.105136] regulator-dummy: no parameters
[    0.109624] NET: Registered protocol family 16
[    0.114550] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.122142] cpuidle: using governor ladder
[    0.126348] cpuidle: using governor menu
[    0.130423] Kirkwood: MV88F6281-A0.
[    0.134094] Feroceon L2: Enabling L2
[    0.137792] Feroceon L2: Cache support initialised.
[    0.143015] [Firmware Info]: /ocp at f1000000/ethernet-controller at 72000/ethernet0-port at 0: local-mac-address is not set
[    0.157058] No ATAGs?
[    0.161742] bio: create slab <bio-0> at 0
[    0.166615] vgaarb: loaded
[    0.170163] Switched to clocksource orion_clocksource
[    0.194396] NET: Registered protocol family 2
[    0.199456] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[    0.206530] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[    0.212970] TCP: Hash tables configured (established 2048 bind 2048)
[    0.219480] TCP: reno registered
[    0.222797] UDP hash table entries: 256 (order: 0, 4096 bytes)
[    0.228717] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[    0.235236] NET: Registered protocol family 1
[    0.239904] Unpacking initramfs...
[    0.997881] Freeing initrd memory: 8620K (c3001000 - c386c000)
[    1.003873] NetWinder Floating Point Emulator V0.97 (double precision)
[    1.011337] futex hash table entries: 256 (order: -1, 2048 bytes)
[    1.017675] audit: initializing netlink subsys (disabled)
[    1.023212] audit: type=2000 audit(0.992:1): initialized
[    1.135788] VFS: Disk quotas dquot_6.5.2
[    1.139863] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    1.146526] jffs2: version 2.2. (NAND) (SUMMARY)  ? 2001-2006 Red Hat, Inc.
[    1.153837] msgmni has been set to 494
[    1.159497] alg: No test for stdrng (krng)
[    1.163758] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
[    1.171331] io scheduler noop registered
[    1.175337] io scheduler deadline registered
[    1.179712] io scheduler cfq registered (default)
[    1.185555] kirkwood-pinctrl f1010000.pinctrl: registered pinctrl driver
[    1.192627] mv_xor f1060800.xor: Marvell shared XOR driver
[    1.218225] mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
[    1.242213] mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
[    1.247834] mv_xor f1060900.xor: Marvell shared XOR driver
[    1.270214] mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
[    1.294213] mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
[    1.300053] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    1.307381] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33, base_baud = 12500000) is a 16550A
[    1.316425] console [ttyS0] enabled
[    1.316425] console [ttyS0] enabled
[    1.323522] bootconsole [earlycon0] disabled
[    1.323522] bootconsole [earlycon0] disabled
[    1.333526] mousedev: PS/2 mouse device common for all mice
[    2.342208] rtc-mv f1010300.rtc: internal RTC not ticking
[    2.347735] i2c /dev entries driver
[    2.357244] TCP: cubic registered
[    2.360651] NET: Registered protocol family 10
[    2.365781] mip6: Mobile IPv6
[    2.368793] NET: Registered protocol family 17
[    2.373281] mpls_gso: MPLS GSO support
[    2.377664] registered taskstats version 1
[    2.382654] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[    2.390450] Freeing unused kernel memory: 192K (c04ff000 - c052f000)
Loading, please wait...
[    2.462758] systemd-udevd[49]: starting version 204
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Waiting for root file system ... done.
Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/disk/by-uuid/2922a347-7209-4983-8038-eae31b911dfa does not exist.  Dropping to a shell!
modprobe: can't change directory to '3.14.0-rc1+': No such file or directory
modprobe: can't change directory to '3.14.0-rc1+': No such file or directory
modprobe: can't change directory to '3.14.0-rc1+': No such file or directory
modprobe: can't change directory to '3.14.0-rc1+': No such file or directory
modprobe: can't change directory to '3.14.0-rc1+': No such file or directory
modprobe: can't change directory to '3.14.0-rc1+': No such file or directory
modprobe: can't change directory to '3.14.0-rc1+': No such file or directory
modprobe: can't change directory to '3.14.0-rc1+': No such file or directory


BusyBox v1.21.1 (Debian 1:1.21.0-1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs) 

Stuck getting DTS working for a new kirkwood board

[Jason Cooper]

On Fri, Feb 21, 2014 at 08:21:11PM +0100, Dashie wrote:
> On 02/21/2014 04:15 PM, Jason Cooper wrote:
> > On Fri, Feb 21, 2014 at 08:39:08AM +0100, Dashie wrote:
> >> On 02/21/2014 02:34 AM, Jason Cooper wrote:
> >>> On Thu, Feb 20, 2014 at 10:22:35PM +0100, Dashie wrote:
> >>>> I've done some tests using mainlineLinux and arcNumber and i remember to
> >>>> got some things working (PCI-e, Intel eth) but only two drives and no
> >>>> fan/sensor using arcNumber for "00000b1e    HP t5325 Thin Client       
> >>>>                         2846".
> >>>>
> >>> Let's focus on converting this board file to devicetree.  which means
> >>> you'll be setting mainlineLinux to true and arcNumber to 0xffffffff.
> >>> (means booting via devicetree).
> >>>
> >> Actually i've unset mainlineLinux and arcNumber, so the DTB is used.
> >> In fact the t5325 device is the only one which the pci-e works, but it
> >> use old -setup.c files and then i'm lost with that.
> >>
> >>>> I've since started to use a DTS, copied the guruplug-server-plus (IIRC)
> >>>> and done some changes, actually i can get working :
> >>>>     - temp sensor
> >>>>     - fan control (off, middle, full)
> >>>>     - integrated marvell eth
> >>>>     - the four disks are detected and seems working
> >>> That's a good start.
> >>>
> >>>> But can't get the PCI-e working (and then the intel ethernet), also
> >>>> sensor path seems to change every reboot (i need to do more tests).
> >>>> Also i've SATA power reg enabled in the DTS but it doesn't seems to have
> >>>> any (to be confirmed, the original firmware seems to have the ability to
> >>>> shutdown unaccessed drives) and i will remove them, anyway i don't know
> >>>> the GPIO, if any.
> >>>>
> >>>> I still miss some GPIOS for : Led (r/g) power, func led, the four sata
> >>>> leds, maybe some triggers for hdds, and the power and func buttons.
> >>>> (already tried gpio export and out direction and "1" in value, but
> >>>> nothing blink)
> >>>> Reset button sends things in /dev/input/input0 so it seems to works.
> >>>>
> >>>> The current DTS is joined to this mail, i've actually the NAS with me
> >>>> and can test things. I can provide too : original dmesg (from original
> >>>> firmware), current dmesg using DTS, lspci -vvv (from kernel with arcNumber).
> >>>>
> >>>> I'm currently using a stock 3.12.9 debian kernel and doesn't have
> >>>> anymore access to the original firmware.
> >>>>
> >>> It would be helpful if you could build a kernel from the git repos.
> >>> Have you done that before?
> >>>
> >> I've built a kernel from the 3.12.9 debian sources but can't get it to
> >> boot, i got nothing after "Uncompressing Linux... done, booting the
> >> kernel.".
> > Check that you have 'earlyprintk' in your commandline, and that you set
> >
> > Kernel hacking
> >   -> Kernel low-level debugging functions
> >   -> Kernel low-level debugging port (Kernel low-level debugging via 8250 UART)
> >   -> (0xf1012000) Physical base address of debug UART
> >   -> (0xfde12000) Virtual base address of debug UART
> >   -> (2) Register offset shift for the 8250 debug UART
> >   -> Early printk
> >
> > Also make sure you have set 'console=ttyS0,115200n8' on the commandline
> > as well.
> All good, also checked for DTB append.
> >> I've used the debian's kernel config file, but i can try the
> >> kirkwood_defconfig make target and checking everything is activated (DTB
> >> append, SATA PMP, etc.)
> >> Which git repos i could try to build then ?
> > We'll have you work with two repos.  Linus' mainline repo:
> >
> > $ cd
> > $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > $ cd linux
> > $ git config --add user.name "first and last"
> > $ git config --add user.email "dashie at sigpipe.me"
> >
> > And we'll add our repo as another remote:
> >
> > $ git remote add mvebu git://git.infradead.org/linux-mvebu.git
> > $ git remote update --prune mvebu
> >
> > First you should try v3.14-rc1
> >
> > $ git checkout -b t5325 v3.14-rc1
> >
> > Now, add your dts file and commit the result.  Build, boot, report back.
> >
> > I wold also do kirkwood_defconfig with the above that I mentioned.
> > 
> Well, with kirkwood_defconfig it doesn't find the SATA PHY and panic.
> So i've used my debian config, make oldconfig, built and ... the toy is
> booting.

Yes, this is a known issue.  You worked around it by enabling generic
phy support (it's most likely in the other configs).

> Since i've checkout the mvebu branch,

?  I'm confused.  You should be on v3.14-rc1 with your dts file change
on top.

> i think it's better to start from kirkwood_defconfig and activate
> things that starting from the debian config, right ?

Yes, we use kirkwood_defconfig for testing here so it should be a good,
up-to-date minimal config for starting from (with the exception of the
above bug).  Debian's config, by necessity is much bigger.

> Anyway, going to play with an initrd to get rootfs on usb working.

Looks like you just need to add some modules or compile them in.

thx,

Jason.

Stuck getting DTS working for a new kirkwood board

[Dashie]

On 02/21/2014 09:08 PM, Jason Cooper wrote:
> On Fri, Feb 21, 2014 at 08:21:11PM +0100, Dashie wrote:
>> On 02/21/2014 04:15 PM, Jason Cooper wrote:
>>> On Fri, Feb 21, 2014 at 08:39:08AM +0100, Dashie wrote:
>>>> On 02/21/2014 02:34 AM, Jason Cooper wrote:
>>>>> On Thu, Feb 20, 2014 at 10:22:35PM +0100, Dashie wrote:
>>>>>> I've done some tests using mainlineLinux and arcNumber and i remember to
>>>>>> got some things working (PCI-e, Intel eth) but only two drives and no
>>>>>> fan/sensor using arcNumber for "00000b1e    HP t5325 Thin Client       
>>>>>>                         2846".
>>>>>>
>>>>> Let's focus on converting this board file to devicetree.  which means
>>>>> you'll be setting mainlineLinux to true and arcNumber to 0xffffffff.
>>>>> (means booting via devicetree).
>>>>>
>>>> Actually i've unset mainlineLinux and arcNumber, so the DTB is used.
>>>> In fact the t5325 device is the only one which the pci-e works, but it
>>>> use old -setup.c files and then i'm lost with that.
>>>>
>>>>>> I've since started to use a DTS, copied the guruplug-server-plus (IIRC)
>>>>>> and done some changes, actually i can get working :
>>>>>>     - temp sensor
>>>>>>     - fan control (off, middle, full)
>>>>>>     - integrated marvell eth
>>>>>>     - the four disks are detected and seems working
>>>>> That's a good start.
>>>>>
>>>>>> But can't get the PCI-e working (and then the intel ethernet), also
>>>>>> sensor path seems to change every reboot (i need to do more tests).
>>>>>> Also i've SATA power reg enabled in the DTS but it doesn't seems to have
>>>>>> any (to be confirmed, the original firmware seems to have the ability to
>>>>>> shutdown unaccessed drives) and i will remove them, anyway i don't know
>>>>>> the GPIO, if any.
>>>>>>
>>>>>> I still miss some GPIOS for : Led (r/g) power, func led, the four sata
>>>>>> leds, maybe some triggers for hdds, and the power and func buttons.
>>>>>> (already tried gpio export and out direction and "1" in value, but
>>>>>> nothing blink)
>>>>>> Reset button sends things in /dev/input/input0 so it seems to works.
>>>>>>
>>>>>> The current DTS is joined to this mail, i've actually the NAS with me
>>>>>> and can test things. I can provide too : original dmesg (from original
>>>>>> firmware), current dmesg using DTS, lspci -vvv (from kernel with arcNumber).
>>>>>>
>>>>>> I'm currently using a stock 3.12.9 debian kernel and doesn't have
>>>>>> anymore access to the original firmware.
>>>>>>
>>>>> It would be helpful if you could build a kernel from the git repos.
>>>>> Have you done that before?
>>>>>
>>>> I've built a kernel from the 3.12.9 debian sources but can't get it to
>>>> boot, i got nothing after "Uncompressing Linux... done, booting the
>>>> kernel.".
>>> Check that you have 'earlyprintk' in your commandline, and that you set
>>>
>>> Kernel hacking
>>>   -> Kernel low-level debugging functions
>>>   -> Kernel low-level debugging port (Kernel low-level debugging via 8250 UART)
>>>   -> (0xf1012000) Physical base address of debug UART
>>>   -> (0xfde12000) Virtual base address of debug UART
>>>   -> (2) Register offset shift for the 8250 debug UART
>>>   -> Early printk
>>>
>>> Also make sure you have set 'console=ttyS0,115200n8' on the commandline
>>> as well.
>> All good, also checked for DTB append.
>>>> I've used the debian's kernel config file, but i can try the
>>>> kirkwood_defconfig make target and checking everything is activated (DTB
>>>> append, SATA PMP, etc.)
>>>> Which git repos i could try to build then ?
>>> We'll have you work with two repos.  Linus' mainline repo:
>>>
>>> $ cd
>>> $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>>> $ cd linux
>>> $ git config --add user.name "first and last"
>>> $ git config --add user.email "dashie at sigpipe.me"
>>>
>>> And we'll add our repo as another remote:
>>>
>>> $ git remote add mvebu git://git.infradead.org/linux-mvebu.git
>>> $ git remote update --prune mvebu
>>>
>>> First you should try v3.14-rc1
>>>
>>> $ git checkout -b t5325 v3.14-rc1
>>>
>>> Now, add your dts file and commit the result.  Build, boot, report back.
>>>
>>> I wold also do kirkwood_defconfig with the above that I mentioned.
>>>
>> Well, with kirkwood_defconfig it doesn't find the SATA PHY and panic.
>> So i've used my debian config, make oldconfig, built and ... the toy is
>> booting.
> Yes, this is a known issue.  You worked around it by enabling generic
> phy support (it's most likely in the other configs).
>
>> Since i've checkout the mvebu branch,
> ?  I'm confused.  You should be on v3.14-rc1 with your dts file change
> on top.
Err yes exactly.
>> i think it's better to start from kirkwood_defconfig and activate
>> things that starting from the debian config, right ?
> Yes, we use kirkwood_defconfig for testing here so it should be a good,
> up-to-date minimal config for starting from (with the exception of the
> above bug).  Debian's config, by necessity is much bigger.
>
>> Anyway, going to play with an initrd to get rootfs on usb working.
> Looks like you just need to add some modules or compile them in.
>
> thx,
>
> Jason.
I restarted from the defconfig kirkwood, activated some builtin stuff
(USB / e1000) and it boots perfectly.
Sata and fan doesn't seems to be detected, but i got PCI-e with intel
eth detected this time.
'will see tomorrow about SATA part.

Thanks,
Dashie.

-------------- next part --------------
Bytes transferred = 3406619 (33fb1b hex)
## Booting image at 02000000 ...
   Image Name:   3.x-git-t5325__5
   Created:      2014-02-21  21:54:13 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3406555 Bytes =  3.2 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.14.0-rc1-dirty (dashie at soarin) (gcc version 4.8.1 (Sourcery CodeBench Lite 2013.11-33) ) #8 PREEMPT Fri Feb 21 22:49:34 CET 2014
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine model: Verbatim PowerBay
bootconsole [earlycon0] enabled
Memory policy: Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: mtdparts=orion_nand:0x000e0000 at 0x00000000(u-boot)ro,0x1d73c0 at 0x000e0000(uImage),0x86cb58 at 0x2b73c0(uInitrd),- at 0xb23f18(rootfs) console=ttyS0,115200n8 verbose mem=256M root=/dev/sda2 rootdelay=8 ip=off earlyprintk
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 252524K/262144K available (4903K kernel code, 253K rwdata, 1320K rodata, 153K init, 630K bss, 9620K reserved, 0K highmem)
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
    lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc061c1d8   (6225 kB)
      .init : 0xc061d000 - 0xc064377c   ( 154 kB)
      .data : 0xc0644000 - 0xc06835a0   ( 254 kB)
       .bss : 0xc06835ac - 0xc0721144   ( 631 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:114
sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474836475ns
Console: colour dummy device 80x30
Calibrating delay loop... 1191.11 BogoMIPS (lpj=5955584)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x4ab1a0 - 0x4ab1f8
devtmpfs: initialized
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor ladder
cpuidle: using governor menu
Kirkwood: MV88F6281-A0.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
[Firmware Info]: /ocp at f1000000/ethernet-controller at 72000/ethernet0-port at 0: local-mac-address is not set
bio: create slab <bio-0> at 0
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
cfg80211: Calling CRDA to update world regulatory domain
Switched to clocksource orion_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 1, 8192 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
futex hash table entries: 256 (order: -1, 2048 bytes)
jffs2: version 2.2. (NAND) ? 2001-2006 Red Hat, Inc.
msgmni has been set to 493
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
kirkwood-pinctrl f1010000.pinctrl: registered pinctrl driver
mvebu-pcie pcie-controller.1: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x1000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xf0000000]
pci_bus 0000:00: root bus resource [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
PCI: bus1: Fast back to back transfers disabled
pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xe00fffff]
pci 0000:00:01.0: BAR 7: assigned [io  0x10000-0x10fff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xe0000000-0xe001ffff]
pci 0000:01:00.0: BAR 3: assigned [mem 0xe0020000-0xe0023fff]
pci 0000:01:00.0: BAR 2: assigned [io  0x10000-0x1001f]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [io  0x10000-0x10fff]
pci 0000:00:01.0:   bridge window [mem 0xe0000000-0xe00fffff]
mv_xor f1060800.xor: Marvell shared XOR driver
mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
mv_xor f1060900.xor: Marvell shared XOR driver
mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33, base_baud = 12500000) is a 16550A
console [ttyS0] enabled
console [ttyS0] enabled
bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
loop: module loaded
e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
e1000e: Copyright(c) 1999 - 2013 Intel Corporation.
PCI: enabling device 0000:00:01.0 (0140 -> 0143)
e1000e 0000:01:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:01:00.0 eth0: registered PHC clock
e1000e 0000:01:00.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:a0:b0:a1:01:79
e1000e 0000:01:00.0 eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:01:00.0 eth0: MAC: 3, PHY: 8, PBA No: FFFFFF-0FF
libphy: orion_mdio_bus: probed
mv643xx_eth: MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth_port mv643xx_eth_port.0 eth1: port 0 with MAC address 00:50:43:3c:3b:5d
libertas_sdio: Libertas SDIO driver
libertas_sdio: Copyright Pierre Ossman
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-orion: EHCI orion driver
orion-ehci f1050000.ehci: EHCI Host Controller
orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
orion-ehci f1050000.ehci: irq 24, io mem 0xf1050000
orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
mousedev: PS/2 mouse device common for all mice
usb 1-1: new high-speed USB device number 2 using orion-ehci
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 2 ports detected
usb 1-1.2: new high-speed USB device number 3 using orion-ehci
usb-storage 1-1.2:1.0: USB Mass Storage device detected
scsi0 : usb-storage 1-1.2:1.0
rtc-mv f1010300.rtc: internal RTC not ticking
i2c /dev entries driver
lm75 0-0049: hwmon0: sensor 'lm75'
orion_wdt: Initial timeout 21 sec
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
oprofile: no performance counters
oprofile: using timer interrupt.
TCP: cubic registered
NET: Registered protocol family 17
lib80211: common routines for IEEE802.11 drivers
input: gpio_keys.3 as /devices/gpio_keys.3/input/input0
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Waiting 8 sec before mounting root device...
scsi 0:0:0:0: Direct-Access     SanDisk  Cruzer Orbit     1.27 PQ: 0 ANSI: 6
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 15633408 512-byte logical blocks: (8.00 GB/7.45 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 < sda5 >
sd 0:0:0:0: [sda] Attached SCSI disk
EXT3-fs (sda2): error: couldn't mount because of unsupported optional features (240)
EXT2-fs (sda2): error: couldn't mount because of unsupported optional features (240)
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:2.
devtmpfs: mounted
Freeing unused kernel memory: 152K (c061d000 - c0643000)
Mount failed for selinuxfs on /sys/fs/selinux:  No such file or directory
INIT: version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.
findfs: unable to resolve 'UUID=2922a347-7209-4983-8038-eae31b911dfa'
[....] Starting the hotplug events dispatcher: udevdsystemd-udevd[771]: starting version 204
. ok 
[....] Synthesizing the initial hotplug events...systemd-udevd[795]: renamed network interface eth1 to rename3
done.
[....] Waiting for /dev to be fully populated...systemd-udevd[792]: renamed network interface eth0 to eth2
systemd-udevd[795]: renamed network interface rename3 to eth0
done.
[....] Activating swap...Adding 383996k swap on /dev/sda5.  Priority:-1 extents:1 across:383996k 
done.
EXT4-fs (sda2): re-mounted. Opts: (null)
[....] Checking root file system...fsck from util-linux 2.20.1
/dev/sda2: clean, 108733/449680 files, 582150/1795328 blocks
done.
random: nonblocking pool is initialized
EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[ ok ] Cleaning up temporary files... /tmp.
[ ok ] Activating lvm and md swap...done.
[....] Checking file systems...fsck from util-linux 2.20.1
/dev/sda1: clean, 17/124496 files, 27791/248832 blocks
done.
[ ok ] Mounting local filesystems...done.
[ ok ] Activating swapfile swap...done.
[ ok ] Cleaning up temporary files....
[ ok ] Setting kernel variables ...done.
[ ok ] Configuring network interfaces...done.
[....] Starting rpcbind daemon...rpcbind: cannot create socket for udp6
rpcbind: cannot create socket for tcp6
. ok 
[ ok ] Starting NFS common utilities: statd idmapd.
[ ok ] Cleaning up temporary files....
[ ok ] Setting sensors limits.
[ ok ] Starting qcontrol daemon: qcontrol.
[ ok ] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.
INIT: Entering runlevel: 2
[info] Using makefile-style concurrent boot in runlevel 2.
[ ok ] Starting fan speed regulator: fancontrol.
[ ok ] Starting NFS common utilities: statd idmapd.
[warn] Not starting NFS kernel daemon: no exports. ... (warning).
mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 100 Mb/s, full duplex, flow control disabled
[ ok ] Starting NetBIOS name server: nmbd.
[ ok ] Starting enhanced syslogd: rsyslogd.
[ ok ] Starting deferred execution scheduler: atd.
[ ok ] Starting periodic command scheduler: cron.
[ ok ] Starting system message bus: dbus.
[ ok ] Starting MTA: exim4.
ALERT: exim paniclog /var/log/exim4/paniclog has non-zero size, mail system possibly broken
[ ok ] Starting sensor daemon: sensord.
[ ok ] Starting SMB/CIFS daemon: smbd.
[ ok ] Starting OpenBSD Secure Shell server: sshd.
[ ok ] Starting the Winbind daemon: winbind.
[info] System boot completed.
Error connecting to socket: No such file or directory

Debian GNU/Linux jessie/sid debian ttyS0

debian login: root
Password: 
Last login: Fri Feb 21 22:50:56 CET 2014 on ttyS0
Linux debian 3.14.0-rc1-dirty #8 PREEMPT Fri Feb 21 22:49:34 CET 2014 armv5tel

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
ifroot at debian:~# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:50:43:3c:3b:5d  
          inet addr:192.168.1.137  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:73 errors:0 dropped:0 overruns:0 frame:0
          TX packets:93 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7219 (7.0 KiB)  TX bytes:9313 (9.0 KiB)
          Interrupt:31 

eth2      Link encap:Ethernet  HWaddr 00:a0:b0:a1:01:79  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:25 Memory:e0000000-e0020000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:100 (100.0 B)  TX bytes:100 (100.0 B)

root at debian:~#  lspci
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

Stuck getting DTS working for a new kirkwood board

[Andrew Lunn]

Hi Dashie

A few more tips for you

> Kernel command line: mtdparts=orion_nand:0x000e0000 at 0x00000000(u-boot)ro,0x1d73c0 at 0x000e0000(uImage),0x86cb58 at 0x2b73c0(uInitrd),- at 0xb23f18(rootfs) console=ttyS0,115200n8 verbose mem=256M root=/dev/sda2 rootdelay=8 ip=off earlyprintk

You seem to be missing nand in your DT. You should be able to work out
the partition sizes from the information above.

> rtc-mv f1010300.rtc: internal RTC not ticking

This suggests there is a different RTC on the board than the built in
one. It is probably on i2c. You can probably get the address using the
i2cdetect program. If you have boot logs from the vendor kernel it
will probably tell you what device it is.

     Andrew

Stuck getting DTS working for a new kirkwood board

[Dashie]

On 02/21/2014 11:12 PM, Andrew Lunn wrote:
> Hi Dashie
>
> A few more tips for you
Hi, thanks.
>> Kernel command line: mtdparts=orion_nand:0x000e0000 at 0x00000000(u-boot)ro,0x1d73c0 at 0x000e0000(uImage),0x86cb58 at 0x2b73c0(uInitrd),- at 0xb23f18(rootfs) console=ttyS0,115200n8 verbose mem=256M root=/dev/sda2 rootdelay=8 ip=off earlyprintk
> You seem to be missing nand in your DT. You should be able to work out
> the partition sizes from the information above.
Yes, I have manually removed nand partitions from my DTS, i don't use
the default ones (except u-boot part) and don't have the rights offsets
atm.
>> rtc-mv f1010300.rtc: internal RTC not ticking
> This suggests there is a different RTC on the board than the built in
> one. It is probably on i2c. You can probably get the address using the
> i2cdetect program. If you have boot logs from the vendor kernel it
> will probably tell you what device it is.
>
>      Andrew
I looked at my photos of the PCB and found a M41T80 "Serial access
real-time clock with alarm", it seems to be at 0x0c, then added :
        i2c at 11000 {
[snip]
                        rtc: rtc at 0c {
                                compatible = "stm,m41t80";
                                reg = <0x0c>;
                        };
        };

And got:
root at debian:~# dmesg|grep -i rtc
rtc-mv f1010300.rtc: internal RTC not ticking
rtc-m41t80 0-000c: chip found, driver version 0.05
rtc-m41t80 0-000c: rtc core: registered m41t80 as rtc0
rtc-m41t80 0-000c: hctosys: unable to read the hardware clock

The chip seems to register but nothing else.
i2cdetect also shown the LM75 (working) and another i2c peripherial i
have no ideas what is it.

Stuck getting DTS working for a new kirkwood board

[Andrew Lunn]

On Sat, Feb 22, 2014 at 09:54:33AM +0100, Dashie wrote:
> On 02/21/2014 11:12 PM, Andrew Lunn wrote:
> > Hi Dashie
> >
> > A few more tips for you
> Hi, thanks.
> >> Kernel command line: mtdparts=orion_nand:0x000e0000 at 0x00000000(u-boot)ro,0x1d73c0 at 0x000e0000(uImage),0x86cb58 at 0x2b73c0(uInitrd),- at 0xb23f18(rootfs) console=ttyS0,115200n8 verbose mem=256M root=/dev/sda2 rootdelay=8 ip=off earlyprintk
> > You seem to be missing nand in your DT. You should be able to work out
> > the partition sizes from the information above.
> Yes, I have manually removed nand partitions from my DTS, i don't use
> the default ones (except u-boot part) and don't have the rights offsets
> atm.

It would be good to have them for the final version, using the
standard defaults.

> >> rtc-mv f1010300.rtc: internal RTC not ticking
> > This suggests there is a different RTC on the board than the built in
> > one. It is probably on i2c. You can probably get the address using the
> > i2cdetect program. If you have boot logs from the vendor kernel it
> > will probably tell you what device it is.

> I looked at my photos of the PCB and found a M41T80 "Serial access
> real-time clock with alarm", it seems to be at 0x0c, then added :
>         i2c at 11000 {
> [snip]
>                         rtc: rtc at 0c {
>                                 compatible = "stm,m41t80";
>                                 reg = <0x0c>;
>                         };
>         };
> 
> And got:
> root at debian:~# dmesg|grep -i rtc
> rtc-mv f1010300.rtc: internal RTC not ticking
> rtc-m41t80 0-000c: chip found, driver version 0.05
> rtc-m41t80 0-000c: rtc core: registered m41t80 as rtc0
> rtc-m41t80 0-000c: hctosys: unable to read the hardware clock
> 
> The chip seems to register but nothing else.
> i2cdetect also shown the LM75 (working) and another i2c peripherial i
> have no ideas what is it.

I just had a look at the data sheet:

http://www.st.com/web/en/resource/technical/document/datasheet/CD00003119.pdf

It says:

   Access is obtained by implementing a start condition followed by
   the correct slave address (D0h).

I2C addresses are a bit odd, so this might actually mean 0x68, because
bit 0 is used to indicate Read/write. Does this address match to the
one you have no idea about?

    Andrew

Stuck getting DTS working for a new kirkwood board

[Gerhard Sittig]

On Sat, Feb 22, 2014 at 09:54 +0100, Dashie wrote:
> 
> On 02/21/2014 11:12 PM, Andrew Lunn wrote:
> > This suggests there is a different RTC on the board than the built in
> > one. It is probably on i2c. You can probably get the address using the
> > i2cdetect program. If you have boot logs from the vendor kernel it
> > will probably tell you what device it is.
> >
> >      Andrew
> I looked at my photos of the PCB and found a M41T80 "Serial access
> real-time clock with alarm", it seems to be at 0x0c, then added :
>         i2c at 11000 {
> [snip]
>                         rtc: rtc at 0c {
>                                 compatible = "stm,m41t80";
>                                 reg = <0x0c>;
>                         };
>         };

Aren't these M41T80 usually at I2C address 0x68 (fixed in the
chip, and not adjustable, not even partly)? 0x0c looks very
unexpected to me.

> And got:
> root at debian:~# dmesg|grep -i rtc
> rtc-mv f1010300.rtc: internal RTC not ticking
> rtc-m41t80 0-000c: chip found, driver version 0.05
> rtc-m41t80 0-000c: rtc core: registered m41t80 as rtc0
> rtc-m41t80 0-000c: hctosys: unable to read the hardware clock
> 
> The chip seems to register but nothing else.

Well, the driver blindly follows your input, and cannot detect
nor verify the chip's being present or being of the correct type.
So an address mismatch explains what you see.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de

Stuck getting DTS working for a new kirkwood board

[Dashie]

On 02/22/2014 07:41 PM, Andrew Lunn wrote:
>>>> Kernel command line: mtdparts=orion_nand:0x000e0000 at 0x00000000(u-boot)ro,0x1d73c0 at 0x000e0000(uImage),0x86cb58 at 0x2b73c0(uInitrd),- at 0xb23f18(rootfs) console=ttyS0,115200n8 verbose mem=256M root=/dev/sda2 rootdelay=8 ip=off earlyprintk
>>> You seem to be missing nand in your DT. You should be able to work out
>>> the partition sizes from the information above.
>> Yes, I have manually removed nand partitions from my DTS, i don't use
>> the default ones (except u-boot part) and don't have the rights offsets
>> atm.
> It would be good to have them for the final version, using the
> standard defaults.
I've the nand offsets from original boot log available.
>>>> rtc-mv f1010300.rtc: internal RTC not ticking
>>> This suggests there is a different RTC on the board than the built in
>>> one. It is probably on i2c. You can probably get the address using the
>>> i2cdetect program. If you have boot logs from the vendor kernel it
>>> will probably tell you what device it is.
>> I looked at my photos of the PCB and found a M41T80 "Serial access
>> real-time clock with alarm", it seems to be at 0x0c, then added :
>>         i2c at 11000 {
>> [snip]
>>                         rtc: rtc at 0c {
>>                                 compatible = "stm,m41t80";
>>                                 reg = <0x0c>;
>>                         };
>>         };
>>
>> And got:
>> root at debian:~# dmesg|grep -i rtc
>> rtc-mv f1010300.rtc: internal RTC not ticking
>> rtc-m41t80 0-000c: chip found, driver version 0.05
>> rtc-m41t80 0-000c: rtc core: registered m41t80 as rtc0
>> rtc-m41t80 0-000c: hctosys: unable to read the hardware clock
>>
>> The chip seems to register but nothing else.
>> i2cdetect also shown the LM75 (working) and another i2c peripherial i
>> have no ideas what is it.
> I just had a look at the data sheet:
>
> http://www.st.com/web/en/resource/technical/document/datasheet/CD00003119.pdf
>
> It says:
>
>    Access is obtained by implementing a start condition followed by
>    the correct slave address (D0h).
>
> I2C addresses are a bit odd, so this might actually mean 0x68, because
> bit 0 is used to indicate Read/write. Does this address match to the
> one you have no idea about?
>
>     Andrew
i2c device currently are :

root at debian:~# i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- UU -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

0x49 is a LM sensor, and 0x0c and 0x64 i don't know.

Stuck getting DTS working for a new kirkwood board

[Dashie]

Hi,

On 02/21/2014 09:08 PM, Jason Cooper wrote:
>> Well, with kirkwood_defconfig it doesn't find the SATA PHY and panic.
>> So i've used my debian config, make oldconfig, built and ... the toy is
>> booting.
> Yes, this is a known issue.  You worked around it by enabling generic
> phy support (it's most likely in the other configs).
Well, i've done some more tests and found that i've commented the
sata at 80000 {} part of the DTS, but does not remember if that was after
trying "debian config".

If i uncomment it, i got the kernel panic with "sata_mv f1080000.sata:
unable to find phy".

About generic phy, is it CONFIG_GENERIC_PHY ? I't already to =y in my
.config actually.
I have CONFIG_PHY_MVEBU_SATA=y and CONFIG_SATA_MV=y too.

Dashie.

Stuck getting DTS working for a new kirkwood board

[Jason Cooper]

On Sat, Feb 22, 2014 at 08:00:04PM +0100, Dashie wrote:
> Hi,
> 
> On 02/21/2014 09:08 PM, Jason Cooper wrote:
> >> Well, with kirkwood_defconfig it doesn't find the SATA PHY and panic.
> >> So i've used my debian config, make oldconfig, built and ... the toy is
> >> booting.
> > Yes, this is a known issue.  You worked around it by enabling generic
> > phy support (it's most likely in the other configs).
> Well, i've done some more tests and found that i've commented the
> sata at 80000 {} part of the DTS, but does not remember if that was after
> trying "debian config".
> 
> If i uncomment it, i got the kernel panic with "sata_mv f1080000.sata:
> unable to find phy".
> 
> About generic phy, is it CONFIG_GENERIC_PHY ? I't already to =y in my
> .config actually.
> I have CONFIG_PHY_MVEBU_SATA=y and CONFIG_SATA_MV=y too.

Ok.  Don't worry about that for the moment.  There's a fix making it's
way to mainline for this issue.  Once we get everything else sorted for
your board, we'll have you try Linus' current master to confirm sata
works on your board.

thx,

Jason.

Stuck getting DTS working for a new kirkwood board

[Andrew Lunn]

> root at debian:~# i2cdetect 0
> WARNING! This program can confuse your I2C bus, cause data loss and worse!
> I will probe file /dev/i2c-0.
> I will probe address range 0x03-0x77.
> Continue? [Y/n]
>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> 00:          -- -- -- -- -- -- -- -- -- UU -- -- --
> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 40: -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- --
> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
> 60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --
> 70: -- -- -- -- -- -- -- --

The datasheet for M41TC8025 says it uses 0x64.

Could you of read the part wrong from the photo?

      Andrew

Stuck getting DTS working for a new kirkwood board

[Dashie]

On 02/22/2014 08:30 PM, Andrew Lunn wrote:
>> root at debian:~# i2cdetect 0
>> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>> I will probe file /dev/i2c-0.
>> I will probe address range 0x03-0x77.
>> Continue? [Y/n]
>>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>> 00:          -- -- -- -- -- -- -- -- -- UU -- -- --
>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 40: -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- --
>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> 60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --
>> 70: -- -- -- -- -- -- -- --
> The datasheet for M41TC8025 says it uses 0x64.
>
> Could you of read the part wrong from the photo?
>
>       Andrew
The only readings on the chip is :
"M41T80
ST(logo) E9927"

I have a picture here :
http://wiki.sigpipe.me/lib/exe/fetch.php?media=hacking:img_3329.jpg

Stuck getting DTS working for a new kirkwood board

[Sebastian Hesselbarth]

On 02/22/2014 08:44 PM, Dashie wrote:
> On 02/22/2014 08:30 PM, Andrew Lunn wrote:
>>> root at debian:~# i2cdetect 0
>>> WARNING! This program can confuse your I2C bus, cause data loss and worse!
>>> I will probe file /dev/i2c-0.
>>> I will probe address range 0x03-0x77.
>>> Continue? [Y/n]
>>>      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
>>> 00:          -- -- -- -- -- -- -- -- -- UU -- -- --
>>> 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 40: -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- --
>>> 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>>> 60: -- -- -- -- 64 -- -- -- -- -- -- -- -- -- -- --
>>> 70: -- -- -- -- -- -- -- --
>> The datasheet for M41TC8025 says it uses 0x64.
>>
>> Could you of read the part wrong from the photo?
>>
>>        Andrew
> The only readings on the chip is :
> "M41T80
> ST(logo) E9927"
>
> I have a picture here :
> http://wiki.sigpipe.me/lib/exe/fetch.php?media=hacking:img_3329.jpg
>

Looking at the picture, I can see M41T80 and an Atmel i2c eeprom above
it. Given to M41T80 datasheet its i2c address is fixed at 0x68 as
Gerhard also noted. The eeprom is coded to 0x50 - you can see that all
right pins are connected to GND which is on pin 4, the white arrow
points to pin 1. You should see both devices but none is in the above
i2cdetect output.

Kirkwood only has one i2c controller, so my guess is that the devices
you are looking for are either connected to some i2c switch or mux, are
on a gpio bitbang i2c, or not connected to the SoC but some
microcontroller instead.

 From the wiki link above, you say there is an NXP 8051-compatible uC..
that would be my guess then.

Sebastian

Stuck getting DTS working for a new kirkwood board

[Jason Cooper]

On Sat, Feb 22, 2014 at 02:30:08PM -0500, Jason Cooper wrote:
> On Sat, Feb 22, 2014 at 08:00:04PM +0100, Dashie wrote:
> > Hi,
> > 
> > On 02/21/2014 09:08 PM, Jason Cooper wrote:
> > >> Well, with kirkwood_defconfig it doesn't find the SATA PHY and panic.
> > >> So i've used my debian config, make oldconfig, built and ... the toy is
> > >> booting.
> > > Yes, this is a known issue.  You worked around it by enabling generic
> > > phy support (it's most likely in the other configs).
> > Well, i've done some more tests and found that i've commented the
> > sata at 80000 {} part of the DTS, but does not remember if that was after
> > trying "debian config".
> > 
> > If i uncomment it, i got the kernel panic with "sata_mv f1080000.sata:
> > unable to find phy".
> > 
> > About generic phy, is it CONFIG_GENERIC_PHY ? I't already to =y in my
> > .config actually.
> > I have CONFIG_PHY_MVEBU_SATA=y and CONFIG_SATA_MV=y too.
> 
> Ok.  Don't worry about that for the moment.  There's a fix making it's
> way to mainline for this issue.  Once we get everything else sorted for
> your board, we'll have you try Linus' current master to confirm sata
> works on your board.

Care to give this a try now and report back?

thx,

Jason.