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

[Stephen Warren]

On 11/08/2016 10:47 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:

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

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.

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


This looks fine for the ARMv7 and ARMv8 Pis, but I forgot to mention 
last time that it causes a build failure for the ARMv6-based original Pis:



board/raspberrypi/rpi/built-in.o: In function `save_boot_params':
board/raspberrypi/rpi/lowlevel_init.S:36: undefined reference to 
`save_boot_params_ret'


That's because arch/arm/cpu/arm1176/start.S doesn't implement the 
save_boot_params hook; you can probably solve this quite easily by 
taking commit 0e2b5350d952 "ARM: Add save_boot_params for ARMv8" and 
porting that to the ARM1176 code first.


Assuming that fix is sent and applied first e.g. in a series with this 
patch, then this patch,

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] mx6ull_14x14_evk: Add README file

[Peng Fan]

Hi Diego,

> -Original Message-
> From: Diego Dorta [mailto:diego.do...@nxp.com]
> Sent: Friday, November 11, 2016 1:06 AM
> To: sba...@denx.de; Peng Fan ; u-boot@lists.denx.de
> Cc: Diego Dorta 
> Subject: [PATCH] mx6ull_14x14_evk: Add README file
> 
> Add a README file to help users getting started with the board.
> 
> Signed-off-by: Diego Dorta 

Reviewed-by: Peng Fan 

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

[U-Boot] [PATCH] SPI: add support for the EON EN25Q80B flash chip

[Angus Ainslie]

add a new jedec id for the EN25Q80B
---
 drivers/mtd/spi/sf_params.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 5b50114..df15b3d 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -27,6 +27,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"AT26DF081A", 0x1f4501, 0x0,   64 * 1024,16, SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_EON/* EON */
+   {"EN25Q80B",   0x1c3014, 0x1c30,64 * 1024,16, 0},
{"EN25Q32B",   0x1c3016, 0x0,   64 * 1024,64, 0},
{"EN25Q64",0x1c3017, 0x0,   64 * 1024,   128, SECT_4K},
{"EN25Q128B",  0x1c3018, 0x0,   64 * 1024,   256, 0},
-- 
2.7.4

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

[U-Boot] [PATCH] imx7: SPI: add suport for SPI flash in mikroBUS slot

[Angus Ainslie]

Enable the escpi3 nets attached to the mikroBUS slot
on the i.MX7 Sabre evalution board. Also enble the SPI flash
commands to work with the "flash click" board.

This is V2 of this patch with changes recommended by the maintainer

CC: Jagan Teki 
---
 board/freescale/mx7dsabresd/mx7dsabresd.c | 24 
 configs/mx7dsabresd_secure_defconfig  |  3 +++
 include/configs/mx7dsabresd.h |  3 +++
 3 files changed, 30 insertions(+)

diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index b936544..6ccdd4b 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -50,6 +50,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define NAND_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_SLOW | PAD_CTL_HYS)
 
+#define SPI_PAD_CTRL \
+  (PAD_CTL_HYS | PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_FAST)
+
 #define NAND_PAD_READY0_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU5KOHM)
 #ifdef CONFIG_SYS_I2C_MXC
 #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
@@ -68,6 +71,23 @@ static struct i2c_pads_info i2c_pad_info1 = {
 };
 #endif
 
+static iomux_v3_cfg_t const ecspi3_pads[] = {
+MX7D_PAD_SAI2_RX_DATA__ECSPI3_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_SYNC__ECSPI3_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_BCLK__ECSPI3_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_DATA__GPIO6_IO22 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+int board_spi_cs_gpio(unsigned bus, unsigned cs)
+{
+ return (bus == 2 && cs == 0) ? (IMX_GPIO_NR(6, 22)) : -1;
+}
+
+static void setup_spi(void)
+{
+ imx_iomux_v3_setup_multiple_pads(ecspi3_pads, 
ARRAY_SIZE(ecspi3_pads));
+}
+
 int dram_init(void)
 {
gd->ram_size = PHYS_SDRAM_SIZE;
@@ -553,6 +573,10 @@ int board_init(void)
board_qspi_init();
 #endif
 
+#ifdef CONFIG_MXC_SPI
+   setup_spi();
+#endif
+
return 0;
 }
 
diff --git a/configs/mx7dsabresd_secure_defconfig 
b/configs/mx7dsabresd_secure_defconfig
index 126ce31..ef93522 100644
--- a/configs/mx7dsabresd_secure_defconfig
+++ b/configs/mx7dsabresd_secure_defconfig
@@ -45,3 +45,6 @@ CONFIG_G_DNL_MANUFACTURER="FSL"
 CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_OF_LIBFDT=y
+CONFIG_SPI_FLASH=y
+CONFIG_CMD_SF=y
+CONFIG_SPI_FLASH_EON=y
diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
index 360a5e0..7f468b2 100644
--- a/include/configs/mx7dsabresd.h
+++ b/include/configs/mx7dsabresd.h
@@ -201,6 +201,9 @@
 #define CONFIG_ENV_SIZESZ_8K
 #define CONFIG_ENV_IS_IN_MMC
 
+/* SPI flash support */
+#define CONFIG_MXC_SPI
+
 /*
  * If want to use nand, define CONFIG_NAND_MXS and rework board
  * to support nand, since emmc has pin conflicts with nand
-- 
2.7.4

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

Re: [U-Boot] [PATCH] arm: sunxi: do not force USB for arch-sunxi

[Yann E. MORIN]

Hans, All,

On 2016-11-10 20:10 +0100, Hans de Goede spake thusly:
> On 10-11-16 19:00, Yann E. MORIN wrote:
> >Ian, Hans, All,
> >
> >On 2016-10-31 22:33 +0100, Yann E. MORIN spake thusly:
> >>Currently, USB is forced-enabled for the sunxi familly, and there is no
> >>way to disable it.
> >>
> >>However, USB takes a long time to initiliase, delaying the boot by up to
> >>5 seconds (without any USB device attached!). This is a very long delay,
> >>especially in cases where USB booting is not wanted at all, and where
> >>the device is expected to boot relatively often (even in production).
> >>
> >>Change the way the dependencies are handled, by only forcibly selecting
> >>USB when CONFIG_DISTRO_DEFAULTS ("defaults suitable for booting general
> >>purpose Linux distributions") is set. This option defaults to y for the
> >>sunxi familly, so the current default behaviour is kept unchanged. Users
> >>interested in boot time and/or size will be able to disable this to
> >>further disable USB.
> >>
> >>With USB disabled, the time spent in U-Boot before handing control to
> >>the Linux kernel is about 1s now, down from ~5s (Nanopi Neo, sunxi H3).
> >
> >Just a gentle ping... ;-)
> 
> 10 days is a bit short in between ping times for a volunteer maintained
> subsys :)

Sorry, I'm just new on the U-Boot list, so I'm not sure what the usual
round-trip is. ;-)

> Anyways I've this on my todo and hopefully will get around
> to it soonish.

Thanks! You'll get a beer next time we meet for ELC-E.

(What? Bribery does not help? Ohh.. ;-) )

Regards,
Yann E. MORIN.

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN |  ___   |
| +33 223 225 172 `.---:  X  AGAINST  |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|   v   conspiracy.  |
'--^---^--^'
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] Makefile: preserve output for images that can contain HAB Blocks

[George McCollister]

On Sun, Nov 6, 2016 at 9:37 AM, Sven Ebenfeld  wrote:
> To being able to sign created binaries, we need to know the HAB Blocks
> for that image. Especially for the imximage type the HAB Blocks are
> only available during creation of the image. We want to preserve the
> information until we get to sign the files.
> In the verbose case we still get them printed out instead of writing
> to log files.
>
> Cc: sba...@denx.de
>
> v2-Changes:
>  - No usage of MKIMAGEOUTPUT_$(@F) macro.
>  - Predefine default value /dev/null in every involved Makefile.
>
> Signed-off-by: Sven Ebenfeld 
> ---
>  .gitignore   | 2 +-
>  Makefile | 6 +-
>  arch/arm/imx-common/Makefile | 4 
>  doc/README.imx6  | 3 ++-
>  scripts/Makefile.lib | 3 ++-
>  scripts/Makefile.spl | 4 +++-
>  6 files changed, 17 insertions(+), 5 deletions(-)
>

Reviewed-by: George McCollister 
Tested-by: George McCollister 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/5] doc: imx6: add section for secure boot with SPL

[George McCollister]

On Sun, Nov 6, 2016 at 9:37 AM, Sven Ebenfeld  wrote:
> Cc: sba...@denx.de
>
> Signed-off-by: Sven Ebenfeld 
> ---
>  doc/README.imx6 | 48 
>  1 file changed, 48 insertions(+)
>

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

Re: [U-Boot] [PATCH v2 3/5] tools: mkimage: add firmware-ivt image type for HAB verification

[George McCollister]

On Sun, Nov 6, 2016 at 9:37 AM, Sven Ebenfeld  wrote:
> When we want to use Secure Boot with HAB from SPL over U-Boot.img,
> we need to append the IVT to the image and leave space for the CSF.
> Images generated as firmware_ivt can directly be signed using the
> Freescale code signing tool. For creation of a CSF, mkimage outputs
> the correct HAB Blocks for the image.
> The changes to the usual firmware image class are quite small,
> that is why I implemented that directly into the default_image.
>
> Cc: sba...@denx.de
>
> v2-Changes: None
>
> Signed-off-by: Sven Ebenfeld 
> ---
>  Makefile  |  9 -
>  common/image.c|  6 ++
>  include/image.h   |  1 +
>  tools/default_image.c | 10 --
>  tools/mkimage.c   | 32 
>  5 files changed, 55 insertions(+), 3 deletions(-)
>

Reviewed-by: George McCollister 
Tested-by: George McCollister 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/5] arm: imx: add HAB authentication of image to SPL boot

[George McCollister]

On Sun, Nov 6, 2016 at 9:37 AM, Sven Ebenfeld  wrote:
> When using HAB as secure boot mechanism on Wandboard, the chain of
> trust breaks immediately after the SPL. As this is not checking
> the authenticity of the loaded image before jumping to it.
>
> The HAB status output will not be implemented in SPL as it adds
> a lot of strings that are only required in debug cases. With those
> it exceeds the maximum size of the available OCRAM (69 KiB).
>
> The SPL MISC driver support must be enabled, so that the driver can use OTP 
> fuse
> to check if HAB is enabled.
>
> Cc: sba...@denx.de
>
> v2-Changes: None
>
> Signed-off-by: Sven Ebenfeld 
> ---
>  arch/arm/imx-common/hab.c | 129 
> ++
>  arch/arm/imx-common/spl.c |  25 +++
>  arch/arm/imx-common/spl_sd.cfg|  10 +++
>  arch/arm/include/asm/imx-common/hab.h |   2 +
>  include/configs/mx6_common.h  |   3 +
>  5 files changed, 110 insertions(+), 59 deletions(-)
>

Reviewed-by: George McCollister 
Tested-by: George McCollister 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] arm: imx: remove bmode , hdmidet and dek commands from SPL

[George McCollister]

On Sun, Nov 6, 2016 at 9:37 AM, Sven Ebenfeld  wrote:
> These files are blowing up the SPL and should not be required
> there as the SPL delivers no command console. Because building fails
> for mx27 and mx31 machines with SPL build, we remove the linker flag
> for them from the Makefile. Nothing is built for them to be linked
> in that directory.
>
> Cc: sba...@denx.de
>
> v2 Changes:
>  - Remove mx27 and mx31 from Makefile during SPL build as nothing is built for
>them in that directory. And removing the commands with the libs-y directive
>lead to linker failures. e.g. "armv5te-ld.bfd: cannot find 
> arch/arm/imx-common/built-in.o: No such file or directory)"
>
> Signed-off-by: Sven Ebenfeld 
> ---
>  arch/arm/Makefile| 2 +-
>  arch/arm/imx-common/Makefile | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
>

Reviewed-by: George McCollister 
Tested-by: George McCollister 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] davinci: omapl138_lcdk: keep booting even when MAC address is invalid

[Tom Rini]

On Thu, Nov 10, 2016 at 05:16:35PM +0100, Fabien Parent wrote:

> If the MAC address specified on the EEPROM is invalid (multicast or
> zero address), then u-boot fails to boot. Having a bad MAC address
> in the EEPROM should not prevent the system from booting.
> 
> This commit changes the error path to just print an error messages
> in case of bad MAC address.
> 
> Signed-off-by: Fabien Parent 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] arm: sunxi: do not force USB for arch-sunxi

[Hans de Goede]

Hi,

On 10-11-16 19:00, Yann E. MORIN wrote:

Ian, Hans, All,

On 2016-10-31 22:33 +0100, Yann E. MORIN spake thusly:

Currently, USB is forced-enabled for the sunxi familly, and there is no
way to disable it.

However, USB takes a long time to initiliase, delaying the boot by up to
5 seconds (without any USB device attached!). This is a very long delay,
especially in cases where USB booting is not wanted at all, and where
the device is expected to boot relatively often (even in production).

Change the way the dependencies are handled, by only forcibly selecting
USB when CONFIG_DISTRO_DEFAULTS ("defaults suitable for booting general
purpose Linux distributions") is set. This option defaults to y for the
sunxi familly, so the current default behaviour is kept unchanged. Users
interested in boot time and/or size will be able to disable this to
further disable USB.

With USB disabled, the time spent in U-Boot before handing control to
the Linux kernel is about 1s now, down from ~5s (Nanopi Neo, sunxi H3).


Just a gentle ping... ;-)


10 days is a bit short in between ping times for a volunteer maintained
subsys :)  Anyways I've this on my todo and hopefully will get around
to it soonish.

Regards,

Hans






Regards,
Yann E. MORIN.


Signed-off-by: "Yann E. MORIN" 
Cc: Ian Campbell 
Cc: Hans De Goede 

---
This is a tentative patch, acting as an RFC (unless it is good to go as
is, of course!).

This has been discussed on IRC with  and , and this
solution is what emerged from the discussions as a first step.

The second step would be to defer intialisation of drivers until they
are actually needed, i.e. if main boot is not from USB, then don't
initiliase USB; if main boot fails, then initialise addtional drivers,
like USB... Or something along those lines... That's a much tougher
work for me, though...

There are other features that are currently forced like USB, but USB
is by far the worst "offender" and a low-hanging fruit. Those other
"offenders" can be handled in follow up changes.
---
 arch/arm/Kconfig | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..c13f60f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -561,22 +561,22 @@ config ARCH_SUNXI
bool "Support sunxi (Allwinner) SoCs"
select CMD_GPIO
select CMD_MMC if MMC
-   select CMD_USB
+   select CMD_USB if DISTRO_DEFAULTS
select DM
select DM_ETH
select DM_GPIO
select DM_KEYBOARD
select DM_SERIAL
-   select DM_USB
+   select DM_USB if DISTRO_DEFAULTS
select OF_BOARD_SETUP
select OF_CONTROL
select OF_SEPARATE
select SPL_STACK_R if SUPPORT_SPL
select SPL_SYS_MALLOC_SIMPLE if SUPPORT_SPL
select SYS_NS16550
-   select USB
-   select USB_STORAGE
-   select USB_KEYBOARD
+   select USB if DISTRO_DEFAULTS
+   select USB_STORAGE if DISTRO_DEFAULTS
+   select USB_KEYBOARD if DISTRO_DEFAULTS
select USE_TINY_PRINTF

 config TARGET_TS4800
--
2.7.4




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

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

[york sun]

On 11/08/2016 02:55 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.
>
> Signed-off-by: Shengzhou Liu 
> ---
> v2: fix a typo
> v3: add reading POR value of debug_29 before changing.
>
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c   |   7 +-
>  arch/powerpc/cpu/mpc85xx/cpu_init.c   |   6 +-
>  arch/powerpc/include/asm/config_mpc85xx.h |   2 -
>  board/freescale/ls1021aqds/ls1021aqds.c   |   6 +-
>  drivers/ddr/fsl/ctrl_regs.c   | 134 
> +-
>  drivers/ddr/fsl/fsl_ddr_gen4.c|  23 -
>  drivers/ddr/fsl/mpc85xx_ddr_gen3.c|   3 -
>  include/fsl_ddr.h |   2 +
>  include/fsl_ddr_sdram.h   |   3 +-
>  9 files changed, 151 insertions(+), 35 deletions(-)
>


Shengzhou,

This patch causes compiling error for qemu-ppce500, and warnings for 
multiple T series platforms (eg T1040RDB).

I noticed you have later patch fixing compiling warning. Please reorder 
your patch to make git bisect happy.

York

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

Re: [U-Boot] [PATCH] arm: sunxi: do not force USB for arch-sunxi

[Yann E. MORIN]

Ian, Hans, All,

On 2016-10-31 22:33 +0100, Yann E. MORIN spake thusly:
> Currently, USB is forced-enabled for the sunxi familly, and there is no
> way to disable it.
> 
> However, USB takes a long time to initiliase, delaying the boot by up to
> 5 seconds (without any USB device attached!). This is a very long delay,
> especially in cases where USB booting is not wanted at all, and where
> the device is expected to boot relatively often (even in production).
> 
> Change the way the dependencies are handled, by only forcibly selecting
> USB when CONFIG_DISTRO_DEFAULTS ("defaults suitable for booting general
> purpose Linux distributions") is set. This option defaults to y for the
> sunxi familly, so the current default behaviour is kept unchanged. Users
> interested in boot time and/or size will be able to disable this to
> further disable USB.
> 
> With USB disabled, the time spent in U-Boot before handing control to
> the Linux kernel is about 1s now, down from ~5s (Nanopi Neo, sunxi H3).

Just a gentle ping... ;-)

Regards,
Yann E. MORIN.

> Signed-off-by: "Yann E. MORIN" 
> Cc: Ian Campbell 
> Cc: Hans De Goede 
> 
> ---
> This is a tentative patch, acting as an RFC (unless it is good to go as
> is, of course!).
> 
> This has been discussed on IRC with  and , and this
> solution is what emerged from the discussions as a first step.
> 
> The second step would be to defer intialisation of drivers until they
> are actually needed, i.e. if main boot is not from USB, then don't
> initiliase USB; if main boot fails, then initialise addtional drivers,
> like USB... Or something along those lines... That's a much tougher
> work for me, though...
> 
> There are other features that are currently forced like USB, but USB
> is by far the worst "offender" and a low-hanging fruit. Those other
> "offenders" can be handled in follow up changes.
> ---
>  arch/arm/Kconfig | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d7a9b11..c13f60f 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -561,22 +561,22 @@ config ARCH_SUNXI
>   bool "Support sunxi (Allwinner) SoCs"
>   select CMD_GPIO
>   select CMD_MMC if MMC
> - select CMD_USB
> + select CMD_USB if DISTRO_DEFAULTS
>   select DM
>   select DM_ETH
>   select DM_GPIO
>   select DM_KEYBOARD
>   select DM_SERIAL
> - select DM_USB
> + select DM_USB if DISTRO_DEFAULTS
>   select OF_BOARD_SETUP
>   select OF_CONTROL
>   select OF_SEPARATE
>   select SPL_STACK_R if SUPPORT_SPL
>   select SPL_SYS_MALLOC_SIMPLE if SUPPORT_SPL
>   select SYS_NS16550
> - select USB
> - select USB_STORAGE
> - select USB_KEYBOARD
> + select USB if DISTRO_DEFAULTS
> + select USB_STORAGE if DISTRO_DEFAULTS
> + select USB_KEYBOARD if DISTRO_DEFAULTS
>   select USE_TINY_PRINTF
>  
>  config TARGET_TS4800
> -- 
> 2.7.4
> 

-- 
.-..--..
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN |  ___   |
| +33 223 225 172 `.---:  X  AGAINST  |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL|   v   conspiracy.  |
'--^---^--^'
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mx6ull_14x14_evk: Add README file

[Fabio Estevam]

On Thu, Nov 10, 2016 at 3:05 PM, Diego Dorta  wrote:
> Add a README file to help users getting started with the board.
>
> Signed-off-by: Diego Dorta 

Looks good:

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

[U-Boot] [PATCH] davinci: omapl138_lcdk: keep booting even when MAC address is invalid

[Fabien Parent]

If the MAC address specified on the EEPROM is invalid (multicast or
zero address), then u-boot fails to boot. Having a bad MAC address
in the EEPROM should not prevent the system from booting.

This commit changes the error path to just print an error messages
in case of bad MAC address.

Signed-off-by: Fabien Parent 
---
 board/davinci/da8xxevm/omapl138_lcdk.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
b/board/davinci/da8xxevm/omapl138_lcdk.c
index 9783b2a..9c1a483 100644
--- a/board/davinci/da8xxevm/omapl138_lcdk.c
+++ b/board/davinci/da8xxevm/omapl138_lcdk.c
@@ -333,15 +333,17 @@ int misc_init_r(void)
get_mac_addr(addr);
}
 
-   if (is_multicast_ethaddr(addr) || is_zero_ethaddr(addr)) {
+   if (!is_multicast_ethaddr(addr) && !is_zero_ethaddr(addr)) {
+   sprintf((char *)tmp, "%02x:%02x:%02x:%02x:%02x:%02x",
+   addr[0], addr[1], addr[2], addr[3], addr[4],
+   addr[5]);
+
+   setenv("ethaddr", (char *)tmp);
+   } else {
printf("Invalid MAC address read.\n");
-   return -EINVAL;
}
-   sprintf((char *)tmp, "%02x:%02x:%02x:%02x:%02x:%02x", addr[0],
-   addr[1], addr[2], addr[3], addr[4], addr[5]);
-
-   setenv("ethaddr", (char *)tmp);
}
+
 #ifdef CONFIG_DRIVER_TI_EMAC_USE_RMII
/* Select RMII fucntion through the expander */
if (rmii_hw_init())
-- 
2.10.2

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

[U-Boot] [PATCH] serial: ns16550: Fix Debug UART initialization for AM335x

[Jacob Siverskog]

Fixed the init sequence in debug_uart_init() to match the one in
NS16550_init(). Without this I was unable to get debug UART working on
AM335x. Based on a patch by Vasili Galka.

Signed-off-by: Jacob Siverskog 
---
 drivers/serial/ns16550.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 6e9b946..40fe246 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -262,6 +262,11 @@ static inline void _debug_uart_init(void)
baud_divisor = ns16550_calc_divisor(com_port, CONFIG_DEBUG_UART_CLOCK,
CONFIG_BAUDRATE);
serial_dout(_port->ier, CONFIG_SYS_NS16550_IER);
+#if defined(CONFIG_OMAP) || defined(CONFIG_AM33XX) || \
+   defined(CONFIG_TI81XX) || defined(CONFIG_AM43XX)
+   serial_dout(_port->mdr1, 0x7);  /* mode select reset TL16C750*/
+#endif
+
serial_dout(_port->mcr, UART_MCRVAL);
serial_dout(_port->fcr, UART_FCRVAL);
 
@@ -269,6 +274,14 @@ static inline void _debug_uart_init(void)
serial_dout(_port->dll, baud_divisor & 0xff);
serial_dout(_port->dlm, (baud_divisor >> 8) & 0xff);
serial_dout(_port->lcr, UART_LCRVAL);
+
+#if defined(CONFIG_OMAP) || \
+   defined(CONFIG_AM33XX) || defined(CONFIG_SOC_DA8XX) || \
+   defined(CONFIG_TI81XX) || defined(CONFIG_AM43XX)
+
+   /* /16 is proper to hit 115200 with 48MHz */
+   serial_dout(_port->mdr1, 0);
+#endif /* CONFIG_OMAP */
 }
 
 static inline void _debug_uart_putc(int ch)
-- 
2.10.2

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

[U-Boot] Encryption of FIT image

[Zvi Vered]

Hello,

Can you tell if this is possible ? How ?

Thank you,
Zvika Vered
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH 1/3] net: phy: realtek: Use the BIT() macro

[Priit Laes]

On Tue, 2016-11-08 at 17:38 +0100, Olliver Schinagl wrote:
> The BIT macro is the preferred method to set bits.
> This patch adds the bit macro and converts bit invocations.
> 
> Signed-off-by: Olliver Schinagl 
> ---
>  drivers/net/phy/realtek.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c
> index 7a99cb0..35b934b 100644
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -9,13 +9,14 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #define PHY_AUTONEGOTIATE_TIMEOUT 5000
>  
>  /* RTL8211x 1000BASE-T Control Register */
> -#define MIIM_RTL8211x_CTRL1000T_MSCE (1 << 12);
> -#define MIIM_RTL8211X_CTRL1000T_MASTER (1 << 11);
> +#define MIIM_RTL8211x_CTRL1000T_MSCE BIT(12);
> +#define MIIM_RTL8211X_CTRL1000T_MASTER BIT(11);

You should also get rid of semicolons.


>  
>  /* RTL8211x PHY Status Register */
>  #define MIIM_RTL8211x_PHY_STATUS   0x11
> -- 
> 2.10.2
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx6ull_14x14_evk: Add README file

[Diego Dorta]

Add a README file to help users getting started with the board.

Signed-off-by: Diego Dorta 
---
 board/freescale/mx6ullevk/README | 36 
 1 file changed, 36 insertions(+)
 create mode 100644 board/freescale/mx6ullevk/README

diff --git a/board/freescale/mx6ullevk/README b/board/freescale/mx6ullevk/README
new file mode 100644
index 000..d5c8770
--- /dev/null
+++ b/board/freescale/mx6ullevk/README
@@ -0,0 +1,36 @@
+How to use U-Boot on Freescale MX6ULL 14x14 EVK
+--
+
+- First make sure you have installed the dtc package (device tree compiler):
+
+$ sudo apt-get install device-tree-compiler
+
+- Build U-Boot for MX6ULL 14x14 EVK:
+
+$ make mrproper
+$ make mx6ull_14x14_evk_defconfig
+$ make
+
+This generates the u-boot-dtb.imx image in the current directory.
+
+- Flash the u-boot-dtb.imx image into the micro SD card:
+
+$ sudo dd if=u-boot-dtb.imx of=/dev/sdb bs=1K seek=1 && sync
+
+- Jumper settings:
+
+SW601: 0 0 1 0
+Sw602: 1 0
+
+Where 0 means bottom position and 1 means top position (from the switch label
+numbers reference).
+
+Connect the USB cable between the EVK and the PC for the console.
+(The USB console connector is the one close the push buttons)
+
+Insert the micro SD card in the board, power it up and U-Boot messages should
+come up.
+
+The link for the board: http://www.nxp.com/products/microcontrollers-and- \
+processors/arm-processors/i.mx-applications-processors/i.mx-6-processors/ \
+i.mx6qp/evaluation-kit-for-the-i.mx-6ull-applications-processor:MCIMX6ULL-EVK
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/2] imx7: SPI: add suport for SPI flash in mikroBUS slot

[Jagan Teki]

On Thu, Nov 10, 2016 at 9:34 PM, Angus Ainslie  wrote:
> Enable the escpi3 nets attached to the mikroBUS slot
> on the i.MX7 Sabre evalution board. Also enble the SPI flash
> commands to work with the "flash click" board.
> ---
>  board/freescale/mx7dsabresd/mx7dsabresd.c | 24 
>  configs/mx7dsabresd_secure_defconfig  |  2 ++
>  include/configs/mx7dsabresd.h |  4 
>  3 files changed, 30 insertions(+)
>
> CC: Stefano Babic 
> CC: Jagan Teki 
> diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
> b/board/freescale/mx7dsabresd/mx7dsabresd.c
> index b936544..6ccdd4b 100644
> --- a/board/freescale/mx7dsabresd/mx7dsabresd.c
> +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
> @@ -50,6 +50,9 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  #define NAND_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_SLOW | 
> PAD_CTL_HYS)
>
> +#define SPI_PAD_CTRL \
> +  (PAD_CTL_HYS | PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_FAST)
> +
>  #define NAND_PAD_READY0_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU5KOHM)
>  #ifdef CONFIG_SYS_I2C_MXC
>  #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
> @@ -68,6 +71,23 @@ static struct i2c_pads_info i2c_pad_info1 = {
>  };
>  #endif
>
> +static iomux_v3_cfg_t const ecspi3_pads[] = {
> +MX7D_PAD_SAI2_RX_DATA__ECSPI3_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
> +MX7D_PAD_SAI2_TX_SYNC__ECSPI3_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
> +MX7D_PAD_SAI2_TX_BCLK__ECSPI3_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
> +MX7D_PAD_SAI2_TX_DATA__GPIO6_IO22 | MUX_PAD_CTRL(NO_PAD_CTRL),
> +};
> +
> +int board_spi_cs_gpio(unsigned bus, unsigned cs)
> +{
> + return (bus == 2 && cs == 0) ? (IMX_GPIO_NR(6, 22)) : -1;
> +}
> +
> +static void setup_spi(void)
> +{
> + imx_iomux_v3_setup_multiple_pads(ecspi3_pads, 
> ARRAY_SIZE(ecspi3_pads));
> +}
> +
>  int dram_init(void)
>  {
> gd->ram_size = PHYS_SDRAM_SIZE;
> @@ -553,6 +573,10 @@ int board_init(void)
> board_qspi_init();
>  #endif
>
> +#ifdef CONFIG_MXC_SPI
> +   setup_spi();
> +#endif
> +
> return 0;
>  }
>
> diff --git a/configs/mx7dsabresd_secure_defconfig 
> b/configs/mx7dsabresd_secure_defconfig
> index 126ce31..c16ba97 100644
> --- a/configs/mx7dsabresd_secure_defconfig
> +++ b/configs/mx7dsabresd_secure_defconfig
> @@ -45,3 +45,5 @@ CONFIG_G_DNL_MANUFACTURER="FSL"
>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>  CONFIG_OF_LIBFDT=y
> +CONFIG_SPI_FLASH=y
> +CONFIG_SPI_FLASH_EON=y
> diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
> index 360a5e0..5609bbe 100644
> --- a/include/configs/mx7dsabresd.h
> +++ b/include/configs/mx7dsabresd.h
> @@ -201,6 +201,10 @@
>  #define CONFIG_ENV_SIZESZ_8K
>  #define CONFIG_ENV_IS_IN_MMC
>
> +/* SPI flash support */
> +#define CONFIG_CMD_SF

Move this to defconfig.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] SPI: add support for the EON EN25Q80B flash

[Angus Ainslie]

jedec id for the 8Mb EN25Q80B flash
---
 drivers/mtd/spi/sf_params.c | 1 +
 1 file changed, 1 insertion(+)

CC: Stefano Babic 
CC: Jagan Teki 
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 5b50114..df15b3d 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -27,6 +27,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"AT26DF081A", 0x1f4501, 0x0,   64 * 1024,16, SECT_4K},
 #endif
 #ifdef CONFIG_SPI_FLASH_EON/* EON */
+   {"EN25Q80B",   0x1c3014, 0x1c30,64 * 1024,16, 0},
{"EN25Q32B",   0x1c3016, 0x0,   64 * 1024,64, 0},
{"EN25Q64",0x1c3017, 0x0,   64 * 1024,   128, SECT_4K},
{"EN25Q128B",  0x1c3018, 0x0,   64 * 1024,   256, 0},
-- 
2.7.4

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

[U-Boot] Add mikroBUS flash click support to the imx7

[Angus Ainslie]

In-Reply-To: 


Add support for the "flash click" and probably other SPI mikroBUS click
boards on i.MX7 Sabre evaluation board.

 board/freescale/mx7dsabresd/mx7dsabresd.c |   24 
 configs/mx7dsabresd_secure_defconfig  |2 ++
 drivers/mtd/spi/sf_params.c   |1 +
 include/configs/mx7dsabresd.h |4 
 4 files changed, 31 insertions(+)


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

[U-Boot] [PATCH 1/2] imx7: SPI: add suport for SPI flash in mikroBUS slot

[Angus Ainslie]

Enable the escpi3 nets attached to the mikroBUS slot
on the i.MX7 Sabre evalution board. Also enble the SPI flash
commands to work with the "flash click" board.
---
 board/freescale/mx7dsabresd/mx7dsabresd.c | 24 
 configs/mx7dsabresd_secure_defconfig  |  2 ++
 include/configs/mx7dsabresd.h |  4 
 3 files changed, 30 insertions(+)

CC: Stefano Babic 
CC: Jagan Teki 
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index b936544..6ccdd4b 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -50,6 +50,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define NAND_PAD_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_SLOW | PAD_CTL_HYS)
 
+#define SPI_PAD_CTRL \
+  (PAD_CTL_HYS | PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_SRE_FAST)
+
 #define NAND_PAD_READY0_CTRL (PAD_CTL_DSE_3P3V_49OHM | PAD_CTL_PUS_PU5KOHM)
 #ifdef CONFIG_SYS_I2C_MXC
 #define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
@@ -68,6 +71,23 @@ static struct i2c_pads_info i2c_pad_info1 = {
 };
 #endif
 
+static iomux_v3_cfg_t const ecspi3_pads[] = {
+MX7D_PAD_SAI2_RX_DATA__ECSPI3_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_SYNC__ECSPI3_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_BCLK__ECSPI3_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL),
+MX7D_PAD_SAI2_TX_DATA__GPIO6_IO22 | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+int board_spi_cs_gpio(unsigned bus, unsigned cs)
+{
+ return (bus == 2 && cs == 0) ? (IMX_GPIO_NR(6, 22)) : -1;
+}
+
+static void setup_spi(void)
+{
+ imx_iomux_v3_setup_multiple_pads(ecspi3_pads, 
ARRAY_SIZE(ecspi3_pads));
+}
+
 int dram_init(void)
 {
gd->ram_size = PHYS_SDRAM_SIZE;
@@ -553,6 +573,10 @@ int board_init(void)
board_qspi_init();
 #endif
 
+#ifdef CONFIG_MXC_SPI
+   setup_spi();
+#endif
+
return 0;
 }
 
diff --git a/configs/mx7dsabresd_secure_defconfig 
b/configs/mx7dsabresd_secure_defconfig
index 126ce31..c16ba97 100644
--- a/configs/mx7dsabresd_secure_defconfig
+++ b/configs/mx7dsabresd_secure_defconfig
@@ -45,3 +45,5 @@ CONFIG_G_DNL_MANUFACTURER="FSL"
 CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_OF_LIBFDT=y
+CONFIG_SPI_FLASH=y
+CONFIG_SPI_FLASH_EON=y
diff --git a/include/configs/mx7dsabresd.h b/include/configs/mx7dsabresd.h
index 360a5e0..5609bbe 100644
--- a/include/configs/mx7dsabresd.h
+++ b/include/configs/mx7dsabresd.h
@@ -201,6 +201,10 @@
 #define CONFIG_ENV_SIZESZ_8K
 #define CONFIG_ENV_IS_IN_MMC
 
+/* SPI flash support */
+#define CONFIG_CMD_SF
+#define CONFIG_MXC_SPI
+
 /*
  * If want to use nand, define CONFIG_NAND_MXS and rework board
  * to support nand, since emmc has pin conflicts with nand
-- 
2.7.4

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

Re: [U-Boot] [PATCH RESEND 4/9] w1: Add 1-Wire gpio driver

[Michal Simek]

On 8.11.2016 11:19, Maxime Ripard wrote:
> Add a bus driver for bitbanging a 1-Wire bus over a GPIO.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/w1/Kconfig   |   6 ++-
>  drivers/w1/Makefile  |   1 +-
>  drivers/w1/w1-gpio.c | 160 -
>  3 files changed, 167 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/w1/w1-gpio.c
> 
> diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
> index 0c056b4c06a9..ccc3ae15db86 100644
> --- a/drivers/w1/Kconfig
> +++ b/drivers/w1/Kconfig
> @@ -12,6 +12,12 @@ config W1
>  
>  if W1
>  
> +config W1_GPIO
> + bool "Enable 1-Wire GPIO bitbanging"
> + depends on DM_GPIO
> + help
> +   Emulate a 1-Wire bus using a GPIO.
> +
>  endif
>  
>  endmenu
> diff --git a/drivers/w1/Makefile b/drivers/w1/Makefile
> index 26820fa209e1..7fd8697f8419 100644
> --- a/drivers/w1/Makefile
> +++ b/drivers/w1/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_W1) += w1-uclass.o
>  
> +obj-$(CONFIG_W1_GPIO) += w1-gpio.o
> diff --git a/drivers/w1/w1-gpio.c b/drivers/w1/w1-gpio.c
> new file mode 100644
> index ..091849162533
> --- /dev/null
> +++ b/drivers/w1/w1-gpio.c
> @@ -0,0 +1,160 @@
> +/*
> + * Copyright (c) 2015 Free Electrons
> + * Copyright (c) 2015 NextThing Co
> + *
> + * Maxime Ripard 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +
> +#define W1_TIMING_A  6
> +#define W1_TIMING_B  64
> +#define W1_TIMING_C  60
> +#define W1_TIMING_D  10
> +#define W1_TIMING_E  9
> +#define W1_TIMING_F  55
> +#define W1_TIMING_G  0
> +#define W1_TIMING_H  480
> +#define W1_TIMING_I  70
> +#define W1_TIMING_J  410
> +
> +struct w1_gpio_pdata {
> + struct gpio_descgpio;
> + u64 search_id;
> +};
> +
> +static bool w1_gpio_read_bit(struct udevice *dev)
> +{
> + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> + int val;
> +
> + dm_gpio_set_dir_flags(>gpio, GPIOD_IS_OUT);
> + udelay(W1_TIMING_A);
> +
> + dm_gpio_set_dir_flags(>gpio, GPIOD_IS_IN);
> + udelay(W1_TIMING_E);
> +
> + val = dm_gpio_get_value(>gpio);
> + udelay(W1_TIMING_F);
> +
> + return val;
> +}
> +
> +static u8 w1_gpio_read_byte(struct udevice *dev)
> +{
> + int i;
> + u8 ret = 0;
> +
> + for (i = 0; i < 8; ++i)
> + ret |= (w1_gpio_read_bit(dev) ? 1 : 0) << i;
> +
> + return ret;
> +}
> +
> +static void w1_gpio_write_bit(struct udevice *dev, bool bit)
> +{
> + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> +
> + dm_gpio_set_dir_flags(>gpio, GPIOD_IS_OUT);
> +
> + bit ? udelay(W1_TIMING_A) : udelay(W1_TIMING_C);
> +
> + dm_gpio_set_value(>gpio, 1);
> +
> + bit ? udelay(W1_TIMING_B) : udelay(W1_TIMING_D);
> +}
> +
> +static void w1_gpio_write_byte(struct udevice *dev, u8 byte)
> +{
> + int i;
> +
> + for (i = 0; i < 8; ++i)
> + w1_gpio_write_bit(dev, (byte >> i) & 0x1);
> +}
> +
> +static bool w1_gpio_reset(struct udevice *dev)
> +{
> + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> + int val;
> +
> + dm_gpio_set_dir_flags(>gpio, GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
> + udelay(W1_TIMING_G);
> +
> + dm_gpio_set_value(>gpio, 0);
> + udelay(W1_TIMING_H);
> +
> + dm_gpio_set_dir_flags(>gpio, GPIOD_IS_IN);
> + udelay(W1_TIMING_I);
> +
> + val = dm_gpio_get_value(>gpio);
> + udelay(W1_TIMING_J);
> +
> + return val;
> +}
> +
> +static u8 w1_gpio_triplet(struct udevice *dev, bool bdir)
> +{
> + u8 id_bit   = w1_gpio_read_bit(dev);
> + u8 comp_bit = w1_gpio_read_bit(dev);
> + u8 retval;
> +
> + if (id_bit && comp_bit)
> + return 0x03;  /* error */
> +
> + if (!id_bit && !comp_bit) {
> + /* Both bits are valid, take the direction given */
> + retval = bdir ? 0x04 : 0;
> + } else {
> + /* Only one bit is valid, take that direction */
> + bdir = id_bit;
> + retval = id_bit ? 0x05 : 0x02;
> + }
> +
> + w1_gpio_write_bit(dev, bdir);
> + return retval;
> +}
> +
> +
> +static const struct w1_ops w1_gpio_ops = {
> + .read_byte  = w1_gpio_read_byte,
> + .reset  = w1_gpio_reset,
> + .triplet= w1_gpio_triplet,
> + .write_byte = w1_gpio_write_byte,
> +};
> +
> +static int w1_gpio_ofdata_to_platdata(struct udevice *dev)
> +{
> + struct w1_gpio_pdata *pdata = dev_get_platdata(dev);
> + int ret;
> +
> + ret = gpio_request_by_name(dev, "gpios", 0, >gpio, 0);
> + if (ret < 0)
> + goto error;
> +
> + return 0;
> +
> +error:
> + printf("Error claiming GPIO %d\n", ret);
> + return ret;
> +};
> +
> +static const struct udevice_id w1_gpio_id[] = {
> + { "w1-gpio", 0 },
> + { },
> +};
> +
> +U_BOOT_DRIVER(w1_gpio_drv) = {
> + .id = 

Re: [U-Boot] [PATCH v3] Retrieve MAC address from EEPROM

[Michal Simek]

On 10.11.2016 13:43, Olliver Schinagl wrote:
> On 10-11-16 13:37, Michal Simek wrote:
>> On 10.11.2016 13:31, Olliver Schinagl wrote:
>>> On 10-11-16 13:26, Michal Simek wrote:
 On 10.11.2016 13:08, Olliver Schinagl wrote:
> Hi Michal,
>
> On 10-11-16 12:37, Michal Simek wrote:
>> On 8.11.2016 16:54, Olliver Schinagl wrote:
>>> This patch-series introduces methods to retrieve the MAC address
>>> from an
>>> onboard EEPROM using the read_rom_hwaddr hook.
>>>
>>> The reason we might want to read the MAC address from an EEPROM
>>> instead of
>>> storing the entire environment is mostly a size thing. Our default
>>> environment
>>> already is bigger then the EEPROM so it is understandable that
>>> someone might
>>> not give up the entire eeprom just for the u-boot environment.
>>> Especially if
>>> only board specific things might be stored in the eeprom (MAC,
>>> serial, product
>>> number etc). Additionally it is a board thing and a MAC address
>>> might be
>>> programmed at the factory before ever seeing any software.
>>>
>>> The current idea of the eeprom layout, is to skip the first 8 bytes,
>>> so that
>>> other information can be stored there if needed, for example a
>>> header
>>> with some
>>> magic to identify the EEPROM. Or equivalent purposes.
>>>
>>> After those 8 bytes the MAC address follows the first macaddress.
>>> The
>>> macaddress
>>> is appended by a CRC8 byte and then padded to make for nice 8 bytes.
>>> Following
>>> the first macaddress one can store a second, or a third etc etc mac
>>> addresses.
>>>
>>> The CRC8 is optional (via a define) but is strongly recommended to
>>> have. It
>>> helps preventing user error and more importantly, checks if the
>>> bytes
>>> read are
>>> actually a user inserted address. E.g. only writing 1 macaddress
>>> into
>>> the eeprom
>>> but trying to consume 2.
>>>
>>> Hans de Goede and I talked about retrieving the MAC from the EEPROM
>>> for sunxi
>>> based boards a while ago, but hopefully this patch makes possible to
>>> have
>>> something slightly more generic, even if only the configuration
>>> options.
>>> Additionally the EEPROM layout could be recommended by u-boot as
>>> well.
>>>
>>> Since the Olimex OLinuXino sunxi boards all seem to have an
>>> eeprom, I
>>> started
>>> my work on one of these and tested the implementation with one of
>>> our
>>> own real
>>> MAC addresses.
>>>
>>> What still needs disussing I think, is the patches that remove the
>>> 'setup_environment' function in board.c. I think we have put
>>> functionality in
>>> boards.c which does not belong. Injecting ethernet addresses into
>>> the
>>> environment instead of using the net_op hooks as well as parsing the
>>> fdt to get
>>> overrides from. I think especially this last point should be done at
>>> a higher
>>> level, if possible at all.
>>>
>>> I explicitly did not use the wiser eth_validate_ethaddr_str(),
>>> eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful
>>> (dependancies) to get these functions into the tools. I would
>>> suggest
>>> to merge
>>> as is, and if someone wants to improve these simple tools to use
>>> these functions
>>> to happily do so.
>>>
>>> These patches where tested on Olimex OLinuXino Lime1 (A10/A20),
>>> Lime2
>>> (NAND
>>> and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
>>> internally on our production systems since v2 of this patch set.
>>>
>>> As a recommendation, I would suggest for the zynq to adopt the
>>> config
>>> defines,
>>> as they are nice and generic and suggest to also implement the 8
>>> byte
>>> offset,
>>> crc8 and pad bytes.
>> Yes, Zynq and ZynqMP is using this feature. I am also aware about
>> using
>> qspi OTP region for storing information like this.
> I saw, which triggered me here. What the Znyq currently does it
> uses its
> own private CONFIG setting:
>
> +int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
> +{
> +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
> +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET) && \
> +defined(CONFIG_ZYNQ_EEPROM_BUS)
> +   i2c_set_bus_num(CONFIG_ZYNQ_EEPROM_BUS);
> +
> +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
> +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
> +   ethaddr, 6))
> +   printf("I2C EEPROM MAC address read failed\n");
> +#endif
> +
> +   return 0;
> +}
>
> which are ZNYQ specific. In my patchset I give them very generic names
> as they can be used by anybody really.
>
> Once 

Re: [U-Boot] [PATCH v3] Retrieve MAC address from EEPROM

[Michal Simek]

On 10.11.2016 13:31, Olliver Schinagl wrote:
> On 10-11-16 13:26, Michal Simek wrote:
>> On 10.11.2016 13:08, Olliver Schinagl wrote:
>>> Hi Michal,
>>>
>>> On 10-11-16 12:37, Michal Simek wrote:
 On 8.11.2016 16:54, Olliver Schinagl wrote:
> This patch-series introduces methods to retrieve the MAC address
> from an
> onboard EEPROM using the read_rom_hwaddr hook.
>
> The reason we might want to read the MAC address from an EEPROM
> instead of
> storing the entire environment is mostly a size thing. Our default
> environment
> already is bigger then the EEPROM so it is understandable that
> someone might
> not give up the entire eeprom just for the u-boot environment.
> Especially if
> only board specific things might be stored in the eeprom (MAC,
> serial, product
> number etc). Additionally it is a board thing and a MAC address
> might be
> programmed at the factory before ever seeing any software.
>
> The current idea of the eeprom layout, is to skip the first 8 bytes,
> so that
> other information can be stored there if needed, for example a header
> with some
> magic to identify the EEPROM. Or equivalent purposes.
>
> After those 8 bytes the MAC address follows the first macaddress. The
> macaddress
> is appended by a CRC8 byte and then padded to make for nice 8 bytes.
> Following
> the first macaddress one can store a second, or a third etc etc mac
> addresses.
>
> The CRC8 is optional (via a define) but is strongly recommended to
> have. It
> helps preventing user error and more importantly, checks if the bytes
> read are
> actually a user inserted address. E.g. only writing 1 macaddress into
> the eeprom
> but trying to consume 2.
>
> Hans de Goede and I talked about retrieving the MAC from the EEPROM
> for sunxi
> based boards a while ago, but hopefully this patch makes possible to
> have
> something slightly more generic, even if only the configuration
> options.
> Additionally the EEPROM layout could be recommended by u-boot as well.
>
> Since the Olimex OLinuXino sunxi boards all seem to have an eeprom, I
> started
> my work on one of these and tested the implementation with one of our
> own real
> MAC addresses.
>
> What still needs disussing I think, is the patches that remove the
> 'setup_environment' function in board.c. I think we have put
> functionality in
> boards.c which does not belong. Injecting ethernet addresses into the
> environment instead of using the net_op hooks as well as parsing the
> fdt to get
> overrides from. I think especially this last point should be done at
> a higher
> level, if possible at all.
>
> I explicitly did not use the wiser eth_validate_ethaddr_str(),
> eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful
> (dependancies) to get these functions into the tools. I would suggest
> to merge
> as is, and if someone wants to improve these simple tools to use
> these functions
> to happily do so.
>
> These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2
> (NAND
> and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
> internally on our production systems since v2 of this patch set.
>
> As a recommendation, I would suggest for the zynq to adopt the config
> defines,
> as they are nice and generic and suggest to also implement the 8 byte
> offset,
> crc8 and pad bytes.
 Yes, Zynq and ZynqMP is using this feature. I am also aware about using
 qspi OTP region for storing information like this.
>>> I saw, which triggered me here. What the Znyq currently does it uses its
>>> own private CONFIG setting:
>>>
>>> +int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
>>> +{
>>> +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
>>> +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET) && \
>>> +defined(CONFIG_ZYNQ_EEPROM_BUS)
>>> +   i2c_set_bus_num(CONFIG_ZYNQ_EEPROM_BUS);
>>> +
>>> +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
>>> +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
>>> +   ethaddr, 6))
>>> +   printf("I2C EEPROM MAC address read failed\n");
>>> +#endif
>>> +
>>> +   return 0;
>>> +}
>>>
>>> which are ZNYQ specific. In my patchset I give them very generic names
>>> as they can be used by anybody really.
>>>
>>> Once Maxime's patches have merged and stabilized, i'd even say to switch
>>> over to the eeprom framework.
>> Can you give me that link to these patches?
> Well [0] is your own patch, so that is easy :) [1] is Maxime's work. But
> with your generic comment, this entire function probably can simply go
> then. The only thing I haven't figured out/thought through yet, if
> eeprom reading fails, we want to fall back to the old board 

Re: [U-Boot] [PATCH v3] Retrieve MAC address from EEPROM

[Olliver Schinagl]

On 10-11-16 13:37, Michal Simek wrote:

On 10.11.2016 13:31, Olliver Schinagl wrote:

On 10-11-16 13:26, Michal Simek wrote:

On 10.11.2016 13:08, Olliver Schinagl wrote:

Hi Michal,

On 10-11-16 12:37, Michal Simek wrote:

On 8.11.2016 16:54, Olliver Schinagl wrote:

This patch-series introduces methods to retrieve the MAC address
from an
onboard EEPROM using the read_rom_hwaddr hook.

The reason we might want to read the MAC address from an EEPROM
instead of
storing the entire environment is mostly a size thing. Our default
environment
already is bigger then the EEPROM so it is understandable that
someone might
not give up the entire eeprom just for the u-boot environment.
Especially if
only board specific things might be stored in the eeprom (MAC,
serial, product
number etc). Additionally it is a board thing and a MAC address
might be
programmed at the factory before ever seeing any software.

The current idea of the eeprom layout, is to skip the first 8 bytes,
so that
other information can be stored there if needed, for example a header
with some
magic to identify the EEPROM. Or equivalent purposes.

After those 8 bytes the MAC address follows the first macaddress. The
macaddress
is appended by a CRC8 byte and then padded to make for nice 8 bytes.
Following
the first macaddress one can store a second, or a third etc etc mac
addresses.

The CRC8 is optional (via a define) but is strongly recommended to
have. It
helps preventing user error and more importantly, checks if the bytes
read are
actually a user inserted address. E.g. only writing 1 macaddress into
the eeprom
but trying to consume 2.

Hans de Goede and I talked about retrieving the MAC from the EEPROM
for sunxi
based boards a while ago, but hopefully this patch makes possible to
have
something slightly more generic, even if only the configuration
options.
Additionally the EEPROM layout could be recommended by u-boot as well.

Since the Olimex OLinuXino sunxi boards all seem to have an eeprom, I
started
my work on one of these and tested the implementation with one of our
own real
MAC addresses.

What still needs disussing I think, is the patches that remove the
'setup_environment' function in board.c. I think we have put
functionality in
boards.c which does not belong. Injecting ethernet addresses into the
environment instead of using the net_op hooks as well as parsing the
fdt to get
overrides from. I think especially this last point should be done at
a higher
level, if possible at all.

I explicitly did not use the wiser eth_validate_ethaddr_str(),
eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful
(dependancies) to get these functions into the tools. I would suggest
to merge
as is, and if someone wants to improve these simple tools to use
these functions
to happily do so.

These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2
(NAND
and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
internally on our production systems since v2 of this patch set.

As a recommendation, I would suggest for the zynq to adopt the config
defines,
as they are nice and generic and suggest to also implement the 8 byte
offset,
crc8 and pad bytes.

Yes, Zynq and ZynqMP is using this feature. I am also aware about using
qspi OTP region for storing information like this.

I saw, which triggered me here. What the Znyq currently does it uses its
own private CONFIG setting:

+int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
+{
+#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
+defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET) && \
+defined(CONFIG_ZYNQ_EEPROM_BUS)
+   i2c_set_bus_num(CONFIG_ZYNQ_EEPROM_BUS);
+
+   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
+   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
+   ethaddr, 6))
+   printf("I2C EEPROM MAC address read failed\n");
+#endif
+
+   return 0;
+}

which are ZNYQ specific. In my patchset I give them very generic names
as they can be used by anybody really.

Once Maxime's patches have merged and stabilized, i'd even say to switch
over to the eeprom framework.

Can you give me that link to these patches?

Well [0] is your own patch, so that is easy :) [1] is Maxime's work. But
with your generic comment, this entire function probably can simply go
then. The only thing I haven't figured out/thought through yet, if
eeprom reading fails, we want to fall back to the old board specific
method. But I think I know what might do there ...

Joe recently applied one our patch
http://lists.denx.de/pipermail/u-boot/2016-November/271662.html
which in case of NET_RAMDOM_ETHADDR generates random address.
I don't have in my mind exact calling sequence but I expect when eeprom
read failed then random eth is generated if selected or warning, etc.
In the case of sunxi, we generate a MAC address based off the CPU serial 
number and device ID, which is more predictable and doesn't change 
compared to the random MAC. The random MAC would then 

Re: [U-Boot] [PATCH v3] Retrieve MAC address from EEPROM

[Olliver Schinagl]

On 10-11-16 13:26, Michal Simek wrote:

On 10.11.2016 13:08, Olliver Schinagl wrote:

Hi Michal,

On 10-11-16 12:37, Michal Simek wrote:

On 8.11.2016 16:54, Olliver Schinagl wrote:

This patch-series introduces methods to retrieve the MAC address from an
onboard EEPROM using the read_rom_hwaddr hook.

The reason we might want to read the MAC address from an EEPROM
instead of
storing the entire environment is mostly a size thing. Our default
environment
already is bigger then the EEPROM so it is understandable that
someone might
not give up the entire eeprom just for the u-boot environment.
Especially if
only board specific things might be stored in the eeprom (MAC,
serial, product
number etc). Additionally it is a board thing and a MAC address might be
programmed at the factory before ever seeing any software.

The current idea of the eeprom layout, is to skip the first 8 bytes,
so that
other information can be stored there if needed, for example a header
with some
magic to identify the EEPROM. Or equivalent purposes.

After those 8 bytes the MAC address follows the first macaddress. The
macaddress
is appended by a CRC8 byte and then padded to make for nice 8 bytes.
Following
the first macaddress one can store a second, or a third etc etc mac
addresses.

The CRC8 is optional (via a define) but is strongly recommended to
have. It
helps preventing user error and more importantly, checks if the bytes
read are
actually a user inserted address. E.g. only writing 1 macaddress into
the eeprom
but trying to consume 2.

Hans de Goede and I talked about retrieving the MAC from the EEPROM
for sunxi
based boards a while ago, but hopefully this patch makes possible to
have
something slightly more generic, even if only the configuration options.
Additionally the EEPROM layout could be recommended by u-boot as well.

Since the Olimex OLinuXino sunxi boards all seem to have an eeprom, I
started
my work on one of these and tested the implementation with one of our
own real
MAC addresses.

What still needs disussing I think, is the patches that remove the
'setup_environment' function in board.c. I think we have put
functionality in
boards.c which does not belong. Injecting ethernet addresses into the
environment instead of using the net_op hooks as well as parsing the
fdt to get
overrides from. I think especially this last point should be done at
a higher
level, if possible at all.

I explicitly did not use the wiser eth_validate_ethaddr_str(),
eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful
(dependancies) to get these functions into the tools. I would suggest
to merge
as is, and if someone wants to improve these simple tools to use
these functions
to happily do so.

These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2
(NAND
and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
internally on our production systems since v2 of this patch set.

As a recommendation, I would suggest for the zynq to adopt the config
defines,
as they are nice and generic and suggest to also implement the 8 byte
offset,
crc8 and pad bytes.

Yes, Zynq and ZynqMP is using this feature. I am also aware about using
qspi OTP region for storing information like this.

I saw, which triggered me here. What the Znyq currently does it uses its
own private CONFIG setting:

+int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
+{
+#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
+defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET) && \
+defined(CONFIG_ZYNQ_EEPROM_BUS)
+   i2c_set_bus_num(CONFIG_ZYNQ_EEPROM_BUS);
+
+   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
+   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
+   ethaddr, 6))
+   printf("I2C EEPROM MAC address read failed\n");
+#endif
+
+   return 0;
+}

which are ZNYQ specific. In my patchset I give them very generic names
as they can be used by anybody really.

Once Maxime's patches have merged and stabilized, i'd even say to switch
over to the eeprom framework.

Can you give me that link to these patches?
Well [0] is your own patch, so that is easy :) [1] is Maxime's work. But 
with your generic comment, this entire function probably can simply go 
then. The only thing I haven't figured out/thought through yet, if 
eeprom reading fails, we want to fall back to the old board specific 
method. But I think I know what might do there ...


Olliver

[0] http://git.denx.de/?p=u-boot.git;a=commit;h=6919b4bf363574
[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg230179.html


Thanks,
Michal



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

Re: [U-Boot] [PATCH v3] Retrieve MAC address from EEPROM

[Michal Simek]

On 10.11.2016 13:08, Olliver Schinagl wrote:
> Hi Michal,
> 
> On 10-11-16 12:37, Michal Simek wrote:
>> On 8.11.2016 16:54, Olliver Schinagl wrote:
>>> This patch-series introduces methods to retrieve the MAC address from an
>>> onboard EEPROM using the read_rom_hwaddr hook.
>>>
>>> The reason we might want to read the MAC address from an EEPROM
>>> instead of
>>> storing the entire environment is mostly a size thing. Our default
>>> environment
>>> already is bigger then the EEPROM so it is understandable that
>>> someone might
>>> not give up the entire eeprom just for the u-boot environment.
>>> Especially if
>>> only board specific things might be stored in the eeprom (MAC,
>>> serial, product
>>> number etc). Additionally it is a board thing and a MAC address might be
>>> programmed at the factory before ever seeing any software.
>>>
>>> The current idea of the eeprom layout, is to skip the first 8 bytes,
>>> so that
>>> other information can be stored there if needed, for example a header
>>> with some
>>> magic to identify the EEPROM. Or equivalent purposes.
>>>
>>> After those 8 bytes the MAC address follows the first macaddress. The
>>> macaddress
>>> is appended by a CRC8 byte and then padded to make for nice 8 bytes.
>>> Following
>>> the first macaddress one can store a second, or a third etc etc mac
>>> addresses.
>>>
>>> The CRC8 is optional (via a define) but is strongly recommended to
>>> have. It
>>> helps preventing user error and more importantly, checks if the bytes
>>> read are
>>> actually a user inserted address. E.g. only writing 1 macaddress into
>>> the eeprom
>>> but trying to consume 2.
>>>
>>> Hans de Goede and I talked about retrieving the MAC from the EEPROM
>>> for sunxi
>>> based boards a while ago, but hopefully this patch makes possible to
>>> have
>>> something slightly more generic, even if only the configuration options.
>>> Additionally the EEPROM layout could be recommended by u-boot as well.
>>>
>>> Since the Olimex OLinuXino sunxi boards all seem to have an eeprom, I
>>> started
>>> my work on one of these and tested the implementation with one of our
>>> own real
>>> MAC addresses.
>>>
>>> What still needs disussing I think, is the patches that remove the
>>> 'setup_environment' function in board.c. I think we have put
>>> functionality in
>>> boards.c which does not belong. Injecting ethernet addresses into the
>>> environment instead of using the net_op hooks as well as parsing the
>>> fdt to get
>>> overrides from. I think especially this last point should be done at
>>> a higher
>>> level, if possible at all.
>>>
>>> I explicitly did not use the wiser eth_validate_ethaddr_str(),
>>> eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful
>>> (dependancies) to get these functions into the tools. I would suggest
>>> to merge
>>> as is, and if someone wants to improve these simple tools to use
>>> these functions
>>> to happily do so.
>>>
>>> These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2
>>> (NAND
>>> and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
>>> internally on our production systems since v2 of this patch set.
>>>
>>> As a recommendation, I would suggest for the zynq to adopt the config
>>> defines,
>>> as they are nice and generic and suggest to also implement the 8 byte
>>> offset,
>>> crc8 and pad bytes.
>> Yes, Zynq and ZynqMP is using this feature. I am also aware about using
>> qspi OTP region for storing information like this.
> I saw, which triggered me here. What the Znyq currently does it uses its
> own private CONFIG setting:
> 
> +int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
> +{
> +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
> +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET) && \
> +defined(CONFIG_ZYNQ_EEPROM_BUS)
> +   i2c_set_bus_num(CONFIG_ZYNQ_EEPROM_BUS);
> +
> +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
> +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
> +   ethaddr, 6))
> +   printf("I2C EEPROM MAC address read failed\n");
> +#endif
> +
> +   return 0;
> +}
> 
> which are ZNYQ specific. In my patchset I give them very generic names
> as they can be used by anybody really.
> 
> Once Maxime's patches have merged and stabilized, i'd even say to switch
> over to the eeprom framework.

Can you give me that link to these patches?

Thanks,
Michal

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

[U-Boot] [PATCH] tools: fix mksunxiboot build for tools-all target

[Andre Przywara]

Commit fed329aebe3a ("tools: add mksunxiboot to tools-all target") added
mksunxiboot to the tools-all target, but used the CONFIG_SUNXI symbol
to enable its build. Now commit aec9a0f19f64 ("sunxi: Rename CONFIG_SUNXI
to CONFIG_ARCH_SUNXI"), merged before that, renamed that symbol, so that
the first patch basically gets ineffective.
Adjust the symbol name in tools/Makefile to make it build again.

Signed-off-by: Andre Przywara 
---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 400588c..9edb504 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -13,7 +13,7 @@ CONFIG_CMD_NET = y
 CONFIG_XWAY_SWAP_BYTES = y
 CONFIG_NETCONSOLE = y
 CONFIG_SHA1_CHECK_UB_IMG = y
-CONFIG_SUNXI = y
+CONFIG_ARCH_SUNXI = y
 endif
 
 subdir-$(HOST_TOOLS_ALL) += easylogo
-- 
2.9.0

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

Re: [U-Boot] [PATCH 08/11] net: sunxi: Allow sunxi boards to set the MAC from an EEPROM

[Olliver Schinagl]

Hi Michal,

On 10-11-16 12:51, Michal Simek wrote:

On 8.11.2016 16:54, Olliver Schinagl wrote:

This patch uses the newly introduced Kconfig options to use the net_op
read_rom_hwaddr to retrieve the MAC from an EEPROM.
This will be especially useful for the Olimex OLinuXino series of sunxi
boards as they all have an 2k i2c eeprom chip.

The MAC address in the eeprom is ignored (if enabled) if the CRC8 check
fails.

This new functionality allows for querying multiple MAC addresses. The
first (supported) device being probed gets the first address, the second
the second etc. If a generated MAC address is desired, set it to all 0
(and if crc8 is configured also add that) for the adapter.

Signed-off-by: Olliver Schinagl 
---
  board/sunxi/Kconfig |  4 
  board/sunxi/board.c | 39 ++-
  2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e1d4ab1..6b8ac99 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -414,6 +414,7 @@ config I2C0_ENABLE
  
  config I2C1_ENABLE

bool "Enable I2C/TWI controller 1"
+   default y if (NET_ETHADDR_EEPROM_I2C_BUS = 1)
default n
select CMD_I2C
---help---
@@ -421,6 +422,7 @@ config I2C1_ENABLE
  
  config I2C2_ENABLE

bool "Enable I2C/TWI controller 2"
+   default y if NET_ETHADDR_EEPROM_I2C_BUS = 2
default n
select CMD_I2C
---help---
@@ -428,6 +430,7 @@ config I2C2_ENABLE
  
  if MACH_SUN6I || MACH_SUN7I

  config I2C3_ENABLE
+   default y if NET_ETHADDR_EEPROM_I2C_BUS = 3
bool "Enable I2C/TWI controller 3"
default n
select CMD_I2C
@@ -447,6 +450,7 @@ endif
  
  if MACH_SUN7I

  config I2C4_ENABLE
+   default y if NET_ETHADDR_EEPROM_I2C_BUS = 4
bool "Enable I2C/TWI controller 4"
default n
select CMD_I2C
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 71124f4..f1e64cd 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -12,6 +12,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -31,6 +32,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -626,11 +628,46 @@ static void _sunxi_gen_sid_hwaddr(unsigned char 
*enetaddr, uint8_t cnt)
memcpy(enetaddr, mac_addr, ARP_HLEN);
  }
  
+static void _sunxi_read_rom_hwaddr(unsigned char *enetaddr, uint8_t cnt)

+{
+   uint8_t eeprom[ARP_HLEN + 1] = { 0x00 };
+#if defined(CONFIG_NET_ETHADDR_EEPROM) && 
defined(CONFIG_NET_ETHADDR_EEPROM_I2C)
+   int old_i2c_bus;
+
+   old_i2c_bus = i2c_get_bus_num();
+   if (old_i2c_bus != CONFIG_NET_ETHADDR_EEPROM_I2C_BUS)
+   i2c_set_bus_num(CONFIG_NET_ETHADDR_EEPROM_I2C_BUS);
+   /* Skip in blocks of 8 (ARP + CRC8 + pad), but read 7. */
+   if (i2c_read(CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR,
+CONFIG_NET_ETHADDR_EEPROM_OFFSET + (cnt * (ARP_HLEN + 2)),
+CONFIG_NET_ETHADDR_EEPROM_I2C_ADDRLEN,
+eeprom, ARP_HLEN + 1)) {
+   i2c_set_bus_num(old_i2c_bus);
+   puts("Could not read the EEPROM; EEPROM missing?\n");
+   return;
+   }
+   i2c_set_bus_num(old_i2c_bus);
+#ifdef CONFIG_NET_ETHADDR_EEPROM_CRC8
+   if (crc8(0, eeprom, ARP_HLEN) != eeprom[ARP_HLEN]) {
+   puts("CRC error on MAC address from EEPROM.\n");
+   return;
+   }
+#endif
+#endif
+
+   memcpy(enetaddr, eeprom, ARP_HLEN);
+}
+

ok. I have briefly looked at the whole series and I think that this
should be done in the core because this should be shared across all
drivers.
Because what you have above make in general sense for every board which
contain mac address in eeprom.
That's why I would create

eeprom_read_rom_etheaddr() in core which will do stuff as you have above
and in driver we will simply assign it to read_rom_hwaddr in drivers or
by default for all with options to rewrite it.
This function will be empty when !NET_ETHADDR_EEPROM.

By this or similar way you open this to all ethernet drivers to read mac
just through enabling Kconfig.

IMHO doesn't make sense to c the same logic over all ethernet drivers.


Initially, I do agree very much. But when I first wrote this last year, 
there was no other driver yet etc. It is very very generic so maybe make 
this a weak function up one level, and let the driver override it even?


Makes using the eeprom framework later easier too. I'll cook something 
up. Good idea!


Olliver


Thanks,
Michal





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

Re: [U-Boot] [PATCH v3] Retrieve MAC address from EEPROM

[Olliver Schinagl]

Hi Michal,

On 10-11-16 12:37, Michal Simek wrote:

On 8.11.2016 16:54, Olliver Schinagl wrote:

This patch-series introduces methods to retrieve the MAC address from an
onboard EEPROM using the read_rom_hwaddr hook.

The reason we might want to read the MAC address from an EEPROM instead of
storing the entire environment is mostly a size thing. Our default environment
already is bigger then the EEPROM so it is understandable that someone might
not give up the entire eeprom just for the u-boot environment. Especially if
only board specific things might be stored in the eeprom (MAC, serial, product
number etc). Additionally it is a board thing and a MAC address might be
programmed at the factory before ever seeing any software.

The current idea of the eeprom layout, is to skip the first 8 bytes, so that
other information can be stored there if needed, for example a header with some
magic to identify the EEPROM. Or equivalent purposes.

After those 8 bytes the MAC address follows the first macaddress. The macaddress
is appended by a CRC8 byte and then padded to make for nice 8 bytes. Following
the first macaddress one can store a second, or a third etc etc mac addresses.

The CRC8 is optional (via a define) but is strongly recommended to have. It
helps preventing user error and more importantly, checks if the bytes read are
actually a user inserted address. E.g. only writing 1 macaddress into the eeprom
but trying to consume 2.

Hans de Goede and I talked about retrieving the MAC from the EEPROM for sunxi
based boards a while ago, but hopefully this patch makes possible to have
something slightly more generic, even if only the configuration options.
Additionally the EEPROM layout could be recommended by u-boot as well.

Since the Olimex OLinuXino sunxi boards all seem to have an eeprom, I started
my work on one of these and tested the implementation with one of our own real
MAC addresses.

What still needs disussing I think, is the patches that remove the
'setup_environment' function in board.c. I think we have put functionality in
boards.c which does not belong. Injecting ethernet addresses into the
environment instead of using the net_op hooks as well as parsing the fdt to get
overrides from. I think especially this last point should be done at a higher
level, if possible at all.

I explicitly did not use the wiser eth_validate_ethaddr_str(),
eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful
(dependancies) to get these functions into the tools. I would suggest to merge
as is, and if someone wants to improve these simple tools to use these functions
to happily do so.

These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2 (NAND
and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
internally on our production systems since v2 of this patch set.

As a recommendation, I would suggest for the zynq to adopt the config defines,
as they are nice and generic and suggest to also implement the 8 byte offset,
crc8 and pad bytes.

Yes, Zynq and ZynqMP is using this feature. I am also aware about using
qspi OTP region for storing information like this.
I saw, which triggered me here. What the Znyq currently does it uses its 
own private CONFIG setting:


+int zynq_board_read_rom_ethaddr(unsigned char *ethaddr)
+{
+#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
+defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET) && \
+defined(CONFIG_ZYNQ_EEPROM_BUS)
+   i2c_set_bus_num(CONFIG_ZYNQ_EEPROM_BUS);
+
+   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
+   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
+   ethaddr, 6))
+   printf("I2C EEPROM MAC address read failed\n");
+#endif
+
+   return 0;
+}

which are ZNYQ specific. In my patchset I give them very generic names 
as they can be used by anybody really.


Once Maxime's patches have merged and stabilized, i'd even say to switch 
over to the eeprom framework.


Thanks,
Michal




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

Re: [U-Boot] [PATCH 0/7] sunxi: Add support for the CHIP Pro

[Heiko Schocher]

Hello Maxime,

Am 09.11.2016 um 15:44 schrieb Maxime Ripard:

Hi Heiko,

On Wed, Nov 09, 2016 at 08:47:12AM +0100, Heiko Schocher wrote:

Am 08.11.2016 um 17:21 schrieb Maxime Ripard:

The CHIP Pro is a SoM made by NextThing Co, and that embeds a GR8 SIP, an
AXP209 PMIC, a WiFi BT chip and a 512MB SLC NAND.

Since the first Allwinner device coming whit an SLC NAND that doesn't have
the shortcomings (and breakages) the MLC NAND has, we can finally enable
the NAND support on a board by default.

This is the occasion to introduce a bunch of additions needed imo to be
able to come up with a sane NAND support for our users.

The biggest pain point is that the BROM uses a different ECC and randomizer
configuration than for the rest of the NAND. In order to lessen the number
of bitflips, you also need to pad with random data the SPL image.

Since it's quite tedious to do right (and most users won't be able to
figure it out) and since if it is not done right, it will eventually turn
into an unusable system (which is bad UX), we think that the best solution
is to generate an SPL image that already embeds all this. We'll possible
have to do the same thing for the U-Boot image (at least for the random
padding) on MLC NANDs.

The only drawback from that is that you need to flash it raw, instead of
using the usual nand write, but it's just a different command, nothing
major anyway.

In order to flash it, from a device switched in FEL, on your host:
sunxi-fel spl spl/sunxi-spl.bin
sunxi-fel write 0x4a00 u-boot-dtb.bin
sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin
sunxi-fel exe 0x4a00

And on the board, once u-boot is running (assuming the NAND is already
erased):

nand write.raw.noverify 0x4300 0 40
nand write.raw.noverify 0x4300 0x40 40

nand write 0x4a00 0x80 0xc

I also encountered some weird bug in the private libgcc that prevents
U-Boot from loading. Disabling CONFIG_USE_PRIVATE_LIBGCC fixes that.


What was the problem?


It has been reported here:
http://lists.denx.de/pipermail/u-boot/2016-August/264513.html


Hmm.. could not find, what was the real problem ...


Let me know what you think,
Maxime

Boris Brezillon (1):
mtd: nand: add support for the TC58NVG2S0H chip

Hans de Goede (1):
sunxi: Enable UBI and NAND support

Maxime Ripard (5):
sunxi: Sync GR8 DTS and AXP209 with the kernel
tools: sunxi: Add spl image builder
nand: sunxi: Add options for the SPL NAND configuration
scripts: sunxi: Build an raw SPL image
sunxi: Add support for the CHIP Pro

   Makefile  |3 +-
   arch/arm/dts/Makefile |1 +-
   arch/arm/dts/axp209.dtsi  |6 +-
   arch/arm/dts/ntc-gr8-chip-pro.dts |  266 +++-
   arch/arm/dts/ntc-gr8.dtsi | 1132 ++-
   configs/CHIP_pro_defconfig|   27 +-
   drivers/mtd/nand/Kconfig  |   16 +-
   drivers/mtd/nand/nand_ids.c   |3 +-
   include/configs/sunxi-common.h|   26 +-
   scripts/Makefile.spl  |   12 +-
   tools/.gitignore  |1 +-
   tools/Makefile|1 +-
   tools/sunxi-spl-image-builder.c   | 1113 +-
   13 files changed, 2603 insertions(+), 4 deletions(-)
   create mode 100644 arch/arm/dts/ntc-gr8-chip-pro.dts
   create mode 100644 arch/arm/dts/ntc-gr8.dtsi
   create mode 100644 configs/CHIP_pro_defconfig
   create mode 100644 tools/sunxi-spl-image-builder.c

base-commit: d8bdfc80da39211d95f10d24e79f2e867305f71b


Can you please add a README file, where the above things are explained?


Sure, where do you want me to put it? in doc/README.* or somewhere
else?


Yes, may doc/README.sunxi ?

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/11] net: sunxi: Allow sunxi boards to set the MAC from an EEPROM

[Michal Simek]

On 8.11.2016 16:54, Olliver Schinagl wrote:
> This patch uses the newly introduced Kconfig options to use the net_op
> read_rom_hwaddr to retrieve the MAC from an EEPROM.
> This will be especially useful for the Olimex OLinuXino series of sunxi
> boards as they all have an 2k i2c eeprom chip.
> 
> The MAC address in the eeprom is ignored (if enabled) if the CRC8 check
> fails.
> 
> This new functionality allows for querying multiple MAC addresses. The
> first (supported) device being probed gets the first address, the second
> the second etc. If a generated MAC address is desired, set it to all 0
> (and if crc8 is configured also add that) for the adapter.
> 
> Signed-off-by: Olliver Schinagl 
> ---
>  board/sunxi/Kconfig |  4 
>  board/sunxi/board.c | 39 ++-
>  2 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index e1d4ab1..6b8ac99 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -414,6 +414,7 @@ config I2C0_ENABLE
>  
>  config I2C1_ENABLE
>   bool "Enable I2C/TWI controller 1"
> + default y if (NET_ETHADDR_EEPROM_I2C_BUS = 1)
>   default n
>   select CMD_I2C
>   ---help---
> @@ -421,6 +422,7 @@ config I2C1_ENABLE
>  
>  config I2C2_ENABLE
>   bool "Enable I2C/TWI controller 2"
> + default y if NET_ETHADDR_EEPROM_I2C_BUS = 2
>   default n
>   select CMD_I2C
>   ---help---
> @@ -428,6 +430,7 @@ config I2C2_ENABLE
>  
>  if MACH_SUN6I || MACH_SUN7I
>  config I2C3_ENABLE
> + default y if NET_ETHADDR_EEPROM_I2C_BUS = 3
>   bool "Enable I2C/TWI controller 3"
>   default n
>   select CMD_I2C
> @@ -447,6 +450,7 @@ endif
>  
>  if MACH_SUN7I
>  config I2C4_ENABLE
> + default y if NET_ETHADDR_EEPROM_I2C_BUS = 4
>   bool "Enable I2C/TWI controller 4"
>   default n
>   select CMD_I2C
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 71124f4..f1e64cd 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -12,6 +12,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -626,11 +628,46 @@ static void _sunxi_gen_sid_hwaddr(unsigned char 
> *enetaddr, uint8_t cnt)
>   memcpy(enetaddr, mac_addr, ARP_HLEN);
>  }
>  
> +static void _sunxi_read_rom_hwaddr(unsigned char *enetaddr, uint8_t cnt)
> +{
> + uint8_t eeprom[ARP_HLEN + 1] = { 0x00 };
> +#if defined(CONFIG_NET_ETHADDR_EEPROM) && 
> defined(CONFIG_NET_ETHADDR_EEPROM_I2C)
> + int old_i2c_bus;
> +
> + old_i2c_bus = i2c_get_bus_num();
> + if (old_i2c_bus != CONFIG_NET_ETHADDR_EEPROM_I2C_BUS)
> + i2c_set_bus_num(CONFIG_NET_ETHADDR_EEPROM_I2C_BUS);
> + /* Skip in blocks of 8 (ARP + CRC8 + pad), but read 7. */
> + if (i2c_read(CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR,
> +  CONFIG_NET_ETHADDR_EEPROM_OFFSET + (cnt * (ARP_HLEN + 2)),
> +  CONFIG_NET_ETHADDR_EEPROM_I2C_ADDRLEN,
> +  eeprom, ARP_HLEN + 1)) {
> + i2c_set_bus_num(old_i2c_bus);
> + puts("Could not read the EEPROM; EEPROM missing?\n");
> + return;
> + }
> + i2c_set_bus_num(old_i2c_bus);
> +#ifdef CONFIG_NET_ETHADDR_EEPROM_CRC8
> + if (crc8(0, eeprom, ARP_HLEN) != eeprom[ARP_HLEN]) {
> + puts("CRC error on MAC address from EEPROM.\n");
> + return;
> + }
> +#endif
> +#endif
> +
> + memcpy(enetaddr, eeprom, ARP_HLEN);
> +}
> +

ok. I have briefly looked at the whole series and I think that this
should be done in the core because this should be shared across all
drivers.
Because what you have above make in general sense for every board which
contain mac address in eeprom.
That's why I would create

eeprom_read_rom_etheaddr() in core which will do stuff as you have above
and in driver we will simply assign it to read_rom_hwaddr in drivers or
by default for all with options to rewrite it.
This function will be empty when !NET_ETHADDR_EEPROM.

By this or similar way you open this to all ethernet drivers to read mac
just through enabling Kconfig.

IMHO doesn't make sense to c the same logic over all ethernet drivers.

Thanks,
Michal



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

Re: [U-Boot] [PATCH v3] Retrieve MAC address from EEPROM

[Michal Simek]

On 8.11.2016 16:54, Olliver Schinagl wrote:
> This patch-series introduces methods to retrieve the MAC address from an
> onboard EEPROM using the read_rom_hwaddr hook.
> 
> The reason we might want to read the MAC address from an EEPROM instead of
> storing the entire environment is mostly a size thing. Our default environment
> already is bigger then the EEPROM so it is understandable that someone might
> not give up the entire eeprom just for the u-boot environment. Especially if
> only board specific things might be stored in the eeprom (MAC, serial, product
> number etc). Additionally it is a board thing and a MAC address might be
> programmed at the factory before ever seeing any software.
> 
> The current idea of the eeprom layout, is to skip the first 8 bytes, so that
> other information can be stored there if needed, for example a header with 
> some
> magic to identify the EEPROM. Or equivalent purposes.
> 
> After those 8 bytes the MAC address follows the first macaddress. The 
> macaddress
> is appended by a CRC8 byte and then padded to make for nice 8 bytes. Following
> the first macaddress one can store a second, or a third etc etc mac addresses.
> 
> The CRC8 is optional (via a define) but is strongly recommended to have. It
> helps preventing user error and more importantly, checks if the bytes read are
> actually a user inserted address. E.g. only writing 1 macaddress into the 
> eeprom
> but trying to consume 2.
> 
> Hans de Goede and I talked about retrieving the MAC from the EEPROM for sunxi
> based boards a while ago, but hopefully this patch makes possible to have
> something slightly more generic, even if only the configuration options.
> Additionally the EEPROM layout could be recommended by u-boot as well.
> 
> Since the Olimex OLinuXino sunxi boards all seem to have an eeprom, I started
> my work on one of these and tested the implementation with one of our own real
> MAC addresses.
> 
> What still needs disussing I think, is the patches that remove the
> 'setup_environment' function in board.c. I think we have put functionality in
> boards.c which does not belong. Injecting ethernet addresses into the
> environment instead of using the net_op hooks as well as parsing the fdt to 
> get
> overrides from. I think especially this last point should be done at a higher
> level, if possible at all.
> 
> I explicitly did not use the wiser eth_validate_ethaddr_str(),
> eth_parse_enetaddr() and the ARP_HLEN define as it was quite painful
> (dependancies) to get these functions into the tools. I would suggest to merge
> as is, and if someone wants to improve these simple tools to use these 
> functions
> to happily do so.
> 
> These patches where tested on Olimex OLinuXino Lime1 (A10/A20), Lime2 (NAND
> and eMMC) and A20-OLinuXino-MICRO-4G variants and have been in use
> internally on our production systems since v2 of this patch set.
> 
> As a recommendation, I would suggest for the zynq to adopt the config defines,
> as they are nice and generic and suggest to also implement the 8 byte offset,
> crc8 and pad bytes.

Yes, Zynq and ZynqMP is using this feature. I am also aware about using
qspi OTP region for storing information like this.

Thanks,
Michal


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

[U-Boot] [PATCHv2 14/15] armv8: ls2080a: Enable PCIe in defconfigs

[Zhiqiang Hou]

From: Minghuan Lian 

The patch enables PCIe in ls2080a defconfigs and
removes unused PCIe related macro defines.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - Moved PCIe related configs macro to defconfig

 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  8 
 configs/ls2080aqds_SECURE_BOOT_defconfig   |  5 -
 configs/ls2080aqds_defconfig   |  5 -
 configs/ls2080aqds_nand_defconfig  |  5 -
 configs/ls2080aqds_qspi_defconfig  |  5 -
 configs/ls2080ardb_SECURE_BOOT_defconfig   |  5 -
 configs/ls2080ardb_defconfig   |  5 -
 configs/ls2080ardb_nand_defconfig  |  5 -
 include/configs/ls2080a_common.h   | 22 --
 include/configs/ls2080aqds.h   |  1 -
 include/configs/ls2080ardb.h   |  1 -
 11 files changed, 28 insertions(+), 39 deletions(-)

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..bd07808 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -104,14 +104,6 @@
 #define CONFIG_SYS_PCIE2_PHYS_ADDR 0x12ULL
 #define CONFIG_SYS_PCIE3_PHYS_ADDR 0x14ULL
 #define CONFIG_SYS_PCIE4_PHYS_ADDR 0x16ULL
-/* LUT registers */
-#define PCIE_LUT_BASE  0x8
-#define PCIE_LUT_LCTRL00x7F8
-#define PCIE_LUT_DBG   0x7FC
-#define PCIE_LUT_UDR(n) (0x800 + (n) * 8)
-#define PCIE_LUT_LDR(n) (0x804 + (n) * 8)
-#define PCIE_LUT_ENABLE (1 << 31)
-#define PCIE_LUT_ENTRY_COUNT32
 
 /* Device Configuration */
 #define DCFG_BASE  0x01e0
diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig 
b/configs/ls2080aqds_SECURE_BOOT_defconfig
index e5ad80d..3147cb2 100644
--- a/configs/ls2080aqds_SECURE_BOOT_defconfig
+++ b/configs/ls2080aqds_SECURE_BOOT_defconfig
@@ -27,7 +27,6 @@ CONFIG_DM=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
@@ -39,3 +38,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls2080aqds_defconfig b/configs/ls2080aqds_defconfig
index e8fa1bd..5361503 100644
--- a/configs/ls2080aqds_defconfig
+++ b/configs/ls2080aqds_defconfig
@@ -27,7 +27,6 @@ CONFIG_DM=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
@@ -37,3 +36,7 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls2080aqds_nand_defconfig 
b/configs/ls2080aqds_nand_defconfig
index 2161815..db8b8ef 100644
--- a/configs/ls2080aqds_nand_defconfig
+++ b/configs/ls2080aqds_nand_defconfig
@@ -36,7 +36,6 @@ CONFIG_DM=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
@@ -46,3 +45,7 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls2080aqds_qspi_defconfig 
b/configs/ls2080aqds_qspi_defconfig
index 7c84eba..cbde0e9 100644
--- a/configs/ls2080aqds_qspi_defconfig
+++ b/configs/ls2080aqds_qspi_defconfig
@@ -28,7 +28,6 @@ CONFIG_DM=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
@@ -38,3 +37,7 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig 
b/configs/ls2080ardb_SECURE_BOOT_defconfig
index c2e613e..b7bde56 100644
--- a/configs/ls2080ardb_SECURE_BOOT_defconfig
+++ b/configs/ls2080ardb_SECURE_BOOT_defconfig
@@ -27,7 +27,6 @@ CONFIG_DM=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
@@ -39,3 +38,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls2080ardb_defconfig b/configs/ls2080ardb_defconfig
index 1a5d83a..3c09b23 100644
--- a/configs/ls2080ardb_defconfig
+++ b/configs/ls2080ardb_defconfig
@@ -27,7 +27,6 @@ CONFIG_DM=y
 

[U-Boot] [PATCHv2 15/15] pci: layerscape: remove unnecessary legacy code

[Zhiqiang Hou]

From: Minghuan Lian 

All Layerscape SoCs have supported new PCIe driver based on DM.
The lagecy PCIe driver code is unused and can be removed.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - No change

 drivers/pci/pcie_layerscape.c | 733 --
 1 file changed, 733 deletions(-)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index f107d1c..31a485e 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -95,737 +95,6 @@ DECLARE_GLOBAL_DATA_PTR;
 #define PCIE_BAR2_SIZE (4 * 1024) /* 4K */
 #define PCIE_BAR4_SIZE (1 * 1024 * 1024) /* 1M */
 
-#ifndef CONFIG_DM_PCI
-
-struct ls_pcie {
-   int idx;
-   void __iomem *dbi;
-   void __iomem *va_cfg0;
-   void __iomem *va_cfg1;
-   int next_lut_index;
-   struct pci_controller hose;
-};
-
-struct ls_pcie_info {
-   unsigned long regs;
-   int pci_num;
-   u64 phys_base;
-   u64 cfg0_phys;
-   u64 cfg0_size;
-   u64 cfg1_phys;
-   u64 cfg1_size;
-   u64 mem_bus;
-   u64 mem_phys;
-   u64 mem_size;
-   u64 io_bus;
-   u64 io_phys;
-   u64 io_size;
-};
-
-#define SET_LS_PCIE_INFO(x, num)   \
-{  \
-   x.regs = CONFIG_SYS_PCIE##num##_ADDR;   \
-   x.phys_base = CONFIG_SYS_PCIE##num##_PHYS_ADDR; \
-   x.cfg0_phys = CONFIG_SYS_PCIE_CFG0_PHYS_OFF +   \
- CONFIG_SYS_PCIE##num##_PHYS_ADDR; \
-   x.cfg0_size = CONFIG_SYS_PCIE_CFG0_SIZE;\
-   x.cfg1_phys = CONFIG_SYS_PCIE_CFG1_PHYS_OFF +   \
- CONFIG_SYS_PCIE##num##_PHYS_ADDR; \
-   x.cfg1_size = CONFIG_SYS_PCIE_CFG1_SIZE;\
-   x.mem_bus = CONFIG_SYS_PCIE_MEM_BUS;\
-   x.mem_phys = CONFIG_SYS_PCIE_MEM_PHYS_OFF + \
-CONFIG_SYS_PCIE##num##_PHYS_ADDR;  \
-   x.mem_size = CONFIG_SYS_PCIE_MEM_SIZE;  \
-   x.io_bus = CONFIG_SYS_PCIE_IO_BUS;  \
-   x.io_phys = CONFIG_SYS_PCIE_IO_PHYS_OFF +   \
-   CONFIG_SYS_PCIE##num##_PHYS_ADDR;   \
-   x.io_size = CONFIG_SYS_PCIE_IO_SIZE;\
-   x.pci_num = num;\
-}
-
-#ifdef CONFIG_LS102XA
-#include 
-
-/* PEX1/2 Misc Ports Status Register */
-#define LTSSM_STATE_SHIFT  20
-
-static int ls_pcie_link_state(struct ls_pcie *pcie)
-{
-   u32 state;
-   struct ccsr_scfg *scfg = (struct ccsr_scfg *)CONFIG_SYS_FSL_SCFG_ADDR;
-
-   state = in_be32(>pexmscportsr[pcie->idx]);
-   state = (state >> LTSSM_STATE_SHIFT) & LTSSM_STATE_MASK;
-   if (state < LTSSM_PCIE_L0) {
-   debug("PCIe link error. LTSSM=0x%02x.\n", state);
-   return 0;
-   }
-
-   return 1;
-}
-#else
-static int ls_pcie_link_state(struct ls_pcie *pcie)
-{
-   u32 state;
-
-   state = pex_lut_in32(pcie->dbi + PCIE_LUT_BASE + PCIE_LUT_DBG) &
-   LTSSM_STATE_MASK;
-   if (state < LTSSM_PCIE_L0) {
-   debug("PCIe link error. LTSSM=0x%02x.\n", state);
-   return 0;
-   }
-
-   return 1;
-}
-#endif
-
-static int ls_pcie_link_up(struct ls_pcie *pcie)
-{
-   int state;
-   u32 cap;
-
-   state = ls_pcie_link_state(pcie);
-   if (state)
-   return state;
-
-   /* Try to download speed to gen1 */
-   cap = readl(pcie->dbi + PCIE_LINK_CAP);
-   writel((cap & (~PCIE_LINK_SPEED_MASK)) | 1, pcie->dbi + PCIE_LINK_CAP);
-   /*
-* Notice: the following delay has critical impact on link training
-* if too short (<30ms) the link doesn't get up.
-*/
-   mdelay(100);
-   state = ls_pcie_link_state(pcie);
-   if (state)
-   return state;
-
-   writel(cap, pcie->dbi + PCIE_LINK_CAP);
-
-   return 0;
-}
-
-static void ls_pcie_cfg0_set_busdev(struct ls_pcie *pcie, u32 busdev)
-{
-   writel(PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX0,
-  pcie->dbi + PCIE_ATU_VIEWPORT);
-   writel(busdev, pcie->dbi + PCIE_ATU_LOWER_TARGET);
-}
-
-static void ls_pcie_cfg1_set_busdev(struct ls_pcie *pcie, u32 busdev)
-{
-   writel(PCIE_ATU_REGION_OUTBOUND | PCIE_ATU_REGION_INDEX1,
-  pcie->dbi + PCIE_ATU_VIEWPORT);
-   writel(busdev, pcie->dbi + PCIE_ATU_LOWER_TARGET);
-}
-
-static void ls_pcie_iatu_outbound_set(struct ls_pcie *pcie, int idx, int type,
- u64 phys, u64 bus_addr, pci_size_t size)
-{
-   writel(PCIE_ATU_REGION_OUTBOUND | idx, pcie->dbi + PCIE_ATU_VIEWPORT);
-   writel((u32)phys, pcie->dbi + PCIE_ATU_LOWER_BASE);
-   writel(phys >> 32, pcie->dbi + PCIE_ATU_UPPER_BASE);
-   writel(phys + size - 1, pcie->dbi + PCIE_ATU_LIMIT);
-   writel((u32)bus_addr, pcie->dbi + PCIE_ATU_LOWER_TARGET);

[U-Boot] [PATCHv2 05/15] arm: ls1012a: add PCIe dts node

[Zhiqiang Hou]

From: Minghuan Lian 

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - No change

 arch/arm/dts/fsl-ls1012a.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi
index 024527e..c4ca9c1 100644
--- a/arch/arm/dts/fsl-ls1012a.dtsi
+++ b/arch/arm/dts/fsl-ls1012a.dtsi
@@ -103,5 +103,20 @@
status = "disabled";
};
 
+   pcie@340 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0340 0x0 0x8   /* dbi registers */
+  0x00 0x0348 0x0 0x4   /* lut registers */
+  0x00 0x034c 0x0 0x4   /* pf controls 
registers */
+  0x40 0x 0x0 0x2>; /* configuration 
space */
+   reg-names = "dbi", "lut", "ctrl", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x40 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x40 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
};
 };
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 01/15] configs: ls1021a: enable DT and DM support

[Zhiqiang Hou]

From: Hou Zhiqiang 

Enable DT to support Driver Model.

Signed-off-by: Hou Zhiqiang 
---
V2:
 - New patch

 configs/ls1021aqds_nand_defconfig   | 3 +++
 configs/ls1021aqds_nor_SECURE_BOOT_defconfig| 2 ++
 configs/ls1021atwr_nor_SECURE_BOOT_defconfig| 2 ++
 configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 2 ++
 configs/ls1021atwr_sdcard_ifc_defconfig | 3 +++
 5 files changed, 12 insertions(+)

diff --git a/configs/ls1021aqds_nand_defconfig 
b/configs/ls1021aqds_nand_defconfig
index 2bdc723..63f455c 100644
--- a/configs/ls1021aqds_nand_defconfig
+++ b/configs/ls1021aqds_nand_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1021AQDS=y
+CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart"
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_FSL_DDR3=y
@@ -13,6 +14,7 @@ CONFIG_VIDEO=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_CONTROL=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,NAND_BOOT"
 CONFIG_NAND_BOOT=y
@@ -36,6 +38,7 @@ CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
+CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_PCI=y
diff --git a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig 
b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
index 567c852..d9f3503 100644
--- a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
+++ b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
@@ -1,11 +1,13 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1021AQDS=y
+CONFIG_DEFAULT_DEVICE_TREE="ls1021a-qds-duart"
 CONFIG_SYS_FSL_DDR3=y
 CONFIG_VIDEO=y
 # CONFIG_SYS_MALLOC_F is not set
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_CONTROL=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="SECURE_BOOT"
 CONFIG_BOOTDELAY=3
diff --git a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig 
b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
index f218e8f..5899dee 100644
--- a/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
+++ b/configs/ls1021atwr_nor_SECURE_BOOT_defconfig
@@ -1,11 +1,13 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1021ATWR=y
+CONFIG_DEFAULT_DEVICE_TREE="ls1021a-twr-duart"
 CONFIG_VIDEO=y
 # CONFIG_SYS_MALLOC_F is not set
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_OF_CONTROL=y
 CONFIG_SYS_EXTRA_OPTIONS="SECURE_BOOT"
 CONFIG_BOOTDELAY=3
 CONFIG_SILENT_CONSOLE=y
diff --git a/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig 
b/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig
index 8178e8a..29f0c8e 100644
--- a/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig
+++ b/configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1021ATWR=y
+CONFIG_DEFAULT_DEVICE_TREE="ls1021a-twr-duart"
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
@@ -12,6 +13,7 @@ CONFIG_VIDEO=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_CONTROL=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT,SECURE_BOOT"
 CONFIG_BOOTDELAY=0
diff --git a/configs/ls1021atwr_sdcard_ifc_defconfig 
b/configs/ls1021atwr_sdcard_ifc_defconfig
index eef1c1c..fd5c6e5 100644
--- a/configs/ls1021atwr_sdcard_ifc_defconfig
+++ b/configs/ls1021atwr_sdcard_ifc_defconfig
@@ -1,5 +1,6 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1021ATWR=y
+CONFIG_DEFAULT_DEVICE_TREE="ls1021a-twr-duart"
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SPL_I2C_SUPPORT=y
@@ -11,6 +12,7 @@ CONFIG_VIDEO=y
 CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_CONTROL=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_SYS_EXTRA_OPTIONS="RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT"
 CONFIG_SD_BOOT=y
@@ -33,6 +35,7 @@ CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
+CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_PCI=y
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 02/15] dm: pci: return the real controller in pci_bus_to_hose()

[Zhiqiang Hou]

From: Minghuan Lian 

for the legacy PCI driver, the function pci_bus_to_hose() returns
the real PCIe controller. To keep consistency, this function is
changed to return the PCIe controller pointer of the root bus
instead of the current PCIe bus.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - No change

 drivers/pci/pci_compat.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci_compat.c b/drivers/pci/pci_compat.c
index ddaf358..25bc095 100644
--- a/drivers/pci/pci_compat.c
+++ b/drivers/pci/pci_compat.c
@@ -49,5 +49,5 @@ struct pci_controller *pci_bus_to_hose(int busnum)
return NULL;
}
 
-   return dev_get_uclass_priv(bus);
+   return dev_get_uclass_priv(pci_get_controller(bus));
 }
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 04/15] arm: ls1021a: add PCIe dts node

[Zhiqiang Hou]

From: Minghuan Lian 

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - No change

 arch/arm/dts/ls1021a.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 119b1af..e06cf60 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -373,5 +373,36 @@
interrupts = ;
dr_mode = "host";
};
+
+   pcie@340 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x0340 0x2   /* dbi registers */
+  0x0157 0x1   /* pf controls registers */
+  0x2400 0x2>; /* configuration space */
+   reg-names = "dbi", "ctrl", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x2402 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x2800 0x2800 0x0 
0x0800>; /* non-prefetchable memory */
+   };
+
+   pcie@350 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x0350 0x1/* dbi registers */
+  0x0157 0x1/* pf controls registers */
+  0x3400 0x2>;  /* configuration space */
+   reg-names = "dbi", "ctrl", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   num-lanes = <2>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x3402 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x3800 0x3800 0x0 
0x0800>; /* non-prefetchable memory */
+   };
};
 };
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 12/15] armv8: ls1043a: Enable PCIe and E1000 in defconfigs

[Zhiqiang Hou]

From: Minghuan Lian 

The patch enables PCIe and E1000 in ls1043a defconfigs and
removes unused PCIe related macro defines.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - Moved PCIe related configs macro to defconfig

 configs/ls1043aqds_defconfig |  7 ++-
 configs/ls1043aqds_lpuart_defconfig  |  7 ++-
 configs/ls1043aqds_nand_defconfig|  7 ++-
 configs/ls1043aqds_nor_ddr3_defconfig|  7 ++-
 configs/ls1043aqds_qspi_defconfig|  7 ++-
 configs/ls1043aqds_sdcard_ifc_defconfig  |  7 ++-
 configs/ls1043aqds_sdcard_qspi_defconfig |  7 ++-
 configs/ls1043ardb_SECURE_BOOT_defconfig |  7 ++-
 configs/ls1043ardb_defconfig |  7 ++-
 configs/ls1043ardb_nand_defconfig|  7 ++-
 configs/ls1043ardb_sdcard_defconfig  |  7 ++-
 include/configs/ls1043a_common.h | 17 -
 12 files changed, 66 insertions(+), 28 deletions(-)

diff --git a/configs/ls1043aqds_defconfig b/configs/ls1043aqds_defconfig
index 7ca27d7..b085a23 100644
--- a/configs/ls1043aqds_defconfig
+++ b/configs/ls1043aqds_defconfig
@@ -24,7 +24,6 @@ CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_SPI_FLASH=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_USB=y
@@ -32,3 +31,9 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1043aqds_lpuart_defconfig 
b/configs/ls1043aqds_lpuart_defconfig
index f6efe46..40d8224 100644
--- a/configs/ls1043aqds_lpuart_defconfig
+++ b/configs/ls1043aqds_lpuart_defconfig
@@ -25,7 +25,6 @@ CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_SPI_FLASH=y
-CONFIG_PCI=y
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
 CONFIG_DM_SPI=y
@@ -34,3 +33,9 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1043aqds_nand_defconfig 
b/configs/ls1043aqds_nand_defconfig
index dbdb416..f7da0eb 100644
--- a/configs/ls1043aqds_nand_defconfig
+++ b/configs/ls1043aqds_nand_defconfig
@@ -36,7 +36,6 @@ CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_SPI_FLASH=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_USB=y
@@ -44,3 +43,9 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1043aqds_nor_ddr3_defconfig 
b/configs/ls1043aqds_nor_ddr3_defconfig
index 1f33c88..88b3bb8 100644
--- a/configs/ls1043aqds_nor_ddr3_defconfig
+++ b/configs/ls1043aqds_nor_ddr3_defconfig
@@ -24,7 +24,6 @@ CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_SPI_FLASH=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_USB=y
@@ -32,3 +31,9 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1043aqds_qspi_defconfig 
b/configs/ls1043aqds_qspi_defconfig
index 38abeaf..bc2f2c0 100644
--- a/configs/ls1043aqds_qspi_defconfig
+++ b/configs/ls1043aqds_qspi_defconfig
@@ -27,7 +27,6 @@ CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_SPI_FLASH=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_USB=y
@@ -35,3 +34,9 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1043aqds_sdcard_ifc_defconfig 
b/configs/ls1043aqds_sdcard_ifc_defconfig
index 24220ed..0878337 100644
--- a/configs/ls1043aqds_sdcard_ifc_defconfig
+++ b/configs/ls1043aqds_sdcard_ifc_defconfig
@@ -36,7 +36,6 @@ CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_SPI_FLASH=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_USB=y
@@ -44,3 +43,9 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1043aqds_sdcard_qspi_defconfig 
b/configs/ls1043aqds_sdcard_qspi_defconfig
index fdcbf8a..2819f2b 100644
--- a/configs/ls1043aqds_sdcard_qspi_defconfig
+++ b/configs/ls1043aqds_sdcard_qspi_defconfig
@@ -37,7 +37,6 @@ CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_SPI_FLASH=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_USB=y
@@ -45,3 +44,9 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y

[U-Boot] [PATCHv2 11/15] arm: ls1012a: Enable PCIe and E1000 in defconfigs

[Zhiqiang Hou]

From: Minghuan Lian 

The patch enables PCIe and E1000 in ls1012a defconfigs and
removes unused PCIe related macro defines

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - Moved PCIe related configs macro to defconfig

 configs/ls1012afrdm_qspi_defconfig |  5 +
 configs/ls1012aqds_qspi_defconfig  |  5 -
 configs/ls1012ardb_qspi_defconfig  |  5 -
 include/configs/ls1012aqds.h   | 16 
 include/configs/ls1012ardb.h   | 16 
 5 files changed, 13 insertions(+), 34 deletions(-)

diff --git a/configs/ls1012afrdm_qspi_defconfig 
b/configs/ls1012afrdm_qspi_defconfig
index 1f3d487..0c862b6 100644
--- a/configs/ls1012afrdm_qspi_defconfig
+++ b/configs/ls1012afrdm_qspi_defconfig
@@ -28,9 +28,14 @@ CONFIG_DM=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
+CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls1012aqds_qspi_defconfig 
b/configs/ls1012aqds_qspi_defconfig
index c0514ae..0e54d5a 100644
--- a/configs/ls1012aqds_qspi_defconfig
+++ b/configs/ls1012aqds_qspi_defconfig
@@ -30,7 +30,6 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
@@ -38,3 +37,7 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls1012ardb_qspi_defconfig 
b/configs/ls1012ardb_qspi_defconfig
index 13c9f21..9f5c82b 100644
--- a/configs/ls1012ardb_qspi_defconfig
+++ b/configs/ls1012ardb_qspi_defconfig
@@ -30,7 +30,6 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
@@ -38,3 +37,7 @@ CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/include/configs/ls1012aqds.h b/include/configs/ls1012aqds.h
index 0cc1791..0e4f6e3 100644
--- a/include/configs/ls1012aqds.h
+++ b/include/configs/ls1012aqds.h
@@ -155,24 +155,8 @@
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
CONFIG_SYS_SCSI_MAX_LUN)
 #define CONFIG_PCIE1   /* PCIE controller 1 */
-#define CONFIG_PCIE_LAYERSCAPE /* Use common FSL Layerscape PCIe code */
 #define FSL_PCIE_COMPAT "fsl,ls1043a-pcie"
 
-#define CONFIG_SYS_PCI_64BIT
-
-#define CONFIG_SYS_PCIE_CFG0_PHYS_OFF  0x
-#define CONFIG_SYS_PCIE_CFG0_SIZE  0x1000  /* 4k */
-#define CONFIG_SYS_PCIE_CFG1_PHYS_OFF  0x1000
-#define CONFIG_SYS_PCIE_CFG1_SIZE  0x1000  /* 4k */
-
-#define CONFIG_SYS_PCIE_IO_BUS 0x
-#define CONFIG_SYS_PCIE_IO_PHYS_OFF0x0001
-#define CONFIG_SYS_PCIE_IO_SIZE0x0001  /* 64k */
-
-#define CONFIG_SYS_PCIE_MEM_BUS 0x0800
-#define CONFIG_SYS_PCIE_MEM_PHYS_OFF0x0400
-#define CONFIG_SYS_PCIE_MEM_SIZE0x8000  /* 128M */
-
 #define CONFIG_NET_MULTI
 #define CONFIG_PCI_SCAN_SHOW
 #define CONFIG_CMD_PCI
diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index 15410dd..d5573ba 100644
--- a/include/configs/ls1012ardb.h
+++ b/include/configs/ls1012ardb.h
@@ -68,24 +68,8 @@
 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
CONFIG_SYS_SCSI_MAX_LUN)
 #define CONFIG_PCIE1   /* PCIE controller 1 */
-#define CONFIG_PCIE_LAYERSCAPE /* Use common FSL Layerscape PCIe code */
 #define FSL_PCIE_COMPAT "fsl,ls1043a-pcie"
 
-#define CONFIG_SYS_PCI_64BIT
-
-#define CONFIG_SYS_PCIE_CFG0_PHYS_OFF  0x
-#define CONFIG_SYS_PCIE_CFG0_SIZE  0x1000  /* 4k */
-#define CONFIG_SYS_PCIE_CFG1_PHYS_OFF  0x1000
-#define CONFIG_SYS_PCIE_CFG1_SIZE  0x1000  /* 4k */
-
-#define CONFIG_SYS_PCIE_IO_BUS 0x
-#define CONFIG_SYS_PCIE_IO_PHYS_OFF0x0001
-#define CONFIG_SYS_PCIE_IO_SIZE0x0001  /* 64k */
-
-#define CONFIG_SYS_PCIE_MEM_BUS 0x0800
-#define CONFIG_SYS_PCIE_MEM_PHYS_OFF0x0400
-#define CONFIG_SYS_PCIE_MEM_SIZE0x8000  /* 128M */
-
 #define CONFIG_NET_MULTI
 #define CONFIG_PCI_SCAN_SHOW
 #define CONFIG_CMD_PCI
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 13/15] armv8: ls1046a: Enable PCIe and E1000 in defconfigs

[Zhiqiang Hou]

From: Minghuan Lian 

The patch enables PCIe and E1000 in ls1046a related defconfigs.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - Moved PCIe related configs macro to defconfig

 configs/ls1046aqds_defconfig | 6 ++
 configs/ls1046aqds_nand_defconfig| 6 ++
 configs/ls1046aqds_qspi_defconfig| 6 ++
 configs/ls1046aqds_sdcard_ifc_defconfig  | 6 ++
 configs/ls1046aqds_sdcard_qspi_defconfig | 6 ++
 configs/ls1046ardb_emmc_defconfig| 6 ++
 configs/ls1046ardb_qspi_defconfig| 6 ++
 configs/ls1046ardb_sdcard_defconfig  | 6 ++
 8 files changed, 48 insertions(+)

diff --git a/configs/ls1046aqds_defconfig b/configs/ls1046aqds_defconfig
index 2cc1a0b..e80cc4d 100644
--- a/configs/ls1046aqds_defconfig
+++ b/configs/ls1046aqds_defconfig
@@ -26,3 +26,9 @@ CONFIG_SPI_FLASH=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1046aqds_nand_defconfig 
b/configs/ls1046aqds_nand_defconfig
index 01140b9..57c6e61 100644
--- a/configs/ls1046aqds_nand_defconfig
+++ b/configs/ls1046aqds_nand_defconfig
@@ -28,3 +28,9 @@ CONFIG_SPI_FLASH=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1046aqds_qspi_defconfig 
b/configs/ls1046aqds_qspi_defconfig
index c8a68fa..b1ef63b 100644
--- a/configs/ls1046aqds_qspi_defconfig
+++ b/configs/ls1046aqds_qspi_defconfig
@@ -29,3 +29,9 @@ CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
 CONFIG_FSL_QSPI=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1046aqds_sdcard_ifc_defconfig 
b/configs/ls1046aqds_sdcard_ifc_defconfig
index e6eeadd..52a9435 100644
--- a/configs/ls1046aqds_sdcard_ifc_defconfig
+++ b/configs/ls1046aqds_sdcard_ifc_defconfig
@@ -28,3 +28,9 @@ CONFIG_SPI_FLASH=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1046aqds_sdcard_qspi_defconfig 
b/configs/ls1046aqds_sdcard_qspi_defconfig
index 8a14862..b241d47 100644
--- a/configs/ls1046aqds_sdcard_qspi_defconfig
+++ b/configs/ls1046aqds_sdcard_qspi_defconfig
@@ -30,3 +30,9 @@ CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_DSPI=y
 CONFIG_FSL_QSPI=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1046ardb_emmc_defconfig 
b/configs/ls1046ardb_emmc_defconfig
index ba28047..1d974c6 100644
--- a/configs/ls1046ardb_emmc_defconfig
+++ b/configs/ls1046ardb_emmc_defconfig
@@ -25,3 +25,9 @@ CONFIG_SPI_FLASH=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1046ardb_qspi_defconfig 
b/configs/ls1046ardb_qspi_defconfig
index 8508c09..583f190 100644
--- a/configs/ls1046ardb_qspi_defconfig
+++ b/configs/ls1046ardb_qspi_defconfig
@@ -24,3 +24,9 @@ CONFIG_SPI_FLASH=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
diff --git a/configs/ls1046ardb_sdcard_defconfig 
b/configs/ls1046ardb_sdcard_defconfig
index 01e6397..e355c3a 100644
--- a/configs/ls1046ardb_sdcard_defconfig
+++ b/configs/ls1046ardb_sdcard_defconfig
@@ -25,3 +25,9 @@ CONFIG_SPI_FLASH=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
 CONFIG_FSL_QSPI=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
+CONFIG_NETDEVICES=y
+CONFIG_E1000=y
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 10/15] arm: ls1021a: Enable PCIe in defconfigs

[Zhiqiang Hou]

From: Minghuan Lian 

The patch enables PCIe in ls1021a defconfigs and
removes unused PCIe related macro defines.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - Moved PCIe related configs macro to defconfig

 configs/ls1021aqds_ddr4_nor_defconfig   |  5 -
 configs/ls1021aqds_ddr4_nor_lpuart_defconfig|  5 -
 configs/ls1021aqds_nand_defconfig   |  5 -
 configs/ls1021aqds_nor_SECURE_BOOT_defconfig|  5 -
 configs/ls1021aqds_nor_defconfig|  5 -
 configs/ls1021aqds_nor_lpuart_defconfig |  5 -
 configs/ls1021aqds_qspi_defconfig   |  5 -
 configs/ls1021aqds_sdcard_ifc_defconfig |  5 -
 configs/ls1021aqds_sdcard_qspi_defconfig|  5 -
 configs/ls1021atwr_nor_SECURE_BOOT_defconfig|  5 -
 configs/ls1021atwr_nor_defconfig|  5 -
 configs/ls1021atwr_nor_lpuart_defconfig |  5 -
 configs/ls1021atwr_qspi_defconfig   |  5 -
 configs/ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig |  5 -
 configs/ls1021atwr_sdcard_ifc_defconfig |  5 -
 configs/ls1021atwr_sdcard_qspi_defconfig|  5 -
 include/configs/ls1021aqds.h| 16 
 include/configs/ls1021atwr.h| 16 
 18 files changed, 64 insertions(+), 48 deletions(-)

diff --git a/configs/ls1021aqds_ddr4_nor_defconfig 
b/configs/ls1021aqds_ddr4_nor_defconfig
index 95930f3..64ca746 100644
--- a/configs/ls1021aqds_ddr4_nor_defconfig
+++ b/configs/ls1021aqds_ddr4_nor_defconfig
@@ -29,7 +29,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
@@ -38,3 +37,7 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls1021aqds_ddr4_nor_lpuart_defconfig 
b/configs/ls1021aqds_ddr4_nor_lpuart_defconfig
index 27ef79d..4f1b0d1 100644
--- a/configs/ls1021aqds_ddr4_nor_lpuart_defconfig
+++ b/configs/ls1021aqds_ddr4_nor_lpuart_defconfig
@@ -30,7 +30,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
 CONFIG_USB=y
@@ -39,3 +38,7 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls1021aqds_nand_defconfig 
b/configs/ls1021aqds_nand_defconfig
index 63f455c..cd0c12d 100644
--- a/configs/ls1021aqds_nand_defconfig
+++ b/configs/ls1021aqds_nand_defconfig
@@ -41,7 +41,6 @@ CONFIG_CMD_FAT=y
 CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
@@ -49,3 +48,7 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 # CONFIG_VIDEO_SW_CURSOR is not set
 CONFIG_OF_LIBFDT=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig 
b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
index d9f3503..38b727f 100644
--- a/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
+++ b/configs/ls1021aqds_nor_SECURE_BOOT_defconfig
@@ -31,7 +31,6 @@ CONFIG_CMD_FAT=y
 CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
@@ -41,3 +40,7 @@ CONFIG_USB_STORAGE=y
 CONFIG_RSA=y
 CONFIG_SPL_RSA=y
 CONFIG_OF_LIBFDT=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls1021aqds_nor_defconfig b/configs/ls1021aqds_nor_defconfig
index 12205ea..a4534f3 100644
--- a/configs/ls1021aqds_nor_defconfig
+++ b/configs/ls1021aqds_nor_defconfig
@@ -29,7 +29,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
@@ -38,3 +37,7 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls1021aqds_nor_lpuart_defconfig 
b/configs/ls1021aqds_nor_lpuart_defconfig
index 4d910cd..6cecc04 100644
--- a/configs/ls1021aqds_nor_lpuart_defconfig
+++ b/configs/ls1021aqds_nor_lpuart_defconfig
@@ -30,7 +30,6 @@ CONFIG_OF_CONTROL=y
 CONFIG_DM=y
 CONFIG_NETDEVICES=y
 CONFIG_E1000=y
-CONFIG_PCI=y
 CONFIG_DM_SERIAL=y
 CONFIG_FSL_LPUART=y
 CONFIG_USB=y
@@ -39,3 +38,7 @@ CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_LAYERSCAPE=y
diff --git a/configs/ls1021aqds_qspi_defconfig 

[U-Boot] [PATCHv2 08/15] armv8: ls2080a: add PCIe dts node

[Zhiqiang Hou]

From: Minghuan Lian 

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - No change

 arch/arm/dts/fsl-ls2080a.dtsi | 60 +++
 1 file changed, 60 insertions(+)

diff --git a/arch/arm/dts/fsl-ls2080a.dtsi b/arch/arm/dts/fsl-ls2080a.dtsi
index f76e981..79047d5 100644
--- a/arch/arm/dts/fsl-ls2080a.dtsi
+++ b/arch/arm/dts/fsl-ls2080a.dtsi
@@ -89,4 +89,64 @@
interrupts = <0 81 0x4>; /* Level high type */
dr_mode = "host";
};
+
+   pcie@340 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0340 0x0 0x8   /* dbi registers */
+  0x00 0x0348 0x0 0x8   /* lut registers */
+  0x10 0x 0x0 0x2>; /* configuration space */
+   reg-names = "dbi", "lut", "config";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   num-lanes = <4>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x10 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x10 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
+
+   pcie@350 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0350 0x0 0x8   /* dbi registers */
+  0x00 0x0358 0x0 0x8   /* lut registers */
+  0x12 0x 0x0 0x2>; /* configuration space */
+   reg-names = "dbi", "lut", "config";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   num-lanes = <4>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x12 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x12 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
+
+   pcie@360 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0360 0x0 0x8   /* dbi registers */
+  0x00 0x0368 0x0 0x8   /* lut registers */
+  0x14 0x 0x0 0x2>; /* configuration space */
+   reg-names = "dbi", "lut", "config";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   num-lanes = <8>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x14 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x14 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
+
+   pcie@370 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0370 0x0 0x8   /* dbi registers */
+  0x00 0x0378 0x0 0x8   /* lut registers */
+  0x16 0x 0x0 0x2>; /* configuration space */
+   reg-names = "dbi", "lut", "config";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   num-lanes = <4>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x16 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x16 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
 };
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 06/15] armv8: ls1043a: add PCIe dts node

[Zhiqiang Hou]

From: Minghuan Lian 

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - No change

 arch/arm/dts/fsl-ls1043a.dtsi | 46 +++
 1 file changed, 46 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index f038f96..fe6698f 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -236,5 +236,51 @@
interrupts = <0 63 0x4>;
dr_mode = "host";
};
+
+   pcie@340 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0340 0x0 0x1   /* dbi registers */
+  0x00 0x0341 0x0 0x1   /* lut registers */
+  0x40 0x 0x0 0x2>; /* configuration 
space */
+   reg-names = "dbi", "lut", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x40 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x40 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
+
+   pcie@350 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0350 0x0 0x1   /* dbi registers */
+  0x00 0x0351 0x0 0x1   /* lut registers */
+  0x48 0x 0x0 0x2>; /* configuration 
space */
+   reg-names = "dbi", "lut", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   num-lanes = <2>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x48 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x48 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
+
+   pcie@360 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0360 0x0 0x1   /* dbi registers */
+  0x00 0x0361 0x0 0x1   /* lut registers */
+  0x50 0x 0x0 0x2>; /* configuration 
space */
+   reg-names = "dbi", "lut", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x50 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x50 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
};
 };
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 07/15] armv8: ls1046a: add PCIe dts node

[Zhiqiang Hou]

From: Minghuan Lian 

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - No change

 arch/arm/dts/fsl-ls1046a.dtsi | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/arch/arm/dts/fsl-ls1046a.dtsi b/arch/arm/dts/fsl-ls1046a.dtsi
index 87dd997..5d30112 100644
--- a/arch/arm/dts/fsl-ls1046a.dtsi
+++ b/arch/arm/dts/fsl-ls1046a.dtsi
@@ -162,5 +162,54 @@
big-endian;
status = "disabled";
};
+
+   pcie@340 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0340 0x0 0x8   /* dbi registers */
+  0x00 0x0348 0x0 0x4   /* lut registers */
+  0x00 0x034c 0x0 0x4   /* pf controls 
registers */
+  0x40 0x 0x0 0x2>; /* configuration 
space */
+   reg-names = "dbi", "lut", "ctrl", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x40 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x40 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
+
+   pcie@350 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0350 0x0 0x8   /* dbi registers */
+  0x00 0x0358 0x0 0x4   /* lut registers */
+  0x00 0x035c 0x0 0x4   /* pf controls 
registers */
+  0x48 0x 0x0 0x2>; /* configuration 
space */
+   reg-names = "dbi", "lut", "ctrl", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   num-lanes = <2>;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x48 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x48 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
+
+   pcie@360 {
+   compatible = "fsl,ls-pcie", "snps,dw-pcie";
+   reg = <0x00 0x0360 0x0 0x8   /* dbi registers */
+  0x00 0x0368 0x0 0x4   /* lut registers */
+  0x00 0x036c 0x0 0x4   /* pf controls 
registers */
+  0x50 0x 0x0 0x2>; /* configuration 
space */
+   reg-names = "dbi", "lut", "ctrl", "config";
+   big-endian;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100 0x0 0x 0x50 0x0002 0x0 
0x0001   /* downstream I/O */
+ 0x8200 0x0 0x4000 0x50 0x4000 0x0 
0x4000>; /* non-prefetchable memory */
+   };
};
 };
-- 
2.1.0.27.g96db324

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

[U-Boot] [PATCHv2 09/15] pci: layerscape: add pci driver based on DM

[Zhiqiang Hou]

From: Minghuan Lian 

There are more than five kinds of Layerscape SoCs. unfortunately,
PCIe controller of each SoC is a little bit different. In order
to avoid too many macro definitions, the patch addes a new
implementation of PCIe driver based on DM. PCIe dts node is
used to describe the difference.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - Rebased the driver against the latest code. 

 drivers/pci/Kconfig   |   8 +
 drivers/pci/pcie_layerscape.c | 761 ++
 2 files changed, 769 insertions(+)

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index b8376b4..07d21ea 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -61,4 +61,12 @@ config PCI_XILINX
  Enable support for the Xilinx AXI bridge for PCI express, an IP block
  which can be used on some generations of Xilinx FPGAs.
 
+config PCIE_LAYERSCAPE
+   bool "Layerscape PCIe support"
+   depends on DM_PCI
+   help
+ Support Layerscape PCIe. The Layerscape SoC may have one or several
+ PCIe controllers. The PCIe may works in RC or EP mode according to
+ RCW setting.
+
 endif
diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 2e6b986..f107d1c 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -11,11 +11,14 @@
 #include 
 #include 
 #include 
+#include 
 #ifndef CONFIG_LS102XA
 #include 
 #include 
 #endif
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #ifndef CONFIG_SYS_PCI_MEMORY_BUS
 #define CONFIG_SYS_PCI_MEMORY_BUS CONFIG_SYS_SDRAM_BASE
 #endif
@@ -40,6 +43,7 @@
 #define PCIE_ATU_REGION_INDEX1 (0x1 << 0)
 #define PCIE_ATU_REGION_INDEX2 (0x2 << 0)
 #define PCIE_ATU_REGION_INDEX3 (0x3 << 0)
+#define PCIE_ATU_REGION_NUM6
 #define PCIE_ATU_CR1   0x904
 #define PCIE_ATU_TYPE_MEM  (0x0 << 0)
 #define PCIE_ATU_TYPE_IO   (0x2 << 0)
@@ -58,6 +62,9 @@
 #define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
 #define PCIE_ATU_UPPER_TARGET  0x91C
 
+/* DBI registers */
+#define PCIE_SRIOV 0x178
+#define PCIE_STRFMR1   0x71c /* Symbol Timer & Filter Mask Register1 */
 #define PCIE_DBI_RO_WR_EN  0x8bc
 
 #define PCIE_LINK_CAP  0x7c
@@ -88,6 +95,8 @@
 #define PCIE_BAR2_SIZE (4 * 1024) /* 4K */
 #define PCIE_BAR4_SIZE (1 * 1024 * 1024) /* 1M */
 
+#ifndef CONFIG_DM_PCI
+
 struct ls_pcie {
int idx;
void __iomem *dbi;
@@ -814,3 +823,755 @@ void ft_pci_setup(void *blob, bd_t *bd)
 {
 }
 #endif
+
+#else
+
+/* LUT registers */
+#define PCIE_LUT_UDR(n)(0x800 + (n) * 8)
+#define PCIE_LUT_LDR(n)(0x804 + (n) * 8)
+#define PCIE_LUT_ENABLE(1 << 31)
+#define PCIE_LUT_ENTRY_COUNT   32
+
+/* PF Controll registers */
+#define PCIE_PF_VF_CTRL0x7F8
+#define PCIE_PF_DBG0x7FC
+
+#define PCIE_SRDS_PRTCL(idx)   (PCIE1 + (idx))
+#define PCIE_SYS_BASE_ADDR 0x340
+#define PCIE_CCSR_SIZE 0x010
+
+/* CS2 */
+#define PCIE_CS2_OFFSET0x1000 /* For PCIe without SR-IOV */
+
+#ifdef CONFIG_LS102XA
+/* LS1021a PCIE space */
+#define LS1021_PCIE_SPACE_OFFSET   0x40ULL
+#define LS1021_PCIE_SPACE_SIZE 0x08ULL
+
+/* LS1021a PEX1/2 Misc Ports Status Register */
+#define LS1021_PEXMSCPORTSR(pex_idx)   (0x94 + (pex_idx) * 4)
+#define LS1021_LTSSM_STATE_SHIFT   20
+#endif
+
+struct ls_pcie {
+   int idx;
+   struct list_head list;
+   struct udevice *bus;
+   struct fdt_resource dbi_res;
+   struct fdt_resource lut_res;
+   struct fdt_resource ctrl_res;
+   struct fdt_resource cfg_res;
+   void __iomem *dbi;
+   void __iomem *lut;
+   void __iomem *ctrl;
+   void __iomem *cfg0;
+   void __iomem *cfg1;
+   bool big_endian;
+   bool enabled;
+   int next_lut_index;
+   struct pci_controller hose;
+};
+
+static LIST_HEAD(ls_pcie_list);
+
+static unsigned int dbi_readl(struct ls_pcie *pcie, unsigned int offset)
+{
+   return in_le32(pcie->dbi + offset);
+}
+
+static void dbi_writel(struct ls_pcie *pcie, unsigned int value,
+  unsigned int offset)
+{
+   out_le32(pcie->dbi + offset, value);
+}
+
+#ifdef CONFIG_FSL_LSCH3
+static void lut_writel(struct ls_pcie *pcie, unsigned int value,
+  unsigned int offset)
+{
+   if (pcie->big_endian)
+   out_be32(pcie->lut + offset, value);
+   else
+   out_le32(pcie->lut + offset, value);
+}
+#endif
+
+static unsigned int ctrl_readl(struct ls_pcie *pcie, unsigned int offset)
+{
+   if (pcie->big_endian)
+   return in_be32(pcie->ctrl + offset);
+   else
+   return in_le32(pcie->ctrl + offset);
+}
+
+static void ctrl_writel(struct ls_pcie *pcie, unsigned int 

[U-Boot] [PATCHv2 03/15] dm: pci: remove pci_bus_to_hose(0) calling

[Zhiqiang Hou]

From: Minghuan Lian 

There may be multiple PCIe controllers in a SoC.
It is not correct that always calling pci_bus_to_hose(0) to get
the first PCIe controller for the PCIe device connected other
controllers. We just remove this calling because hose always point
the correct PCIe controller.

Signed-off-by: Minghuan Lian 
Signed-off-by: Hou Zhiqiang 
---
V2:
 - No change

 drivers/pci/pci_common.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/pci/pci_common.c b/drivers/pci/pci_common.c
index 1755914..448e814 100644
--- a/drivers/pci/pci_common.c
+++ b/drivers/pci/pci_common.c
@@ -181,11 +181,6 @@ phys_addr_t pci_hose_bus_to_phys(struct pci_controller 
*hose,
return phys_addr;
}
 
-#ifdef CONFIG_DM_PCI
-   /* The root controller has the region information */
-   hose = pci_bus_to_hose(0);
-#endif
-
/*
 * if PCI_REGION_MEM is set we do a two pass search with preference
 * on matches that don't have PCI_REGION_SYS_MEMORY set
@@ -248,11 +243,6 @@ pci_addr_t pci_hose_phys_to_bus(struct pci_controller 
*hose,
return bus_addr;
}
 
-#ifdef CONFIG_DM_PCI
-   /* The root controller has the region information */
-   hose = pci_bus_to_hose(0);
-#endif
-
/*
 * if PCI_REGION_MEM is set we do a two pass search with preference
 * on matches that don't have PCI_REGION_SYS_MEMORY set
-- 
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: ls2080aqds: fix SGMII repeater settings

[S.H. Xie]

Hi York,

Please see inline.

> -Original Message-
> From: york sun
> Sent: Tuesday, November 08, 2016 2:42 AM
> To: Prabhakar Kushwaha 
> Cc: shh@gmail.com; u-boot@lists.denx.de; S.H. Xie 
> Subject: Re: [PATCH] armv8: ls2080aqds: fix SGMII repeater settings
> 
> 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?
[S.H] During debug I found mdelay(1) was too short for the signal to be stable, 
mdelay(10) worked but occasional still can see failure, so I changed it to 100 
to assure it.

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