I haven't pushed anything since 6.6.54, just haven't had the time. The pr is ready, I'm just waiting for the initial add 5018 target pr to go through, then I'll send it
Yeah, my mistake, tried to flash the zip, need to take my coffee before try to play with firmwares...
1 Like
the first rule of any sensible programming 
Hey there, it's me again, not sure if is just me, they are working great after flash all of them, now is way more stable, but I have problems with the DHCP server, it just give IPs for 5 hours and after acts like a dumb AP
Now it's show time:
2 Likes
yes i received a message informing me of the good news. Great work @georgem83 , @hzyitc and everyone who made this possible.
I just have one last thing to work out,
Currently, i have for the most part solved this issue.
this is incorrect, or at least as of 6.6.74, I simply added the second entry "b3000" and the glinet stock firmware upgrade now will accept it, furthermore, openwrt uses the first entry "glinet_gl-b3000" (or board-name), in turn ipq-wifi then correctly identifies the board bdfs and all is well.
The only issue i see with this approach is that 3 different image types are generated in the build. An .img file, .ubi file, and sysupgrade tar. The .img file is only used for the initial switch to openwrt. Generally, the sysupgrade tar is used to upgrade moving forward.However, in some cases ( in development anyway) a .ubi or .bin file was needed to reflect all changes, depending on the type of change ie board bdf's or changes to ath11k script etc. As mention, the .ubi can be used in these occasions, but to the best of my knowledge, a ubi file cannot have metadata attached. This results in having to use the force option, which imo seems incomplete.
So my question is, should i do something in the makefile, that would allow to build the .img file for the initial upgrade. And a second option for the sysupgrade and ubi.
which bring me to the final question, is the .ubi even needed ?
define Device/glinet_gl-b3000
$(call Device/FitImage)
DEVICE_VENDOR := GL.iNET
DEVICE_MODEL := GL-B3000
BLOCKSIZE := 128k
PAGESIZE := 2048
SOC := ipq5018
DEVICE_DTS_CONFIG := config@mp03.5-c1
SUPPORTED_DEVICES:=glinet,gl-b3000, b3000
UBINIZE_OPTS := -E 5
IMAGES := sysupgrade.tar nand-factory.img factory.ubi
IMAGE/sysupgrade.tar := sysupgrade-tar | append-metadata
IMAGE/nand-factory.img := append-ubi | qsdk-ipq-factory-nand | append-metadata
IMAGE/factory.ubi := append-ubi
DEVICE_PACKAGES := ath11k-firmware-qcn6122 ipq-wifi-glinet_gl-b3000
endef
TARGET_DEVICES += glinet_gl-b3000
Well done and thanks for all your hard work on this!
You may remember our brief discussions in this thread last November.
All current official Openwrt firmwares for Gl-inet routers can be flashed from the uboot web-ui. Currently this one will be the exception. (unless you added this and I missed it)
If I remember correctly, you had excluded uboot web-ui flashing because in your opinion it should only be used for recovery.
I assume this was to simplify the early development phase.
Now is probably the time to revisit this, as currently "recovering" back to stock firmware will be the only option for most users for a soft brick situation, something many people will want to avoid.
There are other reasons/uses for uboot web-ui flashing of official Openwrt. One that I mentioned is, for example, roll out of a number of devices in say a mesh network where the uboot web-ui is a much more efficient method allowing batch re-flashing. This is currently doable with every other gl-inet router.
1 Like
as i have said before ..uboot webui works as usual. And again, I see no advantage to what you are suggesting as it still requires the img file, regardless of how you decided to apply it.
Then, as usual, I can use uboot web-ui to flash the sysupgrade.bin, as I can for all other gl-inet routers? None of them use a factory.img.
Unlike all the other developers that have worked on porting gl-inet devices to OpenWrt.
and all these ports use uboot, not sysupgrade in which i much prefer. Take for example the case a few posts up, where a zip file was attempted to be flash. Thankfully sysugrade denied it, where as uboot, would have uploaded it a he would now have a brick, If i had not gone that route. The use of the sysupgrade method has saved at least 3 devices in this thread alone ....
All these ports require the use of the sysupgrade.bin in the uboot web-ui.
If you try an img or a ubi or a zip even, it will be rejected.
The exact same sysupgrade.bin can also be used in a running OpenWrt with the sysupgrade utiliy or luci.
The stock firmware is also a sysupgrade.bin.
That is fine if you prefer to use sysupgrade, but that is your choice.
The missing wifi partition should be reinstated and a sysupgrade.bin produced. Then, neither .img nor .ubi would be needed.
Sysupgrade, luci and uboot-web-ui could all be used for flashing official OpenWrt or Stock, simple.foolproof and consistent with all other routers from the same manufacturer.
Its not the wifi partition. A custom bootscript (.ifs) is used. Its stored at addr 0x42000000, this script call be adjusted to excluded the wifi partition. But from what i can see it, the kernel load address as well as a few other things need to be altered and imo it looks icky and it much more complicated then what i have done in my port. The only question remaining for me, is if the .ubi file is necessary to include in the build or not.
if you feel you need to be able to flash openwrt via uboot, you're more then welcome to take it on. I will help where i can, but i am in the middle of project at the moment and can't afford the time it takes to implement this and test it as thoroughly as required. And to be honest, i just do not see the need to do more work to implement a secondary upgrade option, that makes the upgrade more prone to user error, and as a result .. more hard bricked devices.
I will send the pr this evening and let the devs decide which is the best option
2 Likes
I ordered 2xB3000 yesterday, so love the fact the the PR will be fresh and ready for testing once they arrive 
1 Like
I can't even find a PR for the B3000.
2 Likes
Whenever the PR commit is approved.
1 Like
Glad I'm not the only one struggling to find it
1 Like
I'm just finalizing it now. it'll be there by days end don't worry.
4 Likes
I've started the pr ...
3 Likes