Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
mediatek: mt7622: skip build also for Xiaomi AX6S
Also here build fails due to increased kernel size. Fixes: da970d6 ("mediatek: switch to Linux version 6.1") Signed-off-by: Daniel Golle <daniel@makrotopia.org>
- Loading branch information
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what I'm doing differently, but it builds (and runs) fine on mine?
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The answer is simple: You don't have
CONFIG_ALL_KMODS=y
set in your.config
(which is what the buildbots are doing). Compiling the kernel with the option to have all kmods increases the size beyond the boundary of the current partition layout of the AX6S.dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I'll have to check how much space is left, but it looked like there was still some spare. I guess I'll have to look into a new device at some point though...
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is enough space for everything, just the way the stock bootloader expects that space to be partitioned is restricting. One option is of course to replace that bootloader...
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know, yeah. Replacing the bootloader would be nice, but I'm pretty sure there's some kind of signature check there.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure there isn't any check of the preloader or bootloader. All it takes is replacing bl2 and then we can have the same flash layout as on Linksys E8450/Belkin RT3200. I just don't have the hardware to test.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My patch: openwrt-xiaomi@975ae07
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @dangowrt , a remote secure shell would suffice? Or do you need serial access too?
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly we need to check the bootloader environment and/or how the vendor bootloader handles kernel images larger than 4 MiB. As the image is stored on SPI-NAND it will have to be copied into RAM before running, and we need to figure out if the bootloader relies on a hard-coded size or partition layout or if it reads the uImage headers to know the size. In the first case it means replacing the loader or introducing a 2nd stage loader, in the latter case we are good.
Edit: So yes, serial access would be better.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😁
Sure!
Let me try building some debugging environment for you. Will be back in a few days.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have already tested 2 methods of upgrading to the new partition layout with a 6 MiB kernel:
https://forum.openwrt.org/t/adding-openwrt-support-for-xiaomi-redmi-router-ax6s-xiaomi-router-ax3200/111085/1776
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no such restrictions in the stock bootloader. I even checked his code in a disassembler.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice then, someone with the device at hand please make open a pull request and let's go with 8 MiB instead of 6 MiB so the drama doesn't repeat too soon.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will be redundant! 6 MiB definitely enough for 10 years. Example: e8646f5
I can’t, because I don’t know how to prevent users from upgrading when using the -F flag.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@remittor I don't think there is a need to prevent users from upgrading using the -F flag is there?
The default is to stop the upgrade, and there are plenty of warnings that back things will happen if forced.
I believe including that comment in the DEVICE_COMPAT_MESSAGE is good though. i.e. forcing this upgrade WILL result in a brick etc.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that on the ipq807X platform the gziped kernel takes up more than 5 MiB. Therefore, you probably really need to increase the space to 8 MiB...
I have no luck with pull requests and reviewers. It’s better to create a similar pull request yourself.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@remittor hey, would you like to propose your patch into OpenWRT project? It wound be good to move the discussion there instead of continuing here.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's possible to chainload a second u-boot. See: https://web.archive.org/web/20230327231316/https://lunarius.fe80.eu/blog/tag/mt7622.html
I think a better option than increasing kernel partition size is to package a mainline u-boot as FIT, place it where the kernel is supposed to be, and put OpenWrt kernel+rootfs into UBI.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, wouldn't it make sense to reduce the kernel size? I wasn't aware that uboot had UBI support
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even MediaTek's ARM TrustedFirmware-A supports UBI by now, so on MT7622 devices where we anyway replace the bootchain we can have very simple MTD layout:
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have done similar change to what @nbd168 (c6319de) has done for AX6S - main...danpawlik:openwrt:resurrect-ax3200 which is working well after using sysupgrade image.
Tomorrow I will do test on fresh setup and check if its fine upgrading from stock to openwrt and between openwrt versions
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@danpawlik I still prefer the 2nd-uboot approach I mentioned above. I could prepare a PR for testing in a few days.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you create the image with
CONFIG_ALL_KMODS=y
so you actually end up with a kernel larger than 4 MiB?(as this is what buildbots are doing)
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dangowrt not yet, currently I just take my config that does not set this. Will try to make it tomorrow.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the device apparently has a dual-boot mechanism which is already a bit cumbersome to work-around my preference would be to replace the bootchain with something more flexible. But not a strong preference, having an example for 2nd-stage U-Boot in-tree is certainly also a good thing.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do see the appeal to the 2nd-uboot approach, and I think it means the kernel partition could be tiny (as it would only contain 2nd-uboot) and more space could be dedicated to UBI... with the user having more free space depending on the size of their kernel. I like that a lot and if this could be replicated for other devices I think it would be great.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A u-boot mod is better indeed. But I don't have an AX6S myself so I can't do that.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@danpawlik
my patch: #14768
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dangowrt I tested with
CONFIG_ALL_KMODS=y
- https://github.com/danpawlik/openwrt/releases/tag/resurrect-ax3200 and it works fine \o/ .I will make one more test, due I check a build where I enable BPF and.... it does not want to start. Don't have serial interface now to debug what's happening.
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sadly It doesn't prove anything as the kernel is still below 4096K. 😕
Could you try include some more kernel module?
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xabolcs sure, could you propose me some please?
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that BPF stuff looks good, but it works for anything that increases the kernel size - check the sysupgrade file after building, as I did above!
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you do
so you also build all modules from feeds (like the buildbot does).
It definitely ends up with more than 4 MiB size on the buildbots which is why I had to disable the board to unbreak the build...
dadad6b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xabolcs https://github.com/danpawlik/openwrt/releases/tag/resurrect-ax3200-bpf - enabled bpf, also works well on the device with fresh build
@dangowrt And about build: