I find the tutorial really annoying to update the bootloader, why isnt the firmware update doing this automatically? Why is this so complicated? Why isnt this possible from the normal booted GUI?
Will all my configs and files be resetted this way?
Received the same message. Also very confused - and wondering if this is some kind of scam to get people to install a compromised firmware? The uboot firmware file is not even hosted on their own website/domain.
Never manually updated the uboot, why would I need to do so now. And what is the actual issue if its reducing the device's lifespan? The only thing I can imagine is excessive wear on storage in some way.
Looking at the upgrade tutorial it says: Upgrading U-Boot is very dangerous and generally not recommended. ...well okay then. And it seems to require a wired connection, which I don't have as all devices here are using WiFi.
GL.iNet REALLY needs to provide more information about this. The issue, and a MUCH better explanation on how to perform the procedure. Especially if it is, apparently, so dangerous.
A bit confused as well here. I have an X3000 bought direct from Gl.iNet in May of 24 currently running 0704release5 firmware. Do I need to update U-Boot or not? I do reboot mine at least 2x a day. Never seen an issue though.
From that thread it looks like you need to upgrade both the firmware and uboot. Firmware can be done using the web gui (For me it prompted automatically if I want to upgrade). The uboot though is another story, and requires a rather difficult process that - according to the other thread - has already destroyed quite a few routers.
The actual issue is unclear though. Some seem to believe that with every reboot there is a percentage chance of a broken device. But the way the issue was worded by GL.iNet makes me believe that this is a wear-issue, meaning that all routers currently in use have already suffered damages and now have a shortened lifespan. Could GL.iNet please confirm what has happened?
Glinet needs to implement the bootloader flash process into the fw so it does this automatically with next fw update
Wonder if there is a bug in the bootloader which unnecessarily writes to the same flash memory blocks (with each reboot, or with each fw update, or even worse randomly all the time even after boot) and make them become damaged over time so the device stops booting eventually.
I upgraded the uboot following the procedure indicated in the email that the technical support sent me:
I have a Spitz x3000
1 - I downloaded the uboot upgrade file as indicated in the table attached to the warning email and only the one specific for my router model.
2 - I connected the only lan port of the router with the ethernet port of my pc and disconnected the wan cable (this router has no other ports)
3 - I turned off the router
4 - I held down the reset button and turned the router back on
5 - as soon as I saw the "internet" LED flash I freed the reset button
6 - then I changed the ip address from the Lan network settings window of my pc's network card by entering in IP Adress 192.168. 1.2 in subnet mask 255.255. 255.0, the rest all without any number.
7 - I typed the URL address http:// 192.168.1.1/uboot etc.etc. and the update window also indicated in the email from technical support appeared. I selected the file from the "download" folder on the PC where it was saved and clicked "update". The "update completed" notice immediately appeared with the rotating bar indicating the router restart in progress. It rotated for several minutes but for fear of blocking the procedure in progress and bricking the router, I did not interrupt anything, if anything I opened a new window on the browser and entered the address of the router "my custom one" that I had previously, i.e. 192.168.5.1 and not the default one 192.168.8.1 and I noticed that the router was working fine so I closed the window where there was still that circular bar that was still rotating indicating the restart of the UPDATE uboot window.
In this easy procedure I noticed that:
1 - without the sim card you cannot access the page http//:192.168.1.1/uboot etc.etc (I had previously removed the sim card)
2 - I had already done the update of the latest firmware version 4.7.4 a few days ago and therefore the upgrade was done in half a second! Maybe because it is too small (a few Kbytes) or it is already contained in the latest firmware because from the moment I clicked on update after selecting the uboot file from the download folder of the PC, to the moment in which the window indicated "update completed - reboot in progress" less than half a second passed.
3 - no settings in the various router menus were lost or reset to default.
At the moment the router is working fine. This is my experience and I share it
I did as the email told me, I downloaded uboot-mt2500-20250224-md5-74286e770cfb041b611d80d4adaef189.bin
did the precedure of remove all cables except lan, removed power, hold reset button, put back power, LED flashed then stopped, I released reset button.
I was able to go to http://192.168.1.1/uboot.html uploaded the bin file, pressed update, waited... and now my Brume 2 is DEAD. DEAD DEAD DEAD.
Didnt come back online anymore, waited for 10 minutes. No LEDs showing up. Removed power, pressed reset button put back power, no LEDs showing anymore. DEAD. Awesome.
I will write to the support email and ask for a free replacement.
usually you do not update U-boot, but you would if something is really wrong and firmware cannot fix it.
like a pc, a pc has a bios you can compare U-boot like exactly that, in simple layman terms although it is a little bit nuanced.
as a example a while ago for the Flint 1 we needed to upgrade U-boot aswell because of ethernet ports randomly breaking or changing this could only be fixed there via U-boot.
So to come back on the Brume2, what I suspect is that they either enabled a environment variable to speed up EMMC (my guess!) and that caused early tearing of the EMMC which means it will lower the lifetime, or... they enabled something else related what tears up EMMC faster, though I never was able to read the full issue about this and wether the hardware is also a issue which is kinda mocking me, you can compare it with nvidia too on some brands where they used cheaper memory which could break, in some facilities that is normal procedure that chips gets swapped by different ones and so on there might be brume2's with different EMMC chips and quality (maybe).
this U-boot image is supposed to address that, however it seems to fail with a higher amount than expected.
what I don't know is how GL-iNet did tests, maybe they where automated in software and not on the real physical device?, then that is likely the issue.
I wish there was so much more transparancy about this
Flashing a rom as bios/bootloader shouldnt be dangerous except of some unforseen event like power loss. You do this all the time in todays world with motherboards and flashing bios. It is 2025 not 1995. I never encountered a bricked device flashing eeproms in over 20 years. Now that we have several reports of Bricked 2 after updating the uboot, it is more likely something else is going on. Either the uboot file is corrupt and never was tested by Glinet for the Brume 2 in hardware, big fail, or the uboot update process has some flaws in it itself.
A 26 MHz clock speed in the context of eMMC (Embedded MultiMediaCard) refers to a legacy transfer mode (Single Data Rate or SDR) where the eMMC device communicates with the host at a slower speed.
and
In eMMC communication, a 12mA drive strength is often specified for signal lines like EMMC_CLK, EMMC_DATA, and EMMC_datastrobe to ensure proper signal integrity and reliable data transfer,
Interesting. The date for these commits is a bit later than the uboot fixes that were released. But it is possible that these were first fixed in their own codebase and later merged back into generic openwrt?
If these two fixes indeed are the reason for extending the warranty, then I guess the "at slower speed" fix is not the issue. However the 12mA may refer to power levels which, if incorrect, could potentially physically damage storage. I'm guessing the eMMC here does not refer to a specific boot storage, but rather, the general storage available to the router...
So the flash chip might have been "fried" because of too high current being used over time? Why are these commits then after the released new patch file? Or is this a new issue which means there needs to be nother uboot update coming? Does the Brume 2 even have a seperate bios/rom chip for the uboot image, or does it just have one emmc flash with seperate partitions, one bios/uboot, one for firmware.
