That's correct, however, for that to happen the uImage header magic and rootfs partition checksum would need to be bad. In which case, you have a bigger problem to worry about. Of course, you can always modify the bootcmd variable to perform all the necessary nand/ubi steps to get everything mounted and booted. I decided to stick with bootipq for sake of convenience. With the failsafe system, you can have a secondary OpenWRT image in rootfs_1
Thanks. I've just been using this as my bootcmd and it works fine setenv mtdids nand0=nand0 && set mtdparts mtdparts=nand0:0x1A000000@0x2400000(firmware) && ubi part firmware && ubi read 0x44000000 kernel 0x6e0000 && bootm
I'm about to upload an image, just waiting for it to compile. The flashing process is the same as yours
Edit: I was thinking, we might be able to flash images without opening it using the fw_setenv command in the stock fw. Like just make a small script that sets bootcmd to all the flashing commands then have bootcmd set itself to whatever command is used in the end.
@lmore377 -
i've got your images and have been able to write to nand - however, the factory firmware keeps booting. are there two images in nand? i could not find anything in environment vars that would indicate this.
i have tried writing both the initramfs-uimage and the nand-factory files - but still the factory (spectrum) firmware boots.
i cant figure this out -
do i need to setenv your alternate bootcmd ?
edit - this did not work either.
That's the problem I was talking about when using bootipq. The image is too small to override both of the stock firmware partitions, so uboot just overrides openwrt with the still good fw partition. Try reflashing and setting the bootcmd without restarting the router
The size of the image has nothing to do with it. You're not padding your uImage correctly which is why the header check done by the bootloader fails. If you flash my image, you won't have that problem. I'll be uploading my build files for the device later today.
@omdr3j -
your image boots from ram, but writing to nand fails in the same way - reboots to stock. there is a log of the process below https://pastebin.com/jEMkcJn0
what does the bootloader use for a header check? at the end of the log is the interrupted console and the printenv results.
With my image you need to run setenv mtdids nand0=nand0 && set mtdparts mtdparts=nand0:0x1A000000@0x2400000(firmware) && ubi part firmware && ubi read 0x44000000 kernel 0x6e0000 && bootm saveenv
after flashing then reboot
That image doesn't have luci or anything extra installed. I'm rebuilding a new one with some extras
From the logs you posted, I don't see it reverting back to stock. However, it looks like your bootloader always boots from rootfs_1 instead of the default rootfs. I'm now wondering if this is the case on certain revisions? Although, your revision numbers match with mine. If you don't mind completely wiping out the stock firmware, would you mind running a test by writing my image to both partitions? You can do this by running these two commands after TFTPing the image over.
If you're going to use @ondr3j image, only use the instructions here. This image leaves one of the stock partitions, but there's only about 150Mb of free space. I recommend this if you're renting the router.
If you're going to use my image, only use the instructions here. This image overrides both stock partitions so it'll be impossible to go back. Because it overrides both partitions, theres about 300Mb of free space. I recommend this if you own the router (bought it off of eBay or something)
I don't mean to sound rude, but what would that accomplish? We have sufficient access in U-Boot right now. You can modify the bootcmd variable which gives you the ability to use a larger portion of the flash for your firmware.The PBL in the SoC ROM (which is out of our control) authenticates SBL* based on its signature, which in turn validates APPSBL. Messing around with any of the SBL* or APPSBL partitions puts you at risk of bricking your device. We haven't found JTAG pins on the board yet, so there would be no going back.
There's not much else to do. At this point I'm just putting some finishing touches and making sure things like Mac addresses are correct. Can you connect the router to the internet and run speedtests over ethernet, 2.4ghz wifi, and 5 GHz wifi and tell me if speeds are what you're expecting?