Re: [U-Boot] Armada 38x clearfog pci trouble

2017-09-22 Thread Stefan Roese

Hi Bin,

On 22.09.2017 15:33, Bin Meng wrote:

On Fri, Sep 22, 2017 at 8:32 PM, Stefan Roese  wrote:

On 22.09.2017 14:13, Владислав wrote:


I try to port sm750fb driver to uboot. I need to access bar0 because its
framebuffer memory of video card.

After little research i find out pciauto_region_allocate failed for
allocation region for bar0:

PCI Autoconfig: BAR 0, Mem, size=0x400, No room in resource (addr:
0xE800, size: 0x400, res->bus_start: 0xE800, res->size:
0x200)


PCI Autoconfig: BAR 1, Mem, size=0x20, address=0xe800
bus_lower=0xe820


I find out definition in pci_mvebu.c:

#define PCIE_MEM_SIZE (32 << 20)

After changing it to (128 << 20) autoconfig working vell and bar0 is fully
accessible and work


Can we convert this pci_mvebu.c to DM PCI? So that this won't be
hardcoded in the driver, instead using device tree settings from the
boards.


I agree, that this would be much better. But I currently don't
have the time to port this driver over to DM. Patches from
others are very welcome... ;)

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Armada 38x clearfog pci trouble

2017-09-22 Thread Stefan Roese

On 22.09.2017 14:13, Владислав wrote:
I try to port sm750fb driver to uboot. I need to access bar0 because its 
framebuffer memory of video card.


After little research i find out pciauto_region_allocate failed for 
allocation region for bar0:


PCI Autoconfig: BAR 0, Mem, size=0x400, No room in resource (addr: 
0xE800, size: 0x400, res->bus_start: 0xE800, res->size: 
0x200)



PCI Autoconfig: BAR 1, Mem, size=0x20, address=0xe800 
bus_lower=0xe820



I find out definition in pci_mvebu.c:

#define PCIE_MEM_SIZE (32 << 20)

After changing it to (128 << 20) autoconfig working vell and bar0 is 
fully accessible and work


I see. Please send a proper patch to change this setting
in mainline to the list.

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Armada 38x clearfog pci trouble

2017-09-22 Thread Stefan Roese
On 22.09.2017 08:32, Влад Мао wrote:
> Hello. I have a clearfog base board with PCI-E video card based on
> SIlicon Motion s750 (InnoDisk EMPV-1201), and i have trouble with
> u-boot and accessing to this card.
> 
> I use last u-boot from git, and when i try to read memory from Base
> address 0 of PCI-E, board resetted. log from board:
> 
> High speed PHY - Version: 2.0
> Detected Device ID 6828
> board SerDes lanes topology details:
>   | Lane #  | Speed |  Type   |
>   
>   |   0|  3   |  SATA0   |
>   |   1|  0   |  SGMII1  |
>   |   2|  5   |  PCIe1   |
>   |   3|  5   |  USB3 HOST1  |
>   |   4|  5   |  PCIe2   |
>   |   5|  0   |  SGMII2  |
>   
> :** Link is Gen1, check the EP capability
> PCIe, Idx 1: remains Gen1
> PCIe, Idx 2: detected no link
> High speed PHY - Ended Successfully
> DDR3 Training Sequence - Ver TIP-1.29.0
> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> DDR3 Training Sequence - Ended Successfully
> Trying to boot from MMC1
> 
> 
> U-Boot 2017.09-00255-ge884656c2c-dirty (Sep 22 2017 - 09:05:09 +0300)
> 
> SoC:   MV88F6828-A0 at 1600 MHz
> I2C:   ready
> DRAM:  1 GiB (800 MHz, ECC not enabled)
> MMC:   mv_sdh: 0
> PCI:
>00:01.0 - 126f:0750 - Display controller
> Model: SolidRun Clearfog A1
> Board: SolidRun ClearFog
> Net:   eth2: ethernet@3, eth3: ethernet@34000, eth1: ethernet@7
> Hit any key to stop autoboot:  0
> => pci
> Scanning PCI devices on bus 0
> BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
> _
> 00.01.00   0x126f 0x0750 Display controller  0x00
> => pci header 00.01.00
>vendor ID =   0x126f
>device ID =   0x0750
>command register ID = 0x0007
>status register = 0x0010
>revision ID = 0xa1
>class code =  0x03 (Display controller)
>sub class code =  0x00
>programming interface =   0x00
>cache line =  0x08
>latency time =0x00
>header type = 0x00
>BIST =0x00
>base address 0 =  0xfc08
>base address 1 =  0xe800
>base address 2 =  0x
>base address 3 =  0x
>base address 4 =  0x
>base address 5 =  0x
>cardBus CIS pointer = 0x
>sub system vendor ID =0x126f
>sub system ID =   0x0750
>expansion ROM base address =  0xe820
>interrupt line =  0xff
>interrupt pin =   0x01
>min Grant =   0x00
>max Latency = 0x00
> => md.l 0xe800 10
> e800: 20a0 0160 01f0 01765324... `...$Sv.
> e810: 01765324   $Sv.
> e820: 0008   
> e830:    

So accessing BAR1 (memory BAR) seems to work just fine.

> => md.l 0xfc08 10
> fc08:data abort
> pc : [<3ffb8104>]  lr : [<3ffb80e0>]
> reloc pc : [<0083a104>]lr : [<0083a0e0>]
> sp : 3fb68950  ip : 0002 fp : fc08
> r10: fc08  r9 : 3fb6ded8 r8 : 0004
> r7 :   r6 : 0004 r5 : 0004  r4 : 0010
> r3 : fc08  r2 : 003a r1 : 3fb68964  r0 : 0009
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...

You are trying to access BAR0, which is most likely not a
memory but a IO BAR. Why do you want to do this? Do you really
need to access this BAR from within U-Boot?

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot