Is anyone already running the testing kernel 5.15 on their WRT AC series? Judging by the topic linked below, at least 5.14 seemed to be working on the WRT3200 and WRT1900ACS. Space allotted to the kernel on all these devices is 6 MiB on both firmware partitions.
All I get is a blinking power LED when I switch master to 5.15 and run a build. @anomeome Seems 5.15 is running okay for you? I see you got self built master images from August 22nd with 5.15?
Did you check fw_printenv for the exact (kernel-) size read by u-boot (that is iirc smaller -the problem- than the alotted partition size on the nbg6617/ ipq4018)?
5.15 is running well on the 2 wrtpac devices I have (mamba, rango), has been for some time now.
Thank you both. I'll dig into this more when I got the time. Does the offload issue impact Cortex A72 as well btw?
I'm not sure what I should be looking at here, so this is the full output from fw_printenv. Seems kernel size is set to 6 MiB? Should be sufficient no?
root@OpenWrt:~# fw_printenv
CASset=max
MALLOC_len=5
MPmode=SMP
altFwSize=0x2800000
altKernAddr=0x3200000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock7 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $altKernAddr $altKernSize; bootm $defaultLoadAddr
auto_recovery=yes
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
bootargs_dflt=$console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd="run altnandboot"
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name; setenv bootargs $bootargs_dflt; bootm 0x2000000;
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=00:50:43:00:02:01
eth1mtu=1500
eth2addr=00:50:43:00:00:01
eth2mtu=1500
eth3addr=00:50:43:02:00:00
eth3mtu=1500
ethact=egiga0
ethaddr=00:50:43:00:02:01
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
firmwareName=stock.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadAddr $priKernAddr $filesize
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
loadaddr=0x02000000
loads_echo=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,256K(u_env),256K(s_env),1m@9m(devinfo),40m@10m(kernel),34m@16m(rootfs),40m@50m(alt_kernel),34m@56m(alt_rootfs),80m@10m(ubifs),-@90m(syscfg)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:01:00:00
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock5 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr
netbsd_en=no
netmask=255.255.255.0
netretry=no
pcieTune=no
pexMode=RC
priFwSize=0x2800000
priKernAddr=0x0a00000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
serverip=192.168.1.2
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81
boot_part_ready=3
boot_part=2
Looks that way, yes - I was merely guesstimating (don't have any mvebu devices), based on other devices.
Even that guesstimate is appreciated 
. I'm going to open it up and hook up serial. Even my own 22.03 build won't boot. Gotta be something fishy that's goin on.
Quick diff on a working / non-working configdiff to see if there is anything untoward?
Well hooked up serial, and I'm seeing all my builds hang. I've tested official 22.03.1 and master images, they both boot. My own 22.03.1 build (kernel 5.10.147) and master build (with 5.15) both just hang at starting the kernel, e.g.::
Hit any key to stop autoboot: 0
NAND read: device 0 offset 0x3200000, size 0x600000
6291456 bytes read: OK
## Booting kernel from Legacy Image at 02000000 ...
Image Name: ARM OpenWrt Linux-5.15.72
Created: 2022-10-13 20:04:47 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3402962 Bytes = 3.2 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
I'm going to diff my config against the official one, my master build has the early printk stuff enabled, so if it was booting I should be seeing something. Will report back once I've had the time to inspect my build config.
@anomeome I've tested your build from December 2nd with 5.15 and that boots flawlessly (my own attempts still hang). What's the reason for changing the CPU subtype from vfpv3-d16 to vfpv3 if I may ask?
Purely performance by getting all available registers in-play, nothing to do with issues you are experiencing; there is an old PR somewhere with a number of us arguing against the change made in support of some one-off dev board which failed with > 16 registers churned out by GCC.
Edit: and the thread
So I'm not an inch closer to pinning down the issue, but I did manage to mess up the single bootable firmware I had on the device somehow 
.
Error during boot of the installed firmware:
Marvell>> run altnandboot
NAND read: device 0 offset 0x3200000, size 0x600000
6291456 bytes read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
The first partition contains a broken OpenWrt build (kernel will just hang), so switching firmware is no option anymore at this point.
I can TFTP over the ramdisk just fine, and it seems like the memory address is okay as well, but it just hangs (just like with my own images, FWIW). This ramdisk is from the same images @anomeome built - and I successfully sysupgraded to that r21380 build; until now, it booted just fine.
Marvell>> tftpboot 0x8f000000 10.0.0.10:openwrt-mvebu-cortexa9-linksys_wrt1200ac-initramfs-kernel.bin
Using egiga0 device
TFTP from server 10.0.0.10; our IP address is 10.0.0.250
Filename 'openwrt-mvebu-cortexa9-linksys_wrt1200ac-initramfs-kernel.bin'.
Load address: 0x8f000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
####################################################
10.2 MiB/s
done
Bytes transferred = 20789674 (13d39aa hex)
Marvell>> bootm
there was this recent bug that created invalid builds in some cases, could it be that? OpenWrt 22.03.2 second service release - #55 by mpratt14
Thanks, but what hit mvebu is a switch issue that only hits the vanilla 5.10 builds, and that happens way later. Here, it doesn't even load the kernel... And this is a custom master build with 5.15.
Seems I was approaching it wrong, also tried bootelf but didn't manage to get the ramdisk to boot either. Tried a 21.02 and 22.03 image as well.
Then I stumbled upon these instructions and it turns out you just to configure u-boot the right way so it will pull the factory image from the TFTP server with run update_both_images and write it to both firmware partitions again. So nothing like TFTPing it over yourself. No trace of that on the wiki somehow.
If anyone knows how to get TFTP boot to work the usual way, I'm all ears. By now I'd rather not overwrite the flash ten times a day 
.
Alrighty. I was carrying a patch that enabled CONFIG_KERNEL_EARLY_PRINTK by default on a few targets - seems that's what makes boot hang. Revert that for mvebu, and my builds boot happily again.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.