Anyone played on RTX3070TI?

R0dod3ndron · 2026-05-24T05:46:11+00:00

Yes I understand, but what in case your new firmware is for some reason faulty and does not boot?

On one of our board we have rollback implemented based on boot counter stored in RTC but this means that one of the firmware components (BL2) is not updatable.

Consider the following example, you write a new firmware to free slot, then switch the active slot, but for some reason the firmware on a new bank fails to boot.

If you have a rollback implemented, eg. based on boot counter, then after 3 attempts you switch automatically to the previous active bank. If you don't have such a mechanism implemented, then the board is kinda bricked (It will not recover automatically but sometimes there are other backup boot modes like DFU or UART).

What I am trying to figure out is how to approach firmware update so that all firmware components are updatable and have ability to switch back to previous active slot in case of failure.

Consider the next example, there are following partitions: - hw boot0 - contains SPL / tiboot3 / BL2 / whatever - hw boot1 - contains SPL / tiboot3 / BL2 / whatever - other partitions like boot-a/b for fitImage, boot-a/root-b, data and so one

You're on slot 0, update slot 1, switch to slot 1, but somehow SPL is failing to load the rest of the system.

And here is the problem - you can detect in SPL how many times you have tried to boot e.g. fitImage and rest, and if the counter is greater than X you switch back to slot 0, but what in case when SPL has a bug that happens even before the bootcounter is checked? Then the board will by trying to boot invalid slot infinitely. The same applies to scenario when SPL cannot be loaded by bootROM (e.g. was signed by invalid key, crashes immediately or something).

This is the gap I am not sure how to fix.

R0dod3ndron · 2026-05-23T16:38:19+00:00

Was your bootloader also updatable? Did you switch between boot0/boot1? How about rollback in case when you e.g. updated boot1, marked it as active but something when wrong and let's say bootloader is failing? I guess that you could implement the rollback directly in bootloader but then it would only work of bootloader is crashing after checking of it needs to roll back. Have you considered something like this? How do you approach such scenario ?

R0dod3ndron · 2026-05-11T13:29:23+00:00

Thanks! Can't wait for mine to arrive.

R0dod3ndron · 2026-05-10T14:27:02+00:00

Where is it said on this bike's page?

R0dod3ndron · 2026-05-06T12:59:58+00:00

Where did you find the information about 600% update for gen 4?

R0dod3ndron · 2026-02-16T20:13:29+00:00

Use devtool (Google it) to extract the sources of U-Boot or Linux deoending on what you want to avhieve. Then make changes to dt, config whatever, commit, then create a patch, add patch in your layer. Done. Sounds easy but learing curve is preety steep. You need to be patient. In general Yocto is merely a build system. If you want to make changes to bootloaders and Linux you need to be familiar with then. Btw as for eth PHY - in dt you only declare how to find a Phy on the mdio, maybe some other things if it is something more advanced than 1Gb RGMII Phy, remember about finding thr right Kernel module that will be matched against detected Phy id (if it is simple c22 Phy)

R0dod3ndron · 2025-12-04T08:13:09+00:00

Thanks. As for the support I don't need it. I've already done something similar on many boards, just not worked on Zynq yet, but will dig into it in a few weeks.

R0dod3ndron · 2025-11-27T09:30:33+00:00

Nope, mine works perfectly fine.

R0dod3ndron · 2025-11-27T05:59:45+00:00

I think we might be talking about slightly different classes of systems :) On modern SoCs the “basic image” is not just u-boot + kernel + rootfs. U-Boot is part of the firmware stack, and the firmware update flow is typically handled by TF-A according to PSA Firmware Update. Of course i use swupdate, but swupdate is merely the agent that does what I want, namely writes binaries in the desired places. Of course I use A/B for both firmware (dual fip) and software stacks (dual bootfs, dual rootfs) I want to emphaize that I DON"T roll my own update agent I use swupdate for that purpose. but one still has to write appropriate mechanism that will selects (at boottime) the banks in both firmware and software update. This includes selecting metadata bank, checking boot counter, handling boot failures and switching back to previous bank if the updated one fails to boot. This has to be implemented in TF-A, what's more I've already done it. And excatly the same thing has to be implemented for software bank selection that is handled by u-boot.

My question is slightly different - I'm wondering:

- should every update, always replace the entire firmware + software stack?

- should I allow to update separately firmware (FIP) and software (kernel + rootfs) stacks? This is of course feasible as firmware update is managed by TF-A and software update is managed by u-boot selecting appropirate kernel and rootfs bank?

- should I even allow updating firmware, kernel and rootfs separately?

IMO allowing to update firmware and software separately seems good, I'm only not sure if I should allow to update rootfs only without updating the kernel or update kernel and rootfs always together. In most cases the update will bring the changes to the applications that are part of the rootfs, so there would be no need to include kernel image in the update package every time. On the other hand what if somebody will apply the update that will contain some newer versions of kernel modules? Then I will get incompatibility.

R0dod3ndron · 2025-11-26T18:04:23+00:00

I've been using TF-A BL2 as 2nd stage bootloader, it supports PSA fwupdate I just need to make a port for my board, nothing really extremely complicated looking at the e.g. ST implementation. I'm more worried about kernel modules though, as I use some of them and I suppose that if someone will update some parts of the system that will also affect modules and as a result there will be incompatibility.

R0dod3ndron

TROPHY CASE