• State TI Thinks Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 3 answers
  • Subscribers 99 subscribers
  • Views 1638 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM6548: PRU Ethernet in U-boot

user5772774
Intellectual 660 points
Part Number: AM6548

Hi TI team

1. we want to use PRU-ICSSG0 ethernet in u-boot phases. there is a dts file named k3-am654-idk.dtso in the u-boot source in SDK6.00.00.07, but how to use dts overlay in u-boot? we just know how to use dts overlay in the kernel !

2. PRU-ICSSG0 requires a firmware, but how do I load it's firmware in u-boot?

  • 0
    TI__Guru** 101250 points

    Hello,

    Please look at our Uboot Networking documentation. Go to subsection "Booting Linux from the network".

    Please note that we currently support booting Linux over the network on PRU-ICSS2, but the uboot and filesystem would still need to be stored on local memory (i.e., the PRU firmware would need to be stored locally.)

    Feel free to reply if you have follow-up questions.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 660 points

    Hello

    Yes, I have made the PRU-ICSSG2 run successfully in u-boot phase according to the documentation, But we want to use PRU-ICSSG0, I tried to make it work by referring to the method in the documentation, but it failed. the documentation says that only the PRU-ICSSG2 can work in u-boot phase of the AM65xx cpu, I don't know if there is a way to get the PRU-ICSSG0 to work in u-boot?

  • 0 in reply to user5772774
    TI__Guru** 101250 points

    Hello,

    The driver does support using ICSSG0, ICSSG1, and ICSSG2 in uboot. For now, TI is only publishing ICSSG2 support to the broad market. However, you should be able to get PRU-ICSSG0 working.

    Please take a look at the post PRU Ethernet in U-Boot for guidance.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 660 points

    Hi TI team,


        I currently use icssg0 ethernet in u-boot phases, the environment variables to start it are following
       
        setenv firmware_dir '/lib/firmware/ti-pruss'
        setenv ethact pruss0_eth
        setenv get_firmware_mmc 'load mmc 1:2 ${loadaddr} ${firmware_dir}/${firmware_file}'
        setenv start_icssg0 'rproc start 0; rproc start 1'
        setenv load_icssg0_pru0_fw 'setenv firmware_file am65x-pru0-prueth-fw.elf; setenv loadaddr 0x89000000; run get_firmware_mmc; rproc load 0 0x89000000 13040; rproc start 0'
        setenv load_icssg0_rtu0_fw 'setenv firmware_file am65x-rtu0-prueth-fw.elf; setenv loadaddr 0x8a000000; run get_firmware_mmc; rproc load 1 0x8a000000 5676; rproc start 1'
        setenv init_icssg0 'rproc init; run load_icssg0_pru0_fw; run load_icssg0_rtu0_fw'
       
        First I executed 'run init_icssg0' to start icssg0. I found that I must execute this command 'run start_icssg0' before using icssg0 every time, for example using the command 'ping' or 'nfs' in the u-boot command shell!
        This is too much trouble. Is it possible to use icssg0 in a way that allows me to execute 'run start_icssg0' only once?

  • 0 in reply to user5772774
    TI__Guru** 101250 points

    Hello,

    It looks like the U-boot network framework implicitly calls stop after every network related command. That stop command shuts off the remote processor. Thus, in order to start another command, we need to explicitly start again.

    So to the best of my knowledge, you can drop the "stop" commands after every network related command. However, I think you need to keep the start commands.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 660 points

    Hello,

    I made the start command run once and the stop command does not run in u-boot, but the kernel startup hangs !

    Starting kernel ...
    [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
    [    0.000000] Linux version 4.19.38+ (builder@c61926211a7f) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP PREEMPT Thu Oct 10 20:35:52 UTC 2019
    [    0.000000] Machine model: SIMATIC IOT2040B-ADVANCED
    [    0.000000] earlycon: ns16550a0 at MMIO32 0x0000000002810000 (options '')
    [    0.000000] bootconsole [ns16550a0] enabled
    [    0.000000] Reserved memory: created DMA memory pool at 0x000000009b000000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node r5f-dma-memory@9b000000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x000000009b100000, size 15 MiB
    [    0.000000] OF: reserved mem: initialized node r5f-memory@9b100000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x000000009c000000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node r5f-dma-memory@9c000000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x000000009c100000, size 7 MiB
    [    0.000000] OF: reserved mem: initialized node r5f-memory@9c100000, compatible id shared-dma-pool
    [    0.000000] cma: Reserved 512 MiB at 0x00000000c0000000
    [    0.000000] psci: probing for conduit method from DT.
    [    0.000000] psci: PSCIv1.1 detected in firmware.
    [    0.000000] psci: Using standard PSCI v0.2 function IDs
    [    0.000000] psci: Trusted OS migration not required
    [    0.000000] psci: SMC Calling Convention v1.1
    [    0.000000] random: get_random_bytes called from start_kernel+0x94/0x3e4 with crng_init=0
    [    0.000000] percpu: Embedded 2 pages/cpu s52632 r8192 d70248 u131072
    [    0.000000] Detected VIPT I-cache on CPU0
    [    0.000000] CPU features: enabling workaround for ARM erratum 845719
    [    0.000000] Speculative Store Bypass Disable mitigation not required
    [    0.000000] CPU features: detected: Kernel page table isolation (KPTI)
    [    0.000000] Built 1 zonelists, mobility grouping off.  Total pages: 31968
    [    0.000000] Kernel command line: console=ttyS3,115200n8 earlycon=ns16550a,mmio32,0x02810000 mtdparts=47040000.spi.0:512k(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),128k(ospi.env),128k(ospi.env.backup),1m(ospi.sysfw),256k(padding),-@8m(ospi.rootfs) root=/dev/nfs nfsroot=192.168.100.240:/home/nfs/rootfs,nolock ip=dhcp
    [    0.000000] Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
    [    0.000000] Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
    [    0.000000] Memory: 1503168K/2048000K available (8574K kernel code, 726K rwdata, 3072K rodata, 576K init, 656K bss, 20544K reserved, 524288K cma-reserved)
    [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
    [    0.000000] rcu: Preemptible hierarchical RCU implementation.
    [    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
    [    0.000000]  Tasks RCU enabled.
    [    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
    [    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
    [    0.000000] GICv3: GIC: Using split EOI/Deactivate mode
    [    0.000000] GICv3: Distributor has no Range Selector support
    [    0.000000] GICv3: no VLPI support, no direct LPI support
    [    0.000000] ITS [mem 0x01820000-0x0182ffff]
    [    0.000000] GIC: enabling workaround for ITS: Socionext Synquacer pre-ITS
    [    0.000000] ITS@0x0000000001820000: allocated 1048576 Devices @a0800000 (flat, esz 8, psz 64K, shr 0)
    [    0.000000] ITS: using cache flushing for cmd queue
    [    0.000000] GIC: using LPI property table @0x00000000a00d0000
    [    0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000001880000
    [    0.000000] CPU0: using LPI pending table @0x00000000a00e0000
    [    0.000000] GIC: using cache flushing for LPI property table
    [    0.000000] arch_timer: cp15 timer(s) running at 200.00MHz (phys).
    [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x2e2049d3e8, max_idle_ns: 440795210634 ns
    [    0.000004] sched_clock: 56 bits at 200MHz, resolution 5ns, wraps every 4398046511102ns
    [    0.008611] Console: colour dummy device 80x25
    [    0.013199] Calibrating delay loop (skipped), value calculated using timer frequency.. 400.00 BogoMIPS (lpj=800000)
    [    0.023880] pid_max: default: 32768 minimum: 301
    [    0.028690] Security Framework initialized
    [    0.032939] Mount-cache hash table entries: 8192 (order: 0, 65536 bytes)
    [    0.039815] Mountpoint-cache hash table entries: 8192 (order: 0, 65536 bytes)
    [    0.071249] ASID allocator initialised with 32768 entries
    [    0.084808] rcu: Hierarchical SRCU implementation.
    [    0.097874] Platform MSI: gic-its@18200000 domain created
    [    0.103681] PCI/MSI: /interconnect@100000/interrupt-controller@1800000/gic-its@18200000 domain created
    [    0.121237] smp: Bringing up secondary CPUs ...
    [    0.158346] Detected VIPT I-cache on CPU1
    [    0.158381] GICv3: CPU1: found redistributor 1 region 0:0x00000000018a0000
    [    0.158446] CPU1: using LPI pending table @0x00000000a03a0000
    [    0.158496] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
    [    0.220011] Detected VIPT I-cache on CPU2
    [    0.220049] GICv3: CPU2: found redistributor 100 region 0:0x00000000018c0000
    [    0.220117] CPU2: using LPI pending table @0x00000000a0400000
    [    0.220164] CPU2: Booted secondary processor 0x0000000100 [0x410fd034]
    [    0.252400] Detected VIPT I-cache on CPU3
    [    0.252428] GICv3: CPU3: found redistributor 101 region 0:0x00000000018e0000
    [    0.252492] CPU3: using LPI pending table @0x00000000a0490000
    [    0.252523] CPU3: Booted secondary processor 0x0000000101 [0x410fd034]
    [    0.252655] smp: Brought up 1 node, 4 CPUs
    [    0.328230] SMP: Total of 4 processors activated.
    [    0.333046] CPU features: detected: GIC system register CPU interface
    [    0.339645] CPU features: detected: 32-bit EL0 Support
  • 0 in reply to user5772774
    TI__Guru** 101250 points

    Hello,

    What uboot commands are you using?

    When you use "start" before every networking command and "stop" after every networking command, does Linux boot as expected?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 660 points

    By default, run the start_icssg0 command before running the nfs command to load the kernel and dtb in u-boot, then start the kernel in u-boot and the kernel can be started.

  • 0 in reply to user5772774
    TI__Guru** 101250 points

    Hello,

    Is this a correct summary? :
    If you run start_icssg0 before every nfs command, you can successfully use ICSSG0 to boot Linux over the network.

    If that is correct, did you have any additional questions?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 390 points

    Hi Nick,

    We could not just simply drop the "stop" command, otherwise the Linux won't initialize the PRUETH correctly. 

    For now, we just restart the NIC each time when we issue the command.

    Thank you.

    Best Regards,

    Le

  • 0 in reply to user5119396
    Intellectual 660 points

    Hello,

    we want to use icssg0 ethernet in u-boot without having to run 'start' command every time. I try to drop the 'stop' command, but it is not ok, do you have a solutions? 

  • 0 in reply to user5772774
    TI__Guru** 101250 points

    We will continue the discussion about having to run the 'start' command every time on this follow-up PRU Ethernet in U-boot post.

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    TI__Guru** 101250 points

    Hello,

    Bringing the discussion back to this thread.

    Summary: right now, the uboot framework calls stop after every PRU Ethernet network command. I am not sure if it is possible to modify the framework or not. Right now I cannot support customization of your drivers. However, if you found an issue that really impacts your development, I may be able to get the developers to take a look at this.

    You mentioned that you have to "restart prueth each time when issuing network command". What does that mean? Does it get in the way of development? Does it limit functionality?

    Regards,

    Nick

  • 0 in reply to Nick Saulnier
    Intellectual 660 points

    Hello,

    Based on my personal experience, the previous project does not need to execute commands like 'start_icssg0' before using the network commands under u-boot. Even when using the CPSW network port on TI EVM board, there is no need to execute the START command. 

    I know the difference between CPSW ethernet and ICSSG ethernet, but I think that providing users with a consistent interface can avoid many modifications.

  • 0 in reply to user5772774
    Intellectual 390 points

    Add one more info, we have tested to drop the stop command in u-boot, but later kernel won't initialize the prueth correctly.

  • 0 in reply to user5119396
    TI__Guru** 101250 points

    Hello,

    I apologize for the delayed response. It sounds like we want to make sure that stop is called for the PRU before the kernel starts. Otherwise, the kernel prueth driver might find the PRU in a bad state.

    When you tested dropping the stop command, did you try only calling stop after the prueth had completed all of its Uboot networking commands?

    Regards,

    Nick