Repository navigation
gk710x: publish U-Boot in CPU order, like every other file - #50
Merged
Merged
Conversation
The release U-Boot was in chip order -- every 32-bit word swapped, as the chip holds it -- so that a programmer could write it as it is, while OpenIPC/firmware's uImage and rootfs are in CPU order. A programmer image made by concatenating the three put U-Boot on the chip right and the kernel and rootfs unswapped, and the camera found no kernel (a GK7102C dump shows exactly that). One order for everything published: gk710x-image.py writes CPU order, which tftp, mmc and usb load and sf write or SD recovery put on flash as they are. A programmer or qemu flash-file image is the whole flash laid out from those files and then word-swapped as one, e.g. with objcopy --reverse-bytes=4 (the openipc branch's README shows how). gk_sflash.c no longer swaps on read: through the driver the flash reads as it was written, in CPU order. It still recognises a chip-order image written at 0 by its swapped magic and swaps it back, so a programmer image fed to sf write or SD recovery lands right as well. Under qemu-hisilicon: - gk7102: an 8 MiB programmer image built with dd + objcopy from the CPU-order U-Boot, uImage and rootfs boots to login, and the second boot loads the saved environment; - gk7102 and gk7102s (a GK7102C flash dump): with only U-Boot on the chip, SD recovery writes the CPU-order kernel and rootfs images; the flash then reads back byte for byte as the three files, both boots reach login, and on the second the U-Boot, kernel and rootfs images are all "already on the flash"; - gk7102: the programmer image itself, as an SD recovery image at 0, lands on the chip byte for byte (env and the jffs2 overlay aside, which the boot then writes) and boots.
PR Summary by Qodogk710x: Publish U-Boot in CPU byte order
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo
1.
|
![qodo-free-for-open-source-projects[bot]](https://avatars.githubusercontent.com/in/1068000?s=60&v=4){kind=small}
After a chip-order image was written at 0, the window stayed open for any later write below its end. A CPU-order sf update in the same session whose first sector was unchanged skipped it, so nothing at 0 closed the window, and its later changed sectors were written swapped. A write that does not start at 0 now keeps the window only if it starts where the previous write ended -- the pieces of one image, as sf update and SD recovery write them. Under qemu-hisilicon gk7102: chip-order sf write at 0, then a CPU-order sf update of a U-Boot differing at 0x20000, read back with the file's CRC (before: a different one); the same with a saveenv in between; and a chip-order sf update alone lands as the CPU-order file. A programmer image still boots to login twice. Reported by Qodo on #50.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every published file is now in CPU order (U-Boot, uImage, rootfs), so they all load by tftp/mmc/usb and go to flash with
sf writeor SD recovery as they are. The programmer image is the whole flash laid out from those files and word-swapped as one; the openipc-branch PR fromdocs/gk710x-cpu-orderadds the README recipe for it.Why: the U-Boot release was in chip order while kernel and rootfs were not, so concatenating them for a programmer put U-Boot on the chip right and the kernel and rootfs unswapped. A GK7102C dump shows exactly that: U-Boot and env fine,
27 05 19 56andhsqsraw at 0x50000/0x250000, and no kernel found.gk710x-image.pywrites CPU order.gk_sflash.cno longer swaps on read. It still recognises a chip-order image written at 0 and swaps it back, so a programmer image fed tosf writeor SD recovery lands right.Tested in qemu-hisilicon:
dd+objcopyboots to login twice, and the env survives.CI's smoke step already swaps a CPU-order image for qemu.