Re: [U-Boot] [PATCH] ls1021a: QSPI: update the node for QSPI support

[Yao Yuan]

On 11/08/2016 02:27 AM, York Sun wrote:
> On 10/10/2016 11:09 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > Add the address value and size value name for QSPI dts node.
> 
> This message doesn't match the change. Do you call "QuadSPI" the address
> value name?
> 

Yes, I always call QuadSPI as QSPI.
Here
<0x155 0x1 > is the QSPI register space.
<0x4000 0x400> is the QSPI memory space.

So, need I update the QSPI as QuadSPI?

Thanks for your review.

> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm/dts/ls1021a.dtsi | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
> > index 119b1af..37be169 100644
> > --- a/arch/arm/dts/ls1021a.dtsi
> > +++ b/arch/arm/dts/ls1021a.dtsi
> > @@ -176,6 +176,7 @@
> > #size-cells = <0>;
> > reg = <0x155 0x1>,
> > <0x4000 0x400>;
> > +   reg-names = "QuadSPI", "QuadSPI-memory";
> > num-cs = <2>;
> > big-endian;
> > status = "disabled";
> >

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 01/21] sf: Adopt flash table INFO macro from Linux

[york sun]

On 10/30/2016 10:47 AM, Jagan Teki wrote:
> INFO macro make flash table entries more adjustable like
> adding new flash_info attributes, update ID length bytes
> and so on and more over it will sync to Linux way of defining
> flash_info attributes.
>
> - Add JEDEC_ID
> - Add JEDEC_EXT macro
> - Add JEDEC_MFR
> - spi_flash_params => spi_flash_info
> - params => info
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: York Sun 
> Cc: Vignesh R 
> Cc: Mugunthan V N 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/mtd/spi/sandbox.c |  10 +-
>  drivers/mtd/spi/sf_internal.h |  26 +++--
>  drivers/mtd/spi/sf_params.c   | 217 
> ++
>  drivers/mtd/spi/spi_flash.c   | 119 ---
>  include/linux/err.h   |   5 +
>  5 files changed, 205 insertions(+), 172 deletions(-)
>

I got compiling warning on the first patch (tested on top of master branch)

02: sf: Adopt flash table INFO macro from Linux
powerpc:  +   T1024RDB_SPIFLASH T2080QDS_SPIFLASH T1040RDB_NAND 
B4860QDS_SRIO_PCIE_BOOT T1042RDB_PI_SPIFLASH B4860QDS 
T1040RDB_SECURE_BOOT T1024QDS_SPIFLASH B4420QDS 
controlcenterd_36BIT_SDCARD T2081QDS T2080QDS T4240QDS T1040D4RDB 
T4240RDB_SDCARD T2080RDB_SDCARD T1024QDS_NAND T4240QDS_SRIO_PCIE_BOOT 
T1024RDB_NAND T2081QDS_SPIFLASH T1040QDS_SECURE_BOOT UCP1020 T4240RDB 
T4160QDS_NAND T1042D4RDB_SECURE_BOOT T1042RDB_SECURE_BOOT T2080RDB 
T4240QDS_SECURE_BOOT T1024QDS T1040RDB T1042RDB_PI_NAND T2080RDB_NAND 
T1042RDB_PI_SDCARD T1042D4RDB_NAND T2081QDS_NAND T4160QDS_SDCARD 
T2080QDS_SDCARD T1042RDB T4160QDS_SECURE_BOOT T1040RDB_SDCARD 
T2081QDS_SRIO_PCIE_BOOT T2080RDB_SECURE_BOOT B4860QDS_SECURE_BOOT 
T1040QDS T1042D4RDB B4860QDS_NAND T1040QDS_DDR4 T2080QDS_SECURE_BOOT 
T2080RDB_SPIFLASH T4240QDS_SDCARD T1024QDS_DDR4 T1040D4RDB_SDCARD 
T1040D4RDB_SPIFLASH T1024QDS_DDR4_SECURE_BOOT T2080QDS_NAND 
controlcenterd_36BIT_SDCARD_DEVELOP T2080QDS_SRIO_PCIE_BOOT 
UCP1020_SPIFLASH T1040D4RDB_NAND T4160QDS T4160RDB T1024QDS_SECURE_BOOT 
B4860QDS_SPIFLASH T1040RDB_SPIFLASH T1024RDB T4240QDS_NAND B4420QDS_NAND 
T1040D4RDB_SECURE_BOOT T2080RDB_SRIO_PCIE_BOOT T1024RDB_SECURE_BOOT 
T1024QDS_SDCARD T1042D4RDB_SPIFLASH T1042RDB_PI_NAND_SECURE_BOOT 
T1042D4RDB_SDCARD T2081QDS_SDCARD T1024RDB_SDCARD T1042RDB_PI 
B4420QDS_SPIFLASH
w+(T4240RDB,T1024RDB_SPIFLASH,T2080RDB_SECURE_BOOT,T2080QDS_SPIFLASH,B4860QDS_SECURE_BOOT,B4860QDS_SRIO_PCIE_BOOT,T1042RDB_PI_SPIFLASH,B4860QDS,T1024QDS_SPIFLASH,B4420QDS,controlcenterd_36BIT_SDCARD,T2081QDS,T2080QDS,T4240QDS,T1040D4RDB,T4240RDB_SDCARD,T2080RDB_SDCARD,T1024QDS_NAND,T4240QDS_SRIO_PCIE_BOOT,T1024RDB_NAND,T2081QDS_SPIFLASH,T1040QDS_SECURE_BOOT,UCP1020,T4160QDS_NAND,T1042D4RDB_SECURE_BOOT,T1042RDB_SECURE_BOOT,T2080RDB,T4240QDS_SECURE_BOOT,T2081QDS_SRIO_PCIE_BOOT,T1024QDS,T1040RDB,T1042RDB_PI_NAND,T2080RDB_NAND,T1042RDB_PI_SDCARD,T2081QDS_NAND,T4160QDS_SDCARD,T2080QDS_SDCARD,T1042RDB,T4160QDS_SECURE_BOOT,T1040RDB_SDCARD,T1040D4RDB_SPIFLASH,T1040QDS,T1042D4RDB,B4860QDS_NAND,T1040QDS_DDR4,T2080QDS_SECURE_BOOT,T2080RDB_SPIFLASH,T4240QDS_SDCARD,T1024QDS_DDR4,T1040D4RDB_SDCARD,T1024QDS_DDR4_SECURE_BOOT,T2080QDS_NAND,controlcenterd_36BIT_SDCARD_DEVELOP,T2080QDS_SRIO_PCIE_BOOT,UCP1020_SPIFLASH,T1040D4RDB_NAND,T4160QDS,T4160RDB,T1024QDS_SECURE_BOOT,B4860QDS_SPIFLASH,T1040RDB_SPIF
 
LASH,T1024RDB,T4240QDS_NAND,B4420QDS_NAND,T1040D4RDB_SECURE_BOOT,T2080RDB_SRIO_PCIE_BOOT,T1024RDB_SECURE_BOOT,T1024QDS_SDCARD,T1042D4RDB_SPIFLASH,T1042RDB_PI_NAND_SECURE_BOOT,T1040RDB_SECURE_BOOT,T1042D4RDB_NAND,T1042D4RDB_SDCARD,T2081QDS_SDCARD,T1040RDB_NAND,T1024RDB_SDCARD,B4420QDS_SPIFLASH,T1042RDB_PI)
 
../drivers/mtd/spi/spi_flash.c: In function 'spi_flash_scan':
w+(T4240RDB,T1024RDB_SPIFLASH,T2080RDB_SECURE_BOOT,T2080QDS_SPIFLASH,B4860QDS_SECURE_BOOT,B4860QDS_SRIO_PCIE_BOOT,T1042RDB_PI_SPIFLASH,B4860QDS,T1024QDS_SPIFLASH,B4420QDS,controlcenterd_36BIT_SDCARD,T2081QDS,T2080QDS,T4240QDS,T1040D4RDB,T4240RDB_SDCARD,T2080RDB_SDCARD,T1024QDS_NAND,T4240QDS_SRIO_PCIE_BOOT,T1024RDB_NAND,T2081QDS_SPIFLASH,T1040QDS_SECURE_BOOT,UCP1020,T4160QDS_NAND,T1042D4RDB_SECURE_BOOT,T1042RDB_SECURE_BOOT,T2080RDB,T4240QDS_SECURE_BOOT,T2081QDS_SRIO_PCIE_BOOT,T1024QDS,T1040RDB,T1042RDB_PI_NAND,T2080RDB_NAND,T1042RDB_PI_SDCARD,T2081QDS_NAND,T4160QDS_SDCARD,T2080QDS_SDCARD,T1042RDB,T4160QDS_SECURE_BOOT,T1040RDB_SDCARD,T1040D4RDB_SPIFLASH,T1040QDS,T1042D4RDB,B4860QDS_NAND,T1040QDS_DDR4,T2080QDS_SECURE_BOOT,T2080RDB_SPIFLASH,T4240QDS_SDCARD,T1024QDS_DDR4,T1040D4RDB_SDCARD,T1024QDS_DDR4_SECURE_BOOT,T2080QDS_NAND,controlcenterd_36BIT_SDCARD_DEVELOP,T2080QDS_SRIO_PCIE_BOOT,UCP1020_SPIFLASH,T1040D4RDB_NAND,T4160QDS,T4160RDB,T1024QDS_SECURE_BOOT,B4860QDS_SPIFLASH,T1040RDB_SPIF
 

Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.

[Yao Yuan]

On 11/08/2016 02:17 PM, York Sun wrote:
> On 10/16/2016 08:58 PM, Yao Yuan wrote:
> > Hi York,
> >
> > It seems arch/arm/cpu/armv8/fsl-layerscape/doc/README.* is better.
> > I will update my patch and resend soon.
> >
> 
> Did you send the update? BTW, I think you meant "deploy QSPI image" in the
> subject.
> 

Thanks for your reminder.
I will send it just now,

Thanks,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] armv8: fsl-layerscape: Add Readme for deploy QSPI image

[Yuan Yao]

From: Yuan Yao 

Signed-off-by: Yuan Yao 
---
Changed in v2:
Move the readme for QSPI deploy out of only for ls2080aqds.
---
 .../arm/cpu/armv8/fsl-layerscape/doc/README.deploy | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy 
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
new file mode 100644
index 000..25813b3
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
@@ -0,0 +1,44 @@
+Boot source support Overview
+---
+   1. LS1043A
+   LS1043AQDS:QSPI, SD, NOR, NAND
+   LS1043ARDB:SD, NOR, NAND
+   2. LS2080A
+   LS2080AQDS:QSPI, SD, NOR, NAND
+   LS2080ARDB:NOR, NAND
+   3. LS1012A
+   LS1012AQDS:QSPI
+   LS1012ARDB:QSPI
+   4. LS1046A
+   LS1046AQDS:QSPI, SD, NOR, NAND
+   LS1046ARDB:QSPI, SD
+
+Booting from QSPI
+---
+Booting from QSPI requires two images, RCW and u-boot-dtb.bin.
+The difference between QSPI boot RCW image and NOR boot image is the PBI
+command sequence for setting the boot location pointer. It's should point
+to the address for u-boot in QSPI flash.
+
+RCW image should be written to the beginning of QSPI flash device.
+Example of using u-boot command
+
+=> sf probe 0:0
+SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 
32 MiB
+=> sf erase 0 +
+SF: 65536 bytes @ 0x0 Erased: OK
+=> sf write  0 
+SF: 164 bytes @ 0x0 Written: OK
+
+To get the QSPI image, build u-boot with QSPI config, for example,
+_qspi_defconfig. The image needed is u-boot-dtb.bin.
+The u-boot image should be written to 0x1(but 0x1000 for LS1043A, LS2080A).
+
+=> sf probe 0:0
+SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 
32 MiB
+=> sf erase 1 +
+SF: 589824 bytes @ 0x1 Erased: OK
+=> sf write  1 
+SF: 580966 bytes @ 0x1 Written: OK
+
+With these two images in QSPI flash device, the board can boot from QSPI.
-- 
2.1.0.27.g96db324

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: QSPI: Add AHB bus 16MB+ size support

[Yao Yuan]

On 11/08/2016 02:27 AM, York Sun wrote:
> On 10/25/2016 07:10 PM, Yuan Yao wrote:
> > From: Yuan Yao 
> >
> > The default configuration for QSPI AHB bus can't support 16MB+.
> > But some flash on NXP layerscape board are more than 16MB.
> 
> So what do you do?
> 
> Is this an erratum workaround? If yes, please refer the erratum number.

Hi York,

I think It's not an erratum maybe it's better to call it new feature.

As a default configuration for QSPI AHB, the address size is 3-bytes.
It has a good compatibility for QSPI boot for different SPI-NOR flash.

But if the address size is only 3-bytes, the QSPI can't access to the data that 
more than 16M+.

So we can update the default configuration for QSPI AHB in uboot to use 4-bytes 
address.
So that QSPI can access to 16M+ size by AHB bus.

Thanks.
> 
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 37
> ++
> >  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
> > .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
> >  include/configs/ls1012a_common.h   |  1 +
> >  include/configs/ls1046ardb.h   |  1 +
> >  5 files changed, 41 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index d68eeba..18d753e 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -370,6 +370,40 @@ void fsl_lsch2_early_init_f(void)  }  #endif
> >
> > +#ifdef CONFIG_QSPI_AHB_INIT
> > +/* Enable 4bytes address support and fast read */ int
> > +qspi_ahb_init(void) {
> > +   u32 *qspi_lut, lut_key, *qspi_key;
> > +
> > +   qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
> > +   qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
> > +
> > +   lut_key = in_be32(qspi_key);
> > +
> > +   if (lut_key == 0x5af05af0) {
> > +   /* That means the register is BE */
> > +   out_be32(qspi_key, 0x5af05af0);
> > +   out_be32(qspi_key + 1, 0x0002);
> > +   out_be32(qspi_lut, 0x0820040c);
> > +   out_be32(qspi_lut + 1, 0x1c080c08);
> > +   out_be32(qspi_lut + 2, 0x2400);
> > +   out_be32(qspi_key, 0x5af05af0);
> > +   out_be32(qspi_key + 1, 0x0001);
> > +   } else {
> > +   /* That means the register is LE */
> > +   out_le32(qspi_key, 0x5af05af0);
> > +   out_le32(qspi_key + 1, 0x0002);
> > +   out_le32(qspi_lut, 0x0820040c);
> > +   out_le32(qspi_lut + 1, 0x1c080c08);
> > +   out_le32(qspi_lut + 2, 0x2400);
> > +   out_le32(qspi_key, 0x5af05af0);
> > +   out_le32(qspi_key + 1, 0x0001);
> > +   }
> 
> What do these sequences do?

It used to set the AHB bus to use 4-bytes command and the corresponding 
sequence.
So that QSPI can access to 16M+ size by AHB bus.

> 
> Put a blank line before return.
> 
> > +   return 0;
> > +}
> > +#endif
> > +
> >  #ifdef CONFIG_BOARD_LATE_INIT
> >  int board_late_init(void)
> >  {
> > @@ -379,6 +413,9 @@ int board_late_init(void)  #ifdef
> > CONFIG_CHAIN_OF_TRUST
> > fsl_setenv_chain_of_trust();
> >  #endif
> > +#ifdef CONFIG_QSPI_AHB_INIT
> > +   qspi_ahb_init();
> > +#endif
> >
> > return 0;
> >  }
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> > index d88543d..a28b1fd 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> > @@ -18,6 +18,7 @@
> >  #define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR +
> 0x0018)
> >  #define CONFIG_SYS_GIC400_ADDR (CONFIG_SYS_IMMR +
> 0x0040)
> >  #define CONFIG_SYS_IFC_ADDR(CONFIG_SYS_IMMR +
> 0x0053)
> > +#define CONFIG_SYS_QSPI_ADDR   (CONFIG_SYS_IMMR +
> 0x0055)
> >  #define CONFIG_SYS_FSL_ESDHC_ADDR  (CONFIG_SYS_IMMR +
> 0x0056)
> >  #define CONFIG_SYS_FSL_CSU_ADDR
>   (CONFIG_SYS_IMMR + 0x0051)
> >  #define CONFIG_SYS_FSL_GUTS_ADDR   (CONFIG_SYS_IMMR +
> 0x00ee)
> > diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > index 7acba27..8aefc76 100644
> > --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> > @@ -19,6 +19,7 @@
> >  #define CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR   (CONFIG_SYS_IMMR +
> 0x0030)
> >  #define CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR   (CONFIG_SYS_IMMR +
> 0x0031)
> >  #define CONFIG_SYS_FSL_CH3_CLK_CTRL_ADDR   (CONFIG_SYS_IMMR +
> 0x0037)
> > +#define CONFIG_SYS_QSPI_ADDR   (CONFIG_SYS_IMMR +
> 0x010c)
> >  #define CONFIG_SYS_FSL_ESDHC_ADDR  (CONFIG_SYS_IMMR +
> 0x0114)
> >  #define 

Re: [U-Boot] [PATCH] ls1021a: QSPI: update the node for QSPI support

[Yao Yuan]

On 11/08/2016 12:46 PM, York Sun wrote:
> On 11/07/2016 07:58 PM, Yao Yuan wrote:
> > On 11/08/2016 02:27 AM, York Sun wrote:
> >> On 10/10/2016 11:09 PM, Yuan Yao wrote:
> >>> From: Yuan Yao 
> >>>
> >>> Add the address value and size value name for QSPI dts node.
> >>
> >> This message doesn't match the change. Do you call "QuadSPI" the
> >> address value name?
> >>
> >
> > Yes, I always call QuadSPI as QSPI.
> > Here
> > <0x155 0x1 > is the QSPI register space.
> > <0x4000 0x400> is the QSPI memory space.
> >
> > So, need I update the QSPI as QuadSPI?
> 
> You have QSPI register space and memory space. I can understand those.
> But your commit message says "Add address value and size value name". I can't
> match which one is which.
> 
OK, Get it.
I will update the commit message to resend it soon.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5] efi_loader: console: Correctly report modes

[Emmanuel Vadot]

Add support for EFI console modes.
Mode 0 is always 80x25 and present by EFI specification.
Mode 1 is always 80x50 and not mandatory.
Mode 2 and above is freely usable.

If the terminal can handle mode 1, we mark it as supported.
If the terminal size is greater than mode 0 and different than mode 1,
we install it as mode 2.

Modes can be switch with cout_set_mode.

Changes in V5:
 Correctly detect mode before enabling mode 2.

Changes in V4:
 Reset cursor positon on mode switch
 Use local variables in console query code

Changes in V3:
 Valid mode are 0 to EFIMode-1
 Fix style

Changes in V2:
 Add mode switch
 Report only the modes that we support

Signed-off-by: Emmanuel Vadot 
---
 lib/efi_loader/efi_console.c | 100 ---
 1 file changed, 84 insertions(+), 16 deletions(-)

diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 2e0228c..8ef7326 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -9,11 +9,38 @@
 #include 
 #include 
 
-/* If we can't determine the console size, default to 80x24 */
-static int console_columns = 80;
-static int console_rows = 24;
 static bool console_size_queried;
 
+#define EFI_COUT_MODE_2 2
+#define EFI_MAX_COUT_MODE 3
+
+struct cout_mode {
+   unsigned long columns;
+   unsigned long rows;
+   int present;
+};
+
+static struct cout_mode efi_cout_modes[] = {
+   /* EFI Mode 0 is 80x25 and always present */
+   {
+   .columns = 80,
+   .rows = 25,
+   .present = 1,
+   },
+   /* EFI Mode 1 is always 80x50 */
+   {
+   .columns = 80,
+   .rows = 50,
+   .present = 0,
+   },
+   /* Value are unknown until we query the console */
+   {
+   .columns = 0,
+   .rows = 0,
+   .present = 0,
+   },
+};
+
 const efi_guid_t efi_guid_console_control = CONSOLE_CONTROL_GUID;
 
 #define cESC '\x1b'
@@ -56,8 +83,9 @@ const struct efi_console_control_protocol efi_console_control 
= {
.lock_std_in = efi_cin_lock_std_in,
 };
 
+/* Default to mode 0 */
 static struct simple_text_output_mode efi_con_mode = {
-   .max_mode = 0,
+   .max_mode = 1,
.mode = 0,
.attribute = 0,
.cursor_column = 0,
@@ -131,8 +159,10 @@ static efi_status_t EFIAPI efi_cout_output_string(
struct efi_simple_text_output_protocol *this,
const unsigned short *string)
 {
+   struct cout_mode *mode;
u16 ch;
 
+   mode = _cout_modes[efi_con_mode.mode];
EFI_ENTRY("%p, %p", this, string);
for (;(ch = *string); string++) {
print_unicode_in_utf8(ch);
@@ -140,13 +170,12 @@ static efi_status_t EFIAPI efi_cout_output_string(
if (ch == '\n') {
efi_con_mode.cursor_column = 1;
efi_con_mode.cursor_row++;
-   } else if (efi_con_mode.cursor_column > console_columns) {
+   } else if (efi_con_mode.cursor_column > mode->columns) {
efi_con_mode.cursor_column = 1;
efi_con_mode.cursor_row++;
}
-   if (efi_con_mode.cursor_row > console_rows) {
-   efi_con_mode.cursor_row = console_rows;
-   }
+   if (efi_con_mode.cursor_row > mode->rows)
+   efi_con_mode.cursor_row = mode->rows;
}
 
return EFI_EXIT(EFI_SUCCESS);
@@ -160,6 +189,14 @@ static efi_status_t EFIAPI efi_cout_test_string(
return EFI_EXIT(EFI_SUCCESS);
 }
 
+static bool cout_mode_matches(struct cout_mode *mode, int rows, int cols)
+{
+   if (!mode->present)
+   return false;
+
+   return (mode->rows == rows) && (mode->columns == cols);
+}
+
 static efi_status_t EFIAPI efi_cout_query_mode(
struct efi_simple_text_output_protocol *this,
unsigned long mode_number, unsigned long *columns,
@@ -170,6 +207,8 @@ static efi_status_t EFIAPI efi_cout_query_mode(
if (!console_size_queried) {
/* Ask the terminal about its size */
int n[3];
+   int cols;
+   int rows;
u64 timeout;
 
console_size_queried = true;
@@ -191,15 +230,40 @@ static efi_status_t EFIAPI efi_cout_query_mode(
goto out;
}
 
-   console_columns = n[2];
-   console_rows = n[1];
+   cols = n[2];
+   rows = n[1];
+
+   /* Test if we can have Mode 1 */
+   if (cols >= 80 && rows >= 50) {
+   efi_cout_modes[1].present = 1;
+   efi_con_mode.max_mode = 2;
+   }
+
+   /*
+* Install our mode as mode 2 if it is different
+* than mode 0 

Re: [U-Boot] [PATCH v2] armv8: fsl-layerscape: Add Readme for deploy QSPI image

[york sun]

On 11/07/2016 07:52 PM, Yuan Yao wrote:
> From: Yuan Yao 
>
> Signed-off-by: Yuan Yao 
> ---
> Changed in v2:
>   Move the readme for QSPI deploy out of only for ls2080aqds.
> ---
>  .../arm/cpu/armv8/fsl-layerscape/doc/README.deploy | 44 
> ++
>  1 file changed, 44 insertions(+)
>  create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy 
> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> new file mode 100644
> index 000..25813b3
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> @@ -0,0 +1,44 @@
> +Boot source support Overview
> +---
> + 1. LS1043A
> + LS1043AQDS:QSPI, SD, NOR, NAND
> + LS1043ARDB:SD, NOR, NAND
> + 2. LS2080A
> + LS2080AQDS:QSPI, SD, NOR, NAND
> + LS2080ARDB:NOR, NAND
> + 3. LS1012A
> + LS1012AQDS:QSPI
> + LS1012ARDB:QSPI
> + 4. LS1046A
> + LS1046AQDS:QSPI, SD, NOR, NAND
> + LS1046ARDB:QSPI, SD
> +

If you plan to add all SD/NAND/QSPI into this document, it is OK to call 
it README.deploy. Otherwise it may be better to name as README.qspi.

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ls1021a: QSPI: update the node for QSPI support

[york sun]

On 11/07/2016 07:58 PM, Yao Yuan wrote:
> On 11/08/2016 02:27 AM, York Sun wrote:
>> On 10/10/2016 11:09 PM, Yuan Yao wrote:
>>> From: Yuan Yao 
>>>
>>> Add the address value and size value name for QSPI dts node.
>>
>> This message doesn't match the change. Do you call "QuadSPI" the address
>> value name?
>>
>
> Yes, I always call QuadSPI as QSPI.
> Here
> <0x155 0x1 > is the QSPI register space.
> <0x4000 0x400> is the QSPI memory space.
>
> So, need I update the QSPI as QuadSPI?

You have QSPI register space and memory space. I can understand those. 
But your commit message says "Add address value and size value name". I 
can't match which one is which.

York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] kconfig: fsl PPA: move CONFIG_* to Kconfig

[Z.Q. Hou]

Hi York,

Thanks for your comments!

> -Original Message-
> From: york sun
> Sent: 2016年11月8日 2:33
> To: Priyanka Jain ; Z.Q. Hou
> ; u-boot@lists.denx.de; albert.u.b...@aribaud.net;
> s...@chromium.org; bmeng...@gmail.com; h...@denx.de;
> yamada.masah...@socionext.com; Ruchika Gupta ;
> eddy.petri...@gmail.com; s.temerkha...@gmail.com; Prabhakar Kushwaha
> ; s...@denx.de; van.free...@gmail.com;
> fgret...@spaceteq.co.za; rpj...@crashcourse.ca; tr...@konsulko.com;
> Mingkai Hu 
> Subject: Re: [U-Boot] [PATCH 4/5] kconfig: fsl PPA: move CONFIG_* to Kconfig
> 
> On 10/24/2016 12:40 AM, Priyanka Jain wrote:
> >
> >
> >> -Original Message-
> >> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of
> >> Zhiqiang Hou
> >> Sent: Wednesday, October 12, 2016 2:56 PM
> >> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; york sun
> >> ; s...@chromium.org; bmeng...@gmail.com;
> h...@denx.de;
> >> yamada.masah...@socionext.com; Ruchika Gupta
> ;
> >> eddy.petri...@gmail.com; s.temerkha...@gmail.com; Prabhakar
> Kushwaha
> >> ; s...@denx.de; van.free...@gmail.com;
> >> fgret...@spaceteq.co.za; rpj...@crashcourse.ca; tr...@konsulko.com;
> >> Mingkai Hu 
> >> Cc: Z.Q. Hou 
> >> Subject: [U-Boot] [PATCH 4/5] kconfig: fsl PPA: move CONFIG_* to
> >> Kconfig
> >>
> >> From: Hou Zhiqiang 
> >>
> >> Signed-off-by: Hou Zhiqiang 
> >> ---
> >>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  | 29
> >> +  arch/arm/cpu/armv8/fsl-
> >> layerscape/Makefile |  2 +-
> >>  include/configs/ls1043ardb.h   |  7 ---
> >>  include/configs/ls1046ardb.h   |  7 ---
> >>  4 files changed, 30 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> index 94ec8d5..952db19 100644
> >> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> >> @@ -44,6 +44,35 @@ config FSL_LSCH3
> >>  menu "Layerscape architecture"
> >>depends on FSL_LSCH2 || FSL_LSCH3
> >>
> >> +menu "Layerscape PPA"
> >> +config FSL_LS_PPA
> >> +  bool "FSL Layerscape PPA firmware support"
> >> +  depends on ARCH_LS1043A || ARCH_LS1046A
> >> +  select ARMV8_PSCI
> >> +  select ARMV8_SEC_FIRMWARE_SUPPORT
> >> +  select ARMV8_SEC_FIRMWARE_ERET_ADDR_REVERT
> > ' ARMV8_SEC_FIRMWARE_ERET_ADDR_REVERT' macro is not required for
> chassis 3 platforms like LS2088A.
> > So there should be separate CONFIG_.. option for this.
> 
> Zhiqiang,
> 
> How will you handle lsch3?
> 
Will change it to 'select ARMV8_SEC_FIRMWARE_ERET_ADDR_REVERT if FSL_LSCH2', 
since SCFG is big-endian on FSL_LSCH2 but little-endian on FSL_LSCH3.

Thanks,
Zhiqiang

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] ext4: Allow reading files with non-zero offset, clamp read len

[Stephen Warren]

On 11/06/2016 10:33 AM, Stefan Brüns wrote:

Support was already implemented, but not hooked up. This fixes several
fails in the test cases.



diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c



/* Adjust len so it we can't read past the end of the file. */
-   if (len > filesize)
-   len = filesize;
+   if (len + pos > filesize)
+   len = (filesize - pos);


Nit: You don't need the ( ) around the expression there.

Acked-by: Stephen Warren 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] ARM: bcm283x: Implement EFI RTS reset_system

[Stephen Warren]

On 11/06/2016 03:24 AM, Alexander Graf wrote:



On 05/11/2016 23:01, Stephen Warren wrote:

On 11/02/2016 03:36 AM, Alexander Graf wrote:

The rpi has a pretty simple way of resetting the whole system. All it
takes
is to poke a few registers at a well defined location in MMIO space.

This patch adds support for the EFI loader implementation to allow an
OS to
reset and power off the system when we're outside of boot time.


(As an aside, I'm not sure why someone wanting EFI wouldn't just use a
complete EFI implementation such as TianoCore.)


diff --git a/arch/arm/mach-bcm283x/reset.c
b/arch/arm/mach-bcm283x/reset.c



+__efi_runtime_data struct bcm2835_wdog_regs *wdog_regs =
+(struct bcm2835_wdog_regs *)BCM2835_WDOG_PHYSADDR;
+
+void __efi_runtime reset_cpu(ulong addr)
 {
-struct bcm2835_wdog_regs *regs =
-(struct bcm2835_wdog_regs *)BCM2835_WDOG_PHYSADDR;


I'm not sure why that change is required. The value of the variable is
the same in both cases?


Take a look a few lines down in the patch:


+void efi_reset_system_init(void)
+{
+efi_add_runtime_mmio(_regs, sizeof(*wdog_regs));
+}


What this does is register a *pointer* as run time service pointer. What
does that mean?

When we enter RTS, Linux can map any region in the EFI memory map into a
different place in its own virtual memory map. So any pointers we use
inside RTS have to be relocated to the new locations.

For normal relocations, we move the relocations from linker time to run
time, so that we can relocate ourselves when Linux does the switch-over
to a new address space.

However, for MMIO that's trickier. That's where the
efi_add_runtime_mmio() function comes into play. It takes care of adding
the page around the references address to the EFI memory map as RTS MMIO
and relocates the pointer when Linux switches us into the new address
space.

Does that explain why we need to move from an inline address to an
address stored in a memory location?


So EFI RTS runs in the same exception level as the rich OS, and not in 
EL3? I would have expected EFI to run in EL3 with a completely separate 
MMU configuration. If that's not the case, then this part of the patch 
does make sense.



Perhaps it's trying to ensure that if this gets compiled into an ldr
instruction, the referenced data value is in a linker section that's
still around when EFI runs? If so fine, but how is that ensured for all
the other constants that this code uses, and if that happens
automatically due to the __efi_runtime marker above, why doesn't it work
for this one constant?

Does U-Boot have a halt/poweroff/shutdown shell command? If so, it might
be nice to enable it as part of this series, since the code to perform
that operation is now present.


That's what I originally wanted, yes :). Unfortunately due to the
relocation explained above, it's basically impossible for any reset
function that calls into MMIO space.

However, we do have it now for PSCI. If you have a PSCI enabled system,
we don't need to call into MMIO space and thus make the common reset
function available as RTS.


Can't the same U-Boot function be called both (a) during U-Boot runtime, 
where wdog_regs are pre-initialized to match U-Boot's MMU configuration, 
and (b) once the OS has booted, where wdog_regs has been modified 
according to the new memory map?


If not, one could implement a reset/powerdown/... function that takes 
the MMIO virtual address as a pointer, and then separate trivial 
wrappers that pass in either the static/U-Boot MMIO address, or the 
value of the EFI runtime variable that points at the MMIO mapping.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] rpi: passthrough of the firmware provided FDT blob

[Stephen Warren]

On 11/07/2016 07:44 AM, Cédric Schieli wrote:

Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
but this is not true anymore. The address now depends on both the
memory size and the blob size [1].

If one wants to passthrough this FDT blob to the kernel, the most
reliable way is to save its address from the r2/x0 register in the
U-Boot entry point and expose it in a environment variable for
further processing.

This patch just does this:
- save the provided address in the global variable fw_dtb_pointer
- expose it in ${fdt_addr} if it points to a a valid FDT blob

There are many different ways to use it. One can, for example, use
the following script which will extract from the tree the command
line built by the firmware, then hand over the blob to a previously
loaded kernel:

if fdt addr ${fdt_addr}
then
fdt get value bootargs /chosen bootargs
bootz ${kernel_addr_r} - ${fdt_addr}
fi


FWIW, I'd just hard-code the commands into any script that I wrote, and 
avoid the if test completely. If the FW doesn't pass a DTB, the system 
isn't going to boot correctly anyway, and I'd only use this custom 
script in a situation I know that it'd work.



Alternatively, users relying on sysboot/pxe can simply omit any FDT
statement in their extlinux.conf file, U-Boot will automagically pick
${fdt_addr} and pass it to the kernel.

Please note that for this to work the U-Boot binary must be tagged
with a recent version of the mkknlimg script found in the Rasperry
Fundation's kernel tree:

/scripts/mkknlimg --dtok /u-boot.bin /boot/u-boot.bin

[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018


I believe the very latest firmware has been fixed to default to DTB 
rather than ATAGs, since essentially nothing uses ATAGs any more. At 
least, Phil mentioned that sometime; I haven't tracked the status of 
that change or tested it.



diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c



+#ifdef CONFIG_ARM64
+void save_boot_params(unsigned long dtb)
+#else
+void save_boot_params(unsigned long r0, unsigned long r1, unsigned long dtb)
+#endif
+{
+   fw_dtb_pointer = dtb;
+   save_boot_params_ret();
+}


I think you need to write that function in assembly. This "function" is 
called very early during U-Boot startup, before any stack pointer is set 
up. You can't guarantee that a function written in C won't attempt to 
use the stack, although admittedly with the current code, Makefile, and 
the Ubuntu compilers, it just happens not to.


Aside from that issue, this version looks fine.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/3] TI: Remove CONFIG_OMAP_COMMON in favor of CONFIG_ARCH_OMAP2

[Tom Rini]

With the move to arch/arm/mach-omap2 there are now very few uses of
CONFIG_OMAP_COMMON and further they can all be replaced with
CONFIG_ARCH_OMAP2, so do so.

Signed-off-by: Tom Rini 
---
 arch/arm/config.mk | 2 +-
 arch/arm/include/asm/global_data.h | 2 +-
 arch/arm/include/asm/ti-common/sys_proto.h | 2 +-
 include/configs/am3517_crane.h | 1 -
 include/configs/am3517_evm.h   | 1 -
 include/configs/bur_am335x_common.h| 1 -
 include/configs/cm_t335.h  | 2 --
 include/configs/cm_t35.h   | 1 -
 include/configs/cm_t3517.h | 1 -
 include/configs/kc1.h  | 1 -
 include/configs/mcx.h  | 1 -
 include/configs/nokia_rx51.h   | 1 -
 include/configs/omap3_evm.h| 1 -
 include/configs/siemens-am33x-common.h | 1 -
 include/configs/sniper.h   | 1 -
 include/configs/tam3517-common.h   | 1 -
 include/configs/tao3530.h  | 1 -
 include/configs/ti814x_evm.h   | 1 -
 include/configs/ti816x_evm.h   | 1 -
 include/configs/ti_armv7_omap.h| 1 -
 include/configs/tricorder.h| 1 -
 21 files changed, 3 insertions(+), 22 deletions(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 542b897c31e0..d1be266d8886 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -6,7 +6,7 @@
 #
 
 ifndef CONFIG_STANDALONE_LOAD_ADDR
-ifneq ($(CONFIG_OMAP_COMMON),)
+ifneq ($(CONFIG_ARCH_OMAP2),)
 CONFIG_STANDALONE_LOAD_ADDR = 0x8030
 else
 CONFIG_STANDALONE_LOAD_ADDR = 0xc10
diff --git a/arch/arm/include/asm/global_data.h 
b/arch/arm/include/asm/global_data.h
index 10550174df4b..aee87cdcbf9e 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -60,7 +60,7 @@ struct arch_global_data {
unsigned long tlb_allocated;
 #endif
 
-#ifdef CONFIG_OMAP_COMMON
+#ifdef CONFIG_ARCH_OMAP2
u32 omap_boot_device;
u32 omap_boot_mode;
u8 omap_ch_flags;
diff --git a/arch/arm/include/asm/ti-common/sys_proto.h 
b/arch/arm/include/asm/ti-common/sys_proto.h
index 2bdb71cfe8e5..60d1160459bb 100644
--- a/arch/arm/include/asm/ti-common/sys_proto.h
+++ b/arch/arm/include/asm/ti-common/sys_proto.h
@@ -9,7 +9,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifdef CONFIG_OMAP_COMMON
+#ifdef CONFIG_ARCH_OMAP2
 #define TI_ARMV7_DRAM_ADDR_SPACE_START 0x8000
 #define TI_ARMV7_DRAM_ADDR_SPACE_END   0x
 
diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h
index 7f0c0cfa32e7..d63f5f8943dd 100644
--- a/include/configs/am3517_crane.h
+++ b/include/configs/am3517_crane.h
@@ -18,7 +18,6 @@
  */
 #define CONFIG_OMAP1   /* in a TI OMAP core */
 #define CONFIG_OMAP3_AM3517CRANE   1   /* working with CRANEBOARD */
-#define CONFIG_OMAP_COMMON
 /* Common ARM Erratas */
 #define CONFIG_ARM_ERRATA_454179
 #define CONFIG_ARM_ERRATA_430973
diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h
index ab6d5f105191..5dcd120ba064 100644
--- a/include/configs/am3517_evm.h
+++ b/include/configs/am3517_evm.h
@@ -16,7 +16,6 @@
 /* High Level Configuration Options */
 
 #define CONFIG_OMAP
-#define CONFIG_OMAP_COMMON
 
 #define CONFIG_SYS_NO_FLASH
 
diff --git a/include/configs/bur_am335x_common.h 
b/include/configs/bur_am335x_common.h
index 90698614d9a9..7afffa2ec647 100644
--- a/include/configs/bur_am335x_common.h
+++ b/include/configs/bur_am335x_common.h
@@ -14,7 +14,6 @@
 /* - */
 #define CONFIG_AM33XX
 #define CONFIG_OMAP
-#define CONFIG_OMAP_COMMON
 #define CONFIG_MAX_RAM_BANK_SIZE   (1024 << 20)/* 1GB */
 
 /* Timer information */
diff --git a/include/configs/cm_t335.h b/include/configs/cm_t335.h
index ae4f287e4d48..8f24174a21e7 100644
--- a/include/configs/cm_t335.h
+++ b/include/configs/cm_t335.h
@@ -25,8 +25,6 @@
 #undef CONFIG_MAX_RAM_BANK_SIZE
 #define CONFIG_MAX_RAM_BANK_SIZE   (512 << 20) /* 512MB */
 
-#define CONFIG_OMAP_COMMON
-
 #define MACH_TYPE_CM_T335  4586/* Until the next sync */
 #define CONFIG_MACH_TYPE   MACH_TYPE_CM_T335
 
diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h
index 2de170fb56b7..73f6f1f9925c 100644
--- a/include/configs/cm_t35.h
+++ b/include/configs/cm_t35.h
@@ -25,7 +25,6 @@
 #define CONFIG_OMAP/* in a TI OMAP core */
 #define CONFIG_OMAP_GPIO
 #define CONFIG_CM_T3X  /* working with CM-T35 and CM-T3730 */
-#define CONFIG_OMAP_COMMON
 /* Common ARM Erratas */
 #define CONFIG_ARM_ERRATA_454179
 #define CONFIG_ARM_ERRATA_430973
diff --git a/include/configs/cm_t3517.h b/include/configs/cm_t3517.h
index edb52be5a83c..1e2a47702756 100644
--- a/include/configs/cm_t3517.h
+++ b/include/configs/cm_t3517.h
@@ -15,7 +15,6 @@
  */
 #define CONFIG_OMAP/* in a TI OMAP core */
 #define CONFIG_CM_T3517

[U-Boot] [PATCH 2/3] arm: Introduce arch/arm/mach-omap2 for OMAP2 derivative platforms

[Tom Rini]

This moves what was in arch/arm/cpu/armv7/omap-common in to
arch/arm/mach-omap2 and moves
arch/arm/cpu/armv7/{am33xx,omap3,omap4,omap5} in to arch/arm/mach-omap2
as subdirectories.  All refernces to the former locations are updated to
the current locations.  For the logic to decide what our outputs are,
consolidate the tests into a single config.mk rather than including 4.

Signed-off-by: Tom Rini 
---
 arch/arm/Kconfig   |  5 ++---
 arch/arm/Makefile  |  1 +
 arch/arm/cpu/armv7/Makefile|  5 -
 arch/arm/cpu/armv7/omap3/config.mk | 15 ---
 arch/arm/cpu/armv7/omap4/config.mk | 15 ---
 arch/arm/cpu/armv7/omap5/config.mk | 22 --
 .../{cpu/armv7/omap-common => mach-omap2}/Kconfig  |  8 
 .../{cpu/armv7/omap-common => mach-omap2}/Makefile |  7 ++-
 .../{cpu/armv7/omap-common => mach-omap2}/abb.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/am33xx/Kconfig  |  0
 arch/arm/{cpu/armv7 => mach-omap2}/am33xx/Makefile |  0
 arch/arm/{cpu/armv7 => mach-omap2}/am33xx/board.c  |  0
 .../armv7 => mach-omap2}/am33xx/clk_synthesizer.c  |  0
 arch/arm/{cpu/armv7 => mach-omap2}/am33xx/clock.c  |  0
 .../armv7 => mach-omap2}/am33xx/clock_am33xx.c |  0
 .../armv7 => mach-omap2}/am33xx/clock_am43xx.c |  0
 .../armv7 => mach-omap2}/am33xx/clock_ti814x.c |  0
 .../armv7 => mach-omap2}/am33xx/clock_ti816x.c |  0
 arch/arm/{cpu/armv7 => mach-omap2}/am33xx/ddr.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/am33xx/emif4.c  |  0
 arch/arm/{cpu/armv7 => mach-omap2}/am33xx/mux.c|  0
 .../{cpu/armv7 => mach-omap2}/am33xx/sys_info.c|  0
 .../armv7 => mach-omap2}/am33xx/u-boot-spl.lds |  0
 .../armv7/omap-common => mach-omap2}/boot-common.c |  0
 .../omap-common => mach-omap2}/clocks-common.c |  0
 .../arm/{cpu/armv7/am33xx => mach-omap2}/config.mk | 19 ---
 .../omap-common => mach-omap2}/config_secure.mk|  0
 .../armv7/omap-common => mach-omap2}/emif-common.c |  0
 .../omap-common => mach-omap2}/hwinit-common.c |  0
 .../omap-common => mach-omap2}/lowlevel_init.S |  0
 .../armv7/omap-common => mach-omap2}/mem-common.c  |  0
 .../armv7/omap-common => mach-omap2}/omap-cache.c  |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap3/Kconfig   |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap3/Makefile  |  0
 .../{cpu/armv7 => mach-omap2}/omap3/am35x_musb.c   |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap3/board.c   |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap3/boot.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap3/clock.c   |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap3/emac.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap3/emif4.c   |  0
 .../armv7 => mach-omap2}/omap3/lowlevel_init.S |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap3/sdrc.c|  0
 .../{cpu/armv7 => mach-omap2}/omap3/spl_id_nand.c  |  0
 .../arm/{cpu/armv7 => mach-omap2}/omap3/sys_info.c |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap4/Kconfig   |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap4/Makefile  |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap4/boot.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap4/emif.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap4/hw_data.c |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap4/hwinit.c  |  0
 .../{cpu/armv7 => mach-omap2}/omap4/prcm-regs.c|  0
 .../{cpu/armv7 => mach-omap2}/omap4/sdram_elpida.c |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/Kconfig   |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/Makefile  |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/abb.c |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/boot.c|  0
 .../armv7 => mach-omap2}/omap5/dra7xx_iodelay.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/emif.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/fdt.c |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/hw_data.c |  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/hwinit.c  |  0
 .../{cpu/armv7 => mach-omap2}/omap5/prcm-regs.c|  0
 arch/arm/{cpu/armv7 => mach-omap2}/omap5/sdram.c   |  0
 .../arm/{cpu/armv7 => mach-omap2}/omap5/sec-fxns.c |  0
 .../armv7/omap-common => mach-omap2}/pipe3-phy.c   |  0
 .../armv7/omap-common => mach-omap2}/pipe3-phy.h   |  0
 .../{cpu/armv7/omap-common => mach-omap2}/reset.c  |  0
 .../{cpu/armv7/omap-common => mach-omap2}/sata.c   |  0
 .../armv7/omap-common => mach-omap2}/sec-common.c  |  0
 .../{cpu/armv7/omap-common => mach-omap2}/timer.c  |  0
 .../omap-common => mach-omap2}/u-boot-spl.lds  |  0
 .../{cpu/armv7/omap-common => mach-omap2}/utils.c  |  0
 .../arm/{cpu/armv7/omap-common => mach-omap2}/vc.c |  0
 include/configs/am335x_evm.h   |  2 +-
 include/configs/am335x_igep0033.h  |  2 +-
 include/configs/am335x_shc.h   |  2 +-
 include/configs/am335x_sl50.h  |  2 +-
 include/configs/am3517_crane.h |  2 +-
 

[U-Boot] [PATCH 0/3] arm: Move TI/omap related code to arch/arm/mach-omap2

[Tom Rini]

The following series moves the contents of arch/arm/cpu/armv7/omap-common to
arch/arm/mach-omap2/ and arch/arm/cpu/armv7{omap[345],am33xx} over to
sub-directories ofarch/arm/mach-omap2/.  I thought about moving them all to the
top level but I don't think that will add clarity to the situation.  I've also
consolidated the config.mk files into a single one in
arch/arm/mach-omap2/config.mk.  These changes have been boot tested on various
omap3/4/5 and am33xx platforms and built for all of ARM.  There are a few cases
where the sizes change slightly but it looks most likely to be due to strings
and filling.  I've examined a few of the cases in-depth and there's no "real"
changes that I can see.

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/3] arm: Introduce ARCH_OMAP2

[Tom Rini]

To start consolidating various TI-related code, introduce the ARCH_OMAP2
symbol.  While we have removed omap2-specific boards some time ago,
matching up with the kernel naming here will help overall.

Signed-off-by: Tom Rini 
---
 arch/arm/Kconfig | 50 --
 1 file changed, 20 insertions(+), 30 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11c766a..308245185b83 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -126,6 +126,11 @@ config ENABLE_ARM_SOC_BOOT0_HOOK
  ARM_SOC_BOOT0_HOOK which contains the required assembler
  preprocessor code.
 
+config ARCH_OMAP2
+   bool
+   select CPU_V7
+   select SUPPORT_SPL
+
 choice
prompt "Target select"
default TARGET_HIKEY
@@ -327,71 +332,61 @@ config TARGET_VEXPRESS_CA9X4
 
 config TARGET_BRXRE1
bool "Support BRXRE1"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
 
 config TARGET_BRPPT1
bool "Support BRPPT1"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
 
 config TARGET_DRACO
bool "Support draco"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
select DM
select DM_SERIAL
select DM_GPIO
 
 config TARGET_THUBAN
bool "Support thuban"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
select DM
select DM_SERIAL
select DM_GPIO
 
 config TARGET_RASTABAN
bool "Support rastaban"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
select DM
select DM_SERIAL
select DM_GPIO
 
 config TARGET_ETAMIN
bool "Support etamin"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
select DM
select DM_SERIAL
select DM_GPIO
 
 config TARGET_PXM2
bool "Support pxm2"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
select DM
select DM_SERIAL
select DM_GPIO
 
 config TARGET_RUT
bool "Support rut"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
select DM
select DM_SERIAL
select DM_GPIO
 
 config TARGET_TI814X_EVM
bool "Support ti814x_evm"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
 
 config TARGET_TI816X_EVM
bool "Support ti816x_evm"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
 
 config TARGET_BCM23550_W1D
bool "Support bcm23550_w1d"
@@ -486,25 +481,21 @@ config TARGET_MX53SMD
 
 config OMAP34XX
bool "OMAP34XX SoC"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
select USE_TINY_PRINTF
 
 config OMAP44XX
bool "OMAP44XX SoC"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
select USE_TINY_PRINTF
 
 config OMAP54XX
bool "OMAP54XX SoC"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
 
 config AM43XX
bool "AM43XX SoC"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
help
  Support for AM43xx SOC from Texas Instruments.
  The AM43xx high performance SOC features a Cortex-A9
@@ -514,8 +505,7 @@ config AM43XX
 
 config AM33XX
bool "AM33XX SoC"
-   select CPU_V7
-   select SUPPORT_SPL
+   select ARCH_OMAP2
help
  Support for AM335x SOC from Texas Instruments.
  The AM335x high performance SOC features a Cortex-A8
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] ARM: ts4600: add basic board support

[Sebastien Bourdelin]

Hi,

I found an problem with this patch on the last rev B of the TS4600
due to a DRAM timing issue.

Please do not consider this patch until i post an other one.

Sorry for the noise,

Regards.


On 11/07/2016 02:30 PM, Sebastien Bourdelin wrote:
> This commit adds basic support including:
> MMC, Serial console
> 
> Signed-off-by: Sebastien Bourdelin 
> 
> ---
> Changes v1 -> v2:
>   - remove useless define
>   - remove eMMC muxing and init which doesn't exist on the TS4600 board
>   - disable SSP1 and SSP2 clocks settings which are not currently used
> 
> Signed-off-by: Sebastien Bourdelin 
> ---
>  arch/arm/Kconfig |   6 ++
>  board/technologic/ts4600/Kconfig |  15 +
>  board/technologic/ts4600/MAINTAINERS |   6 ++
>  board/technologic/ts4600/Makefile|  11 
>  board/technologic/ts4600/iomux.c | 119 
> +++
>  board/technologic/ts4600/ts4600.c|  89 ++
>  configs/ts4600_defconfig |  18 ++
>  include/configs/ts4600.h |  70 +
>  8 files changed, 334 insertions(+)
>  create mode 100644 board/technologic/ts4600/Kconfig
>  create mode 100644 board/technologic/ts4600/MAINTAINERS
>  create mode 100644 board/technologic/ts4600/Makefile
>  create mode 100644 board/technologic/ts4600/iomux.c
>  create mode 100644 board/technologic/ts4600/ts4600.c
>  create mode 100644 configs/ts4600_defconfig
>  create mode 100644 include/configs/ts4600.h
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d7a9b11..142c445 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -579,6 +579,11 @@ config ARCH_SUNXI
>   select USB_KEYBOARD
>   select USE_TINY_PRINTF
>  
> +config TARGET_TS4600
> + bool "Support TS4600"
> + select CPU_ARM926EJS
> + select SUPPORT_SPL
> +
>  config TARGET_TS4800
>   bool "Support TS4800"
>   select CPU_V7
> @@ -1015,6 +1020,7 @@ source "board/ti/ti816x/Kconfig"
>  source "board/timll/devkit3250/Kconfig"
>  source "board/toradex/colibri_pxa270/Kconfig"
>  source "board/toradex/colibri_vf/Kconfig"
> +source "board/technologic/ts4600/Kconfig"
>  source "board/technologic/ts4800/Kconfig"
>  source "board/vscom/baltos/Kconfig"
>  source "board/woodburn/Kconfig"
> diff --git a/board/technologic/ts4600/Kconfig 
> b/board/technologic/ts4600/Kconfig
> new file mode 100644
> index 000..d0dc2e1
> --- /dev/null
> +++ b/board/technologic/ts4600/Kconfig
> @@ -0,0 +1,15 @@
> +if TARGET_TS4600
> +
> +config SYS_BOARD
> + default "ts4600"
> +
> +config SYS_VENDOR
> + default "technologic"
> +
> +config SYS_SOC
> + default "mxs"
> +
> +config SYS_CONFIG_NAME
> + default "ts4600"
> +
> +endif
> diff --git a/board/technologic/ts4600/MAINTAINERS 
> b/board/technologic/ts4600/MAINTAINERS
> new file mode 100644
> index 000..6f683b5
> --- /dev/null
> +++ b/board/technologic/ts4600/MAINTAINERS
> @@ -0,0 +1,6 @@
> +TS4600 BOARD
> +M:   Sebastien Bourdelin 
> +S:   Maintained
> +F:   board/technologic/ts4600/
> +F:   include/configs/ts4600.h
> +F:   configs/ts4600_defconfig
> diff --git a/board/technologic/ts4600/Makefile 
> b/board/technologic/ts4600/Makefile
> new file mode 100644
> index 000..faa2970
> --- /dev/null
> +++ b/board/technologic/ts4600/Makefile
> @@ -0,0 +1,11 @@
> +#
> +# (C) Copyright 2016 Savoir-faire Linux
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +ifndef   CONFIG_SPL_BUILD
> +obj-y:= ts4600.o
> +else
> +obj-y:= iomux.o
> +endif
> diff --git a/board/technologic/ts4600/iomux.c 
> b/board/technologic/ts4600/iomux.c
> new file mode 100644
> index 000..11d1723
> --- /dev/null
> +++ b/board/technologic/ts4600/iomux.c
> @@ -0,0 +1,119 @@
> +/*
> + * (C) Copyright 2016 Savoir-faire Linux Inc.
> + *
> + * Author: Sebastien Bourdelin 
> + *
> + * Based on work from TS7680 code by:
> + *   Kris Bahnsen 
> + *   Mark Featherston 
> + *   
> https://github.com/embeddedarm/u-boot/tree/master/board/technologic/ts7680
> + *
> + * Derived from MX28EVK code by
> + *   Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define  MUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
> +#define  MUX_CONFIG_EMI  (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
> +
> +const iomux_cfg_t iomux_setup[] = {
> + /* DUART */
> + MX28_PAD_PWM0__DUART_RX,
> + MX28_PAD_PWM1__DUART_TX,
> +
> + /* MMC0 */
> + MX28_PAD_SSP0_DATA0__SSP0_D0 | MUX_CONFIG_SSP0,
> + MX28_PAD_SSP0_DATA1__SSP0_D1 | MUX_CONFIG_SSP0,
> + MX28_PAD_SSP0_DATA2__SSP0_D2 | MUX_CONFIG_SSP0,
> + MX28_PAD_SSP0_DATA3__SSP0_D3 | MUX_CONFIG_SSP0,
> + 

Re: [U-Boot] [PATCH] net: use random ethernet address if invalid and not zero

[James Chargin]

Hi Joe,

Thanks for your reply.

On 11/07/2016 10:20 AM, Joe Hershberger wrote:

Hi Jim,

On Wed, Nov 2, 2016 at 8:21 AM, James Chargin  wrote:

Hi,

Regarding "invalid" Ethernet address.

Is there a reliable way to set the default environment that will prevent
Ethernet communications from being attempted.

That is, when an Ethernet capable system is brand new and before an Ethernet
MAC address has been assigned to that system during manufacturing with the
"setenv ethaddr" command, how can Ethernet comms be disabled?

This would be a fail-safe to make sure that part of the manufacturing
process is done correctly and that an Ethernet address is intentionally
assigned.


There is no feature like that as far as I know. Can you not just read
back the ethaddr variable and compare it to what you intended to
program?


I don't understand what you are suggesting, sorry.

A long time ago I wrote code

/*
 * This is an invalid MAC address.
 * Having it be invalid prevents connection to
 * the network until the U-Boot "setenv ethaddr"
 * command is run, which selects a valid MAC
 * Refer to the section titled "Null values" in
 * http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html.
 */
#define CONFIG_ETHADDR  ff:ff:ff:ff:ff:ff

The referenced section says, "... The all-zeros and all-ones EUI-64 
values, 00-00-00-00-00-00-00-00hex and FF-FF-FF-FF-FF-FF-FF-FFhex, 
respectively, are owned by the IEEE Registration Authority and will 
never be assigned, and are invalid for use as identifiers. ..." (which 
doesn't really apply to my case, but I was hopeful that I could 
generalize to my case)


At the time I wrote this code, I was trying to cope with a mfg process 
that was about to ship systems without setting correct MAC addresses. I 
was new to U-Boot at that time but found that U-Boot would not build 
without CONFIG_ETHADDR defined.


I subsequently checked again and found that U-Boot connects to the 
network regardless of the value of CONFIG_ETHADDR and even when it is 
not defined at compile-time or run-time.


I left it there, instead I made changes to the mfg process so that 
"setenv ethaddr" was more likely to always get done.


I would have liked a way to configure the default U-Boot environment so 
that no network connection could be made until a MAC address had been 
set, but I wasn't willing to spend any more time figuring out how to 
make that happen (possibly by submitting a patch upstream)


Jim
--
Jim Chargin
AJA Video Systems   j...@aja.com
(530) 271-3334  http://www.aja.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] kconfig: fsl PPA: move CONFIG_* to Kconfig

[york sun]

On 10/24/2016 12:40 AM, Priyanka Jain wrote:
>
>
>> -Original Message-
>> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Zhiqiang
>> Hou
>> Sent: Wednesday, October 12, 2016 2:56 PM
>> To: u-boot@lists.denx.de; albert.u.b...@aribaud.net; york sun
>> ; s...@chromium.org; bmeng...@gmail.com;
>> h...@denx.de; yamada.masah...@socionext.com; Ruchika Gupta
>> ; eddy.petri...@gmail.com;
>> s.temerkha...@gmail.com; Prabhakar Kushwaha
>> ; s...@denx.de; van.free...@gmail.com;
>> fgret...@spaceteq.co.za; rpj...@crashcourse.ca; tr...@konsulko.com;
>> Mingkai Hu 
>> Cc: Z.Q. Hou 
>> Subject: [U-Boot] [PATCH 4/5] kconfig: fsl PPA: move CONFIG_* to Kconfig
>>
>> From: Hou Zhiqiang 
>>
>> Signed-off-by: Hou Zhiqiang 
>> ---
>>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  | 29
>> +  arch/arm/cpu/armv8/fsl-
>> layerscape/Makefile |  2 +-
>>  include/configs/ls1043ardb.h   |  7 ---
>>  include/configs/ls1046ardb.h   |  7 ---
>>  4 files changed, 30 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>> index 94ec8d5..952db19 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
>> @@ -44,6 +44,35 @@ config FSL_LSCH3
>>  menu "Layerscape architecture"
>>  depends on FSL_LSCH2 || FSL_LSCH3
>>
>> +menu "Layerscape PPA"
>> +config FSL_LS_PPA
>> +bool "FSL Layerscape PPA firmware support"
>> +depends on ARCH_LS1043A || ARCH_LS1046A
>> +select ARMV8_PSCI
>> +select ARMV8_SEC_FIRMWARE_SUPPORT
>> +select ARMV8_SEC_FIRMWARE_ERET_ADDR_REVERT
> ' ARMV8_SEC_FIRMWARE_ERET_ADDR_REVERT' macro is not required for chassis 3 
> platforms like LS2088A.
> So there should be separate CONFIG_.. option for this.

Zhiqiang,

How will you handle lsch3?

York


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/9] dm: pci: return the real controller in pci_bus_to_hose()

[york sun]

On 10/11/2016 07:11 AM, M.H. Lian wrote:
>>
>> I got it. But this does not look that good to me. There are two controllers, 
>> and
>> bus number should be relative to the controller itself, not system wide. It's
>> definitely right to assign bus number 0 to both PCIe host controllers, as 
>> they
>> forward the bus number on their own bus link. I am wondering we should
>> add a controller number to the PCI command, like the storage device
>> command. The first parameter is the controller number, while the second
>> parameter is the bus number.
> [Minghuan Lian] Yes.  Linux uses "PCI domain" to isolate PCIe controllers.
> And config "CONFIG_PCI_DOMAINS" is to enable domain like controllers number.
> But, under Linux if disable "CONFIG_PCI_DOMAINS ", all PCIe controllers will 
> be assigned continuous  bus
> Number like the current uboot.
>

Where are we on this set?

York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/1] ARM: ts4600: add basic board support

[Sebastien Bourdelin]

This commit adds basic support including:
MMC, Serial console

Signed-off-by: Sebastien Bourdelin 

---
Changes v1 -> v2:
  - remove useless define
  - remove eMMC muxing and init which doesn't exist on the TS4600 board
  - disable SSP1 and SSP2 clocks settings which are not currently used

Signed-off-by: Sebastien Bourdelin 
---
 arch/arm/Kconfig |   6 ++
 board/technologic/ts4600/Kconfig |  15 +
 board/technologic/ts4600/MAINTAINERS |   6 ++
 board/technologic/ts4600/Makefile|  11 
 board/technologic/ts4600/iomux.c | 119 +++
 board/technologic/ts4600/ts4600.c|  89 ++
 configs/ts4600_defconfig |  18 ++
 include/configs/ts4600.h |  70 +
 8 files changed, 334 insertions(+)
 create mode 100644 board/technologic/ts4600/Kconfig
 create mode 100644 board/technologic/ts4600/MAINTAINERS
 create mode 100644 board/technologic/ts4600/Makefile
 create mode 100644 board/technologic/ts4600/iomux.c
 create mode 100644 board/technologic/ts4600/ts4600.c
 create mode 100644 configs/ts4600_defconfig
 create mode 100644 include/configs/ts4600.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..142c445 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -579,6 +579,11 @@ config ARCH_SUNXI
select USB_KEYBOARD
select USE_TINY_PRINTF
 
+config TARGET_TS4600
+   bool "Support TS4600"
+   select CPU_ARM926EJS
+   select SUPPORT_SPL
+
 config TARGET_TS4800
bool "Support TS4800"
select CPU_V7
@@ -1015,6 +1020,7 @@ source "board/ti/ti816x/Kconfig"
 source "board/timll/devkit3250/Kconfig"
 source "board/toradex/colibri_pxa270/Kconfig"
 source "board/toradex/colibri_vf/Kconfig"
+source "board/technologic/ts4600/Kconfig"
 source "board/technologic/ts4800/Kconfig"
 source "board/vscom/baltos/Kconfig"
 source "board/woodburn/Kconfig"
diff --git a/board/technologic/ts4600/Kconfig b/board/technologic/ts4600/Kconfig
new file mode 100644
index 000..d0dc2e1
--- /dev/null
+++ b/board/technologic/ts4600/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_TS4600
+
+config SYS_BOARD
+   default "ts4600"
+
+config SYS_VENDOR
+   default "technologic"
+
+config SYS_SOC
+   default "mxs"
+
+config SYS_CONFIG_NAME
+   default "ts4600"
+
+endif
diff --git a/board/technologic/ts4600/MAINTAINERS 
b/board/technologic/ts4600/MAINTAINERS
new file mode 100644
index 000..6f683b5
--- /dev/null
+++ b/board/technologic/ts4600/MAINTAINERS
@@ -0,0 +1,6 @@
+TS4600 BOARD
+M: Sebastien Bourdelin 
+S: Maintained
+F: board/technologic/ts4600/
+F: include/configs/ts4600.h
+F: configs/ts4600_defconfig
diff --git a/board/technologic/ts4600/Makefile 
b/board/technologic/ts4600/Makefile
new file mode 100644
index 000..faa2970
--- /dev/null
+++ b/board/technologic/ts4600/Makefile
@@ -0,0 +1,11 @@
+#
+# (C) Copyright 2016 Savoir-faire Linux
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifndef CONFIG_SPL_BUILD
+obj-y  := ts4600.o
+else
+obj-y  := iomux.o
+endif
diff --git a/board/technologic/ts4600/iomux.c b/board/technologic/ts4600/iomux.c
new file mode 100644
index 000..11d1723
--- /dev/null
+++ b/board/technologic/ts4600/iomux.c
@@ -0,0 +1,119 @@
+/*
+ * (C) Copyright 2016 Savoir-faire Linux Inc.
+ *
+ * Author: Sebastien Bourdelin 
+ *
+ * Based on work from TS7680 code by:
+ *   Kris Bahnsen 
+ *   Mark Featherston 
+ *   https://github.com/embeddedarm/u-boot/tree/master/board/technologic/ts7680
+ *
+ * Derived from MX28EVK code by
+ *   Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineMUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
+#defineMUX_CONFIG_EMI  (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_NOPULL)
+
+const iomux_cfg_t iomux_setup[] = {
+   /* DUART */
+   MX28_PAD_PWM0__DUART_RX,
+   MX28_PAD_PWM1__DUART_TX,
+
+   /* MMC0 */
+   MX28_PAD_SSP0_DATA0__SSP0_D0 | MUX_CONFIG_SSP0,
+   MX28_PAD_SSP0_DATA1__SSP0_D1 | MUX_CONFIG_SSP0,
+   MX28_PAD_SSP0_DATA2__SSP0_D2 | MUX_CONFIG_SSP0,
+   MX28_PAD_SSP0_DATA3__SSP0_D3 | MUX_CONFIG_SSP0,
+   MX28_PAD_SSP0_CMD__SSP0_CMD | MUX_CONFIG_SSP0,
+   MX28_PAD_SSP0_SCK__SSP0_SCK |
+   (MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_NOPULL),
+
+   /* MMC0 slot power enable */
+   MX28_PAD_PWM3__GPIO_3_28 |
+   (MXS_PAD_12MA | MXS_PAD_3V3 | MXS_PAD_PULLUP),
+
+   /* EMI */
+   MX28_PAD_EMI_D00__EMI_DATA0 | MUX_CONFIG_EMI,
+   MX28_PAD_EMI_D01__EMI_DATA1 | MUX_CONFIG_EMI,
+   MX28_PAD_EMI_D02__EMI_DATA2 | MUX_CONFIG_EMI,
+   MX28_PAD_EMI_D03__EMI_DATA3 | 

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/06/2016 06:21 PM, Alison Wang wrote:
>>
> [Alison Wang] Thanks for all your comments.
>
> For the issue about the tree would not be bisect-able, I have
> a solution. Actually it is the root cause that 64-bit kernel could not boot
> up when U-Boot is running in EL2. I will move these codes from the third patch
> to the first patch.
>
> ENTRY(armv8_switch_to_el2)
> switch_el x5, 1f, 0f, 0f
> -0: ret
> +   /*
> +* x3 is kernel entry point or switch_to_el1
> + * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.

I guess you meant EL2 here.

> + * When running in EL2 now, jump to the
> + * address saved in x3.
> +*/
> +0: br x3
>  1: armv8_switch_to_el2_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el2)
>
>  ENTRY(armv8_switch_to_el1)
> switch_el x5, 0f, 1f, 0f
> -0: ret
> +
> +   /*
> + * x3 is kernel entry point. When running in EL1
> + * now, jump to the address saved in x3.
> +*/
> +0: br x3
>  1: armv8_switch_to_el1_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el1)
>
> With this re-order, the bitsect issue will be fixed and there is not a point
> that kernel could not boot up.
>
> If you all agree with this re-order, I will send out the v8 patch includes the
> first, second and third patches.
>

Would it be a good idea to setup the simulator and verify booting process?

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: QSPI: Add AHB bus 16MB+ size support

[york sun]

On 10/25/2016 07:10 PM, Yuan Yao wrote:
> From: Yuan Yao 
>
> The default configuration for QSPI AHB bus can't support 16MB+.
> But some flash on NXP layerscape board are more than 16MB.

So what do you do?

Is this an erratum workaround? If yes, please refer the erratum number.

>
> Signed-off-by: Yuan Yao 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 37 
> ++
>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
>  include/configs/ls1012a_common.h   |  1 +
>  include/configs/ls1046ardb.h   |  1 +
>  5 files changed, 41 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index d68eeba..18d753e 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -370,6 +370,40 @@ void fsl_lsch2_early_init_f(void)
>  }
>  #endif
>
> +#ifdef CONFIG_QSPI_AHB_INIT
> +/* Enable 4bytes address support and fast read */
> +int qspi_ahb_init(void)
> +{
> + u32 *qspi_lut, lut_key, *qspi_key;
> +
> + qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
> + qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
> +
> + lut_key = in_be32(qspi_key);
> +
> + if (lut_key == 0x5af05af0) {
> + /* That means the register is BE */
> + out_be32(qspi_key, 0x5af05af0);
> + out_be32(qspi_key + 1, 0x0002);
> + out_be32(qspi_lut, 0x0820040c);
> + out_be32(qspi_lut + 1, 0x1c080c08);
> + out_be32(qspi_lut + 2, 0x2400);
> + out_be32(qspi_key, 0x5af05af0);
> + out_be32(qspi_key + 1, 0x0001);
> + } else {
> + /* That means the register is LE */
> + out_le32(qspi_key, 0x5af05af0);
> + out_le32(qspi_key + 1, 0x0002);
> + out_le32(qspi_lut, 0x0820040c);
> + out_le32(qspi_lut + 1, 0x1c080c08);
> + out_le32(qspi_lut + 2, 0x2400);
> + out_le32(qspi_key, 0x5af05af0);
> + out_le32(qspi_key + 1, 0x0001);
> + }

What do these sequences do?

Put a blank line before return.

> + return 0;
> +}
> +#endif
> +
>  #ifdef CONFIG_BOARD_LATE_INIT
>  int board_late_init(void)
>  {
> @@ -379,6 +413,9 @@ int board_late_init(void)
>  #ifdef CONFIG_CHAIN_OF_TRUST
>   fsl_setenv_chain_of_trust();
>  #endif
> +#ifdef CONFIG_QSPI_AHB_INIT
> + qspi_ahb_init();
> +#endif
>
>   return 0;
>  }
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> index d88543d..a28b1fd 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> @@ -18,6 +18,7 @@
>  #define CONFIG_SYS_CCI400_ADDR   (CONFIG_SYS_IMMR + 
> 0x0018)
>  #define CONFIG_SYS_GIC400_ADDR   (CONFIG_SYS_IMMR + 
> 0x0040)
>  #define CONFIG_SYS_IFC_ADDR  (CONFIG_SYS_IMMR + 0x0053)
> +#define CONFIG_SYS_QSPI_ADDR (CONFIG_SYS_IMMR + 0x0055)
>  #define CONFIG_SYS_FSL_ESDHC_ADDR(CONFIG_SYS_IMMR + 0x0056)
>  #define CONFIG_SYS_FSL_CSU_ADDR  (CONFIG_SYS_IMMR + 
> 0x0051)
>  #define CONFIG_SYS_FSL_GUTS_ADDR (CONFIG_SYS_IMMR + 0x00ee)
> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> index 7acba27..8aefc76 100644
> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> @@ -19,6 +19,7 @@
>  #define CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR (CONFIG_SYS_IMMR + 0x0030)
>  #define CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR (CONFIG_SYS_IMMR + 0x0031)
>  #define CONFIG_SYS_FSL_CH3_CLK_CTRL_ADDR (CONFIG_SYS_IMMR + 0x0037)
> +#define CONFIG_SYS_QSPI_ADDR (CONFIG_SYS_IMMR + 0x010c)
>  #define CONFIG_SYS_FSL_ESDHC_ADDR(CONFIG_SYS_IMMR + 0x0114)
>  #define CONFIG_SYS_IFC_ADDR  (CONFIG_SYS_IMMR + 0x0124)
>  #define CONFIG_SYS_NS16550_COM1  (CONFIG_SYS_IMMR + 
> 0x011C0500)
> diff --git a/include/configs/ls1012a_common.h 
> b/include/configs/ls1012a_common.h
> index 80603c9..c1e1102 100644
> --- a/include/configs/ls1012a_common.h
> +++ b/include/configs/ls1012a_common.h
> @@ -61,6 +61,7 @@
>
>  #define FSL_QSPI_FLASH_SIZE  (1 << 24)
>  #define FSL_QSPI_FLASH_NUM   2
> +#define CONFIG_QSPI_AHB_INIT
>
>  /*
>   * Environment
> diff --git a/include/configs/ls1046ardb.h b/include/configs/ls1046ardb.h
> index 2fe8fc1..662ecb1 100644
> --- a/include/configs/ls1046ardb.h
> +++ b/include/configs/ls1046ardb.h
> @@ -209,6 +209,7 @@
>  #define FSL_QSPI_FLASH_SIZE  (1 << 26)
>  

Re: [U-Boot] [PATCH] armv8: ls2080aqds: fix SGMII repeater settings

[york sun]

On 10/17/2016 01:33 AM, shh@gmail.com wrote:
> From: Shaohui Xie 
>
> The current value to check whether the PHY was configured has dependency
> on MC, it expects MC to start PCS AN, this is not true during boot up,
> so it should be changed to remove the dependency.
>
> The PHY's register space should be restore to default after accessing
> extended space.
>
> Signed-off-by: Shaohui Xie 
> ---
>  board/freescale/ls2080aqds/eth.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/board/freescale/ls2080aqds/eth.c 
> b/board/freescale/ls2080aqds/eth.c
> index 95ff68b..cf6791e 100644
> --- a/board/freescale/ls2080aqds/eth.c
> +++ b/board/freescale/ls2080aqds/eth.c
> @@ -144,8 +144,10 @@ static void sgmii_configure_repeater(int serdes_port)
>
>   mdelay(10);
>
> - if ((value & 0xfff) == 0x40f) {
> + if ((value & 0xfff) == 0x401) {
>   printf("DPMAC %d:PHY is . Configured\n", dpmac_id);
> + miiphy_write(dev[mii_bus], riser_phy_addr[dpmac],
> +  0x1f, 0);
>   continue;
>   }
>
> @@ -181,28 +183,29 @@ static void sgmii_configure_repeater(int serdes_port)
>   if (ret > 0)
>   goto error;
>
> - mdelay(1);
> + mdelay(100);

Why change the delay?

>   ret = miiphy_read(dev[mii_bus],
> riser_phy_addr[dpmac],
> 0x11, );
>   if (ret > 0)
>   goto error;
> - mdelay(10);
>
> - if ((value & 0xfff) == 0x40f) {
> + if ((value & 0xfff) == 0x401) {
>   printf("DPMAC %d :PHY is configured ",
>  dpmac_id);
>   printf("after setting repeater 0x%x\n",
>  value);
>   i = 5;
>   j = 5;
> - } else
> + } else {
>   printf("DPMAC %d :PHY is failed to ",
>  dpmac_id);
>   printf("configure the repeater 0x%x\n",
>  value);
>   }
> + }
>   }
> + miiphy_write(dev[mii_bus], riser_phy_addr[dpmac], 0x1f, 0);
>   }
>  error:
>   if (ret)
>

Prabhakar,

Do these changes look correct to you?

York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] driver: net: fsl-mc: Use aligned address for MC FW load

[york sun]

On 10/24/2016 01:05 AM, Priyanka Jain wrote:
> Firmware of Management Complex (MC) should be loaded at 512MB aligned
> address.
> So use aligned address for firmware load.
>
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> ---
>  drivers/net/fsl-mc/mc.c |   62 ++
>  1 files changed, 35 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
> index 1811b0f..c66340b 100644
> --- a/drivers/net/fsl-mc/mc.c
> +++ b/drivers/net/fsl-mc/mc.c
> @@ -29,6 +29,7 @@
>  DECLARE_GLOBAL_DATA_PTR;
>  static int mc_boot_status = -1;
>  static int mc_dpl_applied = -1;
> +static u64 mc_ram_aligned_base_addr;

Why do you need this static variable? You didn't use it.

>  #ifdef CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET
>  static int mc_aiop_applied = -1;
>  #endif
> @@ -87,12 +88,15 @@ void dump_mc_ccsr_regs(struct mc_ccsr_registers __iomem 
> *mc_ccsr_regs)
>  /**
>   * Copying MC firmware or DPL image to DDR
>   */
> -static int mc_copy_image(const char *title,
> -  u64 image_addr, u32 image_size, u64 mc_ram_addr)
> +static int mc_copy_image(const char *title, u64 image_addr,
> +  u32 image_size, u64 mc_ram_aligned_base_addr)
>  {
> - debug("%s copied to address %p\n", title, (void *)mc_ram_addr);
> - memcpy((void *)mc_ram_addr, (void *)image_addr, image_size);
> - flush_dcache_range(mc_ram_addr, mc_ram_addr + image_size);
> + debug("%s copied to address %p\n", title,
> +   (void *)mc_ram_aligned_base_addr);
> + memcpy((void *)mc_ram_aligned_base_addr,
> +(void *)image_addr, image_size);
> + flush_dcache_range(mc_ram_aligned_base_addr,
> +mc_ram_aligned_base_addr + image_size);
>   return 0;
>  }
>
> @@ -224,7 +228,8 @@ static int mc_fixup_dpc(u64 dpc_addr)
>   return 0;
>  }
>
> -static int load_mc_dpc(u64 mc_ram_addr, size_t mc_ram_size, u64 mc_dpc_addr)
> +static int load_mc_dpc(u64 mc_ram_aligned_base_addr, size_t mc_ram_size,
> +u64 mc_dpc_addr)
>  {
>   u64 mc_dpc_offset;
>  #ifndef CONFIG_SYS_LS_MC_DPC_IN_DDR
> @@ -246,7 +251,8 @@ static int load_mc_dpc(u64 mc_ram_addr, size_t 
> mc_ram_size, u64 mc_dpc_addr)
>* Load the MC DPC blob in the MC private DRAM block:
>*/
>  #ifdef CONFIG_SYS_LS_MC_DPC_IN_DDR
> - printf("MC DPC is preloaded to %#llx\n", mc_ram_addr + mc_dpc_offset);
> + printf("MC DPC is preloaded to %#llx\n",
> +mc_ram_aligned_base_addr + mc_dpc_offset);
>  #else
>   /*
>* Get address and size of the DPC blob stored in flash:
> @@ -270,18 +276,20 @@ static int load_mc_dpc(u64 mc_ram_addr, size_t 
> mc_ram_size, u64 mc_dpc_addr)
>   return -EINVAL;
>   }
>
> - mc_copy_image("MC DPC blob",
> -   (u64)dpc_fdt_hdr, dpc_size, mc_ram_addr + mc_dpc_offset);
> + mc_copy_image("MC DPC blob", (u64)dpc_fdt_hdr, dpc_size,
> +   mc_ram_aligned_base_addr + mc_dpc_offset);
>  #endif /* not defined CONFIG_SYS_LS_MC_DPC_IN_DDR */
>
> - if (mc_fixup_dpc(mc_ram_addr + mc_dpc_offset))
> + if (mc_fixup_dpc(mc_ram_aligned_base_addr + mc_dpc_offset))
>   return -EINVAL;
>
> - dump_ram_words("DPC", (void *)(mc_ram_addr + mc_dpc_offset));
> + dump_ram_words("DPC",
> +(void *)(mc_ram_aligned_base_addr + mc_dpc_offset));
>   return 0;
>  }
>
> -static int load_mc_dpl(u64 mc_ram_addr, size_t mc_ram_size, u64 mc_dpl_addr)
> +static int load_mc_dpl(u64 mc_ram_aligned_base_addr, size_t mc_ram_size,
> +u64 mc_dpl_addr)
>  {
>   u64 mc_dpl_offset;
>  #ifndef CONFIG_SYS_LS_MC_DPL_IN_DDR
> @@ -303,7 +311,8 @@ static int load_mc_dpl(u64 mc_ram_addr, size_t 
> mc_ram_size, u64 mc_dpl_addr)
>* Load the MC DPL blob in the MC private DRAM block:
>*/
>  #ifdef CONFIG_SYS_LS_MC_DPL_IN_DDR
> - printf("MC DPL is preloaded to %#llx\n", mc_ram_addr + mc_dpl_offset);
> + printf("MC DPL is preloaded to %#llx\n",
> +mc_ram_aligned_base_addr + mc_dpl_offset);
>  #else
>   /*
>* Get address and size of the DPL blob stored in flash:
> @@ -323,11 +332,12 @@ static int load_mc_dpl(u64 mc_ram_addr, size_t 
> mc_ram_size, u64 mc_dpl_addr)
>   return -EINVAL;
>   }
>
> - mc_copy_image("MC DPL blob",
> -   (u64)dpl_fdt_hdr, dpl_size, mc_ram_addr + mc_dpl_offset);
> + mc_copy_image("MC DPL blob", (u64)dpl_fdt_hdr, dpl_size,
> +   mc_ram_aligned_base_addr + mc_dpl_offset);
>  #endif /* not defined CONFIG_SYS_LS_MC_DPL_IN_DDR */
>
> - dump_ram_words("DPL", (void *)(mc_ram_addr + mc_dpl_offset));
> + dump_ram_words("DPL",
> +(void *)(mc_ram_aligned_base_addr + mc_dpl_offset));
>   return 0;
>  }
>
> @@ -364,7 

Re: [U-Boot] [PATCH] armv8: Add workaround for USB erratum A-009008

[york sun]

On 10/25/2016 12:03 AM, Suresh Gupta wrote:
> USB High Speed (HS) EYE Height Adjustment
> USB HS speed eye diagram fails with the default value at
> many corners, particularly at a high temperature
>
> Optimal eye at TXVREFTUNE value to 1001 is observed, change
> set the same vale.
>
> Signed-off-by: Sriram Dash 
> Signed-off-by: Rajesh Bhagat 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  6 ++
>  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 25 
> ++
>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  6 ++
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
>  4 files changed, 38 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index 94ec8d5..ec3e50d 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -12,6 +12,7 @@ config ARCH_LS1043A
>   select SYS_FSL_DDR_VER_50
>   select SYS_FSL_ERRATUM_A010315
>   select SYS_FSL_ERRATUM_A010539
> + select SYS_FSL_ERRATUM_A009008
>
>  config ARCH_LS1046A
>   bool
> @@ -21,6 +22,7 @@ config ARCH_LS1046A
>   select SYS_FSL_DDR_VER_50
>   select SYS_FSL_ERRATUM_A010539
>   select SYS_FSL_SRDS_2
> + select SYS_FSL_ERRATUM_A009008
>
>  config ARCH_LS2080A
>   bool
> @@ -30,6 +32,7 @@ config ARCH_LS2080A
>   select SYS_FSL_DDR_VER_50
>   select SYS_FSL_HAS_DP_DDR
>   select SYS_FSL_SRDS_2
> + select SYS_FSL_ERRATUM_A009008
>
>  config FSL_LSCH2
>   bool
> @@ -53,6 +56,9 @@ config SYS_FSL_ERRATUM_A010315
>  config SYS_FSL_ERRATUM_A010539
>   bool "Workaround for PIN MUX erratum A010539"
>
> +config SYS_FSL_ERRATUM_A009008
> + bool "Workaround for USB PHY erratum A009008"
> +
>  config MAX_CPUS
>   int "Maximum number of CPUs permitted for Layerscape"
>   default 4 if ARCH_LS1043A
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index d68eeba..88cced1 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -26,6 +26,29 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> +static void erratum_a009008(void)
> +{
> +#ifdef CONFIG_SYS_FSL_ERRATUM_A009008
> +#if defined(CONFIG_LS1043A) || defined(CONFIG_LS1046A)

I think it is better use CONFIG_ARCH_LS1046A which is defined by 
Kconfig. The old macros are defined in header file. We will convert them 
to use Kconfig eventually. Agree?

York
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function

[york sun]

On 11/07/2016 06:12 AM, Mark Rutland wrote:
> On Fri, Oct 28, 2016 at 09:35:37PM +, york sun wrote:
>> I am struggling on the dcache_disable() which implies all dcache is
>> flushed. I don't have a reasonable way to flush all if I want to skip
>> L3. I tried to benchmark flushing by VA to cover my entire 16GB memory.
>> It took 30+ seconds. On the other side, flushing by set/way and flushing
>> L3 together took 7 ms. If I only flush U-Boot stack in this function, it
>> can run really fast, but that defeats the purpose of flush all cache.
>>
>> I thought of parsing each set/way to find the address of each cache line
>> (I don't know how to do that yet), but the tag only contains physical
>> address not VA.
>
> With the MMU off, translation is an idmap (i.e. VA == PA), so if you
> have physical addresses, you can use those directly.
>
> That said, the presence and implementation of any mechanism to read
> addresses from the cache is IMPLEMENTATION DEFINED, so this will not be
> portable.
>
>> The ARM document shows example code to clean entire data or unified
>> cache to PoC, very similar to the code we have in U-Boot armv8/cache.S.
>
> Do you mean the "Example code for cache maintenance instructions"?
>
> In recent versions of the ARM ARM there's a large note explaining why
> this only works in very restricted scenarios (and cannot be used to
> affect system caches such as your L3).
>
> In the latest ARM ARM ("ARM DDI 0487A.k"), see page D3-1710.
>
>> Unless there are other cache maintenance instruction I am not aware of,
>> I don't see how to flush to PoC by set/way.
>
> Architecturally, Set/Way operations are not guaranteed to affect al
> caches prior to the PoC, and may require other IMPLEMENTATION DEFINED
> maintenance (e.g. MMIO control of system-level caches).
>

At this point, seeking alternative ways to clean entire cache without 
flushing L3 seems non-productive. I am going to stop here. Thanks for 
the discussion.

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8/ls1043a: Add the OCRAM initialization

[york sun]

On 10/27/2016 02:47 AM, Calvin Johnson wrote:
> Hi York,
>
>> -Original Message-
>> From: york sun
>> Sent: Wednesday, October 26, 2016 10:09 PM
>> To: Calvin Johnson ; Prabhakar Kushwaha 
>> ; Pratiyush
>> Srivastava ; u-boot@lists.denx.de; Mingkai Hu 
>> 
>> Cc: Hou Zhiqiang 
>> Subject: Re: [PATCH] armv8/ls1043a: Add the OCRAM initialization
>>
>> On 10/24/2016 09:30 PM, Calvin Johnson wrote:
>>
>> I wonder why we don't see ECC errors before this patch. We have
>> LS1043A boots on NAND, SD.
>>
>
> OCRAM has a requirement of initializing before first time "read".
> If user reads OCRAM before **initializing**; ECC error will come.  
> (u-boot is not handling this error for now).
>
> I can only guess the reason of not seeing this error as OCRAM never read 
> before any write.
> Even in case of Stack, data is first written and then read.
>

 Is there a case you want to read from OCRAM before writing anything to it? 
 Why don't we need to do so for SPL or
>> LSCH3?
>>>
>>> This issue will be seen ONLY in secure boot. It was reproduced on LS1043A 
>>> also.
>>>
>>
>> How about LSCH3? We have LS2080A secure boot.
>
> I don't know about LS2080A. Prabhakar or Ruchika(copied) may be able to 
> comment on this.
>

Please follow up on this thread. We need to understand when and where 
OCRAM needs to be cleared.

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ls1021a: QSPI: update the node for QSPI support

[york sun]

On 10/10/2016 11:09 PM, Yuan Yao wrote:
> From: Yuan Yao 
>
> Add the address value and size value name for QSPI dts node.

This message doesn't match the change. Do you call "QuadSPI" the address 
value name?

>
> Signed-off-by: Yuan Yao 
> ---
>  arch/arm/dts/ls1021a.dtsi | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
> index 119b1af..37be169 100644
> --- a/arch/arm/dts/ls1021a.dtsi
> +++ b/arch/arm/dts/ls1021a.dtsi
> @@ -176,6 +176,7 @@
>   #size-cells = <0>;
>   reg = <0x155 0x1>,
>   <0x4000 0x400>;
> + reg-names = "QuadSPI", "QuadSPI-memory";
>   num-cs = <2>;
>   big-endian;
>   status = "disabled";
>

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board/ls2080qds: add the procedure to deply QSPI image.

[york sun]

On 10/16/2016 08:58 PM, Yao Yuan wrote:
> Hi York,
>
> It seems arch/arm/cpu/armv8/fsl-layerscape/doc/README.* is better.
> I will update my patch and resend soon.
>

Did you send the update? BTW, I think you meant "deploy QSPI image" in 
the subject.

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: use random ethernet address if invalid and not zero

[Joe Hershberger]

Hi Jim,

On Wed, Nov 2, 2016 at 8:21 AM, James Chargin  wrote:
> Hi,
>
> Regarding "invalid" Ethernet address.
>
> Is there a reliable way to set the default environment that will prevent
> Ethernet communications from being attempted.
>
> That is, when an Ethernet capable system is brand new and before an Ethernet
> MAC address has been assigned to that system during manufacturing with the
> "setenv ethaddr" command, how can Ethernet comms be disabled?
>
> This would be a fail-safe to make sure that part of the manufacturing
> process is done correctly and that an Ethernet address is intentionally
> assigned.

There is no feature like that as far as I know. Can you not just read
back the ethaddr variable and compare it to what you intended to
program?

-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net: use random ethernet address if invalid and not zero

[Joe Hershberger]

Hi Michal,

https://patchwork.ozlabs.org/patch/690374/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net: mvgbe: Fix build error with CONFIG_PHYLIB

[Joe Hershberger]

Hi Chris,

https://patchwork.ozlabs.org/patch/689658/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: tegra: enable Ethernet on p2771-0000

[Joe Hershberger]

Hi Stephen,

https://patchwork.ozlabs.org/patch/668913/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net: phy: micrel: center FLP burst timing at 16ms

[Joe Hershberger]

Hi Ash,

https://patchwork.ozlabs.org/patch/685298/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: tegra: add DWC EQoS (ethernet) to Tegra186 DT

[Joe Hershberger]

Hi Stephen,

https://patchwork.ozlabs.org/patch/668912/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: tegra: configure Ethernet address on Tegra186

[Joe Hershberger]

Hi Stephen,

https://patchwork.ozlabs.org/patch/668911/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: tegra: add SoC-level hook for board_late_init()

[Joe Hershberger]

Hi Stephen,

https://patchwork.ozlabs.org/patch/668910/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net: add driver for Synopsys Ethernet QoS device

[Joe Hershberger]

Hi Stephen,

https://patchwork.ozlabs.org/patch/685273/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] dt: net: add DWC EQoS binding

[Joe Hershberger]

Hi Stephen,

https://patchwork.ozlabs.org/patch/685272/ was applied to u-boot-net.git.

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: u-boot-net.git master

[Joe Hershberger]

Hi Tom,

The following changes since commit 4b6035da482cccda06aeb419634f99937c9fc783:

  mx6sabresd: Make Ethernet functional again (2016-11-06 06:59:27 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-net.git master

for you to fetch changes up to aa555fe9f07a21b3bbdab15aea594f3869e5ab22:

  net: use random ethernet address if invalid and not zero (2016-11-07 11:28:16 
-0600)


Ash Charles (1):
  net: phy: micrel: center FLP burst timing at 16ms

Chris Packham (1):
  net: mvgbe: Fix build error with CONFIG_PHYLIB

Siva Durga Prasad Paladugu (1):
  net: use random ethernet address if invalid and not zero

Stephen Warren (6):
  dt: net: add DWC EQoS binding
  net: add driver for Synopsys Ethernet QoS device
  ARM: tegra: add SoC-level hook for board_late_init()
  ARM: tegra: configure Ethernet address on Tegra186
  ARM: tegra: add DWC EQoS (ethernet) to Tegra186 DT
  ARM: tegra: enable Ethernet on p2771-

 arch/arm/dts/tegra186-p2771-.dtsi  |5 +
 arch/arm/dts/tegra186.dtsi |   20 +
 arch/arm/mach-tegra/board186.c |7 +-
 arch/arm/mach-tegra/tegra186/Makefile  |1 +
 arch/arm/mach-tegra/tegra186/nvtboot_board.c   |   54 +
 configs/p2771--000_defconfig   |1 +
 configs/p2771--500_defconfig   |1 +
 .../net/snps,dwc-qos-ethernet.txt  |  166 +++
 drivers/net/Kconfig|   11 +
 drivers/net/Makefile   |1 +
 drivers/net/dwc_eth_qos.c  | 1552 
 drivers/net/mvgbe.c|   25 +-
 drivers/net/phy/micrel.c   |   23 +
 include/micrel.h   |3 +
 net/eth-uclass.c   |3 +-
 15 files changed, 1849 insertions(+), 24 deletions(-)
 create mode 100644 arch/arm/mach-tegra/tegra186/nvtboot_board.c
 create mode 100644 doc/device-tree-bindings/net/snps,dwc-qos-ethernet.txt
 create mode 100644 drivers/net/dwc_eth_qos.c

Thanks!
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] fsl/ddr: Revise erratum a009942 and clean related erratum

[york sun]

On 11/06/2016 06:42 PM, Shengzhou Liu wrote:
>
>> -Original Message-
>> From: york sun
>> Sent: Friday, November 04, 2016 11:20 PM
>> To: Shengzhou Liu ; u-boot@lists.denx.de
>> Subject: Re: [PATCH 1/3] fsl/ddr: Revise erratum a009942 and clean related
>> erratum
>>
>> On 11/04/2016 04:18 AM, Shengzhou Liu wrote:
>>> - add additional function erratum_a009942_check_cpo to check if the
>>>   board needs tuning CPO calibration for optimal setting.
>>> - move ERRATUM_A009942(with revision to check cpo_sample option)
>> from
>>>   fsl_ddr_gen4.c to ctrl_regs.c for reuse on all DDR4/DDR3 parts.
>>> - move ERRATUM_A008378 from fsl_ddr_gen4.c to ctrl_regs.c
>>> - remove obsolete ERRATUM_A004934 which is replaced with
>> ERRATUM_A009942.
>>
>> Shengzhou,
>>
>> There is an issue for moving the erratum 9942 workaround to ctrl_regs.c.
>> This workaround requires setting debug register in a read-modify-write
>> fashion. You won't be able to read the debug register in ctrl_regs.c file.
>>
>> York
>
> York,
>
> This change(moving to ctrl_regs.c) has the same effect as 
> read-modify-write(done in fsl_ddr_gen4.c) before MEM_EN is enabled for DDRC.
> As I commented in code with "the POR value of debug_29 register is zero" for 
> A009942 workaround when moving it to ctrl_regs.c,
> Actually only A008378 changes debug_29[8:11] bits to 9 from original POR 
> value 0  before the implementing of A009942, and A009942 overrides 
> debug_29[8:11] set by A008378.
> So we can set debug_29 in ctrl_regs.c, it doesn't break anything.

Shengzhou,

The presumption of POR value is not safe. It is safe for this case for 
now. You may have other erratum workaround popping up later using the 
same register, or other registers. PBI can also change registers. This 
sets an example to preset those registers out the scope of hardware 
interaction, regardless which controller is in use, or its state.

York


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] ARM: ts4600: add basic board support

[Sebastien Bourdelin]

Hi Fabio

On 11/07/2016 11:49 AM, Fabio Estevam wrote:
> Hi Sebastien,
> 
> On Mon, Nov 7, 2016 at 2:24 PM, Sebastien Bourdelin
>  wrote:
> 
>> Yes currently i'm using the mainstream Linux kernel using the mx28evk
>> defconfig and its Device Tree.
>> Obviously not all peripherals are working.
> 
> Ok, got it. So that means that having a dedicated ts4600.dts file in
> mainline kernel would be helpful.
> 
>> For my understanding, are we talking about adding the dts in U-Boot or
>> in Linux?
> 
> I am talking about adding ts4600.dts file to mainline kernel.
> 
Perfect, thanks for the clarification.
I will work on it.

> Regards,
> 
> Fabio Estevam
>

Best Regards,

Sebastien Bourdelin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] ARM: ts4600: add basic board support

[Fabio Estevam]

Hi Sebastien,

On Mon, Nov 7, 2016 at 2:24 PM, Sebastien Bourdelin
 wrote:

> Yes currently i'm using the mainstream Linux kernel using the mx28evk
> defconfig and its Device Tree.
> Obviously not all peripherals are working.

Ok, got it. So that means that having a dedicated ts4600.dts file in
mainline kernel would be helpful.

> For my understanding, are we talking about adding the dts in U-Boot or
> in Linux?

I am talking about adding ts4600.dts file to mainline kernel.

Regards,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program

[Alexander Graf]

On 07/11/2016 10:46, Simon Glass wrote:

Hi Alex,

On 19 October 2016 at 01:09, Alexander Graf  wrote:



On 18/10/2016 22:37, Simon Glass wrote:

Hi Alex,

On 18 October 2016 at 01:14, Alexander Graf  wrote:

On 10/18/2016 04:29 AM, Simon Glass wrote:


It is useful to have a basic sanity check for EFI loader support. Add a
'bootefi hello' command which loads HelloWord.efi and runs it under
U-Boot.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Include a link to the program instead of adding it to the tree



So, uh, where is the link?


I put it in the README (see the arm patch).



I'm really not convinced this command buys us anything yet. I do agree that
we want automated testing - but can't we get that using QEMU and a
downloadable image file that we pass in as disk and have the distro boot do
its magic?


That seems very heavyweight as a sanity check, although I agree it is useful.


It's not really much more heavy weight. The "image file" could simply
contain your hello world binary. But with this we don't just verify
whether "bootefi" works, but also whether the default boot path works ok.


I don't think I understand what you mean by 'image file'. Is it
something other than the .efi file? Do you mean a disk image?


Yes. For reasonable test coverage, we should also verify that the distro 
defaults wrote a sane boot script that automatically searches for a 
default EFI binary in /efi/boot/bootx86.efi on the first partition of 
all devices and runs it.


So if we just provide an SD card image or hard disk image to QEMU which 
contains a hello world .efi binary as that default boot file, we don't 
only test whether the "bootefi" command works, but also whether the 
distro boot script works.







Here I am just making sure that EFI programs can start, print output
and exit. It is a test that we can easily run without a lot of
overhead, much less than a full distro boot.


Again, I don't think it's much more overhead and I do believe it gives
us much cleaner separation between responsibilities of code (tests go
where tests are).


You are talking about a functional test, something that tests things
end to end. I prefer to at least start with a smaller test. Granted it
takes a little more work but it means there are fewer things to hunt
through when something goes wrong.


Yes, I personally find unit tests terribly annoying and unproductive and 
functional tests very helpful :). And in this case, the effort to write 
it is about the same for both, just that the functional test actually 
tells you that things work or don't work at the end of the day.


With a code base like U-Boot, a simple functional test like the above 
plus git bisect should get you to an offending patch very quickly.



Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] ARM: ts4600: add basic board support

[Sebastien Bourdelin]

Hi Fabio.

On 11/07/2016 10:43 AM, Fabio Estevam wrote:
> Hi Sebastien,
> 
> On Mon, Nov 7, 2016 at 1:36 PM, Sebastien Bourdelin
>  wrote:
>>
>> It's in my todo list yes, but nothing really planned currently, do you
>> think i should keep the mx28evk dtb instead?
> 
> I am not familar with this board. Do you mean that you use
> imx28-evk.dtb to boot it?
> 
Yes currently i'm using the mainstream Linux kernel using the mx28evk
defconfig and its Device Tree.
Obviously not all peripherals are working.

> IMHO it would be nice to have a dedicated ts4600.dts to avoid confusion.
> 
For my understanding, are we talking about adding the dts in U-Boot or
in Linux?

> Regards,
> 
> Fabio Estevam
>

Best Regards,

Sebastien Bourdelin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 14/14] x86: Enable EFI loader support

[Simon Glass]

Enable this so that EFI applications (notably grub) can be run under U-Boot
on x86 platforms.

At present the 'hello world' EFI application is not supported for the
qemu-x86_efi_payload64 board. That board builds a payload consisting of a
64-bit header and a 32-bit U-Boot, which is incompatible with the way the
EFI loader builds its EFI application. The following error is obtained:

x86_64-linux-ld.bfd: i386 architecture of input file
   `lib/efi_loader/helloworld.o' is incompatible with i386:x86-64 output

This could be corrected with additional Makefile rules. For now, this
feature is disabled for that board.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4:
- Drop the binary 'hello world' program

Changes in v3: None
Changes in v2:
- Remove EFI support from README.x86 TODO list

 configs/efi-x86_defconfig| 1 +
 configs/qemu-x86_efi_payload64_defconfig | 1 +
 configs/stm32f429-discovery_defconfig| 1 +
 doc/README.x86   | 1 -
 lib/efi_loader/Kconfig   | 2 +-
 5 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/configs/efi-x86_defconfig b/configs/efi-x86_defconfig
index b31c73b..1fe6142 100644
--- a/configs/efi-x86_defconfig
+++ b/configs/efi-x86_defconfig
@@ -34,3 +34,4 @@ CONFIG_USB=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_EFI=y
+# CONFIG_EFI_LOADER is not set
diff --git a/configs/qemu-x86_efi_payload64_defconfig 
b/configs/qemu-x86_efi_payload64_defconfig
index c081ead..a9ffd92 100644
--- a/configs/qemu-x86_efi_payload64_defconfig
+++ b/configs/qemu-x86_efi_payload64_defconfig
@@ -52,3 +52,4 @@ CONFIG_USE_PRIVATE_LIBGCC=y
 CONFIG_EFI=y
 CONFIG_EFI_STUB=y
 CONFIG_EFI_STUB_64BIT=y
+# CONFIG_CMD_BOOTEFI_HELLO is not set
diff --git a/configs/stm32f429-discovery_defconfig 
b/configs/stm32f429-discovery_defconfig
index 24e2221..a68494b 100644
--- a/configs/stm32f429-discovery_defconfig
+++ b/configs/stm32f429-discovery_defconfig
@@ -10,3 +10,4 @@ CONFIG_SYS_PROMPT="U-Boot > "
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_TIMER=y
 CONFIG_OF_LIBFDT=y
+# CONFIG_CMD_BOOTEFI_HELLO is not set
diff --git a/doc/README.x86 b/doc/README.x86
index 6799559..a38cc1b 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -1077,7 +1077,6 @@ TODO List
 -
 - Audio
 - Chrome OS verified boot
-- Support for CONFIG_EFI_LOADER
 - Building U-Boot to run in 64-bit mode
 
 References
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 48563aa..8e7e8a5 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -1,6 +1,6 @@
 config EFI_LOADER
bool "Support running EFI Applications in U-Boot"
-   depends on (ARM64 || ARM) && OF_LIBFDT
+   depends on (ARM64 || ARM || X86) && OF_LIBFDT
default y
help
  Select this option if you want to run EFI applications (like grub2)
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 13/14] efi: x86: Adjust EFI files support efi_loader

[Simon Glass]

Add compiler flags and make a few minor adjustments to support the efi
loader.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Add new patch to adjust EFI files support efi_loader

Changes in v3: None
Changes in v2: None

 arch/x86/config.mk  | 16 
 arch/x86/lib/Makefile   |  5 +
 arch/x86/lib/elf_ia32_efi.lds   |  2 --
 arch/x86/lib/elf_x86_64_efi.lds |  2 --
 4 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 12a8d73..03c71f7 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -65,3 +65,19 @@ PLATFORM_LDFLAGS += --emit-relocs
 LDFLAGS_FINAL += --gc-sections -pie
 
 endif
+
+ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO),)
+
+ifneq ($(CONFIG_EFI_STUB_64BIT),)
+EFI_LDS := elf_x86_64_efi.lds
+EFI_CRT0 := crt0_x86_64_efi.o
+EFI_RELOC := reloc_x86_64_efi.o
+EFI_TARGET := --target=efi-app-ia32
+else
+EFI_LDS := elf_ia32_efi.lds
+EFI_CRT0 := crt0_ia32_efi.o
+EFI_RELOC := reloc_ia32_efi.o
+EFI_TARGET := --target=efi-app-x86_64
+endif
+
+endif
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index aad6555..ff402dc 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -61,4 +61,9 @@ AFLAGS_crt0_x86_64_efi.o += -fpic -fshort-wchar
 
 extra-$(CONFIG_EFI_STUB_32BIT) += crt0_ia32_efi.o reloc_ia32_efi.o
 extra-$(CONFIG_EFI_STUB_64BIT) += crt0_x86_64_efi.o reloc_x86_64_efi.o
+
+endif
+
+ifneq ($(CONFIG_EFI_STUB)$(CONFIG_CMD_BOOTEFI_HELLO),)
+extra-y += $(EFI_CRT0) $(EFI_RELOC)
 endif
diff --git a/arch/x86/lib/elf_ia32_efi.lds b/arch/x86/lib/elf_ia32_efi.lds
index cd3b0a9..174d36f 100644
--- a/arch/x86/lib/elf_ia32_efi.lds
+++ b/arch/x86/lib/elf_ia32_efi.lds
@@ -6,8 +6,6 @@
  * Modified from usr/lib32/elf_ia32_efi.lds in gnu-efi
  */
 
-#include 
-
 OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
 OUTPUT_ARCH(i386)
 ENTRY(_start)
diff --git a/arch/x86/lib/elf_x86_64_efi.lds b/arch/x86/lib/elf_x86_64_efi.lds
index 9d9f057..70c7c52 100644
--- a/arch/x86/lib/elf_x86_64_efi.lds
+++ b/arch/x86/lib/elf_x86_64_efi.lds
@@ -6,8 +6,6 @@
  * Modified from usr/lib32/elf_x86_64_efi.lds in gnu-efi
  */
 
-#include 
-
 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
 OUTPUT_ARCH(i386:x86-64)
 ENTRY(_start)
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 10/14] efi: arm: Enable the hello world test program

[Simon Glass]

It is useful to have a basic sanity check for EFI loader support. Enable
this for ARM.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Use the build-generated 'hello world' program instead of a binary blob

Changes in v3:
- Include a link to the program instead of adding it to the tree
- Fix several typos
- Align backslashes to the same column

Changes in v2: None

 cmd/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index a5d030b..d3b675c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -184,6 +184,7 @@ config CMD_BOOTEFI
 config CMD_BOOTEFI_HELLO
bool "Allow booting a standard EFI hello world for testing"
depends on CMD_BOOTEFI
+   default y if CMD_BOOTEFI
help
  This adds a standard EFI hello world application to U-Boot so that
  it can be used with the 'bootefi hello' command. This is useful
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 12/14] x86: Move efi .S files into the 'lib' directory

[Simon Glass]

These files now need to be in a standard place so that they can be located
by generic Makefile rules. Move them to the 'lib' directory.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 Makefile   |  2 +-
 arch/x86/config.mk |  2 +-
 arch/x86/lib/Makefile  | 18 ++
 arch/x86/lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S}  |  0
 .../lib/{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S}   |  0
 arch/x86/lib/efi/Makefile  | 18 --
 arch/x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c}|  0
 .../x86/lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} |  0
 8 files changed, 20 insertions(+), 20 deletions(-)
 rename arch/x86/lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S} (100%)
 rename arch/x86/lib/{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S} (100%)
 rename arch/x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c} (100%)
 rename arch/x86/lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} (100%)

diff --git a/Makefile b/Makefile
index d3a6a12..c868fa2 100644
--- a/Makefile
+++ b/Makefile
@@ -1140,7 +1140,7 @@ quiet_cmd_u-boot_payload ?= LD  $@
   cmd_u-boot_payload ?= $(LD) $(LDFLAGS_EFI_PAYLOAD) -o $@ \
   -T u-boot-payload.lds arch/x86/cpu/call32.o \
   lib/efi/efi.o lib/efi/efi_stub.o u-boot.bin.o \
-  $(addprefix arch/$(ARCH)/lib/efi/,$(EFISTUB))
+  $(addprefix arch/$(ARCH)/lib/,$(EFISTUB))
 
 u-boot-payload: u-boot.bin.o u-boot-payload.lds FORCE
$(call if_changed,u-boot_payload)
diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index a17abbb..12a8d73 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -46,7 +46,7 @@ endif
 EFIPAYLOAD_BFDARCH = i386
 
 LDSCRIPT_EFI := $(srctree)/arch/x86/lib/elf_$(EFIARCH)_efi.lds
-EFISTUB := crt0-efi-$(EFIARCH).o reloc_$(EFIARCH).o
+EFISTUB := crt0_$(EFIARCH)_efi.o reloc_$(EFIARCH)_efi.o
 OBJCOPYFLAGS_EFI += --target=efi-app-$(EFIARCH)
 
 CPPFLAGS_REMOVE_crt0-efi-$(EFIARCH).o += $(CFLAGS_NON_EFI)
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index b9c2922..aad6555 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -44,3 +44,21 @@ NORMAL_LIBGCC = $(shell $(CC) $(PLATFORM_CPPFLAGS) 
-print-libgcc-file-name)
 OBJCOPYFLAGS := --prefix-symbols=__normal_
 $(obj)/lib.a: $(NORMAL_LIBGCC) FORCE
$(call if_changed,objcopy)
+
+obj-$(CONFIG_EFI_APP) += crt0_ia32_efi.o reloc_ia32_efi.o
+
+ifneq ($(CONFIG_EFI_STUB),)
+
+CFLAGS_REMOVE_reloc_ia32_efi.o += -mregparm=3
+CFLAGS_reloc_ia32_efi.o += -fpic -fshort-wchar
+
+# When building for 64-bit we must remove the i386-specific flags
+CFLAGS_REMOVE_reloc_x86_64_efi.o += -mregparm=3 -march=i386 -m32
+CFLAGS_reloc_x86_64_efi.o += -fpic -fshort-wchar
+
+AFLAGS_REMOVE_crt0_x86_64_efi.o += -mregparm=3 -march=i386 -m32
+AFLAGS_crt0_x86_64_efi.o += -fpic -fshort-wchar
+
+extra-$(CONFIG_EFI_STUB_32BIT) += crt0_ia32_efi.o reloc_ia32_efi.o
+extra-$(CONFIG_EFI_STUB_64BIT) += crt0_x86_64_efi.o reloc_x86_64_efi.o
+endif
diff --git a/arch/x86/lib/efi/crt0-efi-ia32.S b/arch/x86/lib/crt0_ia32_efi.S
similarity index 100%
rename from arch/x86/lib/efi/crt0-efi-ia32.S
rename to arch/x86/lib/crt0_ia32_efi.S
diff --git a/arch/x86/lib/efi/crt0-efi-x86_64.S b/arch/x86/lib/crt0_x86_64_efi.S
similarity index 100%
rename from arch/x86/lib/efi/crt0-efi-x86_64.S
rename to arch/x86/lib/crt0_x86_64_efi.S
diff --git a/arch/x86/lib/efi/Makefile b/arch/x86/lib/efi/Makefile
index af4503e..43aadfc 100644
--- a/arch/x86/lib/efi/Makefile
+++ b/arch/x86/lib/efi/Makefile
@@ -7,21 +7,3 @@
 
 obj-$(CONFIG_EFI_STUB) += car.o
 obj-$(CONFIG_EFI_STUB) += efi.o
-
-obj-$(CONFIG_EFI_APP) += crt0-efi-ia32.o reloc_ia32.o
-
-ifneq ($(CONFIG_EFI_STUB),)
-
-CFLAGS_REMOVE_reloc_ia32.o += -mregparm=3
-CFLAGS_reloc_ia32.o += -fpic -fshort-wchar
-
-# When building for 64-bit we must remove the i386-specific flags
-CFLAGS_REMOVE_reloc_x86_64.o += -mregparm=3 -march=i386 -m32
-CFLAGS_reloc_x86_64.o += -fpic -fshort-wchar
-
-AFLAGS_REMOVE_crt0-efi-x86_64.o += -mregparm=3 -march=i386 -m32
-AFLAGS_crt0-efi-x86_64.o += -fpic -fshort-wchar
-
-extra-$(CONFIG_EFI_STUB_32BIT) += crt0-efi-ia32.o reloc_ia32.o
-extra-$(CONFIG_EFI_STUB_64BIT) += crt0-efi-x86_64.o reloc_x86_64.o
-endif
diff --git a/arch/x86/lib/efi/reloc_ia32.c b/arch/x86/lib/reloc_ia32_efi.c
similarity index 100%
rename from arch/x86/lib/efi/reloc_ia32.c
rename to arch/x86/lib/reloc_ia32_efi.c
diff --git a/arch/x86/lib/efi/reloc_x86_64.c b/arch/x86/lib/reloc_x86_64_efi.c
similarity index 100%
rename from arch/x86/lib/efi/reloc_x86_64.c
rename to arch/x86/lib/reloc_x86_64_efi.c
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 11/14] x86: Move efi .lds files into the 'lib' directory

[Simon Glass]

These files now need to be in a standard place so that they can be located
by generic Makefile rules. Move them to the 'lib' directory.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/config.mk   | 2 +-
 arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds   | 0
 arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds | 0
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds (100%)
 rename arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds (100%)

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index d7addd8..a17abbb 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -45,7 +45,7 @@ endif
 
 EFIPAYLOAD_BFDARCH = i386
 
-LDSCRIPT_EFI := $(srctree)/$(CPUDIR)/efi/elf_$(EFIARCH)_efi.lds
+LDSCRIPT_EFI := $(srctree)/arch/x86/lib/elf_$(EFIARCH)_efi.lds
 EFISTUB := crt0-efi-$(EFIARCH).o reloc_$(EFIARCH).o
 OBJCOPYFLAGS_EFI += --target=efi-app-$(EFIARCH)
 
diff --git a/arch/x86/cpu/efi/elf_ia32_efi.lds b/arch/x86/lib/elf_ia32_efi.lds
similarity index 100%
rename from arch/x86/cpu/efi/elf_ia32_efi.lds
rename to arch/x86/lib/elf_ia32_efi.lds
diff --git a/arch/x86/cpu/efi/elf_x86_64_efi.lds 
b/arch/x86/lib/elf_x86_64_efi.lds
similarity index 100%
rename from arch/x86/cpu/efi/elf_x86_64_efi.lds
rename to arch/x86/lib/elf_x86_64_efi.lds
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 09/14] efi: arm: Add aarch64 EFI app support

[Simon Glass]

Add support for EFI apps on aarch64. This includes start-up and relocation
code plus a link script.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Add new patch to add EFI app support on aarch64

Changes in v3: None
Changes in v2: None

 arch/arm/cpu/armv8/config.mk |   4 ++
 arch/arm/lib/crt0_aarch64_efi.S  | 135 +++
 arch/arm/lib/elf_aarch64_efi.lds |  70 
 arch/arm/lib/reloc_aarch64_efi.c |  87 +
 4 files changed, 296 insertions(+)
 create mode 100644 arch/arm/lib/crt0_aarch64_efi.S
 create mode 100644 arch/arm/lib/elf_aarch64_efi.lds
 create mode 100644 arch/arm/lib/reloc_aarch64_efi.c

diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk
index 6850258..27b66d4 100644
--- a/arch/arm/cpu/armv8/config.mk
+++ b/arch/arm/cpu/armv8/config.mk
@@ -8,3 +8,7 @@ PLATFORM_RELFLAGS += -fno-common -ffixed-x18
 
 PF_NO_UNALIGNED := $(call cc-option, -mstrict-align)
 PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)
+
+EFI_LDS := elf_aarch64_efi.lds
+EFI_CRT0 := crt0_aarch64_efi.o
+EFI_RELOC := reloc_aarch64_efi.o
diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S
new file mode 100644
index 000..5205646
--- /dev/null
+++ b/arch/arm/lib/crt0_aarch64_efi.S
@@ -0,0 +1,135 @@
+/*
+ * crt0-efi-aarch64.S - PE/COFF header for aarch64 EFI applications
+ *
+ * Copright (C) 2014 Linaro Ltd. 
+ *
+ * SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause
+ *
+ * This file is taken and modified from the gnu-efi project.
+ */
+
+   .section.text.head
+
+   /*
+* Magic "MZ" signature for PE/COFF
+*/
+   .globl  ImageBase
+ImageBase:
+   .ascii  "MZ"
+   .skip   58  /* 'MZ' + pad + offset == 64 */
+   .long   pe_header - ImageBase   /* Offset to the PE header */
+pe_header:
+   .ascii  "PE"
+   .short  0
+coff_header:
+   .short  0xaa64  /* AArch64 */
+   .short  2   /* nr_sections */
+   .long   0   /* TimeDateStamp */
+   .long   0   /* PointerToSymbolTable */
+   .long   1   /* NumberOfSymbols */
+   .short  section_table - optional_header /* SizeOfOptionalHeader */
+   /*
+* Characteristics: IMAGE_FILE_DEBUG_STRIPPED |
+* IMAGE_FILE_EXECUTABLE_IMAGE | IMAGE_FILE_LINE_NUMS_STRIPPED
+*/
+   .short  0x206
+optional_header:
+   .short  0x20b   /* PE32+ format */
+   .byte   0x02/* MajorLinkerVersion */
+   .byte   0x14/* MinorLinkerVersion */
+   .long   _edata - _start /* SizeOfCode */
+   .long   0   /* SizeOfInitializedData */
+   .long   0   /* SizeOfUninitializedData */
+   .long   _start - ImageBase  /* AddressOfEntryPoint */
+   .long   _start - ImageBase  /* BaseOfCode */
+
+extra_header_fields:
+   .quad   0   /* ImageBase */
+   .long   0x20/* SectionAlignment */
+   .long   0x8 /* FileAlignment */
+   .short  0   /* MajorOperatingSystemVersion 
*/
+   .short  0   /* MinorOperatingSystemVersion 
*/
+   .short  0   /* MajorImageVersion */
+   .short  0   /* MinorImageVersion */
+   .short  0   /* MajorSubsystemVersion */
+   .short  0   /* MinorSubsystemVersion */
+   .long   0   /* Win32VersionValue */
+
+   .long   _edata - ImageBase  /* SizeOfImage */
+
+   /*
+* Everything before the kernel image is considered part of the header
+*/
+   .long   _start - ImageBase  /* SizeOfHeaders */
+   .long   0   /* CheckSum */
+   .short  EFI_SUBSYSTEM   /* Subsystem */
+   .short  0   /* DllCharacteristics */
+   .quad   0   /* SizeOfStackReserve */
+   .quad   0   /* SizeOfStackCommit */
+   .quad   0   /* SizeOfHeapReserve */
+   .quad   0   /* SizeOfHeapCommit */
+   .long   0   /* LoaderFlags */
+   .long   0x6 /* NumberOfRvaAndSizes */
+
+   .quad   0   /* ExportTable */
+   .quad   0   /* ImportTable */
+   .quad   0   /* ResourceTable */

[U-Boot] [PATCH v4 08/14] efi: arm: Add EFI app support

[Simon Glass]

Add support for EFI apps on ARM. This includes start-up and relocation
code, plus a link script and some compiler setting changes.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Add new patch to add EFI app support

Changes in v3: None
Changes in v2: None

 arch/arm/config.mk   |   7 +++
 arch/arm/lib/Makefile|  10 
 arch/arm/lib/crt0_arm_efi.S  | 138 +++
 arch/arm/lib/elf_arm_efi.lds |  70 ++
 arch/arm/lib/reloc_arm_efi.c |  66 +
 lib/efi_loader/Kconfig   |   2 +-
 6 files changed, 292 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/lib/crt0_arm_efi.S
 create mode 100644 arch/arm/lib/elf_arm_efi.lds
 create mode 100644 arch/arm/lib/reloc_arm_efi.c

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index 542b897..27914a9 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -13,6 +13,9 @@ CONFIG_STANDALONE_LOAD_ADDR = 0xc10
 endif
 endif
 
+CFLAGS_NON_EFI := -fno-pic -ffixed-r9 -ffunction-sections -fdata-sections
+CFLAGS_EFI := -fpic -fshort-wchar
+
 LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
 -fno-common -ffixed-r9
@@ -148,3 +151,7 @@ ifneq ($(CONFIG_VF610),)
 ALL-y += u-boot.vyb
 endif
 endif
+
+EFI_LDS := elf_arm_efi.lds
+EFI_CRT0 := crt0_arm_efi.o
+EFI_RELOC := reloc_arm_efi.o
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index caa62c6..a812306 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -92,3 +92,13 @@ AFLAGS_memset.o := -DMEMSET_NO_THUMB_BUILD
 AFLAGS_memcpy.o := -DMEMCPY_NO_THUMB_BUILD
 endif
 endif
+
+# For building EFI apps
+CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI)
+CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI)
+
+CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI)
+CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI)
+
+extra-$(CONFIG_CMD_BOOTEFI_HELLO) += $(EFI_CRT0) $(EFI_RELOC)
+extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC)
diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S
new file mode 100644
index 000..967c885
--- /dev/null
+++ b/arch/arm/lib/crt0_arm_efi.S
@@ -0,0 +1,138 @@
+/*
+ * crt0-efi-arm.S - PE/COFF header for ARM EFI applications
+ *
+ * Copright (C) 2014 Linaro Ltd. 
+ *
+ * SPDX-License-Identifier: GPL-2.0+ BSD-2-Clause
+ *
+ * This file is taken and modified from the gnu-efi project.
+ */
+
+   .section.text.head
+
+   /*
+* Magic "MZ" signature for PE/COFF
+*/
+   .globl  image_base
+image_base:
+   .ascii  "MZ"
+   .skip   58  /* 'MZ' + pad + offset == 64 */
+   .long   pe_header - image_base  /* Offset to the PE header */
+pe_header:
+   .ascii  "PE"
+   .short  0
+coff_header:
+   .short  0x1c2   /* Mixed ARM/Thumb */
+   .short  2   /* nr_sections */
+   .long   0   /* TimeDateStamp */
+   .long   0   /* PointerToSymbolTable */
+   .long   1   /* NumberOfSymbols */
+   .short  section_table - optional_header /* SizeOfOptionalHeader */
+   /*
+* Characteristics: IMAGE_FILE_32BIT_MACHINE |
+* IMAGE_FILE_DEBUG_STRIPPED | IMAGE_FILE_EXECUTABLE_IMAGE |
+* IMAGE_FILE_LINE_NUMS_STRIPPED
+*/
+   .short  0x306
+optional_header:
+   .short  0x10b   /* PE32+ format */
+   .byte   0x02/* MajorLinkerVersion */
+   .byte   0x14/* MinorLinkerVersion */
+   .long   _edata - _start /* SizeOfCode */
+   .long   0   /* SizeOfInitializedData */
+   .long   0   /* SizeOfUninitializedData */
+   .long   _start - image_base /* AddressOfEntryPoint */
+   .long   _start - image_base /* BaseOfCode */
+   .long   0   /* BaseOfData */
+
+extra_header_fields:
+   .long   0   /* image_base */
+   .long   0x20/* SectionAlignment */
+   .long   0x8 /* FileAlignment */
+   .short  0   /* MajorOperatingSystemVersion 
*/
+   .short  0   /* MinorOperatingSystemVersion 
*/
+   .short  0   /* MajorImageVersion */
+   .short  0   /* MinorImageVersion */
+   .short  0   /* MajorSubsystemVersion */
+   .short  0   /* MinorSubsystemVersion */
+   .long   0   /* Win32VersionValue */
+
+   .long   _edata - image_base /* SizeOfImage */
+
+   /*
+* Everything before the 

[U-Boot] [PATCH v4 07/14] elf: arm: Add a few ARM relocation types

[Simon Glass]

Rather than hard-coding the relocation type, add it to the ELF header file
and use it from there.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/lib/relocate.S|  3 ++-
 arch/arm/lib/relocate_64.S |  3 ++-
 include/elf.h  | 13 +
 3 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S
index 475d503..a6fb07c 100644
--- a/arch/arm/lib/relocate.S
+++ b/arch/arm/lib/relocate.S
@@ -8,6 +8,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #ifdef CONFIG_CPU_V7M
 #include 
@@ -96,7 +97,7 @@ copy_loop:
 fixloop:
ldmia   r2!, {r0-r1}/* (r0,r1) <- (SRC location,fixup) */
and r1, r1, #0xff
-   cmp r1, #23 /* relative fixup? */
+   cmp r1, #R_ARM_RELATIVE
bne fixnext
 
/* relative fix: increase location by offset */
diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S
index 5c51cae..242e56e 100644
--- a/arch/arm/lib/relocate_64.S
+++ b/arch/arm/lib/relocate_64.S
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -47,7 +48,7 @@ fixloop:
ldp x0, x1, [x2], #16   /* (x0,x1) <- (SRC location, fixup) */
ldr x4, [x2], #8/* x4 <- addend */
and x1, x1, #0x
-   cmp x1, #1027   /* relative fixup? */
+   cmp x1, #R_AARCH64_RELATIVE
bne fixnext
 
/* relative fix: store addend plus offset at dest location */
diff --git a/include/elf.h b/include/elf.h
index bcc5eb7..aaecac7 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -13,6 +13,7 @@
 #ifndef _ELF_H
 #define _ELF_H
 
+#ifndef __ASSEMBLER__
 #include "compiler.h"
 
 /*
@@ -517,6 +518,8 @@ unsigned long elf_hash(const unsigned char *name);
 
 #define ELF_TARG_VER   1   /* The ver for which this code is intended */
 
+#endif /* __ASSEMBLER */
+
 /*
  * XXX - PowerPC defines really don't belong in here,
  * but we'll put them in for simplicity.
@@ -602,6 +605,16 @@ unsigned long elf_hash(const unsigned char *name);
that may still be in object files.  */
 #define R_PPC_TOC16 255
 
+ /* ARM relocs */
+#define R_ARM_NONE 0   /* No reloc */
+#define R_ARM_RELATIVE 23  /* Adjust by program base */
+
+/* AArch64 relocs */
+#define R_AARCH64_NONE 0   /* No relocation.  */
+#define R_AARCH64_RELATIVE 1027/* Adjust by program base.  */
+
+#ifndef __ASSEMBLER__
 int valid_elf_image(unsigned long addr);
+#endif
 
 #endif /* _ELF_H */
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 06/14] efi: Add support for a hello world test program

[Simon Glass]

It is useful to have a basic sanity check for EFI loader support. Add a
'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Move hello world test program into new patch

Changes in v3: None
Changes in v2: None

 cmd/Kconfig|  9 +
 cmd/bootefi.c  | 27 +--
 doc/README.efi | 22 ++
 include/asm-generic/sections.h |  2 ++
 lib/efi_loader/Makefile|  4 
 lib/efi_loader/helloworld.c| 24 
 scripts/Makefile.lib   | 33 +
 7 files changed, 115 insertions(+), 6 deletions(-)
 create mode 100644 lib/efi_loader/helloworld.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index e339d86..a5d030b 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -181,6 +181,15 @@ config CMD_BOOTEFI
help
  Boot an EFI image from memory.
 
+config CMD_BOOTEFI_HELLO
+   bool "Allow booting a standard EFI hello world for testing"
+   depends on CMD_BOOTEFI
+   help
+ This adds a standard EFI hello world application to U-Boot so that
+ it can be used with the 'bootefi hello' command. This is useful
+ for testing that EFI is working at a basic level, and for bringing
+ up EFI support on a new architecture.
+
 config CMD_ELF
bool "bootelf, bootvx"
default y
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3ab256e..ae1b713 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -239,13 +239,23 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[])
 
if (argc < 2)
return CMD_RET_USAGE;
-   saddr = argv[1];
+#ifdef CONFIG_CMD_BOOTEFI_HELLO
+   if (!strcmp(argv[1], "hello")) {
+   ulong size = __efi_hello_world_end - __efi_hello_world_begin;
 
-   addr = simple_strtoul(saddr, NULL, 16);
+   addr = CONFIG_SYS_LOAD_ADDR;
+   memcpy((char *)addr, __efi_hello_world_begin, size);
+   } else
+#endif
+   {
+   saddr = argv[1];
 
-   if (argc > 2) {
-   sfdt = argv[2];
-   fdt_addr = simple_strtoul(sfdt, NULL, 16);
+   addr = simple_strtoul(saddr, NULL, 16);
+
+   if (argc > 2) {
+   sfdt = argv[2];
+   fdt_addr = simple_strtoul(sfdt, NULL, 16);
+   }
}
 
printf("## Starting EFI application at %08lx ...\n", addr);
@@ -263,7 +273,12 @@ static char bootefi_help_text[] =
" [fdt address]\n"
"  - boot EFI payload stored at address .\n"
"If specified, the device tree located at  gets\n"
-   "exposed as EFI configuration table.\n";
+   "exposed as EFI configuration table.\n"
+#ifdef CONFIG_CMD_BOOTEFI_HELLO
+   "hello\n"
+   "  - boot a sample Hello World application stored within U-Boot"
+#endif
+   ;
 #endif
 
 U_BOOT_CMD(
diff --git a/doc/README.efi b/doc/README.efi
index 1fd3f00..6e76310 100644
--- a/doc/README.efi
+++ b/doc/README.efi
@@ -310,6 +310,28 @@ Removable media booting (search for 
/efi/boot/boota{a64,arm}.efi) is supported.
 Simple use cases like "Plug this SD card into my ARM device and it just
 boots into grub which boots into Linux", work very well.
 
+
+Running HelloWord.efi
+-
+
+You can run a simple 'hello world' EFI program in U-Boot. This is not
+distributed in the U-Boot source, but you can download this patch:
+
+   https://goo.gl/vihiZS
+
+Then apply it, e.g.:
+
+   $ git am ~/Downloads/0001-efi-Add-test-program-binaries.patch
+
+and enable the option CONFIG_CMD_BOOTEFI_HELLO
+
+Then you can boot into U-Boot and type:
+
+   > bootefi hello
+
+The 'hello world EFI' program will then run, print a message and exit.
+
+
 Future work
 ---
 
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index d69bc60..daf021b 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -22,6 +22,8 @@ extern char __kprobes_text_start[], __kprobes_text_end[];
 extern char __entry_text_start[], __entry_text_end[];
 extern char __initdata_begin[], __initdata_end[];
 extern char __start_rodata[], __end_rodata[];
+extern char __efi_hello_world_begin[];
+extern char __efi_hello_world_end[];
 
 /* Start and end of .ctors section - used for constructor calls. */
 extern char __ctors_start[], __ctors_end[];
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 12159dd..f466408 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -7,6 +7,10 @@
 # This file only gets included with CONFIG_EFI_LOADER set, so all
 # object inclusion implicitly depends on it
 
+CFLAGS_helloworld.o := $(CFLAGS_EFI)
+CFLAGS_REMOVE_helloworld.o := $(CFLAGS_NON_EFI)
+
+obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
 obj-y += efi_image_loader.o efi_boottime.o 

[U-Boot] [PATCH v4 05/14] efi: Makefile: Export variables for use with EFI

[Simon Glass]

When building an EFI app we need three things:

   - start-up code
   - relocation code
   - link script

These are all different for each architecture. We also need special
compiler flags in some cases.

Add top-level Makefile variables for these along with documentation.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 Makefile | 9 +
 1 file changed, 9 insertions(+)

diff --git a/Makefile b/Makefile
index 37cbcb2..d3a6a12 100644
--- a/Makefile
+++ b/Makefile
@@ -527,6 +527,15 @@ endif
 endif
 endif
 
+# These are set by the arch-specific config.mk. Make sure they are exported
+# so they can be used when building an EFI application.
+export EFI_LDS # Filename of EFI link script in arch/$(ARCH)/lib
+export EFI_CRT0# Filename of EFI CRT0 in arch/$(ARCH)/lib
+export EFI_RELOC   # Filename of EFU relocation code in arch/$(ARCH)/lib
+export CFLAGS_EFI  # Compiler flags to add when building EFI app
+export CFLAGS_NON_EFI  # Compiler flags to remove when building EFI app
+export EFI_TARGET  # binutils target if EFI is natively supported
+
 # If board code explicitly specified LDSCRIPT or CONFIG_SYS_LDSCRIPT, use
 # that (or fail if absent).  Otherwise, search for a linker script in a
 # standard location.
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 03/14] efi: Fix debug message address format

[Simon Glass]

This should use U-Boot's standard format for hex address. Fix it.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 cmd/bootefi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index c8079c4..3ab256e 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -248,7 +248,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
fdt_addr = simple_strtoul(sfdt, NULL, 16);
}
 
-   printf("## Starting EFI application at 0x%08lx ...\n", addr);
+   printf("## Starting EFI application at %08lx ...\n", addr);
r = do_bootefi_exec((void *)addr, (void*)fdt_addr);
printf("## Application terminated, r = %d\n", r);
 
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 04/14] x86: Tidy up selection of building the EFI stub

[Simon Glass]

At present we use a CONFIG option in efi.h to determine whether we are
building the EFI stub or not. This means that the same header cannot be
used for EFI_LOADER support. The CONFIG option will be enabled for the
whole build, even when not building the stub.

Use a different define instead, set up just for the files that make up the
stub.

Signed-off-by: Simon Glass 
Reviewed-by: Bin Meng 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Add new patch to tidy up selection of building the EFI stub

 include/efi.h| 7 +--
 lib/efi/Makefile | 4 ++--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/efi.h b/include/efi.h
index d07187c..3d58780 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -30,8 +30,11 @@ struct efi_device_path;
 
 #define EFI_BITS_PER_LONG  BITS_PER_LONG
 
-/* With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64 */
-#ifdef CONFIG_EFI_STUB_64BIT
+/*
+ * With 64-bit EFI stub, EFI_BITS_PER_LONG has to be 64. EFI_STUB is set
+ * in lib/efi/Makefile, when building the stub.
+ */
+#if defined(CONFIG_EFI_STUB_64BIT) && defined(EFI_STUB)
 #undef EFI_BITS_PER_LONG
 #define EFI_BITS_PER_LONG  64
 #endif
diff --git a/lib/efi/Makefile b/lib/efi/Makefile
index e32dc14..9449600 100644
--- a/lib/efi/Makefile
+++ b/lib/efi/Makefile
@@ -9,9 +9,9 @@ obj-$(CONFIG_EFI_STUB) += efi_info.o
 
 CFLAGS_REMOVE_efi_stub.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi_stub.o := -fpic -fshort-wchar
+CFLAGS_efi_stub.o := -fpic -fshort-wchar -DEFI_STUB
 CFLAGS_REMOVE_efi.o := -mregparm=3 \
$(if $(CONFIG_EFI_STUB_64BIT),-march=i386 -m32)
-CFLAGS_efi.o := -fpic -fshort-wchar
+CFLAGS_efi.o := -fpic -fshort-wchar -DEFI_STUB
 
 extra-$(CONFIG_EFI_STUB) += efi_stub.o efi.o
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 01/14] x86: Correct a build warning in x86 tables

[Simon Glass]

There is a build warning for three x86 boards since
write_smbios_table_wrapper() is not used. Fix it.

Fixes: e824cf3f (smbios: Allow compilation on 64bit systems)
Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/x86/lib/tables.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 025b183..5966e58 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -12,10 +12,12 @@
 #include 
 #include 
 
+#ifdef CONFIG_GENERATE_SMBIOS_TABLE
 static u32 write_smbios_table_wrapper(u32 addr)
 {
return write_smbios_table(addr);
 }
+#endif
 
 /**
  * Function prototype to write a specific configuration table
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 02/14] efi: Correct cache flush alignment

[Simon Glass]

Make sure that the cache flushes correctly by ensuring that the end
address is correctly aligned.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 lib/efi_loader/efi_image_loader.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_image_loader.c 
b/lib/efi_loader/efi_image_loader.c
index 5165377..3262d76 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -174,7 +174,8 @@ void *efi_load_pe(void *efi, struct efi_loaded_image 
*loaded_image_info)
efi_loader_relocate(rel, rel_size, efi_reloc);
 
/* Flush cache */
-   flush_cache((ulong)efi_reloc, virt_size);
+   flush_cache((ulong)efi_reloc,
+   ALIGN(virt_size, CONFIG_SYS_CACHELINE_SIZE));
invalidate_icache_all();
 
/* Populate the loaded image interface bits */
-- 
2.8.0.rc3.226.g39d4020

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 00/14] efi: x86: Add EFI hello world and loader support for x86

[Simon Glass]

This series adds EFI loader support for x86. Since U-Boot already supports
running as an EFI app (and as a payload) this is relatively
straightforward, requiring just moving files into place and updating a few
compiler flags.

One problem with the EFI loader is that it lacks even rudimentary test
support within U-Boot. At present the only way to test it is to boot an
EFI application. As a step towards correcting this, this series also adds
support for a 'hello world' test program which can be used to make sure
that EFI loader support works correctly on a supported architecture. It is
only a very simple program (it makes just two API calls!) but it does
provide a sanity check and can be expanded as needed.

No attempt is made to create a pytest with this, but it should be fairly
straightforward to do so.

Changes in v4:
- Move hello world test program into new patch
- Add new patch to add EFI app support
- Add new patch to add EFI app support on aarch64
- Use the build-generated 'hello world' program instead of a binary blob
- Add new patch to adjust EFI files support efi_loader
- Drop the binary 'hello world' program

Changes in v3:
- Include a link to the program instead of adding it to the tree
- Fix several typos
- Align backslashes to the same column

Changes in v2:
- Add new patch to tidy up selection of building the EFI stub
- Remove EFI support from README.x86 TODO list

Simon Glass (14):
  x86: Correct a build warning in x86 tables
  efi: Correct cache flush alignment
  efi: Fix debug message address format
  x86: Tidy up selection of building the EFI stub
  efi: Makefile: Export variables for use with EFI
  efi: Add support for a hello world test program
  elf: arm: Add a few ARM relocation types
  efi: arm: Add EFI app support
  efi: arm: Add aarch64 EFI app support
  efi: arm: Enable the hello world test program
  x86: Move efi .lds files into the 'lib' directory
  x86: Move efi .S files into the 'lib' directory
  efi: x86: Adjust EFI files support efi_loader
  x86: Enable EFI loader support

 Makefile   |  11 +-
 arch/arm/config.mk |   7 ++
 arch/arm/cpu/armv8/config.mk   |   4 +
 arch/arm/lib/Makefile  |  10 ++
 arch/arm/lib/crt0_aarch64_efi.S| 135 
 arch/arm/lib/crt0_arm_efi.S| 138 +
 arch/arm/lib/elf_aarch64_efi.lds   |  70 +++
 arch/arm/lib/elf_arm_efi.lds   |  70 +++
 arch/arm/lib/reloc_aarch64_efi.c   |  87 +
 arch/arm/lib/reloc_arm_efi.c   |  66 ++
 arch/arm/lib/relocate.S|   3 +-
 arch/arm/lib/relocate_64.S |   3 +-
 arch/x86/config.mk |  20 ++-
 arch/x86/lib/Makefile  |  23 
 .../lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S}   |   0
 .../{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S}   |   0
 arch/x86/lib/efi/Makefile  |  18 ---
 arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds |   2 -
 arch/x86/{cpu/efi => lib}/elf_x86_64_efi.lds   |   2 -
 .../x86/lib/{efi/reloc_ia32.c => reloc_ia32_efi.c} |   0
 .../lib/{efi/reloc_x86_64.c => reloc_x86_64_efi.c} |   0
 arch/x86/lib/tables.c  |   2 +
 cmd/Kconfig|  10 ++
 cmd/bootefi.c  |  29 +++--
 configs/efi-x86_defconfig  |   1 +
 configs/qemu-x86_efi_payload64_defconfig   |   1 +
 configs/stm32f429-discovery_defconfig  |   1 +
 doc/README.efi |  22 
 doc/README.x86 |   1 -
 include/asm-generic/sections.h |   2 +
 include/efi.h  |   7 +-
 include/elf.h  |  13 ++
 lib/efi/Makefile   |   4 +-
 lib/efi_loader/Kconfig |   2 +-
 lib/efi_loader/Makefile|   4 +
 lib/efi_loader/efi_image_loader.c  |   3 +-
 lib/efi_loader/helloworld.c|  24 
 scripts/Makefile.lib   |  33 +
 38 files changed, 787 insertions(+), 41 deletions(-)
 create mode 100644 arch/arm/lib/crt0_aarch64_efi.S
 create mode 100644 arch/arm/lib/crt0_arm_efi.S
 create mode 100644 arch/arm/lib/elf_aarch64_efi.lds
 create mode 100644 arch/arm/lib/elf_arm_efi.lds
 create mode 100644 arch/arm/lib/reloc_aarch64_efi.c
 create mode 100644 arch/arm/lib/reloc_arm_efi.c
 rename arch/x86/lib/{efi/crt0-efi-ia32.S => crt0_ia32_efi.S} (100%)
 rename arch/x86/lib/{efi/crt0-efi-x86_64.S => crt0_x86_64_efi.S} (100%)
 rename arch/x86/{cpu/efi => lib}/elf_ia32_efi.lds (98%)
 rename 

Re: [U-Boot] [PATCH 4/6] x86: efi: Add EFI loader support for x86

[Simon Glass]

Hi Alex,

On 25 October 2016 at 15:33, Alexander Graf  wrote:
>
>
> On 10/08/2016 14:56, Simon Glass wrote:
>> Hi Alex,
>>
[...]

   #endif
 struct efi_device_path;
 diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
 index 798b566..e027bd3 100644
 --- a/lib/efi_loader/efi_boottime.c
 +++ b/lib/efi_loader/efi_boottime.c
 @@ -39,6 +39,7 @@ static bool efi_is_direct_boot = true;
*/
   static struct efi_configuration_table EFI_RUNTIME_DATA
 efi_conf_table[1];
   +#ifdef CONFIG_ARM
   /*
* The "gd" pointer lives in a register on ARM and AArch64 that we
 declare
* fixed when compiling U-Boot. However, the payload does not know about
 that
 @@ -46,16 +47,20 @@ static struct efi_configuration_table EFI_RUNTIME_DATA
 efi_conf_table[1];
* EFI callback entry/exit.
*/
   static volatile void *efi_gd, *app_gd;
 +#endif
>>>
>>>
>>> So is fs reserved for firmware use on x86?
>>
>> No I don't think so. The correct approach would be to save and restore
>> the FS register, but it seems to work this way, so I haven't taken it
>> any further.
>
> Can you make sure you save/restore %fs on x86 in the next round then?
> Finding bugs like these is very hard once the code is in.

I still haven't done this. In fact I'm starting to wonder what other
registers we might have a problem with. Looking at the
setjmp()/longjmp() that I have, it doesn't save everything.

>
>> This series was just an attempt to get the EFI loader working on x86.
>
> Yes, and it's very very very much appreciated :).
>
>> Since we have the 32/64-bit limitation on x86 and U-Boot runs in
>> 32-bit at present, it's not going to be very useful yet IMO. But it is
>> a start.
>
> I agree. It's a really good start.

I suspect that it will be quite a bit of work to get U-Boot running in
64-bit mode. I sent a series about a month ago, but it still lacks
quite a few features.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/6] arm: efi: Add a hello world test program

[Simon Glass]

Hi Leif,

On 20 October 2016 at 02:19, Leif Lindholm  wrote:
> On 19 October 2016 at 21:22, Leif Lindholm  wrote:
>> On Mon, Oct 17, 2016 at 07:55:02PM -0600, Simon Glass wrote:
>>> Hi Leif,
>>>
>>> On 26 September 2016 at 19:53, Leif Lindholm  
>>> wrote:
>>> >> Thanks for the pointer. Unfortunately that patch appears to make no
>>> >> differences for me. Are you able to build and send me a 64-bit
>>> >> HelloWorld.efi please?
>>> >
>>> > So, I probably could, but if that isn't working for you, I'd quite
>>> > like to know why.
>>> >
>>> > To make that a little less painful though, I've added support for
>>> > building the helloworld app to my set of scripts:
>>> > https://git.linaro.org/uefi/uefi-tools.git
>>> >
>>> > This still depends on this (updated) patch.
>>> > https://lists.01.org/pipermail/edk2-devel/2016-September/002112.html
>>> >
>>> > But with a current edk2, and a uefi-tools placed in the same directory
>>> > as the edk2 clone, could you try executing:
>>> >
>>> > ../uefi-tools/uefi-build.sh -A AARCH64 hello
>>> >
>>> > If the build fails and creates messy output due to being parallel,
>>> > could you stick a -1 on that command line and send me the output (or
>>> > pastebin)?
>>>
>>> OK thanks. Please see:
>>>
>>> http://pastebin.com/DmixdA4C
>>
>> Right ... so your terminal appears to be discarding stderr, but I'm
>> guessing with that enabled it would look like:
>> ---
>> Processing meta-data ..
>>
>> build.py...
>> /work/git/edk2/MdeModulePkg/MdeModulePkg.dsc(...): error 4000: Instance of 
>> library class [ArmMmuLib] is not found
>> in [/work/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf] [AARCH64]
>> consumed by module 
>> [/work/git/edk2/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf]
>>
>>
>> - Failed -
>> Build end time: 16:51:18, Oct.19 2016
>> Build total time: 00:00:03
>> ---
>>
>> Which is what it looks without the aforementioned patch applied.

I really thought I applied it. But I don't understand the UEFI build
system at all...

>
> As a follow-up: I have now pushed the required patch to edk2, so with
> a fresh pull it should work without any manually added patches.

I think I'm going to build a simple hello world within the U-Boot
tree, to avoiding needing to package a binary.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 7/8] x86: efi: Add a hello world test program

[Simon Glass]

Hi Alex,

On 19 October 2016 at 01:09, Alexander Graf  wrote:
>
>
> On 18/10/2016 22:37, Simon Glass wrote:
>> Hi Alex,
>>
>> On 18 October 2016 at 01:14, Alexander Graf  wrote:
>>> On 10/18/2016 04:29 AM, Simon Glass wrote:

 It is useful to have a basic sanity check for EFI loader support. Add a
 'bootefi hello' command which loads HelloWord.efi and runs it under
 U-Boot.

 Signed-off-by: Simon Glass 
 ---

 Changes in v3:
 - Include a link to the program instead of adding it to the tree
>>>
>>>
>>> So, uh, where is the link?
>>
>> I put it in the README (see the arm patch).
>>
>>>
>>> I'm really not convinced this command buys us anything yet. I do agree that
>>> we want automated testing - but can't we get that using QEMU and a
>>> downloadable image file that we pass in as disk and have the distro boot do
>>> its magic?
>>
>> That seems very heavyweight as a sanity check, although I agree it is useful.
>
> It's not really much more heavy weight. The "image file" could simply
> contain your hello world binary. But with this we don't just verify
> whether "bootefi" works, but also whether the default boot path works ok.

I don't think I understand what you mean by 'image file'. Is it
something other than the .efi file? Do you mean a disk image?

>
>> Here I am just making sure that EFI programs can start, print output
>> and exit. It is a test that we can easily run without a lot of
>> overhead, much less than a full distro boot.
>
> Again, I don't think it's much more overhead and I do believe it gives
> us much cleaner separation between responsibilities of code (tests go
> where tests are).

You are talking about a functional test, something that tests things
end to end. I prefer to at least start with a smaller test. Granted it
takes a little more work but it means there are fewer things to hunt
through when something goes wrong.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/8] arm: efi: Add a hello world test program

[Simon Glass]

Hi Alex,

On 19 October 2016 at 01:07, Alexander Graf  wrote:
>
>
> On 18/10/2016 22:37, Simon Glass wrote:
>> Hi Alex,
>>
>> On 4 October 2016 at 09:50, Alexander Graf  wrote:
>>>
>>>
>>> Am 04.10.2016 um 17:37 schrieb Simon Glass :
>>>
>>> Hi Alex,
>>>
>>> On 3 October 2016 at 21:15, Alexander Graf  wrote:
>>>
>>>
>>>
>>> Am 03.10.2016 um 23:50 schrieb Simon Glass :
>>>
>>>
>>> Hi,
>>>
>>>
>>> On 27 September 2016 at 15:28, Tom Rini  wrote:
>>>
>>>
>>> On Mon, Sep 26, 2016 at 09:36:19AM +0200, Alexander Graf wrote:
>>>
>>>
>>>
>>>
>>> On 25.09.16 23:27, Simon Glass wrote:
>>>
>>>
>>> It is useful to have a basic sanity check for EFI loader support. Add a
>>>
>>>
>>> 'bootefi hello' command which loads HelloWord.efi and runs it under U-Boot.
>>>
>>>
>>>
>>> Signed-off-by: Simon Glass 
>>>
>>>
>>> ---
>>>
>>>
>>>
>>> Changes in v2: None
>>>
>>>
>>>
>>> arch/arm/lib/HelloWorld32.efi  | Bin 0 -> 11712 bytes
>>>
>>>
>>>
>>> IIRC U-Boot as a whole is GPL licensed, which means that any binaries
>>>
>>>
>>> shipped inside would also need to be GPL compatibly licensed which again
>>>
>>>
>>> means that the source code (and build instructions?) for this .efi file
>>>
>>>
>>> would need to be part of the tree, no?
>>>
>>>
>>>
>>> Yeah, I'm not super comfortable with this.
>>>
>>>
>>>
>>> Do you think we should drop these binary patches? I could always put
>>>
>>> the binaries somewhere along with instructions on how to get them.
>>>
>>>
>>>
>>> I think that's the best option, yes. You can always just add a url to the
>>>
>>> readme to point people into the right direction.
>>>
>>>
>>> OK. One problem is that we cannot write a test for it unless we
>>> actually run an EFI application.
>>>
>>>
>>> Well, you could always provide a binary disk image that you run in qemu as
>>> test case. That one doesn't have to be gpl compliant thn because it's not
>>> derived work :).
>>>
>>>
>>>
>>>
>>> I do think it is useful to be able to test the platform though.
>>>
>>>
>>>
>>> I don't disagree, but I would argue that for the average u-boot user it
>>>
>>> brings no additional value ;). And people like you who know how to enable a
>>>
>>> new architecture probably also know how to get a file into their target's
>>>
>>> memory.
>>>
>>>
>>> I wonder if we can build our own hello world application? I think I
>>> did it once. But there is EFI library code that we would need to bring
>>> in (perhaps a small amount).
>>>
>>>
>>> We could. The main problem is the PE header.
>>
>> What is tricky about that?
>
> Our compiler usually generates elf files, no PE binaries. So we'd have
> to assemble the PE header ourselves - or rely on a second compiler.

I think I'm going to go with the first option which seems easy enough.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/8] efi: Use asmlinkage for EFIAPI

[Simon Glass]

Hi Alex,

On 19 October 2016 at 01:11, Alexander Graf  wrote:
>
>
> On 18/10/2016 22:37, Simon Glass wrote:
>> Hi Alex,
>>
>> On 18 October 2016 at 01:12, Alexander Graf  wrote:
>>> On 10/18/2016 04:29 AM, Simon Glass wrote:

 This is required for x86 and is also correct for ARM (since it is empty).

 Signed-off-by: Simon Glass 
 Reviewed-by: Bin Meng 
>>>
>>>
>>> (Replying here in lack for a cover letter)
>>>
>>> Could you please rebase your patches on top of
>>>
>>>   https://github.com/agraf/u-boot.git efi-next
>>>
>>> so that all the patches that I already queued are not repeated in the patch
>>> set and we don't get any conflicts?
>>
>> I can do that - but is this targeting -next? I was expecting these
>> patches to land in master.
>
> Sorry, they are on their way to master. It's just old habit wrt my
> naming scheme:
>
>   -next: current development branch, basically staging for master

I'd suggest calling that 'master'.

>   -release-number: future patches that I already applied proactively for
> the next release, or backports :)
>
> As it stands, I've only taken the base patches, not all of them. Would
> you expect all of the x86 efi enablement to land in 2016.11?

No, let's target the release after that.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] ARM: ts4600: add basic board support

[Fabio Estevam]

Hi Sebastien,

On Mon, Nov 7, 2016 at 1:36 PM, Sebastien Bourdelin
 wrote:
>
> It's in my todo list yes, but nothing really planned currently, do you
> think i should keep the mx28evk dtb instead?

I am not familar with this board. Do you mean that you use
imx28-evk.dtb to boot it?

IMHO it would be nice to have a dedicated ts4600.dts to avoid confusion.

Regards,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] ARM: ts4600: add basic board support

[Sebastien Bourdelin]

Hi Fabio.

On 11/06/2016 02:16 PM, Fabio Estevam wrote:
> Hi Sebastien,
> 
> On Thu, Nov 3, 2016 at 5:20 PM, Sebastien Bourdelin
>  wrote:
> 
>> +/* Extra Environment */
>> +#define CONFIG_EXTRA_ENV_SETTINGS \
>> +   "fdt_addr=0x4100\0" \
>> +   "loadkernel=load mmc ${mmcdev}:${mmcpart} ${loadaddr} zImage\0" \
>> +   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ts4600.dtb\0" \
> 
> Not related to this patch: do you plan to submit ts4600.dts for
> mainline inclusion as well?
> 
It's in my todo list yes, but nothing really planned currently, do you
think i should keep the mx28evk dtb instead?

> Regards,
> 
> Fabio Estevam
>

Regards,

Sebastien Bourdelin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] rpi: passthrough of the firmware provided FDT blob

[Cédric Schieli]

Raspberry firmware used to pass a FDT blob at a fixed address (0x100),
but this is not true anymore. The address now depends on both the
memory size and the blob size [1].

If one wants to passthrough this FDT blob to the kernel, the most
reliable way is to save its address from the r2/x0 register in the
U-Boot entry point and expose it in a environment variable for
further processing.

This patch just does this:
- save the provided address in the global variable fw_dtb_pointer
- expose it in ${fdt_addr} if it points to a a valid FDT blob

There are many different ways to use it. One can, for example, use
the following script which will extract from the tree the command
line built by the firmware, then hand over the blob to a previously
loaded kernel:

if fdt addr ${fdt_addr}
then
fdt get value bootargs /chosen bootargs
bootz ${kernel_addr_r} - ${fdt_addr}
fi

Alternatively, users relying on sysboot/pxe can simply omit any FDT
statement in their extlinux.conf file, U-Boot will automagically pick
${fdt_addr} and pass it to the kernel.

Please note that for this to work the U-Boot binary must be tagged
with a recent version of the mkknlimg script found in the Rasperry
Fundation's kernel tree:

/scripts/mkknlimg --dtok /u-boot.bin /boot/u-boot.bin

[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107=134018

Signed-off-by: Cédric Schieli 
---

Changes in v2:
- merge the series in a single patch
- convert the save_boot_params() function to C code
- add a board_get_usable_ram_top() function to protect the blob
  during relocation
- remove the (obsolete) extern declaration from include/configs/rpi.h
- rename the global variable to fw_dtb_pointer
- rename the environment variable to ${fdt_addr}
- fix 64-bits compatibility issues
- document possible uses of ${fdt_addr}

 board/raspberrypi/rpi/rpi.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index 6245b36..b1614b9 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -25,6 +25,21 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+/* From init.S */
+extern void save_boot_params_ret(void);
+
+static unsigned long fw_dtb_pointer __attribute__ ((section(".data")));
+
+#ifdef CONFIG_ARM64
+void save_boot_params(unsigned long dtb)
+#else
+void save_boot_params(unsigned long r0, unsigned long r1, unsigned long dtb)
+#endif
+{
+   fw_dtb_pointer = dtb;
+   save_boot_params_ret();
+}
+
 static const struct bcm2835_gpio_platdata gpio_platdata = {
.base = BCM2835_GPIO_BASE,
 };
@@ -285,6 +300,31 @@ static void set_fdtfile(void)
setenv("fdtfile", fdtfile);
 }
 
+/*
+ * If the firmware provided a valid FDT at boot time, let's expose it in
+ * ${fdt_addr} so it may be passed unmodified to the kernel.
+ */
+static void set_fdt_addr(void)
+{
+   if (getenv("fdt_addr"))
+   return;
+
+   if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
+   return;
+
+   setenv_hex("fdt_addr", fw_dtb_pointer);
+}
+
+/*
+ * Prevent relocation from stomping on a firmware provided FDT blob.
+ */
+unsigned long board_get_usable_ram_top(unsigned long total_size)
+{
+   if ((gd->ram_top - fw_dtb_pointer) > SZ_64M)
+   return gd->ram_top;
+   return fw_dtb_pointer &~0x;
+}
+
 static void set_usbethaddr(void)
 {
ALLOC_CACHE_ALIGN_BUFFER(struct msg_get_mac_address, msg, 1);
@@ -356,6 +396,7 @@ static void set_serial_number(void)
 
 int misc_init_r(void)
 {
+   set_fdt_addr();
set_fdtfile();
set_usbethaddr();
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
-- 
2.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function

[Mark Rutland]

On Fri, Oct 28, 2016 at 09:35:37PM +, york sun wrote:
> I am struggling on the dcache_disable() which implies all dcache is 
> flushed. I don't have a reasonable way to flush all if I want to skip 
> L3. I tried to benchmark flushing by VA to cover my entire 16GB memory. 
> It took 30+ seconds. On the other side, flushing by set/way and flushing 
> L3 together took 7 ms. If I only flush U-Boot stack in this function, it 
> can run really fast, but that defeats the purpose of flush all cache.
> 
> I thought of parsing each set/way to find the address of each cache line 
> (I don't know how to do that yet), but the tag only contains physical 
> address not VA.

With the MMU off, translation is an idmap (i.e. VA == PA), so if you
have physical addresses, you can use those directly.

That said, the presence and implementation of any mechanism to read
addresses from the cache is IMPLEMENTATION DEFINED, so this will not be
portable.

> The ARM document shows example code to clean entire data or unified 
> cache to PoC, very similar to the code we have in U-Boot armv8/cache.S.

Do you mean the "Example code for cache maintenance instructions"?

In recent versions of the ARM ARM there's a large note explaining why
this only works in very restricted scenarios (and cannot be used to
affect system caches such as your L3).

In the latest ARM ARM ("ARM DDI 0487A.k"), see page D3-1710.

> Unless there are other cache maintenance instruction I am not aware of, 
> I don't see how to flush to PoC by set/way.

Architecturally, Set/Way operations are not guaranteed to affect al
caches prior to the PoC, and may require other IMPLEMENTATION DEFINED
maintenance (e.g. MMIO control of system-level caches).

Thanks,
Mark.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function

[Mark Rutland]

On Fri, Oct 28, 2016 at 12:32:36PM -0600, Stephen Warren wrote:
> Related, consider the following from the Linux kernel's
> Documentation/arm64/booting.txt:
> 
> >- Caches, MMUs
> >  The MMU must be off.
> >  Instruction cache may be on or off.
> >  The address range corresponding to the loaded kernel image must be
> >  cleaned to the PoC.
> 
> (That only applies to the kernel image specifically, but doing the
> same for the entire cache content seems reasonable, perhaps even
> required for other reasons?)

It's certainly preferable.

The wording is somewhat poor too, and needs soem fixing up.

If anything has been allocated into the cache which may conflict with
later use with Normal Inner-Shareable Inner-WB Outer-WB mappings, thise
needs to be (Cleaned+)Invalidated from the caches.

Thanks,
Mark.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 4/7] toradex: config block handling

[Marcel Ziswiler]

Add Toradex factory configuration block handling. The config block is a
data structure which gets stored to flash during production testing. The
structure holds such information as board resp. hardware revision,
product ID and serial number which is used as the NIC part of the
Ethernet MAC address as well. The config block will be read upon boot by
the show_board_info() function, displayed as part of the board
information and passed to Linux via device tree or ATAGs.

Signed-off-by: Marcel Ziswiler 
Acked-by: Max Krummenacher 

---

Changes in v4: None
Changes in v3:
- use custom show_board_info() rather than checkboard() and
  checkboard() rather than checkboard_fallback()
- also reword commit message accordingly

Changes in v2: None

 board/toradex/common/Kconfig |  76 +
 board/toradex/common/Makefile|  11 +
 board/toradex/common/tdx-cfg-block.c | 544 +++
 board/toradex/common/tdx-cfg-block.h |  68 +
 board/toradex/common/tdx-common.c| 168 +++
 board/toradex/common/tdx-common.h|  13 +
 6 files changed, 880 insertions(+)
 create mode 100644 board/toradex/common/Kconfig
 create mode 100644 board/toradex/common/Makefile
 create mode 100644 board/toradex/common/tdx-cfg-block.c
 create mode 100644 board/toradex/common/tdx-cfg-block.h
 create mode 100644 board/toradex/common/tdx-common.c
 create mode 100644 board/toradex/common/tdx-common.h

diff --git a/board/toradex/common/Kconfig b/board/toradex/common/Kconfig
new file mode 100644
index 000..0ec3d6e
--- /dev/null
+++ b/board/toradex/common/Kconfig
@@ -0,0 +1,76 @@
+# Copyright (c) 2016 Toradex, Inc.
+# SPDX-License-Identifier: GPL-2.0+
+
+menuconfig TDX_CFG_BLOCK
+   bool "Enable Toradex config block support"
+   select OF_BOARD_SETUP
+   help
+ The Toradex config block stored production data on the on-module
+ flash device (NAND, NOR or eMMC). The area is normally preserved by
+ software and contains the serial number (out of which the MAC
+ address is generated) and the exact module type.
+
+# Helper config to determine the correct default location of the cfg block
+config TDX_HAVE_MMC
+   bool
+
+config TDX_HAVE_NAND
+   bool
+
+config TDX_HAVE_NOR
+   bool
+
+if TDX_CFG_BLOCK
+
+choice TDX_CFG_BLOCK_LOCATION
+   prompt "Toradex config block location"
+   depends on TDX_CFG_BLOCK
+   default TDX_CFG_BLOCK_IS_IN_MMC if TDX_HAVE_MMC
+   default TDX_CFG_BLOCK_IS_IN_NAND if TDX_HAVE_NAND
+   default TDX_CFG_BLOCK_IS_IN_NOR if TDX_HAVE_NOR
+   help
+ Configure the location of the Toradex config block. By default, the
+ factory version of the Toradex config block is on the NAND, NOR or
+ eMMC flash device on the module.
+
+config TDX_CFG_BLOCK_IS_IN_MMC
+   bool "Location of the config block is in eMMC"
+
+config TDX_CFG_BLOCK_IS_IN_NAND
+   bool "Location of the config block is in NAND"
+
+config TDX_CFG_BLOCK_IS_IN_NOR
+   bool "Location of the config block is in NOR"
+
+endchoice
+
+config TDX_CFG_BLOCK_DEV
+   int "Toradex config block eMMC device ID"
+   depends on TDX_CFG_BLOCK_IS_IN_MMC
+
+config TDX_CFG_BLOCK_PART
+   int "Toradex config block eMMC partition ID"
+   depends on TDX_CFG_BLOCK_IS_IN_MMC
+
+config TDX_CFG_BLOCK_OFFSET
+   int "Toradex config block offset"
+   help
+ Specify the byte offset of the Toradex config block within the flash
+ device the config block is stored on.
+
+config TDX_CFG_BLOCK_OFFSET2
+   int "Toradex config block offset, second instance"
+   default 0
+   help
+ Specify the byte offset of the 2nd instance of the Toradex config 
block
+ within the flash device the config block is stored on.
+ Set to 0 on modules which have no 2nd instance.
+
+config TDX_CFG_BLOCK_2ND_ETHADDR
+   bool "Set the second Ethernet address"
+   help
+ For each serial number two Ethernet addresses are available for dual
+ Ethernet carrier boards. This options enables the code to set the
+ second Ethernet address as environment variable (eth1addr).
+
+endif
diff --git a/board/toradex/common/Makefile b/board/toradex/common/Makefile
new file mode 100644
index 000..d645f5a
--- /dev/null
+++ b/board/toradex/common/Makefile
@@ -0,0 +1,11 @@
+# Copyright (c) 2016 Toradex, Inc.
+# SPDX-License-Identifier: GPL-2.0+
+
+# Common for all Toradex modules
+ifeq ($(CONFIG_SPL_BUILD),y)
+# Necessary to create built-in.o
+obj- := __dummy__.o
+else
+obj-$(CONFIG_TDX_CFG_BLOCK) += tdx-cfg-block.o
+obj-y += tdx-common.o
+endif
diff --git a/board/toradex/common/tdx-cfg-block.c 
b/board/toradex/common/tdx-cfg-block.c
new file mode 100644
index 000..0014ce8
--- /dev/null
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -0,0 +1,544 @@
+/*
+ * Copyright (c) 2016 Toradex, Inc.
+ *
+ * 

[U-Boot] [PATCH v4 7/7] colibri_vf: usb gadget: toradex pid is now set generically

[Marcel Ziswiler]

From: Max Krummenacher 

remove now unused CONFIG_TRDX_PID_XXX

Signed-off-by: Marcel Ziswiler 
Acked-by: Stefan Agner 
Acked-by: Max Krummenacher 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 board/toradex/colibri_vf/colibri_vf.c | 16 
 include/configs/colibri_vf.h  |  7 ---
 scripts/config_whitelist.txt  |  5 -
 3 files changed, 28 deletions(-)

diff --git a/board/toradex/colibri_vf/colibri_vf.c 
b/board/toradex/colibri_vf/colibri_vf.c
index c65ccb3..e65d9c3 100644
--- a/board/toradex/colibri_vf/colibri_vf.c
+++ b/board/toradex/colibri_vf/colibri_vf.c
@@ -528,22 +528,6 @@ int checkboard(void)
return 0;
 }
 
-int g_dnl_bind_fixup(struct usb_device_descriptor *dev, const char *name)
-{
-   unsigned short usb_pid;
-
-   put_unaligned(CONFIG_TRDX_VID, >idVendor);
-
-   if (is_colibri_vf61())
-   usb_pid = CONFIG_TRDX_PID_COLIBRI_VF61IT;
-   else
-   usb_pid = CONFIG_TRDX_PID_COLIBRI_VF50IT;
-
-   put_unaligned(usb_pid, >idProduct);
-
-   return 0;
-}
-
 #ifdef CONFIG_USB_EHCI_VF
 int board_ehci_hcd_init(int port)
 {
diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index 0e622fb..0cd77ff 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -208,13 +208,6 @@
 #define CONFIG_USB_MAX_CONTROLLER_COUNT 2
 #define CONFIG_EHCI_HCD_INIT_AFTER_RESET
 
-/* USB Client Support */
-#define CONFIG_TRDX_VID  0x1B67
-#define CONFIG_TRDX_PID_COLIBRI_VF50 0x0016
-#define CONFIG_TRDX_PID_COLIBRI_VF61 0x0017
-#define CONFIG_TRDX_PID_COLIBRI_VF61IT   0x0018
-#define CONFIG_TRDX_PID_COLIBRI_VF50IT   0x0019
-
 /* USB DFU */
 #define CONFIG_SYS_DFU_DATA_BUF_SIZE (1024 * 1024)
 
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index d476367..c0571c3 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -7985,11 +7985,6 @@ CONFIG_TRACE_EARLY_ADDR
 CONFIG_TRACE_EARLY_SIZE
 CONFIG_TRAILBLAZER
 CONFIG_TRATS
-CONFIG_TRDX_PID_COLIBRI_VF50
-CONFIG_TRDX_PID_COLIBRI_VF50IT
-CONFIG_TRDX_PID_COLIBRI_VF61
-CONFIG_TRDX_PID_COLIBRI_VF61IT
-CONFIG_TRDX_VID
 CONFIG_TSEC
 CONFIG_TSEC1
 CONFIG_TSEC1_NAME
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 0/7] toradex: config block handling

[Marcel Ziswiler]

This series integrates Toradex factory configuration block handling. The
config block is a data structure which gets stored to flash during
production testing. The structure holds such information as board resp.
hardware revision, product ID and serial number which is used as the NIC
part of the Ethernet MAC address as well. The config block will be read
upon boot by the show_board_info() function, displayed as part of the
board information and passed to Linux via device tree or ATAGs.

Changes in v4:
- add various peoples acked- resp. reviewed-bys with which it now
  hopefully could be pulled in ASAP

Changes in v3:
- introduce new patch dropping unused CONFIG_CUSTOM_BOARDINFO by
  reverting commit a9ad18c9d5fe2554753b0f9a52adfd5ebce61147
- introduce new patch making show_board_info() a weak function which
  allows for custom board specific implementations thereof
- fixup deactivation of CONFIG_DISPLAY_BOARDINFO in favour of
  CONFIG_DISPLAY_BOARDINFO_LATE which also displays on the LCD after
  recent move thereof to Kconfig
- use custom show_board_info() rather than checkboard() and
  checkboard() rather than checkboard_fallback()
- also reword commit message accordingly
- use checkboard() rather than checkboard_fallback()
- drop CUSTOM_BOARDINFO
- drop patch 1 'colibri_imx7/vf: move to custom checkboard_fallback()'
  in favour of Stefan's proposed solution

Changes in v2:
- fixed common.h include mess in board/toradex/common by renaming
  common* to tdx-common
- renamed TRDX to TDX and trdx to tdx as in common use internally
- consolidated makefiles and changed copyright message
- renamed configblock* to tdx-cfg-block* analogous to Kconfig symbols
- moved board/toradex/common/Kconfig sourcing from arch/arm/Kconfig
  into our own board Kconfig files
- use a named choice for the config block location for above to work
  without issuing any warnings (undocumented kbuild feature curtsey
  Arnaud Lacombe)
- added CUSTOM_BOARDINFO into our common Kconfig to avoid recent
  no_new_adhoc_configs_check error
- add Max' patch
  colibri_vf: usb gadget: toradex pid is now set generically

Marcel Ziswiler (6):
  Revert "generic-board: allow showing custom board info"
  generic-board: make show_board_info a weak function
  apalis/colibri_t20/t30: deactivate displaying board info
  toradex: config block handling
  apalis/colibri_imx7/pxa270/t20/t30/vf: integrate config block handling
  apalis/colibri_t30: move environment location

Max Krummenacher (1):
  colibri_vf: usb gadget: toradex pid is now set generically

 board/toradex/apalis_t30/Kconfig  |  18 +
 board/toradex/apalis_t30/apalis_t30.c |  12 +-
 board/toradex/colibri_imx7/Kconfig|  16 +
 board/toradex/colibri_pxa270/Kconfig  |  11 +
 board/toradex/colibri_pxa270/colibri_pxa270.c |   8 +
 board/toradex/colibri_t20/Kconfig |  11 +
 board/toradex/colibri_t20/colibri_t20.c   |  13 +
 board/toradex/colibri_t30/Kconfig |  18 +
 board/toradex/colibri_t30/colibri_t30.c   |   9 +-
 board/toradex/colibri_vf/Kconfig  |  14 +
 board/toradex/colibri_vf/colibri_vf.c |  16 -
 board/toradex/common/Kconfig  |  76 
 board/toradex/common/Makefile |  11 +
 board/toradex/common/tdx-cfg-block.c  | 544 ++
 board/toradex/common/tdx-cfg-block.h  |  68 
 board/toradex/common/tdx-common.c | 168 
 board/toradex/common/tdx-common.h |  13 +
 common/board_info.c   |   4 +-
 configs/apalis_t30_defconfig  |   1 +
 configs/colibri_t20_defconfig |   1 +
 configs/colibri_t30_defconfig |   1 +
 configs/colibri_vf_defconfig  |   1 +
 include/configs/apalis_t30.h  |  11 +-
 include/configs/colibri_imx7.h|   6 +-
 include/configs/colibri_pxa270.h  |   6 +-
 include/configs/colibri_t20.h |   2 +-
 include/configs/colibri_t30.h |  11 +-
 include/configs/colibri_vf.h  |  13 +-
 scripts/config_whitelist.txt  |   5 -
 29 files changed, 1041 insertions(+), 47 deletions(-)
 create mode 100644 board/toradex/common/Kconfig
 create mode 100644 board/toradex/common/Makefile
 create mode 100644 board/toradex/common/tdx-cfg-block.c
 create mode 100644 board/toradex/common/tdx-cfg-block.h
 create mode 100644 board/toradex/common/tdx-common.c
 create mode 100644 board/toradex/common/tdx-common.h

-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 3/7] apalis/colibri_t20/t30: deactivate displaying board info

[Marcel Ziswiler]

Deactivate CONFIG_DISPLAY_BOARDINFO in favour of
CONFIG_DISPLAY_BOARDINFO_LATE which also displays on the LCD.

Signed-off-by: Marcel Ziswiler 
Acked-by: Max Krummenacher 

---

Changes in v4: None
Changes in v3:
- fixup deactivation of CONFIG_DISPLAY_BOARDINFO in favour of
  CONFIG_DISPLAY_BOARDINFO_LATE which also displays on the LCD after
  recent move thereof to Kconfig

Changes in v2: None

 configs/apalis_t30_defconfig  | 1 +
 configs/colibri_t20_defconfig | 1 +
 configs/colibri_t30_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/apalis_t30_defconfig b/configs/apalis_t30_defconfig
index 640c9ce..0ac2fe6 100644
--- a/configs/apalis_t30_defconfig
+++ b/configs/apalis_t30_defconfig
@@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="tegra30-apalis"
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_CONSOLE_MUX=y
 CONFIG_SYS_STDIO_DEREGISTER=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Apalis T30 # "
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/colibri_t20_defconfig b/configs/colibri_t20_defconfig
index 5f95e3e..fa56a75 100644
--- a/configs/colibri_t20_defconfig
+++ b/configs/colibri_t20_defconfig
@@ -5,6 +5,7 @@ CONFIG_TARGET_COLIBRI_T20=y
 CONFIG_DEFAULT_DEVICE_TREE="tegra20-colibri"
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_SYS_STDIO_DEREGISTER=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Colibri T20 # "
 CONFIG_CMD_BOOTZ=y
diff --git a/configs/colibri_t30_defconfig b/configs/colibri_t30_defconfig
index de00afe..cb24627 100644
--- a/configs/colibri_t30_defconfig
+++ b/configs/colibri_t30_defconfig
@@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="tegra30-colibri"
 CONFIG_OF_SYSTEM_SETUP=y
 CONFIG_CONSOLE_MUX=y
 CONFIG_SYS_STDIO_DEREGISTER=y
+# CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="Colibri T30 # "
 CONFIG_CMD_BOOTZ=y
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 5/7] apalis/colibri_imx7/pxa270/t20/t30/vf: integrate config block handling

[Marcel Ziswiler]

With our common code in place actually make use of it across all our
modules.

Signed-off-by: Marcel Ziswiler 
Acked-by: Max Krummenacher 

---

Changes in v4: None
Changes in v3:
- use checkboard() rather than checkboard_fallback()
- drop CUSTOM_BOARDINFO

Changes in v2: None

 board/toradex/apalis_t30/Kconfig  | 18 ++
 board/toradex/apalis_t30/apalis_t30.c | 12 +++-
 board/toradex/colibri_imx7/Kconfig| 16 
 board/toradex/colibri_pxa270/Kconfig  | 11 +++
 board/toradex/colibri_pxa270/colibri_pxa270.c |  8 
 board/toradex/colibri_t20/Kconfig | 11 +++
 board/toradex/colibri_t20/colibri_t20.c   | 13 +
 board/toradex/colibri_t30/Kconfig | 18 ++
 board/toradex/colibri_t30/colibri_t30.c   |  9 -
 board/toradex/colibri_vf/Kconfig  | 14 ++
 configs/colibri_vf_defconfig  |  1 +
 include/configs/apalis_t30.h  |  4 ++--
 include/configs/colibri_imx7.h|  6 +-
 include/configs/colibri_pxa270.h  |  6 +-
 include/configs/colibri_t20.h |  2 +-
 include/configs/colibri_t30.h |  4 ++--
 include/configs/colibri_vf.h  |  6 --
 17 files changed, 148 insertions(+), 11 deletions(-)

diff --git a/board/toradex/apalis_t30/Kconfig b/board/toradex/apalis_t30/Kconfig
index f1dcda5..16224da 100644
--- a/board/toradex/apalis_t30/Kconfig
+++ b/board/toradex/apalis_t30/Kconfig
@@ -9,4 +9,22 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "apalis_t30"
 
+config TDX_CFG_BLOCK
+   default y
+
+config TDX_HAVE_MMC
+   default y
+
+config TDX_CFG_BLOCK_DEV
+   default "0"
+
+config TDX_CFG_BLOCK_PART
+   default "1"
+
+# Toradex config block in eMMC, at the end of 1st "boot sector"
+config TDX_CFG_BLOCK_OFFSET
+   default "-512"
+
+source "board/toradex/common/Kconfig"
+
 endif
diff --git a/board/toradex/apalis_t30/apalis_t30.c 
b/board/toradex/apalis_t30/apalis_t30.c
index 3f56971..3d83491 100644
--- a/board/toradex/apalis_t30/apalis_t30.c
+++ b/board/toradex/apalis_t30/apalis_t30.c
@@ -1,5 +1,5 @@
 /*
- *  (C) Copyright 2014
+ *  (C) Copyright 2014-2016
  *  Marcel Ziswiler 
  *
  * SPDX-License-Identifier:GPL-2.0+
@@ -17,6 +17,8 @@
 
 #include "pinmux-config-apalis_t30.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #define PMU_I2C_ADDRESS0x2D
 #define MAX_I2C_RETRY  3
 
@@ -29,6 +31,14 @@ int arch_misc_init(void)
return 0;
 }
 
+int checkboard(void)
+{
+   printf("Model: Toradex Apalis T30 %dGB\n",
+  (gd->ram_size == 0x4000) ? 1 : 2);
+
+   return 0;
+}
+
 /*
  * Routine: pinmux_init
  * Description: Do individual peripheral pinmux configs
diff --git a/board/toradex/colibri_imx7/Kconfig 
b/board/toradex/colibri_imx7/Kconfig
index 7bba26b..414a600 100644
--- a/board/toradex/colibri_imx7/Kconfig
+++ b/board/toradex/colibri_imx7/Kconfig
@@ -16,5 +16,21 @@ config COLIBRI_IMX7_EXT_PHYCLK
  clock source.
default y
 
+config TDX_CFG_BLOCK
+   default y
+
+config TDX_HAVE_NAND
+   default y
+
+config TDX_CFG_BLOCK_OFFSET
+   default "2048"
+
+config TDX_CFG_BLOCK_OFFSET2
+   default "133120"
+
+config TDX_CFG_BLOCK_2ND_ETHADDR
+   default y
+
+source "board/toradex/common/Kconfig"
 
 endif
diff --git a/board/toradex/colibri_pxa270/Kconfig 
b/board/toradex/colibri_pxa270/Kconfig
index 949407a..f646baa 100644
--- a/board/toradex/colibri_pxa270/Kconfig
+++ b/board/toradex/colibri_pxa270/Kconfig
@@ -9,4 +9,15 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "colibri_pxa270"
 
+config TDX_CFG_BLOCK
+   default y
+
+config TDX_HAVE_NOR
+   default y
+
+config TDX_CFG_BLOCK_OFFSET
+   default "262144"
+
+source "board/toradex/common/Kconfig"
+
 endif
diff --git a/board/toradex/colibri_pxa270/colibri_pxa270.c 
b/board/toradex/colibri_pxa270/colibri_pxa270.c
index 3def0a6..de8cb28 100644
--- a/board/toradex/colibri_pxa270/colibri_pxa270.c
+++ b/board/toradex/colibri_pxa270/colibri_pxa270.c
@@ -2,6 +2,7 @@
  * Toradex Colibri PXA270 Support
  *
  * Copyright (C) 2010 Marek Vasut 
+ * Copyright (C) 2016 Marcel Ziswiler 
  *
  * SPDX-License-Identifier:GPL-2.0+
  */
@@ -32,6 +33,13 @@ int board_init(void)
return 0;
 }
 
+int checkboard(void)
+{
+   puts("Model: Toradex Colibri PXA270\n");
+
+   return 0;
+}
+
 int dram_init(void)
 {
pxa2xx_dram_init();
diff --git a/board/toradex/colibri_t20/Kconfig 
b/board/toradex/colibri_t20/Kconfig
index 7f373b2..a43acdd 100644
--- a/board/toradex/colibri_t20/Kconfig
+++ b/board/toradex/colibri_t20/Kconfig
@@ -9,4 +9,15 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "colibri_t20"
 
+config 

[U-Boot] [PATCH v4 6/7] apalis/colibri_t30: move environment location

[Marcel Ziswiler]

Now with the config block handling in place move the U-Boot environment
location before the config block at the end of 1st "boot sector" as
deployed during production using our downstream BSP.

Signed-off-by: Marcel Ziswiler 
Acked-by: Max Krummenacher 

---

Changes in v4:
- add various peoples acked- resp. reviewed-bys with which it now
  hopefully could be pulled in ASAP

Changes in v3:
- drop patch 1 'colibri_imx7/vf: move to custom checkboard_fallback()'
  in favour of Stefan's proposed solution

Changes in v2:
- fixed common.h include mess in board/toradex/common by renaming
  common* to tdx-common
- renamed TRDX to TDX and trdx to tdx as in common use internally
- consolidated makefiles and changed copyright message
- renamed configblock* to tdx-cfg-block* analogous to Kconfig symbols
- moved board/toradex/common/Kconfig sourcing from arch/arm/Kconfig
  into our own board Kconfig files
- use a named choice for the config block location for above to work
  without issuing any warnings (undocumented kbuild feature curtsey
  Arnaud Lacombe)
- added CUSTOM_BOARDINFO into our common Kconfig to avoid recent
  no_new_adhoc_configs_check error
- add Max' patch
  colibri_vf: usb gadget: toradex pid is now set generically

 include/configs/apalis_t30.h  | 7 ---
 include/configs/colibri_t30.h | 7 ---
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/configs/apalis_t30.h b/include/configs/apalis_t30.h
index 069ed20..f2a24c1 100644
--- a/include/configs/apalis_t30.h
+++ b/include/configs/apalis_t30.h
@@ -32,11 +32,12 @@
 #define CONFIG_GENERIC_MMC
 #define CONFIG_TEGRA_MMC
 
-/* Environment in eMMC, at the end of 2nd "boot sector" */
+/* Environment in eMMC, before config block at the end of 1st "boot sector" */
 #define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET  (-CONFIG_ENV_SIZE)
+#define CONFIG_ENV_OFFSET  (-CONFIG_ENV_SIZE + \
+CONFIG_TDX_CFG_BLOCK_OFFSET)
 #define CONFIG_SYS_MMC_ENV_DEV 0
-#define CONFIG_SYS_MMC_ENV_PART2
+#define CONFIG_SYS_MMC_ENV_PART1
 
 /* USB host support */
 #define CONFIG_USB_EHCI
diff --git a/include/configs/colibri_t30.h b/include/configs/colibri_t30.h
index 1ab5c41..e8b3f99 100644
--- a/include/configs/colibri_t30.h
+++ b/include/configs/colibri_t30.h
@@ -32,11 +32,12 @@
 #define CONFIG_GENERIC_MMC
 #define CONFIG_TEGRA_MMC
 
-/* Environment in eMMC, at the end of 2nd "boot sector" */
+/* Environment in eMMC, before config block at the end of 1st "boot sector" */
 #define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET  (-CONFIG_ENV_SIZE)
+#define CONFIG_ENV_OFFSET  (-CONFIG_ENV_SIZE + \
+CONFIG_TDX_CFG_BLOCK_OFFSET)
 #define CONFIG_SYS_MMC_ENV_DEV 0
-#define CONFIG_SYS_MMC_ENV_PART2
+#define CONFIG_SYS_MMC_ENV_PART1
 
 /* USB host support */
 #define CONFIG_USB_EHCI
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 1/7] Revert "generic-board: allow showing custom board info"

[Marcel Ziswiler]

Drop CONFIG_CUSTOM_BOARDINFO as it is not Kconfig compliant and anyway
not really used anywhere plus the upcoming weak show_board_info()
approach seems much superior.

This reverts commit a9ad18c9d5fe2554753b0f9a52adfd5ebce61147.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Tom Rini 
Acked-by: Max Krummenacher 

---

Changes in v4: None
Changes in v3:
- introduce new patch dropping unused CONFIG_CUSTOM_BOARDINFO by
  reverting commit a9ad18c9d5fe2554753b0f9a52adfd5ebce61147

Changes in v2: None

 common/board_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/board_info.c b/common/board_info.c
index bd5dcfa..6afe98e 100644
--- a/common/board_info.c
+++ b/common/board_info.c
@@ -17,7 +17,7 @@ int __weak checkboard(void)
  */
 int show_board_info(void)
 {
-#if defined(CONFIG_OF_CONTROL) && !defined(CONFIG_CUSTOM_BOARDINFO)
+#ifdef CONFIG_OF_CONTROL
DECLARE_GLOBAL_DATA_PTR;
const char *model;
 
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 2/7] generic-board: make show_board_info a weak function

[Marcel Ziswiler]

Make show_board_info() a weak function which allows for custom board
specific implementations thereof.

Signed-off-by: Marcel Ziswiler 
Reviewed-by: Tom Rini 
Acked-by: Max Krummenacher 

---

Changes in v4: None
Changes in v3:
- introduce new patch making show_board_info() a weak function which
  allows for custom board specific implementations thereof

Changes in v2: None

 common/board_info.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/board_info.c b/common/board_info.c
index 6afe98e..aa45e24 100644
--- a/common/board_info.c
+++ b/common/board_info.c
@@ -15,7 +15,7 @@ int __weak checkboard(void)
  * If the root node of the DTB has a "model" property, show it.
  * Then call checkboard().
  */
-int show_board_info(void)
+int __weak show_board_info(void)
 {
 #ifdef CONFIG_OF_CONTROL
DECLARE_GLOBAL_DATA_PTR;
-- 
2.5.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] evb-rk3399: deduced the dram node size when space reserved

[Kever Yang]

The size dram node need to be deduced by the same amount of reserved space.


Signed-off-by: Kever Yang 
---

 board/rockchip/evb_rk3399/evb-rk3399.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c 
b/board/rockchip/evb_rk3399/evb-rk3399.c
index c6e6cd3..c437f1b 100644
--- a/board/rockchip/evb_rk3399/evb-rk3399.c
+++ b/board/rockchip/evb_rk3399/evb-rk3399.c
@@ -71,5 +71,5 @@ void dram_init_banksize(void)
 {
/* Reserve 0x20 for ATF bl31 */
gd->bd->bi_dram[0].start = 0x20;
-   gd->bd->bi_dram[0].size = 0x8000;
+   gd->bd->bi_dram[0].size = 0x7e00;
 }
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tools: Makefile: improve cross_tools target usability

[Stefan Müller-Klieser]

On 05.11.2016 18:41, Masahiro Yamada wrote:
> Hi.
Hi!

> 
> 2016-10-31 22:15 GMT+09:00 Stefan Müller-Klieser 
> :
>> When building the cross_tools target, HOSTCFLAGS and HOSTLDFLAGS will
>> propagate to the target build. This should not happen and is easy to
>> prevent.
>>
>> Signed-off-by: Stefan Müller-Klieser 
>> ---
>>  tools/Makefile | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/tools/Makefile b/tools/Makefile
>> index 400588c..305336c 100644
>> --- a/tools/Makefile
>> +++ b/tools/Makefile
>> @@ -263,6 +263,8 @@ subdir- += env
>>
>>  ifneq ($(CROSS_BUILD_TOOLS),)
>>  HOSTCC = $(CC)
>> +HOSTCFLAGS = $(CFLAGS)
>> +HOSTLDFLAGS = $(LDFLAGS)
> 
> 
> In the current U-Boot build system (= Kbuild),
> CFLAGS is never set, never referenced.
> 
> For the target build, KBUILD_CFLAGS is used instead.

Well, having the cross_tools target, Kbuild actually creates binaries
for two different runtime environments. First we have the u-boot, which
is a bare metal app controlled by e.g. the KBUILD_CFLAGS, and then
we have the cross tools which are linux userspace binaries. The compilation
of the userspace binaries can be very different and kbuild cannot know about
it, e.g. it does not make much sense to set compiler defaults, in my opinion,

> 
> 
> So, $(CFLAGS) is always empty unless your environment
> explicitly sets it.
> Likewise for LDFLAGS.

As intended.

> 
> 
> Did you mean
> 
> HOSTCFLAGS =
> HOSTLDFLAGS =

That would certainly fix the current bug. Reading your comments make me
think that I should have created two different patches, and I even have
one more queued.

> 
> or
> 
> HOSTCFLAGS = $(KBUILD_CFLAGS)
> HOSTLDFLAGS =

That being said, no I think that would create even more confusion.


> 
> ?

Thanks for the review. Looking at the kbuild documentation, the case for CFLAGS
and LDFLAGS is actually different, as LDFLAGS are well defined and CFLAGS are 
not.
The case for cross tools is not specified, to my understanding, please correct 
me.
So another proposal would be:

HOSTCFLAGS = $(TARGETCFLAGS)
HOSTLDFLAGS = $(TARGETLDFLAGS)

?

Regards, Stefan

> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v7 1/2] armv8: Support loading 32-bit OS in AArch32 execution state

[Ryan Harkin]

Hi Alison,

On 7 November 2016 at 02:21, Alison Wang  wrote:
>> On 11/04/2016 10:12 AM, Alexander Graf wrote:
>> >
>> >
>> > On 04/11/2016 17:08, york sun wrote:
>> >> On 11/04/2016 09:53 AM, Alexander Graf wrote:
>> >>>
>> >>>
>> >>> On 04/11/2016 16:43, york sun wrote:
>>  On 11/04/2016 09:32 AM, Ryan Harkin wrote:
>> >>>
>> >>> Yes, with the attached patch on top of your original 2 patches,
>> >>> everything works again.  I tested on FVP Foundation and AEMv8
>> >>> models and Juno R0, R1 and R2.
>> >>>
>> >>> I don't think it would be good to stack these three patches the
>> >>> way they are presented in the upstream tree because it would
>> not
>> >>> be bisect-able.  Some re-work or re-ordering would be needed.
>> >>>
>> >>> Note: I haven't attempted to understand what any of this code
>> is
>> >>> doing, I'm just testing it with my standard boot flow to make
>> >>> sure nothing is broken for me.
>> >>
>> >> Ryan,
>> >>
>> >> I support Alison's patch order for her 32-bit patch sets. This
>> >> feature doesn't exist before her first set. It is functional if
>> >> you run U-Boot at EL3 after the first patch.
>> >
>> > Which I don't do.  I follow the boot flow recommended by ARM and
>> > it doesn't work for that setup, which I don't think is the right
>> > thing to do.
>> >
>> >
>> >> It gets EL2 working after the 2nd set. If there is room to
>> >> clarify in the commit message, please kindly suggest.
>> >>
>> >
>> > Well, I'm not the maintainer of the tree, but I wouldn't want to
>> > have a tree that wasn't bootable at any point in the patch
>> sequence.
>> > That's generally unacceptable on most projects I work on.
>> Keeping
>> > the tree bisect-able to prove which commit caused a problem is
>> > considered to be a valuable tool.
>> >
>> 
>>  Ryan,
>> 
>>  Thanks for sharing your concern. I support git-bisect. It is
>>  valuable, no doubt. Let me try to understand the issue here.
>>  Without Alison's patches, everything boots OK. With her first set,
>> does something break?
>> >>>
>> >>> Yes, with the patches booting 64bit Linux with U-Boot running in
>> EL2
>> >>> breaks according to Ryan.
>> >>>
>>  My understanding is 32-bit OS can boot. If existing 64-bit OS
>>  fails, then she needs to fix it.
>> >>>
>> >>> That's his point :). And I concur.
>> >>
>> >> Thanks for the confirmation.
>> >>
>> >>>
>> >>> (btw, you guys really should start thinking about following the ARM
>> >>> recommended boot model. It's pretty cumbersome to do everything
>> >>> different just for NXP)
>> >>
>> >> If you are referring the trusted firmware, we are following that
>> >> direction. Just not fully up yet on some platform.
>> >>
>> >> It is definitely not our intention to be cumbersome. Please point
>> out
>> >> where it went sideway beside the trusted firmware.
>> >
>> > Basically it boils down to the fact that you are the only platform
>> > that runs U-Boot in EL3 :).
>> >
>> > If you want to keep the memory initialization inside of U-Boot, I
>> > think that's great. But you could either split that into SPL/EL2 or
>> > degrade yourself into EL2 as soon as possible by calling into an EL3
>> firmware.
>> > Whether you build that firmware as part of U-Boot (the stock one
>> could
>> > be very trivial) or externally is not really too much of a problem.
>> >
>> > Things like Alison's patches could then do a simple PSCI call into
>> > said
>> > EL3 firmware to call into 32bit code in EL2 for example.
>> >
>>
>> Basically I agree with you. U-Boot will run at EL2 as soon as we have
>> the trusted firmware in place.
>>
> [Alison Wang] Thanks for all your comments.
>
> For the issue about the tree would not be bisect-able, I have
> a solution. Actually it is the root cause that 64-bit kernel could not boot
> up when U-Boot is running in EL2. I will move these codes from the third patch
> to the first patch.
>
> ENTRY(armv8_switch_to_el2)
> switch_el x5, 1f, 0f, 0f
> -0: ret
> +   /*
> +* x3 is kernel entry point or switch_to_el1
> + * if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
> + * When running in EL2 now, jump to the
> + * address saved in x3.
> +*/
> +0: br x3
>  1: armv8_switch_to_el2_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el2)
>
>  ENTRY(armv8_switch_to_el1)
>   switch_el x5, 0f, 1f, 0f
> -0: ret
> +
> +   /*
> + * x3 is kernel entry point. When running in EL1
> + * now, jump to the address saved in x3.
> +*/
> +0: br x3
>  1: armv8_switch_to_el1_m x3, x4, x5
>  ENDPROC(armv8_switch_to_el1)
>
> With this re-order, the bitsect issue will be fixed and there is not a point
> that kernel could not boot up.
>

That sounds perfect.


> If you all agree with this re-order, I will send out the v8 patch includes the
> first, 

Re: [U-Boot] [PATCH] evb-rk3399: deduced the dram node size when space reserved

[Andreas Färber]

Am 07.11.2016 um 09:30 schrieb Kever Yang:
> The size dram node need to be deduced by the same amount of reserved space.
> 
> 

Reported-by: Andreas Färber 

> Signed-off-by: Kever Yang 

Reviewed-by: Andreas Färber 

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] config: evb-rk3399: enable PWM_ROCKCHIP

[Kever Yang]

PWM_ROCKCHIP need to enable for PWM regulator, this config
is missing during rebase and new patch set in previous submission.

Signed-off-by: Kever Yang 
---

 configs/evb-rk3399_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index e3edeb7..40a8295 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -24,6 +24,7 @@ CONFIG_ROCKCHIP_DWMMC=y
 CONFIG_ROCKCHIP_SDHCI=y
 CONFIG_PINCTRL=y
 CONFIG_ROCKCHIP_RK3399_PINCTRL=y
+CONFIG_PWM_ROCKCHIP=y
 CONFIG_REGULATOR_PWM=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_RAM=y
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] mmc: sunxi: Enable 8bits bus width for sun8i

[Chen-Yu Tsai]

On Mon, Nov 7, 2016 at 4:39 PM, Maxime Ripard
 wrote:
> 1;4600;0c
> On Mon, Nov 07, 2016 at 09:53:00AM +0800, Chen-Yu Tsai wrote:
>> On Mon, Nov 7, 2016 at 1:15 AM, Maxime Ripard
>>  wrote:
>> > On Sat, Nov 05, 2016 at 09:34:25AM +0800, Chen-Yu Tsai wrote:
>> >> On Fri, Nov 4, 2016 at 11:18 PM, Maxime Ripard
>> >>  wrote:
>> >> > The sun8i SoCs also have a 8 bits capable MMC2 controller. Enable the
>> >> > support for those too.
>> >> >
>> >> > Signed-off-by: Maxime Ripard 
>> >> > ---
>> >> >  drivers/mmc/sunxi_mmc.c | 2 +-
>> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
>> >> > index 6953accce123..b8716c93cb06 100644
>> >> > --- a/drivers/mmc/sunxi_mmc.c
>> >> > +++ b/drivers/mmc/sunxi_mmc.c
>> >> > @@ -463,7 +463,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
>> >> >
>> >> > cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
>> >> > cfg->host_caps = MMC_MODE_4BIT;
>> >> > -#ifdef CONFIG_MACH_SUN50I
>> >> > +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
>> >>
>> >> 8 come before 50. :)
>> >
>> > But 5 comes before 8, and 0 before i :)
>>
>> Indeed, though 8 and 50 are akin to a generation number, so
>> it makes sense to sort them in natural order. :)
>
> I know, but it was one of the comments I had in Linux, and we used
> that ordering there. And we probably want to be consistent, but I
> don't really care.

I see we have dictionary order in the ccu driver, natural order in
pinctrl/sunxi/Kconfig, and ordered by SoC name (Axx) in
pinctrl/sunxi/Makefile.

Anyway, no point in bikeshedding over this. Hans, please pick up
this patch as is with my Reviewed-by, unless you have other concerns. :)

ChenYu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] mmc: sunxi: Enable 8bits bus width for sun8i

[Maxime Ripard]

1;4600;0c
On Mon, Nov 07, 2016 at 09:53:00AM +0800, Chen-Yu Tsai wrote:
> On Mon, Nov 7, 2016 at 1:15 AM, Maxime Ripard
>  wrote:
> > On Sat, Nov 05, 2016 at 09:34:25AM +0800, Chen-Yu Tsai wrote:
> >> On Fri, Nov 4, 2016 at 11:18 PM, Maxime Ripard
> >>  wrote:
> >> > The sun8i SoCs also have a 8 bits capable MMC2 controller. Enable the
> >> > support for those too.
> >> >
> >> > Signed-off-by: Maxime Ripard 
> >> > ---
> >> >  drivers/mmc/sunxi_mmc.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> >> > index 6953accce123..b8716c93cb06 100644
> >> > --- a/drivers/mmc/sunxi_mmc.c
> >> > +++ b/drivers/mmc/sunxi_mmc.c
> >> > @@ -463,7 +463,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
> >> >
> >> > cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
> >> > cfg->host_caps = MMC_MODE_4BIT;
> >> > -#ifdef CONFIG_MACH_SUN50I
> >> > +#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
> >>
> >> 8 come before 50. :)
> >
> > But 5 comes before 8, and 0 before i :)
> 
> Indeed, though 8 and 50 are akin to a generation number, so
> it makes sense to sort them in natural order. :)

I know, but it was one of the comments I had in Linux, and we used
that ordering there. And we probably want to be consistent, but I
don't really care.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/4] kconfig: Add API kconfig file

[Emmanuel Vadot]

Add kconfig file to enable API support

Signed-off-by: Emmanuel Vadot 
---
 Kconfig | 2 ++
 api/Kconfig | 9 +
 2 files changed, 11 insertions(+)
 create mode 100644 api/Kconfig

diff --git a/Kconfig b/Kconfig
index 1263d0b..6e7c9b0 100644
--- a/Kconfig
+++ b/Kconfig
@@ -335,6 +335,8 @@ config ARCH_FIXUP_FDT
 
 endmenu# Boot images
 
+source "api/Kconfig"
+
 source "common/Kconfig"
 
 source "cmd/Kconfig"
diff --git a/api/Kconfig b/api/Kconfig
new file mode 100644
index 000..88b4f6c
--- /dev/null
+++ b/api/Kconfig
@@ -0,0 +1,9 @@
+menu "API"
+
+config API
+   bool "Enable U-Boot API"
+   default n
+   help
+ This option enable the U-Boot API.
+
+endmenu
-- 
2.9.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] kconfig: Add a FREEBSD option

[Emmanuel Vadot]

Add a FreeBSD option that enable the API and disable the data cache as
it is needed to boot the FreeBSD loader.

Signed-off-by: Emmanuel Vadot 
---
 common/Kconfig | 9 +
 1 file changed, 9 insertions(+)

diff --git a/common/Kconfig b/common/Kconfig
index 913d21a..73cd205 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -383,4 +383,13 @@ config DISPLAY_BOARDINFO
  when U-Boot starts up. The board function checkboard() is called
  to do this.
 
+config FREEBSD
+   bool "Enable FreeBSD boot"
+   select API
+   select SYS_DCACHE_OFF
+   default n
+   help
+ This option adds boot configuration that can run the FreeBSD
+ loader.
+
 source "common/spl/Kconfig"
-- 
2.9.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/4] kconfig: arm: Add SYS_DCACHE_OFF option

[Emmanuel Vadot]

Add a kconfig option to disable the data cache.

Signed-off-by: Emmanuel Vadot 
---
 arch/arm/Kconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..59b91a0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -118,6 +118,12 @@ config SYS_L2CACHE_OFF
  If SoC does not support L2CACHE or one do not want to enable
  L2CACHE, choose this option.
 
+config SYS_DCACHE_OFF
+   bool "Do not use Data Cache"
+   default n
+   help
+ If one do not want to enable the data cache, choose this option.
+
 config ENABLE_ARM_SOC_BOOT0_HOOK
bool "prepare BOOT0 header"
help
-- 
2.9.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/4] distro_bootcmd: Add command to run FreeBSD

[Emmanuel Vadot]

Add commands that scans for the FreeBSD loader and run it if found.
FreeBSD has two loader: ubldr which is an ELF binary and ubldr.bin which
is a PIE binary.

Signed-off-by: Emmanuel Vadot 
---
 include/config_distro_bootcmd.h | 32 
 1 file changed, 32 insertions(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 9ecaf38..0f5d385 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -153,6 +153,36 @@
 #define SCAN_DEV_FOR_EFI
 #endif
 
+#ifdef CONFIG_FREEBSD
+#define BOOTENV_SHARED_FREEBSD\
+   "boot_freebsd_binary="\
+   "load ${devtype} ${devnum}:${distro_bootpart} "   \
+   "${kernel_addr_r} ubldr.bin; "\
+   "go ${kernel_addr_r}\0"   \
+   \
+   "boot_freebsd_elf="   \
+   "load ${devtype} ${devnum}:${distro_bootpart} "   \
+   "${kernel_addr_r} ubldr; "\
+   "bootelf ${kernel_addr_r}\0"  \
+   \
+   "scan_dev_for_freebsd="   \
+   "if test -e ${devtype} ${devnum}:${distro_bootpart} " \
+   "ubldr.bin; then "\
+   "echo Found FreeBSD U-Boot Loader (bin);" \
+   "run boot_freebsd_binary; "   \
+   "echo FREEBSD FAILED: continuing...; "\
+   "elif test -e ${devtype} ${devnum}:${distro_bootpart} "   \
+   "ubldr; then "\
+   "echo Found FreeBSD U-Boot Loader (elf);" \
+   "run boot_freebsd_elf; "  \
+   "echo FREEBSD FAILED: continuing...; "\
+   "fi;\0"
+#define SCAN_DEV_FOR_FREEBSD "run scan_dev_for_freebsd;"
+#else
+#define BOOTENV_SHARED_FREEBSD
+#define SCAN_DEV_FOR_FREEBSD
+#endif
+
 #ifdef CONFIG_CMD_SATA
 #define BOOTENV_SHARED_SATABOOTENV_SHARED_BLKDEV(sata)
 #define BOOTENV_DEV_SATA   BOOTENV_DEV_BLKDEV
@@ -326,6 +356,7 @@
BOOTENV_SHARED_IDE \
BOOTENV_SHARED_UBIFS \
BOOTENV_SHARED_EFI \
+   BOOTENV_SHARED_FREEBSD \
"boot_prefixes=/ /boot/\0" \
"boot_scripts=boot.scr.uimg boot.scr\0" \
"boot_script_dhcp=boot.scr.uimg\0" \
@@ -369,6 +400,7 @@
"run scan_dev_for_scripts; "  \
"done;"   \
SCAN_DEV_FOR_EFI  \
+   SCAN_DEV_FOR_FREEBSD  \
"\0"  \
\
"scan_dev_for_boot_part=" \
-- 
2.9.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4] config: Add FreeBSD kconfig options

[Emmanuel Vadot]

This series of patches add the needed bits for booting the FreeBSD
loader.
FreeBSD loader needs the U-Boot API and dache disabled for it to run so
add kconfig options for them.
Also add some some boot command that locate and run the FreeBSD loader
if found.

Emmanuel Vadot (4):
  kconfig: Add API kconfig file
  kconfig: arm: Add SYS_DCACHE_OFF option
  kconfig: Add a FREEBSD option
  distro_bootcmd: Add command to run FreeBSD

 Kconfig |  2 ++
 api/Kconfig |  9 +
 arch/arm/Kconfig|  6 ++
 common/Kconfig  |  9 +
 include/config_distro_bootcmd.h | 32 
 5 files changed, 58 insertions(+)
 create mode 100644 api/Kconfig

-- 
2.9.2

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot