All of lore.kernel.org
 help / color / mirror / Atom feed
* NSA310 + DT
       [not found] <51DC564A.8050002@harsszegi.com>
@ 2013-07-09 19:36 ` Andrew Lunn
  2013-07-09 20:21   ` Andrew Lunn
  2013-07-10  1:01   ` tibor at harsszegi.com
  0 siblings, 2 replies; 39+ messages in thread
From: Andrew Lunn @ 2013-07-09 19:36 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jul 09, 2013 at 08:28:26PM +0200, Tibor Harsszegi wrote:
> Hello Andrew,
> 
> sorry to bug you, but honestly couldn't find better way than this :(

Hi Tibor

Its not a problem to bug me, but please also CC: the arm kernel
mailing list. This board port was contributed by Tero Jaasko
<tero.jaasko@gmail.com>, so its good to also ask him.

> I have some issues.

A basic question to start with. Are you using the default kernel
configuration for kirkwood? Which kernel version are you using?
 
> a.) With the current NSA310 .dts the sensors are not working (at
> least on my NSA310). The reason is that the i2c sensors is a lm85
> kind

Do you know what address it is using on the i2c bus? It looks like it
would be one of: 0x2c, 0x2d, 0x2e. Does you board also have the
adt7476?

You will need to edit arch/arm/boot/dts/kirkwood-nsa310.dts and add
something like:

                        lm85: lm85 at 2c {
                                compatible = "lm85";
                                reg = <0x2c>;
                        };

inside the i2c at 11000 node.

> b.) uart0 is not recognized at all during boot, I cannot see that
> 8250 would recognize the UART at the mmaped area, however the .DTS
> config seems fine

Do you see anything like:

Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A

> c.) LEDs are also not working, this is also strange, as the .DTS
> seems to be just fine as well.

How do you mean not working? Is /sys/class/leds/ empty? Or when you
change the brightness value, nothing happens?

       Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-09 19:36 ` NSA310 + DT Andrew Lunn
@ 2013-07-09 20:21   ` Andrew Lunn
  2013-07-10  0:53     ` tibor at harsszegi.com
  2013-07-10  1:01   ` tibor at harsszegi.com
  1 sibling, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-09 20:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jul 09, 2013 at 09:36:05PM +0200, Andrew Lunn wrote:
> On Tue, Jul 09, 2013 at 08:28:26PM +0200, Tibor Harsszegi wrote:
> > Hello Andrew,
> > 
> > sorry to bug you, but honestly couldn't find better way than this :(
> 
> Hi Tibor
> 
> Its not a problem to bug me, but please also CC: the arm kernel
> mailing list. This board port was contributed by Tero Jaasko
> <tero.jaasko@gmail.com>, so its good to also ask him.
> 
> > I have some issues.
> 
> A basic question to start with. Are you using the default kernel
> configuration for kirkwood? Which kernel version are you using?
>  
> > a.) With the current NSA310 .dts the sensors are not working (at
> > least on my NSA310). The reason is that the i2c sensors is a lm85
> > kind

Hi Tibor

Which NSA310 do you actually have? Apparently there are actually two
variants:

http://zyxel.nas-central.org/wiki/Category:NSA-310

It could be yours is actually the rebranded TDC Homedisk. If so, we
should add a new .dts file for it.

       Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-09 20:21   ` Andrew Lunn
@ 2013-07-10  0:53     ` tibor at harsszegi.com
  2013-07-10  6:23       ` Andrew Lunn
  2013-07-10 13:41       ` Andrew Lunn
  0 siblings, 2 replies; 39+ messages in thread
From: tibor at harsszegi.com @ 2013-07-10  0:53 UTC (permalink / raw)
  To: linux-arm-kernel

Hello guys,

> Hi Tibor
> 
> Which NSA310 do you actually have? Apparently there are actually two
> variants:
> 
> http://zyxel.nas-central.org/wiki/Category:NSA-310
> 
> It could be yours is actually the rebranded TDC Homedisk. If so, we
> should add a new .dts file for it.
> 
> Andrew

Well that's a good one. Hohestly have zero idea :(
Here is lspci and cpuinfo.

root at nsa310:~# lspci
00:00.0 Host bridge: Marvell Technology Group Ltd. 88F6281 [Kirkwood] 
ARM SoC (rev 03)
00:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
root at nsa310:~# cat /proc/cpuinfo
processor       : 0
model name      : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS        : 1196.85
Features        : swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant     : 0x2
CPU part        : 0x131
CPU revision    : 1

Hardware        : Marvell Kirkwood (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

I was using the patches from here, they worked
flawlessly (until pre DT kernels)

https://github.com/peeter123/NSA310-320-debian

Cheers,
Tibor

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-09 19:36 ` NSA310 + DT Andrew Lunn
  2013-07-09 20:21   ` Andrew Lunn
@ 2013-07-10  1:01   ` tibor at harsszegi.com
  2013-07-10  7:37     ` Andrew Lunn
  1 sibling, 1 reply; 39+ messages in thread
From: tibor at harsszegi.com @ 2013-07-10  1:01 UTC (permalink / raw)
  To: linux-arm-kernel

Hello guys,

> A basic question to start with. Are you using the default kernel
> configuration for kirkwood? Which kernel version are you using?
> 

standard kernels, have been trying 3.9.8,3.9.9 and 3.10

> Do you know what address it is using on the i2c bus? It looks like it
> would be one of: 0x2c, 0x2d, 0x2e. Does you board also have the
> adt7476?

The address is the same as the adt ones' but it is
recognized as a lm85. Sorry was a bit misleading. I could
make my sensors work via simply changing the type
from adt7476 to lm85

> b.) uart0 is not recognized at all during boot, I cannot see that
> 8250 would recognize the UART at the mmaped area, however the .DTS
> config seems fine
> 
> Do you see anything like:
> 
> Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> console [ttyS0] enabled
> f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
> 

None at all. I only see the first "Serial:" line, then
nothing else, seems like the UART0 is stucked, badly mapped/initialized
at that time.

> c.) LEDs are also not working, this is also strange, as the .DTS
> seems to be just fine as well.
> 
> How do you mean not working? Is /sys/class/leds/ empty? Or when you
> change the brightness value, nothing happens?
> 
Sorry lame me, wasn't clear again :)
All the LEDs remain "uninitialized", all
remains green after bootup, haven't tried setting
them yet :(

Cheers,
Tibor

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10  0:53     ` tibor at harsszegi.com
@ 2013-07-10  6:23       ` Andrew Lunn
  2013-07-10  8:42         ` tibor at harsszegi.com
  2013-07-10 13:41       ` Andrew Lunn
  1 sibling, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-10  6:23 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jul 10, 2013 at 02:53:44AM +0200, tibor at harsszegi.com wrote:
> Hello guys,
> 
> >Hi Tibor
> >
> >Which NSA310 do you actually have? Apparently there are actually two
> >variants:
> >
> >http://zyxel.nas-central.org/wiki/Category:NSA-310
> >
> >It could be yours is actually the rebranded TDC Homedisk. If so, we
> >should add a new .dts file for it.
> >
> >Andrew
> 
> Well that's a good one. Hohestly have zero idea :(

Hi Tibor

How does it compare to the pictures on the website?

    Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10  1:01   ` tibor at harsszegi.com
@ 2013-07-10  7:37     ` Andrew Lunn
  2013-07-10  8:43       ` tibor at harsszegi.com
                         ` (2 more replies)
  0 siblings, 3 replies; 39+ messages in thread
From: Andrew Lunn @ 2013-07-10  7:37 UTC (permalink / raw)
  To: linux-arm-kernel

> >b.) uart0 is not recognized at all during boot, I cannot see that
> >8250 would recognize the UART at the mmaped area, however the .DTS
> >config seems fine
> >
> >Do you see anything like:
> >
> >Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> >f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> >console [ttyS0] enabled
> >f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
> >
> 
> None at all. I only see the first "Serial:" line, then
> nothing else, seems like the UART0 is stucked, badly mapped/initialized
> at that time.

This suggests you are missing SERIAL_OF_PLATFORM.

Try

make kirkwood_defconfig
make

and see if that kernel works any better.

> >c.) LEDs are also not working, this is also strange, as the .DTS
> >seems to be just fine as well.
> >
> >How do you mean not working? Is /sys/class/leds/ empty? Or when you
> >change the brightness value, nothing happens?
> >
> Sorry lame me, wasn't clear again :)
> All the LEDs remain "uninitialized", all
> remains green after bootup, haven't tried setting
> them yet :(

Looking through the patch you pointed out, i think you will find some
work, some don't, and some have the wrong meaning.

We are going to need to add a new DTS file for this board. I can work
on this soon.

   Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10  6:23       ` Andrew Lunn
@ 2013-07-10  8:42         ` tibor at harsszegi.com
  0 siblings, 0 replies; 39+ messages in thread
From: tibor at harsszegi.com @ 2013-07-10  8:42 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

> Hello guys,
> 
> >Hi Tibor
> >
> >Which NSA310 do you actually have? Apparently there are actually two
> >variants:
> >
> >http://zyxel.nas-central.org/wiki/Category:NSA-310
> >
> >It could be yours is actually the rebranded TDC Homedisk. If so, we
> >should add a new .dts file for it.
> >
> >Andrew
> 
> Well that's a good one. Hohestly have zero idea :(
> 
> Hi Tibor
> 
> How does it compare to the pictures on the website?
> 

I have the one on the topmost picture, not the one labelled as "TDC".
Cheers,

Tibor

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10  7:37     ` Andrew Lunn
@ 2013-07-10  8:43       ` tibor at harsszegi.com
       [not found]       ` <51DEDB32.4080101@harsszegi.com>
  2013-07-29 17:05       ` NSA310 + DT Finn Hoffmann
  2 siblings, 0 replies; 39+ messages in thread
From: tibor at harsszegi.com @ 2013-07-10  8:43 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

> >b.) uart0 is not recognized at all during boot, I cannot see that
> >8250 would recognize the UART at the mmaped area, however the .DTS
> >config seems fine
> >
> >Do you see anything like:
> >
> >Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> >f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> >console [ttyS0] enabled
> >f1012100.serial: ttyS1 at MMIO 0xf1012100 (irq = 34) is a 16550A
> >
> 
> None at all. I only see the first "Serial:" line, then
> nothing else, seems like the UART0 is stucked, badly mapped/initialized
> at that time.
> 
> This suggests you are missing SERIAL_OF_PLATFORM.
> 
> Try
> 
> make kirkwood_defconfig
> make
> 
> and see if that kernel works any better.
> 

Aok, will keep you posted.
Thanks a lot!!
Cheers,
t.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10  0:53     ` tibor at harsszegi.com
  2013-07-10  6:23       ` Andrew Lunn
@ 2013-07-10 13:41       ` Andrew Lunn
       [not found]         ` <51DD8E8B.2040505@harsszegi.com>
  1 sibling, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-10 13:41 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Tibor

I created a DTS file based on the tree you gave me.

Please could you try

https://github.com/lunn/linux.git branch v3.10-nsa310-tdc

and the DTS file arch/arm/boot/dts/kirkwood-nsa310-tdc.dts

Please use 

make kirkwood_defconfig
make

and it should have the lm85 built in.

The two different NSA310 are mostly similar, just a few different gpio
LEDs and buttons, so i might actually refactor the two dts files with
what is shared. But lets get your box working first.

     Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
       [not found]         ` <51DD8E8B.2040505@harsszegi.com>
@ 2013-07-10 16:44           ` Tibor Harsszegi
  2013-07-10 16:53           ` Andrew Lunn
  1 sibling, 0 replies; 39+ messages in thread
From: Tibor Harsszegi @ 2013-07-10 16:44 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

just attached a bootlog for a working 2.5 (same /dev/sda2 as the rootfs):
          __  __                      _ _
         |  \/  | __ _ _ ____   _____| | |
         | |\/| |/ _` | '__\ \ / / _ \ | |
         | |  | | (_| | |   \ V /  __/ | |
         |_|  |_|\__,_|_|    \_/ \___|_|_|
  _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
  \___/    |____/ \___/ \___/ \__|
  ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Feb 22 2011 - 10:31:35) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
Kernel address is 0xc80000.

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0
NSA310>> setenv bootargs 'console=ttyS0,115200 root=/dev/sda2 
rootfstype=ext4'
NSA310>> bootm
## Booting image at 02000000 ...
Bad Magic Number
NSA310>> saveenv
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
NSA310>> reboot
Unknown command 'reboot' - try 'help'
NSA310>> bootm 0x800000
## Booting image at 00800000 ...
Bad Magic Number
NSA310>> ?
          __  __                      _ _
         |  \/  | __ _ _ ____   _____| | |
         | |\/| |/ _` | '__\ \ / / _ \ | |
         | |  | | (_| | |   \ V /  __/ | |
         |_|  |_|\__,_|_|    \_/ \___|_|_|
  _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
  \___/    |____/ \___/ \___/ \__|
  ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Feb 22 2011 - 10:31:35) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
Kernel address is 0xc80000.

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0

Reset IDE:
Marvell Serial ATA Adapter
Integrated Sata device found
[0 0 0]: Enable DMA mode (6)
   Device 0 @ 0 0:
Model: SAMSUNG HN-M500MBB                       Firm: 2AR10001 Ser#: 
S2R7J9CB602267
             Type: Hard Disk
             Supports 48-bit addressing
             Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)


2869242 bytes read
## Booting image at 00800000 ...
    Image Name:   Linux-3.10.0-77487-g7693569-dirt
    Created:      2013-07-10  16:32:23 UTC
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    2869178 Bytes =  2.7 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.10.0-77487-g7693569-dirty (root at harsszegi.com) (gcc 
version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #3 PREEMPT Wed Jul 10 
18:28:53 CEST 2013
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell Kirkwood (Flattened Device Tree), model: ZyXEL NSA310 TDC
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4
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: 256MB = 256MB total
Memory: 253636k/253636k available, 8508k 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)
     modules : 0xbf000000 - 0xc0000000   (  16 MB)
       .text : 0xc0008000 - 0xc050f2e4   (5149 kB)
       .init : 0xc0510000 - 0xc0535770   ( 150 kB)
       .data : 0xc0536000 - 0xc0572fa0   ( 244 kB)
        .bss : 0xc0572fa0 - 0xc060c2c4   ( 613 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 21474ms
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc03d1068 - 0xc03d10a4
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Kirkwood: MV88F6281-A1, TCLK=200000000.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
Kirkwood PCIe port 0: link up
PCI: bus0 uses PCIe port 0
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
pci_bus 0000:00: root bus resource [io  0x1000-0xffff]
pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
pci 0000:00:01.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
pci 0000:00:01.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
pci 0000:00:01.0: BAR 0: assigned [io  0x1000-0x10ff]
bio: create slab <bio-0> at 0
USB Power Off: Failed to request enable GPIO21: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Calling CRDA to update world regulatory domain
Switching to clocksource orion_clocksource
NET: Registered protocol family 2
TCP established hash table entries: 2048 (order: 2, 16384 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.
jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
msgmni has been set to 495
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
mv_xor f1060800.xor: Marvell shared XOR driver
mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
mv_xor f1060800.xor: Marvell XOR: ( xor fill cpy )
mv_xor f1060900.xor: Marvell shared XOR driver
mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
mv_xor f1060900.xor: Marvell XOR: ( xor fill cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
loop: module loaded
sata_mv f1080000.sata: slots 32 ports 2
scsi0 : sata_mv
scsi1 : sata_mv
ata1: SATA max UDMA/133 irq 21
ata2: SATA max UDMA/133 irq 21
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 
3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
Scanning device for bad blocks
9 ofpart partitions found on MTD device orion_nand
Creating 9 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "uboot"
0x000000100000-0x000000180000 : "uboot_env"
0x000000180000-0x000000200000 : "key_store"
0x000000200000-0x000000280000 : "info"
0x000000280000-0x000000c80000 : "etc"
0x000000c80000-0x000001680000 : "kernel_1"
0x000001680000-0x000004640000 : "rootfs1"
0x000004640000-0x000005040000 : "kernel_2"
0x000005040000-0x000008000000 : "rootfs2"
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 19, 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
rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
i2c /dev entries driver
gpio_poweroff_probe: Could not get GPIO 48
platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
hwmon_vid: Unknown VRM version of your CPU
lm85 0-002e: Starting monitoring
orion_wdt: Initial timeout 21 sec
cpuidle: using governor ladder
cpuidle: using governor menu
leds-gpio gpio-leds.2: pins are not configured from the driver
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
USB Power Off: Failed to request enable GPIO21: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
gpio_poweroff_probe: Could not get GPIO 48
platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
platform gpio_keys.1: Driver gpio-keys requests probe deferral
rtc-mv f1010300.rtc: setting system clock to 2013-07-10 16:37:24 UTC 
(1373474244)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: ATA-8: SAMSUNG HN-M500MBB, 2AR10001, max UDMA/133
ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
usb 1-1: new high-speed USB device number 2 using orion-ehci
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HN-M500M 2AR1 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 0:0:0:0: [sda] Write Protect is off
USB Power Off: Failed to request enable GPIO21: -517
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
gpio_poweroff_probe: Could not get GPIO 48
platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
platform gpio_keys.1: Driver gpio-keys requests probe deferral
  sda: sda1 sda2 sda3 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
USB Power Off: Failed to request enable GPIO21: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
gpio_poweroff_probe: Could not get GPIO 48
platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
platform gpio_keys.1: Driver gpio-keys requests probe deferral
ata2: SATA link down (SStatus 0 SControl F300)
VFS: Cannot open root device "sda2" or unknown-block(8,2): error -19
Please append a correct "root=" boot option; here are the available 
partitions:
1f00            1024 mtdblock0  (driver?)
1f01             512 mtdblock1  (driver?)
1f02             512 mtdblock2 usb 1-1.2: new high-speed USB device 
number 3 using orion-ehci
  (driver?)
1f03             512 mtdblock3  (driver?)
1f04           10240 mtdblock4  (driver?)
1f05           10240 mtdblock5  (driver?)
1f06           48896 mtdblock6  (driver?)
1f07           10240 mtdblock7  (driver?)
1f08           48896 mtdblock8  (driver?)
0800       488386584 sda  driver: sd
   0801          145408 sda1 0004cbfe-01
   0802         9765888 sda2 0004cbfe-02
   0803               1 sda3
   0805          487424 sda5 0004cbfe-05
   0806       477984768 sda6 0004cbfe-06
Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(8,2)
CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-77487-g7693569-dirty #3
[<c000cf6c>] (unwind_backtrace+0x0/0xf0) from [<c000adec>] 
(show_stack+0x10/0x14)
[<c000adec>] (show_stack+0x10/0x14) from [<c03c7514>] (panic+0x9c/0x1ec)
[<c03c7514>] (panic+0x9c/0x1ec) from [<c0510c58>] 
(mount_block_root+0x1a0/0x258)
[<c0510c58>] (mount_block_root+0x1a0/0x258) from [<c0510e00>] 
(mount_root+0xf0/0x118)
[<c0510e00>] (mount_root+0xf0/0x118) from [<c0510f48>] 
(prepare_namespace+0x120/0x174)
[<c0510f48>] (prepare_namespace+0x120/0x174) from [<c05108dc>] 
(kernel_init_freeable+0x16c/0x1b0)
[<c05108dc>] (kernel_init_freeable+0x16c/0x1b0) from [<c03c566c>] 
(kernel_init+0x8/0xe4)
[<c03c566c>] (kernel_init+0x8/0xe4) from [<c0008d10>] 
(ret_from_fork+0x14/0x24)
?
          __  __                      _ _
         |  \/  | __ _ _ ____   _____| | |
         | |\/| |/ _` | '__\ \ / / _ \ | |
         | |  | | (_| | |   \ V /  __/ | |
         |_|  |_|\__,_|_|    \_/ \___|_|_|
  _   _     ____              _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
  \___/    |____/ \___/ \___/ \__|
  ** MARVELL BOARD: RD-88F6281A LE

U-Boot 1.1.4 (Feb 22 2011 - 10:31:35) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0  BSS: -> 006CFEE0

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000   size 256MB
DRAM Total size 256MB  16bit width
Addresses 10M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (10M - 7M): Done
NAND:128 MB
Flash:  0 kB

CPU : Marvell Feroceon (Rev 1)
Kernel address is 0xc80000.

Streaming disabled
Write allocate disabled

Module 0 is RGMII
Module 1 is TDM

USB 0: host mode
PEX 0: PCI Express Root Complex Interface
PEX interface detected Link X1
Net:   egiga0, egiga1 [PRIME]
Hit any key to stop autoboot:  0
NSA310>> usb start
(Re)start USB...
USB:   scanning bus for devices... 3 USB Device(s) found
        scanning bus for storage devices... 1 Storage Device(s) found
NSA310>> fatload usb 0 0x800000 uImage
reading uImage
.
....................................................................................................................................................................................................

3002408 bytes read
NSA310>> setenv bootargs 'console=ttyS0,115200 root=/dev/sda2'
NSA310>> bootm 0x800000
## Booting image at 00800000 ...
    Image Name:   Linux-3.5.1
    Created:      2012-09-24  17:18:17 UTC
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    3002344 Bytes =  2.9 MB
    Load Address: 00008000
    Entry Point:  00008000
    Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Initializing cgroup subsys cpu
Linux version 3.5.1 (peter at Ubuntu) (gcc version 4.6.3 (Ubuntu/Linaro 
4.6.3-1ubuntu5) ) #1 Mon Sep 24 19:17:28 CEST 2012
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Zyxel NSA-310
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda2
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: 256MB = 256MB total
Memory: 253896k/253896k available, 8248k 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)
     modules : 0xbf000000 - 0xc0000000   (  16 MB)
       .text : 0xc0008000 - 0xc0536930   (5307 kB)
       .init : 0xc0537000 - 0xc055c524   ( 150 kB)
       .data : 0xc055e000 - 0xc058f3a0   ( 197 kB)
        .bss : 0xc058f3c4 - 0xc05d19e0   ( 266 kB)
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:114
sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys blkio
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x464778 - 0x4647b4
devtmpfs: initialized
NET: Registered protocol family 16
Kirkwood: MV88F6281-A1, TCLK=200000000.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
NSA310: Power resume enabled
NSA310: Power-off GPIO enabled
Kirkwood PCIe port 0:
link up
PCI: bus0 uses PCIe port 0
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io  0x0000-0xfffff]
pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
PCI: bus0: Fast back to back transfers disabled
pci 0000:00:01.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
pci 0000:00:01.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
pci 0000:00:01.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
pci 0000:00:01.0: BAR 0: assigned [io  0x1000-0x10ff]
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.25.
Switching to clocksource orion_clocksource
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
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.
NetWinder Floating Point Emulator V0.97 (double precision)
Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
Key type cifs.spnego registered
NTFS driver 2.1.30 [Flags: R/W].
fuse init (API version 7.19)
Btrfs loaded
msgmni has been set to 495
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler cfq registered
mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
console [ttyS0] enabled
brd: module loaded
loop: module loaded
Loading iSCSI transport class v2.0-870.
iscsi: registered transport (tcp)
sata_mv sata_mv.0: cannot get optional clkdev
sata_mv sata_mv.0: slots 32 ports 2
scsi0 : sata_mv
scsi1 : sata_mv
ata1: SATA max UDMA/133 irq 21
ata2: SATA max UDMA/133 irq 21
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 
3,3V 8-bit), page size: 2048, OOB size: 64
Scanning device for bad blocks
Creating 9 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "uboot"
0x000000100000-0x000000180000 : "uboot_env"
0x000000180000-0x000000200000 : "key_store"
0x000000200000-0x000000280000 : "info"
0x000000280000-0x000000c80000 : "etc"
0x000000c80000-0x000001680000 : "kernel_1"
0x000001680000-0x000004640000 : "rootfs1"
0x000004640000-0x000005040000 : "kernel_2"
0x000005040000-0x000008000000 : "rootfs2"
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:00:01.0: eth0: RTL8168d/8111d at 0xd0806000, 
00:00:00:00:00:30, XID 083000c0 IRQ 9
r8169 0000:00:01.0: eth0: jumbo features [frames: 9200 bytes, tx 
checksumming: ko]
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
orion-ehci orion-ehci.0: Marvell Orion EHCI
orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1
orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000
orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: Marvell Orion EHCI
usb usb1: Manufacturer: Linux 3.5.1 ehci_hcd
usb usb1: SerialNumber: orion-ehci.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
rtc-mv rtc-mv: rtc core: registered rtc-mv as rtc0
i2c /dev entries driver
hwmon_vid: Unknown VRM version of your CPU
lm85 0-002e: Starting monitoring
orion_wdt: Initial timeout 21 sec
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usbcore: registered new interface driver snd-usb-audio
TCP: cubic registered
NET: Registered protocol family 10
sit: IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
Key type dns_resolver registered
registered taskstats version 1
input: gpio-keys as /devices/platform/gpio-keys/input/input0
rtc-mv rtc-mv: setting system clock to 2013-07-10 16:41:21 UTC (1373474481)
ALSA device list:
   No soundcards found.
usb 1-1: new high-speed USB device number 2 using orion-ehci
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: ATA-8: SAMSUNG HN-M500MBB, 2AR10001, max UDMA/133
ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access     ATA      SAMSUNG HN-M500M 2AR1 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
ata2: SATA link down (SStatus 0 SControl F300)
usb 1-1.2: new high-speed USB device number 3 using orion-ehci
  sda: sda1 sda2 sda3 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
EXT2-fs (sda2): error: couldn't mount because of unsupported optional 
features (240)
usb 1-1.2: New USB device found, idVendor=0951, idProduct=1607
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1.2: Product: DataTraveler 2.0
usb 1-1.2: Manufacturer: Kingston
usb 1-1.2: SerialNumber: 5B7C15001BF2
scsi2 : usb-storage 1-1.2:1.0
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 8:2.
devtmpfs: mounted
Freeing init memory: 148K
INIT: version 2.88 booting
scsi 2:0:0:0: Direct-Access     Kingston DataTraveler 2.0 PMAP PQ: 0 
ANSI: 0 CCS
sd 2:0:0:0: [sdb] 1953792 512-byte logical blocks: (1.00 GB/954 MiB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through
  sdb: sdb1
sd 2:0:0:0: [sdb] No Caching mode page present
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] Attached SCSI removable disk
[info] Using makefile-style concurrent boot in runlevel S.
findfs: unable to resolve 'UUID=07ec974b-3603-488f-91d9-da5dcb3a76f8'
[....] Starting the hotplug events dispatcher: udevdudevd[693]: starting 
version 175
. ok
[....] Synthesizing the initial hotplug events...done.
[....] Waiting for /dev to be fully populated...done.
[....] Setting preliminary keymap...done.
[....] Setting parameters of disc: (none). ok
[....] Activating swap...Adding 487420k swap on /dev/sda5. Priority:-1 
extents:1 across:487420k
done.
EXT4-fs (sda2): re-mounted. Opts: (null)
[....] Checking root file system...fsck from util-linux 2.20.1
Debian: clean, 83959/610800 files, 479183/2441472 blocks
done.
EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[....] Cleaning up temporary files... /tmp /run/shm. ok
[....] Loading kernel modules...done.
[....] Activating lvm and md swap...done.
[....] Checking file systems...fsck from util-linux 2.20.1
boot: clean, 16/72720 files, 27148/145408 blocks
home has been mounted 27 times without being checked, check forced.
NSA310: USB power enabled==================================    - 93.2%
home: 24/29876224 files (0.0% non-contiguous), 2222043/119496192 blocks
done.
[....] Mounting local filesystems...EXT4-fs (sda6): mounted filesystem 
with ordered data mode. Opts: (null)
done.
[....] Activating swapfile swap...done.
[....] Cleaning up temporary files.... ok
[....] Setting kernel variables ...done.
[....] Configuring network interfaces...r8169 0000:00:01.0: eth0: unable 
to load firmware patch rtl_nic/rtl8168d-2.fw (-2)
r8169 0000:00:01.0: eth0: link down
r8169 0000:00:01.0: eth0: link down
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
r8169 0000:00:01.0: eth0: link up
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
done.
[....] Starting rpcbind daemon.... ok
[....] Starting NFS common utilities: statd idmapd. ok
[....] Cleaning up temporary files.... ok
[info] Setting console screen modes.
[info] Skipping font and keymap setup (handled by console-setup).
[....] Setting up console font and keymap...done.
[....] Setting sensors limits. ok
INIT: Entering runlevel: 2
[info] Using makefile-style concurrent boot in runlevel 2.
[....] Starting rpcbind daemon...[....] Already running.. ok
[....] Starting NFS common utilities: statd idmapd. ok
[....] Not starting NFS kernel daemon: no exports. ... (warning).
[....] Starting enhanced syslogd: rsyslogd. ok
[....] Starting ACPI services...RTNETLINK1 answers: No such file or 
directory
acpid: error talking to the kernel via netlink
. ok
[....] Starting anac(h)ronistic cron: anacron. ok
[....] Starting deferred execution scheduler: atd. ok
[....] Starting periodic command scheduler: cron. ok
[....] Starting system message bus: dbus. ok
[....] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon. ok
[....] Starting MTA:[....] Starting bluetooth: bluetoothd. ok
  exim4. ok
[....] Starting internet superserver: inetd. ok
[....] Starting Common Unix Printing System: cupsd. ok
[....] Starting Samba daemons: nmbdsaned disabled; edit /etc/default/saned
[....] Starting OpenBSD Secure Shell server: sshd. ok
  smbd. ok
[....] Starting the Winbind daemon: winbind. ok
r8169 0000:00:01.0: eth0: link down
r8169 0000:00:01.0: eth0: link down
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
100000
r8169 0000:00:01.0: eth0: link up
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Debian GNU/Linux 7 nsa310 ttyS0

nsa310 login:

> Hello Andrew,
>
> I did a:
>
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb > 
> /tmp/X
> mv /tmp/X arch/arm/boot/zImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
>
> [attached .config]
>
> copied the uImage over the NSA310, rebooted.
> Good news: console is back
> Bad news: LEDs still don't work (all green), kernel stops (tried 
> forcing rootfstype=ext4, didn't help)
> Bootlog:
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 3.10.0-77487-g7693569-dirty (root at harsszegi.com) (gcc 
> version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #3 PREEMPT Wed Jul 10 
> 18:28:53 CEST 2013
> CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Marvell Kirkwood (Flattened Device Tree), model: ZyXEL NSA310 
> TDC
> Memory policy: ECC disabled, Data cache writeback
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
> Kernel command line: console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4
> 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: 256MB = 256MB total
> Memory: 253636k/253636k available, 8508k 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)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0xc0008000 - 0xc050f2e4 (5149 kB)
> .init : 0xc0510000 - 0xc0535770 ( 150 kB)
> .data : 0xc0536000 - 0xc0572fa0 ( 244 kB)
> .bss : 0xc0572fa0 - 0xc060c2c4 ( 613 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 21474ms
> Console: colour dummy device 80x30
> Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc03d1068 - 0xc03d10a4
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Kirkwood: MV88F6281-A1, TCLK=200000000.
> Feroceon L2: Enabling L2
> Feroceon L2: Cache support initialised.
> Kirkwood PCIe port 0: link up
> PCI: bus0 uses PCIe port 0
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
> pci_bus 0000:00: root bus resource [io 0x1000-0xffff]
> pci_bus 0000:00: No busn resource found for root bus, will use [bus 
> 00-ff]
> PCI: bus0: Fast back to back transfers disabled
> pci 0000:00:01.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
> pci 0000:00:01.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
> pci 0000:00:01.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
> pci 0000:00:01.0: BAR 0: assigned [io 0x1000-0x10ff]
> bio: create slab <bio-0> at 0
> USB Power Off: Failed to request enable GPIO21: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> vgaarb: loaded
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> cfg80211: Calling CRDA to update world regulatory domain
> Switching to clocksource orion_clocksource
> NET: Registered protocol family 2
> TCP established hash table entries: 2048 (order: 2, 16384 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.
> jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
> msgmni has been set to 495
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> mv_xor f1060800.xor: Marvell shared XOR driver
> mv_xor f1060800.xor: Marvell XOR: ( xor cpy )
> mv_xor f1060800.xor: Marvell XOR: ( xor fill cpy )
> mv_xor f1060900.xor: Marvell shared XOR driver
> mv_xor f1060900.xor: Marvell XOR: ( xor cpy )
> mv_xor f1060900.xor: Marvell XOR: ( xor fill cpy )
> Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
> f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 33) is a 16550A
> console [ttyS0] enabled
> loop: module loaded
> sata_mv f1080000.sata: slots 32 ports 2
> scsi0 : sata_mv
> scsi1 : sata_mv
> ata1: SATA max UDMA/133 irq 21
> ata2: SATA max UDMA/133 irq 21
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 
> 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 64
> Scanning device for bad blocks
> 9 ofpart partitions found on MTD device orion_nand
> Creating 9 MTD partitions on "orion_nand":
> 0x000000000000-0x000000100000 : "uboot"
> 0x000000100000-0x000000180000 : "uboot_env"
> 0x000000180000-0x000000200000 : "key_store"
> 0x000000200000-0x000000280000 : "info"
> 0x000000280000-0x000000c80000 : "etc"
> 0x000000c80000-0x000001680000 : "kernel_1"
> 0x000001680000-0x000004640000 : "rootfs1"
> 0x000004640000-0x000005040000 : "kernel_2"
> 0x000005040000-0x000008000000 : "rootfs2"
> 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 19, 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
> rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
> i2c /dev entries driver
> gpio_poweroff_probe: Could not get GPIO 48
> platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
> hwmon_vid: Unknown VRM version of your CPU
> lm85 0-002e: Starting monitoring
> orion_wdt: Initial timeout 21 sec
> cpuidle: using governor ladder
> cpuidle: using governor menu
> leds-gpio gpio-leds.2: pins are not configured from the driver
> 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
> USB Power Off: Failed to request enable GPIO21: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> gpio_poweroff_probe: Could not get GPIO 48
> platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
> gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
> platform gpio_keys.1: Driver gpio-keys requests probe deferral
> rtc-mv f1010300.rtc: setting system clock to 2013-07-10 16:37:24 UTC 
> (1373474244)
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
> ata1.00: ATA-8: SAMSUNG HN-M500MBB, 2AR10001, max UDMA/133
> ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> usb 1-1: new high-speed USB device number 2 using orion-ehci
> ata1.00: configured for UDMA/133
> scsi 0:0:0:0: Direct-Access ATA SAMSUNG HN-M500M 2AR1 PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> USB Power Off: Failed to request enable GPIO21: -517
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
> support DPO or FUA
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> gpio_poweroff_probe: Could not get GPIO 48
> platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
> gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
> platform gpio_keys.1: Driver gpio-keys requests probe deferral
> sda: sda1 sda2 sda3 < sda5 sda6 >
> sd 0:0:0:0: [sda] Attached SCSI disk
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 4 ports detected
> USB Power Off: Failed to request enable GPIO21: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> gpio_poweroff_probe: Could not get GPIO 48
> platform gpio_poweroff.3: Driver poweroff-gpio requests probe deferral
> gpio-keys gpio_keys.1: Failed to request GPIO 46, error -517
> platform gpio_keys.1: Driver gpio-keys requests probe deferral
> ata2: SATA link down (SStatus 0 SControl F300)
> VFS: Cannot open root device "sda2" or unknown-block(8,2): error -19
> Please append a correct "root=" boot option; here are the available 
> partitions:
> 1f00 1024 mtdblock0 (driver?)
> 1f01 512 mtdblock1 (driver?)
> 1f02 512 mtdblock2 usb 1-1.2: new high-speed USB device number 3 using 
> orion-ehci
> (driver?)
> 1f03 512 mtdblock3 (driver?)
> 1f04 10240 mtdblock4 (driver?)
> 1f05 10240 mtdblock5 (driver?)
> 1f06 48896 mtdblock6 (driver?)
> 1f07 10240 mtdblock7 (driver?)
> 1f08 48896 mtdblock8 (driver?)
> 0800 488386584 sda driver: sd
> 0801 145408 sda1 0004cbfe-01
> 0802 9765888 sda2 0004cbfe-02
> 0803 1 sda3
> 0805 487424 sda5 0004cbfe-05
> 0806 477984768 sda6 0004cbfe-06
> Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(8,2)
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-77487-g7693569-dirty #3
> [<c000cf6c>] (unwind_backtrace+0x0/0xf0) from [<c000adec>] 
> (show_stack+0x10/0x14)
> [<c000adec>] (show_stack+0x10/0x14) from [<c03c7514>] (panic+0x9c/0x1ec)
> [<c03c7514>] (panic+0x9c/0x1ec) from [<c0510c58>] 
> (mount_block_root+0x1a0/0x258)
> [<c0510c58>] (mount_block_root+0x1a0/0x258) from [<c0510e00>] 
> (mount_root+0xf0/0x118)
> [<c0510e00>] (mount_root+0xf0/0x118) from [<c0510f48>] 
> (prepare_namespace+0x120/0x174)
> [<c0510f48>] (prepare_namespace+0x120/0x174) from [<c05108dc>] 
> (kernel_init_freeable+0x16c/0x1b0)
> [<c05108dc>] (kernel_init_freeable+0x16c/0x1b0) from [<c03c566c>] 
> (kernel_init+0x8/0xe4)
> [<c03c566c>] (kernel_init+0x8/0xe4) from [<c0008d10>] 
> (ret_from_fork+0x14/0x24)
>
>> Hi Tibor
>>
>> I created a DTS file based on the tree you gave me.
>>
>> Please could you try
>>
>> https://github.com/lunn/linux.git branch v3.10-nsa310-tdc
>>
>> and the DTS file arch/arm/boot/dts/kirkwood-nsa310-tdc.dts
>>
>> Please use
>>
>> make kirkwood_defconfig
>> make
>>
>> and it should have the lm85 built in.
>>
>> The two different NSA310 are mostly similar, just a few different gpio
>> LEDs and buttons, so i might actually refactor the two dts files with
>> what is shared. But lets get your box working first.
>>
>>       Andrew
>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
       [not found]         ` <51DD8E8B.2040505@harsszegi.com>
  2013-07-10 16:44           ` Tibor Harsszegi
@ 2013-07-10 16:53           ` Andrew Lunn
  2013-07-10 16:57             ` Tibor Harsszegi
  1 sibling, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-10 16:53 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jul 10, 2013 at 06:40:43PM +0200, Tibor Harsszegi wrote:
> Hello Andrew,
> 
> I did a:
> 
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb > /tmp/X
> mv /tmp/X arch/arm/boot/zImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
> 
> [attached .config]
> 
> copied the uImage over the NSA310, rebooted.
> Good news: console is back

Great. Probably was OF_SERIAL_PLATFORM

> Bad news: LEDs still don't work (all green), kernel stops (tried
> forcing rootfstype=ext4, didn't help)

Ah, O.k. EXT4 is not part of kirkwood_defconfig. Hence it cannot mount
the root fs.

Please could you use make menuconfig and include it into the kernel
image. I will also update the patch later.

LEDs are not working because the GPIO driver is not loading.
I will see if i can spot an obvious typo etc.

  Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10 16:53           ` Andrew Lunn
@ 2013-07-10 16:57             ` Tibor Harsszegi
  2013-07-10 17:13               ` Tibor Harsszegi
  0 siblings, 1 reply; 39+ messages in thread
From: Tibor Harsszegi @ 2013-07-10 16:57 UTC (permalink / raw)
  To: linux-arm-kernel

Cool, keep you posted.
> On Wed, Jul 10, 2013 at 06:40:43PM +0200, Tibor Harsszegi wrote:
>> Hello Andrew,
>>
>> I did a:
>>
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
>> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb > /tmp/X
>> mv /tmp/X arch/arm/boot/zImage
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
>>
>> [attached .config]
>>
>> copied the uImage over the NSA310, rebooted.
>> Good news: console is back
> Great. Probably was OF_SERIAL_PLATFORM
>
>> Bad news: LEDs still don't work (all green), kernel stops (tried
>> forcing rootfstype=ext4, didn't help)
> Ah, O.k. EXT4 is not part of kirkwood_defconfig. Hence it cannot mount
> the root fs.
>
> Please could you use make menuconfig and include it into the kernel
> image. I will also update the patch later.
>
> LEDs are not working because the GPIO driver is not loading.
> I will see if i can spot an obvious typo etc.
>
>    Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10 16:57             ` Tibor Harsszegi
@ 2013-07-10 17:13               ` Tibor Harsszegi
  2013-07-10 17:15                 ` Tibor Harsszegi
  0 siblings, 1 reply; 39+ messages in thread
From: Tibor Harsszegi @ 2013-07-10 17:13 UTC (permalink / raw)
  To: linux-arm-kernel

WTF. Andrew. It works COMPLETELY.
The memory mapped GPIO was working from the .config (don't ask me how).

* sensors
* LEDs
* bootup works

Awesome work thanks a lot!!!!
> Cool, keep you posted.
>> On Wed, Jul 10, 2013 at 06:40:43PM +0200, Tibor Harsszegi wrote:
>>> Hello Andrew,
>>>
>>> I did a:
>>>
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
>>> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb > 
>>> /tmp/X
>>> mv /tmp/X arch/arm/boot/zImage
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
>>>
>>> [attached .config]
>>>
>>> copied the uImage over the NSA310, rebooted.
>>> Good news: console is back
>> Great. Probably was OF_SERIAL_PLATFORM
>>
>>> Bad news: LEDs still don't work (all green), kernel stops (tried
>>> forcing rootfstype=ext4, didn't help)
>> Ah, O.k. EXT4 is not part of kirkwood_defconfig. Hence it cannot mount
>> the root fs.
>>
>> Please could you use make menuconfig and include it into the kernel
>> image. I will also update the patch later.
>>
>> LEDs are not working because the GPIO driver is not loading.
>> I will see if i can spot an obvious typo etc.
>>
>>    Andrew
>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10 17:13               ` Tibor Harsszegi
@ 2013-07-10 17:15                 ` Tibor Harsszegi
  2013-07-10 17:23                   ` Andrew Lunn
  0 siblings, 1 reply; 39+ messages in thread
From: Tibor Harsszegi @ 2013-07-10 17:15 UTC (permalink / raw)
  To: linux-arm-kernel

Ok, was too fast :(
After a reboot the LEDs are gone, all green :(

t.
> WTF. Andrew. It works COMPLETELY.
> The memory mapped GPIO was working from the .config (don't ask me how).
>
> * sensors
> * LEDs
> * bootup works
>
> Awesome work thanks a lot!!!!
>> Cool, keep you posted.
>>> On Wed, Jul 10, 2013 at 06:40:43PM +0200, Tibor Harsszegi wrote:
>>>> Hello Andrew,
>>>>
>>>> I did a:
>>>>
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make clean
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make kirkwood_defconfig
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make zImage
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs
>>>> cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310-tdc.dtb 
>>>> > /tmp/X
>>>> mv /tmp/X arch/arm/boot/zImage
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make uImage
>>>> ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make modules
>>>>
>>>> [attached .config]
>>>>
>>>> copied the uImage over the NSA310, rebooted.
>>>> Good news: console is back
>>> Great. Probably was OF_SERIAL_PLATFORM
>>>
>>>> Bad news: LEDs still don't work (all green), kernel stops (tried
>>>> forcing rootfstype=ext4, didn't help)
>>> Ah, O.k. EXT4 is not part of kirkwood_defconfig. Hence it cannot mount
>>> the root fs.
>>>
>>> Please could you use make menuconfig and include it into the kernel
>>> image. I will also update the patch later.
>>>
>>> LEDs are not working because the GPIO driver is not loading.
>>> I will see if i can spot an obvious typo etc.
>>>
>>>    Andrew
>>
>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10 17:15                 ` Tibor Harsszegi
@ 2013-07-10 17:23                   ` Andrew Lunn
  2013-07-10 17:29                     ` Tibor Harsszegi
  0 siblings, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-10 17:23 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jul 10, 2013 at 07:15:37PM +0200, Tibor Harsszegi wrote:
> Ok, was too fast :(
> After a reboot the LEDs are gone, all green :(

Please do not top post. Answer comes after questions, not before...

root at qnap:/sys# find . -name *gpio*
./bus/platform/devices/gpio_keys.1
./bus/platform/devices/f1010140.gpio
./bus/platform/devices/f1010100.gpio
./bus/platform/drivers/leds-gpio
./bus/platform/drivers/mvebu-gpio
./bus/platform/drivers/mvebu-gpio/f1010140.gpio
./bus/platform/drivers/mvebu-gpio/f1010100.gpio
./bus/platform/drivers/poweroff-gpio
./bus/platform/drivers/gpio-keys
./bus/platform/drivers/gpio-keys/gpio_keys.1
./devices/gpio_keys.1
./devices/ocp.0/f1010140.gpio
./devices/ocp.0/f1010140.gpio/gpio
./devices/ocp.0/f1010140.gpio/gpio/gpiochip32
./devices/ocp.0/f1010140.gpio/gpio/gpiochip32/ngpio
./devices/ocp.0/f1010100.gpio
./devices/ocp.0/f1010100.gpio/gpio
./devices/ocp.0/f1010100.gpio/gpio/gpiochip0
./devices/ocp.0/f1010100.gpio/gpio/gpiochip0/ngpio
./class/gpio
./class/gpio/gpiochip32
./class/gpio/gpiochip0

You should have something similar.

I have no LEDs on this box, but you should should see entries in

/sys/class/leds

What you probably see in the kernel logs is lots of warnings from gpio
about deferred, but then they get repeated later and are successful.

	Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10 17:23                   ` Andrew Lunn
@ 2013-07-10 17:29                     ` Tibor Harsszegi
  0 siblings, 0 replies; 39+ messages in thread
From: Tibor Harsszegi @ 2013-07-10 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,
> root at qnap:/sys# find . -name *gpio*
root at nsa310:/sys# find . -name *gpio*
./bus/platform/devices/gpio_keys.1
./bus/platform/devices/f1010140.gpio
./bus/platform/devices/gpio-leds.2
./bus/platform/devices/f1010100.gpio
./bus/platform/devices/gpio_poweroff.3
./bus/platform/drivers/leds-gpio
./bus/platform/drivers/mvebu-gpio
./bus/platform/drivers/mvebu-gpio/f1010140.gpio
./bus/platform/drivers/mvebu-gpio/f1010100.gpio
./bus/platform/drivers/poweroff-gpio
./bus/platform/drivers/gpio-keys
./bus/platform/drivers/basic-mmio-gpio
./devices/gpio_keys.1
./devices/ocp.0/f1010140.gpio
./devices/ocp.0/f1010140.gpio/gpio
./devices/ocp.0/f1010140.gpio/gpio/gpiochip32
./devices/ocp.0/f1010140.gpio/gpio/gpiochip32/ngpio
./devices/ocp.0/f1010100.gpio
./devices/ocp.0/f1010100.gpio/gpio
./devices/ocp.0/f1010100.gpio/gpio/gpiochip0
./devices/ocp.0/f1010100.gpio/gpio/gpiochip0/ngpio
./devices/gpio-leds.2
./devices/gpio_poweroff.3
./class/gpio
./class/gpio/gpiochip32
./class/gpio/gpiochip0

> I have no LEDs on this box, but you should should see entries in
>
> /sys/class/leds
>
No, I don't.

root at nsa310:/sys# ls -la /sys/class/leds/
total 0
drwxr-xr-x 2 root root 0 j??l 10 19:24 .
drwxr-xr-x 34 root root 0 j??l 10 19:24 ..

Cheers,
t.

> What you probably see in the kernel logs is lots of warnings from gpio
> about deferred, but then they get repeated later and are successful.
>
> 	Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* gpio_blink_set + Kirkwood
       [not found]       ` <51DEDB32.4080101@harsszegi.com>
@ 2013-07-11 16:44         ` Andrew Lunn
  2013-07-11 18:32           ` Tibor Harsszegi
  0 siblings, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-11 16:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
> Hello guys,
> 
> can anyone explain me how does the gpio_blink_set member gets filled
> in leds-gpio through platform_get_drvdata()?
> I can't seem to follow how the specific function pointer can be set
> to orion_gpio_set_blink() for example.
> Sorry for the dumb question :(

Hi Tibor

For DT based board, hardware blinking is not supported, as far as i
remember.

	Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* gpio_blink_set + Kirkwood
  2013-07-11 16:44         ` gpio_blink_set + Kirkwood Andrew Lunn
@ 2013-07-11 18:32           ` Tibor Harsszegi
  2013-07-11 18:37             ` Jason Cooper
  0 siblings, 1 reply; 39+ messages in thread
From: Tibor Harsszegi @ 2013-07-11 18:32 UTC (permalink / raw)
  To: linux-arm-kernel

> On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
>> Hello guys,
>>
>> can anyone explain me how does the gpio_blink_set member gets filled
>> in leds-gpio through platform_get_drvdata()?
>> I can't seem to follow how the specific function pointer can be set
>> to orion_gpio_set_blink() for example.
>> Sorry for the dumb question :(
> Hi Tibor
>
> For DT based board, hardware blinking is not supported, as far as i
> remember.
>
> 	Andrew

Hello Andrew,

is there an example for "mixed machine setup" (if there is anything like 
that) ?
I'm thinking about:

* DT based initialization starts
* then if supported board based "after-DT-init-board-code" executes

similar what we have in board-*.c files just that it would be executed 
after kirkwood has initialized the board
based upon the .DTB
[I'm thinking about getting rid of the LED setup from the .DTB and move 
it back to .C land - at least for a trial]

Thanks,
Tibor

^ permalink raw reply	[flat|nested] 39+ messages in thread

* gpio_blink_set + Kirkwood
  2013-07-11 18:32           ` Tibor Harsszegi
@ 2013-07-11 18:37             ` Jason Cooper
  2013-07-11 18:52               ` Tibor Harsszegi
  0 siblings, 1 reply; 39+ messages in thread
From: Jason Cooper @ 2013-07-11 18:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jul 11, 2013 at 08:32:42PM +0200, Tibor Harsszegi wrote:
> >On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
> >>Hello guys,
> >>
> >>can anyone explain me how does the gpio_blink_set member gets filled
> >>in leds-gpio through platform_get_drvdata()?
> >>I can't seem to follow how the specific function pointer can be set
> >>to orion_gpio_set_blink() for example.
> >>Sorry for the dumb question :(
> >Hi Tibor
> >
> >For DT based board, hardware blinking is not supported, as far as i
> >remember.
> >
> >	Andrew
> 
> Hello Andrew,
> 
> is there an example for "mixed machine setup" (if there is anything
> like that) ?
> I'm thinking about:
> 
> * DT based initialization starts
> * then if supported board based "after-DT-init-board-code" executes
> 
> similar what we have in board-*.c files just that it would be
> executed after kirkwood has initialized the board
> based upon the .DTB
> [I'm thinking about getting rid of the LED setup from the .DTB and
> move it back to .C land - at least for a trial]

As a testing hack, just add the following to board-dt.c:

	if (of_machine_is_compatible("keymile,whizbang-board")) {
		/* GPIO hackery here */
	}

hth,

Jason.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* gpio_blink_set + Kirkwood
  2013-07-11 18:37             ` Jason Cooper
@ 2013-07-11 18:52               ` Tibor Harsszegi
  2013-07-11 19:44                 ` Jason Cooper
  0 siblings, 1 reply; 39+ messages in thread
From: Tibor Harsszegi @ 2013-07-11 18:52 UTC (permalink / raw)
  To: linux-arm-kernel

On 2013-07-11 20:37, Jason Cooper wrote:
> On Thu, Jul 11, 2013 at 08:32:42PM +0200, Tibor Harsszegi wrote:
>>> On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
>>>> Hello guys,
>>>>
>>>> can anyone explain me how does the gpio_blink_set member gets filled
>>>> in leds-gpio through platform_get_drvdata()?
>>>> I can't seem to follow how the specific function pointer can be set
>>>> to orion_gpio_set_blink() for example.
>>>> Sorry for the dumb question :(
>>> Hi Tibor
>>>
>>> For DT based board, hardware blinking is not supported, as far as i
>>> remember.
>>>
>>> 	Andrew
>> Hello Andrew,
>>
>> is there an example for "mixed machine setup" (if there is anything
>> like that) ?
>> I'm thinking about:
>>
>> * DT based initialization starts
>> * then if supported board based "after-DT-init-board-code" executes
>>
>> similar what we have in board-*.c files just that it would be
>> executed after kirkwood has initialized the board
>> based upon the .DTB
>> [I'm thinking about getting rid of the LED setup from the .DTB and
>> move it back to .C land - at least for a trial]
> As a testing hack, just add the following to board-dt.c:
>
> 	if (of_machine_is_compatible("keymile,whizbang-board")) {
> 		/* GPIO hackery here */
> 	}
>
> hth,
>
> Jason.
Ok, but isn't board-dt.c is the very first thing (kinda) which is 
executed prior the .DTB is parsed
and executed?
E.g. if I add the GPIO hack there, I assume that kirkwood and orion is 
already initialized.
Or is the board-dt.c executed after the .DTB is loaded/parsed?
Thanks,

^ permalink raw reply	[flat|nested] 39+ messages in thread

* gpio_blink_set + Kirkwood
  2013-07-11 18:52               ` Tibor Harsszegi
@ 2013-07-11 19:44                 ` Jason Cooper
  0 siblings, 0 replies; 39+ messages in thread
From: Jason Cooper @ 2013-07-11 19:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Jul 11, 2013 at 08:52:08PM +0200, Tibor Harsszegi wrote:
> On 2013-07-11 20:37, Jason Cooper wrote:
> >On Thu, Jul 11, 2013 at 08:32:42PM +0200, Tibor Harsszegi wrote:
> >>>On Thu, Jul 11, 2013 at 06:20:02PM +0200, Tibor Harsszegi wrote:
> >>>>Hello guys,
> >>>>
> >>>>can anyone explain me how does the gpio_blink_set member gets filled
> >>>>in leds-gpio through platform_get_drvdata()?
> >>>>I can't seem to follow how the specific function pointer can be set
> >>>>to orion_gpio_set_blink() for example.
> >>>>Sorry for the dumb question :(
> >>>Hi Tibor
> >>>
> >>>For DT based board, hardware blinking is not supported, as far as i
> >>>remember.
> >>>
> >>>	Andrew
> >>Hello Andrew,
> >>
> >>is there an example for "mixed machine setup" (if there is anything
> >>like that) ?
> >>I'm thinking about:
> >>
> >>* DT based initialization starts
> >>* then if supported board based "after-DT-init-board-code" executes
> >>
> >>similar what we have in board-*.c files just that it would be
> >>executed after kirkwood has initialized the board
> >>based upon the .DTB
> >>[I'm thinking about getting rid of the LED setup from the .DTB and
> >>move it back to .C land - at least for a trial]
> >As a testing hack, just add the following to board-dt.c:
> >
> >	if (of_machine_is_compatible("keymile,whizbang-board")) {
> >		/* GPIO hackery here */
> >	}
> >
> >hth,
> >
> >Jason.
> Ok, but isn't board-dt.c is the very first thing (kinda) which is
> executed prior the .DTB is parsed
> and executed?
> E.g. if I add the GPIO hack there, I assume that kirkwood and orion
> is already initialized.
> Or is the board-dt.c executed after the .DTB is loaded/parsed?

The last line parses the dtb.  Perhaps late_initcall()?

hth,

Jason.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-10  7:37     ` Andrew Lunn
  2013-07-10  8:43       ` tibor at harsszegi.com
       [not found]       ` <51DEDB32.4080101@harsszegi.com>
@ 2013-07-29 17:05       ` Finn Hoffmann
  2013-07-29 19:21         ` Jason Cooper
  2 siblings, 1 reply; 39+ messages in thread
From: Finn Hoffmann @ 2013-07-29 17:05 UTC (permalink / raw)
  To: linux-arm-kernel

Hello,

I have tried to get a current Kernel running on my NSA310. Everything 
works well on Kernels before DT with the mentioned patches from 
https://github.com/peeter123/NSA310-320-debian .
I have linux-3.10.2 running and after I changed the dts file to lm85 
sensors and fanconrtol work but GPIO does not.
I tried https://github.com/lunn/linux/tree/v3.11-rc1-nsa310-tdc and 
linux-3.11.0-rc3.
Both have the problem that r8169 is not working:
r8169: eth0: unknown chipset (mac_version = 0).
and console is spammed with
r8169 0000:01:00.0 eth0: rtl_phyar_cond == 0 (loop: 20, delay: 25).
until I take eth0 down.
GPIO is working.

Any ideas?

Finn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-29 17:05       ` NSA310 + DT Finn Hoffmann
@ 2013-07-29 19:21         ` Jason Cooper
  2013-07-29 20:43           ` Andrew Lunn
  0 siblings, 1 reply; 39+ messages in thread
From: Jason Cooper @ 2013-07-29 19:21 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Finn,

On Mon, Jul 29, 2013 at 07:05:32PM +0200, Finn Hoffmann wrote:
> Hello,
> 
> I have tried to get a current Kernel running on my NSA310.

Nice.

> Everything works well on Kernels before DT with the mentioned
> patches from https://github.com/peeter123/NSA310-320-debian .
> I have linux-3.10.2 running and after I changed the dts file to lm85
> sensors and fanconrtol work but GPIO does not.
> I tried https://github.com/lunn/linux/tree/v3.11-rc1-nsa310-tdc and
> linux-3.11.0-rc3.
> Both have the problem that r8169 is not working:
> r8169: eth0: unknown chipset (mac_version = 0).
> and console is spammed with
> r8169 0000:01:00.0 eth0: rtl_phyar_cond == 0 (loop: 20, delay: 25).
> until I take eth0 down.
> GPIO is working.
> 
> Any ideas?

Adding Andrew Lunn to the Cc: as he is more familiar with those DT
changes.  In future, please Cc myself, Andrew, and Gregory Clement so we
don't miss the email.

thx,

Jason.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-29 19:21         ` Jason Cooper
@ 2013-07-29 20:43           ` Andrew Lunn
       [not found]             ` <51F78DA6.8010307@uni-bremen.de>
  0 siblings, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-29 20:43 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jul 29, 2013 at 03:21:12PM -0400, Jason Cooper wrote:
> Hi Finn,
> 
> On Mon, Jul 29, 2013 at 07:05:32PM +0200, Finn Hoffmann wrote:
> > Hello,
> > 
> > I have tried to get a current Kernel running on my NSA310.
> 
> Nice.
> 
> > Everything works well on Kernels before DT with the mentioned
> > patches from https://github.com/peeter123/NSA310-320-debian .
> > I have linux-3.10.2 running and after I changed the dts file to lm85
> > sensors and fanconrtol work but GPIO does not.
> > I tried https://github.com/lunn/linux/tree/v3.11-rc1-nsa310-tdc and
> > linux-3.11.0-rc3.
> > Both have the problem that r8169 is not working:
> > r8169: eth0: unknown chipset (mac_version = 0).
> > and console is spammed with
> > r8169 0000:01:00.0 eth0: rtl_phyar_cond == 0 (loop: 20, delay: 25).
> > until I take eth0 down.
> > GPIO is working.

Hi Finn

Thanks for testing my tree. I based it on the patches found in 
https://github.com/peeter123/NSA310-320-debian.

The patch-3.6.9-nsa310.diff does not contain any changes to the
ethernet driver. So you best bet is to ask on the netdev mailing
list.

Once you have it solved, it would be nice if you can send a tested-by:
signoff to my patches.

	Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
       [not found]                     ` <20130730191943.49f8070c@skate>
@ 2013-07-30 18:36                       ` Andrew Lunn
  2013-07-30 19:31                         ` Finn Hoffmann
  0 siblings, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-30 18:36 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jul 30, 2013 at 07:19:43PM +0200, Thomas Petazzoni wrote:
> Dear Finn Hoffmann,
> 
> BTW, any reason why this discussion is not taking place on LAKML ?

Ah, sorry, did not look at the CC: list. Now one list...

    Andrew

> 
> On Tue, 30 Jul 2013 18:37:13 +0200, Finn Hoffmann wrote:
> 
> > $ lspci -v
> > 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 
> > 00 [Normal decode])
> >          Flags: bus master, fast devsel, latency 0
> >          Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> >          I/O behind bridge: 00010000-00010fff
> >          Prefetchable memory behind bridge: e0000000-e00fffff
> 
> Ok, so there should be one mem window from e0000000 to e0100000...
> 
> > # cat /sys/kernel/debug/mvebu-mbus/devices
> > [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
> > [01] disabled
> > [02] disabled
> > [03] disabled
> > [04] 00000000f4000000 - 00000000f4010000 : nand
> > [05] 00000000f5000000 - 00000000f5010000 : sram
> > [06] disabled
> > [07] disabled
> 
> ... but there's none here.
> 
> Seems like your device is using a prefetchable memory window, and our
> emulated PCI-to-PCI bridge isn't taking this into account.
> 
> Can you test the below (completely untested) patch? Regardless of
> whether it works or not, I'm interested in seeing the "PCI MVEBU"
> debug messages that I've added, as well as the output
> of /sys/kernel/debug/mvebu-mbus/devices.
> 
> Thanks a lot!
> 
> Thomas
> 
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> index 13a633b..641dd3d 100644
> --- a/drivers/pci/host/pci-mvebu.c
> +++ b/drivers/pci/host/pci-mvebu.c
> @@ -129,6 +129,8 @@ struct mvebu_pcie_port {
>  	struct mvebu_pcie *pcie;
>  	phys_addr_t memwin_base;
>  	size_t memwin_size;
> +	phys_addr_t prefmemwin_base;
> +	size_t prefmemwin_size;
>  	phys_addr_t iowin_base;
>  	size_t iowin_size;
>  };
> @@ -348,6 +350,39 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
>  					  MVEBU_MBUS_PCI_MEM);
>  }
>  
> +static void mvebu_pcie_handle_prefmembase_change(struct mvebu_pcie_port *port)
> +{
> +	/* Are the new membase/memlimit values invalid? */
> +	if (port->bridge.prefmemlimit < port->bridge.prefmembase) {
> +
> +		/* If a window was configured, remove it */
> +		if (port->prefmemwin_base) {
> +			mvebu_mbus_del_window(port->prefmemwin_base,
> +					      port->prefmemwin_size);
> +			port->prefmemwin_base = 0;
> +			port->prefmemwin_size = 0;
> +		}
> +
> +		return;
> +	}
> +
> +	/*
> +	 * We read the PCI-to-PCI bridge emulated registers, and
> +	 * calculate the base address and size of the address decoding
> +	 * window to setup, according to the PCI-to-PCI bridge
> +	 * specifications.
> +	 */
> +	port->prefmemwin_base  = ((port->bridge.prefmembase & 0xFFF0) << 16);
> +	port->prefmemwin_size  =
> +		(((port->bridge.prefmemlimit & 0xFFF0) << 16) | 0xFFFFF) -
> +		port->prefmemwin_base;
> +
> +	mvebu_mbus_add_window_remap_flags(port->name, port->prefmemwin_base,
> +					  port->prefmemwin_size,
> +					  MVEBU_MBUS_NO_REMAP,
> +					  MVEBU_MBUS_PCI_MEM);
> +}
> +
>  /*
>   * Initialize the configuration space of the PCI-to-PCI bridge
>   * associated with the given PCIe interface.
> @@ -492,18 +527,28 @@ static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
>  		bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
>  		bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
>  		bridge->secondary_status = value >> 16;
> +		pr_info("MVEBU PCI %d.%d: new io, base 0x%x, limit 0x%x\n",
> +			port->port, port->lane,
> +			bridge->iobase, bridge->iolimit);
>  		mvebu_pcie_handle_iobase_change(port);
>  		break;
>  
>  	case PCI_MEMORY_BASE:
>  		bridge->membase = value & 0xffff;
>  		bridge->memlimit = value >> 16;
> +		pr_info("MVEBU PCI %d.%d: new mem, base 0x%x, limit 0x%x\n",
> +			port->port, port->lane,
> +			bridge->membase, bridge->memlimit);
>  		mvebu_pcie_handle_membase_change(port);
>  		break;
>  
>  	case PCI_PREF_MEMORY_BASE:
>  		bridge->prefmembase = value & 0xffff;
>  		bridge->prefmemlimit = value >> 16;
> +		pr_info("MVEBU PCI %d.%d: new pref mem, base 0x%x, limit 0x%x\n",
> +			port->port, port->lane,
> +			bridge->prefmembase, bridge->prefmemlimit);
> +		mvebu_pcie_handle_prefmembase_change(port);
>  		break;
>  
>  	case PCI_PREF_BASE_UPPER32:
> 
> 
> -- 
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-30 18:36                       ` Andrew Lunn
@ 2013-07-30 19:31                         ` Finn Hoffmann
  2013-07-30 19:42                           ` Andrew Lunn
  2013-07-30 21:23                           ` Thomas Petazzoni
  0 siblings, 2 replies; 39+ messages in thread
From: Finn Hoffmann @ 2013-07-30 19:31 UTC (permalink / raw)
  To: linux-arm-kernel


Am 30.07.2013 20:36, schrieb Andrew Lunn:
> On Tue, Jul 30, 2013 at 07:19:43PM +0200, Thomas Petazzoni wrote:
>> Dear Finn Hoffmann,
>>
>> BTW, any reason why this discussion is not taking place on LAKML ?
> Ah, sorry, did not look at the CC: list. Now one list...
>
>      Andrew
>
>> On Tue, 30 Jul 2013 18:37:13 +0200, Finn Hoffmann wrote:
>>
>>> $ lspci -v
>>> 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if
>>> 00 [Normal decode])
>>>           Flags: bus master, fast devsel, latency 0
>>>           Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>>>           I/O behind bridge: 00010000-00010fff
>>>           Prefetchable memory behind bridge: e0000000-e00fffff
>> Ok, so there should be one mem window from e0000000 to e0100000...
>>
>>> # cat /sys/kernel/debug/mvebu-mbus/devices
>>> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
>>> [01] disabled
>>> [02] disabled
>>> [03] disabled
>>> [04] 00000000f4000000 - 00000000f4010000 : nand
>>> [05] 00000000f5000000 - 00000000f5010000 : sram
>>> [06] disabled
>>> [07] disabled
>> ... but there's none here.
>>
>> Seems like your device is using a prefetchable memory window, and our
>> emulated PCI-to-PCI bridge isn't taking this into account.
>>
>> Can you test the below (completely untested) patch? Regardless of
>> whether it works or not, I'm interested in seeing the "PCI MVEBU"
>> debug messages that I've added, as well as the output
>> of /sys/kernel/debug/mvebu-mbus/devices.
>>
>> Thanks a lot!
>>
>> Thomas
# cat /sys/kernel/debug/mvebu-mbus/devices
[00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
[01] disabled
[02] disabled
[03] disabled
[04] 00000000f4000000 - 00000000f4010000 : nand
[05] 00000000f5000000 - 00000000f5010000 : sram
[06] 00000000fff00000 - 0000000100000000 : pcie0.0
[07] disabled


# lspci -v
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 
00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00010000-00010fff
Prefetchable memory behind bridge: e0000000-e00fffff

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev
03)
Subsystem: Realtek Semiconductor Co., Ltd. TEG-ECTX Gigabit PCI-E 
Adapter [Trendnet]
Flags: bus master, fast devsel, latency 0, IRQ 9
I/O ports at 10000 [size=256]
Memory at e0014000 (64-bit, prefetchable) [size=4K]
Memory at e0010000 (64-bit, prefetchable) [size=16K]
[virtual] Expansion ROM at e0000000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
Capabilities: [cc] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: r8169




3122350 bytes read
## Booting image at 00800000 ...
Image Name: Linux-3.11.0-rc3
Created: 2013-07-30 18:56:55 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3122286 Bytes = 3 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.11.0-rc3 (finn at T400) (gcc version 4.7.3 (Ubuntu/Linaro 
4.7.3-1ubuntu1) ) #2 PREEMPT Tue Jul 30
20:56:41 CEST 2013
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell Kirkwood (Flattened Device Tree), model: ZyXEL NSA310
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda2
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: 253156K/262144K available (4404K kernel code, 243K rwdata, 1216K 
rodata, 151K init, 615K bss, 8988K reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc0585248 (5621 kB)
.init : 0xc0586000 - 0xc05abcc4 ( 152 kB)
.data : 0xc05ac000 - 0xc05e8fe0 ( 244 kB)
.bss : 0xc05e8fe0 - 0xc0682d60 ( 616 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 21474ms
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc042fe08 - 0xc042fe44
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Kirkwood: MV88F6281-A1, TCLK=200000000.
Feroceon L2: Enabling L2
Feroceon L2: Cache support initialised.
bio: create slab <bio-0> at 0
mvebu-pcie pcie-controller.1: PCIe0.0: link up
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-0xe7ffffff]
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
MVEBU PCI 0.0: new pref mem, base 0xfff0, limit 0xfff0
MVEBU PCI 0.0: new pref mem, base 0x0, limit 0x0
mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window
pci 0000:00:01.0: BAR 9: assigned [mem 0xe0000000-0xe00fffff pref]
pci 0000:00:01.0: BAR 7: assigned [io 0x10000-0x10fff]
pci 0000:01:00.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
pci 0000:01:00.0: BAR 0: assigned [io 0x10000-0x100ff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0: bridge window [io 0x10000-0x10fff]
MVEBU PCI 0.0: new io, base 0x1, limit 0x1
MVEBU PCI 0.0: new mem, base 0xfff0, limit 0x0
pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe00fffff pref]
MVEBU PCI 0.0: new pref mem, base 0xe000, limit 0xe000
mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window
PCI: enabling device 0000:00:01.0 (0140 -> 0143)
USB Power Off: Failed to request enable GPIO21: -517
reg-fixed-voltage 1.regulator: Failed to register regulator: -517
platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
vgaarb: loaded
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
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: 2, 16384 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.
jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
msgmni has been set to 494
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
kirkwood-pinctrl f1010000.pinctrl: registered pinctrl driver
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) is a 16550A
console [ttyS0] enabled
loop: module loaded
sata_mv f1080000.sata: slots 32 ports 2
scsi0 : sata_mv
scsi1 : sata_mv
ata1: SATA max UDMA/133 irq 21
ata2: SATA max UDMA/133 irq 21
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 
3,3V 8-bit), 128MiB, page size: 2048, OOB size: 6
4
Scanning device for bad blocks
Bad eraseblock 249 at 0x000001f20000
9 ofpart partitions found on MTD device orion_nand
Creating 9 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "uboot"
0x000000100000-0x000000180000 : "uboot_env"
0x000000180000-0x000000200000 : "key_store"
0x000000200000-0x000000280000 : "info"
0x000000280000-0x000000c80000 : "etc"
0x000000c80000-0x000001680000 : "kernel_1"
0x000001680000-0x000004640000 : "rootfs1"
0x000004640000-0x000005040000 : "kernel_2"
0x000005040000-0x000008000000 : "rootfs2"
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:01:00.0 eth0: RTL8169 at 0xd092e000, 00:00:00:00:00:00, XID 
00000000 IRQ 9
r8169 0000:01:00.0 eth0: jumbo features [frames: 7152 bytes, tx 
checksumming: ok]
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 19, 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
rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
i2c /dev entries driver
orion_wdt: Initial timeout 21 sec
cpuidle: using governor ladder
cpuidle: using governor menu
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
USB Power Off: 5000 mV
input: gpio_keys.2 as /devices/gpio_keys.2/input/input0
rtc-mv f1010300.rtc: setting system clock to 2013-07-30 19:25:09 UTC 
(1375212309)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: ATA-8: ST31500541AS, CC32, max UDMA/133
ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32)
usb 1-1: new high-speed USB device number 2 using orion-ehci
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA ST31500541AS CC32 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't 
support DPO or FUA
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
sd 0:0:0:0: [sda] Attached SCSI disk
ata2: SATA link down (SStatus 0 SControl F300)
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.
Freeing unused kernel memory: 148K (c0586000 - c05ab000)
INIT: version 2.88 booting

>> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
>> index 13a633b..641dd3d 100644
>> --- a/drivers/pci/host/pci-mvebu.c
>> +++ b/drivers/pci/host/pci-mvebu.c
>> @@ -129,6 +129,8 @@ struct mvebu_pcie_port {
>>   	struct mvebu_pcie *pcie;
>>   	phys_addr_t memwin_base;
>>   	size_t memwin_size;
>> +	phys_addr_t prefmemwin_base;
>> +	size_t prefmemwin_size;
>>   	phys_addr_t iowin_base;
>>   	size_t iowin_size;
>>   };
>> @@ -348,6 +350,39 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
>>   					  MVEBU_MBUS_PCI_MEM);
>>   }
>>   
>> +static void mvebu_pcie_handle_prefmembase_change(struct mvebu_pcie_port *port)
>> +{
>> +	/* Are the new membase/memlimit values invalid? */
>> +	if (port->bridge.prefmemlimit < port->bridge.prefmembase) {
>> +
>> +		/* If a window was configured, remove it */
>> +		if (port->prefmemwin_base) {
>> +			mvebu_mbus_del_window(port->prefmemwin_base,
>> +					      port->prefmemwin_size);
>> +			port->prefmemwin_base = 0;
>> +			port->prefmemwin_size = 0;
>> +		}
>> +
>> +		return;
>> +	}
>> +
>> +	/*
>> +	 * We read the PCI-to-PCI bridge emulated registers, and
>> +	 * calculate the base address and size of the address decoding
>> +	 * window to setup, according to the PCI-to-PCI bridge
>> +	 * specifications.
>> +	 */
>> +	port->prefmemwin_base  = ((port->bridge.prefmembase & 0xFFF0) << 16);
>> +	port->prefmemwin_size  =
>> +		(((port->bridge.prefmemlimit & 0xFFF0) << 16) | 0xFFFFF) -
>> +		port->prefmemwin_base;
>> +
>> +	mvebu_mbus_add_window_remap_flags(port->name, port->prefmemwin_base,
>> +					  port->prefmemwin_size,
>> +					  MVEBU_MBUS_NO_REMAP,
>> +					  MVEBU_MBUS_PCI_MEM);
>> +}
>> +
>>   /*
>>    * Initialize the configuration space of the PCI-to-PCI bridge
>>    * associated with the given PCIe interface.
>> @@ -492,18 +527,28 @@ static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
>>   		bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
>>   		bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
>>   		bridge->secondary_status = value >> 16;
>> +		pr_info("MVEBU PCI %d.%d: new io, base 0x%x, limit 0x%x\n",
>> +			port->port, port->lane,
>> +			bridge->iobase, bridge->iolimit);
>>   		mvebu_pcie_handle_iobase_change(port);
>>   		break;
>>   
>>   	case PCI_MEMORY_BASE:
>>   		bridge->membase = value & 0xffff;
>>   		bridge->memlimit = value >> 16;
>> +		pr_info("MVEBU PCI %d.%d: new mem, base 0x%x, limit 0x%x\n",
>> +			port->port, port->lane,
>> +			bridge->membase, bridge->memlimit);
>>   		mvebu_pcie_handle_membase_change(port);
>>   		break;
>>   
>>   	case PCI_PREF_MEMORY_BASE:
>>   		bridge->prefmembase = value & 0xffff;
>>   		bridge->prefmemlimit = value >> 16;
>> +		pr_info("MVEBU PCI %d.%d: new pref mem, base 0x%x, limit 0x%x\n",
>> +			port->port, port->lane,
>> +			bridge->prefmembase, bridge->prefmemlimit);
>> +		mvebu_pcie_handle_prefmembase_change(port);
>>   		break;
>>   
>>   	case PCI_PREF_BASE_UPPER32:
>>
>>
>> -- 
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-30 19:31                         ` Finn Hoffmann
@ 2013-07-30 19:42                           ` Andrew Lunn
  2013-07-30 21:23                           ` Thomas Petazzoni
  1 sibling, 0 replies; 39+ messages in thread
From: Andrew Lunn @ 2013-07-30 19:42 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jul 30, 2013 at 09:31:44PM +0200, Finn Hoffmann wrote:
> 
> Am 30.07.2013 20:36, schrieb Andrew Lunn:
> >On Tue, Jul 30, 2013 at 07:19:43PM +0200, Thomas Petazzoni wrote:
> >>Dear Finn Hoffmann,
> >>
> >>BTW, any reason why this discussion is not taking place on LAKML ?
> >Ah, sorry, did not look at the CC: list. Now one list...
> >
> >     Andrew
> >
> >>On Tue, 30 Jul 2013 18:37:13 +0200, Finn Hoffmann wrote:
> >>
> >>>$ lspci -v
> >>>00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if
> >>>00 [Normal decode])
> >>>          Flags: bus master, fast devsel, latency 0
> >>>          Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> >>>          I/O behind bridge: 00010000-00010fff
> >>>          Prefetchable memory behind bridge: e0000000-e00fffff
> >>Ok, so there should be one mem window from e0000000 to e0100000...
> >>
> >>># cat /sys/kernel/debug/mvebu-mbus/devices
> >>>[00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
> >>>[01] disabled
> >>>[02] disabled
> >>>[03] disabled
> >>>[04] 00000000f4000000 - 00000000f4010000 : nand
> >>>[05] 00000000f5000000 - 00000000f5010000 : sram
> >>>[06] disabled
> >>>[07] disabled
> >>... but there's none here.
> >>
> >>Seems like your device is using a prefetchable memory window, and our
> >>emulated PCI-to-PCI bridge isn't taking this into account.
> >>
> >>Can you test the below (completely untested) patch? Regardless of
> >>whether it works or not, I'm interested in seeing the "PCI MVEBU"
> >>debug messages that I've added, as well as the output
> >>of /sys/kernel/debug/mvebu-mbus/devices.
> >>
> >>Thanks a lot!
> >>
> >>Thomas
> # cat /sys/kernel/debug/mvebu-mbus/devices
> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
> [01] disabled
> [02] disabled
> [03] disabled
> [04] 00000000f4000000 - 00000000f4010000 : nand
> [05] 00000000f5000000 - 00000000f5010000 : sram
> [06] 00000000fff00000 - 0000000100000000 : pcie0.0
> [07] disabled
> 
> 
> # lspci -v
> 00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846
> (prog-if 00 [Normal decode])
> Flags: bus master, fast devsel, latency 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 00010000-00010fff
> Prefetchable memory behind bridge: e0000000-e00fffff
> 
> 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168B PCI Express Gigabit Ethernet controller (rev
> 03)
> Subsystem: Realtek Semiconductor Co., Ltd. TEG-ECTX Gigabit PCI-E
> Adapter [Trendnet]
> Flags: bus master, fast devsel, latency 0, IRQ 9
> I/O ports at 10000 [size=256]
> Memory at e0014000 (64-bit, prefetchable) [size=4K]
> Memory at e0010000 (64-bit, prefetchable) [size=16K]
> [virtual] Expansion ROM at e0000000 [disabled] [size=64K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Endpoint, MSI 01
> Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
> Capabilities: [cc] Vital Product Data
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
> Kernel driver in use: r8169
> 
> 
> 
> 
> 3122350 bytes read
> ## Booting image at 00800000 ...
> Image Name: Linux-3.11.0-rc3
> Created: 2013-07-30 18:56:55 UTC
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 3122286 Bytes = 3 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.11.0-rc3 (finn at T400) (gcc version 4.7.3
> (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #2 PREEMPT Tue Jul 30
> 20:56:41 CEST 2013
> CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
> CPU: VIVT data cache, VIVT instruction cache
> Machine: Marvell Kirkwood (Flattened Device Tree), model: ZyXEL NSA310
> Memory policy: ECC disabled, Data cache writeback
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
> Kernel command line: console=ttyS0,115200 root=/dev/sda2
> 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: 253156K/262144K available (4404K kernel code, 243K rwdata,
> 1216K rodata, 151K init, 615K bss, 8988K reserved)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
> vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
> lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0xc0008000 - 0xc0585248 (5621 kB)
> .init : 0xc0586000 - 0xc05abcc4 ( 152 kB)
> .data : 0xc05ac000 - 0xc05e8fe0 ( 244 kB)
> .bss : 0xc05e8fe0 - 0xc0682d60 ( 616 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 21474ms
> Console: colour dummy device 80x30
> Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 512
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc042fe08 - 0xc042fe44
> pinctrl core: initialized pinctrl subsystem
> regulator-dummy: no parameters
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Kirkwood: MV88F6281-A1, TCLK=200000000.
> Feroceon L2: Enabling L2
> Feroceon L2: Cache support initialised.
> bio: create slab <bio-0> at 0
> mvebu-pcie pcie-controller.1: PCIe0.0: link up
> 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-0xe7ffffff]
> 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
> MVEBU PCI 0.0: new pref mem, base 0xfff0, limit 0xfff0
> MVEBU PCI 0.0: new pref mem, base 0x0, limit 0x0
> mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window

Hi Thomas

That does not look good, does it?

     Andrew

> pci 0000:00:01.0: BAR 9: assigned [mem 0xe0000000-0xe00fffff pref]
> pci 0000:00:01.0: BAR 7: assigned [io 0x10000-0x10fff]
> pci 0000:01:00.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
> pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
> pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
> pci 0000:01:00.0: BAR 0: assigned [io 0x10000-0x100ff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0: bridge window [io 0x10000-0x10fff]
> MVEBU PCI 0.0: new io, base 0x1, limit 0x1
> MVEBU PCI 0.0: new mem, base 0xfff0, limit 0x0
> pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe00fffff pref]
> MVEBU PCI 0.0: new pref mem, base 0xe000, limit 0xe000
> mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window
> PCI: enabling device 0000:00:01.0 (0140 -> 0143)
> USB Power Off: Failed to request enable GPIO21: -517
> reg-fixed-voltage 1.regulator: Failed to register regulator: -517
> platform 1.regulator: Driver reg-fixed-voltage requests probe deferral
> vgaarb: loaded
> SCSI subsystem initialized
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> 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: 2, 16384 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.
> jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
> msgmni has been set to 494
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> kirkwood-pinctrl f1010000.pinctrl: registered pinctrl driver
> 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) is a 16550A
> console [ttyS0] enabled
> loop: module loaded
> sata_mv f1080000.sata: slots 32 ports 2
> scsi0 : sata_mv
> scsi1 : sata_mv
> ata1: SATA max UDMA/133 irq 21
> ata2: SATA max UDMA/133 irq 21
> NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND
> 128MiB 3,3V 8-bit), 128MiB, page size: 2048, OOB size: 6
> 4
> Scanning device for bad blocks
> Bad eraseblock 249 at 0x000001f20000
> 9 ofpart partitions found on MTD device orion_nand
> Creating 9 MTD partitions on "orion_nand":
> 0x000000000000-0x000000100000 : "uboot"
> 0x000000100000-0x000000180000 : "uboot_env"
> 0x000000180000-0x000000200000 : "key_store"
> 0x000000200000-0x000000280000 : "info"
> 0x000000280000-0x000000c80000 : "etc"
> 0x000000c80000-0x000001680000 : "kernel_1"
> 0x000001680000-0x000004640000 : "rootfs1"
> 0x000004640000-0x000005040000 : "kernel_2"
> 0x000005040000-0x000008000000 : "rootfs2"
> r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> r8169 0000:01:00.0 eth0: RTL8169 at 0xd092e000, 00:00:00:00:00:00,
> XID 00000000 IRQ 9
> r8169 0000:01:00.0 eth0: jumbo features [frames: 7152 bytes, tx
> checksumming: ok]
> 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 19, 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
> rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
> i2c /dev entries driver
> orion_wdt: Initial timeout 21 sec
> cpuidle: using governor ladder
> cpuidle: using governor menu
> 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
> USB Power Off: 5000 mV
> input: gpio_keys.2 as /devices/gpio_keys.2/input/input0
> rtc-mv f1010300.rtc: setting system clock to 2013-07-30 19:25:09 UTC
> (1375212309)
> ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
> ata1.00: ATA-8: ST31500541AS, CC32, max UDMA/133
> ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> usb 1-1: new high-speed USB device number 2 using orion-ehci
> ata1.00: configured for UDMA/133
> scsi 0:0:0:0: Direct-Access ATA ST31500541AS CC32 PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
> support DPO or FUA
> hub 1-1:1.0: USB hub found
> hub 1-1:1.0: 4 ports detected
> sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
> sd 0:0:0:0: [sda] Attached SCSI disk
> ata2: SATA link down (SStatus 0 SControl F300)
> 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.
> Freeing unused kernel memory: 148K (c0586000 - c05ab000)
> INIT: version 2.88 booting
> 
> >>diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> >>index 13a633b..641dd3d 100644
> >>--- a/drivers/pci/host/pci-mvebu.c
> >>+++ b/drivers/pci/host/pci-mvebu.c
> >>@@ -129,6 +129,8 @@ struct mvebu_pcie_port {
> >>  	struct mvebu_pcie *pcie;
> >>  	phys_addr_t memwin_base;
> >>  	size_t memwin_size;
> >>+	phys_addr_t prefmemwin_base;
> >>+	size_t prefmemwin_size;
> >>  	phys_addr_t iowin_base;
> >>  	size_t iowin_size;
> >>  };
> >>@@ -348,6 +350,39 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
> >>  					  MVEBU_MBUS_PCI_MEM);
> >>  }
> >>+static void mvebu_pcie_handle_prefmembase_change(struct mvebu_pcie_port *port)
> >>+{
> >>+	/* Are the new membase/memlimit values invalid? */
> >>+	if (port->bridge.prefmemlimit < port->bridge.prefmembase) {
> >>+
> >>+		/* If a window was configured, remove it */
> >>+		if (port->prefmemwin_base) {
> >>+			mvebu_mbus_del_window(port->prefmemwin_base,
> >>+					      port->prefmemwin_size);
> >>+			port->prefmemwin_base = 0;
> >>+			port->prefmemwin_size = 0;
> >>+		}
> >>+
> >>+		return;
> >>+	}
> >>+
> >>+	/*
> >>+	 * We read the PCI-to-PCI bridge emulated registers, and
> >>+	 * calculate the base address and size of the address decoding
> >>+	 * window to setup, according to the PCI-to-PCI bridge
> >>+	 * specifications.
> >>+	 */
> >>+	port->prefmemwin_base  = ((port->bridge.prefmembase & 0xFFF0) << 16);
> >>+	port->prefmemwin_size  =
> >>+		(((port->bridge.prefmemlimit & 0xFFF0) << 16) | 0xFFFFF) -
> >>+		port->prefmemwin_base;
> >>+
> >>+	mvebu_mbus_add_window_remap_flags(port->name, port->prefmemwin_base,
> >>+					  port->prefmemwin_size,
> >>+					  MVEBU_MBUS_NO_REMAP,
> >>+					  MVEBU_MBUS_PCI_MEM);
> >>+}
> >>+
> >>  /*
> >>   * Initialize the configuration space of the PCI-to-PCI bridge
> >>   * associated with the given PCIe interface.
> >>@@ -492,18 +527,28 @@ static int mvebu_sw_pci_bridge_write(struct mvebu_pcie_port *port,
> >>  		bridge->iobase = (value & 0xff) | PCI_IO_RANGE_TYPE_32;
> >>  		bridge->iolimit = ((value >> 8) & 0xff) | PCI_IO_RANGE_TYPE_32;
> >>  		bridge->secondary_status = value >> 16;
> >>+		pr_info("MVEBU PCI %d.%d: new io, base 0x%x, limit 0x%x\n",
> >>+			port->port, port->lane,
> >>+			bridge->iobase, bridge->iolimit);
> >>  		mvebu_pcie_handle_iobase_change(port);
> >>  		break;
> >>  	case PCI_MEMORY_BASE:
> >>  		bridge->membase = value & 0xffff;
> >>  		bridge->memlimit = value >> 16;
> >>+		pr_info("MVEBU PCI %d.%d: new mem, base 0x%x, limit 0x%x\n",
> >>+			port->port, port->lane,
> >>+			bridge->membase, bridge->memlimit);
> >>  		mvebu_pcie_handle_membase_change(port);
> >>  		break;
> >>  	case PCI_PREF_MEMORY_BASE:
> >>  		bridge->prefmembase = value & 0xffff;
> >>  		bridge->prefmemlimit = value >> 16;
> >>+		pr_info("MVEBU PCI %d.%d: new pref mem, base 0x%x, limit 0x%x\n",
> >>+			port->port, port->lane,
> >>+			bridge->prefmembase, bridge->prefmemlimit);
> >>+		mvebu_pcie_handle_prefmembase_change(port);
> >>  		break;
> >>  	case PCI_PREF_BASE_UPPER32:
> >>
> >>
> >>-- 
> >>Thomas Petazzoni, Free Electrons
> >>Kernel, drivers, real-time and embedded Linux
> >>development, consulting, training and support.
> >>http://free-electrons.com
> >_______________________________________________
> >linux-arm-kernel mailing list
> >linux-arm-kernel at lists.infradead.org
> >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-30 19:31                         ` Finn Hoffmann
  2013-07-30 19:42                           ` Andrew Lunn
@ 2013-07-30 21:23                           ` Thomas Petazzoni
  2013-07-31  9:14                             ` Thomas Petazzoni
  1 sibling, 1 reply; 39+ messages in thread
From: Thomas Petazzoni @ 2013-07-30 21:23 UTC (permalink / raw)
  To: linux-arm-kernel

Dear Finn Hoffmann,

On Tue, 30 Jul 2013 21:31:44 +0200, Finn Hoffmann wrote:
> # cat /sys/kernel/debug/mvebu-mbus/devices
> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
> [01] disabled
> [02] disabled
> [03] disabled
> [04] 00000000f4000000 - 00000000f4010000 : nand
> [05] 00000000f5000000 - 00000000f5010000 : sram
> [06] 00000000fff00000 - 0000000100000000 : pcie0.0

Ok, now we have a memory window created, which looks better, but its
addresses are wrong.

> mvebu-pcie pcie-controller.1: PCIe0.0: link up
> 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-0xe7ffffff]
> 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
> MVEBU PCI 0.0: new pref mem, base 0xfff0, limit 0xfff0
> MVEBU PCI 0.0: new pref mem, base 0x0, limit 0x0
> mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window
> pci 0000:00:01.0: BAR 9: assigned [mem 0xe0000000-0xe00fffff pref]
> pci 0000:00:01.0: BAR 7: assigned [io 0x10000-0x10fff]
> pci 0000:01:00.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref]
> pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
> pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
> pci 0000:01:00.0: BAR 0: assigned [io 0x10000-0x100ff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0: bridge window [io 0x10000-0x10fff]
> MVEBU PCI 0.0: new io, base 0x1, limit 0x1
> MVEBU PCI 0.0: new mem, base 0xfff0, limit 0x0
> pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe00fffff pref]
> MVEBU PCI 0.0: new pref mem, base 0xe000, limit 0xe000
> mvebu_mbus: cannot add window 'pcie0.0', conflicts with another window

Thanks for this log. I need a bit of time to analyze this with the
PCI-to-PCI bridge specification, and I'll cook up a new patch,
hopefully tomorrow.

Thanks again a lot for taking the time to report this bug and test the
patches,

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-30 21:23                           ` Thomas Petazzoni
@ 2013-07-31  9:14                             ` Thomas Petazzoni
  2013-07-31  9:43                               ` Finn Hoffmann
  0 siblings, 1 reply; 39+ messages in thread
From: Thomas Petazzoni @ 2013-07-31  9:14 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Finn,

On Tue, 30 Jul 2013 23:23:16 +0200, Thomas Petazzoni wrote:

> Thanks for this log. I need a bit of time to analyze this with the
> PCI-to-PCI bridge specification, and I'll cook up a new patch,
> hopefully tomorrow.
> 
> Thanks again a lot for taking the time to report this bug and test the
> patches,

Ok, here is another patch that completely disables prefetchable
support, which hopefully should make the PCI stuff fallback on normal
memory. Could you try this one, and again report lspci -v + the
contents of the debugfs file that lists the mbus windows?

I've worked more on the prefetchable support, but doing it right with
the PCI-to-PCI bridge emulation is a bit complex.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-pci-mvebu-disable-prefetchable-memory-support.patch
Type: text/x-patch
Size: 1780 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130731/bce3bb46/attachment.bin>

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-31  9:14                             ` Thomas Petazzoni
@ 2013-07-31  9:43                               ` Finn Hoffmann
  2013-07-31  9:51                                 ` Thomas Petazzoni
  0 siblings, 1 reply; 39+ messages in thread
From: Finn Hoffmann @ 2013-07-31  9:43 UTC (permalink / raw)
  To: linux-arm-kernel


Am 31.07.2013 11:14, schrieb Thomas Petazzoni:
> Hello Finn,
>
> On Tue, 30 Jul 2013 23:23:16 +0200, Thomas Petazzoni wrote:
>
>> Thanks for this log. I need a bit of time to analyze this with the
>> PCI-to-PCI bridge specification, and I'll cook up a new patch,
>> hopefully tomorrow.
>>
>> Thanks again a lot for taking the time to report this bug and test the
>> patches,
> Ok, here is another patch that completely disables prefetchable
> support, which hopefully should make the PCI stuff fallback on normal
> memory. Could you try this one, and again report lspci -v + the
> contents of the debugfs file that lists the mbus windows?
>
> I've worked more on the prefetchable support, but doing it right with
> the PCI-to-PCI bridge emulation is a bit complex.
>
> Thanks!
>
> Thomas
>
Hi Thomas,
here you are.
Network is working.
Thanks
Finn


$ lspci -v
00:01.0 PCI bridge: Marvell Technology Group Ltd. Device 7846 (prog-if 
00 [Normal decode])
         Flags: bus master, fast devsel, latency 0
         Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
         I/O behind bridge: 00010000-00010fff
         Memory behind bridge: e0000000-e00fffff
         Prefetchable memory behind bridge: 00000000-000fffff

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev)
         Subsystem: Realtek Semiconductor Co., Ltd. TEG-ECTX Gigabit 
PCI-E Adapter [Trendnet]
         Flags: bus master, fast devsel, latency 0, IRQ 9
         I/O ports at 10000 [size=256]
         Memory at e0014000 (64-bit, prefetchable) [size=4K]
         Memory at e0010000 (64-bit, prefetchable) [size=16K]
         [virtual] Expansion ROM at e0000000 [disabled] [size=64K]
         Capabilities: <access denied>
         Kernel driver in use: r8169

# cat /sys/kernel/debug/mvebu-mbus/devices
[00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap 0000000000010000)
[01] disabled
[02] disabled
[03] disabled
[04] 00000000f4000000 - 00000000f4010000 : nand
[05] 00000000f5000000 - 00000000f5010000 : sram
[06] 00000000e0000000 - 00000000e0100000 : pcie0.0
[07] disabled

bootlog excerpt:
mvebu-pcie pcie-controller.1: PCIe0.0: link up
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-0xe7ffffff]
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 6: assigned [mem 0xe0000000-0xe000ffff pref]
pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref]
pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref]
pci 0000:01:00.0: BAR 0: assigned [io  0x10000-0x100ff]
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]
PCI: enabling device 0000:00:01.0 (0140 -> 0143)

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-31  9:43                               ` Finn Hoffmann
@ 2013-07-31  9:51                                 ` Thomas Petazzoni
  2013-07-31 11:41                                   ` Finn Hoffmann
  2013-08-02  8:35                                   ` Finn Hoffmann
  0 siblings, 2 replies; 39+ messages in thread
From: Thomas Petazzoni @ 2013-07-31  9:51 UTC (permalink / raw)
  To: linux-arm-kernel

Dear Finn Hoffmann,

On Wed, 31 Jul 2013 11:43:22 +0200, Finn Hoffmann wrote:

> Hi Thomas,
> here you are.
> Network is working.

Excellent, thanks!

> # cat /sys/kernel/debug/mvebu-mbus/devices
> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap
> 0000000000010000) [01] disabled
> [02] disabled
> [03] disabled
> [04] 00000000f4000000 - 00000000f4010000 : nand
> [05] 00000000f5000000 - 00000000f5010000 : sram
> [06] 00000000e0000000 - 00000000e0100000 : pcie0.0
> [07] disabled

Now this looks good, we have both the PCIe memory and PCIe I/O windows
created.

I'll clean up the patch and send it, hopefully for the final 3.11.

Thanks again for all your testing!

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-31  9:51                                 ` Thomas Petazzoni
@ 2013-07-31 11:41                                   ` Finn Hoffmann
  2013-07-31 11:47                                     ` Thomas Petazzoni
  2013-07-31 16:45                                     ` Andrew Lunn
  2013-08-02  8:35                                   ` Finn Hoffmann
  1 sibling, 2 replies; 39+ messages in thread
From: Finn Hoffmann @ 2013-07-31 11:41 UTC (permalink / raw)
  To: linux-arm-kernel


Am 31.07.2013 11:51, schrieb Thomas Petazzoni:
> Dear Finn Hoffmann,
>
> On Wed, 31 Jul 2013 11:43:22 +0200, Finn Hoffmann wrote:
>
>> Hi Thomas,
>> here you are.
>> Network is working.
> Excellent, thanks!
>
>> # cat /sys/kernel/debug/mvebu-mbus/devices
>> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap
>> 0000000000010000) [01] disabled
>> [02] disabled
>> [03] disabled
>> [04] 00000000f4000000 - 00000000f4010000 : nand
>> [05] 00000000f5000000 - 00000000f5010000 : sram
>> [06] 00000000e0000000 - 00000000e0100000 : pcie0.0
>> [07] disabled
> Now this looks good, we have both the PCIe memory and PCIe I/O windows
> created.
>
> I'll clean up the patch and send it, hopefully for the final 3.11.
>
> Thanks again for all your testing!
>
> Best regards,
>
> Thomas
Thomas, thank you for your Work.

I have a question about LED's:
Is it possible to have the powerled blinking while kernel is loading? 
Right now all LED's are turned off when the kernel starts.

I came across one curious thing: With Andrews kernel I had:
$ sensors
adt7476-i2c-0-2e
Adapter: mv64xxx_i2c adapter
in0: +1.82 V (min = +0.00 V, max = +3.31 V)
in1: +1.09 V (min = +0.00 V, max = +2.99 V)
in2: +3.27 V (min = +2.98 V, max = +3.63 V)
in3: +5.12 V (min = +4.53 V, max = +5.52 V)
in4: +11.98 V (min = +0.00 V, max = +15.69 V)
fan1: 4330 RPM (min = 0 RPM)
fan2: 0 RPM (min = 0 RPM)
fan3: 0 RPM (min = 0 RPM)
fan4: 0 RPM (min = 0 RPM)
temp1: +32.2??C (low = -127.0??C, high = +127.0??C)
(crit = +100.0??C, hyst = +96.0??C)
temp2: +32.5??C (low = -127.0??C, high = +127.0??C)
(crit = +100.0??C, hyst = +96.0??C)
temp3: +41.0??C (low = -127.0??C, high = +127.0??C)
(crit = +100.0??C, hyst = +96.0??C)
cpu0_vid: +0.000 V

normally I have:
# sensors
lm85-i2c-0-2e
Adapter: mv64xxx_i2c adapter
in0: +1.82 V (min = +0.00 V, max = +3.32 V)
Vcore: +1.07 V (min = +0.00 V, max = +2.99 V)
+3.3V: +3.25 V (min = +2.97 V, max = +3.63 V)
+5V: +5.05 V (min = +4.50 V, max = +5.50 V)
+12V: +12.12 V (min = +0.00 V, max = +15.94 V)
fan1: 2480 RPM (min = 0 RPM)
temp1: +35.0?C (low = -127.0?C, high = +127.0?C)
temp2: +34.0?C (low = -127.0?C, high = +127.0?C)
temp3: +47.0?C (low = -127.0?C, high = +127.0?C)

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-31 11:41                                   ` Finn Hoffmann
@ 2013-07-31 11:47                                     ` Thomas Petazzoni
  2013-07-31 16:45                                     ` Andrew Lunn
  1 sibling, 0 replies; 39+ messages in thread
From: Thomas Petazzoni @ 2013-07-31 11:47 UTC (permalink / raw)
  To: linux-arm-kernel

Dear Finn Hoffmann,

On Wed, 31 Jul 2013 13:41:23 +0200, Finn Hoffmann wrote:

> I have a question about LED's:
> Is it possible to have the powerled blinking while kernel is loading? 
> Right now all LED's are turned off when the kernel starts.

Yes, you can set a default trigger for GPIO LEDs. Just edit the
kirkwood-nsa310.dts file and add:

	linux,default-trigger	= "heartbeat";

into the GPIO LED that you want to see blinking once the kernel is
running. Note that it won't be blinking while the kernel is loading
(because loading the kernel is done by the bootloader), but it will
start blinking as soon as the kernel has initialized the GPIO LEDs.

> I came across one curious thing: With Andrews kernel I had:
> $ sensors
> adt7476-i2c-0-2e
> Adapter: mv64xxx_i2c adapter
> in0: +1.82 V (min = +0.00 V, max = +3.31 V)
> in1: +1.09 V (min = +0.00 V, max = +2.99 V)
> in2: +3.27 V (min = +2.98 V, max = +3.63 V)
> in3: +5.12 V (min = +4.53 V, max = +5.52 V)
> in4: +11.98 V (min = +0.00 V, max = +15.69 V)
> fan1: 4330 RPM (min = 0 RPM)
> fan2: 0 RPM (min = 0 RPM)
> fan3: 0 RPM (min = 0 RPM)
> fan4: 0 RPM (min = 0 RPM)
> temp1: +32.2??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> temp2: +32.5??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> temp3: +41.0??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> cpu0_vid: +0.000 V
> 
> normally I have:
> # sensors
> lm85-i2c-0-2e
> Adapter: mv64xxx_i2c adapter
> in0: +1.82 V (min = +0.00 V, max = +3.32 V)
> Vcore: +1.07 V (min = +0.00 V, max = +2.99 V)
> +3.3V: +3.25 V (min = +2.97 V, max = +3.63 V)
> +5V: +5.05 V (min = +4.50 V, max = +5.50 V)
> +12V: +12.12 V (min = +0.00 V, max = +15.94 V)
> fan1: 2480 RPM (min = 0 RPM)
> temp1: +35.0?C (low = -127.0?C, high = +127.0?C)
> temp2: +34.0?C (low = -127.0?C, high = +127.0?C)
> temp3: +47.0?C (low = -127.0?C, high = +127.0?C)

I am not sure to understand which one you believe is correct and which
one is wrong, and how the wrong one is wrong. But I don't have much
sensor experience, maybe Andrew has more knowledge than me on this
stuff.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-31 11:41                                   ` Finn Hoffmann
  2013-07-31 11:47                                     ` Thomas Petazzoni
@ 2013-07-31 16:45                                     ` Andrew Lunn
  2013-08-01  8:01                                       ` Finn Hoffmann
  1 sibling, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-07-31 16:45 UTC (permalink / raw)
  To: linux-arm-kernel

> I came across one curious thing: With Andrews kernel I had:
> $ sensors
> adt7476-i2c-0-2e
> Adapter: mv64xxx_i2c adapter
> in0: +1.82 V (min = +0.00 V, max = +3.31 V)
> in1: +1.09 V (min = +0.00 V, max = +2.99 V)
> in2: +3.27 V (min = +2.98 V, max = +3.63 V)
> in3: +5.12 V (min = +4.53 V, max = +5.52 V)
> in4: +11.98 V (min = +0.00 V, max = +15.69 V)
> fan1: 4330 RPM (min = 0 RPM)
> fan2: 0 RPM (min = 0 RPM)
> fan3: 0 RPM (min = 0 RPM)
> fan4: 0 RPM (min = 0 RPM)
> temp1: +32.2??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> temp2: +32.5??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> temp3: +41.0??C (low = -127.0??C, high = +127.0??C)
> (crit = +100.0??C, hyst = +96.0??C)
> cpu0_vid: +0.000 V
> 
> normally I have:
> # sensors
> lm85-i2c-0-2e
> Adapter: mv64xxx_i2c adapter
> in0: +1.82 V (min = +0.00 V, max = +3.32 V)
> Vcore: +1.07 V (min = +0.00 V, max = +2.99 V)
> +3.3V: +3.25 V (min = +2.97 V, max = +3.63 V)
> +5V: +5.05 V (min = +4.50 V, max = +5.50 V)
> +12V: +12.12 V (min = +0.00 V, max = +15.94 V)
> fan1: 2480 RPM (min = 0 RPM)
> temp1: +35.0?C (low = -127.0?C, high = +127.0?C)
> temp2: +34.0?C (low = -127.0?C, high = +127.0?C)
> temp3: +47.0?C (low = -127.0?C, high = +127.0?C)

Note that the first above is an adt7476 and the other lm85.

There are multiple, slightly different NSA310 designs. Some have an
lm85, others have a adt7476. Which do you have? If you are using:

https://github.com/lunn/linux.git branch v3.11-rc1-nsa310-tdc you will
find two different DT descriptions for NSA310. See which works best
for you, kirkwood-nsa310.dtb or kirkwood-nsa310a.dtb.

    Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-31 16:45                                     ` Andrew Lunn
@ 2013-08-01  8:01                                       ` Finn Hoffmann
  2013-08-01 16:04                                         ` Andrew Lunn
  0 siblings, 1 reply; 39+ messages in thread
From: Finn Hoffmann @ 2013-08-01  8:01 UTC (permalink / raw)
  To: linux-arm-kernel


Am 31.07.2013 18:45, schrieb Andrew Lunn:
>> I came across one curious thing: With Andrews kernel I had:
>> $ sensors
>> adt7476-i2c-0-2e
>> Adapter: mv64xxx_i2c adapter
>> in0: +1.82 V (min = +0.00 V, max = +3.31 V)
>> in1: +1.09 V (min = +0.00 V, max = +2.99 V)
>> in2: +3.27 V (min = +2.98 V, max = +3.63 V)
>> in3: +5.12 V (min = +4.53 V, max = +5.52 V)
>> in4: +11.98 V (min = +0.00 V, max = +15.69 V)
>> fan1: 4330 RPM (min = 0 RPM)
>> fan2: 0 RPM (min = 0 RPM)
>> fan3: 0 RPM (min = 0 RPM)
>> fan4: 0 RPM (min = 0 RPM)
>> temp1: +32.2??C (low = -127.0??C, high = +127.0??C)
>> (crit = +100.0??C, hyst = +96.0??C)
>> temp2: +32.5??C (low = -127.0??C, high = +127.0??C)
>> (crit = +100.0??C, hyst = +96.0??C)
>> temp3: +41.0??C (low = -127.0??C, high = +127.0??C)
>> (crit = +100.0??C, hyst = +96.0??C)
>> cpu0_vid: +0.000 V
>>
>> normally I have:
>> # sensors
>> lm85-i2c-0-2e
>> Adapter: mv64xxx_i2c adapter
>> in0: +1.82 V (min = +0.00 V, max = +3.32 V)
>> Vcore: +1.07 V (min = +0.00 V, max = +2.99 V)
>> +3.3V: +3.25 V (min = +2.97 V, max = +3.63 V)
>> +5V: +5.05 V (min = +4.50 V, max = +5.50 V)
>> +12V: +12.12 V (min = +0.00 V, max = +15.94 V)
>> fan1: 2480 RPM (min = 0 RPM)
>> temp1: +35.0?C (low = -127.0?C, high = +127.0?C)
>> temp2: +34.0?C (low = -127.0?C, high = +127.0?C)
>> temp3: +47.0?C (low = -127.0?C, high = +127.0?C)
> Note that the first above is an adt7476 and the other lm85.
>
> There are multiple, slightly different NSA310 designs. Some have an
> lm85, others have a adt7476. Which do you have? If you are using:
>
> https://github.com/lunn/linux.git branch v3.11-rc1-nsa310-tdc you will
> find two different DT descriptions for NSA310. See which works best
> for you, kirkwood-nsa310.dtb or kirkwood-nsa310a.dtb.
>
>      Andrew
There is a ADT7476RQZ chip on the board of my NSA310. I was only 
confused that both work.
But right now I can not reproduce that. I have changed the dts file back to
             adt7476: adt7476a at 2e {
                 compatible = "adt7476";
                 reg = <0x2e>;
             };
but sensors still says it is a lm85.

The LED's on after kernel is loaded, while starting up does not work.
            pmx_led_sys_green: pmx-led-sys-green {
                 marvell,pins = "mpp28";
                 marvell,function = "gpio";
                 linux,default-trigger = "heartbeat";
                 brightness = <255>;
             };
I first tried default-trigger, then I added brightness additionally but 
LED's wont turn on.

There is no sata hdd trigger and nand-disk does not trigger on sata hdd 
activity.

Finn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-08-01  8:01                                       ` Finn Hoffmann
@ 2013-08-01 16:04                                         ` Andrew Lunn
  2013-08-01 20:43                                           ` Finn Hoffmann
  0 siblings, 1 reply; 39+ messages in thread
From: Andrew Lunn @ 2013-08-01 16:04 UTC (permalink / raw)
  To: linux-arm-kernel

> The LED's on after kernel is loaded, while starting up does not work.
>            pmx_led_sys_green: pmx-led-sys-green {
>                 marvell,pins = "mpp28";
>                 marvell,function = "gpio";
>                 linux,default-trigger = "heartbeat";
>                 brightness = <255>;
>             };
> I first tried default-trigger, then I added brightness additionally
> but LED's wont turn on.

Can you manually turn the LED on, using /sys/class/led/.../brightness?
It could be we have the wrong GPIO line for the led. It would be good
if you could test them all, not just this one led.

> There is no sata hdd trigger and nand-disk does not trigger on sata
> hdd activity.

They are out of tree patches. There was some discussion about SATA led
activity maybe 6 to 9 months ago. Maybe you can see why the suggested
patches got rejected. If i remember correctly, it was because they are
in the hot path.

   Andrew

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-08-01 16:04                                         ` Andrew Lunn
@ 2013-08-01 20:43                                           ` Finn Hoffmann
  0 siblings, 0 replies; 39+ messages in thread
From: Finn Hoffmann @ 2013-08-01 20:43 UTC (permalink / raw)
  To: linux-arm-kernel


Am 01.08.2013 18:04, schrieb Andrew Lunn:
>> The LED's on after kernel is loaded, while starting up does not work.
>>             pmx_led_sys_green: pmx-led-sys-green {
>>                  marvell,pins = "mpp28";
>>                  marvell,function = "gpio";
>>                  linux,default-trigger = "heartbeat";
>>                  brightness = <255>;
>>              };
>> I first tried default-trigger, then I added brightness additionally
>> but LED's wont turn on.
> Can you manually turn the LED on, using /sys/class/led/.../brightness?
> It could be we have the wrong GPIO line for the led. It would be good
> if you could test them all, not just this one led.
>
All LED's work via brightness and trigger default-on.
>> There is no sata hdd trigger and nand-disk does not trigger on sata
>> hdd activity.
> They are out of tree patches. There was some discussion about SATA led
> activity maybe 6 to 9 months ago. Maybe you can see why the suggested
> patches got rejected. If i remember correctly, it was because they are
> in the hot path.
>
>     Andrew
On a quick look I have not found it but it is not that important for me.

Finn

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-07-31  9:51                                 ` Thomas Petazzoni
  2013-07-31 11:41                                   ` Finn Hoffmann
@ 2013-08-02  8:35                                   ` Finn Hoffmann
  2013-08-02  8:46                                     ` Thomas Petazzoni
  1 sibling, 1 reply; 39+ messages in thread
From: Finn Hoffmann @ 2013-08-02  8:35 UTC (permalink / raw)
  To: linux-arm-kernel


Am 31.07.2013 11:51, schrieb Thomas Petazzoni:
> Dear Finn Hoffmann,
>
> On Wed, 31 Jul 2013 11:43:22 +0200, Finn Hoffmann wrote:
>
>> Hi Thomas,
>> here you are.
>> Network is working.
> Excellent, thanks!
>
>> # cat /sys/kernel/debug/mvebu-mbus/devices
>> [00] 00000000e8010000 - 00000000e8020000 : pcie0.0 (remap
>> 0000000000010000) [01] disabled
>> [02] disabled
>> [03] disabled
>> [04] 00000000f4000000 - 00000000f4010000 : nand
>> [05] 00000000f5000000 - 00000000f5010000 : sram
>> [06] 00000000e0000000 - 00000000e0100000 : pcie0.0
>> [07] disabled
> Now this looks good, we have both the PCIe memory and PCIe I/O windows
> created.
>
> I'll clean up the patch and send it, hopefully for the final 3.11.
>
> Thanks again for all your testing!
>
> Best regards,
>
> Thomas
Thomas,

I just came across one thing. Is it ok that I have different Marvell 
device with patched 3.11.0-rc3?
With 3.10.2 it has pci id 11ab:6281, with 3.11.0-rc3 and your patch it 
has 11ab:7846.

Finn

3.10.2:

# lspci -vnn
00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. 88F6281 
[Kirkwood] ARM SoC [11ab:6281] (rev 03)
     Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
     Flags: bus master, fast devsel, latency 0, IRQ 9
     Memory at <ignored> (64-bit, prefetchable)
     Capabilities: [40] Power Management version 3
     Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
     Capabilities: [60] Express Root Port (Slot-), MSI 00
     Capabilities: [100] Advanced Error Reporting

00:01.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03)
     Subsystem: Realtek Semiconductor Co., Ltd. TEG-ECTX Gigabit PCI-E 
Adapter [Trendnet] [10ec:8168]
     Flags: bus master, fast devsel, latency 0, IRQ 9
     I/O ports at 1000 [size=256]
     Memory at e0014000 (64-bit, prefetchable) [size=4K]
     Memory at e0010000 (64-bit, prefetchable) [size=16K]
     [virtual] Expansion ROM at e0000000 [disabled] [size=64K]
     Capabilities: [40] Power Management version 3
     Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
     Capabilities: [70] Express Endpoint, MSI 01
     Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
     Capabilities: [cc] Vital Product Data
     Capabilities: [100] Advanced Error Reporting
     Capabilities: [140] Virtual Channel
     Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
     Kernel driver in use: r8169

3.11.0-rc3:
lspci -vnn
00:01.0 PCI bridge [0604]: Marvell Technology Group Ltd. Device 
[11ab:7846] (prog-if 00 [Normal decode])
     Flags: bus master, fast devsel, latency 0
     Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
     I/O behind bridge: 00010000-00010fff
     Memory behind bridge: e0000000-e00fffff
     Prefetchable memory behind bridge: 00000000-000fffff

01:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 03)
     Subsystem: Realtek Semiconductor Co., Ltd. TEG-ECTX Gigabit PCI-E 
Adapter [Trendnet] [10ec:8168]
     Flags: bus master, fast devsel, latency 0, IRQ 9
     I/O ports at 10000 [size=256]
     Memory at e0014000 (64-bit, prefetchable) [size=4K]
     Memory at e0010000 (64-bit, prefetchable) [size=16K]
     [virtual] Expansion ROM at e0000000 [disabled] [size=64K]
     Capabilities: [40] Power Management version 3
     Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
     Capabilities: [70] Express Endpoint, MSI 01
     Capabilities: [ac] MSI-X: Enable- Count=4 Masked-
     Capabilities: [cc] Vital Product Data
     Capabilities: [100] Advanced Error Reporting
     Capabilities: [140] Virtual Channel
     Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
     Kernel driver in use: r8169

^ permalink raw reply	[flat|nested] 39+ messages in thread

* NSA310 + DT
  2013-08-02  8:35                                   ` Finn Hoffmann
@ 2013-08-02  8:46                                     ` Thomas Petazzoni
  0 siblings, 0 replies; 39+ messages in thread
From: Thomas Petazzoni @ 2013-08-02  8:46 UTC (permalink / raw)
  To: linux-arm-kernel

Dear Finn Hoffmann,

On Fri, 02 Aug 2013 10:35:37 +0200, Finn Hoffmann wrote:

> I just came across one thing. Is it ok that I have different Marvell 
> device with patched 3.11.0-rc3?
> With 3.10.2 it has pci id 11ab:6281, with 3.11.0-rc3 and your patch it 
> has 11ab:7846.

Yes, this is expected. 3.11-rc uses a completely new PCI driver for
Marvell platforms, that has a proper Device Tree binding. This driver
uses a very different strategy than the old driver in terms of MBus
window configuration, and to achieve this it relies on an emulated
PCI-to-PCI bridge. The numbers you're seeing are the one of the
emulated PCI-to-PCI bridge.

And the patch I've done fixes this PCI-to-PCI bridge emulation. BTW,
I've officially submitted the patch, which has been taken by the PCI
maintainer and will be part of one of the next 3.11-rc, and therefore
of the final 3.11. I mentioned you as Reported-by and thought git
send-email would automatically Cc you on the patch, but it did not.

Thanks again for your report!

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

^ permalink raw reply	[flat|nested] 39+ messages in thread

end of thread, other threads:[~2013-08-02  8:46 UTC | newest]

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <51DC564A.8050002@harsszegi.com>
2013-07-09 19:36 ` NSA310 + DT Andrew Lunn
2013-07-09 20:21   ` Andrew Lunn
2013-07-10  0:53     ` tibor at harsszegi.com
2013-07-10  6:23       ` Andrew Lunn
2013-07-10  8:42         ` tibor at harsszegi.com
2013-07-10 13:41       ` Andrew Lunn
     [not found]         ` <51DD8E8B.2040505@harsszegi.com>
2013-07-10 16:44           ` Tibor Harsszegi
2013-07-10 16:53           ` Andrew Lunn
2013-07-10 16:57             ` Tibor Harsszegi
2013-07-10 17:13               ` Tibor Harsszegi
2013-07-10 17:15                 ` Tibor Harsszegi
2013-07-10 17:23                   ` Andrew Lunn
2013-07-10 17:29                     ` Tibor Harsszegi
2013-07-10  1:01   ` tibor at harsszegi.com
2013-07-10  7:37     ` Andrew Lunn
2013-07-10  8:43       ` tibor at harsszegi.com
     [not found]       ` <51DEDB32.4080101@harsszegi.com>
2013-07-11 16:44         ` gpio_blink_set + Kirkwood Andrew Lunn
2013-07-11 18:32           ` Tibor Harsszegi
2013-07-11 18:37             ` Jason Cooper
2013-07-11 18:52               ` Tibor Harsszegi
2013-07-11 19:44                 ` Jason Cooper
2013-07-29 17:05       ` NSA310 + DT Finn Hoffmann
2013-07-29 19:21         ` Jason Cooper
2013-07-29 20:43           ` Andrew Lunn
     [not found]             ` <51F78DA6.8010307@uni-bremen.de>
     [not found]               ` <20130730144752.GR24782@lunn.ch>
     [not found]                 ` <20130730172407.3aab15c6@skate>
     [not found]                   ` <51F7EBB9.7000504@uni-bremen.de>
     [not found]                     ` <20130730191943.49f8070c@skate>
2013-07-30 18:36                       ` Andrew Lunn
2013-07-30 19:31                         ` Finn Hoffmann
2013-07-30 19:42                           ` Andrew Lunn
2013-07-30 21:23                           ` Thomas Petazzoni
2013-07-31  9:14                             ` Thomas Petazzoni
2013-07-31  9:43                               ` Finn Hoffmann
2013-07-31  9:51                                 ` Thomas Petazzoni
2013-07-31 11:41                                   ` Finn Hoffmann
2013-07-31 11:47                                     ` Thomas Petazzoni
2013-07-31 16:45                                     ` Andrew Lunn
2013-08-01  8:01                                       ` Finn Hoffmann
2013-08-01 16:04                                         ` Andrew Lunn
2013-08-01 20:43                                           ` Finn Hoffmann
2013-08-02  8:35                                   ` Finn Hoffmann
2013-08-02  8:46                                     ` Thomas Petazzoni

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.