The most recent thing I did, which yielded significant progress, was to find the code that does the clock control for the ethernet GMAC and run it, after that I actually see what looks like action from the network, but get an Exception:
nanopi3# dhcp tjt: dw_eth_init: d2:a5:61:c9:2e:e4 In dw_write_hwaddr: d2:a5:61:c9:2e:e4 (tjt) Speed: 1000, full duplex BOOTP broadcast 1 "Synchronous Abort" handler, esr 0x96000061 ELR: 7da8bb20 LR: 7da8bb0c x0 : 0000000000060101 x1 : 000000007daedc30 x2 : 0000000000000006 x3 : 0000000000000006 x4 : 000000007daedc86 x5 : 00000000000000e4 x6 : 00000000000000bd x7 : 000000007daee270 x8 : 0000000000000000 x9 : 0000000039e3b000 x10: 000000007ba36562 x11: 00000000ffffffff x12: 00000000ffffffff x13: 000000007da9fdc0 x14: 0000000000000001 x15: 000000007ba38800 x16: 0000000000000005 x17: 0000000000000004 x18: 000000007ba36df8 x19: 000000007daedc8e x20: 000000007daedc8e x21: 000000000000000e x22: 000000007daef000 x23: 000000007daed000 x24: 0000000000000001 x25: 000000007daef000 x26: 000000007daefadc x27: 0000000000000000 x28: 000000007ba38b30 x29: 000000007ba36a30 Resetting CPU ...The speed looks right (I am plugged into a 1000 Mbit switch), which hints that the Phy stuff is working as it should. I wonder if a packet ever gets sent. If I use a 100 Mbit switch, I wonder if it will see that, or is 1000 Mbit just a lucky accident?
I dig out an ancient 10-base-T hub. Plugged into that I get:
nanopi3# dhcp tjt: dw_eth_init: d2:a5:61:c9:2e:e4 In dw_write_hwaddr: d2:a5:61:c9:2e:e4 (tjt) dwmac.c0060000 Waiting for PHY auto negotiation to complete..... done Speed: 10, half duplex BOOTP broadcast 1 "Synchronous Abort" handler, esr 0x96000061So it looks like the Phy information is the real thing!!
This makes me wonder about my inability to blink a GPIO. I try to set the alt function register of the GPIO to "1" for the GMAC lines so it will function as a GMAC rather than GPIO. Maybe this is the reset behavior anyway -- I don't see code for this anywhere, and I would expect it right alongside the GMAC clock stuff.
Launch to 0x7FD00800Then there is a research topic -- how exactly does the boot scheme on the s5p6818 work. Why is there fip_secure.img as well as fip_loader.img and bl1_mmcboot.bin. What is all of this about?
Why is U-Boot linked to run at 0x43C00000, but seems to run at addresses like 0x7da8bb20? In fact I confirmed this by writing some code that prints the address it is running at:
I am at 7da3dc44
Why am I unable to control the GPIO from simple C code in U-Boot? Do I need to fiddle with reset bit? I can find no clock control for the GPIO. A quick experiment with the GPIO reset bits at 0xc0010208 yielded no improvement.
Tom's electronics pages / [email protected]