How to flash a new u-boot on Turris Omnia

2 posts were split to a new topic: Version of u-boot in Turris MOX

Between documentation and forum I did not understand much. I have Omnia with 5.0-dev. How do I update U-Boot? Do I do it with serial cable? Do I do it from Turris OS? What are the steps? How do I know which version I have and if a newer one has been released? Where to download?

It’s my questions above.

I saw that there was an exchange of messages. But in the end did you understand how to do it?
I tried using nor-update from the Turris OS shell and it gives me the message: No stable images yet! Does that mean I already have the latest version?

Nobody from Turris team answers. You can flash memory via mtd-utils, but available images are old.

http://www.linux-mtd.infradead.org/doc/general.html

nor-update is a wrapper for userland

that automates the process since the use of mtd is not for the faint-hearted and assumes a knowledgable user or else the node can be bricked easily.

Once a new u-boot version gets released it is likely that nor-update gets (script) invoked without user intervention and the release notes propagated in the forum presumably advertising such update.


  • nor-update via ssh

or

  • mtd via ssh

or

  • via serial as mentioned

Not for MOX and Omnia CZ11NIC23.

It is also known that the NIC.CZ team is working on an updated version, although the process/progress is not transparent, but as previously cited in this thread (and repeating it does not speed up things)


There are various responses pertinent to the subject from the NIC.CZ team in the forum, as cited (even repeatedly) in this thread.
The thread was conceived during the seasonal holidays and would appear not something interrupting the operations of TOS and thus warranting an immediate response from NIC.CZ team, notwithstanding this being a user community forum.

Issue mentioned above [1] been closed (and locked) without any milestone | assignee set (sans transparent progress) and issue [2] has an assignee set but no milestone and no progress (backlog label).


[2] https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/462

2 Likes

Full state on uboot for Omnias of all revisions is that we have new uboot running and deployed on CZ11NIC23. Images are not propagated as stable to all Omnias in Turris OS 4.0+ because there are problems we have to iron out. The problem at the moment is that CZ11NIC13 has potentially only two ram chips and that has to be managed in ram training process. It is not rocket science but we are trying to do it in upstreamable way and most importantly our kernel developers are still tied up with Mox issues.

This blocks automatic boot switch between SFP and metalic ethernet WAN and enable of new features in uboot. Neither one is huge problem because automatic switch is not required technically as you can switch to SFP manually (just relink /boot/dtb to appropriate device tree) and new features are not essential. I am not saying that it is ideal state I am just saying that it is not critical such as other issues our kernel developers are tackling at the moment. Please have patient. Those issues are stalling because other issues are being solved.

4 Likes

That is appreciated to a certain extent, yet not being able to boot from a GPT partitioned drive but legacy MBR only is rather unfortunate, not booting from an exterior USB drive notwithstanding.


That being a well rehearsed tune it is not for the first time that

is being cited for delays on the other platforms. Of course the M issues have to be sorted but it comes at the expense of the other platforms and the M issues seems to be home-grown in the first place, least what transpires in the public domain.

The developer team been spread thin already prior the inauguration of the M platform and with all teething problems seems to be drawing a considerable amount of resources away that creates an imbalance for the other platforms.

I do acknowledge and appreciate the amount of work being undertaken but unfortunately it seems that the development curve for non-essentials is falling behind again.

Will Omnia CZ11NIC13 with updated u-boot support new reset modes?

https://docs.turris.cz/hw/omnia/rescue_modes/

1 Like

Unified U-Boot and Rescue behaviour, across all TO revisions - that would be incredibly useful.

1 Like

Both are valid points for the TO platform, adding:

  • u-boot support for GPT [1]
  • u-boot support for exterior USB(3) (already available for MOX) [2]
  • omnia-support [3] availability in OpenWrt repo for unified user experience in updating u-boot

Unfortunately development for the TO platform has fallen victim to the MOX.


[1] https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/462
[2] https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/485
[3] https://github.com/CZ-NIC/turris-os-packages/tree/master/hardware/omnia/omnia-support

Definitely. I like MOX also but there is the need to solve existing known problems first.

Picking up on that thought there is also the CZ11NIC20 revision.

And what is not clear from the documentation is whether uboot-envtools (fw_setenv command) are included with the

5 LEDs: Unsecure SSH on 192.168.1.1 (Omnia 2019 and newer)
You will end up in rescue mode with limited capabilities

mode or still a serial cable would be required to manipulate the boot variables?

New informations arrived.

How I can test new u-boot for Omnia, eventually MOX?

tested u-boot 2019.07 on CZ11NIC20 that features Bank gpio@71_ (boot.scr probes gpio input gpio@71_4) and with the symlink /boot/dtb removed SPF is automatically detected.

5 LED rescue (Unsecure SSH) through did not work.


N.B. querying u-boot version via ssh cli with strings /dev/mtd0 | grep 'U-Boot 20'

Can you help me how to do?

Also thanks for issues description.

:warning: at your own peril

1 Like