marvellembeddedprocessors/linux-marvell

Marvell Armada Linux kernel

linux-marvell's Issues

How to use dma with armada ?

Hello,

Is there an example or wiki as to how to use DMA engine in armada ? In particular we need to use DMA with PCI express.

Regards,
Ran

UART boot Issue Armada 3700 family with DDR4

Hello Everyone!
In the company where I am, we are migrating the current Zynq architecture with DDR3 to your Armada 3700 family with DDR4.
Before deciding to migrate, we bought some espressobin and were delighted with your product.
We have therefore attempted to develop two cards that use the armada A3700 processor without success. We concluded that the problem is HW but we don't know exactly where.

I have done numerous tests. I try to summarize the key points as briefly as possible.
Our board uses DDR4 MT40A512M16LY-062E IT:E with Armada 88F3720-A0-BVB2I080-P123.
We have created a TIM, WTMI, Uboot package using A3700-utils-marvell, mv-ddr-marvell and atf-marvell from github as indicated in http://espressobin.net/espressobin-ultra-build-instruction/.
The package works correctly on espressobin V7. To test it we set the serial boot with the jumpers on the board then we used the tool A3700-utils-marvell/wtptp/linux/WtpDownload_linux .
We tried to throw the same thing on our board but uboot didn't start.

We then investigated further: to eliminate all the SW section above WTMI we modified the source code at A3700-utils-marvell/wtmi/sys_init/main.c by inserting a return 0 immediately inside the main (therefore after “u32 status”). On espressobin we see that the DDR switches correctly at 800MHz and the console goes back to the bootROM ones (therefore with the ">" symbol). On our board, however, the symbol is always that of the bootROM (we have never seen anything different) but the DDR does not switch at 800MHz: it remains at 400MHz instead.

Deepening the topic, several registers have been read from the bootROM console. In particular:
• the section starting from address 1FFF_0000 onwards (at least 100 registers),
• the section starting from 2000_6000 (at least 100 registers) and
• the section starting at 6410_0000 have been read.
Sections 1FFF_0000 and 2000_6000 have consistent content between our board and espressobin (this is also consistent with TIM and WTMI file). The section 6410_0000 instead is consistent on espressobin with the uboot binary but it is not so on our board. Random and non-repeatable data are read following a power down of our board.

We have therefore concluded (I kindly ask for your confirmation) that the problem is the DDR. To rule out any possibility, our DDR was mounted on a V7 espressobin. The system starts correctly and has therefore validated the HW component.

In order to generate the package that contains the TIM (which from what we understand describes among other things some registers to allow switching to 800MHz) we use the following command:
export CROSS_COMPILE = / opt / toolchains / gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu / bin / aarch64-linux-gnu-
export BL33 = $ BINARIES_DIR / u-boot.bin
make DEBUG = $ MY_DBG USE_COHERENT_MEM = 0 LOG_LEVEL = 60 SECURE = 0 CLOCKSPRESET = CPU_600_DDR_600 DDR_TOPOLOGY = 5 BOOTDEV = SPINOR PARTNUM = 0 PLAT = a3700 all fip
CLOCKSPRESET = CPU_800_DDR_800 was also tried. The variations of this parameter are seen on espressobin (with oscilloscope on DDR clock) but not on our board (which remains at 400MHz).

Further analyzing the A3700-utils-marvell/tim/ddr/DDR_TOPOLOGY_5.txt file and the "ddr_tool" sources present in mv-ddr-marvell/. The ddr_tool are compiled by us with the following:
export PLATFORM = a3700
export DDR_TYPE = DDR4
make clean
make
We tried to change the value of CL and CWL. Putting wrong values also the espressobin stops (like our board) but we were not able to start our board instead.

From what we understand (I kindly ask for your confirmation), the problem is that the TIM structure does not correctly describe our DDR4 (or our PCB with the correct timings on the tracks) this causes the check on the checksum of the uboot section made by bootROM to fail. Then reset the chip.

We therefore ask for confirmation on our deduction and if there is any tool capable of giving us the correct values to be entered in ddr_tool to correctly set the communication with DDR4 on our board.

At the HW level we checked the DDR4 signals (with eye diagrams too). We do not see important reflections on signals that could compromise correct communication. However, the DDR4 clock always remains stationary at 400MHz and the data contained in it always seems to be random (read with command r 6410_0000 and following from the bootROM console).
Hope it can help you with problem analysis,
Best regards

File for support:
cust-ddr4-1cs-1g.txt
DDR_TOPOLOGY_CUST.txt
DDR3_4_Static_configuration_tool_v1.1.xlsx

Failed to compile the driver using the directory drivers/staging/gd5f_spinand/gd5f_spinand.c under linux-4.44.120-armada-18.09.2

Hello, I am using the linux-4.44.120-armada-18.09.2 version of the kernel, then I use make menuconfig and select SPINAND Device Support For Gidadevice under Staging drivers under Device Drivers. After saving and exiting, then use make (The ARCH and CROSS_COMPILE have been specified) Can you see the error after the error?
The first error when I compile it is /drivers/staging/gd5f_spinand/gd5f_spinand.c:37:151: error:variable 'ecc_layout_4KB_bit' has initializer but incomplete type static struct nand_ecclayout ecc_layout_4KB_8bit = {

Unable to compile linux-4.4.120-armada-18.06

Hi,
I have to link time some error when I disable:
CONFIG_MD
CONFIG_UIO
And when I strip the kernel I need disable:
CONFIG_PCI

drivers/irqchip/irq-gic-v2m.c:84:23: error: 'pci_msi_domain_write_msg' undeclared here (not in a function)
.irq_write_msi_msg = pci_msi_domain_write_msg,
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/irqchip/irq-gic-v2m.c: In function 'gicv2m_allocate_domains':
drivers/irqchip/irq-gic-v2m.c:278:15: error: implicit declaration of function 'pci_msi_create_irq_domain' [-Werror=implicit-function-declaration]
pci_domain = pci_msi_create_irq_domain(of_node_to_fwnode(v2m->node),
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/irqchip/irq-gic-v2m.c:278:13: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
pci_domain = pci_msi_create_irq_domain(of_node_to_fwnode(v2m->node),
^
cc1: some warnings being treated as errors
make[2]: *** [scripts/Makefile.build:269: drivers/irqchip/irq-gic-v2m.o] Error 1

drivers/built-in.o: In function mv_pp22_uio_isr': debugfs.c:(.text+0x40ea8): undefined reference to uio_event_notify'
debugfs.c:(.text+0x40ea8): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol uio_event_notify' drivers/built-in.o: In function mv_pp2x_remove':
debugfs.c:(.text+0x447f4): undefined reference to uio_unregister_device' debugfs.c:(.text+0x447f4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol uio_unregister_device'
debugfs.c:(.text+0x44874): undefined reference to uio_unregister_device' debugfs.c:(.text+0x44874): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol uio_unregister_device'
drivers/built-in.o: In function mv_pp2x_port_probe': debugfs.c:(.text+0x4afa0): undefined reference to __uio_register_device'
debugfs.c:(.text+0x4afa0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol __uio_register_device' drivers/built-in.o: In function mv_pp2x_probe':
debugfs.c:(.text+0x4c5d0): undefined reference to uio_unregister_device' debugfs.c:(.text+0x4c5d0): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol uio_unregister_device'
debugfs.c:(.text+0x4c818): undefined reference to __uio_register_device' debugfs.c:(.text+0x4c818): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol __uio_register_device'
drivers/built-in.o: In function dmatest_perf_func': debugfs.c:(.text+0x79b20): undefined reference to xor_blocks'
debugfs.c:(.text+0x79b20): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `xor_blocks'

mvebu_u3d: USB3.0 device mode not working properly

While testing linux-4.4.52-armada-17.08 on our Armada-7040 based board, we found g_mass_storage module can only work for the first time. Just run the following command after booting up:

# modprobe g_mass_storage file=/dev/sda

The host side (Windows PC) recognized USB mass storage device successfully.

If we try to unload g_mass_storage module and load it for a second time, system either crashes or USB device can not be recognized by host. If USB cable is left connected when we do rmmod g_mass_storage, kernel will crash. If we disconnect USB cable and then rmmod g_mass_stroage; modprobe g_mass_storage file=/dev/sda, the Windows host will report "unrecognized USB device" error.

'dmesg' shows:

[ 1217.560142] USB device: connected
[ 1218.404488] USB device: warm reset
[ 1219.036488] USB device: warm reset
[ 1219.667488] USB device: warm reset
[ 1219.780754] USB device: suspend

Disconnecting/reconnecting USB cable won't help; however, it will work if we connect a USB2.0 cable.

Armada-xp-linksys-mamba

The .dts file for the Linksys WRT1900AC v1 (Mamba) is missing. It is based on the Armada XP SoC and it has 256Mb of RAM. Building with the default profile results in an unbootable image since it selects armada-xp-db.dts which includes the armada-xp-mv78460.dtsi instead of armada-xp-mv78230.dtsi. Also, armada-xp-db.dts defines 2Gb of RAM. Please create a profile for the above-mentioned device that includes all necessary requirements to build a working image. Thank you.

PCIe links down on soft-reboot

I'm trying to use a Ubiquiti mini PCIe SR71-E card with a SolidRun ClearFog-A1/PRO (Rev 2.1).
The card works fine, and is correctly recognized: 01:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) (rev 01).

But the card is not recognized anymore after a soft-reboot, e.g. after calling reboot.
The card works again if the board is first powered down and then booted again.

I'm using the SolidRun's official Debian image (sr-a38x-debian-jessie-20160703):
Linux clearfog 3.10.70-marvell-clearfog #3 SMP Sun Jul 10 21:43:27 UTC 2016 armv7l GNU/Linux.

I can rule out the card's driver (ath9k) as they are not included in the image.

dmesg from proper boot:
[ 1.110828] mvebu-pcie pcie-controller.3: PCIe1.0: link up
[ 1.110847] mvebu-pcie pcie-controller.3: PCIe2.0: link down
[ 1.110960] mvebu-pcie pcie-controller.3: PCI host bridge to bus 0000:00
[ 1.110967] pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
[ 1.110970] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
[ 1.110974] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 1.110988] pci 0000:00:02.0: [11ab:7846] type 01 class 0x060400
[ 1.111102] pci 0000:00:03.0: [11ab:7846] type 01 class 0x060400
[ 1.111208] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1.111213] pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1.111307] pci 0000:01:00.0: [168c:002a] type 00 class 0x028000
[ 1.111323] pci 0000:01:00.0: reg 10: [mem 0x42000000-0x4200ffff 64bit]
[ 1.111395] pci 0000:01:00.0: supports D1
[ 1.111398] pci 0000:01:00.0: PME# supported from D0 D1 D3hot
[ 1.111511] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 1.111587] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
[ 1.111620] pci 0000:00:02.0: BAR 8: assigned [mem 0xe0000000-0xe00fffff]
[ 1.111625] pci 0000:01:00.0: BAR 0: assigned [mem 0xe0000000-0xe000ffff 64bit]
[ 1.111634] pci 0000:00:02.0: PCI bridge to [bus 01]
[ 1.111638] pci 0000:00:02.0: bridge window [mem 0xe0000000-0xe00fffff]
[ 1.111646] pci 0000:00:03.0: PCI bridge to [bus 02]
[ 2.260169] ehci-pci: EHCI PCI platform driver

dmesg after reboot:
[ 1.110714] mvebu-pcie pcie-controller.3: PCIe1.0: link down
[ 1.110731] mvebu-pcie pcie-controller.3: PCIe2.0: link down
[ 1.110828] mvebu-pcie pcie-controller.3: PCI host bridge to bus 0000:00
[ 1.110834] pci_bus 0000:00: root bus resource [io 0x1000-0xfffff]
[ 1.110838] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xe7ffffff]
[ 1.110842] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 1.110855] pci 0000:00:02.0: [11ab:7846] type 01 class 0x060400
[ 1.110955] pci 0000:00:03.0: [11ab:7846] type 01 class 0x060400
[ 1.111048] pci 0000:00:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1.111052] pci 0000:00:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1.111140] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 1.111215] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 02
[ 1.111232] pci 0000:00:02.0: PCI bridge to [bus 01]
[ 1.111238] pci 0000:00:03.0: PCI bridge to [bus 02]
[ 2.242095] ehci-pci: EHCI PCI platform driver

Error when building linux-4.4.52-armada-17.10

Hi all,

I am building natively on the MacchiatoBin Doubleshot 1.2, and when I try to make the linux-4.4.52-armada-17.10 branch, I get the following error:
drivers/built-in.o: In function armada_3700_add_composite_clk': /home/luipen01/kernel/4.4.52/drivers/clk/mvebu/armada-37xx-periph.c:355: undefined reference to ____ilog2_NaN'
/home/luipen01/kernel/4.4.52/drivers/clk/mvebu/armada-37xx-periph.c:355:(.text+0x342210): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `____ilog2_NaN'
Makefile:953: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1
Has anyone experienced this?

Cheers

SFP support?

Does this kernel have SFP support for the cages on mcbin? Or is it only directattach cables?

Is there any plan for supporting SFP modules?

18.09 issue

/root/linux-marvell-linux-4.4.120-armada-18.09/drivers/usb/gadget/udc/udc-core.c:510: undefined reference to udc_detect' /root/linux-marvell-linux-4.4.120-armada-18.09/drivers/usb/gadget/udc/udc-core.c:510:(.text+0x1e5b24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol udc_detect'
drivers/built-in.o: In function usb_gadget_probe_driver': /root/linux-marvell-linux-4.4.120-armada-18.09/drivers/usb/gadget/udc/udc-core.c:536: undefined reference to udc_detect'
/root/linux-marvell-linux-4.4.120-armada-18.09/drivers/usb/gadget/udc/udc-core.c:536:(.text+0x1e5bd4): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol udc_detect' drivers/built-in.o: In function xenon_probe_dt':
/root/linux-marvell-linux-4.4.120-armada-18.09/drivers/mmc/host/sdhci-xenon.c:392: undefined reference to mv_soc_info_get_ap_revision' /root/linux-marvell-linux-4.4.120-armada-18.09/drivers/mmc/host/sdhci-xenon.c:392:(.text+0x271748): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol mv_soc_info_get_ap_revision'
drivers/built-in.o: In function xenon_emmc_phy_parse_param_dt': /root/linux-marvell-linux-4.4.120-armada-18.09/drivers/mmc/host/sdhci-xenon-phy.c:680: undefined reference to mv_soc_info_get_ap_revision'
/root/linux-marvell-linux-4.4.120-armada-18.09/drivers/mmc/host/sdhci-xenon-phy.c:680:(.text+0x271c6c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `mv_soc_info_get_ap_revision'
make: *** [Makefile:961: vmlinux] Error 1

4.14.76,Does it support c9130?, i cant find cn913*.dtb

kernel configuration menu: missing items.

i do on yocto: bitbake virtual/kernel -c menuconfig

my kernel configuration on WirelessLAN cut out every item for:
ralink and realtek driver support. nothing appears.
why?
i need include this drivers.

cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant

openwrt/openwrt@f407b2f

How can we contact Marvell to have the needed information ?

armada 7040

Hello,

I use armada7040 ,but I didn't find it listed in documentation/arm/marvell wiki.
Thank you.
Ran