ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN to 2MB
I increased the maximum U-Boot proper size from time to time, but
configs/uniphier_v7_defconfig hit the current limit 832KB.
Some historical info:
In the initial support, the max size was 512MB.
Commit 58d702274c09 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN")
increased it to 576KB, and commit 3ce5b1a8d86d ("ARM: uniphier: move
SPL stack address") moved the SPL stack location to avoid the memory
map conflict. It was the solution to increase the size without changing
the NOR boot image map.
commit 1a4bd3a095b2 ("ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN
again") ended up with increasing the max size again, breaking the NOR
boot image map. The limit was set to 832KB, otherwise the SPL stack
would overwrite the U-Boot proper image:
CONFIG_SPL_STACK - CONFIG_SYS_UBOOT_BASE + sizeof(struct image_header) = 0xd0000
To increase CONFIG_SYS_MONITOR_LEN even more, the SPL stack must be
moved somewhere. I put it back to the original location prior to
commit 3ce5b1a8d86d.
With this change, there is no more practical size limit.
This weird workaround was the best I came up with at that time
to boot U-Boot from TF-A.
I noticed U-Boot successfully boots on LD20 (i.e. CA72 CPU) by using
the latest TF-A.
Specifically, since the following TF-A commit, U-Boot runs at EL2
instead of EL1, and this issue went away as a side-effect.
|commit f998a052fd94ea082833109f25b94ed5bfa24e8b
|Author: Masahiro Yamada <yamada.masahiro@socionext.com>
|Date: Thu Jul 25 10:57:38 2019 +0900
|
| uniphier: run BL33 at EL2
|
| All the SoCs in 64-bit UniPhier SoC family support EL2.
|
| Just hard-code MODE_EL2 instead of using el_implemented() helper.
|
| Change-Id: I7ab48002c5205bc8c013e1b46313b57d6c431db0
| Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
However, if I reverted that, this problem would come back, presumably
because some EL1 code in U-Boot triggers this issue.
Now that commit f8ddd8cbb513 ("arm64: issue ISB after updating system
registers") fixed this issue properly, this weird workaround is no
longer needed irrespective of the exception level at which U-Boot runs.
config: Enable support for the XHCI controller on RPI4 board
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)
Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
32bit mode, this region is mapped at 0xff800000 CPU virtual address.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Move ADDR_MAP related config options from include/configs/*.h to the
proper place in lib/Kconfig. This has been done using
./tools/moveconfig.py and manual inspection of the generated changes.
This is a preparation to use ADDR_MAP helper on ARM 32bit Raspberry Pi4
board for mapping the PCIe XHCI MMIO, which is above the 4GiB identity
mapping limit.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Tom Rini <trini@konsulko.com>
Some atypical users of xhci might need to manually reset their xHCI
controller before starting the HCD setup. Check if a reset controller
device is available to the PCI bus and trigger a reset.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[mb: squash fix to only build xhci_reset_hw() if CONFIG_DM_BUS] Signed-off-by: Matthias Brugger <mbrugger@suse.com>
reset: Add Raspberry Pi 4 firmware reset controller
Raspberry Pi 4's co-processor controls some of the board's HW
initialization process, but it's up to Linux to trigger it when
relevant. Introduce a reset controller capable of interfacing with
RPi4's co-processor that models these firmware initialization routines as
reset lines.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
arm: rpi: Add function to trigger VL805's firmware load
On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Marek Szyprowski [Mon, 25 May 2020 11:39:59 +0000 (13:39 +0200)]
configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit)
This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
and USB commands. To get it working one has to call the following commands:
"pci enum; usb start;", thus such commands have been added to the default
"preboot" environment variable. One has to update their environment if it
is already configured to get this feature working out of the box.
pci: Add driver for Broadcom BCM2711 SoC PCIe controller
This patch adds basic driver PCI Express controller found on Broadcom
set-top-box SoCs, e.g. BCM2711.
The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
handling removed. The inbound access memory region is not currently
parsed from dma-ranges DT property and a fixed 3GB region is used.
The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
USB Host Controller.
linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian
Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
an in depth explanation and two fixes from Johannes Berg: e7d4a95da86e0 "bitfield: fix *_encode_bits()", 37a3862e12382 "bitfield: add u8 helpers".
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
[s.nawrocki: added empty lines between functions and macros] Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
[mb: squash fix including byteorder.h] Signed-off-by: Matthias Brugger <mbrugger@suse.com>
- Add two- and three-argument versions of CONFIG_IS_ENABLED in
linux/kconfig.h
- Adds a new feature which supports copying modified parts of
the frame buffer to the uncached hardware buffer
- Enable the copy framebuffer on various x86 targets
Marek Szyprowski [Mon, 25 May 2020 11:39:55 +0000 (13:39 +0200)]
rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)
Create a non-cacheable mapping for the 0x600000000 physical memory region,
where MMIO registers for the PCIe XHCI controller are instantiated by the
PCIe bridge.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
pci: Move some PCIe register offset definitions to a common header
Some PCI Express register offsets are currently defined in multiple
drivers, move them to a common header to avoid re-definitions and
as a pre-requisite for adding new PCIe driver.
While at it replace some spaces with tabs.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq
There might be hardware configurations where 64-bit data accesses
to XHCI registers are not supported properly. This patch removes
the readq/writeq so always two 32-bit accesses are used to read/write
64-bit XHCI registers, similarly as it is done in Linux kernel.
This patch fixes operation of the XHCI controller on RPI4 Broadcom
BCM2711 SoC based board, where the VL805 USB XHCI controller is
connected to the PCIe Root Complex, which is attached to the system
through the SCB bridge.
Even though the architecture is 64-bit the PCIe BAR is 32-bit and likely
the 64-bit wide register accesses initiated by the CPU are not properly
translated to a sequence of 32-bit PCIe accesses.
xhci_readq(), for example, always returns same value in upper and lower
32-bits, e.g. 0xabcd1234abcd1234 instead of 0x00000000abcd1234.
usb: xhci: Add missing cache flush in the scratchpad array initialization
In current code there is no cache flush after initializing the scratchpad
buffer array with the scratchpad buffer pointers. This leads to a failure
of the "slot enable" command on the rpi4 board (Broadcom STB PCIe
controller + VL805 USB hub) - the very first TRB transfer on the command
ring fails and there is a timeout while waiting for the command completion
event. After adding the missing cache flush everything seems to be working
as expected.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
Tom Rini [Thu, 9 Jul 2020 12:22:44 +0000 (08:22 -0400)]
Merge tag 'for-v2020.10' of https://gitlab.denx.de/u-boot/custodians/u-boot-i2c
i2c changes for v2020.10
- Add support for I2C controllers found on Octeon II/III and Octeon TX
TX2 SoC platforms.
- Add I2C controller support for Cortina Access CAxxxx SoCs
- new rtc methods, rtc command, and tests
- imx_lpi2c: Improve the codes to use private data
- stm32f7_i2c.c: Add new compatible "st,stm32mp15-i2c"
- stm32f7_i2c.c: Add Fast Mode Plus support
- pwm: Add PWM driver for SiFive SoC
Simon Guinot [Sun, 28 Jun 2020 17:00:27 +0000 (19:00 +0200)]
arm: kirkwood: add DT spi0 alias to LaCie boards
The spi0 alias is needed by the environment code to retrieve the SPI
flash. This patch adds some -u-boot.dtsi files, providing the spi0
aliases, for all the following Kirkwood-based LaCie boards:
- d2 Network v2
- Internet Space v2
- 2Big Network v2
- Network Space v2
- Network Space Lite v2
- Network Space Max v2
- Network Space Mini v2
Note that this -u-boot.dtsi files will be removed as soon as the spi0
aliases will be available in the upstream Linux dtsi files.
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Dennis Gilmore [Sat, 27 Jun 2020 20:00:16 +0000 (15:00 -0500)]
arm: mvebu: helios4: sync helios4 config to clearfog and dts to kernel
The helios4 is built on the same microsom as the clearfog, by syncing the config
we enable the same featureset that exists in the som on the helios4. The current
config does not boot as some of the clearfog changes needed to be made on the
helios4 also, generally speaking most changes for the clearfog should also be
made on the helios4.
Signed-off-by: Dennis Gilmore <dennis@ausil.us> Reviewed-by: Stefan Roese <sr@denx.de>
Chris Packham [Thu, 25 Jun 2020 00:48:51 +0000 (12:48 +1200)]
arm: mvebu: a38x: Adjust UTMI PHY parameters
When running USB compliance tests on our Armada-385 hardware platforms
we have seen some eye mask violations. Marvell's internal documentation
says: Based on silicon test results, it is recommended to change the
impedance calibration threshold setting to 0x6 prior to calibration.
Port changes from Marvell's u-boot fork[1] to address this.
Chris Packham [Wed, 27 May 2020 01:31:29 +0000 (13:31 +1200)]
mv_ddr: ddr3: Use correct bitmask for read sample delay
In the Armada 385 functional spec (MV-S109094-00 Rev. C) the read sample
delay fields are 5 bits wide. Use the correct bitmask of 0x1f when
extracting the value.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
[upstream https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/22] Signed-off-by: Chris Packham <judge.packham@gmail.com> Reviewed-by: Stefan Roese <sr@denx.de>
Simon Glass [Wed, 8 Jul 2020 15:02:15 +0000 (09:02 -0600)]
x86: apl: Re-enable loading of SPL
At present the SPL loader is not included in the TPL image so SPL cannot
be loaded. Fix it by including this file for both SPL and TPL.
Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: c87f9ce2273 ("x86: Don't build some unused objects in TPL") Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
linux/kconfig.h: create two- and three-argument versions of CONFIG_IS_ENABLED
This adds a bunch of preprocessor magic to extend the capabilities of
CONFIG_IS_ENABLED. The existing semantics of
CONFIG_IS_ENABLED(FOO)
expanding to a 1 or 0 (depending on build context and the defined-ness
or not of the appropriate CONFIG_FOO/CONFIG_SPL_FOO/CONFIG_TPL_FOO)
are of course preserved. With this, one is also allowed a two-argument
form
CONFIG_IS_ENABLED(FOO, (something))
which expands to something precisely when CONFIG_IS_ENABLED(FOO) would
expand to 1, and expands to nothing otherwise. It is, in other words,
completely equivalent to the three lines
#if CONFIG_IS_ENABLED(FOO)
something
#endif
The second argument must be parenthesized in order to allow any
tokens, including a trailing comma, to appear - one use case for this
is precisely to make it a bit more ergonomic to build an array and
only include certain items depending on .config. That should increase
both readability and not least "git grep"ability.
A third variant is also introduced,
CONFIG_IS_ENABLED(FOO, (xxx), (yyy))
which corresponds to
#if CONFIG_IS_ENABLED(FOO)
xxx
#else
yyy
#endif
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
U-Boot does not have loadable modules, and nothing currently uses any
of the (CONFIG_)?IS_(BUILTIN|MODULE) macros - only
the (CONFIG_)?IS_ENABLED variants are ever used.
While I understand the desire to keep this somewhat synchronized with
linux, we've already departed by the introduction of the
CONFIG_IS_ENABLED extra logic, and deleting these makes the next patch
much simpler, since I won't have to duplicate a lot of logic for no
real gain (as there are no users).
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
linux/kconfig.h: simplify logic for choosing CONFIG_{SPL_, TPL_, }*
Instead of using the arg1_or_junk trick to pick between two choices,
with a bit of duplication between the branches (and most of the
CONFIG_TPL_BUILD case being redundant, as _IS_TPL is known to be
defined to 1 in that case), simply define a prefix that we inject
between CONFIG_ and the given config symbol.
This only requires one level of indirection (to get the
_CONFIG_PREFIX macro expanded before the token concatenation takes
place), and makes it easy to, say, introduce a CONFIG_HOSTTOOL_
prefix. [I would expect most HOSTTOOL_ symbols to just be def_bool y,
but it would allow us to clean up some of the ifdef HOSTCC mess in the
sources shared between U-Boot and host tools.]
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Fri, 3 Jul 2020 03:12:36 +0000 (21:12 -0600)]
minnowmax: Enable the copy framebuffer
Update the video driver to support this feature and enable it on
minnowmax to speed up the display.
With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from over 13 seconds to
300ms, at 1280x1024.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:34 +0000 (21:12 -0600)]
chromebook_samus: Enable the copy framebuffer
Update the video driver to support this feature and enable it on samus.
Also remove the multi-line scrolling since normal scrolling is fast enough
now.
With this change, the time taken to print the environment to the display
without CONFIG_CONSOLE_SCROLL_LINES is reduced from about 430ms to 12ms.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:33 +0000 (21:12 -0600)]
x86: video: Support copy framebuffer with probed devices
For PCI video devices that are not mentioned in the devicetree, U-Boot
does not bind a driver before relocation, since PCI is not fully probed
at that point. Furthermore it is possible for the video device to be on
a secondary bus which is not even scanned.
This is fine if the framebuffer is allocated in fixed memory, as it
normally is on x86. But when using this as a copy framebuffer, we also
need U-Boot to allocate its own cached framebuffer for working in. Since
the video driver is never bound before relocation, the framebuffer size
is never set and U-Boot does no allocation.
Add a new CONFIG option to reserve 16MB of memory for this eventuality.
This allows vesa devices to use the copy framebuffer.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:32 +0000 (21:12 -0600)]
video: Correctly handle multiple framebuffers
At present video_bottom is set to the bottom of each framebuffer when it
is allocated. This is not correct, since it should hold the bottom of the
entire area available for framebuffers.
Fix this by adding a private address in the uclass which keeps track of
the next available spot for a framebuffer.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:30 +0000 (21:12 -0600)]
video: pci: Set up the copy framebuffer
When using a copy framebuffer we need to tell the video subsystem its
address. U-Boot's normally allocated framebuffer is used as the working
buffer, but nothing is displayed until it is copied to the copy
framebuffer.
For this to work the video driver must request that a framebuffer be
allocated separately from the hardware framebuffer, so add a check for
that.
Also add a log category so that logging appears correctly.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:26 +0000 (21:12 -0600)]
video: Update rotated console to support copy buffer
Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:25 +0000 (21:12 -0600)]
video: Update truetype console to support copy buffer
Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:24 +0000 (21:12 -0600)]
video: Update normal console to support copy buffer
Update the implementation to keep a track of what it changes in the frame
buffer and then tell the copy buffer about it. Use the special
vidconsole_memmove() helper so that memmove() operations are also
reflected in the copy buffer.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:20 +0000 (21:12 -0600)]
video: Add support for copying to a hardware framebuffer
Some architectures use a cached framebuffer and flush the cache as needed
so that changes are visible. This is supported by U-Boot.
However x86 uses an uncached framebuffer with a 'write-combining' feature
to speed up writes. Reads are permitted but they are extremely expensive.
Unfortunately, reading from the frame buffer is quite common, e.g. to
scroll it. This makes scrolling very slow.
Add a new feature which supports copying modified parts of the frame
buffer to the uncached hardware buffer. This speeds up scrolling by at
least 10x on x86 so the extra complexity cost seems worth it.
As a starting point, add the Kconfig, update the video structures to keep
track of the buffer and add a function to do the copy.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:18 +0000 (21:12 -0600)]
video: Drop unnecessary #ifdef around vid_console_color()
All of the functions in this file only apply if DM_VIDEO is enabled. Drop
the #ifdef as it just clutters things up. Add the needed forward
declaration.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:17 +0000 (21:12 -0600)]
video: Adjust rotated console to start at right edge
At present when the console is rotated 180 degrees it starts almost a
whole character to the left of the right edge (typically 7 pixels with
an 8-pixel-wide font). On a display which aligns with the font width,
this just wastes space. On a display that does not this can result in
x_frac going negative for the final character (the one on the left
side) and the overflow -EAGAIN check at the start of the function
failing.
Change the function to start at the rightmost pixel to fix these
problems.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:16 +0000 (21:12 -0600)]
video: Split out expression parts into variables
The functions in this file do similar things but not always in the same
way. To make the code easier to read and compare, use a separate 'linenum'
variable in every function. This is then multiplied by the line length to
get the offset within the frame buffer to modify. Also use an 'x' variable
to hold the pixel position within that line. This is multipled by the
pixel size and added to the offset.
Also move the pbytes declaration up a little with the other long lines.
A side effect of splitting out these variables is that they are promoted
to int, i.e. a signed type, from the unsigned short used in the
vidconsole_priv struct. This would be necessary should any of the
variables go negative. At present this can actually happen in
console_putc_xy_2(), if the display width is not a multiple of the
character size (see next patch).
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Tested-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:15 +0000 (21:12 -0600)]
sandbox: video: Allow selection of rotated console
Add a devicetree property to select a rotated console. This uses the same
encoding as vidconsole itself: 0=normal; 1=90 degrees clockwise, 2=upside
down, 3=90 degrees anticlockwise.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de>
Simon Glass [Fri, 3 Jul 2020 03:12:14 +0000 (21:12 -0600)]
video: Show an error when a vidconsole function fails
At present these functions fail silently even when debugging, which is not
very helpful. Add a way to print a message to the serial output when an
error is detected.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Anatolij Gustschin <agust@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Simon Glass [Fri, 3 Jul 2020 03:12:13 +0000 (21:12 -0600)]
console: Add a way to output to serial only
In the video drivers it is useful to print errors while debugging but
doing so risks an infinite loop as the debugging info itself may go
through the video drivers.
Add a new console function that prints information only to the serial
device, thus making it safe for use in debugging.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
i2c: stm32f7: SYSCFG Fast Mode Plus support for I2C STM32F7
Read SYSCFG bindings to set Fast Mode Plus bits if Fast Mode Plus
speed is selected.
Handle the stm32mp15 specific compatible to handle FastMode+
registers handling which is different on the stm32mp15 compared
to the stm32f7 or stm32h7.
Indeed, on the stm32mp15, the FastMode+ set and clear registers
are separated while on the other platforms (F7 or H7) the control
is done in a unique register.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Heiko Schocher <hs@denx.de>
test: dm: rtc: add test of dm_rtc_read, dm_rtc_write
Define a few aux registers and check that they can be read/written
individually. Also check that one can access the time-keeping
registers directly and get the expected results.
The problem is that after each register write,
sandbox_i2c_rtc_complete_write() gets called and sets the internal
time from the current set of registers. However, when we get to
writing 31 to mday, the registers are in an inconsistent state (mon is
still 4), so the mktime machinery ends up translating April 31st to
May 1st. Upon the next register write, the registers are populated by
sandbox_i2c_rtc_prepare_read(), so the 31 we just wrote to mday gets
overwritten by a 1.
Fix it by writing all registers at once, and for consistency, update
the get method to retrieve them all with one "i2c transfer".
Mostly as an aid for debugging RTC drivers, provide a command that can
be used to read/write arbitrary registers (assuming the driver
provides the read/write methods or their single-register-at-a-time
variants).
This simply consists of renaming the existing pcf2127_read_reg()
helper to follow the naming of the other
methods (i.e. pcf2127_rtc_<method name>) and changing the type of its
"len" parameter.
rtc: fall back to ->{read, write} if ->{read, write}8 are not provided
Similar to how the dm_rtc_{read,write} functions fall back to using
the {read,write}8 methods, do the opposite in the rtc_{read,write}8
functions.
This way, each driver only needs to provide either ->read8 or ->read
to make both rtc_read8() and dm_rtc_read() work - without this, a
driver that provides ->read() would most likely just duplicate the
logic here for implementing a ->read8() method in term of its ->read()
method. The same remarks of course apply to the write case.
Similar to dm_rtc_read(), introduce a helper that allows the caller to
write multiple consecutive 8-bit registers with one call. If the
driver provides the ->write method, use that, otherwise loop using
->write8.
Some users may want to read multiple consecutive 8-bit
registers. Instead of each caller having to implement the loop,
provide a dm_rtc_read() helper. Also, allow a driver to provide a
->read method, which can be more efficient than reading one register
at a time.
Ye Li [Wed, 10 Jun 2020 03:29:50 +0000 (20:29 -0700)]
i2c: imx_lpi2c: Improve the codes to use private data
Current driver calls the devfdt_get_addr to get the base address
of lpi2c controller in each sub-functions. Since the devfdt_get_addr
accesses the DTB and translate the address, it introduces much
overhead.
Improve the codes to use private variable which has recorded the
base address from probe.
Signed-off-by: Ye Li <ye.li@nxp.com> Reviewed-by: Peng Fan <peng.fan@nxp.com>
Heiko Stuebner [Fri, 22 May 2020 14:20:33 +0000 (16:20 +0200)]
lib: rsa: function to verify a signature against a hash
rsa_verify() expects a memory region and wants to do the hashing itself,
but there may be cases where the hashing is done via other means,
like hashing a squashfs rootfs.
So add rsa_verify_hash() to allow verifiying a signature against
an existing hash. As this entails the same verification routines
we can just move the relevant code over from rsa_verify() and also
call rsa_verify_hash() from there.
Simon Glass [Wed, 3 Jun 2020 01:26:49 +0000 (19:26 -0600)]
cmd: Add a memory-search command
It is useful to be able to find hex values and strings in a memory range.
Add a command to support this.
cmd: Fix 'md' and add a memory-search command
At present 'md.q' is broken. This series provides a fix for this. It also
implements a new memory-search command called 'ms'. It allows searching
memory for hex and string data.
END
Simon Glass [Wed, 3 Jun 2020 01:26:48 +0000 (19:26 -0600)]
command: Drop #ifdef for MEM_SUPPORT_64BIT_DATA
This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.
Fix up the code to take advantage of that, removing the preprocessor
conditions.
Also include the header file that defines MEM_SUPPORT_64BIT_DATA. It is
included by env.h in this file, but that might not last forever.
Simon Glass [Wed, 3 Jun 2020 01:26:47 +0000 (19:26 -0600)]
display_options: Drop #ifdef for MEM_SUPPORT_64BIT_DATA
This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.
Fix up the code to take advantage of that, removing the preprocessor
conditions.
Also include the missing header file that defines MEM_SUPPORT_64BIT_DATA
Fixes: 09140113108 ("command: Remove the cmd_tbl_t typedef") Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Wed, 3 Jun 2020 01:26:46 +0000 (19:26 -0600)]
cmd: mem: Drop #ifdef for MEM_SUPPORT_64BIT_DATA
This is defined only when __lp64__ is defined. That means that ulong is
64 bits long. Therefore we don't need to use a separate u64 type on those
architectures.
Fix up the code to take advantage of that, removing the preprocessor
conditions.
Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Stefan Roese <sr@denx.de>
projects / u-boot.git / log