- Jul 18, 2022
-
-
The sunxi nand SPL loader was broken at least for SUN4I, SUN5I and SUN7I SOCs since the implementation change from DMA to PIO usage - commit 6ddbb1e9. Root cause for this issue is the NFC control flag NFC_CTL_RAM_METHOD being set by method nand_apply_config. This flag controls the bus being used for the NFCs internal RAM access. It must be set for the DMA use case only. See A33_Nand_Flash_Controller_Specification.pdf page 12. This fix is tested by myself on a Cubietruck A20 board. Others should test it on new generation SOCs as well. Signed-off-by:
Markus Hoffrogge <mhoffrogge@gmail.com> Reviewed-by:
Andre Przywara <andre.przywara@arm.com> Signed-off-by:
-
The boards that come with a flash memory pre-soldered have a Macronix flash chip. Fixes: 280294c5 ("sunxi: boards: Enable SPI flash support in U-Boot proper") Signed-off-by:
Michal Suchanek <msuchanek@suse.de> Reviewed-by:
-
KConfig has range option, use it instead of notice in the option descrition. Signed-off-by:
-
André Przywara authored
Many LicheePi Nano boards come with SPI flash soldered, which already works for booting the SPL and loading U-Boot proper. With the updated DTB, we can now also use the SPI flash from U-Boot proper, so enable the bits in the defconfig, to allow loading binaries from SPI flash. There seem to be board revisions with a Winbond SPI chip, but also others with an XTX chip, so include support for both: the actual chip used will be autodetected. Signed-off-by: -
André Przywara authored
The SPI controllers in the Allwinner F1Cx00 series of SoCs are compatible to the H3 IP. The only difference in the integration is the missing mod clock in the F1C100, instead the SPI clock is directly derived from the AHB clock. We *should* be able to model this through the DT, but the addition of get_rate() requires quite some refactoring, so it's not really worth in this simple case: We programmed both the PLL_PERIPH to 600 MHz and the PLL/AHB divider to 3 in the SPL, so we know the SPI base clock is 200 MHz. Since we used a hard coded fixed clock rate of 24 MHz for all the other SoCs so far, we can as well do the same for the F1C100. Define the SPI input clock and maximum frequency differently when compiling for the F1C100 SoC. Also adjust the power-of-2 divider programming, because that uses a "minus one" encoding, compared to the other SoCs. This allows to enable SPI flash support for the F1C100 boards. Signed-off-by: -
André Przywara authored
The current SPI clock divider calculation has two problems: - We use a normal round-down division, which results in a divider typically being too small, resulting in a too high frequency on the bus. - The calculaction for the power-of-two divider is very inaccurate, and again rounds down, which might lead to wild bus frequencies. This wasn't a real problem so far, since most chips can handle slightly higher bus frequencies just fine. Also the actual speed was mostly lost anyway, due to release_bus() reseting the device. And the power-of-2 calculation was probably never used, because it only applies to frequencies below 47 KHz. However this will become a problem for the F1C100s support, due to its much higher base frequency. Calculate a safe divider correctly (using round-up), and re-use that value when calculating the power-of-2 value. We also separate the maximum frequency and the input clock on the way, since they will be different for the F1C100s. Signed-off-by: -
André Przywara authored
As George rightfully pointed out [1], the spi-sunxi driver programs the speed and mode settings only when the respective functions are called, but this gets lost over a call to release_bus(). That asserts the reset line, thus forces each SPI register back to its default value. Adding to that, trying to program SPI_CCR and SPI_TCR might be pointless in the first place, when the reset line is still asserted (before claim_bus()), so those setting won't apply most of the time. In reality I see two nested claim_bus() calls for the first use, so settings between the two would work (for instance for the initial "sf probe"). However later on the speed setting is not programmed into the hardware anymore. So far we get away with that default frequency, because that is a rather tame 24 MHz, which most SPI flash chips can handle just fine. Move the actual register programming into a separate function, and use .set_speed and .set_mode just to set the variables in our priv structure. Then we only call this new function in claim_bus(), when we are sure that register accesses actually work and are preserved. [1] https://lore.kernel.org/u-boot/20210725231636.879913-17-me@yifangu.com/ Signed-off-by:
George Hilliard <thirtythreeforty@gmail.com>
-
The current detection of RX FIFO depth seems to be not reliable, and XCH will self-clear when a transfer is done. Check XCH bit when polling for transfer finish. Signed-off-by:
Icenowy Zheng <uwu@icenowy.me> Reviewed-by:
-
This header is not used since commit abdbefba ("net: sun8i_emac: Use consistent clock bitfield definitions"). Dropping it allows the driver to be architecture-independent. Signed-off-by:
Samuel Holland <samuel@sholland.org> Reviewed-by:
-
This just prints the PHY mode taken from the devicetree. It does not need to be printed during every boot, and also avoids an unwanted line break for the "net: " reporting line. Signed-off-by:
-
André Przywara authored
For mostly historic reasons we had configuration headers for each Allwinner CPU "family". These days they are mostly just including one common header, with the rest being somewhat empty. There were attempts to remove them, and to just use the one common header to begin with, but this has implications to the build system, which me might not be ready for, yet. To document this behaviour, and to avoid something sneaking in over time, make those files all the same (minus the CPU family name and the copyrights), and add a comment explaining that. This makes it easier to just remove those files later on, when needed and possible. Signed-off-by:
Tom Rini <trini@konsulko.com>
-
The clock and reset drivers use the exact same platform data. Simplify them by sharing the object. This is safe because the parent device (the clock device) always gets its driver model callbacks run first. Signed-off-by:
-
The reason here is the same as the reason for changing the clock driver: platform data can be provided when binding the driver. Signed-off-by:
-
All of the driver private data should really be platform data since it is determined statically (selected by the compatible string or extracted from the devicetree). Move everything to platform data, so it can be provided when binding the driver. This is useful for SPL, or for instantiating the driver as part of an MFD. Signed-off-by:
-
Now that all of the variants use the same bind/probe functions and ops, there is no need to have a separate driver for each variant. Since most SoCs contain two variants (the main CCU and PRCM CCU), this saves a bit of firmware size and RAM. Signed-off-by:
-
This allows all of the clock drivers to use a common bind function. Signed-off-by:
-
Because the gate arrays are not given explicit sizes, the arrays are only as large as the highest-numbered gate described in the driver. However, only a subset of the CCU clocks are needed by U-Boot. So there are valid clock specifiers with indexes greater than the size of the arrays. Referencing any of these clocks causes out-of-bounds access. Fix this by checking the identifier against the size of the array. Fixes: 0d47bc70 ("clk: Add Allwinner A64 CLK driver") Signed-off-by:
-
The reset array size is currently used for bounds checking in the reset driver. The same bounds check should really be done in the clock driver. Currently, the array size is provided to the reset driver separately from the CCU descriptor, which is a bit strange. Let's do this the usual way, with the array sizes next to the arrays themselves. Signed-off-by:
-
- Jul 14, 2022
-
-
Tom Rini authored
- Merge the majority of the relevant wiki content to doc/process/ and convert to Sphinx. Begin cleaning up and modernizing the content as well to match current process. There is still more work to be done in this regard.
-
Tom Rini authored
The wiki had gitdm-generated release statistics starting with v1.3.0. Re-generate this information as Sphinx. This aims to be as historically accurate as possible and so some company renames were kept to their old rather than current name until we had made the switch previously. Signed-off-by: -
Tom Rini authored
For quite a long time we've been using a 3 week, rather than 2 week, merge window as it was only 2 weeks during the timeframe where we did 2 month rather than 3 month releases. This corrects the places that still had 2 weeks and tries to make things a bit clearer overall. Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
Tom Rini authored
Migrate the RelaseCycle wiki page to Sphinx. In terms of visible changes, we stop having a dynamic countdown to when the release is. And we drop the year-based statistics, that were not being kept up to date. For the moment, we only link to statistics for v2022.07 but will add back the historical data in a subsequent patch. Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
Tom Rini authored
The "Workflow of a Custodian" section on the wiki had not been changed in quite some time to reflect how the process has been functioning for some time. First, update some links to point to modern and current sources of information. Second, and more overarching, reword much of the section. This expands on the expectations of both custodians and developers when it comes to rebasing patches. Rework the final points to be clearer that Custodians are expected to do their best to test the changes and ask for help when needed, as well as that pull requests are expected in a timely manner. Cc: Claudius Heine <ch@denx.de> Cc: Martin Bonner <martingreybeard@gmail.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
Tom Rini authored
- Use gender-neutral language to refer to the user, consistently. - Reword a few places so that they read more naturally. - Make the long standing practice around "Twilight Time" more clear, hopefully. - Replace a reference to MAKEALL with a reference to CI testing as that's the current requirement. Cc: Claudius Heine <ch@denx.de> Cc: Martin Bonner <martingreybeard@gmail.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
Tom Rini authored
- Remove some missed wiki markup, and escape a "\n" correctly. - Use gender-neutral language to refer to the user, consistently. Cc: Claudius Heine <ch@denx.de> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
Tom Rini authored
Move the current Process wiki page to doc/develop/process.rst. The changes here are for formatting or slight rewording so that it reads well when linking to other Sphinx documents. Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
Tom Rini authored
For some time now we've allowed for '//' style comments, which mirrors the Linux kernel. So drop this point here. Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
Tom Rini authored
Move the current DesignPrinciples wiki page to doc/develop/designprinciples.rst. The changes here are for formatting or slight rewording so that it reads well when linking to other Sphinx documents. Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
Tom Rini authored
Move the current CodingStyle wiki page to doc/develop/codingstyle.rst. The changes here are for formatting or slight rewording so that it reads well when linking to other Sphinx documents. Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: -
-
board_usb_init() should receive the controller_index as its first parameter instead of having it hardcoded as 0. All in-tree users have CONFIG_SPL_SDP_USB_DEV as 0, so this error should not affect any board. Fix it by passing controller_index as the parameter of board_usb_init(). Signed-off-by:
Fabio Estevam <festevam@denx.de> Acked-by:
Peng Fan <peng.fan@nxp.com>
-
https://source.denx.de/u-boot/custodians/u-boot-mipsTom Rini authored
- MIPS: add drivers and board support for Mediatek MT7621 SoC
-
https://source.denx.de/u-boot/custodians/u-boot-efiTom Rini authored
Pull request for efi-2022-10-rc1 Documentation: * rework the mkimage.1 man-page * add a statistics page for v2022.07 * update environment description UEFI: * add Ilias Apalodimas as co-maintainer * fix a memory leak in efi_set_bootdev() * suppress a build warning
-
- Jul 13, 2022
-
-
Update maintainer for MediaTek MIPS platform Signed-off-by:Weijie Gao <weijie.gao@mediatek.com>
-
The BootROM of MT7621 requires a image header for SPL to record its size and load address when booting from NAND. To create such an image, one can use the following command line: mkimage -T mtk_image -a 0x80200000 -e 0x80200000 -n "mt7621=1" -d u-boot-spl-ddr.bin u-boot-spl-ddr.img Reviewed-by:
Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: -
Add support to load legacy image with payload compressed. This redirects the boot flow for all legacy images. If the payload is not compressed, the actual behavior will remain unchanged. Reviewed-by:
Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: -
If the payload is compressed, SPL_COPY_PAYLOAD_ONLY should always be set since the payload will not be directly read to its load address. The payload will first be read to a temporary buffer, and then be decompressed to its load address, without image header. If the payload is not compressed, and SPL_COPY_PAYLOAD_ONLY is set, image header should be skipped on loading. Otherwise image header should also be read to its load address. Reviewed-by:
Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: -
This patch removes the dependency to SPL_NAND_DRIVERS for SPL_NAND_BASE to allow minimal spl nand driver to use nand base for probing NAND chips. Signed-off-by: -
This patch adds NAND flash controller driver for MediaTek MT7621 SoC. The NAND flash controller of MT7621 supports only SLC NAND flashes. It supports 4~12 bits correction with maximum 4KB page size. Signed-off-by: -
This patch adds GMAC support for MediaTek MT7621 SoC. MT7621 has the same GMAC/Switch configuration as MT7623. Reviewed-by:
Ramon Fried <rfried.dev@gmail.com> Signed-off-by:
-
