From: Vignesh Raghavendra
Enable I2C and EEPROM related configs for A72 SPL/U-Boot.
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Andreas Dannenberg
Signed-off-by: Lokesh Vutla
---
configs/j721e_evm_a72_defconfig | 4
1 file changed, 4 insertions(+)
diff --git
Print the board name and ver along with the DT Model.
Signed-off-by: Lokesh Vutla
---
board/ti/j721e/evm.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index 7327c96b31..aa2240b852 100644
--- a/board/ti/j721e/evm.c
+++
From: Andreas Dannenberg
Make the wkup_i2c0 module usable across all stages of U-Boot by adding
the needed definitions including the associated pinmux definitions.
Signed-off-by: Andreas Dannenberg
Signed-off-by: Lokesh Vutla
---
.../dts/k3-j721e-common-proc-board-u-boot.dtsi| 8
This series enable I2C and EEPROM support on J721e common processor
board.
Logs: https://pastebin.ubuntu.com/p/HTrQk3VnZm/
Changes since v1:
- Fixed board_is_j721e_som() to use the right apis.
Andreas Dannenberg (3):
ti: common: board_detect: Handle EEPROM probe more gracefully
board: ti:
From: Andreas Dannenberg
Use dm_i2c_probe() rather than i2c_get_chip() when trying to access
board-detection EEPROM devices. This has the advantage of more gracefully
handling the case when the EEPROM is not present by allowing to exit the
function early rather than failing and outputting an
From: Andreas Dannenberg
The TI J721E EVM system on module (SOM), the common processor board, and
the associated daughtercards have on-board I2C-based EEPROMs containing
board config data. Use the board detection infrastructure to do the
following:
1) Parse the J721E SOM EEPROM and populate
On 06.01.2020 22:58, Tom Rini wrote:
> The next thing I'd like to point out is that as part of this release
> we've re-synced with upstream for libfdt
Hello Tom,
Regarding the DTC parser (/scripts/dtc/version_gen.h)
#define DTC_VERSION "DTC 1.4.6-gaadd0b65"
Is this compatible with the
On 06.01.2020 22:58, Tom Rini wrote:
> The next thing I'd like to point out is that as part of this release
> we've re-synced with upstream for libfdt
Hello Tom,
Regarding the DTC parser (/scripts/dtc/version_gen.h)
#define DTC_VERSION "DTC 1.4.6-gaadd0b65"
Is this compatible with the
From: YouMin Chen
Add rk3328-sdram-ddr4-666.dtsi for support ddr4 init.
Signed-off-by: YouMin Chen
Signed-off-by: Kever Yang
---
arch/arm/dts/rk3328-sdram-ddr4-666.dtsi | 216
1 file changed, 216 insertions(+)
create mode 100644
No need to do twice data training for rk3328 ddr sdram, we re-use the
setting for both channel. And adjust the sdram_init properly for correct
init flow.
Signed-off-by: Kever Yang
Signed-off-by: YouMin Chen
---
drivers/ram/rockchip/sdram_rk3328.c | 10 +++---
1 file changed, 3
From: YouMin Chen
update lpddr3 setting for fix init fail about "col error".
Signed-off-by: YouMin Chen
Signed-off-by: Kever Yang
---
arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
On 12/28/19 3:54 PM, Heinrich Schuchardt wrote:
struct efi_configuration_table is naturally packed. There is no need for a
__packed attribute. Hence remove it.
This holds true only on 64bit systems as we defined efi_guid_t to be
8-byte aligned. Instead adjust guidcpy to accept void *. See
From: Sughosh Ganu
Add guidcpy function to copy the source guid to the destination
guid. Use this function instead of memcpy for copying to the
destination guid.
Signed-off-by: Sughosh Ganu
Use void * instead of efi_guid_t * for arguments to allow copying unaligned
GUIDs. The GUIDs of
When we hit a matching GUID we can directly return the text. There is no
need for a check after the loop.
efi_guid_t is defined as 8 byte aligned but GUIDs in packed structures do
not follow this alignment. Do not require the argument of get_guid_text()
to be correctly aligned.
Signed-off-by:
Provide sub-command for efidebug to list configuration tables.
Signed-off-by: Heinrich Schuchardt
---
cmd/efidebug.c | 47 ++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 45ed5be885..78fc649782
Provide sub-command for efidebug to list configuration tables.
Adjust get_guid_text() to accept unaligned GUIDs of configuration
tables.
Heinrich Schuchardt (2):
cmd: efidebug: simplify get_guid_text()
cmd: efidebug: new sub-command tables
cmd/efidebug.c | 72
With gcc9, below warnings are shown:
drivers/serial/usbtty.c: In function 'usbtty_init_strings':
drivers/serial/usbtty.c:590:44: warning: taking address of packed member of
'struct usb_string_descriptor' may result in an unaligned pointer value
[-Waddress-of-packed-member]
590 |
With gcc9, below warnings are shown:
drivers/serial/usbtty.c: In function 'usbtty_init_strings':
drivers/serial/usbtty.c:590:44: warning: taking address of packed member of
'struct usb_string_descriptor' may result in an unaligned pointer value
[-Waddress-of-packed-member]
590 |
Hi Tom, Simon,
On 2020/1/6 下午10:20, Tom Rini wrote:
On Mon, Jan 06, 2020 at 01:47:25PM +0100, Matthias Schoepfer wrote:
Hi!
I have had trouble booting a fitImage packed kernel for dragonboard410c,
which is an ARM64 platform. After days and days of debugging, I found that
the fdt is 4-byte
> Subject: Re: [PATCH 1/3] imx8mn: evk: add README
>
> Hi Peng,
>
> On Mon, Jan 6, 2020 at 5:04 AM Peng Fan wrote:
>
> > +Quick Start
> > +===
> > +- Build the ARM Trusted firmware binary
> > +- Get ddr firmware
>
> I prefer you write "Get firmware-imx package" instead because this is
> Subject: Re: [PATCH 1/3] imx8mn: evk: add README
>
> On 06/01/20 09:04, Peng Fan wrote:
> > Add a README for users to build a workable image.
> >
> > Signed-off-by: Peng Fan
> > ---
> > board/freescale/imx8mn_evk/README | 37
> > +
> > 1 file changed, 37
Hi Tom,
On Mon, Jan 6, 2020 at 12:20 PM Fabio Estevam wrote:
> I don't have the U-Boot proper fix yet, so I think this patch can wait
> and go into 2020.04.
I managed to fix the card detection problem in U-Boot proper and have
just sent a patch series.
Thanks
Hi Joe,
On Wed, Dec 11, 2019 at 8:54 AM Schrempf Frieder
wrote:
>
> On 11.10.19 01:00, Soeren Moch wrote:
> > Using a MAC address from ROM storage is the normal case for most
> > ethernet hardware. Why should we warn about this?
> >
> > Signed-off-by: Soeren Moch
>
> Some months ago I came up
Hi Peng,
On Tue, Dec 17, 2019 at 12:46 PM Fabio Estevam wrote:
>
> Hi Peng,
>
> I am trying to boot the latest U-Boot mainline on a imx8qxp mek board
> and this is what I get:
>
> U-Boot SPL 2020.01-rc5-1-g3dd6a9300b-dirty (Dec 17 2019 - 12:33:57 -0300)
> Normal Boot
> WDT: Not found!
>
When no GPIO is used to read the card detect status the following
error is seen:
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... MMC: no card present
*** Warning - No block device, using default
imx6ul-14x14-evk does not have a GPIO dedicated for reading the card
detect pin on the eSDHC2 port. In such cases the "broken-cd" property
must be passed, otherwise the card cannot be detected.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx6ul-14x14-evk.dtsi | 1 +
1 file changed, 1
Fix:
>>> CID 280902: Control flow issues (MISSING_BREAK)
>>> The case for value "VIDEO_BPP32" is not terminated
>>> by a 'break' statement.
Reported-by: Tom Rini
Signed-off-by: Anatolij Gustschin
---
drivers/video/vidconsole-uclass.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Mon, Jan 06, 2020 at 09:58:47PM +0100, Stefan Bosch wrote:
> This patch adds support for SAMSUNG's ARM Cortex-A9 based S5P4418 SoC,
> especially FriendlyARM's NanoPi2 and NanoPC-T2 boards. It is based on
> https://github.com/friendlyarm/u-boot/tree/nanopi2-v2016.01. For v2016.01 I
> have also
This patch adds support for SAMSUNG's ARM Cortex-A9 based S5P4418 SoC,
especially FriendlyARM's NanoPi2 and NanoPC-T2 boards. It is based on
https://github.com/friendlyarm/u-boot/tree/nanopi2-v2016.01. For
v2016.01 I have also made a working SPL (FriendlyARM U-Boot is using a
closed source
Hey all,
It's once again release day. While we've had a few things pop up near
the end of the cycle I think we've got things handled well enough. In
fact, I'm going to be open to doing, if needed, a v2020.01.y, with a
fairly strict set of rules, if we have problems arise that can be safely
Hi Thomas,
> From: Thomas Hebb
> Sent: samedi 21 décembre 2019 03:04
>
> The main prompt for this (defined in /Kconfig) is visible at all times, which
> means
> there's no reason to have an additional, machine-specific prompt to set the
> same
> option.
>
> Signed-off-by: Thomas Hebb
Yes,
On Thu, Dec 19, 2019 at 12:32:09PM +, Andre Przywara wrote:
> On Thu, 19 Dec 2019 12:43:35 +0100
> Marek Vasut wrote:
>
> Hi Marek,
>
> > On 12/19/19 12:36 PM, Andre Przywara wrote:
> > > On Thu, 19 Dec 2019 09:04:32 +0100
> > > Marek Vasut wrote:
> > >> On 12/19/19 2:23 AM, André Przywara
On Thu, Dec 26, 2019 at 12:18:31AM +, Alex Nemirovsky wrote:
> Hi Tom,
>
> Hope you are doing well and enjoying the holiday season.
>
> Cortina Access management has decided that we want to add formal upstream
> support of u-boot
> going forward for our line of SoCs and evaluation boards
Currently the following SPL hang is observed:
U-Boot SPL 2020.01-rc5-00079-g797eee36a1 (Jan 06 2020 - 11:24:09 -0300)
Trying to boot from MMC1
Card did not respond to voltage select!
spl: mmc
On Mon, Jan 06, 2020 at 04:22:02PM +0100, Matthias Schoepfer wrote:
> Hi Tom,
>
> thanks for your reply. As far as I can understand this code, only if
> fdt_high is set to 0x (which is the very case for
> dragonboard410c) a not aligned mapping of the fdt can happen.
> In this
Hi Tom,
thanks for your reply. As far as I can understand this code, only if
fdt_high is set to 0x (which is the very case for
dragonboard410c) a not aligned mapping of the fdt can happen.
In this case, the address is images->ft_addr, which I *think* comes from
the fitImage
Hi Tom,
On Mon, Jan 6, 2020 at 12:06 PM Tom Rini wrote:
> Should this come in for the 2020.01 release then? Thanks!
I don't have the U-Boot proper fix yet, so I think this patch can wait
and go into 2020.04.
Thanks
On Mon, Jan 06, 2020 at 11:26:06AM -0300, Fabio Estevam wrote:
> Currently the following SPL hang is observed:
>
> U-Boot SPL 2020.01-rc5-00079-g797eee36a1 (Jan 06 2020 - 11:24:09 -0300)
>
> Trying to boot from MMC1
>
> Card did
Hi Jagan,
Am 2019-12-18 15:47, schrieb Jagan Teki:
On Wed, Dec 18, 2019 at 4:40 AM Michael Walle wrote:
This is a port of the kernel's spi-nxp-fspi driver. It uses the new
spi-mem interface and does not expose the more generic spi-xfer
interface. The source was taken from the v5.3-rc3 tag.
Currently the following SPL hang is observed:
U-Boot SPL 2020.01-rc5-00079-g797eee36a1 (Jan 06 2020 - 11:24:09 -0300)
Trying to boot from MMC1
Card did not respond to voltage select!
spl: mmc
This commit add test unit for aes196 and aes256.
Signed-off-by: Philippe Reynes
---
test/lib/test_aes.c | 4
1 file changed, 4 insertions(+)
Changelog:
v4:
- no change
v3:
- new patch in this serie (in the previous version, the test to
aes was added to pytest, now, we add test unit for
Until now, we only support aes128. This commit add the support
of aes192 and aes256.
Signed-off-by: Philippe Reynes
---
arch/arm/mach-tegra/tegra20/crypto.c | 41 ++-
cmd/aes.c| 38 --
include/uboot_aes.h | 34
This commit add test unit for aes128.
Signed-off-by: Philippe Reynes
---
test/lib/Makefile | 1 +
test/lib/test_aes.c | 162
2 files changed, 163 insertions(+)
create mode 100644 test/lib/test_aes.c
Changelog:
v4:
- Put test/ headers at
In the code, we use the size of the key for the
size of the block. It's true when the key is 128 bits,
but it become false for key of 192 bits and 256 bits.
So to prepare the support of aes192 and 256,
we introduce a constant for the iaes block size.
Signed-off-by: Philippe Reynes
---
This serie add the support of aes192 and aes256.
This first commit clean a bit the code, and introduce
a constant for the block (instead of using the key size).
The second commit add the support of aes192 and aes256
to the lib and the cmd and update the code of crypto
for tegra20. The third add a
On Mon, Jan 06, 2020 at 01:47:25PM +0100, Matthias Schoepfer wrote:
> Hi!
>
> I have had trouble booting a fitImage packed kernel for dragonboard410c,
> which is an ARM64 platform. After days and days of debugging, I found that
> the fdt is 4-byte aligned. But within the linux kernel,
>
On 12/27/19 8:53 AM, Jagan Teki wrote:
> Hi Marek,
>
> On Thu, Oct 3, 2019 at 6:30 PM Marek Vasut wrote:
>>
>> Convert the designware watchdog timer driver to DM and add DT probing
>> support. Perform minor coding style clean up, like drop superfluous
>> braces. There ought to be no functional
Migrate CONFIG_DESIGNWARE_WATCHDOG to Kconfig and update the headers
accordingly, no functional change. The S10 enables the WDT only in
SPL, but does not enable it in U-Boot itself, hence disable it in
the config again.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dalon Westergreen
Cc:
Convert the designware watchdog timer driver to DM and add DT probing
support. Perform minor coding style clean up, like drop superfluous
braces. These ought to be no functional change.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dalon Westergreen
Cc: Dinh Nguyen
Cc: Jagan Teki
Cc: Ley
Add optional support for fetching watchdog clock rate from DT
and ungating reset via reset framework. This is optional as not
all platforms using DW WDT support the clock and reset frameworks
yet.
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dalon Westergreen
Cc: Dinh Nguyen
Cc: Jagan
Not all boards have the same CSB frequency, nor do every SPI slave
necessarily support running at 16.7 MHz. So implement ->set_speed;
that also allows using a smaller PM (i.e., 0) for slaves that do
support a higher speed.
Based on work by Klaus H. Sørensen.
Cc: Klaus H. Sorensen
Signed-off-by:
There are a few problems with the current driver.
First, it unconditionally reads from dout/writes to din whether or not
those pointers are NULL. So for example a simple "sf probe" ends up
writing four bytes at address 0:
=> md.l 0x0 8
: 45454545 45454545 05050505 05050505
Prepare for supporting setting different speeds in mpc8xxx_spi.c.
Signed-off-by: Rasmus Villemoes
---
arch/powerpc/dts/gdsys/mpc8308.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/dts/gdsys/mpc8308.dtsi
b/arch/powerpc/dts/gdsys/mpc8308.dtsi
index
Patch 3/4 is the important one. Without it, reads and writes of
certain lengths from spi-nor fails, and stuff at physical address 0x0
gets overwritten even if no input buffer is supplied (e.g. when
sending a command).
Tested on an mpc8309-derived board. It would be nice if someone with
access to
Currently, max_cs is write-only; it's just set in
mpc8xxx_spi_ofdata_to_platdata and not otherwise used.
My mpc8309 was always resetting during an "sf probe 0". It turns out
dm_gpio_set_dir_flags() was being called with garbage, since nothing
had initialized priv->gpios[0] - our device tree used
On 06/01/20 09:04, Peng Fan wrote:
> Add a README for users to build a workable image.
>
> Signed-off-by: Peng Fan
> ---
> board/freescale/imx8mn_evk/README | 37 +
> 1 file changed, 37 insertions(+)
> create mode 100644 board/freescale/imx8mn_evk/README
>
Reviewed-by: Jun Chen
Simon Glass 於 2020年1月4日 週六 上午6:27寫道：
> We use struct clk here so really should include this header file to avoid
> build errors. Also switch the order of clk.h in the C file to match the
> required code style.
>
> Signed-off-by: Simon Glass
> Reviewed-by: Ley Foon Tan
>
Reviewed-by: Jun Chen
Simon Glass 於 2020年1月4日 週六 上午6:27寫道：
> Some SoCs support a higher speed than what is currently called 'max' in
> this driver. Rename it to 'high' speed, which is the official name of the
> 3.4MHz speed.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
>
Hi,
The U-Boot gpio command always returns the value of the pin, which
is confusing if you are debugging, since calling the command
gpio set pin always results in failure.
The patch modifies the GPIO command to return CMD_RET_SUCCESS
on success and CMD_RET_FAILURE on command failure and
Hi Simon,
I found this commit has style problems reported by checkpatch.pl,
is it better to fix it?
Simon Glass 於 2020年1月4日 週六 上午6:27寫道：
> Convert the obvious uses of i2c bus speeds to use the enum.
>
> Use livetree access for code changes.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes
Use the correct return value in function do_gpio() and update
commands documentation with the return values from command_ret_t enum.
CMD_RET_SUCCESS is returned on command success and CMD_RET_FAILURE is
returned on command failure.
The command was returning the pin value, which caused confusion
Reviewed-by: Jun Chen
Simon Glass 於 2020年1月4日 週六 上午6:27寫道：
> Group these #defines into an enum to make it easier to understand the
> relationship between them.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2: None
>
> drivers/i2c/designware_i2c.c | 2 +-
>
From: Raviteja Narayanam
Corrected the type of eeprom in device tree for zcu216 boards according
to schematic.
Signed-off-by: Raviteja Narayanam
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu216-revA.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Fix shunt resistor value for ina226 vccint_ams and vccint_io_bram_ps.
2mOhm shunt was only in early board revision schematics but never got to
real revA board.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu216-revA.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Hi!
I have had trouble booting a fitImage packed kernel for dragonboard410c,
which is an ARM64 platform. After days and days of debugging, I found
that the fdt is 4-byte aligned. But within the linux kernel,
Documentation/arm64/booting.txt says, fdt must be 8 byte aligned.
If I change the
Hi Rasmus,
> It's possible that the default_environment[] array contains multiple
> entries for the same variable, e.g. a setting from env_default.h based
> on some CONFIG_* variable, and another from
> CONFIG_EXTRA_ENV_SETTINGS. In such a case, the last setting takes
> effect.
>
> Hence, in
On 06/01/20 00:22, Joris Offouga wrote:
> Signed-off-by: Joris Offouga
> ---
> Change v1 -> v2
> Disable usb ethernet support with patch : pico-imx7d: Disable USB_ETHER
> support for bl33
>
> board/technexion/pico-imx7d/pico-imx7d.c | 46
>
On 06/01/20 00:22, Joris Offouga wrote:
> For DM_ETH support , it's require to disable this config.
> When this config is enable, This generate a error with spl in linker script
>
> Signed-off-by: Joris Offouga
> ---
> configs/pico-imx7d_bl33_defconfig | 3 ---
> 1 file changed, 3 deletions(-)
lx2160a rev1 requires layerscape_gen4 device tree fixup and
lx2160a rev2 requires layerscape device tree fixup.
Add device tree fixup for lx2160a based on SoC and Version.
Signed-off-by: Wasim Khan
---
Changes in v4:
remove num-lanes fixup
Changes in v3:
Updated patch subject and description
lx2160a rev1 and rev2 SoC has different pcie controller.
The pcie controller device tree node fields "compatible"
and registers names needs to be updated accordingly.
Enable CONFIG_OF_BOARD_FIXUP to apply board_fix_fdt
which updates the "compatible" and registers names.
Signed-off-by: Wasim Khan
Add Common device tree fixup for NXP SoCs. Based on
SoC and revision call pcie_layerscape or pcie_layerscape_gen4
fixup.
Signed-off-by: Wasim Khan
---
Changes in v4:
1-fix compilation warning with pcie_layerscape_fixup_common.c file
2-Updated NXP copyright
Changes in v3:
fix compilation
Move streamId allocation to layerscape common device tree fixup.
Calculate streamId based on SoC variant.
Signed-off-by: Wasim Khan
---
Changes in v4:None
Changes in v3:None
Changes in v2:None
drivers/pci/pcie_layerscape_fixup.c| 15 +++
lx2160a rev1 PCIe controller uses pcie_layerscape_gen4 driver and
lx2160a rev2 PCIe controller uses pcie_layerscape driver.
This patch set enables support for lx2160a rev2 and uses pcie_layerscape
or pcie_layerscape_gen4 driver based on SoC.
Also organize the device tree fixup in common,
On Mon, Jan 6, 2020 at 7:40 AM Fabio Estevam wrote:
> but here you use the firmware-imx-8.0 version.
>
> According to the "Rev. L4.19.35_1.1.0, 11/2019" i.MX Linux® Release
> Notes the firmware-imx version in this release is
> "firmware-imx-8.5.bin" instead.
Also, in the Yocto recipe the
It's possible that the default_environment[] array contains multiple
entries for the same variable, e.g. a setting from env_default.h based
on some CONFIG_* variable, and another from
CONFIG_EXTRA_ENV_SETTINGS. In such a case, the last setting takes
effect.
Hence, in order to be able to use the
Hi Jagan and Vignesh,
Could you please review this driver. Actually, I don't want to miss this merge
window.
Moreover, Frieder's suggestions are already incorporated and this version of
driver is almost identical to linux version apart from the changes already
mentioned in commit message.
You
Hi Simon,
> Hi Philippe,
>
> On Thu, 31 Oct 2019 at 07:33, Philippe REYNES
> wrote:
>>
>> Hi Simonn
>>
>> > Hi Philippe,
>> >
>> > On Tue, 29 Oct 2019 at 11:29, Philippe Reynes
>> > wrote:
>> >>
>> >> This commit update the aes tests to check the
>> >> aes192 and aes256.
>> >>
>> >>
Hi Peng,
On Mon, Jan 6, 2020 at 5:04 AM Peng Fan wrote:
> +Quick Start
> +===
> +- Build the ARM Trusted firmware binary
> +- Get ddr firmware
I prefer you write "Get firmware-imx package" instead because this is
the real package name and it contains not only DDR related firmware.
As
On 30/12/2019 02.21, Simon Glass wrote:
> Hi Rasmus,
>
> On Wed, 11 Dec 2019 at 04:03, Rasmus Villemoes
> wrote:
>>
>> From: "Klaus H. Sorensen"
>>
>> Allow reading compressed content from fit image, even if
>> CONFIG_SPL_OS_BOOT is not set.
>>
>> This allow booting compressed 2nd stage u-boot
>-Original Message-
>From: Jagan Teki
>Sent: 02 January 2020 10:29
>To: Pragnesh Patel
>Cc: U-Boot-Denx ; Palmer Dabbelt ( Sifive)
>; Atish Patra ; Alexander Graf
>; Boris Brezillon ; Rick Chen
>; Anup Patel
>Subject: Re: [PATCH 3/3] riscv: sifive: fu540: add SPL configuration
>
>+
On Tue, Dec 10, 2019 at 04:56:04PM +0100, Andre Heider wrote:
> On 03/12/2019 09:45, Andre Heider wrote:
> > Changes since v2:
> > * drop "sunxi: board: Use eth_env_set_enetaddr_by_index()" as it breaks
> >compilation without CONFIG_NET
> > * add "sunxi: board: extract creating a unique sid
On 2019/12/21 上午4:28, Thomas Hebb wrote:
In the RK3399 DRAM driver, the function set_ds_odt() supports operating
in two different modes, selected by the ctl_phy_reg argument: when true,
the function reads and writes directly from the DRAM registers, accessed
through "chan->pctl->denali_*";
>-Original Message-
>From: Bin Meng
>Sent: 03 January 2020 20:22
>To: Pragnesh Patel
>Cc: U-Boot Mailing List
>Subject: Re: [PATCH 2/3] riscv: Add FU540 specific includes
>
>Hi Pragnesh,
>
>On Tue, Dec 31, 2019 at 10:00 PM Pragnesh Patel
> wrote:
>>
>> Added headers needed by upcoming
All drivers should be converted to DM already that's why these hardcoded
base addresses are not needed anymore.
Signed-off-by: Michal Simek
---
arch/arm/mach-zynq/include/mach/hardware.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-zynq/include/mach/hardware.h
From: Ashok Reddy Soma
Remove hardcoded base addresses of smc controller and nand controller.
Get those addresses from dt and replace wherever they are used.
Remove smc and nand base address from header file too.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
From: Ashok Reddy Soma
Move the zynq nand driver to driver model. Select DM_MTD if
zynq nand controller (NAND_ZYNQ) is selected.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
drivers/mtd/nand/raw/Kconfig | 1 +
drivers/mtd/nand/raw/zynq_nand.c | 44
Hi,
This series is moving Xilinx Zynq NAND driver to driver model.
It allows us to remove hardcoded base address of smc and nand controller
and get base addresses from device tree.
Thanks,
Michal
Ashok Reddy Soma (2):
zynq: mtd: nand: Move zynq nand driver to driver model
zynq: mtd: nand:
On 10/12/2019 16:56, Andre Heider wrote:
On 03/12/2019 09:45, Andre Heider wrote:
Changes since v2:
* drop "sunxi: board: Use eth_env_set_enetaddr_by_index()" as it breaks
compilation without CONFIG_NET
* add "sunxi: board: extract creating a unique sid into a helper
function"
and use
Follow i.MX, Sunxi, RISC-V and Rockchip to generate u-boot.itb which
includes U-Boot proper, ATF and DTBs in FIT format. ZynqMP supports FIT for
quite a long time but with using out of tree solution. The patch is filling
this gap.
Tested on zcu102, zcu104 and zcu100/Ultra96.
zcu100/Ultra96 v2.2
On 2019/12/30 上午3:07, Jagan Teki wrote:
Add bootcount support for Rockchip rk3399.
The bootcount value is preserved in PMU_SYS_REG0 register,
this would help to support redundent boot.
Once the redundant boot triggers, the altboot command
will look for extlinux-rollback.conf on particular
On 2019/12/30 上午3:07, Jagan Teki wrote:
Add cpu reset cause in common cpu-info file.
This would help to print the reset cause for
various resets.
Right now it support rk3288, rk3399. rest of rockchip
platforms doesn't have reset cause support ye but this
code is more feasible to extend the
On 2019/12/30 上午3:07, Jagan Teki wrote:
Few of the rockchip family SoC atleast rk3288,
rk3399 are sharing some cru register bits so
adding common code between these SoC families
would require to include both cru include files
that indeed resulting function declarations error.
So, create a
On 2019/12/30 上午3:07, Jagan Teki wrote:
RK3288, RK3399 are now support cpu-info, so enable
DISPLAY_CPUINFO by default.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
configs/evb-rk3288_defconfig | 1 -
configs/evb-rk3399_defconfig
Qemu v4.2.0 maps bootmode registers to address space which was the reason
why board_late_init() was disabled and accesses were failing.
With new Qemu board_late_init() can be called without any issue.
Signed-off-by: Michal Simek
---
Changes in v2:
- Remove QEMU version just for versal_virt
Extend test suite to cover also automatic octal/hex converstions which
haven't been implemented in past.
Signed-off-by: Michal Simek
Acked-by: Stephen Warren
Reviewed-by: Simon Goldschmidt
---
Changes in v2:
- Based on discussion with Simon add TODO
Depends on
>-Original Message-
>From: Bin Meng
>Sent: 03 January 2020 20:18
>To: Pragnesh Patel
>Cc: U-Boot Mailing List ; Rick Chen
>; Paul Walmsley ( Sifive) ;
>Palmer Dabbelt ( Sifive) ; Anup Patel
>; Atish Patra ; Sagar Kadam
>
>Subject: Re: [PATCH 1/3] riscv: Add place-holder for FU540 clk and
The reason for this change is just get in sync with board_fdt_blob_setup()
available at lib/fdtdec.c.
Signed-off-by: Michal Simek
---
Changes in v2: None
board/xilinx/common/board.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/xilinx/common/board.c
OF_BOARD and OF_SEPARATE can use board specific board_fdt_blob_setup().
OF_BOARD option is mostly used for picking up DTB from certain location.
OF_SEPARATE option is used when DTB is appended after u-boot binary.
This board specific function is aligned with current version in
lib/fdtdec.c with
Hi,
it is simply series which align board_fdt_blob_setup() with fdtdec with
highest priority on default location where external DTB can be found.
Thanks,
Michal
Changes in v2:
- Fix print messages not to generate compilation warnings on arm32
- Silent all prints
Michal Simek (2):
arm64:
Hi,
On 30. 12. 19 16:14, Tom Rini wrote:
> On Tue, Dec 17, 2019 at 03:41:40PM +0100, Michal Simek wrote:
>> Qemu v4.2.0 maps bootmode registers to address space which was the reason
>> why board_late_init() was disabled and accesses were failing.
>>
>> With new Qemu board_late_init() can be
1 - 100 of 105 matches
Mail list logo
