Hello, it seems this issue may have happened after the switch to the 5.15 kernel.
The snapshots downloads page show no Image Files:
When building the image for the latest snapshot release, everything compiles fine but the install binaries do not get generated. I'm assuming this is why there are no image files on the downloads page.
The follow message occurs:
JSON info file script could not find any JSON files for target
They changed ipq40xx over to DSA. And that means for some devices, like the Google Wifi, that some porting still needs to be done.
I myself have a few of these Google Wifi devices, which I want to use. And therefore I made my own fork, with the adjustments which I think are needed to build it. ( https://github.com/AvdWerfhorst/openwrt/tree/master ) . But saying that, I did not find the time yet to actually build and test it. That's probably a thing for next weekend.
btw, please don't put too much trust in my fork. I am more an end user than a programmer.
Thanks for the reply. I'll check out your fork.
Regarding DSA, I don't believe that is the issue because I have several Google Wifi devices currently running on the 5.10 kernel (v22.x) snapshots w/ DSA. I believe this issue occurred when they switched over to the 5.15 kernel in early September of this year.
When compiling on the latest 5.15 kernel there are no errors and all of the packages are successfully created. The issue seems to be with the "bundling" of these packages into the install binary.
By comparison, when I compile the
/ipq40xx/generic for the 5.15 kernel, the install binaries are created and it generates a
json_info_files dir with a
*.json metadata file. The
/ipq40xx/chromium isn't doing that, so I'm assuming something changed in 5.15 that broke this.
I'll keep poking around but hopefully someone who manages the chromium code can resolve this. -thanks
No, @AlbertvdW is right. The target got completely disabled because of "lack of DSA setup":
Looks like the committer never even bothered to send any patch at all to the dev list (where I might have noticed), let alone a direct notice to affected contributors...
I'll try to read the docs and see if I can get something working, but this feels like rude behavior.
I did a build of my fork. I managed to build it to an image, without error message, weird crash or whatsoever. If my day goes like expected, tonight (it is now morning here) I will put it on one of my Google Wifi devices and see if everything works like expected.
I'll warn you, I already tried myself (similar patches), and there's at least one more regression to fix. The bootloader doesn't like that some of the old gmac paths are missing.
I'll put my (now working) changes up within 24 hours I hope.
OK, I pushed a patch to this branch: https://github.com/computersforpeace/openwrt/tree/gale
This works for me. Let me know how it goes for you, and I'll make a pull request or patch mail.
I am right now cloning your branch in preparation for a build. I will get back about it when I have completed the build and apply the image to my Google Wifi device.
@bnorris You branch works for me as expected. Great work.
Thanks @bnorris and @AlbertvdW for fixing/testing this issue! The install binaries are successfully building and currently available on the downloads page: https://downloads.openwrt.org/snapshots/targets/ipq40xx/chromium/
Would either of you have any idea when a stable build may be available for this device? I'm assuming it's not going to make it in v22 due to the 5.15 kernel switch?? -thanks
@quantonian It's probably in the next stable series, as that will at one point split from the then current state of the master. So 23.*
Technically, there were only a handful of patches needed on top of existing ipq40xx support to get it working, so it probably could be enabled on the 22.03 release branch without too much effort. And it's been done -- the 22.03 release notes mention various added device support:
But that would require convincing a committer. I can help point the right patches out if you'd really like, but I don't plan on pushing for that myself.
So @AlbertvdW is probably right, and you'll need to wait for the next release branch.
Okay, thanks guys.
@bnorris, pointing out the right patches would be greatly appreciated! And if you have any contact information regarding who would need convincing to get this committed would be great. Being that it is a handful of patches away from a stable build, it would be nice to see this in v22. Thanks!
For who needs convincing: frankly, I don't really know. I think hauke does a lot of the work, and you can see his notes on recent releases here:
I guess maybe you can just open a Github PR, if you get something working (
git cherry-pick -x, build, test, push), and get it into this queue:
Awesome @bnorris, thanks for the info! Looks like you've put a lot of time and effort into this device, it's a shame that it's not already included in the stable builds.