Signed-off-by: Pragnesh Patel
---
arch/riscv/dts/fu540-c000-u-boot.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/dts/fu540-c000-u-boot.dtsi
b/arch/riscv/dts/fu540-c000-u-boot.dtsi
index a06e1b11c6..b7cd600b8c 100644
---
Hi Jaehoon,
> -Original Message-
> From: Jaehoon Chung
> Sent: Tuesday, October 20, 2020 5:52 AM
> To: Y.b. Lu ; u-boot@lists.denx.de; Peng Fan
>
> Subject: Re: [PATCH 2/2] mmc: fsl_esdhc: make sure delay chain locked for
> HS400
>
> Dear Yangbo,
>
> On 10/16/20 12:13 PM, Yangbo Lu
The initial clock setting should be through sysctl register only,
while the mmc_set_clock() will call mmc_set_ios() introduce other
configurations like bus width, mode, and so on.
Signed-off-by: Yangbo Lu
Reviewed-by: Jaehoon Chung
---
Changes for v2:
- Added "Reviewed-by".
---
For eMMC HS400 mode, the DLL reset is a required step for mmc rescan.
This step has not been documented in reference manual, but the RM will
be fixed sooner or later.
In previous commit to support eMMC HS400,
db8f936 mmc: fsl_esdhc: support eMMC HS400 mode
the steps to configure DLL could be
This patch-set provides fix up for eMMC HS400 for a potential
DLL lock issue during mmc rescan.
Changes for v2:
- Added "Reviewed-by".
- Explained more in patch 2 commit message.
Yangbo Lu (2):
mmc: fsl_esdhc: set sysctl register for clock initialization
mmc: fsl_esdhc: make sure delay chain
On Tue, 2020-10-20 at 00:15 +0200, Marek Vasut wrote:
> On 10/19/20 2:19 PM, Chunfeng Yun wrote:
> > Due to the following to patches:
> > 4a1989c0bc77 ("dm: Don't undefine dev_xxx macros")
> > 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
> >
> > Need include
> -Original Message-
> From: Ralph Siemsen
> Sent: Tuesday, October 20, 2020 1:43 AM
> To: Tan, Ley Foon
> Cc: Dinh Nguyen ; Marek Vasut ;
> Simon Goldschmidt ; u-
> b...@lists.denx.de; Tom Rini
> Subject: Re: [PATCH v1] arm: socfpga: fix Gen5 enable of EMAC via FPGA
>
> On Tue, Sep
On 10/19/20 6:13 PM, Reuben Dowle wrote:
The reverted change linked to some kernel documentation that requires 64-
bit alignment. I agree with the alignment requirement.
Im my opinion, there are two things that need to be done:
First is to look at an ALIGNED address for the fdt. A summary
> > What assumptions? Any code that assumes 4 byte alignment will also work
> on 8 byte alignment.
> >
> > Reverting is not the same as assuming ALIGN(...4) if incoming data is not
> already aligned to 4 bytes (as was the case when I saw crashes).
>
> Can the incoming data _not_ be 4 byte aligned
On 10/19/20 6:02 PM, Marek Vasut wrote:
On 10/20/20 12:58 AM, Tom Rini wrote:
On Tue, Oct 20, 2020 at 12:54:35AM +0200, Marek Vasut wrote:
On 10/20/20 12:45 AM, Tom Rini wrote:
On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
On 10/19/20 11:50 PM, Reuben Dowle wrote:
The
> The reverted change linked to some kernel documentation that requires 64-
> bit alignment. I agree with the alignment requirement.
>
> Im my opinion, there are two things that need to be done:
>
> First is to look at an ALIGNED address for the fdt. A summary inspection of
>
On 10/20/20 1:02 AM, Reuben Dowle wrote:
>> The problem is that the previous alignment was 4 byte, now it is 8 byte and
>> that breaks all the other assumptions. So, this patch should be reverted to
>> fix
>> the platforms which used to work (or use ALIGN(...4), which is the same as
>> reverting
> The problem is that the previous alignment was 4 byte, now it is 8 byte and
> that breaks all the other assumptions. So, this patch should be reverted to
> fix
> the platforms which used to work (or use ALIGN(...4), which is the same as
> reverting it really).
What assumptions? Any code that
On 10/20/20 12:58 AM, Tom Rini wrote:
> On Tue, Oct 20, 2020 at 12:54:35AM +0200, Marek Vasut wrote:
>> On 10/20/20 12:45 AM, Tom Rini wrote:
>>> On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
On 10/19/20 11:50 PM, Reuben Dowle wrote:
> The alignment of 8 bytes would also
On Tue, Oct 20, 2020 at 12:54:35AM +0200, Marek Vasut wrote:
> On 10/20/20 12:45 AM, Tom Rini wrote:
> > On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
> >> On 10/19/20 11:50 PM, Reuben Dowle wrote:
> >>> The alignment of 8 bytes would also work if code was expecting 4 byte
> >>>
On 10/20/20 12:45 AM, Tom Rini wrote:
> On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
>> On 10/19/20 11:50 PM, Reuben Dowle wrote:
>>> The alignment of 8 bytes would also work if code was expecting 4 byte
>>> alignment. So the explanation you give for reverting this does not make
On 10/20/20 12:17 AM, Reuben Dowle wrote:
[...]
>> On 10/19/20 11:50 PM, Reuben Dowle wrote:
>>> The alignment of 8 bytes would also work if code was expecting 4 byte
>> alignment. So the explanation you give for reverting this does not make
>> sense to me.
>>
>> Well, since U-Boot 2020.10-rc5,
On Mon, Oct 19, 2020 at 11:59:22PM +0200, Marek Vasut wrote:
> On 10/19/20 11:50 PM, Reuben Dowle wrote:
> > The alignment of 8 bytes would also work if code was expecting 4 byte
> > alignment. So the explanation you give for reverting this does not make
> > sense to me.
>
> Well, since U-Boot
> -Original Message-
> From: Marek Vasut
> Sent: Tuesday, 20 October 2020 10:59 am
> To: Reuben Dowle ; u-boot@lists.denx.de
> Cc: Tom Rini
> Subject: Re: [PATCH] Revert "Fix data abort caused by mis-aligning FIT data"
>
> On 10/19/20 11:50 PM, Reuben Dowle wrote:
> > The alignment of 8
On 10/19/20 2:19 PM, Chunfeng Yun wrote:
> Due to the following to patches:
> 4a1989c0bc77 ("dm: Don't undefine dev_xxx macros")
> 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
>
> Need include device_compat.h and no need use __maybe_unused anymore
> to fix unused
On 08/10/2020 14:02, Heinrich Schuchardt wrote:
Hi,
> On 25.08.20 18:57, Simon Glass wrote:
>> On Mon, 24 Aug 2020 at 22:15, Heinrich Schuchardt wrote:
>>>
>>> On 7/25/20 8:18 PM, Heinrich Schuchardt wrote:
The current default of 0x400 for SYS_MALLOC_F_LEN is too small if any
On 10/19/20 11:50 PM, Reuben Dowle wrote:
> The alignment of 8 bytes would also work if code was expecting 4 byte
> alignment. So the explanation you give for reverting this does not make sense
> to me.
Well, since U-Boot 2020.10-rc5, any STM32MP1 board does no longer boot
and if I revert this
On Mon, 28 Sep 2020 11:30:16 +0200
Patrick Delaunay patrick.delau...@st.com wrote:
...
> 103 files changed, 122 insertions(+), 63 deletions(-)
applied to u-boot-video/master, thanks!
--
Anatolij
On Mon, 28 Sep 2020 11:30:15 +0200
Patrick Delaunay patrick.delau...@st.com wrote:
...
> 119 files changed, 88 insertions(+), 43 deletions(-)
applied to u-boot-video/master, thanks!
--
Anatolij
Dear Yangbo,
On 10/16/20 12:13 PM, Yangbo Lu wrote:
> The initial clock setting should be through sysctl register only,
> while the mmc_set_clock() will call mmc_set_ios() introduce other
> configurations like bus width, mode, and so on.
>
> Signed-off-by: Yangbo Lu
Reviewed-by: Jaehoon Chung
The alignment of 8 bytes would also work if code was expecting 4 byte
alignment. So the explanation you give for reverting this does not make sense
to me.
The version I use in production uses 4 byte alignment, but on advice of Tom
Rini I extended to 8 bytes. Maybe we could switch to just
Dear Yangbo,
On 10/16/20 12:13 PM, Yangbo Lu wrote:
> For eMMC HS400 mode, the DLL reset is a required step for mmc rescan.
> This step has not been documented in reference manual, but the RM will
> be fixed sooner or later.
>
> This patch is to add the step of DLL reset, and make sure delay
From: Frederik Aalund
Some devices have their own framebuffer memory that is not
shared directly with the CPU. For said devices, we need to
copy U-boot's framebuffer (priv->fb) to the device's own
framebuffer memory. E.g., via SPI.
To support these devices, I've added the copy_fb_to_hw op.
It's
This reverts commit eb39d8ba5f0d1468b01b89a2a464d18612d3ea76.
The commit breaks booting of fitImage by SPL, the system simply hangs.
This is because on arm32, the fitImage and all of its content can be
aligned to 4 bytes and U-Boot expects just that.
Signed-off-by: Marek Vasut
Cc: Reuben Dowle
The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
unsupported, reinstate the old cd-gpios behavior until this handling
is fully implemented. This permits the DHSOM to boot from SD again,
without this patch the card detect fails.
Signed-off-by: Marek Vasut
Cc: Patrick Delaunay
On Mon, 28 Sep 2020 11:30:14 +0200
Patrick Delaunay patrick.delau...@st.com wrote:
...
> 23 files changed, 21 insertions(+), 14 deletions(-)
applied to u-boot-video/master, thanks!
--
Anatolij
On Fri, 2 Oct 2020 11:16:08 +0200
Neil Armstrong narmstr...@baylibre.com wrote:
...
> ---
> drivers/video/dw_mipi_dsi.c | 17 +++--
> include/mipi_dsi.h | 16
> 2 files changed, 27 insertions(+), 6 deletions(-)
applied to u-boot-video/master, thanks!
--
On Fri, 2 Oct 2020 11:16:09 +0200
Neil Armstrong narmstr...@baylibre.com wrote:
...
> ---
> drivers/video/dw_mipi_dsi.c | 20
> include/mipi_dsi.h | 1 +
> 2 files changed, 17 insertions(+), 4 deletions(-)
applied to u-boot-video/master, thanks!
--
Anatolij
On Sun, 11 Oct 2020 14:28:02 +0200
Dario Binacchi dario...@libero.it wrote:
...
> Dario Binacchi (2):
> video: backlight: fix pwm data structure description
> video: backlight: fix pwm's duty cycle calculation
Series applied to u-boot-video/master, thanks!
--
Anatolij
On 19/10/2020 05:41, Simon Glass wrote:
> When a section is compressed, all entries within it are grouped together
> into a compressed block of data. This obscures the start of each
> individual child entry.
>
> Avoid reporting bogus 'image-pos' properties in this case, since it is
> not possible
On 19/10/2020 05:41, Simon Glass wrote:
> At present we use 'compress' as the property to set the compression of
> a 'files' entry. But this conflicts with the same property for entries,
> of which Entry_section is a subclass.
>
> Strictly speaking, since Entry_files is in fact a subclass of
>
On 19/10/2020 05:41, Simon Glass wrote:
> Create a new _BuildSectionData() to hold the code that is now in
> GetData(), so that it is clearly separated from entry.GetData() base
> function.
>
> Separate out the 'pad-before' processing to make this easier to
> understand.
>
> Unfortunately this
On Mon, Oct 19, 2020 at 08:13:31AM +, eugen.hris...@microchip.com wrote:
> Hello Tom,
>
> Please pull tag u-boot-atmel-2021.01-b, the second set of new features
> and fixes for 2021.01 cycle.
>
> This feature set brings the rework of the clock tree for sam9x60 SoC.
> This makes the clock
On Sun, Oct 18, 2020 at 10:36:01PM +0200, Anatolij Gustschin wrote:
> Hi Tom,
>
> please pull video updates for v2021.01.
>
> gitlab CI:
> https://gitlab.denx.de/u-boot/custodians/u-boot-video/-/pipelines/5031
>
> Thanks!
>
> The following changes since commit
> -Original Message-
> From: Stefan Roese
> Sent: Monday, October 19, 2020 3:40 PM
> To: Vabhav Sharma (OSS) ; u-
> b...@lists.denx.de; s...@chromium.org
> Cc: Varun Sethi ; andre.przyw...@arm.com; Vabhav
> Sharma
> Subject: Re: [PATCH] dm: core: add function uclass_probe_all() to
From: Vabhav Sharma
U-Boot DM model probe only single device at a time
which is enabled and configured using device tree
or platform data method.
PL011 UART IP is SBSA compliant and firmware does the
serial port set-up, initialization and let the kernel use
UART port for sending and receiving
The series was born from the need to manage the PWM backlight of the
display connected to my beaglebone board. To hit the target, I had to
develop drivers for PWM management which in turn relied on drivers for
managing timers and clocks, all developed according to the driver model.
My intention
From: Vabhav Sharma
- Add common method to probe devices belonging to same uclass
- Add config in serial uclass to support optional inclusion of uclass_probe_all
- Enable support for available serial devices probe
Changes for v3:
Incorporated Simon and Stephan review comment
- Define
From: Vabhav Sharma
Support a common method to probe all devices associated with uclass.
This includes data structures and code for finding the first device and
looping for remaining devices associated with uclasses (groups of devices
with the same purpose, e.g. all SERIAL ports will be in the
On Tue, Sep 29, 2020 at 02:52:05PM -0400, Ralph Siemsen wrote:
Fixes: db5741f7a85ec3ee79b64496172afaa7dc2cb225 ("arm: socfpga: Convert
system manager from struct to defines")
Just curious if you have had a chance to look over this patch?
With support for other clock drivers, the potentially supported CDCE913
device can no longer be probed without specifying its DT node name.
Signed-off-by: Dario Binacchi
---
(no changes since v1)
board/ti/am335x/board.c | 2 +-
board/ti/am43xx/board.c | 2 +-
2 files changed, 2
The schedule for deprecating the features of the pre-driver-model puts
2019.17 as the deadline for the video subsystem. Furthermore, the latest
patches applied to the am335x-fb.c module have decreased the amount of
code shared with the pre-driver-model implementation. Splitting the two
The previous version of am335x-fb.c contained the functionalities of two
drivers that this patch has split. It was a video type driver that used
the same registration compatible string that now registers a panel type
driver. The proof of this is that two compatible strings were referred
to within
Enabling the domain clock is performed by the sysc interconnect target
module driver during the video device probing.
Signed-off-by: Dario Binacchi
---
(no changes since v3)
Changes in v3:
- Remove clock domain enabling/disabling.
- Update the commit message.
The patch configures the display DPLL using the functions provided by
the driver model API for the clock. The device tree contains everything
needed to get the DPLL clock. The round rate function developed for
calculating the DPLL multiplier and divisor and the platform routines
for accessing the
The patch adds a function to get display timings from the device tree
node attached to the device.
Signed-off-by: Dario Binacchi
Reviewed-by: Simon Glass
---
(no changes since v1)
arch/sandbox/dts/test.dts | 46 ++
drivers/core/read.c | 6 +++
include/dm/read.h
Add drivers/video/ti/ folder and move all TI's code in this folder for
better maintenance.
Signed-off-by: Dario Binacchi
---
(no changes since v1)
drivers/video/Kconfig | 5 +
drivers/video/Makefile| 4 +---
drivers/video/ti/Kconfig | 8
The implementation of this driver was needed to bind the device tree
sub-nodes of the 'clocks' node. In fact, the lack of the compatible
property in the 'clocks' node does not allow the generic 'syscon' or
'simple-bus' drivers linked to the 'scm_conf@0' node to bind the
'clocks' node and in turn
The TI PWMSS driver is a simple bus driver for providing clock and power
management for the PWM peripherals on TI AM33xx SoCs, namely eCAP,
eHRPWM and eQEP.
For DT binding details see Linux doc:
- Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
Signed-off-by: Dario Binacchi
---
(no
The __of_translate_address routine translates an address from the
device tree into a CPU physical address. A note in the description of
the routine explains that the crossing of any level with
#size-cells = <0> is to be considered an error not by specification but
since inherited from IBM. This
Enhanced high resolution PWM module (EHRPWM) hardware can be used to
generate PWM output over 2 channels. This commit adds PWM driver support
for EHRPWM device present on AM33XX SOC.
The code is based on the drivers/pwm/pwm-tiehrpwm.c driver of the Linux
kernel version 5.9-rc7.
For DT binding
This minimal driver is only used to bind child devices.
For DT binding details see Linux doc:
- Documentation/devicetree/bindings/arm/omap/prcm.txt
Signed-off-by: Dario Binacchi
---
(no changes since v3)
Changes in v3:
- doc/device-tree-bindings/arm/omap,prcm.txt.
- Add to commit message the
The implementation of this driver was needed to bind the sub-nodes of
the 'clocks' node. In fact, the lack of the compatible property in
the 'clocks' node does not allow the generic 'simple-bus' driver to bind
the 'clocks' node and in turn its sub-nodes.
The 'prcm@20' node is therefore the
The prescaler (PTV) setting must be taken into account even when the
timer input clock frequency has been set.
Signed-off-by: Dario Binacchi
---
(no changes since v1)
drivers/timer/omap-timer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
Add drivers/clk/ti/ folder and move all TI's code in this folder for
better maintenance.
Signed-off-by: Dario Binacchi
---
(no changes since v1)
drivers/clk/Kconfig | 40 +-
drivers/clk/Makefile | 8 +---
Until now the clkctrl clocks have been enabled/disabled through platform
routines. Thanks to this patch they can be enabled and configured directly
by the probed devices that need to use them.
For DT binding details see Linux doc:
- Documentation/devicetree/bindings/clock/ti-clkctrl.txt
Up till this commit passing NULL as input parameter was allowed, but not
handled properly. When a NULL parameter was passed to the function a data
abort was raised.
Signed-off-by: Dario Binacchi
Reviewed-by: Simon Glass
---
(no changes since v1)
arch/arm/mach-omap2/am33xx/clock.c | 10
The patch adds support for TI divider clock binding. The driver uses
routines provided by the common clock framework (ccf).
The code is based on the drivers/clk/ti/divider.c driver of the Linux
kernel version 5.9-rc7.
For DT binding details see:
-
The patch adds support for TI gate clock binding. The code is based on
the drivers/clk/ti/gate.c driver of the Linux kernel version 5.9-rc7.
For DT binding details see:
- Documentation/devicetree/bindings/clock/ti/gate.txt
Signed-off-by: Dario Binacchi
---
Changes in v4:
- Include
Add missing DPLL_EN_FAST_RELOCK_BYPASS macro. Used to put the DPLL in
idle bypass fast relock mode.
Signed-off-by: Dario Binacchi
---
(no changes since v1)
arch/arm/include/asm/arch-am33xx/clock.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/arch-am33xx/clock.h
The digital phase-locked loop (DPLL) provides all interface clocks and
functional clocks to the processor of the AM33xx device. The AM33xx
device integrates five different DPLLs:
* Core DPLL
* Per DPLL
* LCD DPLL
* DDR DPLL
* MPU DPLL
The patch adds support for the compatible strings:
*
It returns the rate which will be set if you ask clk_set_rate() to set
that rate. It provides a way to query exactly what rate you'll get if
you call clk_set_rate() with that same argument.
So essentially, clk_round_rate() and clk_set_rate() are equivalent
except the former does not modify the
The driver manages a register-mapped multiplexer with multiple input
clock signals or parents, one of which can be selected as output. It
uses routines provided by the common clock framework (ccf).
The code is based on the drivers/clk/ti/mux.c driver of the Linux
kernel version 5.9-rc7.
For DT
Add support for PRUSS SYSC type:
The PRUSS module has a SYSCFG which is unique. The SYSCFG has two
additional unique fields called STANDBY_INIT and SUB_MWAIT in addition
to regular IDLE_MODE and STANDBY_MODE fields. Add the bindings for this
new sysc type.
Add support for MCAN on dra76x:
The
There have been several changes to the am33xx.dtsi, so this patch
re-syncs it with Linux.
Let's add proper interconnect hierarchy for l4 interconnect instances
with the related ti-sysc interconnect module data as documented in
Documentation/devicetree/bindings/bus/ti-sysc.txt of the Linux kernel.
We can handle the sysc interconnect target module in a generic way for
many TI SoCs. Initially let's just enable domain clocks before the
children are probed.
The code is loosely based on the drivers/bus/ti-sysc.c of the Linux
kernel version 5.9-rc7.
For DT binding details see:
-
Export routines that can be used by other drivers avoiding duplicating
code.
Signed-off-by: Dario Binacchi
Reviewed-by: Simon Glass
---
(no changes since v2)
Changes in v2:
- Add the clk_ prefix to the divider functions.
- Add kernel-doc comments to the exported functions.
Hi Michael,
On Mon, 19 Oct 2020 at 09:47, Michael Walle wrote:
>
> Am 2020-10-19 16:54, schrieb Wolfgang Denk:
> > Dear Simon,
> >
> > In message <20201019135602.3943835-12-...@chromium.org> you wrote:
> >> In some cases it is necessary to pass parameters to Linux so that it
> >> will
> >> boot
Hi Wolfgang,
On Mon, 19 Oct 2020 at 08:55, Wolfgang Denk wrote:
>
> Dear Simon,
>
> In message <20201019135602.3943835-12-...@chromium.org> you wrote:
> > In some cases it is necessary to pass parameters to Linux so that it will
> > boot correctly. For example, the rootdev parameter is often
Hi Rasmus,
On Mon, 19 Oct 2020 at 08:43, Rasmus Villemoes
wrote:
>
> On 19/10/2020 15.56, Simon Glass wrote:
> > In some cases it is necessary to pass parameters to Linux so that it will
> > boot correctly. For example, the rootdev parameter is often used to
> > specify the root device. However
Am 2020-10-19 16:54, schrieb Wolfgang Denk:
Dear Simon,
In message <20201019135602.3943835-12-...@chromium.org> you wrote:
In some cases it is necessary to pass parameters to Linux so that it
will
boot correctly. For example, the rootdev parameter is often used to
specify the root device.
Dear Simon,
In message <20201019135602.3943835-12-...@chromium.org> you wrote:
> In some cases it is necessary to pass parameters to Linux so that it will
> boot correctly. For example, the rootdev parameter is often used to
> specify the root device. However the root device may change depending
On Mon, Oct 19, 2020 at 11:17:54AM +0200, Maxime Ripard wrote:
> On Sun, Oct 18, 2020 at 09:18:15PM +0200, Anatolij Gustschin wrote:
> > DM_VIDEO conversion deadline has passed, disable VIDEO config
> > option by default. Boards should convert to DM_VIDEO if they
> > need video console support.
>
Dear Simon Glass,
In message <20201019135602.3943835-10-...@chromium.org> you wrote:
> At present we only support updating the 'bootargs' environment
> variable. Add another function to update a buffer instead. This will
> allow zimage to use this feature.
I think this is the wrong way to
Dear Simon,
In message <20201019135602.3943835-8-...@chromium.org> you wrote:
...
>
> It is also useful for zimage to use a buffer, since it does not actually
> put the Linux command line in the bootargs variable.
...which I consider a bug that should be fixed.
Best regards,
Wolfgang Denk
--
On 19/10/2020 15.56, Simon Glass wrote:
> In some cases it is necessary to pass parameters to Linux so that it will
> boot correctly. For example, the rootdev parameter is often used to
> specify the root device. However the root device may change depending on
> whence U-Boot loads the kernel. At
On 19.10.20 15:55, Simon Glass wrote:
> This series adds tests to the fixup_silent-linux() function and extends
> the 'zimage' command to use it.
>
> It also adds a new string-substition feature to allow bootargs to be a
> template, rather than having to build it up piece by piece with
>
Hi,
We have several use cases where customers want to partition memory by
putting NS images above 4GB. On Xilinx arm 64bit SOC 0-2GB can be used for
others CPU in the systems (like R5) or for secure sw.
Currently there is limitation in SPL to record load/entry addresses in
64bit format because
The commit 9f45aeb93727 ("spl: fit: implement fdt_record_loadable") which
introduced fdt_record_loadable() state there spl_fit.c is not 64bit safe.
Based on my tests on Xilinx ZynqMP zcu102 platform there shouldn't be a
problem to record these addresses in 64bit format.
The patch adds support for
SPL is creating fit-images DT node when loadables are recorded in selected
configuration. Entries which are created are using entry-point and
load-addr property names. But there shouldn't be a need to use non standard
properties because entry/load are standard FIT properties. But using
standard
On 19/10/20, Jorge Ramirez-Ortiz, Foundries wrote:
> On 19/10/20, Fabio Estevam wrote:
> > Hi Jorge,
> >
> > On Wed, Oct 14, 2020 at 10:07 AM Jorge Ramirez-Ortiz
> > wrote:
> > >
> > > In order to be able to run the I2C bus at 400Khz, the chip errata[1]
> > > recommends that the peripheral
In order to be able to run the I2C bus at 400Khz, the chip errata[1]
recommends that the peripheral clock runs out of the 24MHz oscillator.
[1] Rev 2, 10/2019, ERR007805
Signed-off-by: Jorge Ramirez-Ortiz
---
arch/arm/mach-imx/mx6/soc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
From: T Karthik Reddy
Remove fixed reference clk used by plat->frequency and use clk
subsystem to get reference clk. As per spi dt bindings
"spi-max-frequency" property should be used by the slave devices.
This property is read by spi-uclass driver for the slave device.
So avoid reading above
From: T Karthik Reddy
Remove fixed reference clk used by plat->frequency and use clk
subsystem to get reference clk. As per spi dt bindings
"spi-max-frequency" property should be used by the slave devices.
This property is read by spi-uclass driver for the slave device.
So avoid reading above
There also a need to check return values to make sure that clocks were
enabled and setup properly.
Signed-off-by: Michal Simek
Reviewed-by: Simon Glass
---
Changes in v2:
- Add missing header
- Add Simon's tag
drivers/serial/serial_pl01x.c | 13 -
1 file changed, 12
At present zimage does its own command-line processing and does not
support the 'silent console' feature. There doesn't seem to be any good
reason for this.
Add support for silent console to zimage.
Signed-off-by: Simon Glass
---
arch/x86/lib/zimage.c | 14 ++
1 file changed, 14
In some cases it is necessary to pass parameters to Linux so that it will
boot correctly. For example, the rootdev parameter is often used to
specify the root device. However the root device may change depending on
whence U-Boot loads the kernel. At present it is necessary to build up
the command
At present only one transformation is supported: making the Linux console
silent. To prepare for adding more, convert the boolean parameter into a
flag value.
Signed-off-by: Simon Glass
---
common/bootm.c | 8 +---
include/bootm.h | 11 +--
test/bootm.c| 10 +-
3
At present we only support updating the 'bootargs' environment
variable. Add another function to update a buffer instead. This will
allow zimage to use this feature.
Also add a lot more tests to cover various cases.
Signed-off-by: Simon Glass
---
common/bootm.c | 18 +++-
At present this function fails silently on error. Update it to produce
an error code. Report this error to the user and abort the boot, since it
likely will prevent a successful start.
No tests are added at this stage, since additional refactoring is taking
place in subsequent patches.
This series adds tests to the fixup_silent-linux() function and extends
the 'zimage' command to use it.
It also adds a new string-substition feature to allow bootargs to be a
template, rather than having to build it up piece by piece with
information obtained in a build script.
It also updates
We want to add more processing to this function. Before doing so, rename
it to bootm_process_cmdline_env(), which is more generic.
Signed-off-by: Simon Glass
---
common/bootm.c | 4 ++--
include/bootm.h | 4 ++--
test/bootm.c| 10 +-
3 files changed, 9 insertions(+), 9
At present bootm_process_cmdline_env() reads the 'bootargs' variable and
then writes it back afterwards. This is painful for tests, which would
rather use a simple buffer.
It is also useful for zimage to use a buffer, since it does not actually
put the Linux command line in the bootargs variable.
This function will soon do more than just handle the 'silent linux'
feature. As a first step, update it to take a boolean parameter,
indicating whether or not the processing is required.
Signed-off-by: Simon Glass
---
common/bootm.c | 20 ++--
include/bootm.h | 3 ++-
Use the size (including terminator) for in this function, rather than
the length. This is arguably easier to follow, with the coming
refactor.
Signed-off-by: Simon Glass
---
common/bootm.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/common/bootm.c
1 - 100 of 141 matches
Mail list logo