On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> Quite a few boards using this SoC family don't use binman, yet
> CONFIG_BINMAN is enabled for all of them. But the option should only be
> enabled if we expect binman to produce an image. Calling binman when the
> device tree is missing, etc.
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> At present this is checked before the config has been loaded by the
> Makefile, so it doesn't work.
>
> Move the check to later.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> Makefile | 4 +++-
> 1 file changed, 3 inser
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> On rockchip various files that need to be created by binman. It does not
> make sense to enumerate these in the Makefile. They are described in the
> configuration (devicetree) for each board and we can simply run binman
> (always) to generat
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> On mediatek various files that need to be created by binman. It does not
> make sense to enumerate these in the Makefile. They are described in the
> configuration (devicetree) for each board and we can simply run binman
> (always) to generat
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> Fix this line which is over the limit.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> Makefile | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Bin Meng
Hi Igor,
On Tue, 23 Jun 2020 14:40:45 +0300
Igor Opaniuk igor.opan...@gmail.com wrote:
...
> Any chance to get this merged?
I've merged another reworked patch to fix the logo drawing problem.
--
Anatolij
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> This option is used to run arch-specific shell scripts which produce .its
> files which are used to produce FIT images. We already have binman which
> is designed to produce firmware images. It is more powerful and has tests.
>
> So this opti
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> This causes conflicts on chromebook_link64. Move it to after U-Boot where
> there should be plenty of space.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/x86/dts/u-boot.dtsi | 4 ++--
> 1 file changed, 2 insertion
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> At present the image layout is not correct, since it uses the SDRAM
> address of the 64-bit U-Boot as the ROM address. Fix this.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> configs/chromebook_link64_defconfig | 2 ++
>
Hi Simon,
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> At present this board uses a custom script to produce the .its file.
> Update it to use binman instead. Binman can create all the images that
> are needed.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> Makefi
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> Now that all board use binman instead of this script, drop it.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/arm/mach-rockchip/fit_spl_optee.sh | 84 -
> 1 file changed, 84 deletions(-)
> d
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> At present there is not enough space for U-Boot due to the EFI loader.
> Correct this.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Add patches to partially migrate rockchip to use binman
>
> configs/chromebook_samus_tpl_defc
On Sun, Jun 14, 2020 at 10:58 AM Simon Glass wrote:
>
> This board does not have microcode but at present that is not supported
> by Kconfig nor the binman image layout. Fix both of these.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/x86/Kconfig| 7
> Subject: Re: [PATCH 2/7] usb: ehci-mx6: Add i.MX8 OTG controller support
>
> On 6/29/20 4:13 AM, Peng Fan wrote:
>
> Hi,
>
> > The i.MX8 has two USB controllers: USBOH and USB3. The USBOH reuses
> > previous i.MX6/7. It has same PHY IP as i.MX7ULP but NC registers are
> > same as i.MX7D. So ad
Migrate the ST Microelectronics STUSB160X Type-C controller code in
a generic I2C driver in st/common, based on Linux one in :
drivers/usb/typec/stusb160x.c
This patch simplifies the stm32mp1 board code and allows to reuse
this STUSB160X driver in other boards.
Signed-off-by: Patrick Delaunay
--
PCA9450A I2C address is 0x25. Fix it.
Signed-off-by: Sébastien Szymanski
---
drivers/power/pmic/pmic_pca9450.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/pmic/pmic_pca9450.c
b/drivers/power/pmic/pmic_pca9450.c
index 67a9090200..c0fb78c4cd 100644
--- a/driv
On 6/29/20 10:24 AM, Peng Fan wrote:
[...]
>>> The i.MX8 has two USB controllers: USBOH and USB3. The USBOH reuses
>>> previous i.MX6/7. It has same PHY IP as i.MX7ULP but NC registers are
>>> same as i.MX7D. So add its support in ehci-mx6 driver.
>>>
>>> Also the driver is updated to remove buil
Forwarded Message
Subject: Re: [PATCH 1/1] riscv: use log functions in fdt_fixup
Date: Mon, 29 Jun 2020 15:21:43 +0800
From: Leo Liang
To: Heinrich Schuchardt
On Fri, Jun 26, 2020 at 06:34:43AM +0200, Heinrich Schuchardt wrote:
> Replace printf() and debug() by log_err() and lo
node varaible is used as iterator into ofnode_for_each_subnode()
loop, when exiting of it, node is no more a valid ofnode.
Use dwc3_node instead as parameter of ofnode_valid()
Fixes: ac28e59a574d ("usb: Migrate to support live DT for some driver")
Signed-off-by: Patrice Chotard
---
drivers/usb/
When variable i will become 0, while(i--) loop breaks but variable i will
again decrement to -1 because of i-- and that's why below condition
"if (!i && (r != resp_match_value)" will never execute, So doing "i--"
inside of while() loop solves this problem.
Signed-off-by: Pragnesh Patel
Reviewed-b
Earlier "mmc erase " command reorts Ok but not actually erase the contents
of some SD cards. This series will resolve this issue.
There is still 1 limitation for some SDHC mmc_spi cards:
"mmc erase *blk#* cnt" can not erase only 1 block that means:
=> mmc erase 0x22 1
will not erase the contents
Erase block start address (CMD32) and erase block end address (CMD33)
command will generate R1 response for mmc SPI mode.
R1 response is 1 byte long for mmc SPI, so assign 1 byte as a response
for this commands.
Signed-off-by: Pragnesh Patel
---
drivers/mmc/mmc_spi.c | 2 ++
1 file changed, 2 i
The content of ssr is useful only for erase operations.
This saves erase time.
Signed-off-by: Pragnesh Patel
Reviewed-by: Bin Meng
---
drivers/mmc/mmc.c | 5 +
drivers/mmc/mmc_spi.c | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 620bb93
R1 response is 1 byte long for mmc SPI commands as per the updated
physical layer specification version 7.10.
So correct the resp and resp_size for existing commands
Signed-off-by: Pragnesh Patel
---
drivers/mmc/mmc_spi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/mmc_spi
As per the SD physical layer specification version 7.10, erase
command (CMD38) and stop transmission command (CMD12) will generate
R1b response.
R1b = R1 + busy signal
A non-zero value after the R1 response indicates card is ready for
next command.
Signed-off-by: Pragnesh Patel
---
drivers/mmc
Send status command (CMD13) will send R1 response under SD mode
but R2 response under SPI mode.
R2 response is 2 bytes long, so read 2 bytes for mmc SPI mode
Signed-off-by: Pragnesh Patel
---
drivers/mmc/mmc_spi.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/d
On Mon, 2020-06-29 at 10:42 +0200, Sébastien Szymanski wrote:
> Caution: EXT Email
>
> PCA9450A I2C address is 0x25. Fix it.
>
> Signed-off-by: Sébastien Szymanski
> ---
> drivers/power/pmic/pmic_pca9450.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/p
Always put the controller in reset, then take it out of reset.
This is to make sure controller always in reset state in both SPL and
proper Uboot.
This is preparation for the next patch to poll for reset completion
(rst_comp) bit after reset.
Signed-off-by: Radu Bacrau
Signed-off-by: Ley Foon Ta
On 6/29/20 11:51 AM, Ye Li wrote:
> On Mon, 2020-06-29 at 10:42 +0200, Sébastien Szymanski wrote:
>> Caution: EXT Email
>>
>> PCA9450A I2C address is 0x25. Fix it.
>>
>> Signed-off-by: Sébastien Szymanski
>> ---
>> drivers/power/pmic/pmic_pca9450.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 del
Fixed delay 200us is not working in certain platforms. Change to
poll for reset completion status to have more reliable reset process.
Controller will set the rst_comp bit in intr_status register after
controller has completed its reset and initialization process.
Signed-off-by: Radu Bacrau
Sign
efi_get_variable_common() does not use EFI_ENTRY(). So we should not use
EFI_EXIT() either.
Fixes: 767f6eeb01d3 ("efi_loader: variable: support variable authentication")
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Add support for defining raw fastboot partitions in eMMC by specifying
the offset and size in an environment variable. Optionally, the eMMC
hardware partition number may also be specified.
This makes it possible to e.g. update only part of the eMMC boot
partition, instead of having to write the en
A64 has UART4 but it was in conflict with R_UART of older SoCs (e.g. A23).
This commit adds necessary definitions and checks to use UART4 port on A64.
Signed-off-by: Nazım Gediz Aydındoğmuş
---
arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
arch/arm/mach-sunxi/board.c| 4
arch/
101 - 133 of 133 matches
Mail list logo
