Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- Since drivers/pwm/pwm-nexell.c is an adapted version of
s5p-common/pwm.c an appropriately changed version of s5p-common/pwm.c
is used instead. Therefore arch/arm/mach-s5pc1xx/include/mach/pwm.h
copied to arch/arm/mach-nexell/include/mach and s5p-common/Makefile
changed appropriately.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
possible (and similar).
Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- livetree API (dev_read_...) is used instead of fdt one (fdt...).
- doc/device-tree-bindings/pinctrl/nexell,s5pxx18-pinctrl.txt added.
Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- driver changed to DM.
- pinctrl-driver/dt is used now instead of configuring the mmc I/O-pins
in the mmc-driver.
- nexell_dwmmc_ofdata_to_platdata() reworked, i.e. valid default values
are used now (where possible) and the appropriate if-blocks have
been removed.
- new dt-property "mmcboost" is used now instead of "CONFIG_BOOST_MMC"
which was not defined anywhere.
Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- i2c/nx_i2c.c: Some adaptions mainly because of changes in
"struct udevice".
- several Bugfixes in nx_i2c.c.
- the driver has been for s5p6818 only. Code extended appropriately
in order s5p4418 is also working.
- "probe_chip" added.
- pinctrl-driver/dt is used instead of configuring the i2c I/O-pins
in the i2c-driver.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
possible (and similar).
- livetree API (dev_read_...) is used instead of fdt one (fdt...).
Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- livetree API (dev_read_...) is used instead of fdt one (fdt...).
Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
Changes in relation to FriendlyARM's U-Boot nanopi2-v2016.01:
- SPL not supported yet --> no spl-directory in arch/arm/mach-nexell.
Appropriate line in Makefile removed.
- clock.c: 'section(".data")' added to declaration of clk_periphs[] and
core_hz.
- Kconfig: Changes to have a structure like in mach-bcm283x/Kconfig,
e.g. "config ..." entries moved from other Kconfig.
- timer.c: 'section(".data")' added to declaration of timestamp and
lastdec.
- arch/arm/mach-nexell/serial.c removed because this is for the UARTs
of the S5P6818 SoC which is not supported yet. S5P4418 UARTs are
different, here the (existing) PL011-code is used.
- '#ifdef CONFIG...' changed to 'if (IS_ENABLED(CONFIG...))' where
possible (and similar).
Signed-off-by: Stefan Bosch <stefan_b@posteo.net>
Some instructions in the ARM ISA have multiple output registers, such
as ldrd/ldp (load pair), where two registers are loaded from memory,
but also ldr with indexing, where the memory base register is incremented
as well when the value is loaded to the destination register.
MMIO emulation under KVM is based on using the architecturally defined
syndrome information that is provided when an exception is taken to the
hypervisor. This syndrome information describes whether the instruction
that triggered the exception is a load or a store, what the faulting
address was, and which register was the destination register.
This syndrome information can only describe one destination register, and
when the trapping instruction is one with multiple outputs, KVM throws an
error like
kvm [615929]: Data abort outside memslots with no valid syndrome info
on the host and kills the QEMU process with the following error:
U-Boot 2020.07-rc3-00208-g88bd5b179360-dirty (Jun 06 2020 - 11:59:22 +0200)
DRAM: 1 GiB
Flash: error: kvm run failed Function not implemented
R00=00000001 R01=00000040 R02=7ee0ce20 R03=00000000
R04=7ffd9eec R05=00000004 R06=7ffda3f8 R07=00000055
R08=7ffd9eec R09=7ef0ded0 R10=7ee0ce20 R11=00000000
R12=00000004 R13=7ee0cdf8 R14=00000000 R15=7ff72d08
PSR=200001d3 --C- A svc32
QEMU: Terminated
This means that, in order to run U-Boot in QEMU under KVM, we need to
avoid such instructions when accessing emulated devices. For the flash
in particular, which is a hybrid between a ROM (backed by a read-only
KVM memslot) when in array mode, and an emulated MMIO device (when in
write mode), we need to take care to only use instructions that KVM can
deal with when they trap.
So override the flash read accessors that are used when running on QEMU
under KVM. Note that the the 64-bit wide read and write accessors have
been omitted: they are never used when running under QEMU given that it
does not emulate CFI flash that supports it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
The QEMU/mach-virt targeted port of u-boot currently only runs on
QEMU under TCG emulation, which does not model the caches at all,
and so no users can exist that are relying on the GRUB hack for
EFI boot.
We will shortly enable support for running under KVM, but the GRUB
hack (which disables all caches without doing cache cleaning by VA
during ExitBootServices()) is likely to cause more problems than it
solves, given that KVM hosts require correct maintenance if they
incorporate non-architected system caches.
So let's disable the GRUB hack by default on the QEMU/mach-virt
port.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Add an override for enable_caches to enable the I and D caches, along
with the cached 1:1 mapping of all of DRAM. This is needed for running
U-Boot under virtualization with QEMU/kvm.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
QEMU's mach-virt machine only supports selecting CPU models that
implement the virtualization extensions, and are therefore guaranteed
to support LPAE as well.
Initially, QEMU would not allow emulating these CPUs running in HYP
mode (or EL2, for AArch64), but today, it also contains a complete
implementation of the virtualization extensions themselves.
This means we could be running U-Boot in HYP mode, in which case the
LPAE long descriptor page table format is the only format that is
supported. If we are not running in HYP mode, we can use either.
So let's enable CONFIG_ARMV7_LPAE for qemu_arm_defconfig so that we
get the best support for running with the MMU and caches enabled at
any privilege level.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The LPAE versions of DCACHE_WRITEBACK and DCACHE_WRITETHROUGH are currently
defined as no-allocate for both reads and writes, which deviates from the
non-LPAE definition, and mostly defeats the purpose of enabling the caches
in the first place.
So align LPAE with !LPAE, and enable allocate-on-read for both. And while
at it, add some clarification about the meaning of the chosen values.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Snapdragon SoCs and IPQ40xx use common TLMM IP,
so existing driver supports IPQ40xx as well.
So lets simply add a compatible for IPQ40xx.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-By: Ramon Fried <rfried.dev@gmail.com>
IPQ40xx and currently supported Snapdragon boards don't use the same one
so enable reading it from DT, if no DT property is found default value
is the same as the previous define.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-By: Ramon Fried <rfried.dev@gmail.com>
This introduces initial support for the popular Qualcomm
IPQ40x8 and IPQ40x9 WiSoC series.
IPQ40xx series have 4x Cortex A7 ARM-v7A cores.
Supported are: IPQ4018, IPQ4019, IPQ4028 and IPQ4029.
IPQ40x8 and IPQ40x9 use the same cores, but differ in
addressable RAM size (1GB for IPQ40x9 and 256MB for IPQ40x8)
and supported peripherals (IPQ40x8 lacks RGMII, LCD controller
and EMMC/SDHCI controllers).
IQP4028/IPQ4029 models differ from IPQ4018/IPQ4019 only
by their rated temperatures rates with IPQ402X models being
rated for wider temperature ranges.
Initially this supports:
* Simple clock driver (Only for UART1 now, will be extended)
* Pinctrl driver (Supports UARTX and GPIO now, will be extended)
* GPIOs already supported by msm_gpio driver with updates
* UARTs already supported by serial_msm driver with updates
Further peripherals will come in later patches.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
The pins for the MMC controller weren't being set up correctly because the
pinctrl driver only sets the GPIO pullup/pulldown config and doesn't
handle the special cases with PUPD/R0/R1 control.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Tested-by: Frank Wunderlich <frank-w@public-files.de>
The sgmii mode init flow is almost the same for all mediatek SoC, the
only difference is the register offset(SGMSYS_GEN2_SPEED) is 0x2028
in the old chip(mt7622) but changed to 0x128 for the newer chip(mt7629
and the following chips).
Signed-off-by: MarkLee <Mark-MC.Lee@mediatek.com>
Enable the support of button (driver and command) on sandbox.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Enable the support of button (driver and command) on sandbox64.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Adds two buttons on sandbox so button framework may be tested.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Adds a command 'button' that provides the list of buttons
supported by the board, and the state of a button.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Add a simple driver which allows use of buttons attached to GPIOs.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Add a new uclass for button that implements two functions:
- button_get_by_label
- button_get_status
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Since commit 9ba84329dc ("sandbox, test: add test for GPIO_HOG
function"), the gpio_a 0,1,2 and 3 are used by hog in test.dts.
But 2 leds 'sandbox:red' and 'sandbox:green' are using gpio_a 0
and 1. As hog always request his gpios, the led command on both
led is broken:
=> led sandbox:red
LED 'sandbox:red' not found (err=-16)
The gpio is already requested by hog, so it can't be enabled
for led 'sandbox:red'.
This commit change the gpio used by hog to 10, 11, 12 and 13,
so the led command could be used again with 'sandbox:red' and
'sandbox:green'.
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
When trying to bind to a non-existent file the following output is
displayed:
=> host bind 0 non_existent
Failed to access host backing file 'non_existent'
exit not allowed from main input shell.
The last line is quite unexpected and due to an incorrect return value.
If do_host_bind() fails, return CMD_RET_FAILURE (= 1).
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
With OF_CONTROL disabled the build fails for
include/dm/read.h:932:10: error: ‘ENOTSUPP’ undeclared (first use in this function)
932 | return -ENOTSUPP;
Fixes: 45224e8f26 ("dm: core: gracefully handle alias seq without of")
Signed-off-by: Dan Murphy <dmurphy@ti.com>
After latest improvements in dtoc, compatible strings are checked
against driver and driver alias list to get a valid driver name. With
this new feature the list of compatible string aliases seems not
useful any more.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
After latest improvements on OF_PLATDATA struct names are generated
based on driver name instead of compatible strings. With this in mind,
using aliases in drivers are not longer needed.
This patch removes code that tried to handle these kind of aliases to
improve readability.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently dtoc checks if the first compatible string in a dtb node
matches either a driver o driver alias name, without taking into account
any other compatible string in the list. In the case that no driver matches
the first compatible string a warning is printed and the U_BOOT_DEVICE is
not being declared correctly.
This patch adds dtoc's support for try all the compatible strings in the
dtb node, in an effort to find the correct driver.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This patch is about bootm process, android boot image and device tree.
Android 10 updates the boot image header to version 2,
which includes a section to store the device tree blob (DTB) image.
include/android_image.h has updated the struct andr_img_hdr,
but not used in bootm process. This patch avoid reporting
"Device tree not found or missing FDT support"
when bootm a correctly constructed android boot image.
Signed-off-by: chenshuo <chenshuo@eswin.com>
At present there is not enough space for U-Boot due to the EFI loader.
Correct this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This board does not have microcode but at present that is not supported
by Kconfig nor the binman image layout. Fix both of these.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the image layout is not correct, since it uses the SDRAM
address of the 64-bit U-Boot as the ROM address. Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This causes conflicts on chromebook_link64. Move it to after U-Boot where
there should be plenty of space.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Now that all board use binman instead of this script, drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present this board uses a custom script to produce the .its file.
Update it to use binman instead. Binman can create all the images that
are needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this board uses a custom script to produce the .its file.
Update it to use binman instead. Binman can create all the images that
are needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
This option is used to run arch-specific shell scripts which produce .its
files which are used to produce FIT images. We already have binman which
is designed to produce firmware images. It is more powerful and has tests.
So this option should be deprecated and not used. Existing uses should be
migrated.
Mentions of this in code reviews over the last year or so do not seem to
have resulted in action, and things are getting worse.
So let's add a warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present we use the empty string to indicate that there is no FIT
generator, but this doesn't allow an individual board to undefine it.
Create a separate bool instead.
Update the config of the boards which currently have an empty string.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present this is checked before the config has been loaded by the
Makefile, so it doesn't work.
Move the check to later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
On mediatek various files that need to be created by binman. It does not
make sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Also update the binman definition so that idbloader.img is only needed
when SPL is actually being used.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
On tegra various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
On sunxi various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
