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: Andre Przywara <andre.przywara@arm.com>
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: Andre Przywara <andre.przywara@arm.com>
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: Andre Przywara <andre.przywara@arm.com>
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: Andre Przywara <andre.przywara@arm.com>
Reported-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: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This header is not used since commit abdbefba2a ("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: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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: Andre Przywara <andre.przywara@arm.com>
Reviewed-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: Samuel Holland <samuel@sholland.org>
Acked-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: add F1C100s support]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
This allows all of the clock drivers to use a common bind function.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: add F1C100s support]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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: 0d47bc7056 ("clk: Add Allwinner A64 CLK driver")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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: Samuel Holland <samuel@sholland.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
[Andre: add F1C100s support]
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
- 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.
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 <trini@konsulko.com>
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 <trini@konsulko.com>
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 <trini@konsulko.com>
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 <trini@konsulko.com>
- 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 <trini@konsulko.com>
- 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 <trini@konsulko.com>
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 <trini@konsulko.com>
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 <trini@konsulko.com>
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 <trini@konsulko.com>
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: Tom Rini <trini@konsulko.com>
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>
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: Weijie Gao <weijie.gao@mediatek.com>
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: Weijie Gao <weijie.gao@mediatek.com>
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: Weijie Gao <weijie.gao@mediatek.com>
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: Weijie Gao <weijie.gao@mediatek.com>
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: Weijie Gao <weijie.gao@mediatek.com>
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: Weijie Gao <weijie.gao@mediatek.com>
The address returned by regmap_get_range() is not remapped. Directly r/w
to this address is ok for ARM platforms since it's idential to the virtual
address.
But for MIPS platform only virtual address should be used for access.
To solve this issue, the regmap api regmap_read/regmap_write should be used
since they will remap address before accessing.
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The iobase address from dts node is actually physical address. It's
identical to the virtual address in ARM platform. This is ok because this
driver was used only by ARM platforms (mt7622/mt7623 ...).
But now this driver will be used by mt7621 which is a MIPS SoC. For MIPS
platform the physical address space is mapped to KSEG0 and KSEG1 and this
makes the virtual address apparently not idential to its physical address.
To solve this issue, this patch replaces dev_read_addr with dev_remap_addr
to get the remapped iobase address.
Reviewed-by: Ramon Fried <rfried.dev@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch makes mt7621_wdt driver available for MediaTek MT7621 SoC
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch makes mt7621_gpio driver available for MediaTek MT7621 SoC
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch adds pinctrl support for MediaTek MT7621 SoC.
The MT7621 SoC supports pinconf, but it is not the same as mt7628.
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
This patch adds a clock driver for MediaTek MT7621 SoC.
This driver provides clock gate control as well as getting clock frequency
for CPU/SYS/XTAL and some peripherals.
Reviewed-by: Sean Anderson <seanga2@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The MT7621 requires external binary blob being executed during u-boot's
boot-up flow. It's necessary to provide a guide here for users to correctly
build the u-boot.
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
The mt7621_rfb board supports integrated giga PHYs plus one external
giga PHYs. It also has up to 512MiB DDR3, 16MB SPI-NOR, 3 mini PCI-e x1
slots, SDXC and USB.
The mt7621_nand_rfb board is almost the same as mt7621_rfb board, but it
uses NAND flash and SDXC is not available.
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
