If neither CONFIG_SPL_FIT_SOURCE nor CONFIG_USE_SPL_FIT_GENERATOR is
enabled, U_BOOT_ITS will be undefined, and attempting to make u-boot.itb
will pass invalid arguments to mkimage, causing it to print its help
message.
Remove the rule in that case, so it is more obvious that u-boot.itb is
not something that can be made. This will reduce confusion as platforms
move away from CONFIG_USE_SPL_FIT_GENERATOR, as u-boot.itb was
previously a valid goal for those platforms.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Previously, because we have no source code about the DRAM initialization
of V3s and missing some configurations (delays and MBUS QoS info), our
V3s DRAM initialization sequence is hacked from the H3 one.
As the SDK shipped with PineCube contains source code for V3s libdram,
we can retrieve these information from it and tweak some other magic
bits.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jagan Teki <jagan@amarulasolutions.com>
The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
additional drivers marked as DM_FLAG_PRE_RELOC are loaded before
relocation.
CONFIG_RSA=y which is needed for UEFI secure boot or for FIT image
verification loads the driver mod_exp_sw which has DM_FLAG_PRE_RELOC.
CONFIG_LOG=Y is another setting requiring additional early malloc
area, cf. log_init().
When running pine64-lts_defconfig with CONFIG_RSA=y and debug UART enabled
we see as output in main U-Boot
alloc_simple() alloc space exhausted
With this patch the default values of SYS_MALLOC_F_LEN and
SPL_SYS_MALLOC_F_LEN on ARCH_SUNXI are raised to 0x2000.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Update email address of Maxime Ripard in git-mailrc to match more
recently updated entry in MAINTAINERS.
commit 9bd9b2bcbe ("MAINTAINERS: Update my email address")
commit bf8f4c4400 ("MAINTAINERS: Update email address for Maxime Ripard")
Signed-off-by: Jonas Smedegaard <dr@jones.dk>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
According to the devicetree and the schematic, the 3.3V power rail for
the PHY is enabled by GPIO PC16. It's wired as active-high, with a
pull-up resistor, so actually works already when the GPIO is in
High-Z state.
However we should not take any chances and explicitly set the GPIO pin
to high, to avoid accidentally losing the PHY power.
The existing MACPWR Kconfig allows to do this easily.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
When sending a command via the MDIO bus, the Designware MAC expects some
bits in the CMD register to describe the clock divider value between
the main clock and the MDIO clock.
So far we were omitting these bits, resulting in setting "00", which
means "/ 16", so ending up with an MDIO frequency of either 18.75 or
12.5 MHz.
All the internal PHYs in the H3/H5/H6 SoCs as well as the Gbit Realtek
PHYs seem to be fine with that - although it looks like to be severly
overclocked (the MDIO spec limits the frequency to 2.5 MHz).
However the external 100Mbit PHY on the Pine64 (non-plus) board is
not happy with that, Ethernet was actually never working there, as the
PHY didn't probe.
As we set the EMAC clock (via AHB2) to 300 MHz in ATF (on the 64-bit
SoCs), and use 200 MHz on the H3, we need the highest divider of 128
to let the MDIO clock end up below the required 2.5 MHz.
This enables Ethernet on the Pine64(non-plus).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The current implementation of sun8i_get_ephy_nodes() makes quite some
assumptions, in general relying on DT path names is a bad idea.
I think the idea of the code was to determine if we are using the
internal PHY, for which there are simpler and more robust methods:
Rewrite (and rename) the existing function to simply lookup the DT node
that "phy-handle" points to, using the device's DT node.
Then check whether the parent of that PHY node is using an "H3 internal
MDIO" compatible string. If we ever get another internal MDIO bus
implementation, we will probably need code adjustments anyway, so this
is good enough for now.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
[jagan: rebase on master]
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The error handling in recv() is somewhat broken, for instance
good_packet isn't really used, and it's hardly readable. Also we try
to check for short or too big packets, but those are actually filtered
out by the hardware.
Simplify the whole routine and improve the error handling:
- Bail out early if the current RX descriptor is not ready.
- Enable propagation of runt, huge and broken packets.
- Check for runt and huge packets, and return 0 to indicate this.
This will force the framework to call free_pkt for cleanup.
- Avoid aligning the packet buffer for invalidation again.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The EMAC soft reset routine was subtly broken, using an open coded
timeout routine without any actual delay.
Remove the unneeded initial reset bit read, and call wait_for_bit_le32()
to handle the timeout correctly.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
When iterating over all RX/TX buffers, we were using a rather long "idx"
control variable, which lead to a nasty overlong line.
Replace "idx" with "i" to avoid this.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
To meet the current alignment requirements for our cache maintenance
functions, we were explicitly aligning the *arguments* to those calls.
This is not only ugly to read, but also wrong, as we need to make sure
we are not accidentally stepping on other data.
Provide wrapper functions for the common case of cleaning or
invalidating a descriptor, to make the cache maintenance calls more
readable. This fixes a good deal of the problematic calls.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
There is no reason to invalidate a TX descriptor before we are setting
it up, as we will only write to a field.
Remove the not needed invalidate_dcache_range() call.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
When we initialise the TX descriptors, there is no need yet to clean
them all to memory, as they don't contain any data yet. Later we will
touch and clean each descriptor anyway.
However we tell the MAC about the beginning of the chain, so we have to
clean at least the first descriptor, to make it clear that this is empty
and there are no packets to transfer yet.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Before we initialise the RX descriptors, there is no need to *clean*
them from the cache, as we touch them for the first time.
However we should cover the case that those buffers contain dirty cache
lines, which could be evicted and written back to DRAM any time later,
in the worst case *after* the MAC has transferred a packet into them.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
The EMAC driver contains a lot of magic bits, although the manuals
and the Linux driver have all names for them.
Define those names and use them when programming the registers.
Also this replaces a lot of readl/mask/writel operations with the much
easier-to-read setbits_le32() macro.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Apparently due to copying from some older or converted driver, the
sun8i_emac driver contains pointless wrapper functions to bridge
between a legacy driver and the driver model.
Since sun8i_emac is (and always was) driver model only, there is no
reason to have those confusing wrappers. Just remove them, and use
the driver model prototypes directly.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
When preparing the register value for the MDIO command register, we
start with a zeroed register, so there is no need to mask off certain
bits before setting them.
Simplify the sequence, and rename the variable to a more matching
mii_cmd on the way.
Also the open-coded time-out routine can be replaced with a much safer
and easier-to-read call to wait_for_bit_le32().
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
When initialising the TX DMA descriptors, we mostly chain them up,
but of course don't know about any data or its length yet.
That means they are still invalid, and the OWN bit should NOT be set
yet.
In fact when we later tell the MAC about the beginning of the chain,
and enable TX DMA in the start() routine, the MAC will start fetching
TX descriptors prematurely, as it can be seen by dumping the TX_DMA_STA
and TX_DMA_CUR_DESC registers.
Clear the owner bit, to not give the MAC the wrong illusion that it
owns the descriptors already.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
When phy_startup() returns with an error, because there is no link or
the user interrupted the process, we shall stop the _start() routine
and return with an error, instead of proceeding anyway.
This fixes pointless operations when there is no Ethernet cable
connected, for instance.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Tested-by: Amit Singh Tomar <amittomer25@gmail.com> # Pine64+
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
-----BEGIN PGP SIGNATURE-----
iQFQBAABCgA6FiEEqxhEmNJ6d7ZdeFLIHrMeAg6sL8gFAl+NMmQcHGV1Z2VuLmhy
aXN0ZXZAbWljcm9jaGlwLmNvbQAKCRAesx4CDqwvyLnEB/0cWFfjDfCMY1o7R4QX
DeDRlD6k6acQWlwa5EiRKwpbPMJKrSI/m5alMCYZG6YHvGtzihqnqohz3gl1sepi
W7eyyyFsM4hqe4P3lSETJRGWe/O8bNkoa0hBzqZ9btqw2OJLBu4JYB+zKgz8kaDY
jzkGLgaaK6wtG3rEu+q4fjzp1y9kuz31WnN+9qS8jd/9UH13XKCkJl9TfY5pLfgc
mmbn2NWtAhi91uShcnIsOpLaNm23IV0ITa22etB9F1docZuUrbhOtiIF45AADjpG
/xtkV3dEVGml3N/17RizgOwxX3xughG0ak9xifsK6tfgqfVhaGMgkToNNBM+1ddm
rZZM
=hF12
-----END PGP SIGNATURE-----
Merge tag 'u-boot-atmel-2021.01-b' of https://gitlab.denx.de/u-boot/custodians/u-boot-atmel
Second set of u-boot-atmel features for 2021.01 cycle:
This feature set brings the rework of the clock tree for sam9x60 SoC.
This makes the clock tree fully compatible with Common Clock Framework
and allows full clock configuration in U-Boot. This means that the
sam9x60 boards can boot now using U-Boot.
This also includes the definitions for sam9x60 SiPs and a divisor fix
for the clock on sama7g5 SoC.
This SoC has the 5th divisor for the mck0 master clock.
Adapt the characteristics accordingly.
Reported-by: Mihai Sain <mihai.sain@microchip.com>
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
clk-master can have 5 divisors with a field width of 3 bits
on some products.
Change the mask and number of divisors accordingly.
Reported-by: Mihai Sain <mihai.sain@microchip.com>
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Use slow clock CCF compatible DT bindings. This will not break
the above functionality as the SoC is not booting with current
PMC bindings.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Heap base address is computed based on SYS_INIT_SP_ADDR by
subtracting the SYS_MALLOC_F_LEN value in
board_init_f_init_reserve().
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Done with:
./tools/moveconfig.py VIDEO_BMP_GZIP
The 3 suspicious migration because CMD_BMP and SPLASH_SCREEN
are not activated in these defconfigs:
- trats_defconfig
- s5pc210_universal_defconfig
- trats2_defconfig
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For levels equal to the maximum value, the duty cycle must be equal to
the period.
Signed-off-by: Dario Binacchi <dariobin@libero.it>
Reviewed-by: Simon Glass <sjg@chromium.org>
The Amlogic D-PHY in the Amlogic AXG SoC Family does support a frequency
higher than 10MHz for the TX Escape Clock, thus make the target rate
configurable.
This is based on the Linux commit [1] and adapted to the U-Boot driver.
[1] a328ca7e4af3 ("drm/bridge: dw-mipi-dsi: permit configuring the escape clock rate")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
The timing values for dw-dsi are often dependent on the used display and
according to Philippe Cornu will most likely also depend on the used phy
technology in the soc-specific implementation.
To solve this and allow specific implementations to define them as needed
add a new get_timing callback to phy_ops and call this from the dphy_timing
function to retrieve the necessary values for the specific mode.
This is based on the Linux commit [1] and adapted to the U-Boot driver.
[1] 25ed8aeb9c39 ("drm/bridge/synopsys: dsi: driver-specific configuration of phy timings")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
syslog_test.h is in test/log/, not include/
Fixes: 52d3df7fef ("log: Allow LOG_DEBUG to always enable log output")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Now that linux/compat.h does not define these macros, we do not need to
undefine them.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
All users of these functions now include dm/device_compat.h directly.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This driver doesn't use DM (in the correct places), so we use a device and
not a udevice. We also need to include device_compat.h
Signed-off-by: Sean Anderson <seanga2@gmail.com>
