I got from colleague AmigaOne XE. And I have some questions.
1. What is correct U-Boot version from Hyperion?
On Hyperion download site is written "AmigaOne Firmware Update *05-Mar-2005*"
And version which is on my AmigaOne is: U-Boot 1.1.1 (Mar 3 2005 - 16:42:53)
This is two days difference. Is it hotfix or some mistake?
Please do somebody have AmigaOne with last Hyperion U-Boot and can check the version from computer?
Can I flash it?
I also have Micro with U-Boot 1.2.0 and it is working perfectly. Is there way howto download U-Boot without removing the ROM? Then I can flash XE with newer experimental U-Boot.
2. My board is DMA fix.
There viewtopic.php?f=16&t=1889 is perfect explanation from tonyw what DMA fix is.
Is possible to do Un-Fix ?
Have somebody exact information which tracks were cutted?
I want to made some experiments and need to use PCI 66MHz slot.
Or, if somebody have unfixed AmigaOne
A1200, Micro A1-C (G3/1.2 GHz), AmigaOne XE (G4/1.4 GHz), Pegasos II (G4/1.33 GHz), Sam440ep, Sam440ep-flex, Sam460LE, AmigaOne X1000
Efika 5200b, Pegasos I, Powerbook, Mac Mini (1.83 GHz), iMac, Powermac Quad
AmigaOS, MorphOS, linux, MacOS X
1 - iirc the two day difference comes simply from the fact that uboot was compiled on the 3rd of march, but officially released two days later.
2. Everything is possible, the question is
a) will you find someone who has the blueprints of the fix, the means and skill and is willing to un-fix
and
b) are *you* willing to probably brick a perfectly fine board?
@raziel
thanks, number6 also confirm this. It is good news, I cannot reflash it.
and no, I don't want to brick it. I want to improve it . I know, it is the risk, but upto now I didn't destroy any of my old computers.
A1200, Micro A1-C (G3/1.2 GHz), AmigaOne XE (G4/1.4 GHz), Pegasos II (G4/1.33 GHz), Sam440ep, Sam440ep-flex, Sam460LE, AmigaOne X1000
Efika 5200b, Pegasos I, Powerbook, Mac Mini (1.83 GHz), iMac, Powermac Quad
AmigaOS, MorphOS, linux, MacOS X
@ZeroG
Many thanks!
Please is possible to send it to me via PM, attachment or similar? Because on www.os4welt.de the attached files are hidden, if I am not logged on.
And is something curious to make here registration for single file...
A1200, Micro A1-C (G3/1.2 GHz), AmigaOne XE (G4/1.4 GHz), Pegasos II (G4/1.33 GHz), Sam440ep, Sam440ep-flex, Sam460LE, AmigaOne X1000
Efika 5200b, Pegasos I, Powerbook, Mac Mini (1.83 GHz), iMac, Powermac Quad
AmigaOS, MorphOS, linux, MacOS X
I came across this article about hacking of U-Boot on other systems, just wondering if it could be used by hackers to affect the Hyperion version in any way.
New U-Boot flaws could enable stealthy firmware attacks
By Lawrence Abrams July 10, 2026 05:59 PM
Six vulnerabilities in the widely used U-Boot bootloader have been discovered that could allow attackers to execute malicious code during device boot, potentially enabling stealthy firmware attacks that compromise security protections and install persistent malware.
U-Boot is one of the world's most widely used open-source bootloaders and is found in many embedded Linux devices, including enterprise servers' Baseboard Management Controllers (BMCs), networking equipment, industrial systems, IoT devices, and other appliances.
Because U-Boot is responsible for loading the operating system, vulnerabilities in the bootloader can allow attackers to compromise a device before the operating system and its security software have a chance to start.
One of its security features, known as Verified Boot, uses cryptographic signatures to ensure that only firmware and operating system images signed by a trusted key are loaded during startup.
In a report published this week, firmware security company Binarly disclosed six vulnerabilities in U-Boot's FIT (Flattened Image Tree) signature verification code.
"Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely," explains Binarly.
"This research revealed six distinct vulnerabilities, ranging in impact from denial of service (DoS) to arbitrary code execution during the verification of an untrusted image."
According to the researchers, two of the flaws can potentially lead to arbitrary code execution during firmware verification, while the remaining four can be exploited to crash vulnerable devices.
As these flaw impact the code for validating firmware images before the operating system starts, if an attacker can exploit that process, they may be able to execute malicious code before the operating system loads.
The six disclosed vulnerabilities are:
BRLY-2026-037: A flaw that can cause U-Boot to crash when processing a malicious firmware image and, under certain conditions, can be used for arbitrary code execution.
BRLY-2026-038: A memory corruption vulnerability that could allow attackers to execute arbitrary code during firmware signature verification.
BRLY-2026-039: An out-of-bounds read vulnerability that can crash devices by forcing U-Boot to read beyond the firmware image.
BRLY-2026-040: A null pointer dereference that allows specially crafted firmware images to crash the bootloader.
BRLY-2026-041: Improper validation of externally stored firmware data that can cause U-Boot to crash when processing malicious firmware images.
BRLY-2026-042: An unbounded recursion flaw that can exhaust available stack memory and crash the bootloader.
According to Binarly, most of the vulnerable code has existed since U-Boot version 2013.07, causing the flaws to potentially affect more than 50 releases of the project as well as vendors who utilized the vulnerable code in their own firmware.
"This means that they potentially affect over 50 stable releases of the U-Boot project. Counting many downstream vendor forks, these vulnerabilities have a significant impact on the industry," explains Binarly.
If successfully exploited, the arbitrary code execution vulnerabilities could allow attackers to execute code during the earliest stages of the boot process.
Because this occurs before the operating system loads, attackers could potentially disable firmware security features, modify the boot process, install persistent firmware malware, or carry out other malicious actions with high levels of access.
Binarly says that malicious would be difficult to detect because they execute before the operating system starts.
Binarly says exploiting these vulnerabilities does not always require physical access. On systems such as BMCs that support remote firmware updates, an attacker who has already compromised the management interface could upload a specially crafted firmware image to exploit the flaws.
Binarly reported the vulnerabilities to the U-Boot maintainers and submitted patches for all six issues, which have since been accepted into the project's upstream codebase.
However, because U-Boot is integrated into firmware by individual hardware manufacturers, the fixes must first be incorporated into vendors' firmware updates before they can be distributed to customers.
Older or unsupported devices that no longer receive firmware updates may never be patched.
