Mvebu: borked?

Have not been able to produce a bootable image on a rango for about a week now, and do not have a serial connection to see what is transpiring on the device. Thought it might be the 5.4.45 push so went to 5.4.46 today, no joy. Wondering if others are seeing same, maybe with a serial that can provide a hint as to why. Wanted to generate a few images to test something, but do not feel like going backwards, too lazy I guess.

Edit: @rsalvaterra, is that you on ML with a borked Turris Omnia build. Not just me then.

On my wrt3200 i had to force sysupgrade as i think they changed the compatible. Don't know if it's related.

Hey! Yeah, it's me, but my issue is entirely different. On Linux 5.4 (OpenWrt master), the PCA9538 I²C/SMBus expander driver seems to leave interrupts unhandled from time to time, when CONFIG_GPIO_PCA953X_IRQ is enabled. This makes the kernel rather angry (and rightfully so). I never had this issue on OpenWrt 19.07 (Linux 4.14), mind you.
Of course Linksys devices don't have this problem, since the PCA9538 is only present in the Omnia (from a cursory look at a couple of device trees).

[EDIT: OpenWrt 19.07 is based on Linux 4.14, not 4.19, my bad.]

I just booted my WRT3200ACM quite ok with OpenWrt SNAPSHOT r13575-d64d5ed142 with kernel 5.4.45

Have you corrected config for the DSA network change? Have you already been using a DSA build, or do you still have a swconfig based network config?
DSA change was 12 days ago, so your "about a week ago" might be near that.

If you still have swconfig based network config, you need to sysupgrade without config. See also comments here.

EDIT: based on your forum messages, you know about DSA change, so likely it is not that.

Okay, thanks much for the confirmation. Ya, it's not the change to DSA or the mvebu name reconciliation change. Looks to be me then, I knew there was a reason those three fingers were pointing back at me. I will start from a distclean and maybe flash a snapshot while waiting. Might have to finally drill a hole in the side of that case.

Apparently the expected semantics of distclean are still not 100%. Doing make distclean, rm -rf bin tmp build_dir, make defconfig and git status indicating a pristine tree would only yield a broken image. Starting from a git clone and copying in the configdiff from the broken tree yields a working image.

I've seen similar stuff a while ago... Are you using ccache? If so, might be worth trying without.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.