GRETH EDCL emulation vs. TFTP in u-boot

[amonakov]

I hit a snag when trying to boot mb115.01 via TFTP. Since EDCL is enabled at reset, greth emulation intercepts incoming packets that match edcl_mac (which is also the MAC address of the NIC from Qemu's point of view), and drops them without passing back to Qemu. As a result, ARP response to the initial ARP request for the TFTP server is never seen.

I worked around it by patching out detection of incoming EDCL packets:

diff --git a/hw/net/greth.c b/hw/net/greth.c
index d3e070b..92ae1ec 100644
--- a/hw/net/greth.c
+++ b/hw/net/greth.c
@@ -455,7 +455,7 @@ static enum packet_type check_packet_belong(GRETHState *s, const uint8_t *buf, s
         break;

     case ETH_PKT_UCAST:
-        if (memcmp(mac_level->h_dest, s->edcl_mac.a, ETH_ALEN) == 0) {
+        if (0 && memcmp(mac_level->h_dest, s->edcl_mac.a, ETH_ALEN) == 0) {
             return PACKET_TYPE_EDCL;
         }

but it would be nice if TFTP worked out-of-the-box too.

[nia40m]

Firstly, I just updated u-boot image that is shipped with the emulator sources so it doesn't have this issue. Secondly, if you are building your own version of u-boot then you just need to change mac-address field in the device-tree file (*your_board_name*.dts) of ethernet controller you are using for tftp.

[amonakov]

Thank you for the swift response! I grabbed the new u-boot image, and now u-boot can ping the TFTP server, but loading the image fails:

=> ping 192.168.0.1
Using greth0@0x3C034000 device
host 192.168.0.1 is alive
=> tftp 50000000 uImage
Using greth0@0x3C034000 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'uImage'.
Load address: 0x50000000
Loading: *

 !!! Interrupt happens (DTLB_miss)
        R1:     0x4EFFFAB0
        R3:     0x00000025
        LR:     0x4D06EFA8
        SRR0:   0x4D000288
        SRR1:   0x00008000
        CSRR0:  0x00000000
        CSRR1:  0x00000000

Reset after 10 seconds...

My Qemu command line is

 ./qemu-system-ppc -M mb115.01 -bios module_mb115_rumboot.bin -drive file=module_mb115_u-boot.bin,if=mtd,format=raw -serial mon:stdio -nic user,model=greth,net=192.168.0.0/24,host=192.168.0.1,tftp=/tmp/tftp

I'm using exactly the same setup as before (where TFTP boot was working with my workaround), except with new u-boot.

To summarize the now-fixed issue with EDCL, the MAC address specified in the dts parsed by u-boot is supposed to be different from the EDCL MAC that emulated NIC receives at reset?

[nia40m]

To summarize the now-fixed issue with EDCL, the MAC address specified in the dts parsed by u-boot is supposed to be different from the EDCL MAC that emulated NIC receives at reset?

Yes, it should be different.

u-boot can ping the TFTP server, but loading the image fails

It looks like the new u-boot has other mappings so the virtual address 0x50000000 is not available. You can add it manually using map set command. I will also check the difference myself.

[nia40m]

To add the mapping you were using before just add a command mmap set 0x50000000 256m 0x10000000 before using that address in tftpload command. This will map virtual address 0x50000000 to the first DDR slot with offset of 256 MB (0x10000000).

[amonakov]

Now it always hangs when transferring the dtb (with old u-boot this didn't hang, but printed 'T' once after a short delay):

=> mmap set 0x50000000 256m 0x10000000
=> tftp 0x50000000 uImage
Using greth0@0x3C034000 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'uImage'.
Load address: 0x50000000
Loading: ##################################################  5.8 MiB
         48.2 MiB/s
done
Bytes transferred = 6120326 (5d6386 hex)
=> tftp 0x50f00000 mpw7705.dtb
Using greth0@0x3C034000 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'mpw7705.dtb'.
Load address: 0x50f00000
Loading: ################################################T T T T T T T T T T
Abort

[nia40m]

Is your mpw7705.dtb file bigger then 1MB? I tested same commands on my files: uImage (5,9 MB) and .dtb (27,7 KB) and that worked fine.

[amonakov]

Is your mpw7705.dtb file bigger then 1MB?

It's 23748 bytes.

[nia40m]

The issue with TFTP was in u-boot and it was fixed with commit c698969 Also updated mappings to be like in old version

Please test new version and tell me the results

[amonakov]

Thank you, I can confirm the new version works fine, closing.

[vit9696]

@nia40m, could you please tell us what U-Boot changes did you make and perhaps upload them to https://github.com/YetAnotherMod/u-boot? We sometimes have issues with TFTP loading on a real (mb115) board with a rather old U-Boot and eventually want to update to master.