EDIT: found the schematics, located the S25FL116K. Will play with it tomorrow.
Open question: how did the RX fry without the TX being affected?
–
I managed to mess up the uboot block on my Omnia (using fw_setenv, btw)
...
flags: 64bit ncq led only pmp fbss pio slum part sxs
Net: neta2
Hit any key to stop autoboot: 0
Unknown command 'host' - try 'help'
Unknown command 'host' - try 'help'
=>
Normally that wouldn’t be much of a problem, except for the fact that apparently my router’s RX is fried - I tried 2 cables, and it doesn’t seem to receive anything (the PC receives just fine, so the TX is ok).
Soooo… any hints on how to produce a CRC error? I’d imagine the flash is connected to SPI, but I think I could handle JTAG too if need be - if only I knew to which chip and which interface.
PS. Ironically, I did the setenv thing to get rid of a “boot block crc error” message that appeared on boot. Bad idea…
And also saw some docs-thing about root partition moved to extroot (SSD for example) that required messing with uboot env values. And as far as I remember there were the original values (or almost original) as well. I will find it I think…Yup I got it: https://doc.turris.cz/doc/en/howto/omnia_booting_from_external_storage
I guess this should help you to boot from USB and then investigate uboot more.
In the case of emergency I could unscrew my router plug UART cable and try to get orig values if I manage to but this only at the begining of the weekend when I have time to mess around with no internet at home.
EDIT: Owww no RecieveX (RX) or TX? So you can send a message but cannot recieve or recieve but cannot send? I dont understand so how did you get log? As an answer I see http://dangerousprototypes.com/docs/Bus_Pirate as a try.
Router’s RX is fried - I cannot send from PC; router’s TX works, I can receive - hence being able to provide the boot log. That’s why I got interested in the flash (not eMMC) chip
In the mean time, I found the schematics (https://doc.turris.cz/doc/_media/rtrom01-schema.pdf) and identified the SPI flash chip on the board; I’ll take the router to work tomorrow, connect to the flash chip, back it up :), and then wipe the environment. I hope that’ll fix it.
And yeah, if I can’t figure out what the story is with RX not working, I’m getting another Omnia (I don’t like being locked out of the BL :D). Need to check with some friends who are better at this than I am
Note to the devs:
I don’t suppose you could hack fw_*env to display the correct default environment block for our Omnias, could you?
The reason I’m asking is: the way I bricked my box was by simply doing a fw_setenv that would set a variable to the value fw_printenv lied to me it already had. And I ended up with an environment block that didn’t look one bit like what I can see in https://gitlab.labs.nic.cz/turris/turris-omnia-uboot/blob/master/include/configs/db-88f6820-gp.h …
In default in Omnia is default uboot environment not flashed to nor to discourage from tampering. The idea is that it is that unless you use serial cable and do in uboot saveenv you should not see environment. Most users should be convinced not to tamper with it when they see CRC error and serial cable is when you break stuff required in such case. I am not saying that it is an ideal state but having duplicate environment in package seems to me as not a good idea.
To restore uboot environment you can use serial cable and with two commands env default and saveenv you can restore original environment and at the same it fw_printenv starts working.
