Re: [U-Boot] Please pull fsl-qoriq master

[Tom Rini]

On Thu, May 25, 2017 at 02:59:00PM +, york sun wrote:

> Tom,
> 
> The following changes since commit 22f3368e71321db1e0e15dfbf54b052367890ec7:
> 
>Merge branch 'master' of git://git.denx.de/u-boot-mips (2017-05-13 
> 16:45:35 -0400)
> 
> are available in the git repository at:
> 
>git://git.denx.de/u-boot-fsl-qoriq.git
> 
> for you to fetch changes up to 7676074ac756ab9566d52544cc836f7b93f80b37:
> 
>armv8: LS2080A: Adjust memory map for secure boot headers for 
> NOR-boot (2017-05-23 09:59:14 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] Uboot send pull request

[Tom Rini]

On Wed, May 24, 2017 at 09:36:29AM +0800, ub...@andestech.com wrote:

>  Hi Tom,
> 
>  Please pull the following patch from u-boot-nds32 into your tree.
>  Thanks!
> 
> The following changes since commit be71a179bdd935336fb0bee8283be729144ac965:
> 
>   nds32: eth: Support ftmac100 DM. (2017-05-23 13:48:27 +0800)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-nds32.git master
> 
> for you to fetch changes up to be71a179bdd935336fb0bee8283be729144ac965:
> 
>   nds32: eth: Support ftmac100 DM. (2017-05-23 13:48:27 +0800)

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 3/6] rockchip: evb-rk3328: set uart2 and sdmmc io routing

[Heiko Stuebner]

Hi Kever,

Am Mittwoch, 24. Mai 2017, 10:35:04 CEST schrieb Kever Yang:
> On 05/20/2017 10:29 AM, Simon Glass wrote:
> > On 16 May 2017 at 21:44, Kever Yang  wrote:
> >> In rk3328, some function pin may have more than one choice, and muxed
> >> with more than one IO, for example, the UART2 controller IO,
> >> TX and RX, have 3 choice(setting in com_iomux):
> >> - M0 which mux with GPIO1A0/GPIO1A1
> >> - M1 which mux with GPIO2A0/GPIO2A1
> >> - usb2phy which mux with USB2.0 DP/DM pin.
> >>
> >> We should set these IO routing in board file.
> >>
> >> Signed-off-by: Kever Yang 
> >> ---
> >>
> >>   board/rockchip/evb_rk3328/evb-rk3328.c | 12 
> >>   1 file changed, 12 insertions(+)
> >>
> >> diff --git a/board/rockchip/evb_rk3328/evb-rk3328.c 
> >> b/board/rockchip/evb_rk3328/evb-rk3328.c
> >> index a7895cb..d9dc782 100644
> >> --- a/board/rockchip/evb_rk3328/evb-rk3328.c
> >> +++ b/board/rockchip/evb_rk3328/evb-rk3328.c
> >> @@ -5,7 +5,10 @@
> >>*/
> >>
> >>   #include 
> >> +#include 
> >> +#include 
> >>   #include 
> >> +#include 
> >>   #include 
> >>   #include 
> >>
> >> @@ -13,6 +16,15 @@ DECLARE_GLOBAL_DATA_PTR;
> >>
> >>   int board_init(void)
> >>   {
> >> +#define GRF_BASE   0xff10
> >> +   struct rk3328_grf_regs * const grf = (void *)GRF_BASE;
> >> +
> >> +   /* uart2 select m1, sdcard select m1*/
> >> +   rk_clrsetreg(>com_iomux,
> >> +IOMUX_SEL_UART2_MASK | IOMUX_SEL_SDMMC_MASK,
> >> +IOMUX_SEL_UART2_M1 << IOMUX_SEL_UART2_SHIFT |
> >> +IOMUX_SEL_SDMMC_M1 << IOMUX_SEL_SDMMC_SHIFT);
> >> +
> >>  return 0;
> >>   }
> > This needs to be done via a call to some sort of driver. The above
> > hack is OK in SPL but not in U-Boot proper.
> 
> Yes, SPL also needs this. I thinks here should be the right place
> before there is a SPL for rk3328.
> >
> > See my comments elsewhere about using a misc driver with an IOCTL
> > interface to do this sort of thing. Although here I wonder why you
> > cannot use pinctrl?
> 
> This is different from traditional pinctrl, kernel also still not have
> final solution on this, see [0], and some people think it should be
> done in boot loader.

Just to point out that thanks to David Wu we now have a solution [1]
on the kernel side I'm pretty happy with - as part of the pinctrl driver.


Heiko


> [0] 
> http://lists.infradead.org/pipermail/linux-rockchip/2016-August/011209.html

[1] https://www.spinics.net/lists/kernel/msg2517794.html

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

Re: [U-Boot] [PATCH v3 27/30] ARM: dts: k2g: Disable netcp by default

[Tom Rini]

On Fri, May 26, 2017 at 01:57:18PM -0500, Franklin S Cooper Jr wrote:
> 
> 
> On 05/26/2017 01:46 PM, Tom Rini wrote:
> > On Fri, May 26, 2017 at 01:22:17PM -0500, Franklin S Cooper Jr wrote:
> >>
> >>
> >> On 05/26/2017 01:09 PM, Tom Rini wrote:
> >>> On Wed, May 24, 2017 at 10:43:07AM -0500, Franklin S Cooper Jr wrote:
> >>>
>  Disable netcp by default like all other peripherals in the dtsi file.
>  Enable the peripheral explicitly in the board specific dts file.
> 
>  Signed-off-by: Franklin S Cooper Jr 
> >>>
> >>> This is being mirrored in the kernel, yes?
> >>
> >> This isn't applicable in the kernel since K2G kernel dts is bare minimal
> >> and doesn't included netcp.
> > 
> > OK, but will it be going up at some point?
> 
> Yes. There are some dependency clock framework patches that I'm
> depending on before I can enable various peripherals in the kernel.
> Various folks seem to have made good progress getting things upstreamed
> and I believe the remaining should get accepted soon. After that happens
> we should be able to enable all the various peripherals in the kernel's
> K2G dts file.

OK, thanks.

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 27/30] ARM: dts: k2g: Disable netcp by default

[Franklin S Cooper Jr]

On 05/26/2017 01:46 PM, Tom Rini wrote:
> On Fri, May 26, 2017 at 01:22:17PM -0500, Franklin S Cooper Jr wrote:
>>
>>
>> On 05/26/2017 01:09 PM, Tom Rini wrote:
>>> On Wed, May 24, 2017 at 10:43:07AM -0500, Franklin S Cooper Jr wrote:
>>>
 Disable netcp by default like all other peripherals in the dtsi file.
 Enable the peripheral explicitly in the board specific dts file.

 Signed-off-by: Franklin S Cooper Jr 
>>>
>>> This is being mirrored in the kernel, yes?
>>
>> This isn't applicable in the kernel since K2G kernel dts is bare minimal
>> and doesn't included netcp.
> 
> OK, but will it be going up at some point?

Yes. There are some dependency clock framework patches that I'm
depending on before I can enable various peripherals in the kernel.
Various folks seem to have made good progress getting things upstreamed
and I believe the remaining should get accepted soon. After that happens
we should be able to enable all the various peripherals in the kernel's
K2G dts file.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 27/30] ARM: dts: k2g: Disable netcp by default

[Tom Rini]

On Fri, May 26, 2017 at 01:22:17PM -0500, Franklin S Cooper Jr wrote:
> 
> 
> On 05/26/2017 01:09 PM, Tom Rini wrote:
> > On Wed, May 24, 2017 at 10:43:07AM -0500, Franklin S Cooper Jr wrote:
> > 
> >> Disable netcp by default like all other peripherals in the dtsi file.
> >> Enable the peripheral explicitly in the board specific dts file.
> >>
> >> Signed-off-by: Franklin S Cooper Jr 
> > 
> > This is being mirrored in the kernel, yes?
> 
> This isn't applicable in the kernel since K2G kernel dts is bare minimal
> and doesn't included netcp.

OK, but will it be going up at some point?

-- 
Tom


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

Re: [U-Boot] [PATCH v2 09/30] board_f: Add new function to allow runtime DTB selection

[Franklin S Cooper Jr]

On 05/26/2017 03:08 AM, Lothar Waßmann wrote:
> Franklin S Cooper Jr  wrote:
> 
>> Runtime U-boot dtb selection is generally a two step process. First step
>> is to simply use an initial generic dtb. The second step is to select
>> the dtb and perhaps execute additional code ones U-boot knows what board
>>
> s/ones/once/
> 
>> it is running on. Embedded_dtb_select handles the second step by allowing
>> board specific code to run and perform what ever necessary configuration
>> that is needed.
>>
>> Signed-off-by: Franklin S Cooper Jr 
>> ---
>>  common/Kconfig   | 10 ++
>>  common/board_f.c |  3 +++
>>  include/common.h |  4 
>>  3 files changed, 17 insertions(+)
>>
>> diff --git a/common/Kconfig b/common/Kconfig
>> index 2429953..b6327f0 100644
>> --- a/common/Kconfig
>> +++ b/common/Kconfig
>> @@ -421,6 +421,16 @@ config SYS_STDIO_DEREGISTER
>>  
>>  endmenu
>>  
>> +config DTB_RESELECT
>> +bool "Support swapping dtbs at a later point in boot"
>> +depends on FIT_EMBED
>> +default n
>>
> 'default n' is redundant.
> 
> 

Tom mentioned this also in my v1 patch and I forgot to fix it in this
patchset. I've sent a v3 that already drops this.

https://patchwork.ozlabs.org/patch/766537/
> Lothar Waßmann
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 27/30] ARM: dts: k2g: Disable netcp by default

[Franklin S Cooper Jr]

On 05/26/2017 01:09 PM, Tom Rini wrote:
> On Wed, May 24, 2017 at 10:43:07AM -0500, Franklin S Cooper Jr wrote:
> 
>> Disable netcp by default like all other peripherals in the dtsi file.
>> Enable the peripheral explicitly in the board specific dts file.
>>
>> Signed-off-by: Franklin S Cooper Jr 
> 
> This is being mirrored in the kernel, yes?
> 

This isn't applicable in the kernel since K2G kernel dts is bare minimal
and doesn't included netcp.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] ARM: ti: Update layout for MMC and eMMC (env and dfu)

[Tom Rini]

On Wed, May 24, 2017 at 12:08:27PM +0200, Jean-Jacques Hiblot wrote:

> The problems with the current DFU layout are:
> MMC: The space allocated for u-boot is too small for the latest u-boot
>  (>750KB). We need to increase it. eMMC uses a much bigger area (2MB).
> eMMC: region "u-boot.img.raw" overlaps the environment area and the region
>   "spl-os-image.raw".
> both: region "spl-os-image.raw" is quite small and can't handle android
>   kernels
> 
> Fixing this requires growing some regions and moving others.
> Care has been taken to leave some room for further growth of
> "spl-os-args.raw".
> Also the "env" now appears in the dfu so that it's apparent that the
> region is not free space that can be used to grow "u-boot.img.raw".
> The MLO region is 0x100 sectors wide but the 0x100 are unused in case the
> MLO comes too overflow this areas.
> The total space allocated for those raw binaries is 16MB, of which 13+MB
> are reserved for the kernel image.
> 
> Signed-off-by: Jean-Jacques Hiblot 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] power: pmic: tps65218: Fix tps65218_voltage_update function

[Tom Rini]

On Thu, May 25, 2017 at 03:35:25PM +0530, Keerthy wrote:

> Currently while setting the vsel value for dcdc1 and dcdc2
> the driver is wrongly masking the entire 8 bits in the process
> clearing PFM (bit7) field as well. Hence describe an appropriate
> mask for vsel field and modify only those bits in the vsel
> mask.
> 
> Source: http://www.ti.com/lit/ds/symlink/tps65218.pdf
> 
> Signed-off-by: Keerthy 
> Fixes: 86db550b38 ("power: Add support for the TPS65218 PMIC")

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 09/30] board_f: Add new function to allow runtime DTB selection

[Tom Rini]

On Wed, May 24, 2017 at 10:42:49AM -0500, Franklin S Cooper Jr wrote:

> Runtime U-boot dtb selection is generally a two step process. First step
> is to simply use an initial generic dtb. The second step is to select
> the dtb and perhaps execute additional code ones U-boot knows what board
> it is running on. Embedded_dtb_select handles the second step by allowing
> board specific code to run and perform what ever necessary configuration
> that is needed.
> 
> Signed-off-by: Franklin S Cooper Jr 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 30/30] defconfig: k2g_evm_defconfig: Add K2G ICE to OF_LIST

[Tom Rini]

On Wed, May 24, 2017 at 10:43:10AM -0500, Franklin S Cooper Jr wrote:

> Include K2G ICE to OF_LIST so it can be used for runtime board
> detection.
> 
> Signed-off-by: Franklin S Cooper Jr 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 26/30] ARM: dts: keystone-k2g-evm: Add unit address to memory node

[Tom Rini]

On Wed, May 24, 2017 at 10:43:06AM -0500, Franklin S Cooper Jr wrote:

> Upstream Linux has the unit address being added to the various 66AK2Gx
> boards dts. Therefore, update the dts to mimic this change.
> 
> Also remove memory node from the base K2G dtsi file.
> 
> Signed-off-by: Franklin S Cooper Jr 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 28/30] ARM: dts: k2g: Add DT support for K2G Industrial Communication Engine evm

[Tom Rini]

On Wed, May 24, 2017 at 10:43:08AM -0500, Franklin S Cooper Jr wrote:

> Add basic DT support for K2G ICE evm. Only minimal peripherals are
> supported to allow console output and MMC boot.
> 
> Signed-off-by: Franklin S Cooper Jr 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 25/30] ARM: dts: keystone-k2g: Remove skeleton.dtsi

[Tom Rini]

On Wed, May 24, 2017 at 10:43:05AM -0500, Franklin S Cooper Jr wrote:

> Adding the unit address to the memory node was causing the below error:
> Warning (reg_format): "reg" property in /memory has invalid length
> (8 bytes) (#address-cells == 2, #size-cells == 2)
> 
> Further debugging showed that this was due to the memory node added by
> default to skeleton.dtsi which was being included in keystone-k2g.dtsi.
> Adding a missing node was all that was needed to remove this deprecated
> dtsi file from the SoC dtsi. With skeleton.dtsi removed the dtc compiler
> no longer complained about including the unit address for the memory node.
> 
> Signed-off-by: Franklin S Cooper Jr 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 01/30] ti: common: board_detect: Allow settings board detection variables manually

[Tom Rini]

On Wed, May 24, 2017 at 10:42:41AM -0500, Franklin S Cooper Jr wrote:

> From: Nishanth Menon 
> 
> In some situations the EEPROM used for board detection may not be
> programmed or simply programmed incorrectly. Therefore, it may be
> necessary to "simulate" reading the contents of the EEPROM to set
> appropriate variables used in the board detection code.
> 
> This may also be helpful in certain boot modes where doing i2c reads
> may be costly and the config supports running only a specific board.
> 
> Signed-off-by: Nishanth Menon 
> Signed-off-by: Tero Kristo 
> Signed-off-by: Keerthy 
> Signed-off-by: Franklin S Cooper Jr. 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 07/30] ARM: dts: k2g: Introduce U-boot specific dtsi file

[Tom Rini]

On Wed, May 24, 2017 at 10:42:47AM -0500, Franklin S Cooper Jr wrote:

> Introduce K2G evm specific dtsi file for U-boot specific configurations.
> This will help seperate U-boot only configurations thus making it easier to
> keep device tree files synced between U-boot and Linux.
> 
> For now only add nodes to allow i2c drivers to be probed early during
> the boot process.
> 
> Signed-off-by: Franklin S Cooper Jr 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v3 27/30] ARM: dts: k2g: Disable netcp by default

[Tom Rini]

On Wed, May 24, 2017 at 10:43:07AM -0500, Franklin S Cooper Jr wrote:

> Disable netcp by default like all other peripherals in the dtsi file.
> Enable the peripheral explicitly in the board specific dts file.
> 
> Signed-off-by: Franklin S Cooper Jr 

This is being mirrored in the kernel, yes?

-- 
Tom


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

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Jagan Teki]

On Fri, May 26, 2017 at 11:04 PM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Fri, May 26, 2017 at 2:28 PM, Jagan Teki  wrote:
>
>> OK, please rebase now, forgot to update this series changes.
>
> The pmic command appears in this version, but I see other issues now:
>
> U-Boot SPL 2017.05-00704-g16fa9ec (May 26 2017 - 14:30:16)
> Trying to boot from MMC1
>
>
> U-Boot 2017.05-00704-g16fa9ec (May 26 2017 - 14:30:16 -0300)
>
> CPU:   Freescale i.MX6Q rev1.2 996 MHz (running at 792 MHz)
> CPU:   Automotive temperature grade (-40C to 125C) at 38C
> Reset cause: POR
> Model: Freescale i.MX6 Quad SABRE Smart Device Board
> I2C:   ready
> DRAM:  1 GiB
> PMIC:  PFUZE100 ID=0x10
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> gpio@020a4000: dir_output: error: gpio GPIO3_19 not reserved
> gpio@020a4000: set_value: error: gpio GPIO3_19 not reserved
> gpio@020b4000: dir_output: error: gpio GPIO7_12 not reserved
> gpio@020b4000: set_value: error: gpio GPIO7_12 not reserved
>
> (These errors are new)

Yes, because of non-dm-gpio calls.

>
> PCI:   pcie phy link never came up
> No panel detected: default to Hannstar-XGA
> gpio@0209c000: dir_output: error: gpio GPIO1_21 not reserved
> Display: Hannstar-XGA (1024x768)
> In:serial
> Out:   serial
> Err:   serial
> Net:
> Warning: ethernet@02188000 MAC addresses don't match:
> Address in ROM is  00:04:9f:02:70:67
> Address in environment is  00:04:9f:02:19:a0
> eth0: ethernet@02188000
> Hit any key to stop autoboot:  0
> => dhcp zImage
> Read MDIO failed...
> Read MDIO failed...
> Read MDIO failed...
> Read MDIO failed...
> Read MDIO failed...
> Read MDIO failed...
> Read MDIO failed...
>
> (Ethernet does not work anymore).

Will fix, and get back.

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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Fabio Estevam]

Hi Jagan,

On Fri, May 26, 2017 at 2:28 PM, Jagan Teki  wrote:

> OK, please rebase now, forgot to update this series changes.

The pmic command appears in this version, but I see other issues now:

U-Boot SPL 2017.05-00704-g16fa9ec (May 26 2017 - 14:30:16)
Trying to boot from MMC1


U-Boot 2017.05-00704-g16fa9ec (May 26 2017 - 14:30:16 -0300)

CPU:   Freescale i.MX6Q rev1.2 996 MHz (running at 792 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 38C
Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Smart Device Board
I2C:   ready
DRAM:  1 GiB
PMIC:  PFUZE100 ID=0x10
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
gpio@020a4000: dir_output: error: gpio GPIO3_19 not reserved
gpio@020a4000: set_value: error: gpio GPIO3_19 not reserved
gpio@020b4000: dir_output: error: gpio GPIO7_12 not reserved
gpio@020b4000: set_value: error: gpio GPIO7_12 not reserved

(These errors are new)

PCI:   pcie phy link never came up
No panel detected: default to Hannstar-XGA
gpio@0209c000: dir_output: error: gpio GPIO1_21 not reserved
Display: Hannstar-XGA (1024x768)
In:serial
Out:   serial
Err:   serial
Net:
Warning: ethernet@02188000 MAC addresses don't match:
Address in ROM is  00:04:9f:02:70:67
Address in environment is  00:04:9f:02:19:a0
eth0: ethernet@02188000
Hit any key to stop autoboot:  0
=> dhcp zImage
Read MDIO failed...
Read MDIO failed...
Read MDIO failed...
Read MDIO failed...
Read MDIO failed...
Read MDIO failed...
Read MDIO failed...

(Ethernet does not work anymore).
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Jagan Teki]

On Fri, May 26, 2017 at 10:47 PM, Fabio Estevam  wrote:
> On Fri, May 26, 2017 at 2:14 PM, Jagan Teki  wrote:
>
>> Can you please confirm, are you using v7 series? in this I kept the
>> PMIC as it is.
>>
>> /* PMIC */
>> #define CONFIG_POWER
>> #define CONFIG_POWER_I2C
>> #define CONFIG_POWER_PFUZE100
>> #define CONFIG_POWER_PFUZE100_I2C_ADDR  0x08
>
> I used the latest version from your git tree and these options seem to
> be missing there.

OK, please rebase now, forgot to update this series changes.

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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Fabio Estevam]

On Fri, May 26, 2017 at 2:14 PM, Jagan Teki  wrote:

> Can you please confirm, are you using v7 series? in this I kept the
> PMIC as it is.
>
> /* PMIC */
> #define CONFIG_POWER
> #define CONFIG_POWER_I2C
> #define CONFIG_POWER_PFUZE100
> #define CONFIG_POWER_PFUZE100_I2C_ADDR  0x08

I used the latest version from your git tree and these options seem to
be missing there.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Jagan Teki]

On Fri, May 26, 2017 at 10:34 PM, Fabio Estevam  wrote:
> On Fri, May 26, 2017 at 1:55 PM, Jagan Teki  wrote:
>
>> No, PMIC and I2C are as it is like old code, I never did any
>> modification to use it for dts since driver require dm.
>
> Let me try to clarify the problem.
>
> If I use the latest u-boot-imx:
>
> U-Boot SPL 2017.05-35079-g4c78028 (May 26 2017 - 13:58:48)
> Trying to boot from MMC1
>
>
> U-Boot 2017.05-35079-g4c78028 (May 26 2017 - 13:58:48 -0300)
>
> CPU:   Freescale i.MX6Q rev1.1 at 792MHz
> CPU:   Commercial temperature grade (0C to 95C) at 31C
> Reset cause: POR
> Board: MX6-SabreSD
> I2C:   ready
> DRAM:  1 GiB
> PMIC:  PFUZE100 ID=0x10
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> PCI:   pcie phy link never came up
> No panel detected: default to Hannstar-XGA
> Display: Hannstar-XGA (1024x768)
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC [PRIME]
> Hit any key to stop autoboot:  0
> => pmic
> pmic - PMIC
>
> Usage:
> pmic list - list available PMICs
> pmic name dump - dump named PMIC registers
> pmic name read  - read register
> pmic name write   - write register
> pmic name bat state - write register
> pmic name bat charge - write register
>
> If I use your series:
>
> U-Boot SPL 2017.05-rc3-00037-g60e903a (May 26 2017 - 14:02:35)
> Trying to boot from MMC1
>
>
> U-Boot 2017.05-rc3-00037-g60e903a (May 26 2017 - 14:02:35 -0300)
>
> CPU:   Freescale i.MX6Q rev1.1 at 792MHz
> CPU:   Commercial temperature grade (0C to 95C) at 38C
> Reset cause: POR
> Model: Freescale i.MX6 Quad SABRE Smart Device Board
> DRAM:  1 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> PCI:   pcie phy link never came up
> No panel detected: default to Hannstar-XGA
> Display: Hannstar-XGA (1024x768)
> In:serial
> Out:   serial
> Err:   serial
> Net:   eth0: ethernet@02188000
> Hit any key to stop autoboot:  0
> => pmic
> Unknown command 'pmic' - try 'help'

Can you please confirm, are you using v7 series? in this I kept the
PMIC as it is.

/* PMIC */
#define CONFIG_POWER
#define CONFIG_POWER_I2C
#define CONFIG_POWER_PFUZE100
#define CONFIG_POWER_PFUZE100_I2C_ADDR  0x08

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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Fabio Estevam]

On Fri, May 26, 2017 at 1:55 PM, Jagan Teki  wrote:

> No, PMIC and I2C are as it is like old code, I never did any
> modification to use it for dts since driver require dm.

Let me try to clarify the problem.

If I use the latest u-boot-imx:

U-Boot SPL 2017.05-35079-g4c78028 (May 26 2017 - 13:58:48)
Trying to boot from MMC1


U-Boot 2017.05-35079-g4c78028 (May 26 2017 - 13:58:48 -0300)

CPU:   Freescale i.MX6Q rev1.1 at 792MHz
CPU:   Commercial temperature grade (0C to 95C) at 31C
Reset cause: POR
Board: MX6-SabreSD
I2C:   ready
DRAM:  1 GiB
PMIC:  PFUZE100 ID=0x10
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
PCI:   pcie phy link never came up
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   FEC [PRIME]
Hit any key to stop autoboot:  0
=> pmic
pmic - PMIC

Usage:
pmic list - list available PMICs
pmic name dump - dump named PMIC registers
pmic name read  - read register
pmic name write   - write register
pmic name bat state - write register
pmic name bat charge - write register

If I use your series:

U-Boot SPL 2017.05-rc3-00037-g60e903a (May 26 2017 - 14:02:35)
Trying to boot from MMC1


U-Boot 2017.05-rc3-00037-g60e903a (May 26 2017 - 14:02:35 -0300)

CPU:   Freescale i.MX6Q rev1.1 at 792MHz
CPU:   Commercial temperature grade (0C to 95C) at 38C
Reset cause: POR
Model: Freescale i.MX6 Quad SABRE Smart Device Board
DRAM:  1 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
PCI:   pcie phy link never came up
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@02188000
Hit any key to stop autoboot:  0
=> pmic
Unknown command 'pmic' - try 'help'
=>

As you can see the 'pmic' command is no longer present with your series.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Jagan Teki]

On Fri, May 26, 2017 at 10:22 PM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Fri, May 26, 2017 at 1:49 PM, Jagan Teki  wrote:
>
>> Yes, Pointed the same on cover-letter, I2C and PMIC combo not using
>> dts as of now since pmic area require driver-model conversion so these
>> are as-it-is.
>
> Ok, but we should not lose the PMIC functionality.
>
> It is fine if PMIC code stays in the board C file for now, but what I
> don't want is to have PMIC unsupported after your series gets applied.

No, PMIC and I2C are as it is like old code, I never did any
modification to use it for dts since driver require dm.

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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Fabio Estevam]

Hi Jagan,

On Fri, May 26, 2017 at 1:49 PM, Jagan Teki  wrote:

> Yes, Pointed the same on cover-letter, I2C and PMIC combo not using
> dts as of now since pmic area require driver-model conversion so these
> are as-it-is.

Ok, but we should not lose the PMIC functionality.

It is fine if PMIC code stays in the board C file for now, but what I
don't want is to have PMIC unsupported after your series gets applied.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH 00/12] Big work on sunxi DW DRAM controllers and some new DDR type support

[icenowy]

在 2017-04-27 15:09，Maxime Ripard 写道：

Hi,

On Wed, Apr 26, 2017 at 10:49:55PM +0800, Icenowy Zheng wrote:

This patchset contains several works on the sunxi DesignWare DRAM
controllers.

The 1st patch made an option for H3-like DRAM controllers
(DesignWare ones), which can ease further import of alike controllers.

The 2nd and 3rd patches are for supporting 16-bit DW DRAM controllers,
in order to add V3s DRAM support (The controller on V3s is 16-bit).

The 4th patch adds bank detection code, in order to support some DDR2
chips.

The 5th patch adds a framework for select DRAM type and timing -- it's
needed for boards that use DRAM chips rather than DDR3.

The 6th patch enables dual rank detection in the DW DRAM code on SoCs
except R40. For R40 the dual rank facility is still not so clear, so 
it's

temporarily disabled.

The 7th~9th patches enables support for DRAM initialization and SPL 
for

the V3s SoC, which integrates a DDR2 chip.

The 10th and 11th patches adds support for LPDDR3, with the stock 
boot0
timing. (Seen in A83T boot0 source and some leaked H5/R40 libdram 
source)


The 12th patches adds a defconfig for SoPine w/ official baseboard, 
which

utilizes LPDDR3.


All those changes looks good to me. I'll wait for Jens' review
however, since he knows that part much more than I do.


It seems that Jens haven't appeared for several months...

I grep'ed my local IRC log, and his latest appearance is in March.

After then he's still in the people list, however he haven't said
anything since March.

The IRC client of him seems to be running on a VPS, so it's always
online.

Jens, can you see this?



Thanks!
Maxime

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

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

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Jagan Teki]

On Fri, May 26, 2017 at 10:17 PM, Fabio Estevam  wrote:
> Hi Jagan,
>
> On Fri, May 26, 2017 at 1:41 PM, Jagan Teki  wrote:
>
>> Can you finalize this series, early to have better test.
>
> The issue I see with this series is that the 'pmic' commands are gone.
>
> Do you plan to fix it?

Yes, Pointed the same on cover-letter, I2C and PMIC combo not using
dts as of now since pmic area require driver-model conversion so these
are as-it-is.

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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Fabio Estevam]

Hi Jagan,

On Fri, May 26, 2017 at 1:41 PM, Jagan Teki  wrote:

> Can you finalize this series, early to have better test.

The issue I see with this series is that the 'pmic' commands are gone.

Do you plan to fix it?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] pico-imx7d: Add initial support

[Fabio Estevam]

Hi Stefano,

On Fri, May 26, 2017 at 1:44 PM, Stefano Babic  wrote:

> It is ok for me to apply the original patch and add DTS support in a
> follow-up patch. Let's do in this order.

Sounds good, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] pico-imx7d: Add initial support

[Stefano Babic]

On 26/05/2017 18:28, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Fri, May 19, 2017 at 12:49 PM, Vanessa Maegima
>  wrote:
>> Hi Stefano, Jagan,
>>
>> I have been trying to add the dts support for this board but I could not 
>> make Ethernet, I2C and PMIC support work using dts.
>>
>> I am still trying to add this support but I don't know how much time it can 
>> take. I'm new to U-Boot.
>>
>> Can you please consider applying the original patch?
> 
> Could you please comment?
> 

It is ok for me to apply the original patch and add DTS support in a
follow-up patch. Let's do in this order.

Regards,
Stefano


-- 
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v7 00/17] ARM: i.MX6: SabreSD: Add dts support

[Jagan Teki]

Hi Stefano/Fabio,

On Tue, May 23, 2017 at 1:28 PM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> Fabio, please add your changes on-top-of this series.
>
> Compared to previous series, this series
> - Removed 'Fabio' patch changes.
> - Droped DM_I2C and DM_PMIC, since power driver need to chage dm
> - Added phy-reset-gpio support for fec_mxc driver
> - Added Linux merge tag details on dts patches
>
> Changes for v6:
> - rebase on u-boot-imx/master
> - Droped DM_I2C and DM_PMIC changes
> - Added phy-reset-gpio support for fec_mxc driver
> - Added Linux merge tag details on dts patches
> - Removed 'Fabio' patch changes.
>
> Changes for v6:
> - rebase on u-boot-imx/master
> - Fixed comments from 'Fabio' in v5
> - Droped file/directory rename changes patches
> - Droped dm_gpio changes on board
>
> Changes for v5:
> - rebase on master
> - removed SPL support for i.MX6DL SabreSD
> - Add board_fit_config_name_match for SPL to fetch board dts
> - Add imx6qdl_sabresd_spl_defconfig for common SPL support
>
> Changes for v4:
> - rebase on master
> - Rename imx6[dl|q]_sabresd_spl_defconfig to imx6[dl|q]_sabresd_spl_defconfig
> - Update README
> - Move CONFIG_FEC_MXC to configs/mx6[dl|q|qp]sabreauto_defconfigs
> - Add dts support for non-spl based defconfigs
>
> Changes for v3:
> - rebase on master
> - Added patch 'ARM: i.MX6: sabresd: Cleanup board code'
> - Added patch 'ARM: i.MX6DL: sabresd: Move DCD reginit on SPL'
>
> Changes for v2:
> - rebase on master
> - Added new-patches.
>
> Jagan Teki (17):
>   ARM: i.MX6: sabresd: Remove SPL_I2C_SUPPORT
>   ARM: dts: i.MX6: Add imx6qdl-sabresd.dtsi
>   ARM: dts: i.MX6: Add imx6q-sabresd.dts
>   ARM: dts: i.MX6: Add imx6dl-sabresd.dts
>   ARM: dts: i.MX6: Add imx6qp.dtsi
>   ARM: dts: i.MX6: Add imx6qp-sabresd.dts
>   sabresd: i.MX6Q: Add initial dts support
>   sabresd: i.MX6QP: Add initial dts support
>   SabreSD: i.MX6DL: Add initial dts support
>   SabreSD: Move CONFIG_SYS_I2C_MXC to defconfigs
>   SabreSD: Enable CONFIG_DM_REGULATOR
>   SabreSD: Enable DM_USB
>   i.MX6: Sabre: Move CONFIG_FEC_MXC to defconfigs
>   net: fec_mxc: Add 'phy-reset-gpios' support
>   i.MX6: SabreSD: Enable DM_ETH
>   i.MX6: sabresd: Drop checkboard
>   i.MX6: SabreSD: Cleanup board code

Can you finalize this series, early to have better test.

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
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] pico-imx7d: Add initial support

[Jagan Teki]

On Fri, May 19, 2017 at 9:19 PM, Vanessa Maegima
 wrote:
> Hi Stefano, Jagan,
>
> I have been trying to add the dts support for this board but I could not
> make Ethernet, I2C and PMIC support work using dts.

Ethernet we can do with dts, just try on top of these patches [1]

For PMIC and I2C combo, we need to wait for pmic area to convert into
driver-model, till then just defined on board code instead of dts.

With dts, we can have
- DM_I2C (if not PMIC combo)
- DM_ETH
- DM_GPIO
- DM_MMC
- DM_THERMAL
- DM_USB

[1] https://patchwork.ozlabs.org/patch/765980/

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

Re: [U-Boot] [PATCH] pico-imx7d: Add initial support

[Fabio Estevam]

Hi Stefano,

On Fri, May 19, 2017 at 12:49 PM, Vanessa Maegima
 wrote:
> Hi Stefano, Jagan,
>
> I have been trying to add the dts support for this board but I could not make 
> Ethernet, I2C and PMIC support work using dts.
>
> I am still trying to add this support but I don't know how much time it can 
> take. I'm new to U-Boot.
>
> Can you please consider applying the original patch?

Could you please comment?

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

Re: [U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

On 26 May 2017 at 09:18, Tom Rini  wrote:
>
> On Wed, May 24, 2017 at 06:19:04PM -0600, Simon Glass wrote:
>
> > Hi Tom,
> >
> > This is the first two of the livetree series as well as some
> > driver-model adjustments for MMC.
> >
> > It's up to you if you want to take this now, or wait. I will send a
> > new version of the 3rd livetree series later by early next week and am
> > happy to do this all at once if you prefer. On the other hand I don't
> > want to miss RC1 if I can help it.
> >
> >
> > The following changes since commit be62fbf376261ab3a4ed5db3bf54d5df9e216d9f:
> >
> >   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2017-05-23
> > 16:22:03 -0400)
> >
> > are available in the git repository at:
> >
> >   git://git.denx.de/u-boot-dm.git
> >
> > for you to fetch changes up to 68dbdcb3cf8c59ab04b1b31d750fcee1e603e760:
> >
> >   sandbox: Move to use live tree (2017-05-24 14:18:23 -0600)
>
> I bisected a boot time failure:
> U-Boot SPL 2017.05-00797-g137396d6249b (May 26 2017 - 11:08:31)
> DRA722-GP ES1.0
> Trying to boot from MMC1
> *** Warning - No MMC card found, using default environment
>
> reading u-boot.img
> reading u-boot.img
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2017.05-00797-g137396d6249b (May 26 2017 - 11:08:31 -0400)
>
> CPU  : DRA722-GP ES1.0
> Model: TI DRA722
> Board: DRA72x EVM REV
> DRAM:  1 GiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> ### ERROR ### Please RESET the board ###

Where is this error coming from? Normally we would see the initcall
report a message. There are only a very few places where we can die
without a preceding message.

>
> down to:
>
> commit 8e8cb1b3dd28404fa6d8fed316867185673f43ea
> Author: Simon Glass 
> Date:   Wed May 17 17:18:09 2017 -0600
>
> dm: core: Replace of_offset with accessor (part 2)
>
> but don't quite know what would cause it to fail.

Me neither, although I have stared at the code pretty hard for a while.

Would it be possible for me to repeat this with beaglebone black?  I'm
not sure what board you are using here.

>
> --
> Tom

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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Tom Rini]

On Fri, May 26, 2017 at 02:58:04PM +0200, Jorge Ramirez Ortiz wrote:
> On May 26, 2017 2:46 PM, "Tom Rini"  wrote:
> 
> On Fri, May 26, 2017 at 09:28:28AM +0200, Jorge Ramirez wrote:
> > On 05/26/2017 12:08 AM, Tom Rini wrote:
> > >On Thu, May 25, 2017 at 11:16:42PM +0200, Jorge Ramirez wrote:
> > >>On 05/25/2017 11:12 PM, Tom Rini wrote:
> > >>>On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:
> > On 05/25/2017 10:55 PM, Jorge Ramirez wrote:
> > >On 05/25/2017 10:31 PM, Tom Rini wrote:
> > >>On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:
> > >>>On 05/18/2017 12:06 AM, Tom Rini wrote:
> > >>>having platform data.
> > >>No, I think we're going for overkill here by not doing
> > >>serial_pl01x.c as
> > >>platform data.  ns16550 does platform data for this already.
> This
> > >>sounds like the lowest overhead way to get the clock
> > >>populated and not
> > >>have some DT data that's not going to be accepted upstream.
> > >>
> > >u I am a bit lost at this point, could we recap please?
> > Lets update the recap:
> > - Please re-submit the dts file, now with whatever form is
> > in v4.12-rc1,
> >    saying as such in the commit (if it's just the commit message
> that
> >    changes, that's fine and great).
> > >>>The DTS file in v4.12-rc2 still does NOT contain the usb node.
> > >>>
> > >>>==> Should I then not use the DM on USB so I can avoid DTS changes?
> > >>Well, you can either put it in the -u-boot.dtsi file for the board,
> and
> > >>remove that later once it's upstream.
> > yes I'll do that. thanks.
> > 
> > - Please update serial_pl01x.c to be able to get the clock
> > via platform
> >    data, update and test your board to confirm it works.
> > >>>um, It gets tricky;
> > >>>I can not use platform_data since I can not use SERIAL_DM because
> > >>>the device tree does have a UART node which gets picked up.
> > >>How about disabling the node in -u-boot.dtsi for the board and then
> you
> > >>can use platform data,
> > I dont think that would because CONFIG_OF is enabled for USB; so the
> > kernel dtsi that contains the uart node (without the clock!) will be
> > picked by u-boot and the uart will not be initialized properly.
> > I still think that the simplest solution is to let me merge with the
> > kernel's device tree plus this u-boot.dtsi [1];
> > then just get rid of the file when possible (and NEIHER the source
> > code NOR the configs) would need to change
> > 
> > [1] https://github.com/ldts/poplar-u-boot/blob/upstream/
> arch/arm/dts/hi3798cv200-u-boot.dtsi
> > >>>Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
> > >>>use platform data, at least for now.  I do want to talk more with Rob
> > >>>about the general problem this exposes.
> > >>so you want me to
> > >>
> > >>1) keep the node in https://github.com/ldts/poplar-u-boot/blob/upstream/
> arch/arm/dts/hi3798cv200-u-boot.dtsi
> > >Well, a uart0 node, but no "clock" property as that just needs to go
> > >away.
> >
> > Sounds good to me. now see below
> >
> > >>2) add status=disable
> > >>3) then add the platform_data
> > >>
> > >>BUT for the pl011 driver to take the platform_data dont I also have
> > >>to disable CONFIG_OF?
> > >>
> > >>but  if I disable CONFIG_OF then I lose USB_DM
> > >No, the status = "disable" on uart0 should remove it from the dtb, or at
> > >least we should see it and go "Oh, no, we don't have uart0 via DT".
> >
> > 1) Since the UART0 is enabled in the kernel's DTS I will have to
> > modify the device tree that I am importing from kernel.org to
> > disable it.
> 
> Yes, the dtsi file in [1] is what modifies it.
> 
> > 2) But even doing this is not enough: I have to completely remove
> > the uart0 node from the tree.
> 
> Why?  Is this in theory, or in practice?  I ask since we just had to
> disable the kernel-enabled mmc3 node on am335x-evm.dts in
> am335x-evm-u-boot.dtsi in order to have it boot as probing mmc3 in
> U-Boot fails (we don't enable the relevant clocks).  So disabling uart0
> should cause the resulting dtb file to omit entirely, or just have
>  {status="disabled"} or similar and U-Boot should not do anything,
> so platform data should be used.  If this is not the case, there's a bug
> we need to track down.
> 
> >
> >
> > So to sum up:
> >
> > In order to get the platform data for pl01x I have to either disable
> > OF (so I lose the USB node as I said earlier) or *completely* remove
> > the UART0 node from from the kernel dts.
> > I personally would rather not modify the kernel's DTS trees that I
> > am importing into uboot but I am really confused about the policy
> > now.
> >
> > please could you clarify?
> >
> > I still think what I proposed when we started is the better way to
> > go: a uboot 

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Wed, May 24, 2017 at 06:19:04PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> This is the first two of the livetree series as well as some
> driver-model adjustments for MMC.
> 
> It's up to you if you want to take this now, or wait. I will send a
> new version of the 3rd livetree series later by early next week and am
> happy to do this all at once if you prefer. On the other hand I don't
> want to miss RC1 if I can help it.
> 
> 
> The following changes since commit be62fbf376261ab3a4ed5db3bf54d5df9e216d9f:
> 
>   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2017-05-23
> 16:22:03 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-dm.git
> 
> for you to fetch changes up to 68dbdcb3cf8c59ab04b1b31d750fcee1e603e760:
> 
>   sandbox: Move to use live tree (2017-05-24 14:18:23 -0600)

I bisected a boot time failure:
U-Boot SPL 2017.05-00797-g137396d6249b (May 26 2017 - 11:08:31)
DRA722-GP ES1.0
Trying to boot from MMC1
*** Warning - No MMC card found, using default environment

reading u-boot.img
reading u-boot.img
reading u-boot.img
reading u-boot.img


U-Boot 2017.05-00797-g137396d6249b (May 26 2017 - 11:08:31 -0400)

CPU  : DRA722-GP ES1.0
Model: TI DRA722
Board: DRA72x EVM REV
DRAM:  1 GiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
### ERROR ### Please RESET the board ###

down to:

commit 8e8cb1b3dd28404fa6d8fed316867185673f43ea
Author: Simon Glass 
Date:   Wed May 17 17:18:09 2017 -0600

dm: core: Replace of_offset with accessor (part 2)

but don't quite know what would cause it to fail.

-- 
Tom


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

Re: [U-Boot] [PATCH] sun50i: a64: Add initial Banana Pi M64 support

[Andre Przywara]

Hi,

seems like you beat me to that, I had as similar patch ready, but wanted
to wait for the A64 DTS update to be accepted (and merged).
It looks like you depend on that as well?

On 26/05/17 10:21, Jagan Teki wrote:
> From: Jagan Teki 
> 
> BPI-M64 is a 64-bit quad-core mini single board computer
> using the Allwinner A64 SOC.
> 
> BPI-M64 features
> - 1.2 Ghz Quad-Core ARM Cortex A53
> - 2GB DDR3 SDRAM with 733MHz
> - MicroSD/eMMC(8GB)
> - 10/100/1000Mbps ethernet (Realtek RTL8211E/D)

By using the below approach and depending on the updated DT you will
loose Ethernet access. You will need to copy and adjust the -u-boot.dtsi
file from the Pine64 Plus.
However we might want to wait if there is another solution short from
having a bunch of virtually identical -u-boot.dtsi files for every
board. If someone (Tom?) comes up with a way of allowing multiple,
possibly shared .dtsi files, we can simplify this whole thing.

> - Wifi + BT
> - IR receiver
> - Audio In/Out
> - Video In/Out
> - 5V 2A DC power-supply
> 
> For dts file,
> Sync with Linux commit 4879b7ae("Merge tag 'dmaengine-4.12-rc1'").
> 
> Signed-off-by: Jagan Teki 
> ---
> Note: Not tested yet, board is on-the-way to reach.

You should be very careful with that ;-)

>  arch/arm/dts/Makefile|   1 +
>  arch/arm/dts/sun50i-a64-bananapi-m64.dts | 114 
> +++
>  board/sunxi/MAINTAINERS  |   5 ++
>  configs/bananapi_m64_defconfig   |  16 +
>  4 files changed, 136 insertions(+)
>  create mode 100644 arch/arm/dts/sun50i-a64-bananapi-m64.dts
>  create mode 100644 configs/bananapi_m64_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a59395b..242b329 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -319,6 +319,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
>   sun50i-h5-orangepi-prime.dtb \
>   sun50i-h5-orangepi-zero-plus2.dtb
>  dtb-$(CONFIG_MACH_SUN50I) += \
> + sun50i-a64-bananapi-m64.dtb \
>   sun50i-a64-orangepi-win.dtb \
>   sun50i-a64-pine64-plus.dtb \
>   sun50i-a64-pine64.dtb
> diff --git a/arch/arm/dts/sun50i-a64-bananapi-m64.dts 
> b/arch/arm/dts/sun50i-a64-bananapi-m64.dts
> new file mode 100644
> index 000..9001812
> --- /dev/null
> +++ b/arch/arm/dts/sun50i-a64-bananapi-m64.dts
> @@ -0,0 +1,114 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + * Copyright (C) 2017 Jagan Teki 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "BananaPi-M64";
> + compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> +   

Re: [U-Boot] [PATCH v6 0/6] Add Intel Arria 10 SoC FPGA driver

[Dinh Nguyen]

On 05/26/2017 03:48 AM, Chee, Tien Fong wrote:

>>
>> So the patch for using CONFIG_SPL_FPGA_SUPPORT is causing this build
>> error. Please investigate.
>>
>> Dinh
> 
> Hi Dinh,
> 
> I have tried with both u-boot.git and u-boot-socfpga.git lastest
> version, i can't still reproduce the issue u have seen :(. Would you
> mind to share me the details of the step to reproduce it such as on
> what branch?
> 

Ah, sorry about that. I went back and just did a batch apply of all 6
patches, and it builds fine.

I was hitting the build error because I missed applying patch 4/6 "arm:
socfpga: Enable FPGA driver build on SPL"

The reason I missed this was because the 3/6 patch was named "arm:
socfpga: Enable FPGA driver on SPL".

So can you please go back and edit the commit header of patch 4/6, to
something more generic? As its not ARM or SOCFPGA specific.

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

Re: [U-Boot] [PATCH v2 1/2] rockchip: Add basic support for phyCORE-RK3288 SoM based carrier board

[Wadim Egorov]

Hello Simon,


Am 24.05.2017 um 02:44 schrieb Simon Glass:
> Hi Wadim,
>
> On 15 May 2017 at 08:19, Wadim Egorov  wrote:
>> The phyCORE-RK3288 is a SoM (System on Module) containing a RK3288 SoC.
>> The module can be connected to different carrier boards.
>> It can be also equipped with different RAM, SPI flash and eMMC variants.
>> The Rapid Development Kit option is using the following setup:
>>
>>   - 1 GB DDR3 RAM (2 Banks)
>>   - 1x 4 KB EEPROM
>>   - DP83867 Gigabit Ethernet PHY
>>   - 16 MB SPI Flash
>>   - 4 GB eMMC Flash
>>
>> Add basic support for the PCM-947 carrier board, a RK3288 based development
>> board made by PHYTEC. This board works in a combination with
>> the phyCORE-RK3288 System on Module.
>>
>> Signed-off-by: Wadim Egorov 
>> Reviewed-by: Simon Glass 
>> ---
>> Changes in v2:
>> - Move phycore initialization to an own function
>> - Use of_machine_is_compatible() instead of #ifdef
>> - Drop board_boot_order() and use spl_boot_device()
>> - Added Reviewed-by: Simon Glass 
>>
>> ---
>>  arch/arm/dts/Makefile|   1 +
>>  arch/arm/dts/rk3288-phycore-rdk.dts  | 294 
>>  arch/arm/dts/rk3288-phycore-som.dtsi | 503 
>> +++
>>  arch/arm/mach-rockchip/rk3288-board-spl.c|  37 ++
>>  arch/arm/mach-rockchip/rk3288/Kconfig|  10 +
>>  board/phytec/phycore_rk3288/Kconfig  |  15 +
>>  board/phytec/phycore_rk3288/MAINTAINERS  |   6 +
>>  board/phytec/phycore_rk3288/Makefile |   8 +
>>  board/phytec/phycore_rk3288/phycore-rk3288.c |   8 +
>>  configs/phycore-rk3288_defconfig |  69 
>>  include/configs/phycore_rk3288.h |  23 ++
>>  11 files changed, 974 insertions(+)
>>  create mode 100644 arch/arm/dts/rk3288-phycore-rdk.dts
>>  create mode 100644 arch/arm/dts/rk3288-phycore-som.dtsi
>>  create mode 100644 board/phytec/phycore_rk3288/Kconfig
>>  create mode 100644 board/phytec/phycore_rk3288/MAINTAINERS
>>  create mode 100644 board/phytec/phycore_rk3288/Makefile
>>  create mode 100644 board/phytec/phycore_rk3288/phycore-rk3288.c
>>  create mode 100644 configs/phycore-rk3288_defconfig
>>  create mode 100644 include/configs/phycore_rk3288.h
> This unfortunately causes build errors on various rockchip boards.

This seems to be a problem because I am using of_machine_is_compatible().
I think we will need a CONFIG_TARGET_PHYCORE_RK3288 guard there.

>
> Try 'buildman rockchip' to see it.
>
> Please see below.
>
> [...]
>
>> diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c 
>> b/arch/arm/mach-rockchip/rk3288-board-spl.c
>> index 74f3379..724dcb4 100644
>> --- a/arch/arm/mach-rockchip/rk3288-board-spl.c
>> +++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
>> @@ -8,6 +8,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -25,6 +26,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  DECLARE_GLOBAL_DATA_PTR;
>>
>> @@ -157,6 +159,38 @@ static int configure_emmc(struct udevice *pinctrl)
>>  }
>>  #endif
>>
>> +void phycore_init(void)
>> +{
>> +   struct udevice *dev;
>> +   uint reg;
>> +   int ret;
>> +
>> +   ret = uclass_get_device(UCLASS_I2C, 0, );
>> +   if (ret) {
>> +   debug("I2C init failed: %d\n", ret);
>> +   return;
>> +   }
>> +
>> +   ret = i2c_get_chip(dev, 0x1c, 1, );
> We should not be hard-coding the bus address here.
>
> See veyron_init() for an example of another way to do this.
>
>> +   if (ret) {
>> +   debug("Cannot find RK818: %d\n", ret);
>> +   return;
>> +   }
>> +
>> +   reg = dm_i2c_reg_read(dev, REG_USB_CTRL);
>> +
>> +   /*
>> +* Increase USB input current selection to 2A and close charger
>> +* when usb lower then 3.4V.
>> +*/
>> +   reg |= 0x77;
>> +   ret = dm_i2c_reg_write(dev, REG_USB_CTRL, reg);
> Here you are hacking registers in the PMIC. This should go in the PMIC
> driver. See rk8xx_spl_configure_buck() for how to do this in SPL
> without bringing in the whole regulator framework.

For this I have to enable CONFIG_SPL_POWER_SUPPORT to get the pmic part
compiled.
Unfortunately, I am not able to boot my board with POWER_SUPPORT
enabled, because the dm_init_and_scan() function which is called from
spl_early_init() is failing.
Do you have any hints on what the problem could be?

Regards,
Wadim

>
>> +   if (ret) {
>> +   debug("Unable to set RK818 REG_USB_CTRL: %d\n", ret);
>> +   return;
>> +   }
>> +}
>> +
> Regards,
> Simon

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

Re: [U-Boot] i.Mx6q u-boot stuck

[Fausto Sessego]

Hi Fabio,

i tried both solutions without any output.



--
*Ing. Fausto Sessego*
*R Hardware & Software Engineer*

info
mob
>
*Tecnologie Wireless per la logistica e la sicurezza*
*address:* Parco scientifico e tecnologico della Sardegna, Edificio 1 Loc.
Piscinamanna - 09010 Pula (CA)

*phone:* +39 070 92432952
*email:* fausto.sess...@infomob.it
*skype:* fausto.sessego.infomob
*web:* www.infomob.it

2017-05-26 14:36 GMT+02:00 Fabio Estevam :

> Hi Fausto,
>
> On Fri, May 26, 2017 at 7:39 AM, Fausto Sessego  > wrote:
>
>>
>>
>> #define CONFIG_BOOTCOMMAND \
>> "run mmcargs; " \
>> "run loadfdt; " \
>> "run loadimage; " \
>> "bootz ${loadaddr} - ${fdt_addr}; "\
>>
>
> The bootz command expects a zImage type of kernel.
>
> In your previous message you were passing uImage, so what you should do is:
>
> 1.Pass a zImage and use it with bootz
>
> or
>
> 2. Pass a uImage and use it with bootm.
>
> Hope this helps.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez Ortiz]

On May 26, 2017 2:46 PM, "Tom Rini"  wrote:

On Fri, May 26, 2017 at 09:28:28AM +0200, Jorge Ramirez wrote:
> On 05/26/2017 12:08 AM, Tom Rini wrote:
> >On Thu, May 25, 2017 at 11:16:42PM +0200, Jorge Ramirez wrote:
> >>On 05/25/2017 11:12 PM, Tom Rini wrote:
> >>>On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:
> On 05/25/2017 10:55 PM, Jorge Ramirez wrote:
> >On 05/25/2017 10:31 PM, Tom Rini wrote:
> >>On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:
> >>>On 05/18/2017 12:06 AM, Tom Rini wrote:
> >>>having platform data.
> >>No, I think we're going for overkill here by not doing
> >>serial_pl01x.c as
> >>platform data.  ns16550 does platform data for this already.
This
> >>sounds like the lowest overhead way to get the clock
> >>populated and not
> >>have some DT data that's not going to be accepted upstream.
> >>
> >u I am a bit lost at this point, could we recap please?
> Lets update the recap:
> - Please re-submit the dts file, now with whatever form is
> in v4.12-rc1,
>    saying as such in the commit (if it's just the commit message
that
>    changes, that's fine and great).
> >>>The DTS file in v4.12-rc2 still does NOT contain the usb node.
> >>>
> >>>==> Should I then not use the DM on USB so I can avoid DTS changes?
> >>Well, you can either put it in the -u-boot.dtsi file for the board,
and
> >>remove that later once it's upstream.
> yes I'll do that. thanks.
> 
> - Please update serial_pl01x.c to be able to get the clock
> via platform
>    data, update and test your board to confirm it works.
> >>>um, It gets tricky;
> >>>I can not use platform_data since I can not use SERIAL_DM because
> >>>the device tree does have a UART node which gets picked up.
> >>How about disabling the node in -u-boot.dtsi for the board and then
you
> >>can use platform data,
> I dont think that would because CONFIG_OF is enabled for USB; so the
> kernel dtsi that contains the uart node (without the clock!) will be
> picked by u-boot and the uart will not be initialized properly.
> I still think that the simplest solution is to let me merge with the
> kernel's device tree plus this u-boot.dtsi [1];
> then just get rid of the file when possible (and NEIHER the source
> code NOR the configs) would need to change
> 
> [1] https://github.com/ldts/poplar-u-boot/blob/upstream/
arch/arm/dts/hi3798cv200-u-boot.dtsi
> >>>Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
> >>>use platform data, at least for now.  I do want to talk more with Rob
> >>>about the general problem this exposes.
> >>so you want me to
> >>
> >>1) keep the node in https://github.com/ldts/poplar-u-boot/blob/upstream/
arch/arm/dts/hi3798cv200-u-boot.dtsi
> >Well, a uart0 node, but no "clock" property as that just needs to go
> >away.
>
> Sounds good to me. now see below
>
> >>2) add status=disable
> >>3) then add the platform_data
> >>
> >>BUT for the pl011 driver to take the platform_data dont I also have
> >>to disable CONFIG_OF?
> >>
> >>but  if I disable CONFIG_OF then I lose USB_DM
> >No, the status = "disable" on uart0 should remove it from the dtb, or at
> >least we should see it and go "Oh, no, we don't have uart0 via DT".
>
> 1) Since the UART0 is enabled in the kernel's DTS I will have to
> modify the device tree that I am importing from kernel.org to
> disable it.

Yes, the dtsi file in [1] is what modifies it.

> 2) But even doing this is not enough: I have to completely remove
> the uart0 node from the tree.

Why?  Is this in theory, or in practice?  I ask since we just had to
disable the kernel-enabled mmc3 node on am335x-evm.dts in
am335x-evm-u-boot.dtsi in order to have it boot as probing mmc3 in
U-Boot fails (we don't enable the relevant clocks).  So disabling uart0
should cause the resulting dtb file to omit entirely, or just have
 {status="disabled"} or similar and U-Boot should not do anything,
so platform data should be used.  If this is not the case, there's a bug
we need to track down.

>
>
> So to sum up:
>
> In order to get the platform data for pl01x I have to either disable
> OF (so I lose the USB node as I said earlier) or *completely* remove
> the UART0 node from from the kernel dts.
> I personally would rather not modify the kernel's DTS trees that I
> am importing into uboot but I am really confused about the policy
> now.
>
> please could you clarify?
>
> I still think what I proposed when we started is the better way to
> go: a uboot specific hi3798cv200-u-boot.dtsifile that contains the
> two nodes that are giving trouble.

I don't understand what we're not understanding, yes, you should be
using a -u-boot.dtsi file to mark uart0 as disabled and not have to
modify the kernel dts file at all.



This the bit that is NOT 

Re: [U-Boot] Please pull u-boot-fdt, take 2

[Tom Rini]

On Thu, May 25, 2017 at 09:15:33PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On 25 May 2017 at 11:42, Tom Rini  wrote:
> > On Thu, May 25, 2017 at 11:27:10AM -0600, Simon Glass wrote:
> >> Hi Tom,
> >>
> >> On 25 May 2017 at 05:19, Tom Rini  wrote:
> >> >
> >> > On Wed, May 24, 2017 at 06:15:25PM -0600, Simon Glass wrote:
> >> >
> >> > > Hi Tom,
> >> > >
> >> > > This incorporates the v2 patch for 'fdt: Build the new python libfdt
> >> > > module' which should fix the problem with the original pull request.
> >> > >
> >> > >
> >> > > The following changes since commit 
> >> > > be62fbf376261ab3a4ed5db3bf54d5df9e216d9f:
> >> > >
> >> > >   Merge branch 'rmobile' of git://git.denx.de/u-boot-sh (2017-05-23
> >> > > 16:22:03 -0400)
> >> > >
> >> > > are available in the git repository at:
> >> > >
> >> > >   git://git.denx.de/u-boot-fdt.git
> >> > >
> >> > > for you to fetch changes up to 
> >> > > da9c601049eb7c993c7f6e33ae10af7a847a483d:
> >> > >
> >> > >   fdt: Drop fdt_select.py (2017-05-24 18:12:31 -0600)
> >> >
> >> > NAK.  travis-ci blows up quite badly:
> >> > https://travis-ci.org/trini/u-boot/builds/235861889
> >>
> >> I'm not sure how to repeat this problem. When I try this:
> >
> > Your best bet is likely:
> > https://docs.travis-ci.com/user/common-build-problems/#Troubleshooting-Locally-in-a-Docker-Image
> 
> Sadly still no luck. I installed this one:
> 
> travisci/ci-garnet:packer-1478744932
> 
> It includes python-dev but not swig, so should not be able to build
> the module. As expected I get this error:
> 
> NO_SDL=1 ./tools/buildman/buildman -P sandbox_spl
> boards.cfg is up to date. Nothing to do.
> Building current source for 1 boards (1 thread, 8 jobs per thread)
>sandbox:  +   sandbox_spl
> +Traceback (most recent call last):
> +  File "", line 1, in 
> +ImportError: No module named libfdt
> +make[2]: *** [checkdtoc] Error 1
> +make[1]: *** [spl/u-boot-spl] Error 2
> +make: *** [sub-make] Error 2
> 
> 
> If I install swig then all is well. I don't see the same error.
> 
> I'm also unsure how you get it to pass with some boards but not others...
> 
> There is obviously something odd going on. I also cannot understand
> why in this one:
> 
> https://travis-ci.org/trini/u-boot/jobs/235861899#L769
> 
> I see it trying to compile libfdt_wrap.c. That should be handled by
> setup.py - I just cannot figure out why it would try to compile it
> itself:
> 
>   arm:  +  mx6sabresd_spl
> +mv: cannot stat lib/libfdt/pylibfdt/libfdt.py: No such file or directory
> +make[2]: *** [tools/_libfdt.so] Error 1
> +make[1]: *** [tools] Error 2
> +make: *** [sub-make] Error 2
>   arm:  +  ls1021aqds_nor_lpuart
> +x86_64-linux-gnu-gcc: error: lib/libfdt/pylibfdt/libfdt_wrap.c: No
> such file or directory
> +x86_64-linux-gnu-gcc: fatal error: no input files
> +compilation terminated.
> +error: command 'x86_64-linux-gnu-gcc' failed with exit status 4
> +make[2]: *** [tools/_libfdt.so] Error 1
> +make[1]: *** [tools] Error 2
> +make: *** [sub-make] Error 2
>   arm:  +  mx6slevk
> +x86_64-linux-gnu-gcc: error: lib/libfdt/pylibfdt/libfdt_wrap.c: No
> such file or directory
> +x86_64-linux-gnu-gcc: fatal error: no input files
> +compilation terminated.
> +error: command 'x86_64-linux-gnu-gcc' failed with exit status 4
> +make[2]: *** [tools/_libfdt.so] Error 1
> +make[1]: *** [tools] Error 2
> +make: *** [sub-make] Error 2
>   5503 /58 mx6qsabreauto
> boards.cfg is up to date. Nothing to do.
> Summary of current source for 58 boards (2 threads, 1 job per thread)
>   arm:  +  mx6sabresd_spl ls1021aqds_nor_lpuart mx6slevk
> +mv: cannot stat lib/libfdt/pylibfdt/libfdt.py: No such file or directory
> 
> 
> Are you able to run with V=1 to get the full make output? That might
> help me narrow it down. Or, if you have a particular docket image,
> please point me to it. There seems to be some init going on though
> (e.g. /tmp/dtc).

Anyone can use travis-ci :)  In the past I've had some luck debugging
these issues (since I didn't want to mess with docker) by hacking up the
.travis.yml file to just have a single matrix entry for whatever I was
debugging and hack things as needed, including 'cat'ing files.

-- 
Tom


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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Tom Rini]

On Fri, May 26, 2017 at 09:28:28AM +0200, Jorge Ramirez wrote:
> On 05/26/2017 12:08 AM, Tom Rini wrote:
> >On Thu, May 25, 2017 at 11:16:42PM +0200, Jorge Ramirez wrote:
> >>On 05/25/2017 11:12 PM, Tom Rini wrote:
> >>>On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:
> On 05/25/2017 10:55 PM, Jorge Ramirez wrote:
> >On 05/25/2017 10:31 PM, Tom Rini wrote:
> >>On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:
> >>>On 05/18/2017 12:06 AM, Tom Rini wrote:
> >>>having platform data.
> >>No, I think we're going for overkill here by not doing
> >>serial_pl01x.c as
> >>platform data.  ns16550 does platform data for this already.  This
> >>sounds like the lowest overhead way to get the clock
> >>populated and not
> >>have some DT data that's not going to be accepted upstream.
> >>
> >u I am a bit lost at this point, could we recap please?
> Lets update the recap:
> - Please re-submit the dts file, now with whatever form is
> in v4.12-rc1,
>    saying as such in the commit (if it's just the commit message that
>    changes, that's fine and great).
> >>>The DTS file in v4.12-rc2 still does NOT contain the usb node.
> >>>
> >>>==> Should I then not use the DM on USB so I can avoid DTS changes?
> >>Well, you can either put it in the -u-boot.dtsi file for the board, and
> >>remove that later once it's upstream.
> yes I'll do that. thanks.
> 
> - Please update serial_pl01x.c to be able to get the clock
> via platform
>    data, update and test your board to confirm it works.
> >>>um, It gets tricky;
> >>>I can not use platform_data since I can not use SERIAL_DM because
> >>>the device tree does have a UART node which gets picked up.
> >>How about disabling the node in -u-boot.dtsi for the board and then you
> >>can use platform data,
> I dont think that would because CONFIG_OF is enabled for USB; so the
> kernel dtsi that contains the uart node (without the clock!) will be
> picked by u-boot and the uart will not be initialized properly.
> I still think that the simplest solution is to let me merge with the
> kernel's device tree plus this u-boot.dtsi [1];
> then just get rid of the file when possible (and NEIHER the source
> code NOR the configs) would need to change
> 
> [1] 
> https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi
> >>>Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
> >>>use platform data, at least for now.  I do want to talk more with Rob
> >>>about the general problem this exposes.
> >>so you want me to
> >>
> >>1) keep the node in 
> >>https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi
> >Well, a uart0 node, but no "clock" property as that just needs to go
> >away.
> 
> Sounds good to me. now see below
> 
> >>2) add status=disable
> >>3) then add the platform_data
> >>
> >>BUT for the pl011 driver to take the platform_data dont I also have
> >>to disable CONFIG_OF?
> >>
> >>but  if I disable CONFIG_OF then I lose USB_DM
> >No, the status = "disable" on uart0 should remove it from the dtb, or at
> >least we should see it and go "Oh, no, we don't have uart0 via DT".
> 
> 1) Since the UART0 is enabled in the kernel's DTS I will have to
> modify the device tree that I am importing from kernel.org to
> disable it.

Yes, the dtsi file in [1] is what modifies it.

> 2) But even doing this is not enough: I have to completely remove
> the uart0 node from the tree.

Why?  Is this in theory, or in practice?  I ask since we just had to
disable the kernel-enabled mmc3 node on am335x-evm.dts in
am335x-evm-u-boot.dtsi in order to have it boot as probing mmc3 in
U-Boot fails (we don't enable the relevant clocks).  So disabling uart0
should cause the resulting dtb file to omit entirely, or just have
 {status="disabled"} or similar and U-Boot should not do anything,
so platform data should be used.  If this is not the case, there's a bug
we need to track down.

> 
> 
> So to sum up:
> 
> In order to get the platform data for pl01x I have to either disable
> OF (so I lose the USB node as I said earlier) or *completely* remove
> the UART0 node from from the kernel dts.
> I personally would rather not modify the kernel's DTS trees that I
> am importing into uboot but I am really confused about the policy
> now.
> 
> please could you clarify?
> 
> I still think what I proposed when we started is the better way to
> go: a uboot specific hi3798cv200-u-boot.dtsifile that contains the
> two nodes that are giving trouble.

I don't understand what we're not understanding, yes, you should be
using a -u-boot.dtsi file to mark uart0 as disabled and not have to
modify the kernel dts file at all.

-- 
Tom


signature.asc
Description: Digital signature

Re: [U-Boot] [PATCH 3/3] rename GPT partitions to detect boot failure

[Tom Rini]

On Sat, May 20, 2017 at 07:27:55PM -0700, ali...@peloton-tech.com wrote:

> From: Alison Chaiken 
> 
> This patch provides support in u-boot for renaming GPT
> partitions.  The renaming is accomplished via a new 'gpt flip'
> command.
[snip]
> Signed-off-by: Alison Chaiken 
> ---
>  cmd/gpt.c | 207 
> --
>  1 file changed, 201 insertions(+), 6 deletions(-)

There's some whitespace-only chunks, please drop.  Also:

[snip]
> +/* ONEMIB is 2**20 */
> +#define ONEMIB 1024*1024

SZ_1MB from 

> +/*
> + * The number '33' comes from the '32' in the definition of disk_partition_t
> + * in include/part.h.   That file has '37' rather than UUID_STR_LEN + 1, from
> + * include/uuid.h
> + */

Lets update include/part.h in a new patch earlier in the series,
possibly as part of addressing the problems I mention with the previous
patch.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/3] GPT: read partition table from device into a data structure

[Tom Rini]

On Sat, May 20, 2017 at 07:27:54PM -0700, ali...@peloton-tech.com wrote:

> From: Alison Chaiken 
> 
> Make the partition table available for modification by reading it from
> the user-specified device into a linked list.   Provide an accessor
> function for command-line testing.
> 
> Signed-off-by: Alison Chaiken 
[snip]
> + /*
> +  * 33 rather than 32, as each string must be null-terminated;
> +  * other extract_val() above will fail.
> +  */
> + strncpy((char *)newpart->gpt_part_info.name, (const char *)info->name, 
> 33);
> + strncpy((char *)newpart->gpt_part_info.type, (const char *)info->type, 
> 33);

This isn't right.  We have name[32]/type[32] so we're overflowing.  I'm
not quite sure where 32 came from and if we should be defining a name
for it as well.  But to make sure it is null-terminated we should be
here memset'ing after malloc.

> + newpart->gpt_part_info.bootable = info->bootable;
> +#ifdef CONFIG_PARTITION_UUIDS
> + strncpy(newpart->gpt_part_info.uuid, (const char *)info->uuid,
> + UUID_STR_LEN + 1);
> +#endif

Then this should just be copying UUID_STR_LEN over.

> + if (!valid_parts) {
> + printf("** No valid partitions found **\n");
> + del_gpt_info();
> + return -1;

We should return something from errno here rather than -1.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 1/3] GPT: add accessor function for disk GUID

[Tom Rini]

On Sat, May 20, 2017 at 07:27:53PM -0700, ali...@peloton-tech.com wrote:

> From: Alison Chaiken 
> 
> In order to read the GPT, modify the partition name strings, and then
> write out a new GPT, the disk GUID is needed.  While there is an
> existing accessor for the partition UUIDs, there is none yet for the
> disk GUID.
> 
> Signed-off-by: Alison Chaiken 

Overall looks good, a few style things:

> + if (namestr != NULL)
> + setenv(namestr, disk_guid);

You can just if (namestr) here

[snip]
> + } else if (strcmp(argv[1], "guid") == 0) {
> + if (argc == 5) strcpy(varname, argv[4]);

Go ahead and do this on multiple lines please.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 0/3] add support for GPT partition name manipulation

[Tom Rini]

On Sat, May 20, 2017 at 07:27:52PM -0700, ali...@peloton-tech.com wrote:

> From: Alison Chaiken 
> 
> One way for userspace and the bootloader to exchange information about
> dynamic image selection is via the storage device partition table, as
> described at
> 
> https://source.android.com/devices/tech/ota/ab_updates
> 
> The scheme described there relies on setting partitions' "boot" flag.
> When no partition on a device is bootable since the kernel and U-Boot
> are stored elsewhere, the name field in the GPT partition table offers
> another logical place to store information.  These patches allow users
> to easily modify GPT partition names via bootscripts that can select
> different images based on a boot-failure counter, or when userspace
> installs a software update.
> 
> These patches have been tested on a TI DRA7xx-based SOM with U-Boot
> 2015.07.  The storage device is an eMMC.
> 
> Alison Chaiken (3):
>   GPT: add accessor function for disk GUID
>   GPT: read partition table from device into a data structure
>   rename GPT partitions to detect boot failure
> 
>  cmd/gpt.c   | 339 
> +++-
>  disk/part_efi.c |  31 ++
>  include/part.h  |  24 
>  3 files changed, 392 insertions(+), 2 deletions(-)

Interesting.  Adding Lukasz for comments as well.  I was thinking
perhaps the final patch in the series might want to be guarded with some
Kconfig option as it's rather specific to this update mechanism and
probably causes a noticeable size increase due to the strings.  Thanks!

-- 
Tom


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

Re: [U-Boot] i.Mx6q u-boot stuck

[Fabio Estevam]

Hi Fausto,

On Fri, May 26, 2017 at 7:39 AM, Fausto Sessego 
wrote:

>
>
> #define CONFIG_BOOTCOMMAND \
> "run mmcargs; " \
> "run loadfdt; " \
> "run loadimage; " \
> "bootz ${loadaddr} - ${fdt_addr}; "\
>

The bootz command expects a zImage type of kernel.

In your previous message you were passing uImage, so what you should do is:

1.Pass a zImage and use it with bootz

or

2. Pass a uImage and use it with bootm.

Hope this helps.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] i.Mx6q u-boot stuck

[Lothar Waßmann]

Fausto Sessego  wrote:

> Hi,
> 
> here you are my configuration:
> 
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "image=zImage\0" \
> "console=" CONFIG_CONSOLE_DEV "\0" \
> "fdt_file=imx6q-tibidabo.dtb\0" \
> "fdt_addr=0x1400\0" \
> "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
> "mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
> "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
> "mmcautodetect=yes\0" \
> "mmcargs=setenv bootargs console=${console},${baudrate} earlyprintk " \
> "root=${mmcroot}\0" \
> "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
> "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
> 
> 
> #define CONFIG_BOOTCOMMAND \
> "run mmcargs; " \
> "run loadfdt; " \
> "run loadimage; " \
> "bootz ${loadaddr} - ${fdt_addr}; "\
> 
> it is easy.
> 
> I tried to put earlyprintk but i didn't see any output.
> 
> 
Please do not top-post! (put your own comments _after_ the quoted
portion of the original mail you are responding to just like everyone
else on this mailing list).

Your SDRAM size is 2GiB. That means U-Boot will relocate the FDT
outside reach for the kernel. Try setting 'fdt_high=0x' (or
${fdt_addr}), to prevent U-Boot from relocating the FDT.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: mx6: remove unused config variable CONFIG_SPL_NAND_MXS

[Jagan Teki]

On Fri, May 26, 2017 at 1:42 PM, Lothar Waßmann  
wrote:
> The config variable CONFIG_SPL_NAND_MXS is only set in
> include/configs/imx6_spl.h but used nowhere.
> Remove it.
>
> Signed-off-by: Lothar Waßmann 

Reviewed-by: Jagan Teki 

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
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3] arm64: ls1043ardb: Add distro boot support

[Shengzhou Liu]

Include common config_distro_defaults.h and config_distro_bootcmd.h
for u-boot enviroments to support automatical distro boot which
scan boot.scr from external storage devices(e.g. SD/USB/SATA/SCSI disk)
and execute autoboot script. Tested on ls1043ardb with automatically
boot Ubuntu from SD card or USB disk, if it fails to detect external
storage disk, fall back to nor/qspi boot.

Signed-off-by: Shengzhou Liu 
---
v3: updated to load_addr for installer

 configs/ls1043ardb_defconfig|  1 +
 configs/ls1043ardb_sdcard_defconfig |  1 +
 include/configs/ls1043a_common.h| 67 -
 3 files changed, 54 insertions(+), 15 deletions(-)

diff --git a/configs/ls1043ardb_defconfig b/configs/ls1043ardb_defconfig
index 894110b..84eadf5 100644
--- a/configs/ls1043ardb_defconfig
+++ b/configs/ls1043ardb_defconfig
@@ -36,3 +36,4 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/ls1043ardb_sdcard_defconfig 
b/configs/ls1043ardb_sdcard_defconfig
index d34a253..211399f 100644
--- a/configs/ls1043ardb_sdcard_defconfig
+++ b/configs/ls1043ardb_sdcard_defconfig
@@ -51,3 +51,4 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
+CONFIG_DISTRO_DEFAULTS=y
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index 2c471fd..e8a756f 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -263,38 +263,75 @@
"5m(kernel),1m(dtb),9m(file_system)"
 #endif
 
+
+
+#include 
+#ifndef CONFIG_SPL_BUILD
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(USB, usb, 0)
+#include 
+#endif
+
+
 /* Initial environment variables */
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"hwconfig=fsl_ddr:bank_intlv=auto\0"\
-   "loadaddr=0x8010\0" \
"fdt_high=0x\0" \
-   "initrd_high=0x\0"  \
-   "kernel_start=0x6110\0" \
-   "kernel_load=0xa000\0"  \
+   "initrd_high=0xfffn\0"  \
+   "fdt_addr=0x64f0\0"  \
+   "kernel_addr=0x6500\0"  \
+   "scriptaddr=0x8000\0"  \
+   "fdtheader_addr_r=0x8010\0" \
+   "kernelheader_addr_r=0x8020\0"  \
+   "kernel_addr_r=0x8100\0"\
+   "fdt_addr_r=0x9000\0"   \
+   "load_addr=0xa000\0"   \
"kernel_size=0x280\0"   \
-   "console=ttyS0,115200\0"\
-   "mtdparts=" MTDPARTS_DEFAULT "\0"
+   "console=ttyS0,115200\0"\
+   "mtdparts=" MTDPARTS_DEFAULT "\0"   \
+   BOOTENV \
+   "boot_scripts=ls1043ardb_boot.scr\0"\
+   "scan_dev_for_boot_part="  \
+"part list ${devtype} ${devnum} devplist; "   \
+"env exists devplist || setenv devplist 1; "  \
+"for distro_bootpart in ${devplist}; do " \
+ "if fstype ${devtype} " \
+ "${devnum}:${distro_bootpart} "  \
+ "bootfstype; then " \
+ "run scan_dev_for_boot; " \
+ "fi; "   \
+ "done\0"\
+   "installer=load mmc 0:2 $load_addr "  \
+  "/flex_installer_arm64.itb; "  \
+  "bootm $load_addr#ls1043ardb\0"\
+   "qspi_bootcmd=echo Trying load from qspi..;"  \
+   "sf probe && sf read $load_addr " \
+   "$kernel_addr $kernel_size && bootm $load_addr#$board\0" \
+   "nor_bootcmd=echo Trying load from nor..;"\
+   "cp.b $kernel_addr $load_addr "   \
+   "$kernel_size && bootm $load_addr#$board\0"
+
+
+#undef CONFIG_BOOTCOMMAND
+#if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
+#define CONFIG_BOOTCOMMAND "run distro_bootcmd;run qspi_bootcmd"
+#else
+#define CONFIG_BOOTCOMMAND "run distro_bootcmd;run nor_bootcmd"
+#endif
 
 #define CONFIG_BOOTARGS"console=ttyS0,115200 
root=/dev/ram0 " \
"earlycon=uart8250,mmio,0x21c0500 "\
MTDPARTS_DEFAULT
-
-#if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_SD_BOOT_QSPI)
-#define CONFIG_BOOTCOMMAND "sf probe && sf read $kernel_load "\
-   "e f0 && bootm $kernel_load"
-#else
-#define CONFIG_BOOTCOMMAND "cp.b $kernel_start $kernel_load " \
-   "$kernel_size && bootm $kernel_load"
-#endif
 #endif
 
+
 /* Monitor Command Prompt */
 #define CONFIG_SYS_CBSIZE   

Re: [U-Boot] i.Mx6q u-boot stuck

[Fausto Sessego]

Hi,

here you are my configuration:

#define CONFIG_EXTRA_ENV_SETTINGS \
"image=zImage\0" \
"console=" CONFIG_CONSOLE_DEV "\0" \
"fdt_file=imx6q-tibidabo.dtb\0" \
"fdt_addr=0x1400\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
"mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
"mmcautodetect=yes\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} earlyprintk " \
"root=${mmcroot}\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
"loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \


#define CONFIG_BOOTCOMMAND \
"run mmcargs; " \
"run loadfdt; " \
"run loadimage; " \
"bootz ${loadaddr} - ${fdt_addr}; "\

it is easy.

I tried to put earlyprintk but i didn't see any output.



--
*Ing. Fausto Sessego*
*R Hardware & Software Engineer*

info
mob
>
*Tecnologie Wireless per la logistica e la sicurezza*
*address:* Parco scientifico e tecnologico della Sardegna, Edificio 1 Loc.
Piscinamanna - 09010 Pula (CA)

*phone:* +39 070 92432952
*email:* fausto.sess...@infomob.it
*skype:* fausto.sessego.infomob
*web:* www.infomob.it

2017-05-25 10:57 GMT+02:00 Anatolij Gustschin :

> On Wed, 24 May 2017 18:29:50 +0200
> Fausto Sessego fausto.sess...@infomob.it wrote:
> ...
> > The Kernel doesn't start.
> >
> > U-Boot 2016.07 (May 24 2017 - 17:11:18 +0200)
> >
> > CPU:   Freescale i.MX6Q rev1.2 at 792MHz
> > CPU:   Industrial temperature grade (-40C to 105C) at 20C
> > Reset cause: POR
> > Board: i.MX6Q TIBIDABO
> > Support: http://www.infomob.it/
> > I2C:   ready
> > DRAM:  gd->ram_size: 2147483648
> > DRAM test not implemented!
> > 2 GiB
> > MMC:   FSL_SDHC: 0, FSL_SDHC: 1
> > *** Warning - bad CRC, using default environment
>
> you didn't save the environment, so the default environment is
> used.
>
> > In:serial
> > Out:   serial
> > Err:   serial
> > Net:   FEC [PRIME]
> > Error: FEC address not set.
> >
> > Hit any key to stop autoboot:  0
> > reading imx6q-tibidabo.dtb
> > 29640 bytes read in 22 ms (1.3 MiB/s)
> > reading uImage
> > 6621928 bytes read in 324 ms (19.5 MiB/s)
> > ## Booting kernel from Legacy Image at 1200 ...
> >Image Name:   Linux-4.1.38
> >Image Type:   ARM Linux Kernel Image (uncompressed)
> >Data Size:6621864 Bytes = 6.3 MiB
> >Load Address: 10008000
> >Entry Point:  10008000
> >Verifying Checksum ... OK
> >Loading Kernel Image ... OK
> >
> > Starting kernel ...
>
> Please check 'bootargs' environment variable (print bootargs).
> It should contain "console=ttymxc0,115200" among other values.
> Probably this is not set in the default environment and is missing.
> Ensure that you are passing the correct console string for your
> board in bootargs. I'm not sure if ttymxc0 is correct, please
> test it first.
>
> --
> Anatolij
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] sun50i: a64: Add initial Banana Pi M64 support

[Jagan Teki]

From: Jagan Teki 

BPI-M64 is a 64-bit quad-core mini single board computer
using the Allwinner A64 SOC.

BPI-M64 features
- 1.2 Ghz Quad-Core ARM Cortex A53
- 2GB DDR3 SDRAM with 733MHz
- MicroSD/eMMC(8GB)
- 10/100/1000Mbps ethernet (Realtek RTL8211E/D)
- Wifi + BT
- IR receiver
- Audio In/Out
- Video In/Out
- 5V 2A DC power-supply

For dts file,
Sync with Linux commit 4879b7ae("Merge tag 'dmaengine-4.12-rc1'").

Signed-off-by: Jagan Teki 
---
Note: Not tested yet, board is on-the-way to reach.

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/sun50i-a64-bananapi-m64.dts | 114 +++
 board/sunxi/MAINTAINERS  |   5 ++
 configs/bananapi_m64_defconfig   |  16 +
 4 files changed, 136 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-a64-bananapi-m64.dts
 create mode 100644 configs/bananapi_m64_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a59395b..242b329 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -319,6 +319,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
 dtb-$(CONFIG_MACH_SUN50I) += \
+   sun50i-a64-bananapi-m64.dtb \
sun50i-a64-orangepi-win.dtb \
sun50i-a64-pine64-plus.dtb \
sun50i-a64-pine64.dtb
diff --git a/arch/arm/dts/sun50i-a64-bananapi-m64.dts 
b/arch/arm/dts/sun50i-a64-bananapi-m64.dts
new file mode 100644
index 000..9001812
--- /dev/null
+++ b/arch/arm/dts/sun50i-a64-bananapi-m64.dts
@@ -0,0 +1,114 @@
+/*
+ * Copyright (c) 2016 ARM Ltd.
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64.dtsi"
+
+#include 
+
+/ {
+   model = "BananaPi-M64";
+   compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   status = "okay";
+};
+
+_pins {
+   bias-pull-up;
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_vcc3v3>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>;
+   cd-inverted;
+   disable-wp;
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   non-removable;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   status = "okay";
+};
+
+ {
+   

Re: [U-Boot] [PATCH v6 0/6] Add Intel Arria 10 SoC FPGA driver

[Chee, Tien Fong]

On Kha, 2017-05-25 at 08:35 -0500, Dinh Nguyen wrote:
> 
> On 05/25/2017 03:53 AM, Chee, Tien Fong wrote:
> > 
> > On Rab, 2017-05-24 at 09:56 -0500, Dinh Nguyen wrote:
> > > 
> > > 
> > > On 05/23/2017 09:24 PM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is the 6th version of patchset to adds support for Intel
> > > > Arria
> > > > 10 SoC FPGA
> > > > driver. This version mainly resolved comments from Dinh in
> > > > [v5].
> > > > This series is working on top of u-boot-socfpga-next branch
> > > > http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=re
> > > > fs/h
> > > > eads/next.
> > > > 
> > > > [v5]: https://www.mail-archive.com/u-boot@lists.denx.de/msg2505
> > > > 17.h
> > > > tml
> > > > 
> > > > v5 -> v6 changes:
> > > > -
> > > > - Created separate patch for enabling FPGA driver support.
> > > > 
> > > Please consider at least doing a compile test for this patch
> > > series?
> > > I'm
> > > now very skeptical that you've done any kind of testing on this
> > > patch
> > > series? :(
> > > 
> > > For 'make socfpga_cyclone5_defconfig:
> > > 
> > > arch/arm/mach-socfpga/built-in.o: In function
> > > `socfpga_bridges_reset':
> > > /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
> > > socfpga/reset_manager_gen5.c:101:
> > > undefined reference to `fpgamgr_test_fpga_ready'
> > > arch/arm/mach-socfpga/built-in.o: In function
> > > `populate_sysmgr_fpgaintf_module':
> > > /home/dinguyen/linux_dev/u-boot/arch/arm/mach-
> > > socfpga/system_manager_gen5.c:48:
> > > undefined reference to `fpgamgr_test_fpga_ready'
> > > drivers/built-in.o: In function `sdram_mmr_init_full':
> > > /home/dinguyen/linux_dev/u-boot/drivers/ddr/altera/sdram.c:448:
> > > undefined reference to `fpgamgr_test_fpga_ready'
> > > scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl'
> > > failed
> > > make[1]: *** [spl/u-boot-spl] Error 1
> > > Makefile:1347: recipe for target 'spl/u-boot-spl' failed
> > > make: *** [spl/u-boot-spl] Error 2
> > > 
> > > For socfpga_arria10_defconfig:
> > > 
> > > arch/arm/mach-socfpga/built-in.o: In function `socfpga_fpga_add':
> > > /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:110:
> > > undefined reference to `fpga_init'
> > > /home/dinguyen/linux_dev/u-boot/arch/arm/mach-socfpga/misc.c:112:
> > > undefined reference to `fpga_add'
> > > scripts/Makefile.spl:334: recipe for target 'spl/u-boot-spl'
> > > failed
> > > make[1]: *** [spl/u-boot-spl] Error 1
> > > Makefile:1347: recipe for target 'spl/u-boot-spl' failed
> > > make: *** [spl/u-boot-spl] Error 2
> > > 
> > > 
> > > Dinh
> > I did the compilation on each patch, and testing the patch set on
> > all
> > arria10, cyclone5 and arria10 devkit.
> > 
> > I suspect something wrong with v6-0005-arm-socfpga-Move-FPGA-
> > manager-
> > driver-to-FPGA-driv.patch you applied. Could you help me check
> > again
> > and confirm all the patches waere applied properly?
> > 
> Yes, I've applied all of your patches correctly. The only diff
> between
> this series and the last is:
> 
> $ git diff tien_fong_fpga_a10_v5
> diff --git a/drivers/Makefile b/drivers/Makefile
> index b4a2230..4a4b237 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -47,7 +47,6 @@ obj-$(CONFIG_OMAP_USB_PHY) += usb/phy/
>  obj-$(CONFIG_SPL_SATA_SUPPORT) += block/
>  obj-$(CONFIG_SPL_USB_HOST_SUPPORT) += block/
>  obj-$(CONFIG_SPL_MMC_SUPPORT) += block/
> -obj-$(CONFIG_FPGA) += fpga/
>  endif
> 
>  ifdef CONFIG_TPL_BUILD
> diff --git a/include/configs/socfpga_common.h
> b/include/configs/socfpga_common.h
> index 913b9f1..9edcd2d 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -109,6 +109,7 @@
>  #define CONFIG_FPGA
>  #define CONFIG_FPGA_ALTERA
>  #define CONFIG_FPGA_SOCFPGA
> +#define CONFIG_SPL_FPGA_SUPPORT
>  #define CONFIG_FPGA_COUNT  1
>  #endif
> 
> So the patch for using CONFIG_SPL_FPGA_SUPPORT is causing this build
> error. Please investigate.
> 
> Dinh

Hi Dinh,

I have tried with both u-boot.git and u-boot-socfpga.git lastest
version, i can't still reproduce the issue u have seen :(. Would you
mind to share me the details of the step to reproduce it such as on
what branch?

Hi Ley Foon,

Could you help to try out the patch set too?

Thanks a lot.

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

Re: [U-Boot] [PATCH] armv7m: Fix larger builds

[Phil Edworthy]

Hi Vikas,

On 26 May 2017 00:58 Vikas MANOCHA wrote:
> On Thursday, May 25, 2017 6:58 AM Phil Edworthy wrote:
> > On 25 May 2017 10:16 Phil Edworthy wrote:
> > > > On 24 May 2017 18:32 Vikas MANOCHA wrote:
> > > > Hi Phil,
> > > >
> > > > > On Wednesday, May 24, 2017 7:34 AM Phil Edworthy wrote:
> > > > > The branch instruction only has an 11-bit relative target
> > > > > address, which is
> > > > sometimes not enough.
> > > > >
> > > > > Signed-off-by: Phil Edworthy 
> > > > > ---
> > > > >  arch/arm/cpu/armv7m/start.S | 3 ++-
> > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/arch/arm/cpu/armv7m/start.S
> > > b/arch/arm/cpu/armv7m/start.S
> > > > > index 49f2720..d79adb5 100644
> > > > > --- a/arch/arm/cpu/armv7m/start.S
> > > > > +++ b/arch/arm/cpu/armv7m/start.S
> > > > > @@ -8,7 +8,8 @@
> > > > >  .globl   reset
> > > > >  .type reset, %function
> > > > >  reset:
> > > > > - b   _main
> > > > > + ldr r0, =_main
> > > > > + mov pc, r0
> > > >
> > > > How about using W(b) for wider range ?
> > > Yes, that makes better sense!
> > Hmm, if I use W(b) it complains with:
> > arch/arm/cpu/armv7m/start.S:14:(.text+0x0): relocation truncated to
> > fit: R_ARM_THM_JUMP11 against symbol `_main' defined in .text section
> > in arch/arm/lib/built-in.o
> 
> Seems like the generated branch instruction is still 16 bit, you can check the
> disassembly.  Which compiler & version you are using ?
> Are you getting the same issue with "b_main" also. If no, compare the
> disassembly.
I'm using Linaro GCC 6.3-2017.02

b   _main
or
W(b)_main
Disassembly is the same:
   0:   e7feb.n 0 <_main>

The problem appears to be that __ASSEMBLY__ is defined and so in
arch/arm/include/asm/unified.h, W(x) does nothing. Having said that,
if I simply change the code to
b.w _main
then I get a build error "Error: bad instruction `b.w _main'"

Sorry, I'm not very familiar with ARM asm :)

Thanks
Phil

> Cheers,
> Vikas
> 
> >
> > Any ideas why?
> > Phil
> >
> > > Thanks
> > > Phil
> > >
> > > > Cheers,
> > > > Vikas
> > > >
> > > > >
> > > > >  .globl   c_runtime_cpu_setup
> > > > >  c_runtime_cpu_setup:
> > > > > --
> > > > > 2.7.4

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

[U-Boot] [PATCH] arm: mx6: remove unused config variable CONFIG_SPL_NAND_MXS

[Lothar Waßmann]

The config variable CONFIG_SPL_NAND_MXS is only set in
include/configs/imx6_spl.h but used nowhere.
Remove it.

Signed-off-by: Lothar Waßmann 
---
 include/configs/imx6_spl.h   | 5 -
 scripts/config_whitelist.txt | 1 -
 2 files changed, 6 deletions(-)

diff --git a/include/configs/imx6_spl.h b/include/configs/imx6_spl.h
index 4598d27..bda9541 100644
--- a/include/configs/imx6_spl.h
+++ b/include/configs/imx6_spl.h
@@ -35,11 +35,6 @@
  */
 #define CONFIG_SPL_PAD_TO  0x11000
 
-/* NAND support */
-#if defined(CONFIG_SPL_NAND_SUPPORT)
-#define CONFIG_SPL_NAND_MXS
-#endif
-
 /* MMC support */
 #if defined(CONFIG_SPL_MMC_SUPPORT)
 #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index ed349b9..0768bb2 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -2705,7 +2705,6 @@ CONFIG_SPL_NAND_ECC
 CONFIG_SPL_NAND_INIT
 CONFIG_SPL_NAND_LOAD
 CONFIG_SPL_NAND_MINIMAL
-CONFIG_SPL_NAND_MXS
 CONFIG_SPL_NAND_RAW_ONLY
 CONFIG_SPL_NAND_SIMPLE
 CONFIG_SPL_NAND_SOFTECC
-- 
2.1.4

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

Re: [U-Boot] [PATCH v2 09/30] board_f: Add new function to allow runtime DTB selection

[Lothar Waßmann]

Franklin S Cooper Jr  wrote:

> Runtime U-boot dtb selection is generally a two step process. First step
> is to simply use an initial generic dtb. The second step is to select
> the dtb and perhaps execute additional code ones U-boot knows what board
>
s/ones/once/

> it is running on. Embedded_dtb_select handles the second step by allowing
> board specific code to run and perform what ever necessary configuration
> that is needed.
> 
> Signed-off-by: Franklin S Cooper Jr 
> ---
>  common/Kconfig   | 10 ++
>  common/board_f.c |  3 +++
>  include/common.h |  4 
>  3 files changed, 17 insertions(+)
> 
> diff --git a/common/Kconfig b/common/Kconfig
> index 2429953..b6327f0 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -421,6 +421,16 @@ config SYS_STDIO_DEREGISTER
>  
>  endmenu
>  
> +config DTB_RESELECT
> + bool "Support swapping dtbs at a later point in boot"
> + depends on FIT_EMBED
> + default n
>
'default n' is redundant.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: Set the initial clock speed to 400KHz

[Jaehoon Chung]

Hi Phil,

On 05/26/2017 05:01 PM, Phil Edworthy wrote:
> Hi Jaehoon Chung,
> 
> On 26 May 2017 04:38 Jaehoon Chung wrote:
>> On 05/25/2017 11:14 PM, Phil Edworthy wrote:
>>> On 25 May 2017 15:10 Jaehoon Chung wrote:
 On 05/25/2017 11:02 PM, Phil Edworthy wrote:
> On 25 May 2017 14:50 Jaehoon Chung wrote:
>> On 05/24/2017 10:54 PM, Phil Edworthy wrote:
>>> The code currently defaults to the slowest clock speed that can be
>>> achieved, which can be significantly lower than the SD spec.
>>
>> Is there any problem..As i know, it should be changed from 1 to
>> min_clk.
> The only problem is that the initial SD clock can be very slow so it
> increases the time to start SD. Admittedly, it's a very small
> increase in time, but we should use the correct initial clock speed.

 Well..i didn't agree yet...

 If mmc_set_clock(mmc, 400K) and mmc->cfg->f_min is 300K?
 Initial clock should be always 400K..but spec is mentioned "initial
 clock is maximum 400K.."
 It means the clock can be the value under 400K.
>>> I'm not sure I follow you.
>>> The spec means that all SD cards must support an initial clock speed of
>> 400KHz, right?
>>
>> No..clock frequency range shall be 100KHz - 400KHz during initialization
>> sequence.
>> Some targets should not work fine with 400KHz..So it needs to check f_min
>> value.
>> otherwise, it needs to find the initial clock value like Linux kernel scheme.
> f_min is not the frequency that must be used during init, it is the minimum
> frequency that the Controller can operate at. If a controller has f_min=300KHz
> then there is no problem attempting to set the MMC clock to 400KHz. If the
> controller cannot do exactly 400KHz, the driver should set the clock to the
> closest frequency _under_ 400KHz.
> 
> For example, SDHCI v3 controllers set f_min to f_max / 2046. In my particular
> case, SDHCI v3 controller f_max is 50MHz, so f_min is approximately 25KHz.
> Therefore, when the code does this:
>   mmc_set_clock(mmc, 1);
> it will set the clock rate to approximately 25KHz.
> Clearly this is outside the valid 100-400KHz range that you quote.

Well..then i will check the real frequency with oscilloscope..
then it's more clear than now.. :)

Thanks for pointing out about this.

Best Regards,
Jaehoon Chung

> 
> Thanks
> Phil
> 
>>> If so, then there is no harm in setting it to 400KHz.
>>>
>>> Thanks
>>> Phil
>>>
>>> Signed-off-by: Phil Edworthy 
>>> ---
>>>  drivers/mmc/mmc.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
>>> 72fc177..dff1be3 100644
>>> --- a/drivers/mmc/mmc.c
>>> +++ b/drivers/mmc/mmc.c
>>> @@ -1676,7 +1676,7 @@ int mmc_start_init(struct mmc *mmc)
>> #endif
>>> mmc->ddr_mode = 0;
>>> mmc_set_bus_width(mmc, 1);
>>> -   mmc_set_clock(mmc, 1);
>>> +   mmc_set_clock(mmc, 40);
>>>
>>> /* Reset the Card */
>>> err = mmc_go_idle(mmc);
>>>
>
>
>
>
>>>
>>>
>>>
>>>
> 
> 
> 
> 

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

[U-Boot] [PATCH] arm: ls1021atwr: Add distro boot support

[Alison Wang]

This patch includes common config_distro_defaults.h and
config_distro_bootcmd.h for u-boot enviroments to support distro boot
which automatically scan boot.scr from storage devices(e.g.
SD/USB/SATA/SCSI disk) and execute autoboot script on LS1021ATWR board.

Signed-off-by: Shengzhou Liu 
Signed-off-by: Alison Wang 
---
 configs/ls1021atwr_nor_defconfig |  1 +
 configs/ls1021atwr_sdcard_ifc_defconfig  |  1 +
 configs/ls1021atwr_sdcard_qspi_defconfig |  1 +
 include/configs/ls1021atwr.h | 81 ++--
 4 files changed, 81 insertions(+), 3 deletions(-)

diff --git a/configs/ls1021atwr_nor_defconfig b/configs/ls1021atwr_nor_defconfig
index c56533a..dcacdac 100644
--- a/configs/ls1021atwr_nor_defconfig
+++ b/configs/ls1021atwr_nor_defconfig
@@ -44,3 +44,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 CONFIG_VIDEO_FSL_DCU_FB=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/ls1021atwr_sdcard_ifc_defconfig 
b/configs/ls1021atwr_sdcard_ifc_defconfig
index 9809c60..616bec6 100644
--- a/configs/ls1021atwr_sdcard_ifc_defconfig
+++ b/configs/ls1021atwr_sdcard_ifc_defconfig
@@ -56,3 +56,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 CONFIG_VIDEO_FSL_DCU_FB=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/ls1021atwr_sdcard_qspi_defconfig 
b/configs/ls1021atwr_sdcard_qspi_defconfig
index 5ccfc96..293e735 100644
--- a/configs/ls1021atwr_sdcard_qspi_defconfig
+++ b/configs/ls1021atwr_sdcard_qspi_defconfig
@@ -63,3 +63,4 @@ CONFIG_USB_XHCI_DWC3=y
 CONFIG_USB_STORAGE=y
 CONFIG_VIDEO_FSL_DCU_FB=y
 # CONFIG_VIDEO_SW_CURSOR is not set
+CONFIG_DISTRO_DEFAULTS=y
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 60c3d5d..74ee74d 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -354,7 +354,6 @@
 #endif
 
 #define CONFIG_CMDLINE_TAG
-#define CONFIG_CMDLINE_EDITING
 
 #define CONFIG_PEN_ADDR_BIG_ENDIAN
 #define CONFIG_LAYERSCAPE_NS_ACCESS
@@ -366,19 +365,95 @@
 
 #define CONFIG_FSL_DEVICE_DISABLE
 
+#include 
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(USB, usb, 0)
+#include 
 
 #ifdef CONFIG_LPUART
 #define CONFIG_EXTRA_ENV_SETTINGS   \
"bootargs=root=/dev/ram0 rw console=ttyLP0,115200\0" \
"initrd_high=0x\0"  \
-   "fdt_high=0x\0"
+   "fdt_high=0x\0" \
+   "fdt_addr=0x64f0\0" \
+   "kernel_addr=0x6500\0"  \
+   "scriptaddr=0x8000\0"   \
+   "fdtheader_addr_r=0x8010\0" \
+   "kernelheader_addr_r=0x8020\0"  \
+   "kernel_addr_r=0x8100\0"\
+   "fdt_addr_r=0x9000\0"   \
+   "ramdisk_addr_r=0xa000\0"   \
+   "load_addr=0xa000\0"\
+   "kernel_size=0x280\0"   \
+   BOOTENV \
+   "boot_scripts=ls1021atwr_boot.scr\0"\
+   "scan_dev_for_boot_part="   \
+   "part list ${devtype} ${devnum} devplist; " \
+   "env exists devplist || setenv devplist 1; "\
+   "for distro_bootpart in ${devplist}; do "   \
+   "if fstype ${devtype} " \
+   "${devnum}:${distro_bootpart} " \
+   "bootfstype; then " \
+   "run scan_dev_for_boot; "   \
+   "fi; "  \
+   "done\0"\
+   "installer=load mmc 0:2 $load_addr "\
+   "/flex_installer_arm32.itb; "   \
+   "bootm $load_addr#ls1021atwr\0" \
+   "qspi_bootcmd=echo Trying load from qspi..;"\
+   "sf probe && sf read $load_addr "   \
+   "$kernel_addr $kernel_size && bootm $load_addr#$board\0"
\
+   "nor_bootcmd=echo Trying load from nor..;"  \
+   "cp.b $kernel_addr $load_addr " \
+   "$kernel_size && bootm $load_addr#$board\0"
 #else
 #define CONFIG_EXTRA_ENV_SETTINGS  \
"bootargs=root=/dev/ram0 rw console=ttyS0,115200\0" \
"initrd_high=0x\0"  \
-   "fdt_high=0x\0"
+   "fdt_high=0x\0" \
+   "fdt_addr=0x64f0\0" \
+   "kernel_addr=0x6500\0"  \
+   "scriptaddr=0x8000\0"   \
+   "fdtheader_addr_r=0x8010\0" \
+   "kernelheader_addr_r=0x8020\0"  \
+   "kernel_addr_r=0x8100\0"\
+   "fdt_addr_r=0x9000\0"   \
+   "ramdisk_addr_r=0xa000\0"   \
+   "load_addr=0xa000\0"\
+   "kernel_size=0x280\0"   \
+   BOOTENV \
+   "boot_scripts=ls1021atwr_boot.scr\0"\
+   

Re: [U-Boot] [PATCH] mmc: Set the initial clock speed to 400KHz

[Phil Edworthy]

Hi Jaehoon Chung,

On 26 May 2017 04:38 Jaehoon Chung wrote:
> On 05/25/2017 11:14 PM, Phil Edworthy wrote:
> > On 25 May 2017 15:10 Jaehoon Chung wrote:
> >> On 05/25/2017 11:02 PM, Phil Edworthy wrote:
> >>> On 25 May 2017 14:50 Jaehoon Chung wrote:
>  On 05/24/2017 10:54 PM, Phil Edworthy wrote:
> > The code currently defaults to the slowest clock speed that can be
> > achieved, which can be significantly lower than the SD spec.
> 
>  Is there any problem..As i know, it should be changed from 1 to
> min_clk.
> >>> The only problem is that the initial SD clock can be very slow so it
> >>> increases the time to start SD. Admittedly, it's a very small
> >>> increase in time, but we should use the correct initial clock speed.
> >>
> >> Well..i didn't agree yet...
> >>
> >> If mmc_set_clock(mmc, 400K) and mmc->cfg->f_min is 300K?
> >> Initial clock should be always 400K..but spec is mentioned "initial
> >> clock is maximum 400K.."
> >> It means the clock can be the value under 400K.
> > I'm not sure I follow you.
> > The spec means that all SD cards must support an initial clock speed of
> 400KHz, right?
> 
> No..clock frequency range shall be 100KHz - 400KHz during initialization
> sequence.
> Some targets should not work fine with 400KHz..So it needs to check f_min
> value.
> otherwise, it needs to find the initial clock value like Linux kernel scheme.
f_min is not the frequency that must be used during init, it is the minimum
frequency that the Controller can operate at. If a controller has f_min=300KHz
then there is no problem attempting to set the MMC clock to 400KHz. If the
controller cannot do exactly 400KHz, the driver should set the clock to the
closest frequency _under_ 400KHz.

For example, SDHCI v3 controllers set f_min to f_max / 2046. In my particular
case, SDHCI v3 controller f_max is 50MHz, so f_min is approximately 25KHz.
Therefore, when the code does this:
mmc_set_clock(mmc, 1);
it will set the clock rate to approximately 25KHz.
Clearly this is outside the valid 100-400KHz range that you quote.

Thanks
Phil

> > If so, then there is no harm in setting it to 400KHz.
> >
> > Thanks
> > Phil
> >
> > Signed-off-by: Phil Edworthy 
> > ---
> >  drivers/mmc/mmc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> > 72fc177..dff1be3 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -1676,7 +1676,7 @@ int mmc_start_init(struct mmc *mmc)
> #endif
> > mmc->ddr_mode = 0;
> > mmc_set_bus_width(mmc, 1);
> > -   mmc_set_clock(mmc, 1);
> > +   mmc_set_clock(mmc, 40);
> >
> > /* Reset the Card */
> > err = mmc_go_idle(mmc);
> >
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >

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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez]

On 05/26/2017 09:28 AM, Jorge Ramirez wrote:


[1] 
https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi 


Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
use platform data, at least for now.  I do want to talk more with Rob
about the general problem this exposes.

so you want me to

1) keep the node in 
https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi 


Well, a uart0 node, but no "clock" property as that just needs to go
away.


Sounds good to me. now see below




2) add status=disable
3) then add the platform_data

BUT for the pl011 driver to take the platform_data dont I also have
to disable CONFIG_OF?

but  if I disable CONFIG_OF then I lose USB_DM

No, the status = "disable" on uart0 should remove it from the dtb, or at
least we should see it and go "Oh, no, we don't have uart0 via DT".




1) Since the UART0 is enabled in the kernel's DTS I will have to 
modify the device tree that I am importing from kernel.org to disable it.


2) But even doing this is not enough: I have to completely remove the 
uart0 node from the tree.



So to sum up:

In order to get the platform data for pl01x I have to either disable 
OF (so I lose the USB node as I said earlier) or *completely* remove 
the UART0 node from from the kernel dts.
I personally would rather not modify the kernel's DTS trees that I am 
importing into uboot but I am really confused about the policy now.


ie: to be clear from my side, doing the following is not enough:

diff --git a/arch/arm/dts/hi3798cv200-poplar.dts 
b/arch/arm/dts/hi3798cv200-poplar.dts

index b914287..d4ce16d 100644
--- a/arch/arm/dts/hi3798cv200-poplar.dts
+++ b/arch/arm/dts/hi3798cv200-poplar.dts
@@ -152,7 +152,7 @@
 };

  {
-   status = "okay";
+ status = "disabled";
 };


I have to actually do

diff --git a/arch/arm/dts/hi3798cv200-poplar.dts 
b/arch/arm/dts/hi3798cv200-poplar.dts

index b914287..028013f 100644
--- a/arch/arm/dts/hi3798cv200-poplar.dts
+++ b/arch/arm/dts/hi3798cv200-poplar.dts
@@ -17,7 +17,6 @@
compatible = "hisilicon,hi3798cv200-poplar", 
"hisilicon,hi3798cv200";


aliases {
-   serial0 = 
serial2 = 
};

@@ -151,12 +150,9 @@
label = "LS-SPI0";
 };

- {
-   status = "okay";
-};

  {
status = "okay";
label = "LS-UART0";
 };


OR

[jramirez@titan git.u-boot (upstream *$)]$ git diff
diff --git a/arch/arm/dts/hi3798cv200-poplar.dts 
b/arch/arm/dts/hi3798cv200-poplar.dts

index b914287..5d909b83 100644
--- a/arch/arm/dts/hi3798cv200-poplar.dts
+++ b/arch/arm/dts/hi3798cv200-poplar.dts
@@ -21,10 +21,6 @@
serial2 = 
};

-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
memory@0 {
device_type = "memory";
reg = <0x0 0x0 0x0 0x8000>;
@@ -152,7 +148,7 @@
 };

  {
-   status = "okay";
+ status = "disabled";
 };

  {



Is this the right way to go then? alter the kernel DTS when merging into 
uboot?




please could you clarify?

I still think what I proposed when we started is the better way to go: 
a uboot specific hi3798cv200-u-boot.dtsifile that contains the two 
nodes that are giving trouble.


The timeline then goes:
- the usb node will disappear as soon as it lands in korg
- the uart node and the whole file will be removed during the cleanup 
of all the pl01x uart offenders.


but if you think modifying the kernels dts is better I can do that as 
well. 


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

Re: [U-Boot] [PATCHv4 3/3] ARM64: poplar: hi3798cv200: u-boot support for Poplar 96Boards

[Jorge Ramirez]

On 05/26/2017 12:08 AM, Tom Rini wrote:

On Thu, May 25, 2017 at 11:16:42PM +0200, Jorge Ramirez wrote:

On 05/25/2017 11:12 PM, Tom Rini wrote:

On Thu, May 25, 2017 at 10:58:20PM +0200, Jorge Ramirez wrote:

On 05/25/2017 10:55 PM, Jorge Ramirez wrote:

On 05/25/2017 10:31 PM, Tom Rini wrote:

On Thu, May 25, 2017 at 08:38:47PM +0200, Jorge Ramirez wrote:

On 05/18/2017 12:06 AM, Tom Rini wrote:

having platform data.

No, I think we're going for overkill here by not doing
serial_pl01x.c as
platform data.  ns16550 does platform data for this already.  This
sounds like the lowest overhead way to get the clock
populated and not
have some DT data that's not going to be accepted upstream.


u I am a bit lost at this point, could we recap please?

Lets update the recap:
- Please re-submit the dts file, now with whatever form is
in v4.12-rc1,
   saying as such in the commit (if it's just the commit message that
   changes, that's fine and great).

The DTS file in v4.12-rc2 still does NOT contain the usb node.

==> Should I then not use the DM on USB so I can avoid DTS changes?

Well, you can either put it in the -u-boot.dtsi file for the board, and
remove that later once it's upstream.

yes I'll do that. thanks.


- Please update serial_pl01x.c to be able to get the clock
via platform
   data, update and test your board to confirm it works.

um, It gets tricky;
I can not use platform_data since I can not use SERIAL_DM because
the device tree does have a UART node which gets picked up.

How about disabling the node in -u-boot.dtsi for the board and then you
can use platform data,

I dont think that would because CONFIG_OF is enabled for USB; so the
kernel dtsi that contains the uart node (without the clock!) will be
picked by u-boot and the uart will not be initialized properly.
I still think that the simplest solution is to let me merge with the
kernel's device tree plus this u-boot.dtsi [1];
then just get rid of the file when possible (and NEIHER the source
code NOR the configs) would need to change

[1] 
https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi

Yes, sorry.  [1] needs to be updated to disable uart0 so that you can
use platform data, at least for now.  I do want to talk more with Rob
about the general problem this exposes.

so you want me to

1) keep the node in 
https://github.com/ldts/poplar-u-boot/blob/upstream/arch/arm/dts/hi3798cv200-u-boot.dtsi

Well, a uart0 node, but no "clock" property as that just needs to go
away.


Sounds good to me. now see below




2) add status=disable
3) then add the platform_data

BUT for the pl011 driver to take the platform_data dont I also have
to disable CONFIG_OF?

but  if I disable CONFIG_OF then I lose USB_DM

No, the status = "disable" on uart0 should remove it from the dtb, or at
least we should see it and go "Oh, no, we don't have uart0 via DT".




1) Since the UART0 is enabled in the kernel's DTS I will have to modify 
the device tree that I am importing from kernel.org to disable it.


2) But even doing this is not enough: I have to completely remove the 
uart0 node from the tree.



So to sum up:

In order to get the platform data for pl01x I have to either disable OF 
(so I lose the USB node as I said earlier) or *completely* remove the 
UART0 node from from the kernel dts.
I personally would rather not modify the kernel's DTS trees that I am 
importing into uboot but I am really confused about the policy now.


please could you clarify?

I still think what I proposed when we started is the better way to go: a 
uboot specific hi3798cv200-u-boot.dtsifile that contains the two nodes 
that are giving trouble.


The timeline then goes:
- the usb node will disappear as soon as it lands in korg
- the uart node and the whole file will be removed during the cleanup of 
all the pl01x uart offenders.


but if you think modifying the kernels dts is better I can do that as well.










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

Re: [U-Boot] [PATCH v4 2/2] doc: document u-boot, mmc-env-offset and u-boot, mmc-env-offset-redund

[Jaehoon Chung]

On 05/25/2017 10:51 PM, Jaehoon Chung wrote:
> On 05/16/2017 07:16 AM, Philipp Tomsich wrote:
>> Adding documentation on the new config properties:
>>'u-boot,mmc-env-offset' - overrides CONFIG_ENV_OFFSET
>>'u-boot,mmc-env-offset-redundant'
>>- overrides CONFIG_ENV_OFFSET_REDUND
>>
>> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Jaehoon Chung 


Applied to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
>>
>> ---
>>
>> Changes in v4: None
>> Changes in v3: None
>> Changes in v2:
>> - added documentation in config.txt
>>
>>  doc/device-tree-bindings/config.txt | 12 
>>  1 file changed, 12 insertions(+)
>>
>> diff --git a/doc/device-tree-bindings/config.txt 
>> b/doc/device-tree-bindings/config.txt
>> index d4bc1df..fe0e04a 100644
>> --- a/doc/device-tree-bindings/config.txt
>> +++ b/doc/device-tree-bindings/config.txt
>> @@ -21,6 +21,18 @@ u-boot,efi-partition-entries-offset
>>  
>>  This setting will override any values configured via Kconfig.
>>  
>> +u-boot,mmc-env-offset
>> +u-boot,mmc-env-offset-redundant
>> +If present, the values of the 'u-boot,mmc-env-offset' and/or
>> +of the u-boot,mmc-env-offset-redundant' properties overrides
>> +CONFIG_ENV_OFFSET and CONFIG_ENV_OFFSET_REDUND, respectively,
>> +for SD/MMC devices.
>> +
>> +Values are interpreted as the offset from the start of the
>> +device, specified in bytes.  It is assumed that the setting
>> +will point at the beginning of a LBA and values that are not
>> +LBA-aligned will be rounded up to the next LBA address.
>> +
>>  u-boot,spl-payload-offset
>>  If present (and SPL is controlled by the device-tree), this allows
>>  to override the CONFIG_SYS_SPI_U_BOOT_OFFS setting using a value
>>
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

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

Re: [U-Boot] [PATCH v4 1/2] env_mmc: configure environment offsets via device tree

[Jaehoon Chung]

On 05/25/2017 10:51 PM, Jaehoon Chung wrote:
> Hi Philipp,
> 
> On 05/16/2017 07:16 AM, Philipp Tomsich wrote:
>> This introduces the ability to override the environment offets from the
>> device tree by setting the following nodes in '/config':
>>  'u-boot,mmc-env-offset' - overrides CONFIG_ENV_OFFSET
>>  'u-boot,mmc-env-offset-redundant'
>>  - overrides CONFIG_ENV_OFFSET_REDUND
>>
>> To keep with the previous logic, the CONFIG_* defines still need to
>> be available and the statically defined values become the defaults,
>> when the corresponding properties are not set in the device-tree.
>>
>> Signed-off-by: Philipp Tomsich 
>> Acked-by: Simon Glass 
> 
> I'm doing check this patches..after building,,if there is no problem, i will 
> pick.

Applied to u-boot-mmc. Thanks!

Best Regards,
Jaehoon Chung

> 
> Thanks!
> 
> Best Regards,
> Jaehoon Chung
> 
>> ---
>>
>> Changes in v4:
>> - change the test for OF_CONTROL to use CONFIG_IS_ENABLED to pick up
>>   the differece between SPL_OF_CONTROL and OF_CONTROL
>>
>> Changes in v3:
>> - changes the config-check to depend on CONFIG_OF_CONTROL to detect
>>   if 'fdtdec_get_config_int' is available
>>
>> Changes in v2: None
>>
>>  common/env_mmc.c | 31 +++
>>  1 file changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/common/env_mmc.c b/common/env_mmc.c
>> index a5d14d4..45d95a1 100644
>> --- a/common/env_mmc.c
>> +++ b/common/env_mmc.c
>> @@ -10,6 +10,7 @@
>>  
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -36,15 +37,37 @@ DECLARE_GLOBAL_DATA_PTR;
>>  #define CONFIG_ENV_OFFSET 0
>>  #endif
>>  
>> -__weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
>> +#if CONFIG_IS_ENABLED(OF_CONTROL)
>> +static inline s64 mmc_offset(int copy)
>>  {
>> -s64 offset;
>> +const char *propname = "u-boot,mmc-env-offset";
>> +s64 defvalue = CONFIG_ENV_OFFSET;
>>  
>> -offset = CONFIG_ENV_OFFSET;
>> -#ifdef CONFIG_ENV_OFFSET_REDUND
>> +#if defined(CONFIG_ENV_OFFSET_REDUND)
>> +if (copy) {
>> +propname = "u-boot,mmc-env-offset-redundant";
>> +defvalue = CONFIG_ENV_OFFSET_REDUND;
>> +}
>> +#endif
>> +
>> +return fdtdec_get_config_int(gd->fdt_blob, propname, defvalue);
>> +}
>> +#else
>> +static inline s64 mmc_offset(int copy)
>> +{
>> +s64 offset = CONFIG_ENV_OFFSET;
>> +
>> +#if defined(CONFIG_ENV_OFFSET_REDUND)
>>  if (copy)
>>  offset = CONFIG_ENV_OFFSET_REDUND;
>>  #endif
>> +return offset;
>> +}
>> +#endif
>> +
>> +__weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
>> +{
>> +s64 offset = mmc_offset(copy);
>>  
>>  if (offset < 0)
>>  offset += mmc->capacity;
>>
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 

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