On Wed, 2020-09-30 at 07:38 +0200, Heiko Schocher wrote:
> Hello mingming,
>
> Am 09.09.2020 um 08:07 schrieb mingming lee:
> > From: Mingming Lee
> >
> > Add MediaTek I2C basic driver
> >
> > Signed-off-by: Mingming Lee
> > ---
> > drivers/i2c/Kconfig | 9 +
> > drivers/i2c/Makefile |
> This patch adds the necessary device tree bindings.
>
> Signed-off-by: Sean Anderson
> Reviewed-by: Simon Glass
> ---
>
> (no changes since v2)
>
> Changes in v2:
> - Convert to use pinmux property
> - Don't hog ISP on boot
> - Re-order GPIOs to match the defaults more closely
>
>
> From: Heinrich Schuchardt
>
> Add a device tree binding for the BOOT button on the Maix board.
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Sean Anderson
> Signed-off-by: Sean Anderson
> ---
> This commit was previously submitted on its own as
>
From: Mingming Lee
Add MediaTek I2C basic driver
Signed-off-by: Mingming Lee
---
Changes for v2:
- using error number defined in include/linux/errno.h
---
drivers/i2c/Kconfig | 9 +
drivers/i2c/Makefile | 1 +
drivers/i2c/mt_i2c.c | 617 +++
3
From: Mingming Lee
add bindings for mediatek i2c driver
Signed-off-by: Mingming Lee
---
doc/device-tree-bindings/i2c/i2c-mtk.txt | 39
1 file changed, 39 insertions(+)
create mode 100644 doc/device-tree-bindings/i2c/i2c-mtk.txt
diff --git
From: Mingming Lee
This patch series adds basic i2c support for MediaTek MT8512 EMMC boards.
---
Changes for v2:
- using error number defined in include/linux/errno.h.
- add Mediatek i2c controller driver to ARM MEDIATEK in MAINTAINERS.
- add bindings for mediatek i2c driver.
Mingming
From: Mingming Lee
add Mediatek i2c controller driver to ARM MEDIATEK.
Signed-off-by: Mingming Lee
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 889a73f15f..cc78561818 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -254,10 +254,12 @@ S:
From: Mingming Lee
Enable MTK I2C
Enable I2C basic command
Signed-off-by: Mingming Lee
---
configs/mt8512_bm1_emmc_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configs/mt8512_bm1_emmc_defconfig
b/configs/mt8512_bm1_emmc_defconfig
index 10a2083134..6b3d9a4e9b 100644
---
From: Haibo Chen
Currently, readl/writel and esdhc_read32/esdhc_write32 are used. To align
the usage, change to only use esdhc_read32/esdhc_write32.
Signed-off-by: Haibo Chen
---
drivers/mmc/fsl_esdhc_imx.c | 64 ++---
1 file changed, 32 insertions(+), 32
Hello Lad,
Am 21.09.2020 um 18:33 schrieb Lad Prabhakar:
This reverts commit 7c8f821e ("i2c: rcar_i2c: Set the
slave address from rcar_i2c_xfer"), as it blindly called
rcar_i2c_set_addr() with read argument always set to 1
during xfer which introduced read errors, whereas
earlier
From: Mingming Lee
add i2c dts node support for mt8512
Signed-off-by: Mingming Lee
---
arch/arm/dts/mt8512-bm1-emmc.dts | 12 ++
arch/arm/dts/mt8512.dtsi | 38 +++-
2 files changed, 49 insertions(+), 1 deletion(-)
diff --git
Hi Tom,
This PR is for -next
Please pull some riscv updates:
- Disable CMD_IRQ for RISC-V.
- Update sipeed/maix doc
- Obtain reg of SiFive RAM via dev_read_addr_index() instead of regmap API.
- Cleans up RISC-V timer drivers and converts them to DM.
- Correctly handle IPIs already pending upon
commit 7c8f821e ("i2c: rcar_i2c: Set the slave address from
rcar_i2c_xfer"), blindly called rcar_i2c_set_addr() with read argument
always set to 1 during xfer which introduced read/write errors, whereas
earlier rcar_i2c_read_common() called rcar_i2c_set_addr() with read set to
1 and
On 9/30/20 11:16 AM, Lad Prabhakar wrote:
[...]
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 4267bbfa5a..e76201df6b 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -211,7 +211,7 @@ static int rcar_i2c_xfer(struct udevice *dev, struct
> i2c_msg
Hi Marek,
Thank you for the review.
On Wed, Sep 30, 2020 at 10:57 AM Marek Vasut wrote:
>
> On 9/30/20 11:16 AM, Lad Prabhakar wrote:
> [...]
> > diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> > index 4267bbfa5a..e76201df6b 100644
> > --- a/drivers/i2c/rcar_i2c.c
> > +++
CONFIG_IS_ENABLED() takes the kconfig name without the CONFIG_ prefix,
e.g. CONFIG_IS_ENABLED(CLK) for CONFIG_CLK. Some of these were being
fixed every now and then, see:
commit 71ba2cb0d678 ("board: stm32mp1: correct CONFIG_IS_ENABLED usage for
LED")
commit a5ada25e4213 ("rockchip: clk:
Dear Tom,
In message <20200929174506.GJ14816@bill-the-cat> you wrote:
>
> One of my worries about updating our hush code would be to maintain
> compatibility with all of the scripts out there that rely on whatever
> odd behavior we have.
Agreed. Unfortunately we never collected any list of
CONFIG_IS_ENABLED() takes the kconfig name without the CONFIG_ prefix,
e.g. CONFIG_IS_ENABLED(CLK) for CONFIG_CLK. Make including the prefix
an error in checkpatch.pl so calls in the wrong format aren't
accidentally reintroduced.
Signed-off-by: Alper Nebi Yasak
---
scripts/checkpatch.pl | 6
Hi Heiko,
Thank you for the review.
On Wed, Sep 30, 2020 at 8:18 AM Heiko Schocher wrote:
>
> Hello Lad,
>
> Am 21.09.2020 um 18:33 schrieb Lad Prabhakar:
> > This reverts commit 7c8f821e ("i2c: rcar_i2c: Set the
> > slave address from rcar_i2c_xfer"), as it blindly called
> >
90
.size = 0x484470
busfreq =264 MHz
bootflags = 0x
intfreq =528 MHz
=> tftp 10 kmcoge5ne/20200930/u-boot.bin
Using ucc@3200 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.1
Filename 'kmcoge5ne/2
Hi guys,
For my graduation I developed my own board to sniff out PLC communication.
Now I'm running into some problems and I was hoping you might be able to
help me out/have some good tips.
As processor I chose a SoM: phycore AM335x
Hi,
I'm following the README
(https://gitlab.denx.de/u-boot/u-boot/-/tree/master/board/freescale/imx8mp_evk)
to bring up u-boot on a imx8mp EVK board. My boot ends up in this on the
console:
U-Boot SPL 2020.10-rc5-00049-gd44d46e9fa (Sep 30 2020 - 11:46:20 +0200)
Normal Boot
WDT:
Add compatible string entry for RZ/G2H (R8A774E1) SoC.
Signed-off-by: Biju Das
Reviewed-by: Lad Prabhakar
---
drivers/spi/renesas_rpc_spi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/renesas_rpc_spi.c b/drivers/spi/renesas_rpc_spi.c
index 844b7f59b7..111528daaa 100644
---
Add compatible string entry for RZ/G2N (R8A774B1) SoC.
Signed-off-by: Biju Das
Reviewed-by: Lad Prabhakar
---
drivers/spi/renesas_rpc_spi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/spi/renesas_rpc_spi.c b/drivers/spi/renesas_rpc_spi.c
index a63390f1b7..844b7f59b7 100644
---
Hi Marek,
Thanks for the feedback.
> Subject: Re: [PATCH 2/2] spi: renesas_rpc_spi: Add compatible string for
> R8A774E1
>
> On 9/30/20 1:13 PM, Biju Das wrote:
> > Add compatible string entry for RZ/G2H (R8A774E1) SoC.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Lad Prabhakar
Em qua., 30 de set. de 2020 às 02:23, Stefan Roese escreveu:
> On 30.09.20 04:14, Otavio Salvador wrote:
> Wouldn't it be better, to add this CONFIG_SILENT_CONSOLE check to
> the console / printf function itself instead of adding it to all
> callers?
I believe in critical errors and like, it is
[BCC'ed TF-A only, migrating to u-boot, including folks involved there]
On 30.09.20 11:20, Yann GAUTIER wrote:
> Hi Jan,
>
> After discussing with my colleagues, it seems there are 2 issues there.
> One patch is missing in U-Boot:
>
On 30.09.20 12:03, Marek Vasut wrote:
> On 9/30/20 11:51 AM, Jan Kiszka wrote:
>> [BCC'ed TF-A only, migrating to u-boot, including folks involved there]
>>
>> On 30.09.20 11:20, Yann GAUTIER wrote:
>>> Hi Jan,
>>>
>>> After discussing with my colleagues, it seems there are 2 issues there.
>>> One
Dear Tom,
In message <20200929185004.GO14816@bill-the-cat> you wrote:
>
> Wolfgang, I was wondering could we not, given the few callers of 'getc'
> carefully change our internal usage / name to 'getchar', which is more
> POSIX-like and have our EXPORT_FUNC line be:
> EXPORT_FUNC(getc, int,
On 9/30/20 11:51 AM, Jan Kiszka wrote:
> [BCC'ed TF-A only, migrating to u-boot, including folks involved there]
>
> On 30.09.20 11:20, Yann GAUTIER wrote:
>> Hi Jan,
>>
>> After discussing with my colleagues, it seems there are 2 issues there.
>> One patch is missing in U-Boot:
>>
On 2020-05-04 12:18, Nandor Han wrote:
Description
---
Add support for reboot-mode configuration using GPIOs and RTC SRAM as
back-end.
Ping. Any comments about this? Can this be applied?
Regards,
Nandor
On 9/30/20 1:13 PM, Biju Das wrote:
> Add compatible string entry for RZ/G2H (R8A774E1) SoC.
>
> Signed-off-by: Biju Das
> Reviewed-by: Lad Prabhakar
> ---
> drivers/spi/renesas_rpc_spi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/spi/renesas_rpc_spi.c
On Thu, Sep 17, 2020 at 06:07:44PM +0200, Heinrich Schuchardt wrote:
> Fix a typo
>
> %s/interract/interact/
>
> Use Samsung's capitalization of their trademarks
>
> %s/onenand/OneNAND/
> %s/Hyperflash/HyperFlash/
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Stefan Roese
With the
Add fallback compatibility string for R-Car Gen3 and RZ/G2.
Also sorted the compatible string as per SoC ID.
Signed-off-by: Biju Das
---
v1->V2:
* Incorporated Marek's review comment
(Ref:-https://patchwork.ozlabs.org/project/uboot/patch/20200930111332.3307-2-biju.das...@bp.renesas.com/)
On Tue, Sep 15, 2020 at 10:44:36AM -0400, Sean Anderson wrote:
> This series adds some additional information to dev_xxx output. This requires
> the first argument to dev_xxx to be a struct udevice. The first argument has
> never been used in U-Boot, so many drivers have some invalid calls. To
On Wed, Sep 30, 2020 at 12:03:06PM +0200, Marek Vasut wrote:
> On 9/30/20 11:51 AM, Jan Kiszka wrote:
> > [BCC'ed TF-A only, migrating to u-boot, including folks involved there]
> >
> > On 30.09.20 11:20, Yann GAUTIER wrote:
> >> Hi Jan,
> >>
> >> After discussing with my colleagues, it seems
From: Michael Trimarchi
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
General features:
- Rockchip PX30
- Up to 2GB DDR4
- eMMC 4 GB expandible
- rest of PX30 features
PX30.Core needs to mount on top of Engicam baseboards for creating
complete platform boards.
Possible
Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive
Evaluation Board.
Genaral features:
- LCD 7" C.Touch
- microSD slot
- Ethernet 1Gb
- Wifi/BT
- 2x LVDS Full HD interfaces
- 3x USB 2.0
- 1x USB 3.0
- HDMI Out
- Mini PCIe
- MIPI CSI
- 2x CAN
- Audio Out
SOM's like PX30.Core
TARGET_EVB_PX30 can be possible to use other px30 boards.
Add the help text for existing EVB, so-that the new boards
which are resuing this config option can mention their board
help text.
This would help to track which boards are using EVB_PX30 config.
Signed-off-by: Jagan Teki
Reviewed-by:
The existing common code for Engicam boards uses i.MX6,
so attach that into i.MX6 Engicam boards so-that adding
new SoC variants of Engicam boards become meaningful.
Add support for it.
Cc: Stefano Babic
Signed-off-by: Jagan Teki
---
Changes for v3:
- new patch
board/engicam/common/Kconfig
Engicam C.TOUCH 2.0 is an EDIMM compliant general purpose
carrier board with capacitive touch interface.
Genaral features:
- TFT 10.1" industrial, 1280x800 LVDS display
- Ethernet 10/100
- Wifi/BT
- USB Type A/OTG
- Audio Out
- CAN
- LVDS panel connector
SOM's like PX30.Core needs to mount on
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
C.TOUCH 2.0 is a general purpose carrier board with capacitive
touch interface support.
PX30.Core needs to mount on top of this Carrier board for creating
complete PX30.Core C.TOUCH 2.0 board.
Add support for it.
Signed-off-by:
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
PX30.Core needs to mount on top of Engicam baseboards for creating
complete platform boards.
Possible baseboards are,
- EDIMM2.2 Starter Kit
- C.TOUCH 2.0
Note: dts patches are in Linux mailing-list.
thanks,
Jagan.
Jagan Teki
On Tue, 29 Sep 2020 at 03:48, Peter Robinson wrote:
>
> The 44758771ee commit removes CONFIG_PREBOOT but actually sets the USE_PREBOOT
> Kconfig option which isn't CONFIG_PREBOOT and is also a bool option which
> means
> we regress because 'usb start' isn't run when expected, it should also be
commit 7c8f821e ("i2c: rcar_i2c: Set the slave address from
rcar_i2c_xfer") blindly called rcar_i2c_set_addr() with read argument
always set to 1 during xfer which introduced read/write errors, whereas
earlier rcar_i2c_read_common() called rcar_i2c_set_addr() with read set to
1 and
On Tue, Sep 29, 2020 at 10:48:14AM +0100, Peter Robinson wrote:
> The 44758771ee commit removes CONFIG_PREBOOT but actually sets the USE_PREBOOT
> Kconfig option which isn't CONFIG_PREBOOT and is also a bool option which
> means
> we regress because 'usb start' isn't run when expected, it should
On Thu, Sep 24, 2020 at 03:57:19PM +0900, Naoki Hayama wrote:
> I suppose 'these' might be 'there'.
>
> Signed-off-by: Naoki Hayama
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
On Tue, Sep 29, 2020 at 02:27:41AM +0200, Heinrich Schuchardt wrote:
> %s/Normlly/Normally/
>
> Signed-off-by: Heinrich Schuchardt
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
On Wed, Sep 23, 2020 at 09:13:51PM +0200, Heinrich Schuchardt wrote:
> We should check if the incoming parameter file_mapping is not NULL instead
> of checking after adding an offset.
>
> Reported-by: Coverity CID 307210
> Signed-off-by: Heinrich Schuchardt
> Acked-by: Thomas Petazzoni
On Tue, Sep 15, 2020 at 10:44:36AM -0400, Sean Anderson wrote:
> This series adds some additional information to dev_xxx output. This requires
> the first argument to dev_xxx to be a struct udevice. The first argument has
> never been used in U-Boot, so many drivers have some invalid calls. To
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam.
EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive
Evaluation Board from Engicam.
PX30.Core needs to mount on top of this Evaluation board for
creating complete PX30.Core EDIMM2.2 Starter Kit.
Add support for it.
This would be useful and recommended boot flow for new boards
which has doesn't have the DDR support yet in mainline.
Sometimes it is very useful for debugging mainline DDR support.
Documen it for px30 boot flow.
Signed-off-by: Jagan Teki
---
Changes for v3, v2:
- no changes
On 9/30/20 10:39 AM, Andre Przywara wrote:
> When we build an arm64 target and enable POSITION_INDEPENDENT, we were
> skipping our build-time dynamic relocation fixup routine (STATIC_RELA).
>
> This was probably done because we didn't need it in this case, as the
> PIE fixup routine in start.S
Hi
I'm trying to wrap my head around the purpose of the following lines in
ft_system_setup():
if (!CONFIG_IS_ENABLED(OPTEE) ||
!tee_find_device(NULL, NULL, NULL, NULL))
stm32_fdt_disable_optee(blob);
My interpretation is "if optee is not running, delete
In the UEFI context we use colored output. When printing truetype letters
we have to interpolate the pixel color between the foreground and
background color according to the gray value of the font pixel.
We could speed up the output a by writing a lookup table in the uclass
whenever a color
Hello Lad,
Am 30.09.2020 um 14:24 schrieb Lad Prabhakar:
commit 7c8f821e ("i2c: rcar_i2c: Set the slave address from
rcar_i2c_xfer") blindly called rcar_i2c_set_addr() with read argument
always set to 1 during xfer which introduced read/write errors, whereas
earlier rcar_i2c_read_common()
On 9/29/20 10:20 PM, Marek Vasut wrote:
> On 9/29/20 10:03 PM, Heinrich Schuchardt wrote:
>> void * can be assigned to any pointer variable. Avoid unnecessary
>> conversions.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> drivers/usb/host/xhci-mem.c | 21 +
>> 1 file
On 9/30/20 2:24 PM, Lad Prabhakar wrote:
> commit 7c8f821e ("i2c: rcar_i2c: Set the slave address from
> rcar_i2c_xfer") blindly called rcar_i2c_set_addr() with read argument
> always set to 1 during xfer which introduced read/write errors, whereas
> earlier rcar_i2c_read_common() called
Hello Lad,
Am 30.09.2020 um 14:24 schrieb Lad Prabhakar:
commit 7c8f821e ("i2c: rcar_i2c: Set the slave address from
rcar_i2c_xfer") blindly called rcar_i2c_set_addr() with read argument
always set to 1 during xfer which introduced read/write errors, whereas
earlier rcar_i2c_read_common()
Am Mittwoch, den 30.09.2020, 17:45 +0200 schrieb Mauro Condarelli:
> Use right shift to avoid 64-bit divisions.
>
> These divisions are needed to convert from file length (potentially
> over 32-bit range) to block number, so result and remainder are
> guaranteed to fit in 32-bit integers.
>
>
On Sat, Sep 26, 2020 at 7:35 PM Peng Fan wrote:
>
> > Subject: Re: IMX8MM 4GiB boundary issue
> >
> > On 9/27/20 2:56 AM, Peng Fan wrote:
> >
> > [...]
> >
> > >>> I can imagine that either the FEC/SDHCI is limited to 32bit
> > >>> addressing in hardware (the DMA can only operate on 32bit range
On Wed, Sep 23, 2020 at 05:05:44PM +0200, Christian Gmeiner wrote:
> Set the defaults on probe for the packet buffer size registers
> for the i210.
>
> The TXPBSIZE register of the i210 resets to its default value only
> at power-on. It doesn't reset if you reboot the system, only if you
> pull
Currently we hard-code the number and initial addresses of QEMU's flash
banks, even though our code is perfectly able to gather the same
information from the DTB provided by QEMU.
This is especially annoying, since we have two slightly different
U-Boot configurations ("bare-metal" vs. loaded via
CONFIG_ARCH_SUPPORT_TFABOOT was used on the qemu-arm64 platform to
guard a tweak to the flash bank configuration. U-Boot now reads the
current flash setup from the devicetree, so there is no need for
this option anymore.
Signed-off-by: Andre Przywara
---
arch/arm/Kconfig | 1 -
1 file changed,
Now that PIE works when U-Boot is started from ROM, let's enable
CONFIG_POSITION_INDEPENDENT, which allows to load U-Boot also via
ARM Trusted-Firmware's fip.bin to DRAM, without tweaking the
configuration.
To get a writable initial stack, we need to keep the fixed initial
stack pointer, which
When the actual offset between link and runtime address is zero, there
is no need for patching up U-Boot early when running with
CONFIG_POSITION_INDEPENDENT.
Skip the whole routine when the distance is 0.
This helps when U-Boot is loaded into ROM, or in otherwise sensitive
memory locations.
On Fri, Jun 05, 2020 at 09:22:54AM +0200, Patrick Delaunay wrote:
> From: Etienne Carriere
>
> Move call to optee_copy_fdt_nodes() introduced by [1] before generic
> changes in kernel FDT so that platform specific changes are not
> overridden by the changes made by this function.
>
> Link: [1]
When we build an arm64 target and enable POSITION_INDEPENDENT, we were
skipping our build-time dynamic relocation fixup routine (STATIC_RELA).
This was probably done because we didn't need it in this case, as the
PIE fixup routine in start.S would take care of that at runtime.
However when we
Currently selecting CONFIG_POSITION_INDEPENDENT also forces us to use an
initial stack pointer relative to the beginning of the BSS section.
This makes some sense, because this should be writable memory anyway.
However the BSS section is not cleared or used until later in the
setup process (after
U-Boot on QEMU-arm64 can be used in two configurations: Loaded directly
via QEMU's -bios option, or as a non-secure payload (BL33) via
ARM Trusted Firmware-A (TF-A).
In the latter case we need to define CONFIG_TFABOOT, to accommodate
the first flash bank being secure only, and manually set
On Wed, Sep 30, 2020 at 05:39:12PM +0100, Andre Przywara wrote:
> U-Boot on QEMU-arm64 can be used in two configurations: Loaded directly
> via QEMU's -bios option, or as a non-secure payload (BL33) via
> ARM Trusted Firmware-A (TF-A).
> In the latter case we need to define CONFIG_TFABOOT, to
On Wed, Sep 30, 2020 at 05:39:17PM +0100, Andre Przywara wrote:
> CONFIG_ARCH_SUPPORT_TFABOOT was used on the qemu-arm64 platform to
> guard a tweak to the flash bank configuration. U-Boot now reads the
> current flash setup from the devicetree, so there is no need for
> this option anymore.
>
>
Hi Vabhav,
On Tue, 29 Sep 2020 at 11:33, Vabhav Sharma wrote:
>
> 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
Hi Yann, Tom and all,
On Wed, 30 Sep 2020 at 15:06, Tom Rini wrote:
>
> On Wed, Sep 30, 2020 at 12:03:06PM +0200, Marek Vasut wrote:
> > On 9/30/20 11:51 AM, Jan Kiszka wrote:
> > > [BCC'ed TF-A only, migrating to u-boot, including folks involved there]
> > >
> > > On 30.09.20 11:20, Yann
On Wed, Sep 30, 2020 at 07:28:42PM +0530, Pratyush Yadav wrote:
> On 24/09/20 10:04AM, Pratyush Yadav wrote:
> > Hi,
> >
> > This series is a re-spin of Jean-Jacques' earlier effort [0], the goal
> > of which was to facilitate porting drivers from the Linux kernel. It
> > adds the managed API,
On Wed, Sep 30, 2020 at 02:04:26PM +0300, Nandor Han wrote:
> On 2020-05-04 12:18, Nandor Han wrote:
> > Description
> > ---
> > Add support for reboot-mode configuration using GPIOs and RTC SRAM as
> > back-end.
> >
>
> Ping. Any comments about this? Can this be applied?
Sorry for the
On Wed, Sep 30, 2020 at 02:52:43PM +0800, ub...@andestech.com wrote:
> Hi Tom,
>
> This PR is for -next
>
> Please pull some riscv updates:
>
> - Disable CMD_IRQ for RISC-V.
> - Update sipeed/maix doc
> - Obtain reg of SiFive RAM via dev_read_addr_index() instead of regmap API.
> - Cleans up
On Wed, Sep 30, 2020 at 03:45:07PM +0100, Andre Przywara wrote:
> The CONFIG_TFABOOT option is more about what U-Boot DOES NOT need to do
> than to support some features.
>
> Explain a bit more in the Kconfig help text to avoid misunderstandings.
>
> Signed-off-by: Andre Przywara
Thanks!
On 30.09.20 16:25, Hilliard, George wrote:
On Sep 30, 2020, at 12:20 AM, Stefan Roese wrote:
Hi George,
thanks for the new version. One nitpicking comment below...
On 29.09.20 20:34, George Hilliard wrote:
+ /* Set up CS GPIOs in device tree, if any */
+ if
From: Etienne Carriere
Move call to optee_copy_fdt_nodes() introduced by [1] before generic
changes in kernel FDT so that platform specific changes are not
overridden by the changes made by this function.
Link: [1] commit 6ccb05eae01b ("image: fdt: copy possible optee nodes to a
loaded
Use right shift to avoid 64-bit divisions.
These divisions are needed to convert from file length (potentially
over 32-bit range) to block number, so result and remainder are
guaranteed to fit in 32-bit integers.
Signed-off-by: Mauro Condarelli
---
Changes in v2:
- replace division with right
this work *only* under the assumption block-size is always a power
of 2; I was unable to find where it is enforced.
Alternative strategy would be to use directly the lower-level do_div(),
or the lldiv() wrapper instead.
Please review because I did not find a place where it is enforced
that
On Wed, Sep 30, 2020 at 05:45:08PM +0200, Patrick Delaunay wrote:
> From: Etienne Carriere
>
> Move call to optee_copy_fdt_nodes() introduced by [1] before generic
> changes in kernel FDT so that platform specific changes are not
> overridden by the changes made by this function.
>
> Link: [1]
On 24/09/20 10:04AM, Pratyush Yadav wrote:
> Hi,
>
> This series is a re-spin of Jean-Jacques' earlier effort [0], the goal
> of which was to facilitate porting drivers from the Linux kernel. It
> adds the managed API, using the same API as Linux. It also adds support
> for regmap fields.
>
>
On Sep 30, 2020, at 12:20 AM, Stefan Roese wrote:
>
> Hi George,
>
> thanks for the new version. One nitpicking comment below...
>
> On 29.09.20 20:34, George Hilliard wrote:
>>
>> + /* Set up CS GPIOs in device tree, if any */
>> + if (CONFIG_IS_ENABLED(DM_GPIO) &&
Hey Mattias,
In testing the RPi4 8Gb I've run into an interesting crash, not seen
it on either a 4Gb or 2Gb mode, and I'm wondering if you're aware of
it. It occurs with either the latest firmware or one from April 1st.
If I boot without a display connected, so just via serial console, I
see the
> Hey Mattias,
>
> In testing the RPi4 8Gb I've run into an interesting crash, not seen
> it on either a 4Gb or 2Gb mode, and I'm wondering if you're aware of
> it. It occurs with either the latest firmware or one from April 1st.
>
> If I boot without a display connected, so just via serial
The CONFIG_TFABOOT option is more about what U-Boot DOES NOT need to do
than to support some features.
Explain a bit more in the Kconfig help text to avoid misunderstandings.
Signed-off-by: Andre Przywara
---
arch/arm/Kconfig | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff
88 matches
Mail list logo
