Add hardkernel-odroid-h4-plus docs #903
Conversation
philipandag
force-pushed
the
hardkernel-odroid-h4-plus-docs
branch
from
fa4d4e1 to
5f07834
Compare
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
philipandag
force-pushed
the
hardkernel-odroid-h4-plus-docs
branch
from
5f07834 to
e162fab
Compare
| 3. Build the firmware: | ||
|
|
||
| ```bash | ||
| ./build.sh odroid_h4 |
There was a problem hiding this comment.
IT DOES NOT WORK
Will we add this platform to the build script? It might as well be replaced with manual build instructions if not.
There was a problem hiding this comment.
We may add the platform to the build script.
There was a problem hiding this comment.
Working on it here: Dasharo/coreboot#564
philipandag
force-pushed
the
hardkernel-odroid-h4-plus-docs
branch
from
afb6187 to
12953f1
Compare
Signed-off-by: Filip Gołaś <[email protected]>
philipandag
force-pushed
the
hardkernel-odroid-h4-plus-docs
branch
from
12953f1 to
befecc5
Compare
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
| 3. Build the firmware: | ||
|
|
||
| ```bash | ||
| ./build.sh odroid_h4 |
There was a problem hiding this comment.
We may add the platform to the build script.
Signed-off-by: Filip Gołaś <[email protected]>
philipandag
force-pushed
the
hardkernel-odroid-h4-plus-docs
branch
from
746fa1f to
07655bc
Compare
Co-authored-by: Michał Żygowski <[email protected]> Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
| - [Releases](../../variants/hardkernel_odroid_h4/releases.md) | ||
| - [Hardware Configuration Matrix](../../variants/hardkernel_odroid_h4/hardware-matrix.md) | ||
| - [Test Matrix](./test-matrix.md#hardkernel-odroid-h4) |
There was a problem hiding this comment.
Many links are missing: firmware udpate, iitial deployment, recovery, building manual...
There was a problem hiding this comment.
Sorry, I've filled them later and forgot to update.
3f54856
There was a problem hiding this comment.
Take a look how other platforms add overview. e.g. Dell OptiPlex:
* [Releases](releases.md) - groups information about all releases.
* [Building manual](building-manual.md) - describes how to build Dasharo
compatible with Dell OptiPlex 7010/9010.
* [Initial deployment](initial-deployment.md) - describes initial Dasharo
deployment methods (i. e. flashing new firmware) compatible with Dell
OptiPlex 7010/9010.
* [Firmware update](firmware-update.md) - explains supported Dasharo
open-source firmware update methods.
* [Recovery](recovery.md) - gathers information on how to recover the platform
from potential failure.
* [Hardware configuration matrix](hardware-matrix.md) - describes the
platform's hardware configuration used during the Dasharo firmware
validation procedure.
* [Test matrix](test-matrix.md) - describes validation scope used during
Dasharo firmware validation procedure.
The commit is very minimal
Co-authored-by: Michał Żygowski <[email protected]>
Co-authored-by: Michał Żygowski <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
| 1. Move the flash selector jumper to select the backup flash chip. If the | ||
| device does not boot from any of the flash chips, an external recovery | ||
| needs to be performed. In that case continue with the recovery instructions | ||
| for the ODROID H4 model. |
There was a problem hiding this comment.
@philipandag please link that section I guess you mean "External flashing"
There was a problem hiding this comment.
Probably this https://wiki.odroid.com/odroid-h4/hardware/restore_h4_bios#using_tool_and_soldering_skills and https://wiki.odroid.com/odroid-h3/hardware/restore_h3_bios_usbprogrammer#with_usb_programmer_module_ch341a.
Had to test this recovery and it worked (flashed only one SPI, second one recovered with flashrom -p internal)
There was a problem hiding this comment.
please link that section I guess you mean "External flashing"
Yes, the sections were renamed and I didn't update this sentence.
aa4abb3#diff-63d4fe5312d3d5c9d0e564e54adf0e43958113fb5d526eb698cd0ff31bd3dc79L19-L21
Do we want to give an URL to the instructions from wiki.odroid.com? If the point of this documentation is only to help the users maybe it would be better to only redirect them to the wiki instead of writing pretty much the same instructions again? I have added the URL to ODROID wiki instructions on flashing using the CH341A programmer as a second tab of the External Flashing section. a3a7f52
In that case maybe an URL to the dual-bios recovery method should also be referenced? The wiki tells how to do it on Windows and using the EFI shell, that might be useful to some users.
There was a problem hiding this comment.
If the point of this documentation is only to help the users maybe it would be better to only redirect them to the wiki instead of writing pretty much the same instructions again?
We can link only if instructions are followed without comment, adjustment, or modification. Otherwise, we should write our own, which does not require such additional information.
There was a problem hiding this comment.
The documentation on odroid wiki includes instructions on flashing from UEFI shell and Windows which weren't tested by us, so I can't tell if they would require any additional information. Some weird flashing software which you need to launch from a USB drive is used there. Flashing using flashrom is not described on the wiki, so it does not overlap with what we have in our documentation, it may be included as an additional source.
| with the path to the Dasharo image you want to flash, e.g. `hardkernel_odroid_h4_v0.9.0.rom`. | ||
|
|
||
| ```bash | ||
| sudo flashrom -p internal -w [path] --ifd -i bios |
There was a problem hiding this comment.
Are we sure particle flashing is what we should do for initial deployment? I have doubts because using partial flashing from AMI to Dasharo gave me no support for the network. Then partial flashing from Dasharo to Dasharo leads to serious bricking. The reset of CMOS + G3 helped, but I was pretty concerned when switching SPI to AMI, which didn't boot (it looks like a lack of CMOS reset). Let's make sure this section is robust.
There was a problem hiding this comment.
I have doubts because using partial flashing from AMI to Dasharo gave me no support for the network.
Any more details on it? iPXE has to be explicitly enabled in the setup.
Then partial flashing from Dasharo to Dasharo leads to serious bricking.
Happened to me as well, but also after AMI->Dasharo transition. This PR should fix the bricking: Dasharo/coreboot#569
There was a problem hiding this comment.
Any more details on it? iPXE has to be explicitly enabled in the setup.
After booting to DTS v2.0.0, I had no network interface. I cannot reproduce that now, but I should analyze it more deeply when testing over the next 1-2 days.
There was a problem hiding this comment.
It happened again while doing Dasharo->AMI transition:
bash-5.2# flashrom -p internal -w logs/rom.bin
flashrom v1.2-1037-g5b4a5b40 on Linux 6.6.21-yocto-standard (x86_64)
flashrom is free software, get the source code at https://flashrom.org
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
coreboot table found at 0x76933000.
Found chipset "Intel Alder Lake-N".
Enabling flash write... Warning: Setting BIOS Control at 0xdc from 0x8b to 0x89 failed.
New value is 0x8b.
SPI Configuration is locked down.
FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
FREG1: BIOS region (0x00600000-0x00ffffff) is read-write.
FREG2: Management Engine region (0x00001000-0x00413fff) is read-write.
PR0: Warning: 0x00b00000-0x00ffffff is read-only.
At least some flash regions are write protected. For write operations,
you should use a flash layout and include only writable regions. See
manpage for more details.
OK.
Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific) on internal.
Reading old flash chip contents... done.
Erasing and writing flash chip... Transaction error between offset 0x00b00000 and 0x00afffff (= 0x00b00000 + -1)!
Reading current flash chip contents... done. Looking for another erase function.
Looking for another erase function.
Looking for another erase function.
Looking for another erase function.
Looking for another erase function.
Looking for another erase function.
Looking for another erase function.
No usable erase functions left.
FAILED!
Uh oh. Erase/write failed. Checking if anything has changed.
Reading current flash chip contents... done.
Apparently at least some data has changed.
Your flash chip is in an unknown state.
Get help on IRC (see https://www.flashrom.org/Contact) or mail
[email protected] with the subject "FAILED: <your board name>"!-------------------------------------------------------------------------------
DO NOT REBOOT OR POWEROFF!This is my fault since I didn't remove all necessary locks before flashing, but the critical question is how to deal with such a situation correctly. PR0 range is weird, why it does not cover whole bios region?
There was a problem hiding this comment.
I guess one way to deal with the problem is to write Dasharo again, go to the setup menu, disable protection, and then do the recovery.
There was a problem hiding this comment.
During training, @mkopec also faced a similar issue with the lack of an Ethernet interface, it seem to be some problem with power cycles because after G3, things started to work correctly.
There was a problem hiding this comment.
We might say to perform a G3 an/or cmos reset if necessary. I am not sure what other changes I can suggest.
There was a problem hiding this comment.
This is my fault since I didn't remove all necessary locks before flashing, but the critical question is how to deal with such a situation correctly.
Platform should still be bootable
PR0 range is weird, why it does not cover whole bios region?
It covers the WP_RO region, Vboot's recovery. So theoretically it should boot from recovery (provided Dasharo works with AMI's ME blobs)
| the brick state using an [RTE](../../transparent-validation/rte/introduction.md) | ||
| and Dasharo open-source firmware. | ||
|
|
||
| ## Dual BIOS |
There was a problem hiding this comment.
This section could be improved based on my experience from recovery after bad initial deployment: https://github.com/Dasharo/docs/pull/903/files#r1788722185
There was a problem hiding this comment.
Although I'm not sure if this issue would arise when recovering. You had issues with the initial deployment of Dasharo flashing only the bios region. Here we are flashing the whole FW, so there shouldn't be any issues with ME or network interfaces being in some invalid state afterwards?
There was a problem hiding this comment.
I also had issues with flashing the whole firmware, especially on top of working proprietary BIOS.
philipandag
force-pushed
the
hardkernel-odroid-h4-plus-docs
branch
from
783fadb to
78c2068
Compare
Signed-off-by: Filip Gołaś <[email protected]>
Co-authored-by: Michał Żygowski <[email protected]>
Co-authored-by: Michał Żygowski <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
Signed-off-by: Filip Gołaś <[email protected]>
philipandag
force-pushed
the
hardkernel-odroid-h4-plus-docs
branch
from
45e632d to
782894f
Compare
philipandag
changed the title
Co-authored-by: Michał Żygowski <[email protected]>
No description provided.