[U-Boot] [PATCH v4 3/3] whitelist: Remove "CONFIG_SYS_CCI400_ADDR" from whitelist
This config is depricated and new config SYS_CCI400_OFFSET is introduced in Kconfig Signed-off-by: Ashish Kumar --- v3: This is v3 for https://patchwork.ozlabs.org/patch/731464/ v4: No change scripts/config_whitelist.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index e261d02..c29f8f3 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -2516,7 +2516,6 @@ CONFIG_SYS_CACHE_STASHING CONFIG_SYS_CADMUS_BASE_REG CONFIG_SYS_CBSIZE CONFIG_SYS_CCCR -CONFIG_SYS_CCI400_ADDR CONFIG_SYS_CCSRBAR CONFIG_SYS_CCSRBAR_PHYS CONFIG_SYS_CCSRBAR_PHYS_HIGH -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/3] armv8:fsl-layerscape: Consolidate registers space defination for CCI-400 bus
CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which
provides full cache coherency between two clusters of multi-core
CPUs and I/O coherency for devices and I/O masters.
This patch add new CONFIG defination "SYS_FSL_HAS_CCI400" and
moves existing register space definaton of CCI-400 bus
from immap_lsch2 to fsl_immap, so that it can be used
for both chasis 2 and chasis 3.
"CONFIG_SYS_CCI400_ADDR" is depricated and new SYS_CCI400_OFFSET
is introduced in Kconfig
Signed-off-by: Ashish Kumar
Signed-off-by: Prabhakar Kushwaha
---
v3:
This is v3 for https://patchwork.ozlabs.org/patch/731464/
v4:
Header file included in middle of the file in cpu.c
README | 9
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 13 ++
arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 1 +
arch/arm/cpu/armv8/fsl-layerscape/soc.c| 10 +++--
.../include/asm/arch-fsl-layerscape/immap_lsch2.h | 49 -
board/freescale/ls1012afrdm/ls1012afrdm.c | 4 +-
board/freescale/ls1012aqds/ls1012aqds.c| 4 +-
board/freescale/ls1012ardb/ls1012ardb.c| 3 +-
board/freescale/ls1021aqds/ls1021aqds.c| 9 ++--
include/fsl_immap.h| 51 ++
10 files changed, 94 insertions(+), 59 deletions(-)
diff --git a/README b/README
index c73f6dd..165f403 100644
--- a/README
+++ b/README
@@ -312,6 +312,15 @@ Many of the options are named exactly as the corresponding
Linux
kernel configuration options. The intention is to make it easier to
build a config tool - later.
+- ARM Platform Bus Type(CCI):
+ CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which
+ provides full cache coherency between two clusters of multi-core
+ CPUs and I/O coherency for devices and I/O masters
+
+ CONFIG_SYS_FSL_HAS_CCI400
+
+ Defined For SoC that has cache coherent interconnect
+ CCN-400
The following options need to be configured:
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 5825f9b..1132969 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -84,6 +84,7 @@ config ARCH_LS2080A
config FSL_LSCH2
bool
+ select SYS_FSL_HAS_CCI400
select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_5
select SYS_FSL_SEC_BE
@@ -247,6 +248,15 @@ config QSPI_AHB_INIT
But some QSPI flash size up to 64MBytes, so initialize the QSPI AHB
bus for those flashes to support the full QSPI flash size.
+config SYS_CCI400_OFFSET
+ hex "Offset for CCI400 base"
+ depends on SYS_FSL_HAS_CCI400
+ default 0x309 if ARCH_LS1088A
+ default 0x18 if FSL_LSCH2
+ help
+ Offset for CCI400 base
+ CCI400 base addr = CCSRBAR + CCI400_OFFSET
+
config SYS_FSL_IFC_BANK_COUNT
int "Maximum banks of Integrated flash controller"
depends on ARCH_LS1043A || ARCH_LS1046A || ARCH_LS2080A
@@ -254,6 +264,9 @@ config SYS_FSL_IFC_BANK_COUNT
default 4 if ARCH_LS1046A
default 8 if ARCH_LS2080A
+config SYS_FSL_HAS_CCI400
+ bool
+
config SYS_FSL_HAS_DP_DDR
bool
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index c6fede3..ec58065 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index aee1ffa..ddb7d82 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -285,7 +286,8 @@ static void erratum_a008850_early(void)
{
#ifdef CONFIG_SYS_FSL_ERRATUM_A008850
/* part 1 of 2 */
- struct ccsr_cci400 __iomem *cci = (void *)CONFIG_SYS_CCI400_ADDR;
+ struct ccsr_cci400 __iomem *cci = (void *)(CONFIG_SYS_IMMR +
+ CONFIG_SYS_CCI400_OFFSET);
struct ccsr_ddr __iomem *ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR;
/* Skip if running at lower exception level */
@@ -304,7 +306,8 @@ void erratum_a008850_post(void)
{
#ifdef CONFIG_SYS_FSL_ERRATUM_A008850
/* part 2 of 2 */
- struct ccsr_cci400 __iomem *cci = (void *)CONFIG_SYS_CCI400_ADDR;
+ struct ccsr_cci400 __iomem *cci = (void *)(CONFIG_SYS_IMMR +
+ CONFIG_SYS_CCI400_OFFSET);
struct ccsr_ddr __iomem *ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR;
u32 tmp;
@@ -439,7 +442,8 @@ int setup_chip_volt(void)
void fsl_lsch2_early_init_f(void)
{
- struct ccsr_cci400 *cci = (struct ccsr_cci400 *)
[U-Boot] [PATCH v4 2/3] armv7: Consolidate registers space defination for CCI-400 bus
CoreLink Cache Coherent Interconnect (CCI) is ARM BUS which
provides full cache coherency between two clusters of multi-core
CPUs and I/O coherency for devices and I/O masters.
This patch add new CONFIG defination "FSL_SYS_HAS_CCI400" and
removes register space definaton of CCI-400 bus from
immap_ls102xa to fsl_immap, since same is defined there already
"CONFIG_SYS_CCI400_ADDR" is depricated and new SYS_CCI400_OFFSET
is introduced in Kconfig
Signed-off-by: Ashish Kumar
---
v3:
This is v3 for https://patchwork.ozlabs.org/patch/731464/
v4:
No change
arch/arm/cpu/armv7/ls102xa/Kconfig| 12 ++
arch/arm/cpu/armv7/ls102xa/soc.c | 3 +-
arch/arm/include/asm/arch-ls102xa/config.h| 1 -
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 49 +--
4 files changed, 16 insertions(+), 49 deletions(-)
diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index 6a013b2..61dd522 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -5,6 +5,7 @@ config ARCH_LS1021A
select SYS_FSL_ERRATUM_A009663
select SYS_FSL_ERRATUM_A009942
select SYS_FSL_ERRATUM_A010315
+ select SYS_FSL_HAS_CCI400
select SYS_FSL_SRDS_1
select SYS_HAS_SERDES
select SYS_FSL_DDR_BE if SYS_FSL_DDR
@@ -48,9 +49,20 @@ config SECURE_BOOT
Enable Freescale Secure Boot feature. Normally selected
by defconfig. If unsure, do not change.
+config SYS_CCI400_OFFSET
+ hex "Offset for CCI400 base"
+ depends on SYS_FSL_HAS_CCI400
+ default 0x18
+ help
+ Offset for CCI400 base.
+ CCI400 base addr = CCSRBAR + CCI400_OFFSET
+
config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
+config SYS_FSL_HAS_CCI400
+ bool
+
config SYS_FSL_SRDS_1
bool
diff --git a/arch/arm/cpu/armv7/ls102xa/soc.c b/arch/arm/cpu/armv7/ls102xa/soc.c
index b84a1a6..c043b82 100644
--- a/arch/arm/cpu/armv7/ls102xa/soc.c
+++ b/arch/arm/cpu/armv7/ls102xa/soc.c
@@ -80,7 +80,8 @@ void erratum_a010315(void)
int arch_soc_init(void)
{
struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR;
- struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
+ struct ccsr_cci400 *cci = (struct ccsr_cci400 *)(CONFIG_SYS_IMMR +
+ CONFIG_SYS_CCI400_OFFSET);
unsigned int major;
#ifdef CONFIG_LAYERSCAPE_NS_ACCESS
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index fc954c5..ff0fc47 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -20,7 +20,6 @@
#define SYS_FSL_GIC_ADDR (CONFIG_SYS_IMMR + 0x0040)
#define CONFIG_SYS_FSL_DDR_ADDR(CONFIG_SYS_IMMR +
0x0008)
-#define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR + 0x0018)
#define CONFIG_SYS_FSL_CSU_ADDR (CONFIG_SYS_IMMR + 0x0051)
#define CONFIG_SYS_IFC_ADDR(CONFIG_SYS_IMMR + 0x0053)
#define CONFIG_SYS_FSL_ESDHC_ADDR (CONFIG_SYS_IMMR + 0x0056)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index c34fd63..1415b0b 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -6,6 +6,7 @@
#ifndef __ASM_ARCH_LS102XA_IMMAP_H_
#define __ASM_ARCH_LS102XA_IMMAP_H_
+#include
#define SVR_MAJ(svr) (((svr) >> 4) & 0xf)
#define SVR_MIN(svr) (((svr) >> 0) & 0xf)
@@ -374,53 +375,7 @@ struct ccsr_serdes {
u8 res_a00[0x1000-0xa00]; /* from 0xa00 to 0xfff */
};
-#define CCI400_CTRLORD_TERM_BARRIER0x0008
-#define CCI400_CTRLORD_EN_BARRIER 0
-#define CCI400_SHAORD_NON_SHAREABLE0x0002
-#define CCI400_DVM_MESSAGE_REQ_EN 0x0002
-#define CCI400_SNOOP_REQ_EN0x0001
-
-/* CCI-400 registers */
-struct ccsr_cci400 {
- u32 ctrl_ord; /* Control Override */
- u32 spec_ctrl; /* Speculation Control */
- u32 secure_access; /* Secure Access */
- u32 status; /* Status */
- u32 impr_err; /* Imprecise Error */
- u8 res_14[0x100 - 0x14];
- u32 pmcr; /* Performance Monitor Control */
- u8 res_104[0xfd0 - 0x104];
- u32 pid[8]; /* Peripheral ID */
- u32 cid[4]; /* Component ID */
- struct {
- u32 snoop_ctrl; /* Snoop Control */
- u32 sha_ord;/* Shareable Override */
- u8 res_1008[0x1100 - 0x1008];
- u32 rc_qos_ord; /* read channel QoS Value Override */
Re: [U-Boot] [PATCH] arm: omap3: Detect boot mode very early
On 7/25/2017 7:38 AM, Siarhei Siamashka wrote:
> On Fri, 14 Jul 2017 08:53:20 -0500
> Adam Ford wrote:
>
>> Fixes 4bd754d8abef ("arm: omap: Detect boot mode very early") where
>> the intent was to store the boot params information in a known
>> location and pass it to SPL very early. Unfortunately it didn't
>> account for OMAP3 boards.
>>
>> This patch adds adds this functionality back into OMAP3 boards.
>>
>> Reviewed-by: Lokesh Vutla
>> Signed-off-by: Adam Ford
>>
>> diff --git a/arch/arm/mach-omap2/omap3/board.c
>> b/arch/arm/mach-omap2/omap3/board.c
>> index cd8e302..a61b933 100644
>> --- a/arch/arm/mach-omap2/omap3/board.c
>> +++ b/arch/arm/mach-omap2/omap3/board.c
>> @@ -212,6 +212,12 @@ void board_init_f(ulong dummy)
>> {
>> early_system_init();
>> mem_init();
>> +/*
>> +* Save the boot parameters passed from romcode.
>> +* We cannot delay the saving further than this,
>> +* to prevent overwrites.
>> +*/
>> +save_omap_boot_params();
>> }
>> #endif
>>
>
> Hello,
>
> Something seems to be fishy here.
>
> The 4bd754d8abef patch from Lokesh Vutla basically replicated the same
> chunk of code for every OMAP variant rather than keeping it in one
> common location. The justification for this code duplication is that
> the boot parameters may be overwritten. Can we have a bit more details
> about how and when this overwrite actually happens in practice?
ROM stores the boot_params info in SRAM and passed this address to SPL.
For SPL, all the dtb, malloc, stack, and scratch area are in SRAM. There
is high probability that it might override the boot params info. So, we
need to parse this info asap. I did see this is being overwritten on
dra7 evm so I had to introduce this patch. You can always dump R0 at the
beiginning of SPL and compare it with objdump of spl.
>
> I don't quite like the fact that we still have the code, which relies
> on OMAP_SRAM_SCRATCH_BOOT_PARAMS in the "jump_to_image_no_args"
> function very late in the SPL:
I don't think U-Boot uses this information at all, so till now there is
no effect. You can as well not pass anything.
Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/3] rockchip: firefly: Add "usb start" to auto-start USB device
HI leo, Leo Wen wrote on 2017年07月25日 13:53: Add "usb start" to #define PREBOOT,you don't need to input "usb start" in command line of u-boot console,it can auto-start the USB device, after that usb keyboard can work. Change-Id: I40f6d81a6e8478703cb03c44e0f00fc2d26df33a Change-Id should be removed. Signed-off-by: Leo Wen --- include/configs/rk3288_common.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h index ac268cd..23d7389 100644 --- a/include/configs/rk3288_common.h +++ b/include/configs/rk3288_common.h @@ -113,6 +113,6 @@ BOOTENV #endif -#define CONFIG_PREBOOT +#define CONFIG_PREBOOT "usb start" It should not be set in here, it will affect all rockchip bords. You can append "preboot=usb start;" to ROCKCHIP_DEVICE_SETTINGS. https://github.com/rockchip-linux/u-boot/blob/release/include/configs/firefly-rk3288.h#L10 #endif ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image
On 24 July 2017 at 00:41, Tom Rini wrote: > On Sun, Jul 23, 2017 at 11:48:53PM +1000, Bin Chen wrote: > > On 19 July 2017 at 12:53, Tom Rini wrote: > > > > > On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote: > > > > On 18 July 2017 at 22:32, Tom Rini wrote: > > > > > > > > > On Thu, Jul 13, 2017 at 05:33:08PM +1000, Bin Chen wrote: > > > > > > Hi Tom, > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > On 13 July 2017 at 04:25, Tom Rini wrote: > > > > > > > > > > > > > On Tue, Jul 11, 2017 at 03:56:04PM +1000, Bin Chen wrote: > > > > > > > > > > > > > > > It's my understanding that we are supposed to use booti, > instead > > > of > > > > > > > bootm, > > > > > > > > for arm64 image. But booti lacks of android image support. > Bootm > > > has > > > > > > > > the andriod image support but lack of the arm64 image > handling. > > > > > > > > > > > > > > > > So, what is suppose the right way of booting an android arm64 > > > image? > > > > > > > > or, should we create a separate command? > > > > > > > > > > > > > > > > This patch is an invitation for that discussion. > > > > > > > > > > > > > > > > It *hacked* the booti command and it aslo assume the dtb is > in > > > the > > > > > > > second area > > > > > > > > of android boot image. It also has other belives like u-boot > > > should > > > > > be > > > > > > > > in control of where to put the kernnel/ramdisk/dtb images so > it > > > > > ignores > > > > > > > > the value specified in the android images. > > > > > > > > > > > > > > > > Signed-off-by: Bin Chen > > > > > > > > > > > > > > So, booti is very much for the "Image" format described in the > > > Linux > > > > > > > kernel in Documentation/arm64/booting.txt. One can (and > people > > > have) > > > > > > > used bootm on aarch64 for "uImage" style kernels and FIT > kernels, > > > and I > > > > > > > would see being able to boot an aarch64 Android image with > bootm > > > as the > > > > > > > way to go forward. > > > > > > > > > > > > > > > > > > Are you suggesting that we should use bootm path, instead of > booti? > > > > > > > > > > > > I have two questions regarding this: > > > > > > > > > > > > 1. currently arm64 kernel don't have a uImage kernel target. And > I'm > > > not > > > > > > sure > > > > > > if adding that will be something that is wanted and/or sensible. > > > > > > > > > > There's some confusion here. bootm is not only for "uImage" > kernels. > > > > > It for example handles the aarch32 Android image format. > > > > > > > > > > > 2. bootm path doesn't have the logic that is currently in the > booti, > > > such > > > > > > as the > > > > > > kernel relocation. > > > > > > > > > > Now I'm confused, what is different in an "Android" image for > aarch64 > > > > > than from a standard aarch64 Linux kernel 'Image' ? > > > > > > > > > > > > > Android image wraps the 'Image'. There is a section called “kernel” > in > > > > Android > > > > image, and will place the Image there [1]. Do you think it is the > right > > > way > > > > to do that? > > > > > > > > I think that's the case for aarch32 android image as well, but > replace > > > the > > > > 'Image' with > > > > aarch32 kernel build target - I don't know what the format of that > target > > > > is. > > > > > > > > [1] > > > > https://android.googlesource.com/platform/system/core/+/ > > > master/mkbootimg/bootimg.h > > > > > > > > > > > > > > Also, one other question raised during internal discussion was > why > > > the > > > > > > booti > > > > > > was created in the first place, if we could have had that > > > implemented in > > > > > > the > > > > > > bootm path. > > > > > > > > > > Well, there's some discussion in the archives about this. The > short > > > > > answer is that "bootm" wasn't supposed to become a "figure out > whatever > > > > > this image is, boot it" command. > > > > > > > > > > > > > Good to know the idea beyond that and what bootm isn't supposed to > be. > > > > That helps to decide whether we should stuff things into bootm or > having > > > a > > > > separate one. > > > > > > > > > > > > > In hindsight, now, I'm thinking that the aarch32 Android image > support > > > > > maybe should have gone into "bootandroid" and in turn it would be > > > easier > > > > > to get someone to write a new command, say "bootauto" that would > ask > > > > > bootm/bootelf/bootefi/bootandroid/bootz/booti/etc if it liked the > > > image > > > > > found at $address and if so, boot it, and if not, move on to > checking > > > > > the next type. > > > > > > > > > > > > > That seems the idea what many people agree upon. Not sure how easy > > > > to move aarch32 support out and I don't have a aarch32 platform to > test. > > > > Do you think we'll want to start with aarch64 (considering that may > be > > > the > > > > aarch > > > > for most android phone out there) and have a separate boota(ndroid) > > > command? > > > > > > I think the best path forward today is to make sure that whatever > > > aarch64-Image suppo
[U-Boot] [PATCH] rockchip: use UUID for root partitions
We use to use /dev/mmcbl0p7 as root partition, and pass it
to kernel by cmdline, but the mmc number in kernel in not
fixed, we need to change the bootargs to adapt it from time
to time.
We can use the UUID to fix it, the ID is from:
https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
ARM 32bit: 69dad710-2ce4-4e3c-b16c-21a1d49abed3
ARM 64bit: b921b045-1df0-41c3-af44-4c6f280d3fae
Signed-off-by: Kever Yang
---
include/configs/rockchip-common.h | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/configs/rockchip-common.h
b/include/configs/rockchip-common.h
index 9d183ce..e330cd5 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -28,6 +28,12 @@
#endif
#define CONFIG_RANDOM_UUID
+
+#ifdef CONFIG_ARM64
+#define ROOT_UUID "B921B045-1DF0-41C3-AF44-4C6F280D3FAE;\0"
+#else
+#define ROOT_UUID "69DAD710-2CE4-4E3C-B16C-21A1D49ABED3;\0"
+#endif
#define PARTS_DEFAULT \
"uuid_disk=${uuid_gpt_disk};" \
"name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};" \
@@ -36,7 +42,7 @@
"name=loader2,size=4MB,uuid=${uuid_gpt_loader2};" \
"name=atf,size=4M,uuid=${uuid_gpt_atf};" \
"name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};" \
- "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};\0" \
+ "name=rootfs,size=-,uuid="ROOT_UUID
#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] 2017.05-RC3 hanging on DM3730
My employer is committed to producing product with the DM3730 until mid
2020's. Even if nobody else pushes OMAP3, I am willing to experiment and
try code. If someone has something they need me to try.
Adam
On Jul 24, 2017 10:10 PM, "Siarhei Siamashka"
wrote:
> On Thu, 4 May 2017 18:38:39 -0500
> Adam Ford wrote:
>
> > On Thu, May 4, 2017 at 6:08 PM, Tom Rini wrote:
> > > On Thu, May 04, 2017 at 05:58:47PM -0500, Adam Ford wrote:
> > >> On Thu, May 4, 2017 at 4:27 PM, Tom Rini wrote:
> > >> > On Thu, May 04, 2017 at 04:06:33PM -0500, Adam Ford wrote:
> > >> >
> > >> >> Tom,
> > >> >>
> > >> >> I re-synced my U-boot trunk today and did a clean build and found
> that
> > >> >> SPL isn't able to load U-Boot.
> > >> >>
> > >> >> U-Boot SPL 2017.05-rc3 (May 04 2017 - 15:48:21)
> > >> >>
> > >> >>
> > >> >> I haven't had a chance yet to bisect the issue. Do you know when
> you
> > >> >> plan to do the 2017.05 release? I'd like to try and locate the
> issue
> > >> >> before the final release.
> > >> >
> > >> > I'd like to do the release on Monday. Can you please start
> bisecting?
> > >>
> > >> I bisected it since I won't have time tomorrow or this weekend.
> > >>
> > >> Commit 7584f2e0fb0f ("arm: omap3: Compile clock.c with -marm option to
> > >> unbreak OMAP3530") seems to break the OMAP3630 (DM3730) in that
> > >> nothing boots at all:
> > >>
> > >>(dead)
> > >>
> > >>
> > >> Commit 19a75b8cf8d1("arm: omap3: Bring back ARM errata workaround
> > >> 725233") at least shows some activity, but not enough to do anything:
> > >>
> > >>U-Boot SPL 2017.03-7-g19a75b8 (May 04 2017 - 17:53:10)
> > >>
> > >>(dead)
> > >>
> > >> I am wondering if other OMAP36/37 devices have had any issues?
> > >
> > > My bbXM is working. Can you try and see which of the errata is
> breaking
> > > your particular setup? Thanks!
> >
> > It appears to be a toolchain issue. I use Buildroot which builds
> > everything from scratch. I specify some items like glibc, gcc version,
> > binutils, etc.
> >
> > I am not sure why the removal of "CFLAGS_clock.o += -marm" causes an
> issue.
> >
> > When I built it with Linaro 2016.11 it worked, but that version is
> > tuned for a corex-A9, but it proves the code is ok. Sorry for the
> > noise.
>
> Hello,
>
> It is actually unlikely to be a toolchain issue, but more like
> some racy code in U-boot, which happens to be timing sensitive. As
> the commit message [1] says, it was not a proper fix but a quick and
> dirty workaround. More information is also available in the mailing
> list archive [2].
>
> Anyway, thanks a lot for your feedback. It's good to know that DM3730
> is also affected. Because this clearly rules out any possible impact
> of some Thumb2 errata (OMAP3530 had an old bug ridden Cortex-A8, but
> DM3730 has the latest revision of it).
>
> Right now the OMAP3 clock code has some sort of a timing sensitive
> latent bug and it may potentially blow up on any future toolchain
> update (regardless of the use of the ARM or Thumb2 mode). So it's
> best if somebody finds the root cause and fixes it. But I guess,
> OMAP3 is very old and does not get much love nowadays.
>
>
> 1. http://git.denx.de/?p=u-boot.git;a=commit;h=7584f2e0fb0f
> 2. https://lists.denx.de/pipermail/u-boot/2017-March/283078.html
>
> --
> Best regards,
> Siarhei Siamashka
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] 2017.05-RC3 hanging on DM3730
On Thu, 4 May 2017 18:38:39 -0500
Adam Ford wrote:
> On Thu, May 4, 2017 at 6:08 PM, Tom Rini wrote:
> > On Thu, May 04, 2017 at 05:58:47PM -0500, Adam Ford wrote:
> >> On Thu, May 4, 2017 at 4:27 PM, Tom Rini wrote:
> >> > On Thu, May 04, 2017 at 04:06:33PM -0500, Adam Ford wrote:
> >> >
> >> >> Tom,
> >> >>
> >> >> I re-synced my U-boot trunk today and did a clean build and found that
> >> >> SPL isn't able to load U-Boot.
> >> >>
> >> >> U-Boot SPL 2017.05-rc3 (May 04 2017 - 15:48:21)
> >> >>
> >> >>
> >> >> I haven't had a chance yet to bisect the issue. Do you know when you
> >> >> plan to do the 2017.05 release? I'd like to try and locate the issue
> >> >> before the final release.
> >> >
> >> > I'd like to do the release on Monday. Can you please start bisecting?
> >>
> >> I bisected it since I won't have time tomorrow or this weekend.
> >>
> >> Commit 7584f2e0fb0f ("arm: omap3: Compile clock.c with -marm option to
> >> unbreak OMAP3530") seems to break the OMAP3630 (DM3730) in that
> >> nothing boots at all:
> >>
> >>(dead)
> >>
> >>
> >> Commit 19a75b8cf8d1("arm: omap3: Bring back ARM errata workaround
> >> 725233") at least shows some activity, but not enough to do anything:
> >>
> >>U-Boot SPL 2017.03-7-g19a75b8 (May 04 2017 - 17:53:10)
> >>
> >>(dead)
> >>
> >> I am wondering if other OMAP36/37 devices have had any issues?
> >
> > My bbXM is working. Can you try and see which of the errata is breaking
> > your particular setup? Thanks!
>
> It appears to be a toolchain issue. I use Buildroot which builds
> everything from scratch. I specify some items like glibc, gcc version,
> binutils, etc.
>
> I am not sure why the removal of "CFLAGS_clock.o += -marm" causes an issue.
>
> When I built it with Linaro 2016.11 it worked, but that version is
> tuned for a corex-A9, but it proves the code is ok. Sorry for the
> noise.
Hello,
It is actually unlikely to be a toolchain issue, but more like
some racy code in U-boot, which happens to be timing sensitive. As
the commit message [1] says, it was not a proper fix but a quick and
dirty workaround. More information is also available in the mailing
list archive [2].
Anyway, thanks a lot for your feedback. It's good to know that DM3730
is also affected. Because this clearly rules out any possible impact
of some Thumb2 errata (OMAP3530 had an old bug ridden Cortex-A8, but
DM3730 has the latest revision of it).
Right now the OMAP3 clock code has some sort of a timing sensitive
latent bug and it may potentially blow up on any future toolchain
update (regardless of the use of the ARM or Thumb2 mode). So it's
best if somebody finds the root cause and fixes it. But I guess,
OMAP3 is very old and does not get much love nowadays.
1. http://git.denx.de/?p=u-boot.git;a=commit;h=7584f2e0fb0f
2. https://lists.denx.de/pipermail/u-boot/2017-March/283078.html
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: omap3: Detect boot mode very early
On Fri, 14 Jul 2017 08:53:20 -0500
Adam Ford wrote:
> Fixes 4bd754d8abef ("arm: omap: Detect boot mode very early") where
> the intent was to store the boot params information in a known
> location and pass it to SPL very early. Unfortunately it didn't
> account for OMAP3 boards.
>
> This patch adds adds this functionality back into OMAP3 boards.
>
> Reviewed-by: Lokesh Vutla
> Signed-off-by: Adam Ford
>
> diff --git a/arch/arm/mach-omap2/omap3/board.c
> b/arch/arm/mach-omap2/omap3/board.c
> index cd8e302..a61b933 100644
> --- a/arch/arm/mach-omap2/omap3/board.c
> +++ b/arch/arm/mach-omap2/omap3/board.c
> @@ -212,6 +212,12 @@ void board_init_f(ulong dummy)
> {
> early_system_init();
> mem_init();
> + /*
> + * Save the boot parameters passed from romcode.
> + * We cannot delay the saving further than this,
> + * to prevent overwrites.
> + */
> + save_omap_boot_params();
> }
> #endif
>
Hello,
Something seems to be fishy here.
The 4bd754d8abef patch from Lokesh Vutla basically replicated the same
chunk of code for every OMAP variant rather than keeping it in one
common location. The justification for this code duplication is that
the boot parameters may be overwritten. Can we have a bit more details
about how and when this overwrite actually happens in practice?
I don't quite like the fact that we still have the code, which relies
on OMAP_SRAM_SCRATCH_BOOT_PARAMS in the "jump_to_image_no_args"
function very late in the SPL:
void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
{
typedef void __noreturn (*image_entry_noargs_t)(u32 *);
image_entry_noargs_t image_entry =
(image_entry_noargs_t) spl_image->entry_point;
u32 boot_params = *((u32 *)OMAP_SRAM_SCRATCH_BOOT_PARAMS);
debug("image entry point: 0x%lX\n", spl_image->entry_point);
/* Pass the saved boot_params from rom code */
image_entry((u32 *)boot_params);
}
This code had been introduced by Paul Kocialkowski in the old
patch 60c7c30aa084588ef9746 ("omap-common: Common boot code
OMAP3 support and cleanup") and still exists in U-Boot. And
the commit message from that patch implied that no overwrite of
this OMAP_SRAM_SCRATCH_BOOT_PARAMS data happens during the whole
SPL lifetime:
http://git.denx.de/?p=u-boot.git;a=commitdiff;h=60c7c30aa084588ef974663be3d22a1de7f66cbb
So what's going on? Can Lokesh or Paul comment?
--
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] serial: ns16550: Add RX interrupt buffer support
On Tue, Jul 25, 2017 at 09:18:02AM +0800, Bin Meng wrote: > Hi Tom, > > On Tue, Jul 25, 2017 at 8:44 AM, Tom Rini wrote: > > On Fri, Jul 14, 2017 at 05:25:54PM +0200, Stefan Roese wrote: > > > >> Pasting longer lines into the U-Boot console prompt sometimes leads to > >> characters missing. One problem here is the small 16-byte FIFO of the > >> legacy NS16550 UART, e.g. on x86 platforms. > >> > >> This patch now introduces a Kconfig option to enable RX interrupt > >> buffer support for NS16550 style UARTs. With this option enabled, I was > >> able paste really long lines into the U-Boot console, without any > >> characters missing. > >> > >> Signed-off-by: Stefan Roese > >> Reviewed-by: Simon Glass > >> Cc: Bin Meng > > > > Applied to u-boot/master, thanks! > > I believe Stefan will send a v3 to address my comments. Oh poop, sorry! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] serial: ns16550: Add RX interrupt buffer support
Hi Tom, On Tue, Jul 25, 2017 at 8:44 AM, Tom Rini wrote: > On Fri, Jul 14, 2017 at 05:25:54PM +0200, Stefan Roese wrote: > >> Pasting longer lines into the U-Boot console prompt sometimes leads to >> characters missing. One problem here is the small 16-byte FIFO of the >> legacy NS16550 UART, e.g. on x86 platforms. >> >> This patch now introduces a Kconfig option to enable RX interrupt >> buffer support for NS16550 style UARTs. With this option enabled, I was >> able paste really long lines into the U-Boot console, without any >> characters missing. >> >> Signed-off-by: Stefan Roese >> Reviewed-by: Simon Glass >> Cc: Bin Meng > > Applied to u-boot/master, thanks! > I believe Stefan will send a v3 to address my comments. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] [rfc] support booting arm64 android image
On 24 July 2017 at 00:41, Tom Rini wrote: > On Sun, Jul 23, 2017 at 11:48:53PM +1000, Bin Chen wrote: > > On 19 July 2017 at 12:53, Tom Rini wrote: > > > > > On Wed, Jul 19, 2017 at 12:44:48PM +1000, Bin Chen wrote: > > > > On 18 July 2017 at 22:32, Tom Rini wrote: > > > > > > > > > On Thu, Jul 13, 2017 at 05:33:08PM +1000, Bin Chen wrote: > > > > > > Hi Tom, > > > > > > > > > > > > Thanks for the review. > > > > > > > > > > > > On 13 July 2017 at 04:25, Tom Rini wrote: > > > > > > > > > > > > > On Tue, Jul 11, 2017 at 03:56:04PM +1000, Bin Chen wrote: > > > > > > > > > > > > > > > It's my understanding that we are supposed to use booti, > instead > > > of > > > > > > > bootm, > > > > > > > > for arm64 image. But booti lacks of android image support. > Bootm > > > has > > > > > > > > the andriod image support but lack of the arm64 image > handling. > > > > > > > > > > > > > > > > So, what is suppose the right way of booting an android arm64 > > > image? > > > > > > > > or, should we create a separate command? > > > > > > > > > > > > > > > > This patch is an invitation for that discussion. > > > > > > > > > > > > > > > > It *hacked* the booti command and it aslo assume the dtb is > in > > > the > > > > > > > second area > > > > > > > > of android boot image. It also has other belives like u-boot > > > should > > > > > be > > > > > > > > in control of where to put the kernnel/ramdisk/dtb images so > it > > > > > ignores > > > > > > > > the value specified in the android images. > > > > > > > > > > > > > > > > Signed-off-by: Bin Chen > > > > > > > > > > > > > > So, booti is very much for the "Image" format described in the > > > Linux > > > > > > > kernel in Documentation/arm64/booting.txt. One can (and > people > > > have) > > > > > > > used bootm on aarch64 for "uImage" style kernels and FIT > kernels, > > > and I > > > > > > > would see being able to boot an aarch64 Android image with > bootm > > > as the > > > > > > > way to go forward. > > > > > > > > > > > > > > > > > > Are you suggesting that we should use bootm path, instead of > booti? > > > > > > > > > > > > I have two questions regarding this: > > > > > > > > > > > > 1. currently arm64 kernel don't have a uImage kernel target. And > I'm > > > not > > > > > > sure > > > > > > if adding that will be something that is wanted and/or sensible. > > > > > > > > > > There's some confusion here. bootm is not only for "uImage" > kernels. > > > > > It for example handles the aarch32 Android image format. > > > > > > > > > > > 2. bootm path doesn't have the logic that is currently in the > booti, > > > such > > > > > > as the > > > > > > kernel relocation. > > > > > > > > > > Now I'm confused, what is different in an "Android" image for > aarch64 > > > > > than from a standard aarch64 Linux kernel 'Image' ? > > > > > > > > > > > > > Android image wraps the 'Image'. There is a section called “kernel” > in > > > > Android > > > > image, and will place the Image there [1]. Do you think it is the > right > > > way > > > > to do that? > > > > > > > > I think that's the case for aarch32 android image as well, but > replace > > > the > > > > 'Image' with > > > > aarch32 kernel build target - I don't know what the format of that > target > > > > is. > > > > > > > > [1] > > > > https://android.googlesource.com/platform/system/core/+/ > > > master/mkbootimg/bootimg.h > > > > > > > > > > > > > > Also, one other question raised during internal discussion was > why > > > the > > > > > > booti > > > > > > was created in the first place, if we could have had that > > > implemented in > > > > > > the > > > > > > bootm path. > > > > > > > > > > Well, there's some discussion in the archives about this. The > short > > > > > answer is that "bootm" wasn't supposed to become a "figure out > whatever > > > > > this image is, boot it" command. > > > > > > > > > > > > > Good to know the idea beyond that and what bootm isn't supposed to > be. > > > > That helps to decide whether we should stuff things into bootm or > having > > > a > > > > separate one. > > > > > > > > > > > > > In hindsight, now, I'm thinking that the aarch32 Android image > support > > > > > maybe should have gone into "bootandroid" and in turn it would be > > > easier > > > > > to get someone to write a new command, say "bootauto" that would > ask > > > > > bootm/bootelf/bootefi/bootandroid/bootz/booti/etc if it liked the > > > image > > > > > found at $address and if so, boot it, and if not, move on to > checking > > > > > the next type. > > > > > > > > > > > > > That seems the idea what many people agree upon. Not sure how easy > > > > to move aarch32 support out and I don't have a aarch32 platform to > test. > > > > Do you think we'll want to start with aarch64 (considering that may > be > > > the > > > > aarch > > > > for most android phone out there) and have a separate boota(ndroid) > > > command? > > > > > > I think the best path forward today is to make sure that whatever > > > aarch64-Image suppo
Re: [U-Boot] [U-Boot, 4/5] cmd: Kconfig: Make CMD_UBI select CMD_MTDPARTS
On Wed, Jul 12, 2017 at 04:11:46PM +, karl beldan wrote: > From: Karl Beldan > > Many configs still define CMD_MTDPARTS in their non-Kconfig but > CMD_MTDPARTS has now moved to Kconfig. > > Signed-off-by: Karl Beldan > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 13/14] powerpc, 8xx: fix missing function declarations.
On Thu, Jul 13, 2017 at 03:10:08PM +0200, Christophe Leroy wrote: > Add missing .h and add missing declarations in .h > Declare local functions as static > > Based on warnings reported by 'make C=2' > > Signed-off-by: Christophe Leroy Note that when applying I dropped a few of these fixes as we have differing prototypes on other PowerPC platforms. I've addressed those and will post in a separate short series. Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 03/14] powerpc, timer: Does 8xx specific actions in 8xx cpu_init
On Thu, Jul 13, 2017 at 03:09:48PM +0200, Christophe Leroy wrote: > The actions inside #ifdef CONFIG_8xx in arch/powerpc/lib/time.c > can be performed before, in a 8xx dedicated function. > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 12/14] powerpc: move get_pvr() and get_svr() into C
On Thu, Jul 13, 2017 at 03:10:06PM +0200, Christophe Leroy wrote: > Avoid unnecessary assembly functions when they can easily be written > in C. > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 3/5] ubi: Kconfig: Make MTD_UBI select MTD_PARTITIONS
On Wed, Jul 12, 2017 at 04:11:45PM +, karl beldan wrote: > From: Karl Beldan > > This missing dependency has probably remained under the radar because > MTD_PARTITIONS is still whitelisted. > > Signed-off-by: Karl Beldan > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 09/14] powerpc, 8xx: Move cache function into C files
On Thu, Jul 13, 2017 at 03:10:00PM +0200, Christophe Leroy wrote: > Avoid unnecessary assembly functions when they can easily be written > in C. > > Also remove dc_read() as it is nowhere referenced > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,1/2] moveconfig: Tidy up imply flag parsing
On Mon, Jul 10, 2017 at 02:47:46PM -0600, Simon Glass wrote: > Add an option to specify 'all' to enable all flags. Also print an error > if an unrecognised flag is used. At present it just prints usage > information which is not very helpful. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 01/14] powerpc, 8xx: Simplify brgclk calculation and remove get_brgclk()
On Thu, Jul 13, 2017 at 03:09:44PM +0200, Christophe Leroy wrote: > divider is calculated based on SCCR_DFBRG, with: > SCCR_DFBRG 00 => divider 1 = 1 << 0 > SCCR_DFBRG 01 => divider 4 = 1 << 2 > SCCR_DFBRG 10 => divider 16 = 1 << 4 > SCCR_DFBRG 11 => divider 64 = 1 << 6 > > This can be easily converted to a single shift operation: > divider = 1 << (SCCR_DFBRG * 2) > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,5/5] cmd: Kconfig: Fix CMD_UBIFS dependencies
On Wed, Jul 12, 2017 at 04:11:47PM +, karl beldan wrote: > From: Karl Beldan > > Remove the ARCH_SUNXI and RBTREE dependencies. > CMD_UBIFS already gets RBTREE from CMD_UBI (from MTD_UBI), and should > the first become independant from the latter, there would likely be a > dependency on MTD_UBI anyway. > > Cc: Boris Brezillon > Cc: Jagan Teki > Signed-off-by: Karl Beldan > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,4/4] pinctrl: meson: convert to livetree
On Mon, Jul 10, 2017 at 12:30:06AM +0200, Beniamino Galvani wrote: > Update the Meson pinctrl/gpio driver to support a live device tree. > > Signed-off-by: Beniamino Galvani This does not apply on top of master currently. Should I wait until some other changes land to apply the whole series? Or just 1-3 for now? Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 06/14] powerpc: Remove unneccessary #ifdefs in reginfo
On Thu, Jul 13, 2017 at 03:09:54PM +0200, Christophe Leroy wrote: > reginfo command is calling mpc8xx_reginfo(), mpc85xx_reginfo() > or mpc86xx_reginfo() based on CONFIG_ symbol. > As those 3 functions can't me defined at the same time, let's > rename them print_reginfo() to avoid the #ifdefs > The name is kept generic as it is not at all dependent on > powerpc arch and any other arch could want to also print > such information. > > In addition, as the Makefile compiles cmd/reginfo.c only when > CONFIG_CMD_REGINFO is set, there is no need to enclose the U_BOOT_CMD > definition inside a #ifdef CONFIG_CMD_REGINFO > > Lets all remove the #ifdefs around the U_BOOT_CMD as this > file is only compiled when CONFIG_CMD_REGINFO is defined > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] RFC: moveconfig: Use toolchains from buildman
On Mon, Jul 10, 2017 at 02:47:47PM -0600, Simon Glass wrote: > It is annoying to have to set up and maintain two sets of toolchains, one > for buildman and one for moveconfig. > > Adjust moveconfig to make use to buildman's toolchains. This should make > things easier. > > One missing feature is the ability to specify the toolchain on the command > line with a special environment variable, e.g. CROSS_COMPILE_ARM. I'm not > sure if that is useful, but if it is it could be implemented in buildman. > > Signed-off-by: Simon Glass > Reviewed-by: Philipp Tomsich > Tested-by: Philipp Tomsich Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 6/6] board: ti: am43xx: Add FDT fixup for HS devices
On Mon, Jul 10, 2017 at 02:45:54PM -0500, Andrew F. Davis wrote: > Disable RNG and add TEE to FDT used on HS devices. > > Signed-off-by: Andrew F. Davis Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: omap3: Detect boot mode very early
On Fri, Jul 14, 2017 at 08:53:20AM -0500, Adam Ford wrote:
> Fixes 4bd754d8abef ("arm: omap: Detect boot mode very early") where
> the intent was to store the boot params information in a known
> location and pass it to SPL very early. Unfortunately it didn't
> account for OMAP3 boards.
>
> This patch adds adds this functionality back into OMAP3 boards.
>
> Reviewed-by: Lokesh Vutla
> Signed-off-by: Adam Ford
>
> diff --git a/arch/arm/mach-omap2/omap3/board.c
> b/arch/arm/mach-omap2/omap3/board.c
> index cd8e302..a61b933 100644
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/5] ubi: Kconfig: Fix MTD_UBI selection dependency
On Wed, Jul 12, 2017 at 04:11:43PM +, karl beldan wrote: > From: Karl Beldan > > Remove the ARCH_SUNXI dependency on selection of RBTREE. > > Cc: Boris Brezillon > Cc: Maxime Ripard > Cc: Jagan Teki > Signed-off-by: Karl Beldan > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/5] cmd: Kconfig: Fix a dependency of CMD_MTDPARTS
On Wed, Jul 12, 2017 at 04:11:44PM +, karl beldan wrote: > From: Karl Beldan > > Remove the ARCH_SUNXI dependency. > > Cc: Maxime Ripard > Cc: Jagan Teki > Signed-off-by: Karl Beldan > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] serial: ns16550: Add RX interrupt buffer support
On Fri, Jul 14, 2017 at 05:25:54PM +0200, Stefan Roese wrote: > Pasting longer lines into the U-Boot console prompt sometimes leads to > characters missing. One problem here is the small 16-byte FIFO of the > legacy NS16550 UART, e.g. on x86 platforms. > > This patch now introduces a Kconfig option to enable RX interrupt > buffer support for NS16550 style UARTs. With this option enabled, I was > able paste really long lines into the U-Boot console, without any > characters missing. > > Signed-off-by: Stefan Roese > Reviewed-by: Simon Glass > Cc: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and CMD_UBIFS
On Mon, Jul 24, 2017 at 08:36:02PM -0400, Tom Rini wrote: > The above CONFIG options are in Kconfig, and now have correct depends and > inter-dependencies. Migrate these to configs/ from include/configs/. In the > case of CMD_UBIFS also change it to be a default y if CMD_UBI. > > Signed-off-by: Tom Rini Note that I size-tested this and there's no important deltas, so: Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 5/6] board: ti: am43xx: Add TEE loading and firewall setup
On Mon, Jul 10, 2017 at 02:45:53PM -0500, Andrew F. Davis wrote: > Add support for loading a TEE and setting up firewalled regions to > AM43xx HS boards. > > Signed-off-by: Andrew F. Davis Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,14/14] powerpc: Remove 8260 remainders
On Thu, Jul 13, 2017 at 03:10:10PM +0200, Christophe Leroy wrote:
> commit 2eb48ff7a210d ("powerpc, 8260: remove support for mpc8260")
> removed support for 8260 CPU.
>
> This patch remove some remainders.
>
> Signed-off-by: Christophe Leroy
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 4/6] arm: mach-omap2: am33xx: Add FDT fixup suport for AM33xx/AM43xx boards
On Mon, Jul 10, 2017 at 02:45:52PM -0500, Andrew F. Davis wrote: > Similar to what is done with OMAP5 class boards we need to > perform fixups common to this SoC class, add support for this here > and add HS fixups. > > Signed-off-by: Andrew F. Davis Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 08/14] powerpc, 8xx: Simplifying check_CPU()
On Thu, Jul 13, 2017 at 03:09:58PM +0200, Christophe Leroy wrote: > All complex case have been removed and we now only support > MPC866 and MPC885 families. > > So check_CPU() can be made a lot simpler. > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 11/14] powerpc, 8xx: move cache helper into C
On Thu, Jul 13, 2017 at 03:10:04PM +0200, Christophe Leroy wrote: > Avoid unnecessary assembly functions when they can easily be written > in C. > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,04/14] power, timer: reset TBL before TBU
On Thu, Jul 13, 2017 at 03:09:50PM +0200, Christophe Leroy wrote: > In order to avoid TBU increment due to TBL reaching its max > and wrapping, reset TBL before resetting TBU > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 05/14] powerpc: move set_msr() and get_msr() into .h
On Thu, Jul 13, 2017 at 03:09:52PM +0200, Christophe Leroy wrote: > set_msr() and get_msr() are defined and used twice. > This patch moves them into ppc.h > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] km/ivm: always set ethaddr after reading IVM
On Thu, Jul 13, 2017 at 11:15:40AM +0200, Holger Brunck wrote: > If we rebrand the IVM and ethaddr was set previously we need to change > ethaddr. Otherwise we end up with a wrong MAC adress for the ethernet > interface. > > Cc: Heiko Schocher > Signed-off-by: Holger Brunck Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 2/6] arm: mach-omap2: Factor out common FDT fixup suport
On Mon, Jul 10, 2017 at 02:45:50PM -0500, Andrew F. Davis wrote: > Some of the fixups currently done for OMAP5 class boards are common to > other OMAP family devices, move these to fdt-common.c. > > Signed-off-by: Andrew F. Davis Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 10/14] powerpc, 8xx: move get_immr() into C
On Thu, Jul 13, 2017 at 03:10:02PM +0200, Christophe Leroy wrote: > Avoid unnecessary assembly functions when they can easily be written > in C. > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 07/14] Convert CONFIG_CMD_REGINFO to Kconfig
On Thu, Jul 13, 2017 at 03:09:56PM +0200, Christophe Leroy wrote: > This patch converts CONFIG_CMD_REGINFO to Kconfig > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,02/14] powerpc: get rid of addr_probe()
On Thu, Jul 13, 2017 at 03:09:46PM +0200, Christophe Leroy wrote: > This function has never been used, at least since the beginning > of the git repository > > Signed-off-by: Christophe Leroy Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] km/ivm: allow to set locally administred MAC addresses
On Thu, Jul 13, 2017 at 11:15:41AM +0200, Holger Brunck wrote: > It is possible to flag MAC addresses as locally administred. In this > case they don't need to be unique. This is only allowed for interfaces > which have no connection to the outside. For the TEGR1 board we use > this feature. > > Cc: Heiko Schocher > Signed-off-by: Holger Brunck Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/6] arm: mach-omap2: Move omap5/sec-fxns.c into sec-common.c
On Mon, Jul 10, 2017 at 02:45:49PM -0500, Andrew F. Davis wrote: > TEE loading and firewall setup are common to all omap2 devices, move > these function out of omap5 and into mach-omap2. This allows us > to use these functions from other omap class devices. > > Signed-off-by: Andrew F. Davis Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 3/6] arm: mach-omap2: fdt-common: Add OP-TEE node when firmware node is defined
On Mon, Jul 10, 2017 at 02:45:51PM -0500, Andrew F. Davis wrote: > If a firmware node is already present in the FDT we will fail to create > one and so fail to add our OP-TEE node, make this fixup first check for > a firmware node and then only try to add one if it is not found. > > Signed-off-by: Andrew F. Davis Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Makefile: add dependencies to regenerate u-boot.cfg when lost
On Wed, Jul 05, 2017 at 05:30:40PM +0200, Philipp Tomsich wrote: > When running a 'make clean' or carelessly removing u-boot.cfg, all > future make invocations (until autoconf is regenerated) will print > an error for a missing u-boot.cfg due to missing rules and dependencies. > > This commit adds (i) an explicit rule dependency from all (which will > invokes the configuration checker) to cfg, and (b) adds a rule to > invoke scripts/Makefile.autoconf to regenerate u-boot.cfg. > > Signed-off-by: Philipp Tomsich > Reviewed-by: Simon Glass > Tested-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] dtc: mkimage: Add the possibility to specify DTC
On Sun, Jun 25, 2017 at 09:43:33AM +0200, Emmanuel Vadot wrote: > FreeBSD recently switch to it's BSDL dtc. While it support most of the > features of the GPL one it still lacks the incbin directive. > Add the possibility to specify which dtc we want to use for compiling dts > and generating fit image. > > Signed-off-by: Emmanuel Vadot > Acked-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v2,1/1] meson-gx: reserved memory regions
On Fri, Jun 09, 2017 at 10:13:59PM +0200, xypron.g...@gmx.de wrote: > The Odroid C2 has two GiB of memory with two reserved regions. > reg = <0x0 0x0 0x0 0x100>; > reg = <0x0 0x1000 0x0 0x20>; > > Patch > bfcef28ae4cf (arm: add initial support for Amlogic Meson and > ODROID-C2) provided function dram_init_banksize to reserve the > first 16 MiB of RAM for firmware in function dram_init_banksize > in arch/arm/mach-meson/board.c and defined > CONFIG_NR_DRAM_BANKS = 1. > > With this patch dram_init_banksize is changed to additionally > reserve the 2MiB region for the ARM Trusted Firmware (BL31). > CONFIG_NR_DRAM_BANKS is set to 2. > > Cc: Andreas Färber > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/3] env: Add generic redundant environment implementation
On Wed, Jan 25, 2017 at 06:53:11PM +1000, Fiach Antaw wrote: > All current environments that implement redundancy use almost > identical implementations. This patch implements the env_nand > implementation as a function in env_common, and updates the > env_export function to export an env_nand-style 'flags' field by > default. > > Signed-off-by: Fiach Antaw > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tests: test_dfu.py: Add example udev rule for host_usb_dev_node
On Mon, Aug 29, 2016 at 09:57:01AM -0400, Tom Rini wrote: > If one does not already have a rule to create a custom device node when > a given device enumerates it can be useful to have udev create a > bus path based node to the entry in /dev/bus/usb that was just > enumerated. Given that DFU itself does not require a /dev entry it is a > good idea to provide a rule that will generate one. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/3] env: Switch env_nand, env_mmc and env_ubi to env_import_redund
On Wed, Jan 25, 2017 at 06:53:12PM +1000, Fiach Antaw wrote: > The env_nand, env_mmc and env_ubi implementations all implement > redundancy using an identical serial-number scheme. This commit > migrates them to use the implementation in env_common, which is > functionally identical. > > Signed-off-by: Fiach Antaw > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] tools/fw_env: use fsync to ensure that data is physically stored
On Mon, May 20, 2013 at 09:34:42PM +0200, Michael Heimpold wrote: > Closing a file descriptor does not guarantee that the data has been > successfully saved to disk, as the kernel might defer the write. > > Signed-off-by: Michael Heimpold Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: allow efi_loader code to call EFI interfaces
To implement efi_load_image() for the case of loading an image from a
device path rather than image already loaded into source_buffer, it is
convenient to be able to re-use simple-file-system and efi-file
interfaces. But these are already using EFI_ENTER()/EFI_EXIT(). Allow
entry into EFI interfaces to be recursive, since this greatly simplifies
things.
(And hypothetically this would be needed anyways to allow grub to call
into interfaces installed by something outside of grub.)
Signed-off-by: Rob Clark
---
lib/efi_loader/efi_boottime.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 8735b1f418..a113124708 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -47,6 +47,7 @@ static struct efi_configuration_table __efi_runtime_data
efi_conf_table[2];
* EFI callback entry/exit.
*/
static volatile void *efi_gd, *app_gd;
+static int entry_level = 0;
#endif
/* Called from do_bootefi_exec() */
@@ -61,6 +62,8 @@ void efi_save_gd(void)
void efi_restore_gd(void)
{
#ifdef CONFIG_ARM
+ if (entry_level++)
+ return;
/* Only restore if we're already in EFI context */
if (!efi_gd)
return;
@@ -75,6 +78,8 @@ void efi_restore_gd(void)
efi_status_t efi_exit_func(efi_status_t ret)
{
#ifdef CONFIG_ARM
+ if (--entry_level)
+ return ret;
gd = app_gd;
#endif
--
2.13.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Uboot compatible with board Tegra124-nyan-big (ChromeBook G3 HP 14")
Hey Alexandre, Here is a link to a precompiled and signed non verified uboot for the nyan-big chromebook: https://drive.google.com/file/d/0B3uMpbwOyYIadEtPdVpHV1piWEU/view?usp=sharing This is how you would boot a kernel from an sdcard that had uImage and tegra124-nyan-big.dtb in ext2 formatted partition on /dev/mmcblk1p3 mmc dev 1 ; mmc rescan 1 ; ext2load mmc 1:3 0x8100 uImage ; ext2load mmc 1:3 0x8200 tegra124-nyan-big.dtb ; bootm 0x8100 - 0x8200 Hope that helps On Fri, Jul 21, 2017 at 3:48 AM, Simon Glass wrote: > Hi Alexandre, > > [...] > > >> Hi , My Name is Alexander and i need some tip information about > U-boot > >> Board Nyan-Big to runinng Linux v4.4.x.x. > > > > Can you please resend this to the U-Boot mailing list and cc me? > > > > Thanks, > > Simon > >> > >> > >> I compiled source 4.4.0.70 Ubuntu distribution in chroot environment in > my > >> chormebook Tegra Tk1. > >> After compilation the generated files were the following: > >> > >> > >> > >> [aperfeito@alarm boot]$ ls -l > >> total 24992 > >> -rw-r--r-- 1 root root98874 Jul 13 14:54 config-4.4.70-ARCH > >> -rw-r--r-- 1 root root 8277506 Jul 13 14:54 initrd.img-4.4.70-ARCH > >> -rw-r--r-- 1 root root 2033244 Jul 13 14:54 System.map-4.4.70-ARCH > >> -rw-r--r-- 1 root root 15175680 Jul 13 14:54 vmlinuz-4.4.70-ARCH > >> > >> I also compiled the u-boot-tegra in the same environment in chroot > Ubuntu > >> Xenial distribution these were compiled according to the email of Tom > Warren > >> send before > >> > >> Make 'nyan-big_defconfig' and everything ok as you see below the > >> generated files: > >> > >> > >> [aperfeito@alarm u-boot-tegra]$ ls *.bin > >> u-boot.bin u-boot-dtb-tegra.bin u-boot-nodtb-tegra.bin > >> u-boot-dtb.bin u-boot-nodtb.bin u-boot-tegra.bin > >> > >> Now is the tip I'm asking you: > >> I have two suggestions on how to put this in the KERNEL partition of my > >> USB. > >> My USB has two partitions > >>To 1st. KERNEL Name with 16 megabytes of space dev / sda6 > >>A 2st. ROOFS Name approximately 29 Gigabytes of space where I > worked > >> to compile the UbuntuXenial and Uboot-Tegra srcs kernel as you see in > the > >> email. > >> > >> > >> Sugestion : 1 > >> mkimage -D "-I dts -O dtb -p 2048" -f kernel.its vmlinux.uimg > >> dd if=/dev/zero of=bootloader.bin bs=512 count=1 > >> vbutil_kernel \ > >> --pack vmlinux.kpart \ > >> --version 1 \ > >> --vmlinuz vmlinux.uimg \ > >> --arch arm \ > >> --keyblock kernel.keyblock \ --> How I do This if necessary > >> --signprivate kernel_data_key.vbprivk \ --> How I do This if > >> necessary > >> --config cmdline \ --> TXT file whit this config below > >> --bootloader bootloader.bin > >> > >> kernel.its adjust to files below as given to te src kernel 4.4.0-70 > >> ./arch/arm/boot/dts/tegra124-nyan-blaze.dtb > >> ./arch/arm/boot/dts/tegra124-nyan-big.dtb > >> ___TXT CONFIG FILE > >> __ > >> console=tty1 init=/sbin/init root=PARTUUID=%U/PARTNROFF=1 rootwait rw > >> noinitrd lsm.module_locking=0 ## OR ### > >> initrd=/boot/initrd.img-4.4.0-ARCH console=ttyS0,115200n8 console=tty1 > >> ignore_loglevel earlyprintk cgroup_enable=memory root=/dev/sda7 > >> > >> > >> ### For config line need your sugestion with is the best. > >> > >> > >> Sugestion: 2 > >> > >> I have to copy the kernel, generated initramfs, and dtb to the SDA6 > >> partition and added the following kernel config to > /dev/sda7/roofsparttion > >> :/boot/extlinux/extlinux.conf > >> > >> LABEL UbuntuXenial > >> MENU LABEL UbuntuXenial on sda7 with 4.4 kernel > >> LINUX /boot/vmlinuz-4.4.0 > >> FDT /boot/dtb/tegra124-nyan-big.dtb > >> APPEND initrd=/boot/initrd.img-4.4.0-ARCH console=ttyS0,115200n8 > >> console=tty1 ignore_loglevel earlyprintk cgroup_enable=memory > root=/dev/sda7 > >> > >> > >> > >> How to make U-boot-Tegra now Work with Kernel 4.4.x.x as v3.10.x.x > Kernels > >> booting on USB. > > There is a series which shows how to do this for tegra and rockchip. > It is at u-boot-dm/chain-working and you can find a README there as > well. > > The series has not been applied yet - I think it is in Tom Warren's queue? > > Regards, > Simon > [...] > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Fix compile failure encountered on u-boot-usb tree (2017-07-20)
Hi Marek, On Tue, Jul 25, 2017 at 1:32 AM, Marek Vasut wrote: > On 07/24/2017 05:07 PM, patrice.chot...@st.com wrote: >> From: Patrice Chotard >> >> This series fixes : >> _ compilation issue reported by Ran Wang on u-boot-usb branch >> _ add last minute fixes for both generic-ehci and generic_ohci drivers >> which avoid to init a generic PHY if not found, reported by Patrick >> Delaunay >> >> This series need an additionnal patch from Jean-Jacques Hiblot : >> [PATCH v2] phy: add a NO-OP phy driver >> >> >> Patrice Chotard (4): >> dm: phy: add missing #ifdef CONFIG_PHY >> dm: usb: host: xhci-dwc3: add missing #ifdef CONFIG_DM_USB >> usb: host: ehci-generic: initialize PHY only when found >> usb: host: ohci-generic: initialize PHY only when found >> >> drivers/usb/host/ehci-generic.c | 11 ++- >> drivers/usb/host/ohci-generic.c | 11 ++- >> drivers/usb/host/xhci-dwc3.c| 2 ++ >> include/generic-phy.h | 42 >> + >> 4 files changed, 56 insertions(+), 10 deletions(-) >> > Applied all, thanks. > I see these 4 patches are applied on top of u-boot-usb/master directly. I think they should be squashed into Patrice's previous patches, so that we can still maintain bisectablity. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: How to update Espressobin (U-Boot) firmware?
Hi Andre, Just FYI, if you want to build bootloader for SATA boot, please use the ATF build instructions like below: make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 SECURE=0 CLOCKSPRESET=CPU_1000_DDR_800 DDR_TOPOLOGY=2 BOOTDEV=SATA PARTNUM=0 PLAT=a3700 WTP=`pwd`/../A3700-utils-marvell all fip The A3700 bootROM has partition capability, so if you dd the flash-image.bin to a partition with type 0x4d, and the ESPRESSObin is able to find the bootloader at power up. Of course you can dd to LBA0 to make it simpler. Thanks, Benjamin -Original Message- From: André Przywara [mailto:andre.przyw...@arm.com] Sent: Sunday, July 23, 2017 2:06 PM To: Andreas Färber Cc: Kostya Porotchkin ; Thomas Petazzoni ; Benjamin (Guodan) Huang ; Marc Zyngier ; U-Boot ; Stefan Roese Subject: [EXT] Re: How to update Espressobin (U-Boot) firmware? External Email -- On 19/07/17 18:01, Andre Przywara wrote: Hi Andreas, > On 19/07/17 17:58, Andreas Färber wrote: >> Hi, >> >> Am 19.07.2017 um 18:50 schrieb Andre Przywara: >>> On 19/07/17 17:37, Kostya Porotchkin wrote: I probably have to build and try the SATA image as the next step. >>> >>> Yeah, that was my plan for tonight as well, since this would allow me to >>> experiment safely with the generated image. >>> >>> Oh, BTW: Chain-loading mainline U-Boot worked quite nicely and I could >>> launch the generic debian-testing installer via EFI boot. The only issue >>> was that I was using the U-Boot DT directly, which isn't enough for the >>> kernel (missing clocks and interrupts). I will try to send some patches >>> to bring the U-Boot DT in sync with the kernel one. If this is in place, >>> one could simply attach some (UEFI enabled) USB pen drive and it should >>> start without further ado (given a newer U-Boot in the SPI flash with >>> EFI support). >> >> Which devices have you successfully enumerated on mainline U-Boot? Does >> SATA work for you? I had reported an endless reset on another board. USB >> was not quite working either last time I tried on the other board - >> either the initial scan or a reset had similar symptoms to SATA. > > I was using USB (2.0), that worked with origin/master. I haven't tested > SATA yet, but will try tonight and let you know. Quick update: Indeed SATA does not work with mainline U-Boot, I see it probing, but it apparently runs into a timeout. Also MMC (SD card) didn't work for me, I think there was no device detected at all. USB works. This was with chainloading U-Boot, so it might as well be a problem with those devices not being turned off properly and/or the mainline init code not being able to cope with all corner cases (like already initialized devices). All of MMC, USB and SATA work with the Marvell U-Boot version on the SPI flash. Unfortunately I can't do further tests or debugging at the moment (although the build process now seems to work correctly), as I managed to snap off the microUSB socket from my board (while pushing apparently too hard to the SATA cable), so I lost console access and couldn't recover yet. I didn't have success with a 1.8V serial adapter connected to those UART pins on the JTAG header. I will try later to solder a TX and RX wire to the PL2303 chip's pins directly (where I can measure 1.8V in contrast to those JTAG header pins) - but only after my holidays ;-) Cheers, Andre. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Fix compile failure encountered on u-boot-usb tree (2017-07-20)
On 07/24/2017 05:07 PM, patrice.chot...@st.com wrote: > From: Patrice Chotard > > This series fixes : > _ compilation issue reported by Ran Wang on u-boot-usb branch > _ add last minute fixes for both generic-ehci and generic_ohci drivers > which avoid to init a generic PHY if not found, reported by Patrick > Delaunay > > This series need an additionnal patch from Jean-Jacques Hiblot : > [PATCH v2] phy: add a NO-OP phy driver > > > Patrice Chotard (4): > dm: phy: add missing #ifdef CONFIG_PHY > dm: usb: host: xhci-dwc3: add missing #ifdef CONFIG_DM_USB > usb: host: ehci-generic: initialize PHY only when found > usb: host: ohci-generic: initialize PHY only when found > > drivers/usb/host/ehci-generic.c | 11 ++- > drivers/usb/host/ohci-generic.c | 11 ++- > drivers/usb/host/xhci-dwc3.c| 2 ++ > include/generic-phy.h | 42 > + > 4 files changed, 56 insertions(+), 10 deletions(-) > FYI, poplar, dra7xx_evm, evb-rk3328 still have errors. Just try building the entirety of ARM and ARM64 and you'll see them. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] phy: add a NO-OP phy driver
On 07/24/2017 03:18 PM, Jean-Jacques Hiblot wrote:
> This driver is used to stub PHY operations in a driver (USB, SATA).
> This is useful when the 'client' driver (USB, SATA, ...) uses the PHY
> framework and there is no actual PHY harwdare to drive.
>
> Signed-off-by: Jean-Jacques Hiblot
> ---
>
> Even with patch http://patchwork.ozlabs.org/patch/792712 ("dm: phy: add PHY
> stub function"), this patch is still useful because disabling CONFIG_PHY may
> not always be a valid option: another driver may require it.
Applied, thanks.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Fix compile failure encountered on u-boot-usb tree (2017-07-20)
On 07/24/2017 05:07 PM, patrice.chot...@st.com wrote: > From: Patrice Chotard > > This series fixes : > _ compilation issue reported by Ran Wang on u-boot-usb branch > _ add last minute fixes for both generic-ehci and generic_ohci drivers > which avoid to init a generic PHY if not found, reported by Patrick > Delaunay > > This series need an additionnal patch from Jean-Jacques Hiblot : > [PATCH v2] phy: add a NO-OP phy driver > > > Patrice Chotard (4): > dm: phy: add missing #ifdef CONFIG_PHY > dm: usb: host: xhci-dwc3: add missing #ifdef CONFIG_DM_USB > usb: host: ehci-generic: initialize PHY only when found > usb: host: ohci-generic: initialize PHY only when found > > drivers/usb/host/ehci-generic.c | 11 ++- > drivers/usb/host/ohci-generic.c | 11 ++- > drivers/usb/host/xhci-dwc3.c| 2 ++ > include/generic-phy.h | 42 > + > 4 files changed, 56 insertions(+), 10 deletions(-) > Applied all, thanks. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] efi_loader: workaround for grub lsefi bug
On Mon, Jul 24, 2017 at 2:31 PM, Heinrich Schuchardt wrote:
> On 07/20/2017 01:59 PM, Rob Clark wrote:
>> Patch has also been sent to fix grub to not ignore the error returned
>> and treat protocol_buffer_count as valid. But that that might take a
>> while to trickle into distro's, so this workaround might be useful.
>>
>> Signed-off-by: Rob Clark
>> ---
>> lib/efi_loader/efi_boottime.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
>> index 27e51a253f..a45de39919 100644
>> --- a/lib/efi_loader/efi_boottime.c
>> +++ b/lib/efi_loader/efi_boottime.c
>> @@ -637,6 +637,7 @@ static efi_status_t EFIAPI efi_protocols_per_handle(void
>> *handle,
>> {
>> EFI_ENTRY("%p, %p, %p", handle, protocol_buffer,
>> protocol_buffer_count);
>> + *protocol_buffer_count = 0;
>> return EFI_EXIT(EFI_OUT_OF_RESOURCES);
>> }
>>
>>
>
> NAK
>
> We already have this patch waiting to correctly implement
> ProtocolsPerHandle:
>
> efi_loader: implement ProtocolsPerHandle
> https://patchwork.ozlabs.org/patch/787995/
>
> @Rob: Could you, please, test if this patch solves your problem.
>
From a quick look, it looks like it probably should. I mostly sent
this patch so people would have a way to lsefi in grub to see what my
device-path patches where doing.
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 1/1] omap3: incorrect logical check in do_emif4_init - Please, pull.
On 06/25/2017 03:54 PM, Tom Rini wrote: > On Sun, Jun 25, 2017 at 08:13:19AM +0200, Heinrich Schuchardt wrote: > >> Hello Tom, >> >> could you, please, pull the patch >> https://patchwork.ozlabs.org/patch/751043/ >> which has been reviewed in April. > > I actually want to run-test this patch. I happen to have a platform, > and I even set it up the other day, but forgot about this patch. I'll > set it back up and test it, then apply. Thanks! > Hello Tom, any update? Regards Heinrich >> >> Best regards >> >> Heinrich Schuchardt >> >> On 04/16/2017 09:34 PM, Simon Glass wrote: >>> On 15 April 2017 at 08:11, Heinrich Schuchardt wrote: ((readl(&emif4_base->sdram_iodft_tlgc) & (1<<10)) == 0x01) is always false. This does not match the comment /*Wait till that bit clears*/ The problem was indicated by cppcheck. I do not have the hardware to test if the code change below leads to a correct system behavior. Signed-off-by: Heinrich Schuchardt --- arch/arm/mach-omap2/omap3/emif4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> Reviewed-by: Simon Glass >>> >> > > > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] efi_loader: workaround for grub lsefi bug
On 07/20/2017 01:59 PM, Rob Clark wrote:
> Patch has also been sent to fix grub to not ignore the error returned
> and treat protocol_buffer_count as valid. But that that might take a
> while to trickle into distro's, so this workaround might be useful.
>
> Signed-off-by: Rob Clark
> ---
> lib/efi_loader/efi_boottime.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 27e51a253f..a45de39919 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -637,6 +637,7 @@ static efi_status_t EFIAPI efi_protocols_per_handle(void
> *handle,
> {
> EFI_ENTRY("%p, %p, %p", handle, protocol_buffer,
> protocol_buffer_count);
> + *protocol_buffer_count = 0;
> return EFI_EXIT(EFI_OUT_OF_RESOURCES);
> }
>
>
NAK
We already have this patch waiting to correctly implement
ProtocolsPerHandle:
efi_loader: implement ProtocolsPerHandle
https://patchwork.ozlabs.org/patch/787995/
@Rob: Could you, please, test if this patch solves your problem.
Regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] efi_loader: refactor efi_open_protocol
On Mon, Jul 24, 2017 at 1:11 PM, Heinrich Schuchardt wrote:
> On 07/24/2017 11:48 AM, Rob Clark wrote:
>> On Tue, Jul 11, 2017 at 4:06 PM, Heinrich Schuchardt
>> wrote:
>>> efi_open_protocol was implemented to call a protocol specific open
>>> function to retrieve the protocol interface.
>>>
>>> The UEFI specification does not know of such a function.
>>>
>>> It is not possible to implement InstallProtocolInterface with the
>>> current design.
>>>
>>> With the patch the protocol interface itself is stored in the list
>>> of installed protocols of an efi_object instead of an open function.
>>>
>>> Signed-off-by: Heinrich Schuchardt
>>> ---
>>> v2
>>> Remove implementation of efi_return_handle.
>>> ---
>>> cmd/bootefi.c | 14 +++---
>>> include/efi_loader.h | 17 ++---
>>> lib/efi_loader/efi_boottime.c | 18 ++
>>> lib/efi_loader/efi_disk.c | 29 +++--
>>> lib/efi_loader/efi_gop.c | 2 +-
>>> lib/efi_loader/efi_image_loader.c | 8
>>> lib/efi_loader/efi_net.c | 30 +++---
>>> 7 files changed, 26 insertions(+), 92 deletions(-)
>>>
>>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>>> index 7ddeead671..7cf0129a18 100644
>>> --- a/cmd/bootefi.c
>>> +++ b/cmd/bootefi.c
>>> @@ -54,14 +54,6 @@ static struct efi_device_path_file_path
>>> bootefi_device_path[] = {
>>> }
>>> };
>>>
>>> -static efi_status_t EFIAPI bootefi_open_dp(void *handle, efi_guid_t
>>> *protocol,
>>> - void **protocol_interface, void *agent_handle,
>>> - void *controller_handle, uint32_t attributes)
>>> -{
>>> - *protocol_interface = bootefi_device_path;
>>> - return EFI_SUCCESS;
>>> -}
>>> -
>>> /* The EFI loaded_image interface for the image executed via "bootefi" */
>>> static struct efi_loaded_image loaded_image_info = {
>>> .device_handle = bootefi_device_path,
>>> @@ -78,7 +70,7 @@ static struct efi_object loaded_image_info_obj = {
>>> * return handle which points to loaded_image_info
>>> */
>>> .guid = &efi_guid_loaded_image,
>>> - .open = &efi_return_handle,
>>> + .protocol_interface = &loaded_image_info,
>>
>> btw, I probably should have looked at this patchset earlier.. in
>> general, I like it, since it removes a lot of boilerplate. But there
>> are some cases where ->open() allows deferred allocation. For
>> example, I'm working on efi_file and simple-file-system-protocol
>> implementation. A file object can have a device-path accessed by
>> opening device-path protocol. 99% of the time this isn't used, so the
>> ->open() approach lets me defer constructing a file's device-path.
>>
>> How would you feel if I re-introduced ->open() as an optional thing
>> (where the normal case if open is NULL would be to just return
>> protocol_interface)?
>>
>> BR,
>> -R
>>
>
>
> Hello Rob,
>
> a big gap we currently have in the EFI implementation is the missing
> handling of lock entries in OpenProtocol which have to be stored per
> protocol as a list of EFI_OPEN_PROTOCOL_INFORMATION_ENTRYs.
>
> Could you, please, elaborate how OpenProtocolInformation,
> ConnectController, and DisconnectController shall work together with
> your suggested open() approach.
>
> We need be able to iterate efficiently over the
> EFI_OPEN_PROTOCOL_INFORMATION_ENTRYs in these functions.
>
> I fear your proposal will make the code overly complicated here.
>
I guess I'm not too sure what you see the issue would be, but I'm also
unfamiliar with what needs to be implemented.
The patch I sent just (on first OpenProtocol()) calls ->open() to
resolve the actual protocol interface. Afaiu, ->OpenProtocol() always
have to be called first. And ofc it is completely optional. It
avoids having to up-front create the simple-file-system, and avoids
having to construct a device-path for each efi_file object (when it is
almost never accessed).
BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 30/52] rockchip: rk3368: grf: use shifted-constants and prefix with RK3368_
> On 24 Jul 2017, at 19:17, Simon Glass wrote: > > Hi Philipp, > > On 24 July 2017 at 10:49, Dr. Philipp Tomsich > wrote: >> >>> On 24 Jul 2017, at 18:43, Simon Glass wrote: >>> >>> Hi Philipp, >>> >>> On 24 July 2017 at 07:10, Dr. Philipp Tomsich >>> wrote: > On 24 Jul 2017, at 14:45, Kever Yang wrote: > > Hi Philipp, > > > On 07/24/2017 05:11 PM, Dr. Philipp Tomsich wrote: >>> On 24 Jul 2017, at 10:34, Andy Yan wrote: >>> >>> Hi Philipp: >>> >>> >>> On 2017年07月21日 16:34, Dr. Philipp Tomsich wrote: > On 21 Jul 2017, at 05:50, Andy Yan wrote: > > Hi Philipp: > > > On 2017年07月19日 04:36, Philipp Tomsich wrote: >> The RK3368 GRF header was still defines with a shifted-mask but with >> non-shifted function selectors for the IOMUX defines. As the RK3368 >> support is still fresh enough to allow a quick rename, we do this now >> before having more code use this. >> >> As some of the downstream drivers (e.g. the Designware GMAC wrapper) >> may need to include the grf-header of multiple devices, we rename the >> various defines for the RK3368 by prefixing them with the device >> name. >> This avoids future trouble during driver integration. > Is that really necessary to add such a prefix for all the register > definition, just to fit the GMAC dirver? > Maybe the gmac driver can define the platform specific macro in its > own code like dwmac-rk in the kernel. Then we can keep the register > header file a little tidy. The problem is not the GMAC driver (although it was the motivation for doing this change), but rather how easy it is to pick up the wrong grf-file and refer to the wrong definitions/values… the conflicts are not through the GMAC-specifc defines but rather through things like the IOMUX masks or (before I moved this to the DDR-driver) things like the defines to enable DRAM in GRF. Until we find a way to consistently structure things in such a way that (a) common constructs can be shared (e.g. the masks in the IOMUX) (b) specific definitions (e.g. the pin-out for a specific device) is not visible outside of its driver I prefer the names to explicitly refer to each device. That said, the longer-term plan (especially with a larger number of devices being supported) needs to include a consistent rework of how (and where) we manage all these definitions from the grf-header files. >>> It's true that many devices use GRF, we also face this condition in the >>> kernel land.And all the drivers in kernel handle this device specific >>> definition in the driver itself(by of_device_id->data or MACRO). And >>> there is also no need to use the grf constructs, the common syscon api >>> will provide you the grf base address. I think this keeps things >>> simple, we don't need to rely on too much of the grf or cru header, >>> maybe some day we can remove the header file, just as clean as the >>> kernel. >> The problem is not the base-address of GRF, but rather the need to pull >> in the >> register structure (so we can refer to individual registers by name >> instead of by >> hard-coded offset): as we pull this in today, the definitions for the >> various IOMUX >> entries will also be pulled in, which will cause duplicate definitions. > > I really don't like the idea of add the prefix, which end with longer > MACRO but no other improve. > I think the GRF is used mostly for the IOMUX, in this case the better > solution is > port the kernel rockchip-pinctrl driver in uboot, which not rely on the > dtsi instead of header file. > > If we do this, we can remove most of the GRF header definition for IOMUX, > I can ask David Wu > to do this, but maybe few weeks later. As indicated earlier: this is a temporary solution (although we have a local saying that "nothing is more permanent than a temporary solution”) and should remain limited to the RK3368 until we can clean this up across all boards. >>> >>> Can we drop the prefix for now? I do worry about the precedent this >>> sets. If this is needed anywhere then it suggests to me that we have >>> not split up the drivers correctly. We should not be including two >>> different GRF headers into the same file. E.g. there should be >>> different pinctrl drivers for each SoC. >> >> If we drop it, we can’t get RK3368-support merged into the GMAC driver for >> now. >> Splitting the Rockchip-wrapper of the GMAC-driver doesn’t appear like a >> workable >> solution either, as this would create a
Re: [U-Boot] [PATCH 30/52] rockchip: rk3368: grf: use shifted-constants and prefix with RK3368_
Hi Philipp, On 24 July 2017 at 10:49, Dr. Philipp Tomsich wrote: > >> On 24 Jul 2017, at 18:43, Simon Glass wrote: >> >> Hi Philipp, >> >> On 24 July 2017 at 07:10, Dr. Philipp Tomsich >> wrote: >>> >>> On 24 Jul 2017, at 14:45, Kever Yang wrote: Hi Philipp, On 07/24/2017 05:11 PM, Dr. Philipp Tomsich wrote: >> On 24 Jul 2017, at 10:34, Andy Yan wrote: >> >> Hi Philipp: >> >> >> On 2017年07月21日 16:34, Dr. Philipp Tomsich wrote: On 21 Jul 2017, at 05:50, Andy Yan wrote: Hi Philipp: On 2017年07月19日 04:36, Philipp Tomsich wrote: > The RK3368 GRF header was still defines with a shifted-mask but with > non-shifted function selectors for the IOMUX defines. As the RK3368 > support is still fresh enough to allow a quick rename, we do this now > before having more code use this. > > As some of the downstream drivers (e.g. the Designware GMAC wrapper) > may need to include the grf-header of multiple devices, we rename the > various defines for the RK3368 by prefixing them with the device name. > This avoids future trouble during driver integration. Is that really necessary to add such a prefix for all the register definition, just to fit the GMAC dirver? Maybe the gmac driver can define the platform specific macro in its own code like dwmac-rk in the kernel. Then we can keep the register header file a little tidy. >>> The problem is not the GMAC driver (although it was the motivation for >>> doing >>> this change), but rather how easy it is to pick up the wrong grf-file >>> and refer >>> to the wrong definitions/values… the conflicts are not through the >>> GMAC-specifc >>> defines but rather through things like the IOMUX masks or (before I >>> moved >>> this to the DDR-driver) things like the defines to enable DRAM in GRF. >>> >>> Until we find a way to consistently structure things in such a way that >>> (a) common constructs can be shared (e.g. the masks in the IOMUX) >>> (b) specific definitions (e.g. the pin-out for a specific device) is >>> not visible outside of its driver >>> I prefer the names to explicitly refer to each device. >>> That said, the longer-term plan (especially with a larger number of >>> devices >>> being supported) needs to include a consistent rework of how (and where) >>> we manage all these definitions from the grf-header files. >> It's true that many devices use GRF, we also face this condition in the >> kernel land.And all the drivers in kernel handle this device specific >> definition in the driver itself(by of_device_id->data or MACRO). And >> there is also no need to use the grf constructs, the common syscon api >> will provide you the grf base address. I think this keeps things >> simple, we don't need to rely on too much of the grf or cru header, >> maybe some day we can remove the header file, just as clean as the >> kernel. > The problem is not the base-address of GRF, but rather the need to pull > in the > register structure (so we can refer to individual registers by name > instead of by > hard-coded offset): as we pull this in today, the definitions for the > various IOMUX > entries will also be pulled in, which will cause duplicate definitions. I really don't like the idea of add the prefix, which end with longer MACRO but no other improve. I think the GRF is used mostly for the IOMUX, in this case the better solution is port the kernel rockchip-pinctrl driver in uboot, which not rely on the dtsi instead of header file. If we do this, we can remove most of the GRF header definition for IOMUX, I can ask David Wu to do this, but maybe few weeks later. >>> >>> As indicated earlier: this is a temporary solution (although we have a >>> local saying that >>> "nothing is more permanent than a temporary solution”) and should remain >>> limited to >>> the RK3368 until we can clean this up across all boards. >> >> Can we drop the prefix for now? I do worry about the precedent this >> sets. If this is needed anywhere then it suggests to me that we have >> not split up the drivers correctly. We should not be including two >> different GRF headers into the same file. E.g. there should be >> different pinctrl drivers for each SoC. > > If we drop it, we can’t get RK3368-support merged into the GMAC driver for > now. > Splitting the Rockchip-wrapper of the GMAC-driver doesn’t appear like a > workable > solution either, as this would create a new file for each chip-variant in > drivers/net. > > I’ll just pull the RK3368 GMAC (driver) support for now and split it off this > series. My view of GRF is that we should try to have a driver for t
Re: [U-Boot] [PATCH v2 01/12] efi_loader: refactor efi_open_protocol
On 07/24/2017 11:48 AM, Rob Clark wrote:
> On Tue, Jul 11, 2017 at 4:06 PM, Heinrich Schuchardt
> wrote:
>> efi_open_protocol was implemented to call a protocol specific open
>> function to retrieve the protocol interface.
>>
>> The UEFI specification does not know of such a function.
>>
>> It is not possible to implement InstallProtocolInterface with the
>> current design.
>>
>> With the patch the protocol interface itself is stored in the list
>> of installed protocols of an efi_object instead of an open function.
>>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> v2
>> Remove implementation of efi_return_handle.
>> ---
>> cmd/bootefi.c | 14 +++---
>> include/efi_loader.h | 17 ++---
>> lib/efi_loader/efi_boottime.c | 18 ++
>> lib/efi_loader/efi_disk.c | 29 +++--
>> lib/efi_loader/efi_gop.c | 2 +-
>> lib/efi_loader/efi_image_loader.c | 8
>> lib/efi_loader/efi_net.c | 30 +++---
>> 7 files changed, 26 insertions(+), 92 deletions(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 7ddeead671..7cf0129a18 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -54,14 +54,6 @@ static struct efi_device_path_file_path
>> bootefi_device_path[] = {
>> }
>> };
>>
>> -static efi_status_t EFIAPI bootefi_open_dp(void *handle, efi_guid_t
>> *protocol,
>> - void **protocol_interface, void *agent_handle,
>> - void *controller_handle, uint32_t attributes)
>> -{
>> - *protocol_interface = bootefi_device_path;
>> - return EFI_SUCCESS;
>> -}
>> -
>> /* The EFI loaded_image interface for the image executed via "bootefi" */
>> static struct efi_loaded_image loaded_image_info = {
>> .device_handle = bootefi_device_path,
>> @@ -78,7 +70,7 @@ static struct efi_object loaded_image_info_obj = {
>> * return handle which points to loaded_image_info
>> */
>> .guid = &efi_guid_loaded_image,
>> - .open = &efi_return_handle,
>> + .protocol_interface = &loaded_image_info,
>
> btw, I probably should have looked at this patchset earlier.. in
> general, I like it, since it removes a lot of boilerplate. But there
> are some cases where ->open() allows deferred allocation. For
> example, I'm working on efi_file and simple-file-system-protocol
> implementation. A file object can have a device-path accessed by
> opening device-path protocol. 99% of the time this isn't used, so the
> ->open() approach lets me defer constructing a file's device-path.
>
> How would you feel if I re-introduced ->open() as an optional thing
> (where the normal case if open is NULL would be to just return
> protocol_interface)?
>
> BR,
> -R
>
Hello Rob,
a big gap we currently have in the EFI implementation is the missing
handling of lock entries in OpenProtocol which have to be stored per
protocol as a list of EFI_OPEN_PROTOCOL_INFORMATION_ENTRYs.
Could you, please, elaborate how OpenProtocolInformation,
ConnectController, and DisconnectController shall work together with
your suggested open() approach.
We need be able to iterate efficiently over the
EFI_OPEN_PROTOCOL_INFORMATION_ENTRYs in these functions.
I fear your proposal will make the code overly complicated here.
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 30/52] rockchip: rk3368: grf: use shifted-constants and prefix with RK3368_
> On 24 Jul 2017, at 18:43, Simon Glass wrote: > > Hi Philipp, > > On 24 July 2017 at 07:10, Dr. Philipp Tomsich > wrote: >> >> >>> On 24 Jul 2017, at 14:45, Kever Yang wrote: >>> >>> Hi Philipp, >>> >>> >>> On 07/24/2017 05:11 PM, Dr. Philipp Tomsich wrote: > On 24 Jul 2017, at 10:34, Andy Yan wrote: > > Hi Philipp: > > > On 2017年07月21日 16:34, Dr. Philipp Tomsich wrote: >>> On 21 Jul 2017, at 05:50, Andy Yan wrote: >>> >>> Hi Philipp: >>> >>> >>> On 2017年07月19日 04:36, Philipp Tomsich wrote: The RK3368 GRF header was still defines with a shifted-mask but with non-shifted function selectors for the IOMUX defines. As the RK3368 support is still fresh enough to allow a quick rename, we do this now before having more code use this. As some of the downstream drivers (e.g. the Designware GMAC wrapper) may need to include the grf-header of multiple devices, we rename the various defines for the RK3368 by prefixing them with the device name. This avoids future trouble during driver integration. >>> Is that really necessary to add such a prefix for all the register >>> definition, just to fit the GMAC dirver? >>> Maybe the gmac driver can define the platform specific macro in its own >>> code like dwmac-rk in the kernel. Then we can keep the register header >>> file a little tidy. >> The problem is not the GMAC driver (although it was the motivation for >> doing >> this change), but rather how easy it is to pick up the wrong grf-file >> and refer >> to the wrong definitions/values… the conflicts are not through the >> GMAC-specifc >> defines but rather through things like the IOMUX masks or (before I moved >> this to the DDR-driver) things like the defines to enable DRAM in GRF. >> >> Until we find a way to consistently structure things in such a way that >> (a) common constructs can be shared (e.g. the masks in the IOMUX) >> (b) specific definitions (e.g. the pin-out for a specific device) is >> not visible outside of its driver >> I prefer the names to explicitly refer to each device. >> That said, the longer-term plan (especially with a larger number of >> devices >> being supported) needs to include a consistent rework of how (and where) >> we manage all these definitions from the grf-header files. > It's true that many devices use GRF, we also face this condition in the > kernel land.And all the drivers in kernel handle this device specific > definition in the driver itself(by of_device_id->data or MACRO). And > there is also no need to use the grf constructs, the common syscon api > will provide you the grf base address. I think this keeps things simple, > we don't need to rely on too much of the grf or cru header, maybe some > day we can remove the header file, just as clean as the kernel. The problem is not the base-address of GRF, but rather the need to pull in the register structure (so we can refer to individual registers by name instead of by hard-coded offset): as we pull this in today, the definitions for the various IOMUX entries will also be pulled in, which will cause duplicate definitions. >>> >>> I really don't like the idea of add the prefix, which end with longer MACRO >>> but no other improve. >>> I think the GRF is used mostly for the IOMUX, in this case the better >>> solution is >>> port the kernel rockchip-pinctrl driver in uboot, which not rely on the >>> dtsi instead of header file. >>> >>> If we do this, we can remove most of the GRF header definition for IOMUX, I >>> can ask David Wu >>> to do this, but maybe few weeks later. >> >> As indicated earlier: this is a temporary solution (although we have a local >> saying that >> "nothing is more permanent than a temporary solution”) and should remain >> limited to >> the RK3368 until we can clean this up across all boards. > > Can we drop the prefix for now? I do worry about the precedent this > sets. If this is needed anywhere then it suggests to me that we have > not split up the drivers correctly. We should not be including two > different GRF headers into the same file. E.g. there should be > different pinctrl drivers for each SoC. If we drop it, we can’t get RK3368-support merged into the GMAC driver for now. Splitting the Rockchip-wrapper of the GMAC-driver doesn’t appear like a workable solution either, as this would create a new file for each chip-variant in drivers/net. I’ll just pull the RK3368 GMAC (driver) support for now and split it off this series. >> Pulling this into the pinctrl drivers is an excellent choice. >> Please watch out for board_debug_uart_init(…), which also directly accesses >> the IOMUX >> constants and will need to be restructured together with pinctrl drivers. >> >
Re: [U-Boot] [PATCH] zynq: fb_mmc: Correct cast of address to u32
On 23 July 2017 at 09:47, Tom Rini wrote: > On Sun, Jul 23, 2017 at 09:05:31AM -0600, Simon Glass wrote: > >> This does not work on 64-bit machines. Update it to use ulong. >> >> This fixes the following warnings in some zynq boards; >> >> common/fb_mmc.c: In function 'fb_mmc_update_zimage': >> common/fb_mmc.c:188:13: warning: cast from pointer to integer of different >> size [-Wpointer-to-int-cast] >> common/fb_mmc.c:189:8: warning: cast to pointer from integer of different >> size [-Wint-to-pointer-cast] >> >> Signed-off-by: Simon Glass > > I fixed this in a slightly different way a while ago and am waiting for > it to come in via the USB tree currently. OK thanks. - Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 30/52] rockchip: rk3368: grf: use shifted-constants and prefix with RK3368_
Hi Philipp, On 24 July 2017 at 07:10, Dr. Philipp Tomsich wrote: > > > > On 24 Jul 2017, at 14:45, Kever Yang wrote: > > > > Hi Philipp, > > > > > > On 07/24/2017 05:11 PM, Dr. Philipp Tomsich wrote: > >>> On 24 Jul 2017, at 10:34, Andy Yan wrote: > >>> > >>> Hi Philipp: > >>> > >>> > >>> On 2017年07月21日 16:34, Dr. Philipp Tomsich wrote: > > On 21 Jul 2017, at 05:50, Andy Yan wrote: > > > > Hi Philipp: > > > > > > On 2017年07月19日 04:36, Philipp Tomsich wrote: > >> The RK3368 GRF header was still defines with a shifted-mask but with > >> non-shifted function selectors for the IOMUX defines. As the RK3368 > >> support is still fresh enough to allow a quick rename, we do this now > >> before having more code use this. > >> > >> As some of the downstream drivers (e.g. the Designware GMAC wrapper) > >> may need to include the grf-header of multiple devices, we rename the > >> various defines for the RK3368 by prefixing them with the device name. > >> This avoids future trouble during driver integration. > >Is that really necessary to add such a prefix for all the register > > definition, just to fit the GMAC dirver? > > Maybe the gmac driver can define the platform specific macro in its own > > code like dwmac-rk in the kernel. Then we can keep the register header > > file a little tidy. > The problem is not the GMAC driver (although it was the motivation for > doing > this change), but rather how easy it is to pick up the wrong grf-file > and refer > to the wrong definitions/values… the conflicts are not through the > GMAC-specifc > defines but rather through things like the IOMUX masks or (before I moved > this to the DDR-driver) things like the defines to enable DRAM in GRF. > > Until we find a way to consistently structure things in such a way that > (a) common constructs can be shared (e.g. the masks in the IOMUX) > (b) specific definitions (e.g. the pin-out for a specific device) is > not visible outside of its driver > I prefer the names to explicitly refer to each device. > That said, the longer-term plan (especially with a larger number of > devices > being supported) needs to include a consistent rework of how (and where) > we manage all these definitions from the grf-header files. > >>> It's true that many devices use GRF, we also face this condition in the > >>> kernel land.And all the drivers in kernel handle this device specific > >>> definition in the driver itself(by of_device_id->data or MACRO). And > >>> there is also no need to use the grf constructs, the common syscon api > >>> will provide you the grf base address. I think this keeps things simple, > >>> we don't need to rely on too much of the grf or cru header, maybe some > >>> day we can remove the header file, just as clean as the kernel. > >> The problem is not the base-address of GRF, but rather the need to pull in > >> the > >> register structure (so we can refer to individual registers by name > >> instead of by > >> hard-coded offset): as we pull this in today, the definitions for the > >> various IOMUX > >> entries will also be pulled in, which will cause duplicate definitions. > > > > I really don't like the idea of add the prefix, which end with longer MACRO > > but no other improve. > > I think the GRF is used mostly for the IOMUX, in this case the better > > solution is > > port the kernel rockchip-pinctrl driver in uboot, which not rely on the > > dtsi instead of header file. > > > > If we do this, we can remove most of the GRF header definition for IOMUX, I > > can ask David Wu > > to do this, but maybe few weeks later. > > As indicated earlier: this is a temporary solution (although we have a local > saying that > "nothing is more permanent than a temporary solution”) and should remain > limited to > the RK3368 until we can clean this up across all boards. Can we drop the prefix for now? I do worry about the precedent this sets. If this is needed anywhere then it suggests to me that we have not split up the drivers correctly. We should not be including two different GRF headers into the same file. E.g. there should be different pinctrl drivers for each SoC. > > Pulling this into the pinctrl drivers is an excellent choice. > Please watch out for board_debug_uart_init(…), which also directly accesses > the IOMUX > constants and will need to be restructured together with pinctrl drivers. > > Thanks! > —Philipp. > > > Thanks, > > - Kever > >> > >>> On the other hand, add such a prefix of rk3368 breaks the consistency > >>> with other rockchip devices. > >> I do agree that we need to clean this up across all the boards and drivers > >> supported today. As of today, I can not resolve this on a RK3368-only > >> basis, > >> as I’d need to clean up the RK3288 at the same time (and don’t want to do > >> this > >> in a R
[U-Boot] [PATCH 3/4] usb: host: ehci-generic: initialize PHY only when found
From: Patrice Chotard
Call generic_phy_init() only when a PHY was found.
This will avoid a crash if no "phys" property is found in DT.
Signed-off-by: Patrice Chotard
Reported-by: Patrick Delaunay
---
drivers/usb/host/ehci-generic.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index 3f751f1..03f8d32 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -99,12 +99,13 @@ static int ehci_usb_probe(struct udevice *dev)
error("failed to get usb phy\n");
goto reset_err;
}
- }
+ } else {
- err = generic_phy_init(&priv->phy);
- if (err) {
- error("failed to init usb phy\n");
- goto reset_err;
+ err = generic_phy_init(&priv->phy);
+ if (err) {
+ error("failed to init usb phy\n");
+ goto reset_err;
+ }
}
hccr = map_physmem(devfdt_get_addr(dev), 0x100, MAP_NOCACHE);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] usb: host: ohci-generic: initialize PHY only when found
From: Patrice Chotard
Call generic_phy_init() only when a PHY was found.
This will avoid a crash if no "phys" property is found in DT.
Signed-off-by: Patrice Chotard
Reported-by: Patrick Delaunay
---
drivers/usb/host/ohci-generic.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/ohci-generic.c b/drivers/usb/host/ohci-generic.c
index 9249039..e22ee97 100644
--- a/drivers/usb/host/ohci-generic.c
+++ b/drivers/usb/host/ohci-generic.c
@@ -91,12 +91,13 @@ static int ohci_usb_probe(struct udevice *dev)
error("failed to get usb phy\n");
goto reset_err;
}
- }
+ } else {
- err = generic_phy_init(&priv->phy);
- if (err) {
- error("failed to init usb phy\n");
- goto reset_err;
+ err = generic_phy_init(&priv->phy);
+ if (err) {
+ error("failed to init usb phy\n");
+ goto reset_err;
+ }
}
err = ohci_register(dev, regs);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] dm: usb: host: xhci-dwc3: add missing #ifdef CONFIG_DM_USB
From: Patrice Chotard
Add CONFIG_DM_USB flag to avoid following compilation errors
detected by buildman :
+drivers/usb/host/built-in.o: In function `xhci_dwc3_remove':
+drivers/usb/host/xhci-dwc3.c:168: undefined reference to `xhci_deregister'
+drivers/usb/host/built-in.o: In function `xhci_dwc3_probe':
+drivers/usb/host/xhci-dwc3.c:145: undefined reference to `usb_get_dr_mode'
+drivers/usb/host/xhci-dwc3.c:152: undefined reference to `xhci_register'
introduced by patch d5c3f014da3 "usb: host: xhci-dwc3: Convert driver to DM"
Signed-off-by: Patrice Chotard
Reported-by: Ran Wang
---
drivers/usb/host/xhci-dwc3.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 374fe74..541a785 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -111,6 +111,7 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
GFLADJ_30MHZ(val));
}
+#ifdef CONFIG_DM_USB
static int xhci_dwc3_probe(struct udevice *dev)
{
struct xhci_dwc3_platdata *plat = dev_get_platdata(dev);
@@ -184,3 +185,4 @@ U_BOOT_DRIVER(xhci_dwc3) = {
.platdata_auto_alloc_size = sizeof(struct xhci_dwc3_platdata),
.flags = DM_FLAG_ALLOC_PRIV_DMA,
};
+#endif
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/4] Fix compile failure encountered on u-boot-usb tree (2017-07-20)
From: Patrice Chotard This series fixes : _ compilation issue reported by Ran Wang on u-boot-usb branch _ add last minute fixes for both generic-ehci and generic_ohci drivers which avoid to init a generic PHY if not found, reported by Patrick Delaunay This series need an additionnal patch from Jean-Jacques Hiblot : [PATCH v2] phy: add a NO-OP phy driver Patrice Chotard (4): dm: phy: add missing #ifdef CONFIG_PHY dm: usb: host: xhci-dwc3: add missing #ifdef CONFIG_DM_USB usb: host: ehci-generic: initialize PHY only when found usb: host: ohci-generic: initialize PHY only when found drivers/usb/host/ehci-generic.c | 11 ++- drivers/usb/host/ohci-generic.c | 11 ++- drivers/usb/host/xhci-dwc3.c| 2 ++ include/generic-phy.h | 42 + 4 files changed, 56 insertions(+), 10 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] dm: phy: add missing #ifdef CONFIG_PHY
From: Patrice Chotard
To avoid compilation breakage on platform that doesn't
support DM PHY but uses xhci-dwc3 driver, add the missing
CONFIG_PHY flag.
Introduced by patch :
84e53877 "usb: host: xhci-dwc3: Add generic PHY support"
Cc: Ran Wang
Cc: Bin Meng
Signed-off-by: Patrice Chotard
Reported-by: Ran Wang
---
include/generic-phy.h | 42 ++
1 file changed, 42 insertions(+)
diff --git a/include/generic-phy.h b/include/generic-phy.h
index 58cd2b2..eac5adc 100644
--- a/include/generic-phy.h
+++ b/include/generic-phy.h
@@ -122,6 +122,7 @@ struct phy_ops {
int (*power_off)(struct phy *phy);
};
+#ifdef CONFIG_PHY
/**
* generic_phy_init() - initialize the PHY port
@@ -220,6 +221,47 @@ int generic_phy_get_by_index(struct udevice *user, int
index,
int generic_phy_get_by_name(struct udevice *user, const char *phy_name,
struct phy *phy);
+#else /* CONFIG_PHY */
+
+static inline int generic_phy_init(struct phy *phy)
+{
+ return 0;
+}
+
+static inline int generic_phy_exit(struct phy *phy)
+{
+ return 0;
+}
+
+static inline int generic_phy_reset(struct phy *phy)
+{
+ return 0;
+}
+
+static inline int generic_phy_power_on(struct phy *phy)
+{
+ return 0;
+}
+
+static inline int generic_phy_power_off(struct phy *phy)
+{
+ return 0;
+}
+
+static inline int generic_phy_get_by_index(struct udevice *user, int index,
+struct phy *phy)
+{
+ return 0;
+}
+
+static inline int generic_phy_get_by_name(struct udevice *user, const char
*phy_name,
+ struct phy *phy)
+{
+ return 0;
+}
+
+#endif /* CONFIG_PHY */
+
/**
* generic_phy_valid() - check if PHY port is valid
*
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] efi_loader: expose protocols via GUID
shim.efi (or rather gnu-efi's LibLocateProtocol() which shim.efi uses)
resolves protocols via efi_locate_handle() so the console protocols
need to be added to the efi object list.
Signed-off-by: Rob Clark
---
include/efi_api.h| 9 +
include/efi_loader.h | 1 +
lib/efi_loader/efi_console.c | 15 ++-
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index 2c443080b6..d8fecb6980 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -393,6 +393,11 @@ struct simple_text_output_mode {
bool cursor_visible;
};
+
+#define EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID \
+ EFI_GUID(0x387477c2, 0x69c7, 0x11d2, \
+0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+
struct efi_simple_text_output_protocol {
void *reset;
efi_status_t (EFIAPI *output_string)(
@@ -427,6 +432,10 @@ struct efi_input_key {
s16 unicode_char;
};
+#define EFI_SIMPLE_TEXT_INPUT_PROTOCOL_GUID \
+ EFI_GUID(0x387477c1, 0x69c7, 0x11d2, \
+0x8e, 0x39, 0x0, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
+
struct efi_simple_input_interface {
efi_status_t(EFIAPI *reset)(struct efi_simple_input_interface *this,
bool ExtendedVerification);
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 51fbf23864..48eeb4cdd8 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -109,6 +109,7 @@ int efi_net_register(void **handle);
/* Called by bootefi to make SMBIOS tables available */
void efi_smbios_register(void);
+
/* Called by networking code to memorize the dhcp ack package */
void efi_net_set_dhcp_ack(void *pkt, int len);
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index dbe98ac08b..ba0a8b90cd 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -426,7 +426,6 @@ struct efi_simple_input_interface efi_con_in = {
.read_key_stroke = efi_cin_read_key_stroke,
.wait_for_key = NULL,
};
-
static struct efi_event *console_timer_event;
static void efi_key_notify(struct efi_event *event, void *context)
@@ -441,10 +440,24 @@ static void efi_console_timer_notify(struct efi_event
*event, void *context)
EFI_EXIT(EFI_SUCCESS);
}
+
+static struct efi_object efi_console_control_obj =
+ EFI_PROTOCOL_OBJECT(efi_guid_console_control, &efi_console_control);
+static struct efi_object efi_console_output_obj =
+ EFI_PROTOCOL_OBJECT(EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID, &efi_con_out);
+static struct efi_object efi_console_input_obj =
+ EFI_PROTOCOL_OBJECT(EFI_SIMPLE_TEXT_INPUT_PROTOCOL_GUID, &efi_con_in);
+
/* This gets called from do_bootefi_exec(). */
int efi_console_register(void)
{
efi_status_t r;
+
+ /* Hook up to the device list */
+ list_add_tail(&efi_console_control_obj.link, &efi_obj_list);
+ list_add_tail(&efi_console_output_obj.link, &efi_obj_list);
+ list_add_tail(&efi_console_input_obj.link, &efi_obj_list);
+
r = efi_create_event(EVT_NOTIFY_WAIT, TPL_CALLBACK,
efi_key_notify, NULL, &efi_con_in.wait_for_key);
if (r != EFI_SUCCESS) {
--
2.13.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] efi_loader: add helper macro to construct protocol objects
There are a bunch of protocols which should be exposed by GUID but are
not. Add a helper macro to create an efi_object, to avoid much typing.
Note that using the pointer for efiobj->handle is semi-arbitrary. We
just need a unique value to match the efiobj supporting the protocol
with the handle that LocateHandle() returns..
See LibLocateProtocol() in gnu-efi. It does LocateHandle() to find all
the handles, and then loops over them calling HandleProtocol() with the
GUID of the protocol it is trying to find.
Signed-off-by: Rob Clark
---
include/efi_loader.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 27c741ba0c..51fbf23864 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -63,6 +63,14 @@ struct efi_object {
void *handle;
};
+#define EFI_PROTOCOL_OBJECT(_guid, _protocol) (struct efi_object){ \
+ .protocols = {{ \
+ .guid = &(_guid), \
+ .protocol_interface = (void *)(_protocol), \
+ }}, \
+ .handle = (void *)(_protocol), \
+}
+
/**
* struct efi_event
*
--
2.13.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: add back optional efi_handler::open()
In some cases it is useful to defer creation of the protocol interface
object. So add back an optional ->open() hook that is used if
protcol_interface is NULL.
I've slightly simplified the fxn ptr signature to remove unneeded args,
and so compiler will complain if patches that used the "old way" are,
and which do not need this extra complexity, are rebased.
Signed-off-by: Rob Clark
---
include/efi_loader.h | 9 -
lib/efi_loader/efi_boottime.c | 7 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 90411cdbab..3da0477fdc 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -41,10 +41,17 @@ extern unsigned int __efi_runtime_rel_start,
__efi_runtime_rel_stop;
/*
* When the UEFI payload wants to open a protocol on an object to get its
* interface (usually a struct with callback functions), this struct maps the
- * protocol GUID to the respective protocol interface */
+ * protocol GUID to the respective protocol interface.
+ *
+ * The optional ->open() fxn can be used for cases where the protocol
+ * interface is constructed on-demand, and is called if protocol_interface
+ * is NULL.
+ */
struct efi_handler {
const efi_guid_t *guid;
void *protocol_interface;
+ efi_status_t (EFIAPI *open)(void *handle, efi_guid_t *protocol,
+ void **protocol_interface);
};
/*
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 7d45c18ff7..21f41866d0 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1063,6 +1063,13 @@ static efi_status_t EFIAPI efi_open_protocol(
if (!guidcmp(hprotocol, protocol)) {
if (attributes !=
EFI_OPEN_PROTOCOL_TEST_PROTOCOL) {
+ if (!handler->protocol_interface) {
+ r =
handler->open(efiobj->handle,
+ protocol,
+
&handler->protocol_interface);
+ if (r != EFI_SUCCESS)
+ goto out;
+ }
*protocol_interface =
handler->protocol_interface;
}
--
2.13.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: log EFI return values too
Turns out this is rather useful to tracking down where things fail.
Signed-off-by: Rob Clark
---
v2: use EFI_ERROR_MASK
include/efi_loader.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 40e0f1dbd7..a8df44fdb6 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -20,7 +20,10 @@
debug("EFI: Entry %s(" format ")\n", __func__, ##__VA_ARGS__); \
} while(0)
-#define EFI_EXIT(ret) efi_exit_func(ret);
+#define EFI_EXIT(ret) ({ \
+ debug("EFI: Exit: %s: %u\n", __func__, (u32)((ret) & ~EFI_ERROR_MASK));
\
+ efi_exit_func(ret); \
+ })
extern struct efi_runtime_services efi_runtime_services;
extern struct efi_system_table systab;
--
2.13.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] am335x uboot TFTP via SPL over usb is failing
Hi Jason, Have a look at this thread, and help us find a solution. Thanks On Mon, Jul 3, 2017 at 5:53 PM, Ravi Kumar Prasad <7rav...@gmail.com> wrote: > Hi, Michael > Please cc the your findings of second bisect here, so that someone can > help further. > > On Mon, Jun 26, 2017 at 5:12 PM, Ravi Kumar Prasad <7rav...@gmail.com> > wrote: > >> Hi, >> >> I'm developing a node.js usb bootloader server for the am335x >> (BeagleBone) platform which can boot it into USB mass storage mode. The >> server TFTPs SPL over usb and then TFTPs uboot (configured for ums) via SPL. >> >> The SPL binary gets transferred successfully, but SPL can't TFTP the >> uboot binary with the uboot build from latest sources. >> >> The previous versions of u-boot succeed in doing so. The known working >> u-boot version was v2014.07 ( https://github.com/u-boot/u- >> boot/commit/524123a70761110c5cf3ccc5f52f6d4da071b959 ). >> >> So, we did a git bisect on uboot to track when it stopped failing to >> TFTP. Here's the bisect log https://pastebin.com/hwXJUf3K >> >> Here's outputs of all u-boot https://pastebin.com/t2WNLQsQ >> >> So, first bad commit turns out to be this https://github.com/u-boot >> /u-boot/commit/98d2d5e8c473232dc718763dbec284b7349dcc05 >> >> Config used for u-boot build : am335x_evm_usbspl_defconfig >> Patch for uboot ums : https://pastebin.com/rZ3R3zRs >> >> Here's code for the server https://github.com/ravikp7/node-beagle-boot , >> it currently works only on Linux. >> >> I need help in fixing this. >> >> Thanks >> Ravi Kumar >> >> > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] db410c: config updates
On Fri, Jul 21, 2017 at 07:08:23PM -0400, Rob Clark wrote: > On Fri, Jul 21, 2017 at 6:20 PM, Tom Rini wrote: > > On Fri, Jul 21, 2017 at 03:10:14PM -0400, Rob Clark wrote: > >> Signed-off-by: Rob Clark > >> --- > >> arch/arm/Kconfig | 2 +- > >> configs/dragonboard410c_defconfig | 8 +++- > >> 2 files changed, 8 insertions(+), 2 deletions(-) > >> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >> index f7b44392ac..db6a325ee1 100644 > >> --- a/arch/arm/Kconfig > >> +++ b/arch/arm/Kconfig > >> @@ -633,7 +633,7 @@ config ARCH_SNAPDRAGON > >> select DM_SERIAL > >> select SPMI > >> select OF_CONTROL > >> - select OF_SEPARATE > >> + select OF_BOARD > >> > >> config ARCH_SOCFPGA > >> bool "Altera SOCFPGA family" > >> diff --git a/configs/dragonboard410c_defconfig > >> b/configs/dragonboard410c_defconfig > >> index d992c2adda..45a121822f 100644 > >> --- a/configs/dragonboard410c_defconfig > >> +++ b/configs/dragonboard410c_defconfig > >> @@ -37,4 +37,10 @@ CONFIG_USB_EHCI_MSM=y > >> CONFIG_USB_ULPI_VIEWPORT=y > >> CONFIG_USB_ULPI=y > >> CONFIG_USB_STORAGE=y > >> -CONFIG_OF_LIBFDT_OVERLAY=y > >> +CONFIG_DM_VIDEO=y > >> +# CONFIG_VIDEO_BPP8 is not set > >> +CONFIG_VIDEO_BPP16=y > >> +CONFIG_VIDEO_BPP32=y > >> +CONFIG_CONSOLE_NORMAL=y > >> +CONFIG_VIDEO_SIMPLE=y > >> +CONFIG_OF_BOARD=y > > > > This doesn't look like you updated it with savedefconfig, did you? > > No, probably not.. tbh this is the first time I've done a defconfig > update (u-boot or kernel), board level stuff is a bit outside what I > normally work on (ie. mesa and gpu/drm), so pls forgive cluelessness > in this regard.. Ah, yeah. It's the handy-dandy way to keep things in sync and sometimes even avoid patch conflicts with others. > > Also, we don't want to nuke the overlay support I assume. Thanks! > > probably not.. although it is still an open question, I think, from > distro standpoint how to eventually pass the right fdt to kernel. As > it stands, the stage before u-boot patches the fdt bundled with > u-boot.img with useful things like wifi/bt mac addresses. But the fdt > in u-boot.img (at least if built from u-boot tree) is highly > insufficient to enabled all of the upstream drivers. And requiring > the end user to flash a new u-boot.img w/ bundled fdt as new features > (where there is not yet any clue how dt bindings should look, like > bus-scaling), isn't super friendly. > > We might eventually want some optional board hook to let board > specific code patch an fdt loaded from OS media by u-boot (or grub?) > based on fields in fdt passed from previous stage to u-boot. Maybe > overlays are a way to do that.. idk, I still need to look into how > they work.. Yeah, overlays are the standard DT way to deal with things like add-on boards for 96boards/CHIP/beaglebone/etc, along with similar but non-dev board cases. We want to keep the 'overlay' option enabled for Dragonboard I think :) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Makefile: also build fdt for snapdragon
On Fri, Jul 21, 2017 at 06:57:58PM -0400, Rob Clark wrote: > On Fri, Jul 21, 2017 at 6:18 PM, Tom Rini wrote: > > On Fri, Jul 21, 2017 at 03:10:10PM -0400, Rob Clark wrote: > > > >> Snapdragon is a bit of a funny case, where we want to build the fdt to > >> pass to lk, which loads us, but otherwise want to treat it as OF_BOARD, > >> since lk will patch the fdt (for example, to insert simple-framebuffer > >> node). > >> > >> Signed-off-by: Rob Clark > >> --- > >> Makefile | 6 ++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/Makefile b/Makefile > >> index 452596485d..0749cdfc5d 100644 > >> --- a/Makefile > >> +++ b/Makefile > >> @@ -780,6 +780,12 @@ ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img > >> endif > >> ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin > >> ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb > >> +# Snapdragon devices, where lk/aboot loads u-boot is kind of a special > >> +# case, because lk loads the fdt which is embedded (along with u-boot) > >> +# in a boot.img. But it also does some fdt fixups. So generally we > >> +# want to treat it like CONFIG_OF_BOARD=y, except that we also want > >> +# to build the dtb's > >> +ALL-$(CONFIG_ARCH_SNAPDRAGON) += u-boot.dtb > >> ifeq ($(CONFIG_SPL_FRAMEWORK),y) > >> ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img > >> endif > > > > We really can't just select OF_SEPARATE here? Because the code in > > lib/fdtdec.c is wrong, as it stands, yes? If so, could we shuffle that > > code right to allow for the case of "we get our DT modified by firmware > > that loads us" ? That doesn't soune like a super uncommon case moving > > forward. > > from a quick look, I think the only reason we need OF_BOARD is the > call to board_fdt_blob_setup() in fdtdec.. > > I guess we could make that a weak sym, and call it unconditionally.. > in that case I think OF_SEPARATE would work. If you think that is a > cleaner solution, I can give that a try. I think so. I really don't want to have changes in the Makefiles to special case logic like this if we can avoid it, without making the code ugly too. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 00/10] usb: Extend ehci and ohci generic driver
After discussion with Marek, this series will be canceled, only incremental patches are needed. Patrice On 07/24/2017 01:46 PM, patrice.chot...@st.com wrote: > From: Patrice Chotard > > This series improves generic ehci and ohci drivers by addition of : > _ error path during probe (clocks, resets and phy release) > _ .remove callback > _ add generic PHY framework for both generic ehci and ohci drivers > _ add RESET and CLOCK framework for generic ohci driver > > To implement these features, some new methods are needed in reset, clock and > in dm/core framework: > _ add reset_request() and reset_assert_all() methods in RESET framework > _ add clk_count() and clk_disable_all() methods in CLOCK framework > _ add ofnode_count_phandle_with_args() and > dev_count_phandle_with_args() in dm/core > > This series has dependencies with series "[PATCH v8 0/6] Extend xhci-dwc3", > so must been merged after this indicated series. > > v11: _ fix issue in ehci (patch 7) and ohci (patch 10) drivers reported by > Patrick DELAUNAY. > Generic PHY must be initialized only when found. > v10: _ add dev_count_phandle_with_args() requested by Simon Glass > _ fix some mirno remarks > > v9: _ rename reset_assert_all() in reset_release_all() as this function not > only assert all resets but also free all of them > _ rename clk_disable_all() in clk_release_all() as this function not > only disable all clocks but also free all of them > _ add a check in reset_release_all()/clk_disable_all() to verify if > reset/clock > has been previously requested before asserting/disabling and freeing > it. > > v8: _ rework error path by propagating the initial error code until the end > of probe() > _ replace devm_kmalloc() with devm_kcalloc() > _ fix cosmetics remarks > > v7: _ replace clk_count() and reset_count() methods by > ofnode_count_phandle_with_args() in patches 3, 4 and 5 > > v6: _ replace clk_get_by_index() by dev_read_phandle_with_args() in > clk_count() in patch 4 > _ add Reviewed-by Simon Glass for patch 2 and 5 > > v5: _ rebase on top of dm/master requested by Simon Glass in order to use > livetree update > _ replace fdtdec_parse_phandle_with_args() by > dev_read_phandle_with_args() in patch 2 > > v4: _ add clk_disable_all() and reset_assert_all() methods into CLOCK and > RESET framework as suggested by Simon Glass and Marek Vasut > _ add reset_count() and clk_count() methods which returns respectively > the > number of resets and clocks declared into "resets" and "clocks" DT > properties. > This allows to allocate the right amount of memory to keep resets and > clocks > reference > _ update the memory allocation for deasserted resets and enabled > clocks reference list. Replace lists by arrays. > > v3: _ keep enabled clocks and deasserted resets reference in list in > order to > disable clock or assert resets in error path or in .remove callback > _ add missing commit message > _ use struct generic_ehci * instead of struct udevice * as parameter for > ehci_release_resets() and ehci_release_clocks() > _ test return value on generic_phy_get_by_index() and > generic_phy_init() > _ split previous patch 5 in 3 independant patch for CLOCK, RESET and > PHY support > > v2: _ add needed reset_request() in RESET framework > _ add error path in ehci/ohci-generic to disable clocks and to assert > resets > _ add .remove callback with clocks, resets and phy release > _ split the replacement of printf() by error() in an independant patch > > Patrice Chotard (10): >reset: add reset_request() >reset: add reset_release_all() >clk: add clk_release_all() >dm: core: add ofnode_count_phandle_with_args() >usb: host: ehci-generic: replace printf() by error() >usb: host: ehci-generic: add error path and .remove callback >usb: host: ehci-generic: add generic PHY support >usb: host: ohci-generic: add CLOCK support >usb: host: ohci-generic: add RESET support >usb: host: ohci-generic: add generic PHY support > > drivers/clk/clk-uclass.c| 26 +++ > drivers/core/of_access.c| 7 ++ > drivers/core/ofnode.c | 12 > drivers/reset/reset-uclass.c| 34 ++ > drivers/usb/host/ehci-generic.c | 147 > +--- > drivers/usb/host/ohci-generic.c | 122 - > include/clk.h | 14 > include/dm/of_access.h | 18 + > include/dm/ofnode.h | 17 + > include/dm/read.h | 25 +++ > include/reset.h | 27 > 11 files changed, 424 insertions(+), 25 deletions(-) >
Re: [U-Boot] [PATCH v8 0/6] Extend xhci-dwc3
After discussion with Marek, this series will be canceled, only incremental patches are needed. Patrice On 07/24/2017 11:44 AM, patrice.chot...@st.com wrote: > From: Patrice Chotard > > This series extend xhci-dwc3.c drivers by : > _ converting it to DM model, > _ adding dual role mode support from DT > _ adding new generic_phy_valid() method in PHY framework > _ adding support of generic PHY framework > > > v8: _ Add CONFIG_DM_USB flag in path 1 to fix compilation issue for > platforms > which uses xhci-dwc3 driver and doesn't support yet driver model > _ add PHY stub functions in patch 5 to fix compilation issue for > platforms > which uses xhci-dwc3 driver and doesn't support generic PHY framework > _ fix bisection issue with patch 1 reported by Łukasz Majewski, move > struct > xhci_dwc3_platdata in patch 6 to fix it. > v7: _ add Reviewed-by in patch 1 > _ declare bool generic_phy_valid(struct phy *phy) as static inline in > patch 4 > v6: _ remove useless struct xhci_dwc3 in patch 1 > v5: _ rebase on top of dm/master in order to use the last livetree update > _ replace dev_get_addr() by devfdt_get_addr() in patch 1 > v4: _ set phy->dev to NULL in case of generic_phy_get_by_index() > v3: _ introduce generic_phy_valid() method > _ add Reviewed-by > v2: _ use dev_get_addr() in PATCH 1 and removed useless piece of code > > Patrice Chotard (6): >usb: host: xhci-dwc3: Convert driver to DM >usb: host: xhci-dwc3: Add dual role mode support from DT >drivers: phy: Set phy->dev to NULL when generic_phy_get_by_index() > fails >drivers: phy: add generic_phy_valid() method >dm: phy: add PHY stub function >usb: host: xhci-dwc3: Add generic PHY support > > drivers/phy/phy-uclass.c | 1 + > drivers/usb/host/xhci-dwc3.c | 89 > > include/generic-phy.h| 53 ++ > 3 files changed, 143 insertions(+) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: fb_mmc: Correct cast of address to u32
On 07/24/2017 03:28 PM, Łukasz Majewski wrote: > On 07/24/2017 02:53 PM, Marek Vasut wrote: >> On 07/24/2017 02:47 PM, Tom Rini wrote: >>> On Mon, Jul 24, 2017 at 02:09:56PM +0200, Marek Vasut wrote: On 07/23/2017 05:47 PM, Tom Rini wrote: > On Sun, Jul 23, 2017 at 09:05:31AM -0600, Simon Glass wrote: > >> This does not work on 64-bit machines. Update it to use ulong. >> >> This fixes the following warnings in some zynq boards; >> >> common/fb_mmc.c: In function 'fb_mmc_update_zimage': >> common/fb_mmc.c:188:13: warning: cast from pointer to integer of >> different >> size [-Wpointer-to-int-cast] >> common/fb_mmc.c:189:8: warning: cast to pointer from integer of >> different >> size [-Wint-to-pointer-cast] >> >> Signed-off-by: Simon Glass > > I fixed this in a slightly different way a while ago and am waiting > for > it to come in via the USB tree currently. MMC patch via USB ? Anyway, this should use uintptr_t I guess ? >>> >>> "fastboot" is USB gadget code, and comes via Lukasz. Unless you want me >>> to pick it up directly? Thanks! >>> >> The tags didn't indicate any such thing and I didn't see the entire >> patch since it was clipped, so ... anyway, if it's fastboot, it indeed >> goes via Lukasz. >> > > The fb_mmc.c is a bit misleading. > > I will take this patch when we fix issues with u-boot-usb tree. > Super, thanks. Seems that'll not take long anymore ... -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 9/9] omap: detect board before spl_early_init()
On Thu, Jul 20, 2017 at 07:02:36PM +0200, Jean-Jacques Hiblot wrote: > In order to be able to select the right DTB, we need to have identified the > board before spl_early_init() is called. > > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: fb_mmc: Correct cast of address to u32
On 07/24/2017 02:53 PM, Marek Vasut wrote: On 07/24/2017 02:47 PM, Tom Rini wrote: On Mon, Jul 24, 2017 at 02:09:56PM +0200, Marek Vasut wrote: On 07/23/2017 05:47 PM, Tom Rini wrote: On Sun, Jul 23, 2017 at 09:05:31AM -0600, Simon Glass wrote: This does not work on 64-bit machines. Update it to use ulong. This fixes the following warnings in some zynq boards; common/fb_mmc.c: In function 'fb_mmc_update_zimage': common/fb_mmc.c:188:13: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] common/fb_mmc.c:189:8: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Signed-off-by: Simon Glass I fixed this in a slightly different way a while ago and am waiting for it to come in via the USB tree currently. MMC patch via USB ? Anyway, this should use uintptr_t I guess ? "fastboot" is USB gadget code, and comes via Lukasz. Unless you want me to pick it up directly? Thanks! The tags didn't indicate any such thing and I didn't see the entire patch since it was clipped, so ... anyway, if it's fastboot, it indeed goes via Lukasz. The fb_mmc.c is a bit misleading. I will take this patch when we fix issues with u-boot-usb tree. -- Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 8/9] spl: dm: Make it possible for the SPL to pick its own DTB from a FIT
On Thu, Jul 20, 2017 at 07:02:35PM +0200, Jean-Jacques Hiblot wrote: > u-boot can be embedded within a FIT image with multiple DTBs. It then > selects at run-time which one is best suited for the platform. > Use the same principle here for the SPL: put the DTBs in a FIT image, > compress it (LZO, GZIP, or no compression) and append it at the end of the > SPL. > > Signed-off-by: Jean-Jacques Hiblot > --- > dts/Kconfig | 76 ++ > lib/fdtdec.c | 85 > ++-- > scripts/Makefile.spl | 35 +- > 3 files changed, 186 insertions(+), 10 deletions(-) > > diff --git a/dts/Kconfig b/dts/Kconfig > index c78438a..2b9ea42 100644 > --- a/dts/Kconfig > +++ b/dts/Kconfig > @@ -118,6 +118,82 @@ config MULTI_DTB_FIT > the correct DTB to be used. Use this if you need to support > multiple DTBs but don't use the SPL. > > + > +config SPL_MULTI_DTB_FIT > + depends on SPL_LOAD_FIT && SPL_OF_CONTROL && !SPL_OF_PLATDATA > + bool "support embedding several DTBs in a FIT image for the SPL" > + default n n is the default already, please add some help. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/9] lib: allow building lzo and gunzip for the SPL
On Thu, Jul 20, 2017 at 07:02:34PM +0200, Jean-Jacques Hiblot wrote: > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] gzip: add a function to parse the header
On Thu, Jul 20, 2017 at 07:02:33PM +0200, Jean-Jacques Hiblot wrote: > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] lzo: add a function to check the validity of the header
On Thu, Jul 20, 2017 at 07:02:32PM +0200, Jean-Jacques Hiblot wrote: > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/9] fit: If no matching config is found in fit_find_config_node(), use the default one
On Thu, Jul 20, 2017 at 07:02:31PM +0200, Jean-Jacques Hiblot wrote: > If board_fit_config_name_match() doesn't match any configuration node, > then use the default one (if provided). > > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] fit: fixed bug in locate_dtb_in_fit()
On Thu, Jul 20, 2017 at 07:02:30PM +0200, Jean-Jacques Hiblot wrote: > If the dtb is the first data of the FIT, the its offset is 0x0. Change the > test to '<' instead of '<=' > > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] fit: use 'const' for the input of fdt_offset() and locate_dtb_in_fit()
On Thu, Jul 20, 2017 at 07:02:29PM +0200, Jean-Jacques Hiblot wrote: > Those 2 functions don't modify their input, we can mark it const. > This prevents compilation warnings when they are provided const input. > > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] phy: add a NO-OP phy driver
This driver is used to stub PHY operations in a driver (USB, SATA).
This is useful when the 'client' driver (USB, SATA, ...) uses the PHY
framework and there is no actual PHY harwdare to drive.
Signed-off-by: Jean-Jacques Hiblot
---
Even with patch http://patchwork.ozlabs.org/patch/792712 ("dm: phy: add PHY
stub function"), this patch is still useful because disabling CONFIG_PHY may
not always be a valid option: another driver may require it.
v2 : - Better description in Kconfig
- changed all "noop" to "nop"
Documentation/devicetree/bindings/phy/no-op.txt | 16 +++
drivers/phy/Kconfig | 18 +
drivers/phy/Makefile| 1 +
drivers/phy/nop-phy.c | 26 +
4 files changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/no-op.txt
create mode 100644 drivers/phy/nop-phy.c
diff --git a/Documentation/devicetree/bindings/phy/no-op.txt
b/Documentation/devicetree/bindings/phy/no-op.txt
new file mode 100644
index 000..de03676
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/no-op.txt
@@ -0,0 +1,16 @@
+NOP PHY driver
+
+This driver is used to stub PHY operations in a driver (USB, SATA).
+This is useful when the 'client' driver (USB, SATA, ...) uses the PHY framework
+and there is no actual PHY harwdare to drive.
+
+Required properties:
+- compatible : must contain "nop-phy"
+- #phy-cells : must contain <0>
+
+Example:
+
+nop_phy {
+ compatible = "nop-phy";
+ #phy-cells = <0>;
+};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7841554..98f2a1b 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -41,6 +41,24 @@ config PHY_SANDBOX
This select a dummy sandbox PHY driver. It used only to implement
the unit tests for the phy framework
+config NOP_PHY
+ bool "NOP PHY driver"
+ depends on PHY
+ help
+ Support for a no-op PHY driver (stubbed PHY driver).
+
+ This is useful when a driver uses the PHY framework but no real PHY
+ hardware exists.
+
+config SPL_NOP_PHY
+ bool "NOP PHY driver in SPL"
+ depends on SPL_PHY
+ help
+ Support for a no-op PHY driver (stubbed PHY driver) in the SPL.
+
+ This is useful when a driver uses the PHY framework but no real PHY
+ hardware exists.
+
config PIPE3_PHY
bool "Support omap's PIPE3 PHY"
depends on PHY && ARCH_OMAP2PLUS
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 6ce96d2..ab56c46 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -6,5 +6,6 @@
#
obj-$(CONFIG_$(SPL_)PHY) += phy-uclass.o
+obj-$(CONFIG_$(SPL_)NOP_PHY) += nop-phy.o
obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o
obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o
diff --git a/drivers/phy/nop-phy.c b/drivers/phy/nop-phy.c
new file mode 100644
index 000..2201cc3
--- /dev/null
+++ b/drivers/phy/nop-phy.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2017 Texas Instruments Incorporated - http://www.ti.com/
+ * Written by Jean-Jacques Hiblot
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+
+static const struct udevice_id nop_phy_ids[] = {
+ { .compatible = "nop-phy" },
+ { }
+};
+
+static struct phy_ops nop_phy_ops = {
+};
+
+U_BOOT_DRIVER(nop_phy) = {
+ .name = "nop_phy",
+ .id = UCLASS_PHY,
+ .of_match = nop_phy_ids,
+ .ops = &nop_phy_ops,
+};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] dts: renamed FIT_EMBED to MULTI_DTB_FIT and moved it to the dts Kconfig
On Thu, Jul 20, 2017 at 07:02:28PM +0200, Jean-Jacques Hiblot wrote: > Signed-off-by: Jean-Jacques Hiblot Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 30/52] rockchip: rk3368: grf: use shifted-constants and prefix with RK3368_
> On 24 Jul 2017, at 14:45, Kever Yang wrote: > > Hi Philipp, > > > On 07/24/2017 05:11 PM, Dr. Philipp Tomsich wrote: >>> On 24 Jul 2017, at 10:34, Andy Yan wrote: >>> >>> Hi Philipp: >>> >>> >>> On 2017年07月21日 16:34, Dr. Philipp Tomsich wrote: > On 21 Jul 2017, at 05:50, Andy Yan wrote: > > Hi Philipp: > > > On 2017年07月19日 04:36, Philipp Tomsich wrote: >> The RK3368 GRF header was still defines with a shifted-mask but with >> non-shifted function selectors for the IOMUX defines. As the RK3368 >> support is still fresh enough to allow a quick rename, we do this now >> before having more code use this. >> >> As some of the downstream drivers (e.g. the Designware GMAC wrapper) >> may need to include the grf-header of multiple devices, we rename the >> various defines for the RK3368 by prefixing them with the device name. >> This avoids future trouble during driver integration. >Is that really necessary to add such a prefix for all the register > definition, just to fit the GMAC dirver? > Maybe the gmac driver can define the platform specific macro in its own > code like dwmac-rk in the kernel. Then we can keep the register header > file a little tidy. The problem is not the GMAC driver (although it was the motivation for doing this change), but rather how easy it is to pick up the wrong grf-file and refer to the wrong definitions/values… the conflicts are not through the GMAC-specifc defines but rather through things like the IOMUX masks or (before I moved this to the DDR-driver) things like the defines to enable DRAM in GRF. Until we find a way to consistently structure things in such a way that (a) common constructs can be shared (e.g. the masks in the IOMUX) (b) specific definitions (e.g. the pin-out for a specific device) is not visible outside of its driver I prefer the names to explicitly refer to each device. That said, the longer-term plan (especially with a larger number of devices being supported) needs to include a consistent rework of how (and where) we manage all these definitions from the grf-header files. >>> It's true that many devices use GRF, we also face this condition in the >>> kernel land.And all the drivers in kernel handle this device specific >>> definition in the driver itself(by of_device_id->data or MACRO). And there >>> is also no need to use the grf constructs, the common syscon api will >>> provide you the grf base address. I think this keeps things simple, we >>> don't need to rely on too much of the grf or cru header, maybe some day we >>> can remove the header file, just as clean as the kernel. >> The problem is not the base-address of GRF, but rather the need to pull in >> the >> register structure (so we can refer to individual registers by name instead >> of by >> hard-coded offset): as we pull this in today, the definitions for the >> various IOMUX >> entries will also be pulled in, which will cause duplicate definitions. > > I really don't like the idea of add the prefix, which end with longer MACRO > but no other improve. > I think the GRF is used mostly for the IOMUX, in this case the better > solution is > port the kernel rockchip-pinctrl driver in uboot, which not rely on the dtsi > instead of header file. > > If we do this, we can remove most of the GRF header definition for IOMUX, I > can ask David Wu > to do this, but maybe few weeks later. As indicated earlier: this is a temporary solution (although we have a local saying that "nothing is more permanent than a temporary solution”) and should remain limited to the RK3368 until we can clean this up across all boards. Pulling this into the pinctrl drivers is an excellent choice. Please watch out for board_debug_uart_init(…), which also directly accesses the IOMUX constants and will need to be restructured together with pinctrl drivers. Thanks! —Philipp. > Thanks, > - Kever >> >>> On the other hand, add such a prefix of rk3368 breaks the consistency with >>> other rockchip devices. >> I do agree that we need to clean this up across all the boards and drivers >> supported today. As of today, I can not resolve this on a RK3368-only basis, >> as I’d need to clean up the RK3288 at the same time (and don’t want to do >> this >> in a RK3368-focused series that already has way too much going on). >> >> Let’s try to clean this up for the next (i.e. the one after this) merge >> window. >> Once we have bit-definitions out of the grf-header, I’ll remove the RK3368_ >> prefixes... >> >> Signed-off-by: Philipp Tomsich >> --- >> >> arch/arm/include/asm/arch-rockchip/grf_rk3368.h | 617 >> +--- >> drivers/pinctrl/rockchip/pinctrl_rk3368.c | 17 +- >> 2 files changed, 334 insertions(+), 300 deletions(-) >> >> diff --git a/arch/arm/
Re: [U-Boot] [PATCH] imx6: Add support for Phytec pfla02 (NAND)
Hi Fabio,
On 24/07/2017 14:37, Fabio Estevam wrote:
> Hi Stefano,
>
> On Mon, Jul 24, 2017 at 7:13 AM, Stefano Babic wrote:
>
>> +int board_mmc_getcd(struct mmc *mmc)
>> +{
>> + struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
>> + int ret = 0;
>> +
>> + switch (cfg->esdhc_base) {
>> + case USDHC2_BASE_ADDR:
>> + ret = !gpio_get_value(USDHC2_CD_GPIO);
>
> Is this GPIO read really needed?
>
>> + ret = 1;
>
GPIO is correct, but value should not be overwritten - thanks, I fix it
in V2.
> as it is overwritten here.
>
>> +#define PHYS_SDRAM_SIZE(1u * 1024 * 1024 * 1024)
>
> This definition seems to be unused.
Youz're right, I drop it.
Best regards,
Stefano
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: log EFI return values too
On 24.07.17 14:53, Rob Clark wrote:
On Mon, Jul 24, 2017 at 8:36 AM, Alexander Graf wrote:
On 24.07.17 13:59, Rob Clark wrote:
Turns out this is rather useful to tracking down where things fail.
Signed-off-by: Rob Clark
---
I've been carrying this around locally for a while.. but I find it
useful and I expect others would too.
include/efi_loader.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 043b29edd3..98d69a6dab 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -20,7 +20,10 @@
debug("EFI: Entry %s(" format ")\n", __func__, ##__VA_ARGS__); \
} while(0)
-#define EFI_EXIT(ret) efi_exit_func(ret);
+#define EFI_EXIT(ret) ({ \
For consistency, please follow the same construct as in EFI_ENTRY().
You mean the do { ... } while (0)? That won't work since EFI_EXIT()
has to evaluate to ret. Or did I misunderstand you.
Ah, right. No, I just misunderstood the reason for the change :).
+ debug("EFI: Exit: %s: %u\n", __func__, (u32)((ret) & 0x)); \
I guess you just want to mask out EFI_ERROR_MASK?
Yup.. is there a better way?
Yeah, & ~EFI_ERROR_MASK :).
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] zynq: fb_mmc: Correct cast of address to u32
On 07/24/2017 02:47 PM, Tom Rini wrote: > On Mon, Jul 24, 2017 at 02:09:56PM +0200, Marek Vasut wrote: >> On 07/23/2017 05:47 PM, Tom Rini wrote: >>> On Sun, Jul 23, 2017 at 09:05:31AM -0600, Simon Glass wrote: >>> This does not work on 64-bit machines. Update it to use ulong. This fixes the following warnings in some zynq boards; common/fb_mmc.c: In function 'fb_mmc_update_zimage': common/fb_mmc.c:188:13: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] common/fb_mmc.c:189:8: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Signed-off-by: Simon Glass >>> >>> I fixed this in a slightly different way a while ago and am waiting for >>> it to come in via the USB tree currently. >> >> MMC patch via USB ? Anyway, this should use uintptr_t I guess ? > > "fastboot" is USB gadget code, and comes via Lukasz. Unless you want me > to pick it up directly? Thanks! > The tags didn't indicate any such thing and I didn't see the entire patch since it was clipped, so ... anyway, if it's fastboot, it indeed goes via Lukasz. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
