[U-Boot] Armada 38x clearfog pci trouble
Stefan Roese
sr at denx.de
Fri Sep 22 11:46:39 UTC 2017
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 at 30000, eth3: ethernet at 34000, eth1: ethernet at 70000
> 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 = 0xfc000008
> base address 1 = 0xe8000000
> base address 2 = 0x00000000
> base address 3 = 0x00000000
> base address 4 = 0x00000000
> base address 5 = 0x00000000
> cardBus CIS pointer = 0x00000000
> sub system vendor ID = 0x126f
> sub system ID = 0x0750
> expansion ROM base address = 0xe8200000
> interrupt line = 0xff
> interrupt pin = 0x01
> min Grant = 0x00
> max Latency = 0x00
> => md.l 0xe8000000 10
> e8000000: 20a00000 01000060 01f00000 01765324 ... `.......$Sv.
> e8000010: 01765324 00000000 00000000 00000000 $Sv.............
> e8000020: 00000008 00000000 00000000 00000000 ................
> e8000030: 00000000 00000000 00000000 00000000 ................
So accessing BAR1 (memory BAR) seems to work just fine.
> => md.l 0xfc000008 10
> fc000008:data abort
> pc : [<3ffb8104>] lr : [<3ffb80e0>]
> reloc pc : [<0083a104>] lr : [<0083a0e0>]
> sp : 3fb68950 ip : 00000002 fp : fc000008
> r10: fc000008 r9 : 3fb6ded8 r8 : 00000004
> r7 : 00000000 r6 : 00000004 r5 : 00000004 r4 : 00000010
> r3 : fc000008 r2 : 0000003a r1 : 3fb68964 r0 : 00000009
> 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
More information about the U-Boot
mailing list