Updated f1c100s code from linux-sunxi #2
Conversation
This file contains 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
As per the wiki[1] set ttbr0 to 0x44000 to enable the MMU. Transfer speed is increased from 191KB/s to ~800KB/s which is handy when transferring larger kernels and root filesystems. Tested on a custom H8/A83T board. [1] https://linux-sunxi.org/FEL/USBBoot
The watchdog register isn't in the same place, nor uses the same values to trigger a reset. Signed-off-by: Karl Palsson <karlp@tweak.net.au>
The watchdog register isn't in the same place, nor uses the same values to trigger a reset. Signed-off-by: Karl Palsson <karlp@tweak.net.au>
Signed-off-by: Priit Laes <plaes@plaes.org>
Provide a wrapper for reset via watchdog Tested-By: Priit Laes plaes@plaes.org # On A20 with custom patch
A20 wdreset support
Add support for reading A10 SPI flash
The Allwinner V3s SoC have the same SPI0 pinmux configuration, SPI clock configuration and SPI controller (base address and the controller) with H3. Add spiflash support for it. Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Add the JEDEC manufacturer ID for Eon to the list of recognized vendors, also add the EN25QH series to the list of supported chips. Those chips are used on some internal boards with V831 from Sipeed now, but the chips themselves are widely available on the market. Tag the struct definition with the member names on the way to improve readability of the SPI flash chip description. Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
spi: add support for V3s SoC
fel: SPI: add Eon support
fel: enable A83T MMU
The non-IRQ stack is moved to near the end of the SRAM C, which is very high, and have no need to save. Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
V831 SoC is one of sun8i family (with Cortex-A7 CPUs), and it follows a similar memory map with H6. Add support for it. The detection for H6-style memory map is positive on V831, because it have the same version of GIC at the same address. Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
The Allwinner V831 SoC has similar memory map and CCU with H6. Add support for it by make the code to dynamically acquire the SPI0 memory base and add clock setup for V831. These code should work on H6 too, but I am too lazy to test it. Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
V831 SoC support
Add support for H616
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
Resolve typo for GPIO base address for SoCs other than V831. Signed-off-by: Nazım Gediz Aydındoğmuş <gedizaydindogmus@gmail.com>
spi: fix GPIO base address
The "wdreset" command so far only covered a few SoCs. Add the watchdog data for the other ones as well. Signed-off-by: Andre Przywara <osp@andrep.de>
The R40 is closely related to the A20, but has in fact a newer generation SPI controller. Add the R40 SoC ID to the right places to enable SPI support. Tested on a Bananapi M2 Berry with SPI flash attached to header pins. Signed-off-by: Andre Przywara <osp@andrep.de>
As Icenowy rightfully assumed, the V831 SPI support covers the H6 as well. The only difference was a slight deviation in the pinmux setup: the H6 has the SPI0-CS on pin PC5, the V831 on pin PC1. Just add the right SoC ID and tweak the pinmux setup to enable it. Tested on a Pine H64. Signed-off-by: Andre Przywara <osp@andrep.de>
Shifting signed types to the left is dodgy, especially by 31 bits, since it depends on the result type whether the result is undefined or not. Do not take any chances here, and mark those shift bases as unsigned where we can or will hit bit 31, to avoid undefined behaviour. Signed-off-by: Andre Przywara <osp@andrep.de>
The CCU section in all Allwinner manuals asks to de-assert the reset signal first, then to ungate the bus clock. On a nearby note it also requires to switch dividers before changing the clock source. The SPI flash code violated those two rules, fix this to make the code more robust. Signed-off-by: Andre Przywara <osp@andrep.de>
meminfo: Replace sys/io.h by direct register accesses.
Enabling SPI flash support for H6 & R40 (+ fixes)
wdreset: Add remaining SoCs
The H616 SPI is very similar to the H6, only differs in the GPIOs (again). Add the SoC-ID at the right places and add the GPIOs according to the manual. Tested on OrangePi Zero 2. Signed-off-by: Andre Przywara <osp@andrep.de>
spi: Add H616 support
Currently we check the U-Boot (legacy!) image header checksum very early and bail out with an error message if it does not match. Move that check later into the function, *after* we have established that we are actually dealing with such an U-Boot image. This avoids confusing error messages in case there is no U-Boot image used at all. Signed-off-by: Andre Przywara <osp@andrep.de>
We have a check to avoid that the SPL accidentally overwrites the thunk buffer we use to execute code on the board. Unfortunately this compares the SPL *size* against the thunk *address*, which is only valid when the SPL starts at 0 (older 32-bit SoCs). Factor in the SoC dependent SPL start address, to make this check work properly on newer (64-bit) SoCs. Signed-off-by: Andre Przywara <osp@andrep.de>
At the moment we always use a 32KB offset to place the U-Boot image after the SPL. Newer SoCs can (and will) have bigger SPLs, so we need to become more flexible with this offset. Read the actual SPL size, and assume the U-Boot payload is located right behind the SPL, if the SPL size is bigger than 32KB. We use at least 32KB, because this is how U-Boot is doing it today, even when the SPL size is actually smaller than that. Signed-off-by: Andre Przywara <osp@andrep.de>
At the moment we assume the SPL load size to be limited to 32KB, even though many SoCs have more SRAM A1 or a large SRAM C directly after SRAM A1. To later allow to extend the SPL load size, let's introduce a SoC specific variable to hold the SRAM size after the SPL load address. This could either cover the whole of SRAM A1, or even SRAM C, if that is contiguous to SRAM A1. Eventually this variable is meant to hold the *usable* SRAM size, so not including regions that are used by the BROM code. However this value is very SoC specific and not documented, and the SPL size is limited by the thunk and stack buffers anyway at the moment, so the values used here right now are just taken from the respective manuals. Signed-off-by: Andre Przywara <osp@andrep.de>
At the moment we limit the maximum SPL load size to 32 KB, because this was a BROM limit in previous SoCs. Newer SoCs (H6 and later) lift this limit, but also this tool is not bound by the BROM limit, since we can load any size. Use the just introduced SRAM size to establish an upper limit for the SPL size, then limit this as we go if any part of the memory is used for the FEL backup buffers. Given the buffer addresses chosen wisely, this can drastically increase the maximum SPL load size, even on those SoCs with a 32KB BROM limit. Signed-off-by: Andre Przywara <osp@andrep.de>
The H616 has quite a large chunk of continuous SRAM, and also the BROM allows to load eGON images far bigger than 32KB. U-Boot's SPL is actually relying on this, as we need more code for the PMIC and DRAM driver. Move the FEL stack backup buffers and the thunk address towards the end of SRAM C, so that we have a larger chunk of continuous SRAM available for the SPL. Signed-off-by: Andre Przywara <osp@andrep.de>
The H6 has quite a large chunk of continuous SRAM, and also the BROM allows to load eGON images far bigger than 32KB. Move the FEL stack backup buffers and the thunk address towards the end of SRAM C, so that we have a larger chunk of continuous SRAM available for the SPL. Signed-off-by: Andre Przywara <osp@andrep.de>
The A64 and H5 have a rather generous SRAM C directly adjacent to SRAM A1, so we can make use of the larger continuous SRAM area to increase the maximum SPL size. Move the location of the FEL stack backup buffer up, towards the end of SRAM C. We restrict ourselves to the slightly tighter requirements of the H5, to be able to still share the joint swap_buffers data structure. Signed-off-by: Andre Przywara <osp@andrep.de>
fel: Allow larger SPL payload
Our FEL code does not deal very well with the upload size being 0. Check for that before calling any USB routines, and skip the call entirely. Mark the buffer as "const" on the way, since we have no business other than reading from it. That helps to properly skip dummy images later. Signed-off-by: Andre Przywara <osp@andrep.de>
So far FEL was limited to 32-bit payloads only, but this will change. To accomodate 64-bit entry points, introduce a corresponding flag and use either the normal FEL execute call or the RMR request to kick off execution. Signed-off-by: Andre Przywara <osp@andrep.de>
A while ago the SPL header was extended to hold the name of the DTB file that shall be used for the board a firmware image is made for. Add some code to extract that name from the SPL header. This will be used in later patches to load the proper DTB file. Signed-off-by: Andre Przywara <osp@andrep.de>
In preparation for proper FIT image support, detect a FIT image by checking its first four byte against the DTB magic. Report this as not-yet-supported to the user, for now. Signed-off-by: Andre Przywara <osp@andrep.de>
So far sunxi-fel expects a legacy U-Boot image after the SPL, when called with the "uboot" command. This only works for (current) 32-bit builds, which only need one image to load (U-Boot proper). 64-bit builds also include at least a Trusted Firmware binary, and also might contain a firmware image for the ARISC management processor. So we use the more capable FIT image, which can contain multiple images to load. Introduce support for that, by adding code to parse a FIT image, find the image files included, and load them to their respective load addresses. On the way we keep track of the entry point, that only one of those images provides, and also note the architecture of this image (ARMv7 or AArch64). On top of that we detect which of the images is the actual U-Boot proper image, and append the chosen DTB to the end of it. This all mimics the code U-Boot's SPL uses to achieve the same goal when running from MMC or SPI flash, compare the implementation of spl_load_simple_fit() in U-Boot's common/spl/spl_fit.c: https://gitlab.denx.de/u-boot/u-boot/-/blob/master/common/spl/spl_fit.c This requires the libfdt library for parsing the FIT image (which is in fact a devicetree blob). Signed-off-by: Andre Przywara <osp@andrep.de>
sunxi-fel FIT image support
Allwinner R329 has no SRAM A1, but a huge SRAM A2 that is partly utilized as boot time SRAM. Add basical support for it. The spl subcommand is tested with modified uart0-helloworld-sdboot and extracted original boot0. Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
Allwinner R329 has some different base addresses. Fortunately the base addresses that our SoC detection code relies keep the same with H6, so its support can be added. Add support for it. Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
There are two more dependencies in addition to libusb and pkgconfig, which are libz and libfdt. Tell about them and give an example command to install the packages through apt. Signed-off-by: Nazım Gediz Aydındoğmuş <gedizaydindogmus@gmail.com>
README: Add more information about other requirements
R329 support
|
Nice, thank you! Let me get back in front of a computer and I'll review. |
|
Most of the changes are just fitting your changes into mainline (mismatched if-else, additional makefile dependencies, etc). The only major change is that mainline no longer uses the spi0_base variable for offsetting memory locations, but instead has a lookup function called It compiles fine for me on Windows Subsystem for Linux (Ubuntu 20.04), and on my Raspberry Pi. I was able to use it to flash a SPI memory chip in FEL mode, but I have not tested the other tools, as I am not really sure how to use them, and I don't have a F1C100s dev board, just a finished product with the F1C200s in it. |
|
@thirtythreeforty Any status on this? |
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.
I pulled in the changes from upstream and fixed merge conflicts. Now the f1c100s branch is up to date with the upstream and ready to be merged into the upstream.