> Date: Sat, 27 Dec 2025 22:09:41 +0000
> From: Klemens Nanni <[email protected]>
> 
> 13.12.2025 18:47, Klemens Nanni пишет:
> > 01.12.2025 00:46, Klemens Nanni пишет:
> >> U-boot has had support for years, but it is enabled by default only
> >> for some boards/targets.
> >>
> >> After I flashed my NanoPi R6S's eMMC (no SD-card) as per INSTALL.arm64:
> >>
> >>    => setenv serverip6 fe80::1
> >>    => tftpboot BOOTAA64.EFI -ipv6
> >>    ROUTER SOLICITATION 1
> >>    Set gatewayip6: fe80:0000:0000:0000:fce1:baff:fed0:2e5c, prefix_length: 
> >> 64
> >>    Using ethernet@fe1c0000 device
> >>    TFTP from server fe80:0000:0000:0000:0000:0000:0000:0001; our IP 
> >> address is fe80:0000:0000:0000:5c27:b1ff:fe14:a9c9
> >>    Filename 'BOOTAA64.EFI'.
> >>    Load address: 0xc00800
> >>    Loading: ################
> >>             1.7 MiB/s
> >>    done
> >>    Bytes transferred = 229585 (380d1 hex)
> >>    => bootefi $loadaddr
> >>    Booting /BOOTAA64.EFI
> >>    disks: sd0
> >>    >> OpenBSD/arm64 BOOTAA64 1.22
> >>    boot> 
> >>
> >> iPXE also boots this way, but then hangs, at least on the serial:
> >>
> >>    Booting /ipxe.efi
> >>    iPXE initialising devices...
> >>
> >>
> >>    iPXE 1.21.1+ (ge9a2) -- Open Source Network Boot Firmware -- 
> >> https://ipxe.org
> >>    Features: DNS HTTP iSCSI TFTP VLAN SRP AoE EFI Menu
> >>
> >>    Press Ctrl-B for the iPXE command line...
> >>
> >> I'll investigate that next, but IPv6 itself works fine incl. the
> >> ping6 and pxe commands.
> >>
> >> I don't use DHCPv6 and omitting it causes interactive prompts,
> >> hence why it's disabled.
> >>
> >> Image size growth seems negligible:
> >>
> >>    $  du -k u-*
> >>    9408    u-boot-rockchip.bin
> >>    9424    u-boot-rockchip.bin.new
> >>
> >> Feedback? OK?
> > 
> > Ping, now with base arm64 hackers in Cc.
> > Same diff again.
> 
> One more ping, now with Marcus in Cc also.
> 
> Unless there are objections, I'm inclined to commit this in a few days.

What does this do on boards that don't have network interfaces
enabled?  For example the Radxa ROCK 5B.

Maybe a better strategy is to just patch the boards you care about
(and submit the changes upstream)?

> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/sysutils/u-boot/rk3588/Makefile,v
> diff -u -p -r1.10 Makefile
> --- Makefile  9 Aug 2025 09:53:19 -0000       1.10
> +++ Makefile  30 Nov 2025 20:23:33 -0000
> @@ -1,4 +1,5 @@
>  VERSION=     2025.07
> +REVISION=    0
>  
>  SOC=         rk3588
>  
> @@ -27,6 +28,11 @@ EXTRACT_ONLY=      ${DISTNAME}${EXTRACT_SUFX}
>  
>  MAKE_ENV+=   BL31=${FULLDISTDIR}/${RK3588_BL31}
>  
> +ENABLE_OPTS= IPV6 \
> +             IPV6_ROUTER_DISCOVERY \
> +             CMD_PING6
> +DISABLE_OPTS=        CMD_DHCP6
> +
>  pre-build:
>       cc -o ${WRKSRC}/rkbinpatch ${FILESDIR}/rkbinpatch.c 
>       cd ${WRKSRC} && \
> @@ -41,7 +47,9 @@ do-build:
>               O="build/${BOARD}" \
>               -f ${MAKE_FILE} "${BOARD}"_defconfig
>       cd ${WRKSRC}/build/${BOARD} && \
> -         ../../scripts/config --set-val BAUDRATE 115200
> +         ../../scripts/config --set-val BAUDRATE 115200 \
> +             ${ENABLE_OPTS:=-e %} \
> +             ${DISABLE_OPTS:=-d %}
>       cd ${WRKSRC} && \
>           ${SETENV} ${MAKE_ENV} ROCKCHIP_TPL=${RK3588_TPL} ${MAKE_PROGRAM} \
>               ${MAKE_FLAGS} O="build/${BOARD}" \
> 
> 

Reply via email to