Re: [U-Boot] Armada 38x clearfog pci trouble
Hi Bin, On 22.09.2017 15:33, Bin Meng wrote: On Fri, Sep 22, 2017 at 8:32 PM, Stefan Roesewrote: 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
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
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