You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
U-Boot in RVVM currently reuses QEMU board config. This works fine for the most part, but needs a few additional patches which are queued up for mainline U-Boot: https://lists.denx.de/pipermail/u-boot/2024-July/559139.html.
Let's hope they are accepted at some point, but we may always build an out-of-tree fork if needed.
The bigger issue is that QEMU U-Boot config (Or perhaps U-Boot on RISC-V in general?) needs at least 256M of RAM to work reliably. This is quite a lot, in fact it's the most RAM you can put into a computer in survival currently.
It's most likely artificial for the most part, since the same issue happens with OpenSBI and is already patched by me.
This must be fixed to make U-Boot work on 16-32M computers, as I don't want to resort to flashing Linux kernel into firmware chip.
Additionally, U-Boot always consumes 100% of CPU. This is normally OK since boot process doesn't take a lot, but it's quite problematic for computers which were powered on without a working OS.
Computers are already CPU limited, but ideally this may be fixed by implementing CPU sleep in U-Boot mainline for RISC-V.
The text was updated successfully, but these errors were encountered:
U-Boot in RVVM currently reuses QEMU board config. This works fine for the most part, but needs a few additional patches which are queued up for mainline U-Boot: https://lists.denx.de/pipermail/u-boot/2024-July/559139.html.
Let's hope they are accepted at some point, but we may always build an out-of-tree fork if needed.
The bigger issue is that QEMU U-Boot config (Or perhaps U-Boot on RISC-V in general?) needs at least 256M of RAM to work reliably. This is quite a lot, in fact it's the most RAM you can put into a computer in survival currently.
It's most likely artificial for the most part, since the same issue happens with OpenSBI and is already patched by me.
This must be fixed to make U-Boot work on 16-32M computers, as I don't want to resort to flashing Linux kernel into firmware chip.
Additionally, U-Boot always consumes 100% of CPU. This is normally OK since boot process doesn't take a lot, but it's quite problematic for computers which were powered on without a working OS.
Computers are already CPU limited, but ideally this may be fixed by implementing CPU sleep in U-Boot mainline for RISC-V.
The text was updated successfully, but these errors were encountered: