[U-Boot] [PATCH] rockchip: rk3036: change ddr frequency to 400M

[Jeffy Chen]

From: Lin Huang 

emac may use dpll as clock parent, and it request the clock frequency
multiples of 50, so change ddr frequency to 400M.

Signed-off-by: Lin Huang 
Signed-off-by: Jeffy Chen 

---

 arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c 
b/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
index e3ca870..ec8305c 100644
--- a/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
+++ b/arch/arm/mach-rockchip/rk3036/sdram_rk3036.c
@@ -37,7 +37,7 @@ struct rk3036_sdram_priv {
 /* use integer mode, 396MHz dpll setting
  * refdiv, fbdiv, postdiv1, postdiv2
  */
-const struct pll_div dpll_init_cfg = {1, 66, 4, 1};
+const struct pll_div dpll_init_cfg = {1, 50, 3, 1};
 
 /* 396Mhz ddr timing */
 const struct rk3036_ddr_timing ddr_timing = {0x18c,
-- 
2.1.4


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

[U-Boot] [PATCH] ARM: zynq: Enable SPL RAM support by default

[Michal Simek]

Use RAM support in jtagboot mode.

Signed-off-by: Michal Simek 
---

 include/configs/zynq-common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/zynq-common.h b/include/configs/zynq-common.h
index e8c3ef0c3872..9bd3e9f32665 100644
--- a/include/configs/zynq-common.h
+++ b/include/configs/zynq-common.h
@@ -307,6 +307,7 @@
 #define CONFIG_SPL_LIBGENERIC_SUPPORT
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_BOARD_INIT
+#define CONFIG_SPL_RAM_DEVICE
 
 #define CONFIG_SPL_LDSCRIPT"arch/arm/mach-zynq/u-boot-spl.lds"
 
-- 
1.9.1

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Jagan Teki]

Hi Bin,

On 17 February 2016 at 13:07, Jagan Teki  wrote:
> Hi Bin,
>
> On 17 February 2016 at 10:52, Bin Meng  wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki  wrote:
>>> On 15 February 2016 at 02:16, Jagan Teki  wrote:
 Compared to previous patch series this series adds spi-nor
 core with spi-nor controller drivers are of "mtd uclass"

 This is whole series for all spi-nor related changes, and while
 series tested on spansion spi-nor chip.

 Know issue:
 - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.

 Why this framework:

 Some of the SPI device drivers at drivers/spi not a real
 spi controllers, Unlike normal/generic SPI controllers they
 operates only with SPI-NOR flash devices. these were technically
 termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c

 The problem with these were resides at drivers/spi is entire
 SPI layer becomes SPI-NOR flash oriented which is absolutely
 a wrong indication where SPI layer getting effected more with
 flash operations - So this SPI-NOR core will resolve this issue
 by separating all SPI-NOR flash operations from spi layer and
 creats a generic layer called SPI-NOR core which can be used to
 interact SPI-NOR to SPI driver interface layer and the SPI-NOR
 controller driver. The idea is taken from Linux spi-nor framework.

 Before SPI-NOR:

 ---
 cmd/sf.c
 ---
 spi_flash.c
 ---
 sf_probe.c
 ---
 spi-uclass
 ---
 spi drivers
 ---
 SPI NOR chip
 ---

 After SPI-NOR:

 --
 cmd/sf.c
 --
 spi-nor.c
 ---
 m25p80.cspi nor drivers
 ---
 spi-uclass  SPI NOR chip
 ---
 spi drivers
 ---
 SPI NOR chip
 ---

 SPI-NOR with MTD:

 --
 cmd/sf.c
 --
 MTD core
 --
 spi-nor.c
 ---
 m25p80.cspi nor drivers
 ---
 spi-uclass  SPI NOR chip
 ---
 spi drivers
 ---
 SPI NOR chip
 ---

 drivers/mtd/spi-nor/spi-nor.c: spi-nor core
 drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
 which is an interface layer b/w spi-nor core drivers/spi
 drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Tested both DM and non-DM models
>>>
>>> Tested-by: Jagan Teki 
>>
>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>> Warning - bad CRC, using default environment
>>
>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>> KiB, total 2 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Anything wrong?
>
>

 I'm not getting the warning, after saveenv.

DRAM:  ECC disabled 1 GiB
MMC:
spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
KiB, total 16 MiB
In:serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Model: Zynq MicroZED Board

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Jagan Teki]

Hi Bin,

On 17 February 2016 at 10:52, Bin Meng  wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki  wrote:
>> On 15 February 2016 at 02:16, Jagan Teki  wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> ---
>>> cmd/sf.c
>>> ---
>>> spi_flash.c
>>> ---
>>> sf_probe.c
>>> ---
>>> spi-uclass
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> After SPI-NOR:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> SPI-NOR with MTD:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> MTD core
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Tested both DM and non-DM models
>>
>> Tested-by: Jagan Teki 
>
> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
> the SPI flash correctly, however after "reset" U-Boot still shows: ***
> Warning - bad CRC, using default environment
>
> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
> KiB, total 2 MiB
> *** Warning - bad CRC, using default environment
>
> Anything wrong?

I'm not getting the warning


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

Re: [U-Boot] test/py main_signon

[Michal Simek]

Hi Heiko,

On 17.2.2016 07:34, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 16.02.2016 um 17:04 schrieb Michal Simek:
>> Hi Heiko,
>>
>> On 16.2.2016 14:32, Heiko Schocher wrote:
>>> Hello Michal,
>>>
>>> Am 16.02.2016 um 13:12 schrieb Michal Simek:
 Hi Stephen,

 trying to run the latest testing on zynq board and getting this
 main_signon error.

 This is what I am running
 ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
 and getting below.
>>>
>>> Does this board has SPL support without SPL serial output?
>>
>> I do load u-boot via jtag that's why SPL logs are not visible.
>>
>>> If so, can you try my patch:
>>> http://patchwork.ozlabs.org/patch/583348/
>>
>> I have applied your patch but it is still not working.
>>
>> If I run full flow with SPL then I can't see any issue.
> 
> I am not an expert of test/py (I still try to dig into it), but as
> I understand it, it looks if CONFIG_SPL is defined, if so, the
> framework expects a SPL output first, if not found, it raises
> the error you see ...
> 
> My patch fixes this, for boards which use SPL, but without serial
> SPL output ...
> 
> Now you test only u-boot with SPL configured with SPL serial output ...
> 
> I think Stephen can say here more, how to solve this ...

Ok. I have spent some time on this. Your patch is covering a little bit
different case than I have.
We have in general two used cases. One is to use SPL as first stage
bootloader and then private full featured FSBL.
Both of them works with the same u-boot image. It means I can build
uboot with SPL and run two test sets. One with SPL which is working fine
and the second without but there is no reason to rebuild u-boot without
SPL just to pass testing.
It means the feature I am looking for is more about ignoring SPL signon
instead of supporting cases where SPL doesn't print anything.

Thanks,
Michal

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

Re: [U-Boot] [PATCH 4/4] pci_rom: fix may be used uninitialized warning

[Anatolij Gustschin]

On Tue, 16 Feb 2016 23:29:31 +0100
Andreas Bießmann andreas.de...@googlemail.com wrote:

> Building pci_rom.c with my toolchain complains about may be used uninitialized
> rom varaible:
> 
> ---8<---
> +drivers/pci/pci_rom.c:269:25: note: 'rom' was declared here
> w+drivers/pci/pci_rom.c: In function 'dm_pci_run_vga_bios':
> w+drivers/pci/pci_rom.c:154:14: warning: 'rom' may be used uninitialized in 
> this function [-Wmaybe-uninitialized]
> --->8---
> 
> Fix this as done in 55616b86c745fcac5a791268ab8e7cba36965c0f the ram variable.
> 
> Signed-off-by: Andreas Bießmann 

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

Re: [U-Boot] [PATCH] video: tegra: Correct a Kconfig warning with VIDCONSOLE_AS_LCD

[Anatolij Gustschin]

On Tue, 16 Feb 2016 18:09:19 -0700
Simon Glass s...@chromium.org wrote:

> This new feature causes a Kconfig warning on boards without a display
> enabled. Fix this.
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] how does board_init_f() -> board_init_r?

[Peter Chen]

Oh I see. Thanks.

On Tue, Feb 16, 2016 at 8:41 AM, Stephen Warren 
wrote:

> On 02/16/2016 09:01 AM, Simon Glass wrote:
>
>> +Stephen who will know more
>>
>> Hi,
>>
>> On 13 February 2016 at 18:52, quantumlight 
>> wrote:
>>
>>> I am trying to modify the bootloader code for NVIDIA's jetson board.
>>>
>>> So I am looking at crt0.S. It seems that two builds happen, one with
>>> CONFIG_SPL_BUILD and one without. So you end up with two file, u-boot.bin
>>> and spl/u-boot-spl.bin.
>>>
>>
>> SPL is built with ARMv4t
>> U-Boot proper is built with ARMv7
>>
>> That's why SPL is used on Tegra. The SPL does not actually load
>> U-Boot. In fact both are bundle together and loaded at the same time.
>> SPL simply jumps to U-Boot when needed.
>>
>
> There's some more background on this topic at:
>
> ftp://download.nvidia.com/tegra-public-appnotes/index.html
>
> In particular, see the "Tegra Boot Flow" link/document.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] test/py: only check for SPL signature if SPL uses serial output

[Heiko Schocher]

check for U-Boot SPL signature only if SPL really has a serial output.
So check if CONFIG_SPL_SERIAL_SUPPORT is active in board config.

Signed-off-by: Heiko Schocher 
---
found this while trying test/py on the smartweb
board, which has SPL but no SPL serial output.

Changes in v2:
- add comments from Stephen Warren:
  - introduce some variables to shorten text
  - do not use nested if, instead use "if a and b"
  - use wrapping of 72-74 chars in commit message
- add Michal Simek to Cc

 test/py/u_boot_console_base.py | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index bc2bd76..79b8dc6 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -303,8 +303,13 @@ class ConsoleBase(object):
 if not self.config.gdbserver:
 self.p.timeout = 3
 self.p.logfile_read = self.logstream
-if self.config.buildconfig.get('config_spl', False) == 'y':
-m = self.p.expect([pattern_u_boot_spl_signon] + 
self.bad_patterns)
+bcfg = u_boot_console.config.buildconfig
+config_spl = bcfg.get('config_spl', 'n') == 'y'
+config_spl_serial_support = bcfg.get('config_spl_serial_support',
+ 'n') == 'y'
+if config_spl and config_spl_serial_support:
+m = self.p.expect([pattern_u_boot_spl_signon] +
+  self.bad_patterns)
 if m != 0:
 raise Exception('Bad pattern found on console: ' +
 self.bad_pattern_ids[m - 1])
-- 
2.5.0

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

Re: [U-Boot] [PATCH 14/30] dm: part: Convert partition API use to linker lists

[Stephen Warren]

On 02/14/2016 07:16 PM, Simon Glass wrote:
> We can use linker lists instead of explicitly declaring each function.
> This makes the code shorter by avoiding switch() statements and lots of
> header file declarations.
> 
> While this does clean up the code it introduces a few code issues with SPL.
> SPL never needs to print partition information since this all happens from
> commands. SPL mostly doesn't need to obtain information about a partition
> either, except in a few cases. Add these cases so that the code will be
> dropped from each partition driver when not needed. This avoids code bloat.
> 
> I think this is still a win, since it is not a bad thing to be explicit
> about which features are used in SPL. But others may like to weigh in.

This patch changes the order in which partition types are detected,
which matters when multiple partition types match (a GPT often/always
has a protective MBR too). Consequently, this breaks GPT support.

By hacking around this (turning off DOS partition support), and fixing
the PCIe issue I mentioned elsewhere, test/py seems to work for me with
this series applied.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] test/py main_signon

[Heiko Schocher]

Hello Michal,

Am 16.02.2016 um 17:04 schrieb Michal Simek:

Hi Heiko,

On 16.2.2016 14:32, Heiko Schocher wrote:

Hello Michal,

Am 16.02.2016 um 13:12 schrieb Michal Simek:

Hi Stephen,

trying to run the latest testing on zynq board and getting this
main_signon error.

This is what I am running
./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
and getting below.


Does this board has SPL support without SPL serial output?


I do load u-boot via jtag that's why SPL logs are not visible.


If so, can you try my patch:
http://patchwork.ozlabs.org/patch/583348/


I have applied your patch but it is still not working.

If I run full flow with SPL then I can't see any issue.


I am not an expert of test/py (I still try to dig into it), but as
I understand it, it looks if CONFIG_SPL is defined, if so, the
framework expects a SPL output first, if not found, it raises
the error you see ...

My patch fixes this, for boards which use SPL, but without serial
SPL output ...

Now you test only u-boot with SPL configured with SPL serial output ...

I think Stephen can say here more, how to solve this ...

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Jagan Teki]

On 17 February 2016 at 10:57, Bin Meng  wrote:
> On Wed, Feb 17, 2016 at 1:22 PM, Bin Meng  wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki  wrote:
>>> On 15 February 2016 at 02:16, Jagan Teki  wrote:
 Compared to previous patch series this series adds spi-nor
 core with spi-nor controller drivers are of "mtd uclass"

 This is whole series for all spi-nor related changes, and while
 series tested on spansion spi-nor chip.

 Know issue:
 - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.

 Why this framework:

 Some of the SPI device drivers at drivers/spi not a real
 spi controllers, Unlike normal/generic SPI controllers they
 operates only with SPI-NOR flash devices. these were technically
 termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c

 The problem with these were resides at drivers/spi is entire
 SPI layer becomes SPI-NOR flash oriented which is absolutely
 a wrong indication where SPI layer getting effected more with
 flash operations - So this SPI-NOR core will resolve this issue
 by separating all SPI-NOR flash operations from spi layer and
 creats a generic layer called SPI-NOR core which can be used to
 interact SPI-NOR to SPI driver interface layer and the SPI-NOR
 controller driver. The idea is taken from Linux spi-nor framework.

 Before SPI-NOR:

 ---
 cmd/sf.c
 ---
 spi_flash.c
 ---
 sf_probe.c
 ---
 spi-uclass
 ---
 spi drivers
 ---
 SPI NOR chip
 ---

 After SPI-NOR:

 --
 cmd/sf.c
 --
 spi-nor.c
 ---
 m25p80.cspi nor drivers
 ---
 spi-uclass  SPI NOR chip
 ---
 spi drivers
 ---
 SPI NOR chip
 ---

 SPI-NOR with MTD:

 --
 cmd/sf.c
 --
 MTD core
 --
 spi-nor.c
 ---
 m25p80.cspi nor drivers
 ---
 spi-uclass  SPI NOR chip
 ---
 spi drivers
 ---
 SPI NOR chip
 ---

 drivers/mtd/spi-nor/spi-nor.c: spi-nor core
 drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
 which is an interface layer b/w spi-nor core drivers/spi
 drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Tested both DM and non-DM models
>>>
>>> Tested-by: Jagan Teki 
>>
>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>> Warning - bad CRC, using default environment
>>
>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>> KiB, total 2 MiB
>> *** Warning - bad CRC, using default environment
>>
>> Anything wrong?
>>
>
> Another testing on Intel Galileo shows that: it does NOT build for galileo.
>
> arch/x86/lib/built-in.o: In function `mrccache_update':
> arch/x86/lib/mrccache.c:142: undefined reference to `spi_flash_erase_dm'
> arch/x86/lib/mrccache.c:153: undefined reference to `spi_flash_write_dm'
>
> Did you run buildman for your whole series?

Yes this is the known issues, I mentioned on the cover letter. we need
to fix this one.

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

Re: [U-Boot] [PATCH V2 1/2] pinctrl: imx: Introduce pinctrl driver for i.MX6

[Peng Fan]

Hi Simon,

On Tue, Feb 16, 2016 at 07:50:25PM -0700, Simon Glass wrote:
>Hi Peng,
>
>On 16 February 2016 at 19:45, Peng Fan  wrote:
>> Hi Simon,
>>
>> On Tue, Feb 16, 2016 at 09:00:55AM -0700, Simon Glass wrote:
>>>Hi Peng,
>>>
>>>On 15 February 2016 at 01:33, Peng Fan  wrote:
 Hi Simon,

 Gentle ping..
>>>
>>>Do you mean Stefan? I reviewed the previous so did not think it
>>>necessary to look again.
>>
>> In this V2 version, I addressed your comments for V1. Not sure whether
>> it's ok from your side :). This patch set was here for nearly two weeks.
>> If it's ok for you, please merge this patch set :).
>
>I can certainly do this, but shouldn't it go through the freescale tree?

I just think you are the owner of driver model tree :)
imx tree or your tree, both are ok for me.

Stefano, do you have time to review the patch set and merge?

Thanks,
Peng.

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Bin Meng]

On Wed, Feb 17, 2016 at 1:22 PM, Bin Meng  wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki  wrote:
>> On 15 February 2016 at 02:16, Jagan Teki  wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> ---
>>> cmd/sf.c
>>> ---
>>> spi_flash.c
>>> ---
>>> sf_probe.c
>>> ---
>>> spi-uclass
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> After SPI-NOR:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> SPI-NOR with MTD:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> MTD core
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Tested both DM and non-DM models
>>
>> Tested-by: Jagan Teki 
>
> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
> the SPI flash correctly, however after "reset" U-Boot still shows: ***
> Warning - bad CRC, using default environment
>
> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
> KiB, total 2 MiB
> *** Warning - bad CRC, using default environment
>
> Anything wrong?
>

Another testing on Intel Galileo shows that: it does NOT build for galileo.

arch/x86/lib/built-in.o: In function `mrccache_update':
arch/x86/lib/mrccache.c:142: undefined reference to `spi_flash_erase_dm'
arch/x86/lib/mrccache.c:153: undefined reference to `spi_flash_write_dm'

Did you run buildman for your whole series?

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Bin Meng]

Hi Jagan,

On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki  wrote:
> On 15 February 2016 at 02:16, Jagan Teki  wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> ---
>> cmd/sf.c
>> ---
>> spi_flash.c
>> ---
>> sf_probe.c
>> ---
>> spi-uclass
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> After SPI-NOR:
>>
>> --
>> cmd/sf.c
>> --
>> spi-nor.c
>> ---
>> m25p80.cspi nor drivers
>> ---
>> spi-uclass  SPI NOR chip
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> SPI-NOR with MTD:
>>
>> --
>> cmd/sf.c
>> --
>> MTD core
>> --
>> spi-nor.c
>> ---
>> m25p80.cspi nor drivers
>> ---
>> spi-uclass  SPI NOR chip
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>
> Tested both DM and non-DM models
>
> Tested-by: Jagan Teki 

My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
the SPI flash correctly, however after "reset" U-Boot still shows: ***
Warning - bad CRC, using default environment

spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
KiB, total 2 MiB
*** Warning - bad CRC, using default environment

Anything wrong?

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

Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman driver code

[Qianyu Gong]

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Wednesday, February 17, 2016 5:23 AM
> To: Qianyu Gong ; york sun ; u-
> b...@lists.denx.de
> Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman
> driver code
> 
> On Mon, 2016-02-15 at 05:44 +, Qianyu Gong wrote:
> > > -Original Message-
> > > From: york sun
> > > Sent: Friday, February 12, 2016 1:39 AM
> > > To: Scott Wood ; Qianyu Gong
> > > ; u- b...@lists.denx.de
> > > Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup
> > > to Fman driver code
> > >
> > > On 02/08/2016 11:25 AM, Scott Wood wrote:
> > > > On Mon, 2016-02-08 at 19:22 +, york sun wrote:
> > > > > On 02/08/2016 11:18 AM, Scott Wood wrote:
> > > > > > On Mon, 2016-02-08 at 19:03 +, york sun wrote:
> > > > > > > On 02/01/2016 09:06 AM, york sun wrote:
> > > > > > > > On 01/25/2016 09:40 PM, Qianyu Gong wrote:
> > > > > > > > >
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > > > > > > Sent: Tuesday, January 26, 2016 1:17 AM
> > > > > > > > > > To: Qianyu Gong ;
> > > > > > > > > > u-boot@lists.denx.de
> > > > > > > > > > Cc: b07...@freescale.com; Shaohui Xie
> > > > > > > > > > 
> > > > > > > > > > Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move
> > > > > > > > > > fman ucode fixup to Fman driver code
> > > > > > > > > >
> > > > > > > > > > On Mon, 2016-01-25 at 19:37 +0800, Gong Qianyu wrote:
> > > > > > > > > > > Both Freescale Layerscape and powerpc/mpc85xx
> > > > > > > > > > > platforms are using
> > > > > > > > > > > fdt_fixup_fman_firmware() to insert Fman ucode blob
> > > > > > > > > > > into the device tree. So move the function to driver
> > > > > > > > > > > code.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Gong Qianyu 
> > > > > > > > > > > ---
> > > > > > > > > > > V3:
> > > > > > > > > > >  - Remove file changes about "qe.h".
> > > > > > > > > > >(Should be put in the first patch of this
> > > > > > > > > > > patchset)
> > > > > > > > > > > V2:
> > > > > > > > > > >  - New patch.
> > > > > > > > > > >
> > > > > > > > > > >  arch/powerpc/cpu/mpc85xx/fdt.c | 125
> > > > > > > > > > > ++
> > > > > > > > > > > -
> > > > > > > > > > >  drivers/net/fm/Makefile|   1 +
> > > > > > > > > > >  drivers/net/fm/fdt.c   | 129
> > > > > > > > > > > +
> > > > > > > > > > >  include/fsl_fman.h |   1 +
> > > > > > > > > > >  4 files changed, 136 insertions(+), 120
> > > > > > > > > > > deletions(-)
> > > > > > > > > >
> > > > > > > > > > Again, pass -M -C to git format-patch.
> > > > > > > > > >
> > > > > > > > > > -Scott
> > > > > > > > >
> > > > > > > > > I don't understand but I've already used "git
> > > > > > > > > format-patch -M -C
> > > > > > > > > - -stat ...".
> > > > > > > > >
> > > > > > > >
> > > > > > > > Scott means using -M and -C, git should detect the moving
> > > > > > > > instead of adding and deleting the same code. Try to add
> > > > > > > > --find-copies-harder to see if it generates a smaller
> > > > > > > > patch.
> > > > > > > >
> > > > > > >
> > > > > > > Qianyu,
> > > > > > >
> > > > > > > Since you are on holiday, I tried it for you. Adjusting "-M -C"
> > > > > > > doesn't
> > > > > > > work.
> > > > > > > Even you are moving the function from one file to another,
> > > > > > > "git format -patch"
> > > > > > > cannot detect the moving because both files exist before and
> > > > > > > after this change, and the change set is not significant
> > > > > > > enough to be detected.
> > > > > >
> > > > > > It looks like the patch is creating drivers/net/fm/fdt.c...
> > > > > >
> > >
> > > Actually you were right. This patch creates a new file. There are
> > > also other small changes here and there. Maybe that's the reason git
> > > doesn't detect the move.
> > >
> > > Anyway, let me know if you have further comment. I am testing these
> > > patches.
> > >
> > > York
> >
> > Hi York,
> >
> > Thanks! I did make small changes in the function to make it work for
> > both powerpc and arm platforms.
> 
> Those changes should have been a separate patch -- otherwise it's a lot of 
> work to
> see what those changes are and review them.
> 
> -Scott

OK.. Thanks for your reminder.

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

Re: [U-Boot] [PATCH 22/30] dm: blk: Add a block-device uclass

[Bin Meng]

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Add a uclass for block devices. These provide block-oriented data access,
> supporting reading, writing and erasing of whole blocks.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/block/Kconfig  |  11 +++
>  drivers/block/Makefile |   2 +
>  drivers/block/blk-uclass.c | 175 
> +
>  include/blk.h  | 145 +
>  include/dm/uclass-id.h |   1 +
>  5 files changed, 334 insertions(+)
>  create mode 100644 drivers/block/blk-uclass.c
>

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

Re: [U-Boot] [PATCH V2 1/2] pinctrl: imx: Introduce pinctrl driver for i.MX6

[Simon Glass]

Hi Peng,

On 16 February 2016 at 19:45, Peng Fan  wrote:
> Hi Simon,
>
> On Tue, Feb 16, 2016 at 09:00:55AM -0700, Simon Glass wrote:
>>Hi Peng,
>>
>>On 15 February 2016 at 01:33, Peng Fan  wrote:
>>> Hi Simon,
>>>
>>> Gentle ping..
>>
>>Do you mean Stefan? I reviewed the previous so did not think it
>>necessary to look again.
>
> In this V2 version, I addressed your comments for V1. Not sure whether
> it's ok from your side :). This patch set was here for nearly two weeks.
> If it's ok for you, please merge this patch set :).

I can certainly do this, but shouldn't it go through the freescale tree?

[snip]

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

Re: [U-Boot] [PATCH V2 1/2] pinctrl: imx: Introduce pinctrl driver for i.MX6

[Peng Fan]

Hi Simon,

On Tue, Feb 16, 2016 at 09:00:55AM -0700, Simon Glass wrote:
>Hi Peng,
>
>On 15 February 2016 at 01:33, Peng Fan  wrote:
>> Hi Simon,
>>
>> Gentle ping..
>
>Do you mean Stefan? I reviewed the previous so did not think it
>necessary to look again.

In this V2 version, I addressed your comments for V1. Not sure whether
it's ok from your side :). This patch set was here for nearly two weeks.
If it's ok for you, please merge this patch set :).

Thanks,
Peng.

>
>>
>> Thanks,
>> Peng.
>
>Regards,
>Simon
>
>>
>> On Wed, Feb 03, 2016 at 10:06:07AM +0800, Peng Fan wrote:
>>>Introduce pinctrl for i.MX6
>>>1. pinctrl-imx.c is for common usage. It's used by i.MX6/7.
>>>2. Add PINCTRL_IMX PINCTRL_IMX6 Kconfig entry.
>>>3. To the pinctrl_ops implementation, only set_state is implemented.
>>>   To i.MX6/7, the pinctrl dts entry is as following:
>>> {
>>>pinctrl-names = "default";
>>>
>>>pinctrl_csi1: csi1grp {
>>>fsl,pins = <
>>>MX6UL_PAD_CSI_MCLK__CSI_MCLK0x1b088
>>>MX6UL_PAD_CSI_PIXCLK__CSI_PIXCLK0x1b088
>>>MX6UL_PAD_CSI_VSYNC__CSI_VSYNC  0x1b088
>>>>;
>>>};
>>>
>>>[.]
>>>};
>>>  there is no property named function or groups. So pinctrl_generic_set_state
>>>  can not be used here.
>>>5. This driver is a simple implementation for i.mx iomux controller,
>>>   only parse the fsl,pins property and write value to registers.
>>>6. With DEBUG enabled, we can see log when "i2c bus 0":
>>>   "
>>>   set_state_simple op missing
>>>   imx_pinctrl_set_state: i2c1grp
>>>   mux_reg 0x14c, conf_reg 0x3bc, input_reg 0x5d8, mux_mode 0x0, input_val 
>>> 0x1, config_val 0x407f
>>>   write mux: offset 0x14c val 0x10
>>>   select_input: offset 0x5d8 val 0x1
>>>   write config: offset 0x3bc val 0x7f
>>>   mux_reg 0x148, conf_reg 0x3b8, input_reg 0x5d4, mux_mode 0x0, input_val 
>>> 0x1, config_val 0x407f
>>>   write mux: offset 0x148 val 0x10
>>>   select_input: offset 0x5d4 val 0x1
>>>   write config: offset 0x3b8 val 0x7f
>>>   "
>>>   this means imx6 pinctrl driver works as expected.
>>>
>>>Signed-off-by: Peng Fan 
>>>Reviewed-by: Simon Glass 
>>>---
>>>
>>>V2:
>>> Add more details in Kconfig entry
>>> Use fdt_getprop and fdtdec_get_int_array as suggested by Simon
>>> Add reviewed-by Simon
>>> Refer linux binding doc in code.
>>>
>>> drivers/pinctrl/Kconfig|   1 +
>>> drivers/pinctrl/Makefile   |   1 +
>>> drivers/pinctrl/nxp/Kconfig|  16 +++
>>> drivers/pinctrl/nxp/Makefile   |   2 +
>>> drivers/pinctrl/nxp/pinctrl-imx.c  | 241 
>>> +
>>> drivers/pinctrl/nxp/pinctrl-imx.h  |  50 
>>> drivers/pinctrl/nxp/pinctrl-imx6.c |  41 +++
>>> 7 files changed, 352 insertions(+)
>>> create mode 100644 drivers/pinctrl/nxp/Kconfig
>>> create mode 100644 drivers/pinctrl/nxp/Makefile
>>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx.c
>>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx.h
>>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx6.c
>>>
>>>diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
>>>index 57e6142..9fd8f62 100644
>>>--- a/drivers/pinctrl/Kconfig
>>>+++ b/drivers/pinctrl/Kconfig
>>>@@ -133,6 +133,7 @@ config PINCTRL_SANDBOX
>>>
>>> endif
>>>
>>>+source "drivers/pinctrl/nxp/Kconfig"
>>> source "drivers/pinctrl/uniphier/Kconfig"
>>>
>>> endmenu
>>>diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
>>>index 70d25dc..dcd20bf 100644
>>>--- a/drivers/pinctrl/Makefile
>>>+++ b/drivers/pinctrl/Makefile
>>>@@ -5,6 +5,7 @@
>>> obj-y += pinctrl-uclass.o
>>> obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC)  += pinctrl-generic.o
>>>
>>>+obj-y += nxp/
>>> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
>>> obj-$(CONFIG_PINCTRL_SANDBOX) += pinctrl-sandbox.o
>>>
>>>diff --git a/drivers/pinctrl/nxp/Kconfig b/drivers/pinctrl/nxp/Kconfig
>>>new file mode 100644
>>>index 000..f1c9b92
>>>--- /dev/null
>>>+++ b/drivers/pinctrl/nxp/Kconfig
>>>@@ -0,0 +1,16 @@
>>>+config PINCTRL_IMX
>>>+  bool
>>>+
>>>+config PINCTRL_IMX6
>>>+  bool "IMX6 pinctrl driver"
>>>+  depends on ARCH_MX6 && PINCTRL_FULL
>>>+  select DEVRES
>>>+  select PINCTRL_IMX
>>>+  help
>>>+Say Y here to enable the imx6 pinctrl driver
>>>+
>>>+This provides a simple pinctrl driver for i.MX6 SoC familiy,
>>>+i.MX6DQ/SL/SX/UL/DQP. This feature depends on device tree
>>>+configuration. This driver is different from the linux one,
>>>+this is a simple implementation, only parses the 'fsl,pins'
>>>+property and configure related registers.
>>>diff --git a/drivers/pinctrl/nxp/Makefile b/drivers/pinctrl/nxp/Makefile
>>>new file mode 100644
>>>index 000..7fd9850
>>>--- /dev/null
>>>+++ b/drivers/pinctrl/nxp/Makefile
>>>@@ -0,0 +1,2 @@

Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

[Simon Glass]

Hi Tom,

On 16 February 2016 at 13:13, Tom Warren  wrote:
> Simon,
>
> 
>
>> >>
>> >> I think it was the follow-up patches to add the environment
>> >> work-around that was applied.
>> >>
>> >> 6c88b51 video: tegra: Enable the 'lcd' env variable work-around
>> >> a2931b3 dm: video: Add a temporary work-around for old stdout var
>> >>
>> >> I see the original v2 series here:
>> >>
>> >> http://patchwork.ozlabs.org/project/uboot/list/?delegate=4839
>> >>
>> >> so that is what needs to be applied I think. Then the Tegra config
>> >> issue should be fixed.
>> > I've applied the 23 v2 DM video patches to u-boot-tegra/master, then
>> rebased against current u-boot/master.
>> >
>> > I see the 'warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which
>> has unmet direct dependencies (DM_VIDEO)' spew for almost every board
>> (w/MAKEALL -s tegra).
>> >
>> > Am I missing some patches?
>>
>> I'll make some time to look but I am tied up most of the day so it will be 
>> later,
>> sorry.
>>
>> The original series is at u-boot-dm/rke-working if that helps.
> I pulled down rke-working. The two commits you list above are *not* in that 
> repo/branch. They _are_ in my u-boot-tegra/next branch (just pushed it to 
> Denx).
> So building rke-working for tegra doesn't result in the DM_VIDEO warning, 
> since the commits aren't there.
>
> Back to you.
>
> Tom

I found that tegra boards without the display enabled generate this
warning. I've sent a patch.

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

[U-Boot] [PATCH] video: tegra: Correct a Kconfig warning with VIDCONSOLE_AS_LCD

[Simon Glass]

This new feature causes a Kconfig warning on boards without a display
enabled. Fix this.

Signed-off-by: Simon Glass 
---

 arch/arm/mach-tegra/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 3540eda..ba6983f 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -14,7 +14,7 @@ config TEGRA_COMMON
select DM_SPI
select DM_SPI_FLASH
select OF_CONTROL
-   select VIDCONSOLE_AS_LCD
+   select VIDCONSOLE_AS_LCD if DM_VIDEO
 
 config TEGRA_ARMV7_COMMON
bool "Tegra 32-bit common options"
-- 
2.7.0.rc3.207.g0ac5344

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

Re: [U-Boot] [PATCH 02/30] dm: pci: Break out the common region display code

[Stephen Warren]

On 02/14/2016 07:16 PM, Simon Glass wrote:

Each region is displayed in almost the same way. Break out this common code
into its own function.



diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c



+   if (hose->pci_mem)
+   pciauto_show_region("Memory", hose->pci_mem);
+   if (hose->pci_prefetch)
+   pciauto_show_region("Prefetchable Mem", hose->pci_mem);


That parameter should be hose->pci_prefetch


+   if (hose->pci_io)
+   pciauto_show_region("I/O", hose->pci_io);


With that fixed, the "dhcp" failure I mentioned earlier is fixed (the 
system in question uses PCIe Ethernet).

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

Re: [U-Boot] [PATCH 00/30] dm: Add driver-model support for block drivers

[Stephen Warren]

On 02/14/2016 07:16 PM, Simon Glass wrote:

Recent additions of the MMC and DISK uclasses have indicated that it is time
to look at adding a uclass for block devices. This series does this and
includes a few clean-ups to the partition code also.

A block device is typically a child device of its storage parent. For
example an MMC device will have a block-device child. A USB storage device
may have multiple block-device children, one for each LUN.

With this series only USB storage and 'host' are converted over to use the
new support. Several more remain, including SCSI, IDE and MMC. Each of these
should get its own uclass.

The uclass implements only a few basic features. A few tests are added to
check that things work as expected.

The code size impact of switching to driver model for block devices is
small. One benefit is that it becomes possible to enumerate all block
devices, regardless of their type.


This series looks OK, and I would give it an Acked-by, except that it 
seems to break DFU to SD card on the 3 systems where I'm running 
test/py, and even cause "dhcp" to fail on one of them (that could be 
either memory corruption caused by these patches, or pre-existing 
corruption that these patches shuffle around in memory so it only now 
causes a problem). I'll see if I can bisect these down to a specific 
patch in the series and see what's up.

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

Re: [U-Boot] [PATCH 24/30] dm: sandbox: Add driver-model block-device support for sandbox

[Stephen Warren]

On 02/14/2016 07:16 PM, Simon Glass wrote:

Update the host driver to support driver model for block devices. A future
commit will remove the old code, but for now it is useful to be able to use
it both with and without CONFIG_BLK.



diff --git a/drivers/block/sandbox.c b/drivers/block/sandbox.c



+#ifdef CONFIG_BLK
+int host_dev_bind(int devnum, char *filename)
+{
+   struct host_block_dev *host_dev;
+   struct udevice *dev;
+   char dev_name[20], *str, *fname;

...

+   sprintf(dev_name, "host%d", devnum);


Use snprintf() to avoid overflow?


+   str = strdup(dev_name);
+   if (!str)
+   return -ENOMEM;
+   fname = strdup(filename);
+   if (!fname) {
+   free(str);
+   return -ENOMEM;
+   }


Do those get free()d somewhere on unbind?

Actually, I don't see any unbind() function in this file (even before 
this patch).

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

Re: [U-Boot] [PATCH 18/30] dm: block: Rename device number member dev to devnum

[Stephen Warren]

On 02/14/2016 07:16 PM, Simon Glass wrote:

This is a device number, and we want to use 'dev' to mean a driver model
device. Rename the member.



diff --git a/cmd/cbfs.c b/cmd/cbfs.c
index cdfc9b6..779e9c0 100644
--- a/cmd/cbfs.c
+++ b/cmd/cbfs.c
@@ -141,6 +141,7 @@ int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
*const argv[])
type_name = "cmos layout";
break;
case -1:
+   case 0:
type_name = "null";
break;
}


Should that be part of the earlier cbfs fix patch?

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

Re: [U-Boot] arm: at91: Add support for DENX MA5D4 SoM and EVK

[Andreas Bießmann]

On Thu, Feb 11, 2016 at 02:13:38PM +0100, Marek Vasut wrote:
> Add support for DENX MA5D4 SoM and MA5D4EVK board, based on the
> Atmel SAMA5D4 SoC. The SoM contains the SoC, eMMC, SPI NOR, SPI
> CAN controllers and DRAM, the baseboard contains UART connectors,
> ethernet port, microSD slot, LCD header, 2x CAN connector and a
> lot of expansion headers.
> 
> Signed-off-by: Marek Vasut 
> Cc: Andreas Bießmann 
> Reviewed-by: Heiko Schocher 

Reviewed-by: Andreas Bießmann 

> ---
> V2: Remove the BDI commands, that was just a development remnant
> ---
>  arch/arm/mach-at91/Kconfig  |   6 +
>  board/denx/ma5d4evk/Kconfig |  12 ++
>  board/denx/ma5d4evk/MAINTAINERS |   6 +
>  board/denx/ma5d4evk/Makefile|   7 +
>  board/denx/ma5d4evk/ma5d4evk.c  | 412 
> 
>  configs/ma5d4evk_defconfig  |  11 ++
>  include/configs/ma5d4evk.h  | 255 +
>  7 files changed, 709 insertions(+)
>  create mode 100644 board/denx/ma5d4evk/Kconfig
>  create mode 100644 board/denx/ma5d4evk/MAINTAINERS
>  create mode 100644 board/denx/ma5d4evk/Makefile
>  create mode 100644 board/denx/ma5d4evk/ma5d4evk.c
>  create mode 100644 configs/ma5d4evk_defconfig
>  create mode 100644 include/configs/ma5d4evk.h
> 
> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
> index 9426302b..88ccf23 100644
> --- a/arch/arm/mach-at91/Kconfig
> +++ b/arch/arm/mach-at91/Kconfig
> @@ -96,6 +96,11 @@ config TARGET_SAMA5D4EK
>   select CPU_V7
>   select SUPPORT_SPL
>  
> +config TARGET_MA5D4EVK
> + bool "DENX MA5D4EVK Evaluation Kit"
> + select CPU_V7
> + select SUPPORT_SPL
> +
>  config TARGET_MEESC
>   bool "Support meesc"
>   select CPU_ARM926EJS
> @@ -135,6 +140,7 @@ source "board/atmel/sama5d4_xplained/Kconfig"
>  source "board/atmel/sama5d4ek/Kconfig"
>  source "board/bluewater/snapper9260/Kconfig"
>  source "board/calao/usb_a9263/Kconfig"
> +source "board/denx/ma5d4evk/Kconfig"
>  source "board/egnite/ethernut5/Kconfig"
>  source "board/esd/meesc/Kconfig"
>  source "board/mini-box/picosam9g45/Kconfig"
> diff --git a/board/denx/ma5d4evk/Kconfig b/board/denx/ma5d4evk/Kconfig
> new file mode 100644
> index 000..b4ef106
> --- /dev/null
> +++ b/board/denx/ma5d4evk/Kconfig
> @@ -0,0 +1,12 @@
> +if TARGET_MA5D4EVK
> +
> +config SYS_BOARD
> + default "ma5d4evk"
> +
> +config SYS_VENDOR
> + default "denx"
> +
> +config SYS_CONFIG_NAME
> + default "ma5d4evk"
> +
> +endif
> diff --git a/board/denx/ma5d4evk/MAINTAINERS b/board/denx/ma5d4evk/MAINTAINERS
> new file mode 100644
> index 000..bb25a9c
> --- /dev/null
> +++ b/board/denx/ma5d4evk/MAINTAINERS
> @@ -0,0 +1,6 @@
> +DENX MA5D4EVK BOARD
> +M:   Marek Vasut 
> +S:   Maintained
> +F:   board/denx/ma5d4evk/
> +F:   include/configs/ma5d4evk.h
> +F:   configs/ma5d4evk_defconfig
> diff --git a/board/denx/ma5d4evk/Makefile b/board/denx/ma5d4evk/Makefile
> new file mode 100644
> index 000..b12b5dc
> --- /dev/null
> +++ b/board/denx/ma5d4evk/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Copyright (C) 2015 Marek Vasut 
> +#
> +# SPDX-License-Identifier:   GPL-2.0+
> +#
> +
> +obj-y += ma5d4evk.o
> diff --git a/board/denx/ma5d4evk/ma5d4evk.c b/board/denx/ma5d4evk/ma5d4evk.c
> new file mode 100644
> index 000..ec0fa28
> --- /dev/null
> +++ b/board/denx/ma5d4evk/ma5d4evk.c
> @@ -0,0 +1,412 @@
> +/*
> + * Copyright (C) 2015 Marek Vasut 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#ifdef CONFIG_ATMEL_SPI
> +int spi_cs_is_valid(unsigned int bus, unsigned int cs)
> +{
> + return bus == 0 && cs == 0;
> +}
> +
> +void spi_cs_activate(struct spi_slave *slave)
> +{
> + at91_set_pio_output(AT91_PIO_PORTC, 3, 0);
> +}
> +
> +void spi_cs_deactivate(struct spi_slave *slave)
> +{
> + at91_set_pio_output(AT91_PIO_PORTC, 3, 1);
> +}
> +
> +static void ma5d4evk_spi0_hw_init(void)
> +{
> + at91_set_a_periph(AT91_PIO_PORTC, 0, 0);/* SPI0_MISO */
> + at91_set_a_periph(AT91_PIO_PORTC, 1, 0);/* SPI0_MOSI */
> + at91_set_a_periph(AT91_PIO_PORTC, 2, 0);/* SPI0_SPCK */
> +
> + at91_set_pio_output(AT91_PIO_PORTC, 3, 1);  /* SPI0_CS0 */
> +
> + /* Enable clock */
> + at91_periph_clk_enable(ATMEL_ID_SPI0);
> +}
> +#endif /* CONFIG_ATMEL_SPI */
> +
> +#ifdef CONFIG_CMD_USB
> +static void ma5d4evk_usb_hw_init(void)
> +{
> + at91_set_pio_output(AT91_PIO_PORTE, 11, 0);
> + at91_set_pio_output(AT91_PIO_PORTE, 14, 0);
> +}
> +#endif
> +
> +#ifdef CONFIG_LCD
> +vidinfo_t panel_info = {
> + .vl_col

Re: [U-Boot] [PATCH 10/30] dm: blk: Rename get_device() to blk_get_device_str()

[Stephen Warren]

On 02/14/2016 07:16 PM, Simon Glass wrote:

The current name is too generic. The function returns a block device based
on a provided string. Rename it to aid searching and make its purpose
clearer. Also add a few comments.



+int blk_get_device_str(const char *ifname, const char *dev_str,
+  struct blk_desc **dev_desc);


Bikeshed: s/_str/_by_str/? Otherwise it somewhat sounds like it returns 
a "device_str" rather than returns a "device" and searches for it using 
a "str".


Of course, this is a really annoying comment that would cause a large 
amount of work, so feel free to ignore it.

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

Re: [U-Boot] siemens,at91: enable features for smartweb

[Andreas Bießmann]

On Wed, Jan 27, 2016 at 03:56:07PM +0100, Egli, Samuel wrote:
> From: Matthias Michel 
> 
> New features for smartweb:
> * switch to hush command parser
> * change autoboot stop to 
> * allow to write ethaddr
> 
> Signed-off-by: Matthias Michel 
> Reviewed-by: Samuel Egli 
> Cc: Roger Meier 
> Cc: Heiko Schocher 
> Reviewed-by: Heiko Schocher 

Reviewed-by: Andreas Bießmann 

> ---
>  configs/smartweb_defconfig |  5 -
>  include/configs/smartweb.h | 14 ++
>  2 files changed, 14 insertions(+), 5 deletions(-)
> 
> diff --git a/configs/smartweb_defconfig b/configs/smartweb_defconfig
> index ee4340f..654bb4b 100644
> --- a/configs/smartweb_defconfig
> +++ b/configs/smartweb_defconfig
> @@ -3,4 +3,7 @@ CONFIG_ARCH_AT91=y
>  CONFIG_TARGET_SMARTWEB=y
>  CONFIG_SPL=y
>  CONFIG_SYS_EXTRA_OPTIONS="AT91SAM9260"
> -CONFIG_SYS_PROMPT="U-Boot> "
> +CONFIG_SYS_PROMPT="U-Boot# "
> +CONFIG_AUTOBOOT_KEYED=y
> +CONFIG_AUTOBOOT_PROMPT="Autobooting in %d seconds, press \"\" to 
> stop\n"
> +CONFIG_AUTOBOOT_STOP_STR="\x1b\x1b"
> diff --git a/include/configs/smartweb.h b/include/configs/smartweb.h
> index 44d1d5a..de7b6bc 100644
> --- a/include/configs/smartweb.h
> +++ b/include/configs/smartweb.h
> @@ -49,10 +49,18 @@
>  #define CONFIG_BOARD_EARLY_INIT_F/* call board_early_init_f() */
>  #define CONFIG_DISPLAY_CPUINFO   /* display CPU Info at startup 
> */
>  
> +/* We set the max number of command args high to avoid HUSH bugs. */
> +#define CONFIG_SYS_MAXARGS32
> +
>  /* setting board specific options */
> -# define CONFIG_MACH_TYPEMACH_TYPE_SMARTWEB
> -#define CONFIG_CMDLINE_EDITING
> +#define CONFIG_MACH_TYPE MACH_TYPE_SMARTWEB
> +#define CONFIG_AUTO_COMPLETE
> +#define CONFIG_ENV_OVERWRITE1 /* Overwrite ethaddr / serial# */
> +#define CONFIG_SYS_HUSH_PARSER/* use "hush" command parser */
> +#define CONFIG_SYS_PROMPT_HUSH_PS2  "> "
>  #define CONFIG_AUTO_COMPLETE
> +#define CONFIG_SYS_AUTOLOAD "yes"
> +#define CONFIG_RESET_TO_RETRY
>  
>  /* The LED PINs */
>  #define CONFIG_RED_LED   AT91_PIN_PA9
> @@ -184,9 +192,7 @@
>  /* General Boot Parameter */
>  #define CONFIG_BOOTDELAY 3
>  #define CONFIG_BOOTCOMMAND   "run flashboot"
> -#define CONFIG_BOOT_RETRY_TIME  30
>  #define CONFIG_SYS_CBSIZE512
> -#define CONFIG_SYS_MAXARGS   16
>  #define CONFIG_SYS_PBSIZE \
>   (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16)
>  #define CONFIG_SYS_LONGHELP
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2] ARM: at91: sama5d2: configure the L2 cache memory

[Andreas Bießmann]

On Tue, Feb 16, 2016 at 09:45:06AM +0100, Samuel Mescoff wrote:
> The SAMA5D2 has a second internal SRAM that can be reassigned as a L2
> cache memory.
> Make sure it is configured as a L2 cache memory when booting from a SPL
> image.
> 
> Based on the commit b5ea95ef2b5b from the at91bootstrap repository.
> 
> Signed-off-by: Samuel Mescoff 
> Reviewed-by: Wenyou Yang 

Reviewed-by: Andreas Bießmann 

> ---
> 
> Changes for v2:
>  - removed useless #ifdef CONFIG_SAMA5D2
> 
>  arch/arm/mach-at91/atmel_sfr.c| 7 +++
>  arch/arm/mach-at91/include/mach/at91_common.h | 1 +
>  arch/arm/mach-at91/include/mach/sama5_sfr.h   | 1 +
>  arch/arm/mach-at91/spl_atmel.c| 4 
>  4 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/atmel_sfr.c b/arch/arm/mach-at91/atmel_sfr.c
> index 2bccb84..adf44c6 100644
> --- a/arch/arm/mach-at91/atmel_sfr.c
> +++ b/arch/arm/mach-at91/atmel_sfr.c
> @@ -19,3 +19,10 @@ void redirect_int_from_saic_to_aic(void)
>   writel((key32 | ATMEL_SFR_AICREDIR_NSAIC), >aicredir);
>   }
>  }
> +
> +void configure_2nd_sram_as_l2_cache(void)
> +{
> + struct atmel_sfr *sfr = (struct atmel_sfr *)ATMEL_BASE_SFR;
> +
> + writel(1, >l2cc_hramc);
> +}
> diff --git a/arch/arm/mach-at91/include/mach/at91_common.h 
> b/arch/arm/mach-at91/include/mach/at91_common.h
> index efcd74e..0742ffc 100644
> --- a/arch/arm/mach-at91/include/mach/at91_common.h
> +++ b/arch/arm/mach-at91/include/mach/at91_common.h
> @@ -34,5 +34,6 @@ void at91_spl_board_init(void);
>  void at91_disable_wdt(void);
>  void matrix_init(void);
>  void redirect_int_from_saic_to_aic(void);
> +void configure_2nd_sram_as_l2_cache(void);
>  
>  #endif /* AT91_COMMON_H */
> diff --git a/arch/arm/mach-at91/include/mach/sama5_sfr.h 
> b/arch/arm/mach-at91/include/mach/sama5_sfr.h
> index 7b19a20..b040256 100644
> --- a/arch/arm/mach-at91/include/mach/sama5_sfr.h
> +++ b/arch/arm/mach-at91/include/mach/sama5_sfr.h
> @@ -25,6 +25,7 @@ struct atmel_sfr {
>   u32 sn0;/* 0x4c */
>   u32 sn1;/* 0x50 */
>   u32 aicredir;   /* 0x54 */
> + u32 l2cc_hramc; /* 0x58 */
>  };
>  
>  /* Bit field in DDRCFG */
> diff --git a/arch/arm/mach-at91/spl_atmel.c b/arch/arm/mach-at91/spl_atmel.c
> index b2fb51d..688289e 100644
> --- a/arch/arm/mach-at91/spl_atmel.c
> +++ b/arch/arm/mach-at91/spl_atmel.c
> @@ -79,6 +79,10 @@ void board_init_f(ulong dummy)
>  {
>   switch_to_main_crystal_osc();
>  
> +#ifdef CONFIG_SAMA5D2
> + configure_2nd_sram_as_l2_cache();
> +#endif
> +
>   /* disable watchdog */
>   at91_disable_wdt();
>  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2] ARM: at91: sama5d2: configure the L2 cache memory

[Andreas Bießmann]

On Tue, Feb 16, 2016 at 09:45:06AM +0100, Samuel Mescoff wrote:
> The SAMA5D2 has a second internal SRAM that can be reassigned as a L2
> cache memory.
> Make sure it is configured as a L2 cache memory when booting from a SPL
> image.
> 
> Based on the commit b5ea95ef2b5b from the at91bootstrap repository.
> 
> Signed-off-by: Samuel Mescoff 
> Reviewed-by: Wenyou Yang 

Reviewed-by: Andreas Bießmann 

> ---
> 
> Changes for v2:
>  - removed useless #ifdef CONFIG_SAMA5D2
> 
>  arch/arm/mach-at91/atmel_sfr.c| 7 +++
>  arch/arm/mach-at91/include/mach/at91_common.h | 1 +
>  arch/arm/mach-at91/include/mach/sama5_sfr.h   | 1 +
>  arch/arm/mach-at91/spl_atmel.c| 4 
>  4 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/atmel_sfr.c b/arch/arm/mach-at91/atmel_sfr.c
> index 2bccb84..adf44c6 100644
> --- a/arch/arm/mach-at91/atmel_sfr.c
> +++ b/arch/arm/mach-at91/atmel_sfr.c
> @@ -19,3 +19,10 @@ void redirect_int_from_saic_to_aic(void)
>   writel((key32 | ATMEL_SFR_AICREDIR_NSAIC), >aicredir);
>   }
>  }
> +
> +void configure_2nd_sram_as_l2_cache(void)
> +{
> + struct atmel_sfr *sfr = (struct atmel_sfr *)ATMEL_BASE_SFR;
> +
> + writel(1, >l2cc_hramc);
> +}
> diff --git a/arch/arm/mach-at91/include/mach/at91_common.h 
> b/arch/arm/mach-at91/include/mach/at91_common.h
> index efcd74e..0742ffc 100644
> --- a/arch/arm/mach-at91/include/mach/at91_common.h
> +++ b/arch/arm/mach-at91/include/mach/at91_common.h
> @@ -34,5 +34,6 @@ void at91_spl_board_init(void);
>  void at91_disable_wdt(void);
>  void matrix_init(void);
>  void redirect_int_from_saic_to_aic(void);
> +void configure_2nd_sram_as_l2_cache(void);
>  
>  #endif /* AT91_COMMON_H */
> diff --git a/arch/arm/mach-at91/include/mach/sama5_sfr.h 
> b/arch/arm/mach-at91/include/mach/sama5_sfr.h
> index 7b19a20..b040256 100644
> --- a/arch/arm/mach-at91/include/mach/sama5_sfr.h
> +++ b/arch/arm/mach-at91/include/mach/sama5_sfr.h
> @@ -25,6 +25,7 @@ struct atmel_sfr {
>   u32 sn0;/* 0x4c */
>   u32 sn1;/* 0x50 */
>   u32 aicredir;   /* 0x54 */
> + u32 l2cc_hramc; /* 0x58 */
>  };
>  
>  /* Bit field in DDRCFG */
> diff --git a/arch/arm/mach-at91/spl_atmel.c b/arch/arm/mach-at91/spl_atmel.c
> index b2fb51d..688289e 100644
> --- a/arch/arm/mach-at91/spl_atmel.c
> +++ b/arch/arm/mach-at91/spl_atmel.c
> @@ -79,6 +79,10 @@ void board_init_f(ulong dummy)
>  {
>   switch_to_main_crystal_osc();
>  
> +#ifdef CONFIG_SAMA5D2
> + configure_2nd_sram_as_l2_cache();
> +#endif
> +
>   /* disable watchdog */
>   at91_disable_wdt();
>  
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] mxsboot: remove unused include

[Marek Vasut]

On 02/16/2016 11:29 PM, Andreas Bießmann wrote:
> Commit 276d3ebb883024d753cd9c69ab2fd243ffa1262e removed htole32() but missed
> to remove the corresponding header. This is annoying, since BSD systems do not
> have endian.h.
> 
> Signed-off-by: Andreas Bießmann 
Nice, thanks!

Acked-by: Marek Vasut 

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

[U-Boot] [PATCH 4/4] pci_rom: fix may be used uninitialized warning

[Andreas Bießmann]

Building pci_rom.c with my toolchain complains about may be used uninitialized
rom varaible:

---8<---
+drivers/pci/pci_rom.c:269:25: note: 'rom' was declared here
w+drivers/pci/pci_rom.c: In function 'dm_pci_run_vga_bios':
w+drivers/pci/pci_rom.c:154:14: warning: 'rom' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
--->8---

Fix this as done in 55616b86c745fcac5a791268ab8e7cba36965c0f the ram variable.

Signed-off-by: Andreas Bießmann 
---

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

diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index d5bf6f4..9eb605b 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -266,7 +266,7 @@ int dm_pci_run_vga_bios(struct udevice *dev, int 
(*int15_handler)(void),
int exec_method)
 {
struct pci_child_platdata *pplat = dev_get_parent_platdata(dev);
-   struct pci_rom_header *rom, *ram = NULL;
+   struct pci_rom_header *rom = NULL, *ram = NULL;
int vesa_mode = -1;
bool emulate, alloced;
int ret;
-- 
2.5.4 (Apple Git-61)

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

[U-Boot] [PATCH 0/4] Some things that bug me

[Andreas Bießmann]

These are some fixes to the current TOT that break my test building on OS X.
Maybe some of them already addressed by some other patches. If so, please just
drop the corresponding patch from the series.


Andreas Bießmann (4):
  tools: -Wno-deprecated-declarations for OpenSSL on darwin
  mxsboot: remove unused include
  samsung: fix mkorigenspl for darwin
  pci_rom: fix may be used uninitialized warning

 board/samsung/origen/tools/mkorigenspl.c | 4 ++--
 drivers/pci/pci_rom.c| 2 +-
 tools/Makefile   | 8 
 tools/mxsboot.c  | 1 -
 4 files changed, 11 insertions(+), 4 deletions(-)

-- 
2.5.4 (Apple Git-61)

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

[U-Boot] [PATCH 3/4] samsung: fix mkorigenspl for darwin

[Andreas Bießmann]

Compiling the mkorigenspl tool on darwin complains about undefined ulong. Fix
this by using the unified way.

Signed-off-by: Andreas Bießmann 
---

 board/samsung/origen/tools/mkorigenspl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/samsung/origen/tools/mkorigenspl.c 
b/board/samsung/origen/tools/mkorigenspl.c
index 8b0c3ac..7b5d93b 100644
--- a/board/samsung/origen/tools/mkorigenspl.c
+++ b/board/samsung/origen/tools/mkorigenspl.c
@@ -83,8 +83,8 @@ int main(int argc, char **argv)
for (i = 0; i < IMG_SIZE - SPL_HEADER_SIZE; i++)
checksum += buffer[i+16];
 
-   *(ulong *)buffer ^= 0x1f;
-   *(ulong *)(buffer+4) ^= checksum;
+   *(unsigned long *)buffer ^= 0x1f;
+   *(unsigned long *)(buffer+4) ^= checksum;
 
for (i = 1; i < SPL_HEADER_SIZE; i++)
buffer[i] ^= buffer[i-1];
-- 
2.5.4 (Apple Git-61)

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

[U-Boot] [PATCH 1/4] tools: -Wno-deprecated-declarations for OpenSSL on darwin

[Andreas Bießmann]

Since OpenSSL is deprecated on OS X in favour of Common Crypto API disable the
warning for this host OS.

Another solution would be to add some glue layer for crypto stuff, but I think
this is not worth the effort.

Signed-off-by: Andreas Bießmann 
---

 tools/Makefile | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/Makefile b/tools/Makefile
index 1382b05..2881a7c 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -129,6 +129,14 @@ endif
 ifneq ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_FIT_SIGNATURE),)
 HOSTLOADLIBES_mkimage += \
$(shell pkg-config --libs libssl libcrypto 2> /dev/null || echo "-lssl 
-lcrypto")
+
+# OS X deprecate openssl in favour of CommonCrypto, supress deprecation
+# warnings on those systems
+ifeq ($(HOSTOS),darwin)
+HOSTCFLAGS_mxsimage.o += -Wno-deprecated-declarations
+HOSTCFLAGS_image-sig.o += -Wno-deprecated-declarations
+HOSTCFLAGS_rsa-sign.o += -Wno-deprecated-declarations
+endif
 endif
 
 HOSTLOADLIBES_dumpimage := $(HOSTLOADLIBES_mkimage)
-- 
2.5.4 (Apple Git-61)

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

[U-Boot] [PATCH 2/4] mxsboot: remove unused include

[Andreas Bießmann]

Commit 276d3ebb883024d753cd9c69ab2fd243ffa1262e removed htole32() but missed
to remove the corresponding header. This is annoying, since BSD systems do not
have endian.h.

Signed-off-by: Andreas Bießmann 
---

 tools/mxsboot.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/mxsboot.c b/tools/mxsboot.c
index 457f435..2e72009 100644
--- a/tools/mxsboot.c
+++ b/tools/mxsboot.c
@@ -7,7 +7,6 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
 #include 
 #include 
 #include 
-- 
2.5.4 (Apple Git-61)

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

Re: [U-Boot] [PATCH 00/16] image: Fix various test failures

[Stephen Warren]

On 02/14/2016 06:36 PM, Simon Glass wrote:

Recent changes have broken the FIT and vboot tests. Also the SPI tests have
been wrong since before the last release and were disabled.

This series collects together the required fixes.

Note: The FIT and vboot tests are hard to run (in that each requires manual
effort). At some point we should be able to bring these into Stephen Warren's
test framework.


The series,
Tested-by: Stephen Warren 
(via ./test/py/test.py --bd sandbox --build)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] test/py main_signon

[Stephen Warren]

On 02/16/2016 12:08 PM, Michal Simek wrote:

Hi Stephen,

2016-02-16 17:39 GMT+01:00 Stephen Warren >:

On 02/16/2016 09:04 AM, Michal Simek wrote:

Hi Heiko,

On 16.2.2016 14:32, Heiko Schocher wrote:

Hello Michal,

Am 16.02.2016 um 13:12 schrieb Michal Simek:

Hi Stephen,

trying to run the latest testing on zynq board and
getting this
main_signon error.

This is what I am running
./test/py/test.py --bd zynq_zc702  --build
--board-identity zc702
and getting below.


Does this board has SPL support without SPL serial output?


I do load u-boot via jtag that's why SPL logs are not visible.

If so, can you try my patch:
http://patchwork.ozlabs.org/patch/583348/


I have applied your patch but it is still not working.

If I run full flow with SPL then I can't see any issue.


I assume this is resolved then?


Unfortunately both cases should work because SPL is not only one first
stage bootloader
which can be used. I didn't test zynqmp but there is no SPL and the same
problem is
probably there too. Or is there any dependency that if SPL is not build
than testing system
is not expecting it?

I will look tmr at jtag boot mode with SPL if I can get it work.


The test scripts currently assume that if SPL is enabled in the U-Boot 
configuration file, then U-Boot SPL will run and print its signon 
message to the serial console. If you're starting U-Boot using a 
technique that invalidates this assumption, it won't work currently, as 
you found.


It's pretty easy to add a flag in the boardenv file to tell the system 
not to expect SPL signon. If you take a look at my second suggestion in:


http://lists.denx.de/pipermail/u-boot/2016-February/245759.html
[U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses 
serial output


... then it's probably a simple as adding a third variable into the if 
condition, where that variable gets looks up from the "board 
environment", similar to:


spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] tools: kwboot: Clean up usage text

[Kevin Smith]

Usage text was getting unwieldy and somewhat incorrect.  The
usage summary implied that some options were mutually exclusive
(e.g. -q or -s).  Clean up the summary to just include the
important ones, and include a generic "[OPTIONS]" instead.

Signed-off-by: Kevin Smith 
Cc: Stefan Roese 
---
 tools/kwboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index c5f4492..6d1f66e 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -674,7 +674,7 @@ static void
 kwboot_usage(FILE *stream, char *progname)
 {
fprintf(stream,
-   "Usage: %s [-d | -a | -q  | -s  | -b 
 | -D  ] [ -t ] [-B  ] \n",
+   "Usage: %s [OPTIONS] [-b  | -D  ] [-B  ] 
\n",
progname);
fprintf(stream, "\n");
fprintf(stream,
-- 
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] tools: kwboot: Add xmodem timeout option

[Kevin Smith]

Add command-line specification of xmodem timeout.  If the binary
header needs to take a while to do something (e.g. DDR ECC
scrubbing), the xmodem transfer can time out.  Add a configurable
xmodem block timeout to allow transfers with slow binary headers
to succeed.

Signed-off-by: Kevin Smith 
Cc: Stefan Roese 
---
 tools/kwboot.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 6d1f66e..2bd56eb 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -74,6 +74,7 @@ static int kwboot_verbose;
 
 static int msg_req_delay = KWBOOT_MSG_REQ_DELAY;
 static int msg_rsp_timeo = KWBOOT_MSG_RSP_TIMEO;
+static int blk_rsp_timeo = KWBOOT_BLK_RSP_TIMEO;
 
 static void
 kwboot_printv(const char *fmt, ...)
@@ -378,7 +379,7 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block)
break;
 
do {
-   rc = kwboot_tty_recv(fd, , 1, KWBOOT_BLK_RSP_TIMEO);
+   rc = kwboot_tty_recv(fd, , 1, blk_rsp_timeo);
if (rc)
break;
 
@@ -686,6 +687,8 @@ kwboot_usage(FILE *stream, char *progname)
fprintf(stream, "  -a: use timings for Armada XP\n");
fprintf(stream, "  -q :  use specific request-delay\n");
fprintf(stream, "  -s : use specific response-timeout\n");
+   fprintf(stream,
+   "  -o : use specific xmodem block timeout\n");
fprintf(stream, "\n");
fprintf(stream, "  -t: mini terminal\n");
fprintf(stream, "\n");
@@ -718,7 +721,7 @@ main(int argc, char **argv)
kwboot_verbose = isatty(STDOUT_FILENO);
 
do {
-   int c = getopt(argc, argv, "hb:ptaB:dD:q:s:");
+   int c = getopt(argc, argv, "hb:ptaB:dD:q:s:o:");
if (c < 0)
break;
 
@@ -758,6 +761,10 @@ main(int argc, char **argv)
msg_rsp_timeo = atoi(optarg);
break;
 
+   case 'o':
+   blk_rsp_timeo = atoi(optarg);
+   break;
+
case 'B':
speed = kwboot_tty_speed(atoi(optarg));
if (speed == -1)
-- 
2.4.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to Fman driver code

[Scott Wood]

On Mon, 2016-02-15 at 05:44 +, Qianyu Gong wrote:
> > -Original Message-
> > From: york sun
> > Sent: Friday, February 12, 2016 1:39 AM
> > To: Scott Wood ; Qianyu Gong ; u-
> > b...@lists.denx.de
> > Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman ucode fixup to
> > Fman
> > driver code
> > 
> > On 02/08/2016 11:25 AM, Scott Wood wrote:
> > > On Mon, 2016-02-08 at 19:22 +, york sun wrote:
> > > > On 02/08/2016 11:18 AM, Scott Wood wrote:
> > > > > On Mon, 2016-02-08 at 19:03 +, york sun wrote:
> > > > > > On 02/01/2016 09:06 AM, york sun wrote:
> > > > > > > On 01/25/2016 09:40 PM, Qianyu Gong wrote:
> > > > > > > > 
> > > > > > > > > -Original Message-
> > > > > > > > > From: Scott Wood [mailto:o...@buserror.net]
> > > > > > > > > Sent: Tuesday, January 26, 2016 1:17 AM
> > > > > > > > > To: Qianyu Gong ; u-boot@lists.denx.de
> > > > > > > > > Cc: b07...@freescale.com; Shaohui Xie 
> > > > > > > > > Subject: Re: [U-Boot] [Patch V3 2/3] fm: fdt: Move fman
> > > > > > > > > ucode
> > > > > > > > > fixup to Fman driver code
> > > > > > > > > 
> > > > > > > > > On Mon, 2016-01-25 at 19:37 +0800, Gong Qianyu wrote:
> > > > > > > > > > Both Freescale Layerscape and powerpc/mpc85xx platforms
> > > > > > > > > > are
> > > > > > > > > > using
> > > > > > > > > > fdt_fixup_fman_firmware() to insert Fman ucode blob into
> > > > > > > > > > the
> > > > > > > > > > device tree. So move the function to driver code.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Gong Qianyu 
> > > > > > > > > > ---
> > > > > > > > > > V3:
> > > > > > > > > >  - Remove file changes about "qe.h".
> > > > > > > > > >(Should be put in the first patch of this patchset)
> > > > > > > > > > V2:
> > > > > > > > > >  - New patch.
> > > > > > > > > > 
> > > > > > > > > >  arch/powerpc/cpu/mpc85xx/fdt.c | 125
> > > > > > > > > > ++
> > > > > > > > > > -
> > > > > > > > > >  drivers/net/fm/Makefile|   1 +
> > > > > > > > > >  drivers/net/fm/fdt.c   | 129
> > > > > > > > > > +
> > > > > > > > > >  include/fsl_fman.h |   1 +
> > > > > > > > > >  4 files changed, 136 insertions(+), 120 deletions(-)
> > > > > > > > > 
> > > > > > > > > Again, pass -M -C to git format-patch.
> > > > > > > > > 
> > > > > > > > > -Scott
> > > > > > > > 
> > > > > > > > I don't understand but I've already used "git format-patch -M 
> > > > > > > > -C
> > > > > > > > - -stat ...".
> > > > > > > > 
> > > > > > > 
> > > > > > > Scott means using -M and -C, git should detect the moving
> > > > > > > instead of
> > > > > > > adding and
> > > > > > > deleting the same code. Try to add --find-copies-harder to see
> > > > > > > if it
> > > > > > > generates a
> > > > > > > smaller patch.
> > > > > > > 
> > > > > > 
> > > > > > Qianyu,
> > > > > > 
> > > > > > Since you are on holiday, I tried it for you. Adjusting "-M -C"
> > > > > > doesn't
> > > > > > work.
> > > > > > Even you are moving the function from one file to another, "git
> > > > > > format
> > > > > > -patch"
> > > > > > cannot detect the moving because both files exist before and after
> > > > > > this
> > > > > > change,
> > > > > > and the change set is not significant enough to be detected.
> > > > > 
> > > > > It looks like the patch is creating drivers/net/fm/fdt.c...
> > > > > 
> > 
> > Actually you were right. This patch creates a new file. There are also
> > other
> > small changes here and there. Maybe that's the reason git doesn't detect
> > the move.
> > 
> > Anyway, let me know if you have further comment. I am testing these
> > patches.
> > 
> > York
> 
> Hi York,
> 
> Thanks! I did make small changes in the function to make it work for both
> powerpc 
> and arm platforms.

Those changes should have been a separate patch -- otherwise it's a lot of
work to see what those changes are and review them.

-Scott

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

Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

[Tom Warren]

Simon,



> >>
> >> I think it was the follow-up patches to add the environment
> >> work-around that was applied.
> >>
> >> 6c88b51 video: tegra: Enable the 'lcd' env variable work-around
> >> a2931b3 dm: video: Add a temporary work-around for old stdout var
> >>
> >> I see the original v2 series here:
> >>
> >> http://patchwork.ozlabs.org/project/uboot/list/?delegate=4839
> >>
> >> so that is what needs to be applied I think. Then the Tegra config
> >> issue should be fixed.
> > I've applied the 23 v2 DM video patches to u-boot-tegra/master, then
> rebased against current u-boot/master.
> >
> > I see the 'warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which
> has unmet direct dependencies (DM_VIDEO)' spew for almost every board
> (w/MAKEALL -s tegra).
> >
> > Am I missing some patches?
> 
> I'll make some time to look but I am tied up most of the day so it will be 
> later,
> sorry.
> 
> The original series is at u-boot-dm/rke-working if that helps.
I pulled down rke-working. The two commits you list above are *not* in that 
repo/branch. They _are_ in my u-boot-tegra/next branch (just pushed it to Denx).
So building rke-working for tegra doesn't result in the DM_VIDEO warning, since 
the commits aren't there.

Back to you.

Tom
--
nvpublic

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

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

[Jagan Teki]

On 15 February 2016 at 02:16, Jagan Teki  wrote:
> Compared to previous patch series this series adds spi-nor
> core with spi-nor controller drivers are of "mtd uclass"
>
> This is whole series for all spi-nor related changes, and while
> series tested on spansion spi-nor chip.
>
> Know issue:
> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>
> Why this framework:
>
> Some of the SPI device drivers at drivers/spi not a real
> spi controllers, Unlike normal/generic SPI controllers they
> operates only with SPI-NOR flash devices. these were technically
> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>
> The problem with these were resides at drivers/spi is entire
> SPI layer becomes SPI-NOR flash oriented which is absolutely
> a wrong indication where SPI layer getting effected more with
> flash operations - So this SPI-NOR core will resolve this issue
> by separating all SPI-NOR flash operations from spi layer and
> creats a generic layer called SPI-NOR core which can be used to
> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> controller driver. The idea is taken from Linux spi-nor framework.
>
> Before SPI-NOR:
>
> ---
> cmd/sf.c
> ---
> spi_flash.c
> ---
> sf_probe.c
> ---
> spi-uclass
> ---
> spi drivers
> ---
> SPI NOR chip
> ---
>
> After SPI-NOR:
>
> --
> cmd/sf.c
> --
> spi-nor.c
> ---
> m25p80.cspi nor drivers
> ---
> spi-uclass  SPI NOR chip
> ---
> spi drivers
> ---
> SPI NOR chip
> ---
>
> SPI-NOR with MTD:
>
> --
> cmd/sf.c
> --
> MTD core
> --
> spi-nor.c
> ---
> m25p80.cspi nor drivers
> ---
> spi-uclass  SPI NOR chip
> ---
> spi drivers
> ---
> SPI NOR chip
> ---
>
> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> which is an interface layer b/w spi-nor core drivers/spi
> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)

Tested both DM and non-DM models

Tested-by: Jagan Teki 

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

[U-Boot] [PATCH v7 73/76] configs: Enable CONFIG_SPL_MTD_SUPPORT

[Jagan Teki]

Since SPI-NOR is driven by MTD core, so the SPL
need to use the MTD as well.

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes v7:
- Remove duplicate define on CONFIG_SPL_MTD_SUPPORT for zynq

 include/configs/P1010RDB.h | 1 +
 include/configs/P1022DS.h  | 1 +
 include/configs/T102xQDS.h | 1 +
 include/configs/T102xRDB.h | 1 +
 include/configs/T104xRDB.h | 1 +
 include/configs/T208xQDS.h | 1 +
 include/configs/T208xRDB.h | 1 +
 include/configs/am335x_evm.h   | 1 +
 include/configs/at91sam9n12ek.h| 1 +
 include/configs/at91sam9x5ek.h | 1 +
 include/configs/bav335x.h  | 1 +
 include/configs/cgtqmx6eval.h  | 1 +
 include/configs/chromebook_jerry.h | 1 +
 include/configs/clearfog.h | 1 +
 include/configs/cm_fx6.h   | 1 +
 include/configs/cm_t43.h   | 1 +
 include/configs/da850evm.h | 2 ++
 include/configs/db-88f6820-gp.h| 1 +
 include/configs/db-mv784mp-gp.h| 1 +
 include/configs/dra7xx_evm.h   | 1 +
 include/configs/ds414.h| 1 +
 include/configs/maxbcm.h   | 1 +
 include/configs/omapl138_lcdk.h| 1 +
 include/configs/ot1200.h   | 1 +
 include/configs/p1_p2_rdb_pc.h | 1 +
 include/configs/pcm051.h   | 1 +
 include/configs/sama5d2_xplained.h | 1 +
 include/configs/sama5d3xek.h   | 1 +
 include/configs/sama5d4_xplained.h | 1 +
 include/configs/sama5d4ek.h| 1 +
 include/configs/siemens-am33x-common.h | 1 +
 include/configs/socfpga_common.h   | 1 +
 include/configs/taurus.h   | 1 +
 include/configs/theadorable.h  | 1 +
 include/configs/ti_armv7_keystone2.h   | 1 +
 include/configs/tseries.h  | 1 +
 36 files changed, 37 insertions(+)

diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index a76630a..ec311fc 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -62,6 +62,7 @@
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SPL_FLUSH_IMAGE
 #define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h
index c8e7524..d4c17f9 100644
--- a/include/configs/P1022DS.h
+++ b/include/configs/P1022DS.h
@@ -51,6 +51,7 @@
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SPL_FLUSH_IMAGE
 #define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h
index 999fce2..569af49 100644
--- a/include/configs/T102xQDS.h
+++ b/include/configs/T102xQDS.h
@@ -81,6 +81,7 @@
 #define CONFIG_RESET_VECTOR_ADDRESS0x200FFC
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x0020)
diff --git a/include/configs/T102xRDB.h b/include/configs/T102xRDB.h
index 0ad1ce7..643eae0 100644
--- a/include/configs/T102xRDB.h
+++ b/include/configs/T102xRDB.h
@@ -88,6 +88,7 @@
 #define CONFIG_RESET_VECTOR_ADDRESS0x3FFC
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x3000)
diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
index b81c194..4132814 100644
--- a/include/configs/T104xRDB.h
+++ b/include/configs/T104xRDB.h
@@ -74,6 +74,7 @@ $(SRCTREE)/board/freescale/t104xrdb/t1042d4_rcw.cfg
 #defineCONFIG_RESET_VECTOR_ADDRESS 0x3FFC
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x3000)
diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h
index 76a9f93..05c123c 100644
--- a/include/configs/T208xQDS.h
+++ b/include/configs/T208xQDS.h
@@ -91,6 +91,7 @@
 #defineCONFIG_RESET_VECTOR_ADDRESS 0x200FFC
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define 

[U-Boot] [PATCH v7 16/76] spi_flash: Use mtd_info operation for SPI-NOR

[Jagan Teki]

Since spi-nor is using mtd layer for flash operations
this patch used mtd ops from user commands instead of
legacy spi_flash{} ops.

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes for v7:
- Rename CONFIG_MTD_DM_SPI_NOR to CONFIG_DM_MTD_SPI_NOR

 include/spi_flash.h | 60 ++---
 1 file changed, 48 insertions(+), 12 deletions(-)

diff --git a/include/spi_flash.h b/include/spi_flash.h
index 181b31e..09a7ce6 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -12,6 +12,7 @@
 
 #include /* Because we dereference struct udevice here */
 #include 
+#include 
 
 #ifndef CONFIG_SF_DEFAULT_SPEED
 # define CONFIG_SF_DEFAULT_SPEED   100
@@ -112,6 +113,39 @@ struct spi_flash {
 
 typedef struct mtd_info spi_flash_t;
 
+static inline int spi_flash_read(spi_flash_t *info, u32 offset,
+size_t len, void *buf)
+{
+   return mtd_read(info, offset, len, , (u_char *)buf);
+}
+
+static inline int spi_flash_write(spi_flash_t *info, u32 offset,
+ size_t len, const void *buf)
+{
+   return mtd_write(info, offset, len, , (u_char *)buf);
+}
+
+static inline int spi_flash_erase(spi_flash_t *info, u32 offset, size_t len)
+{
+   struct erase_info instr;
+
+   instr.mtd = info;
+   instr.addr = offset;
+   instr.len = len;
+   instr.callback = 0;
+
+   return mtd_erase(info, );
+}
+
+static inline int spi_flash_protect(spi_flash_t *info, u32 ofs,
+   u32 len, bool prot)
+{
+   if (prot)
+   return mtd_lock(info, ofs, len);
+   else
+   return mtd_unlock(info, ofs, len);
+}
+
 #ifdef CONFIG_DM_MTD_SPI_NOR
 
 int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
@@ -137,6 +171,20 @@ void spi_flash_free(spi_flash_t *flash);
 
 #endif /* CONFIG_DM_MTD_SPI_NOR */
 
+#else
+
+static inline int spi_flash_protect(struct spi_flash *flash, u32 ofs, u32 len,
+   bool prot)
+{
+   if (!flash->flash_lock || !flash->flash_unlock)
+   return -EOPNOTSUPP;
+
+   if (prot)
+   return flash->flash_lock(flash, ofs, len);
+   else
+   return flash->flash_unlock(flash, ofs, len);
+}
+
 #endif /* CONFIG_MTD_SPI_NOR */
 
 struct dm_spi_flash_ops {
@@ -259,18 +307,6 @@ static inline int spi_flash_erase(struct spi_flash *flash, 
u32 offset,
 }
 #endif
 
-static inline int spi_flash_protect(struct spi_flash *flash, u32 ofs, u32 len,
-   bool prot)
-{
-   if (!flash->flash_lock || !flash->flash_unlock)
-   return -EOPNOTSUPP;
-
-   if (prot)
-   return flash->flash_lock(flash, ofs, len);
-   else
-   return flash->flash_unlock(flash, ofs, len);
-}
-
 void spi_boot(void) __noreturn;
 void spi_spl_load_image(uint32_t offs, unsigned int size, void *vdst);
 
-- 
1.9.1

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

[U-Boot] [PATCH v7 12/76] mtd: spi-nor: m25p80: Add spi_nor support for non-dm

[Jagan Teki]

Like adding spi_nor support for dm-driven code in m25p80
add the same way for non-dm code as well.
- allocate spi_nor{}
- basic initilization
- install hooks
- call to spi-nor core, using spi_nor_scan
- register with mtd core

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes for v7:
- Rename CONFIG_MTD_DM_SPI_NOR to CONFIG_DM_MTD_SPI_NOR

 drivers/mtd/spi-nor/m25p80.c | 108 ++-
 include/spi_flash.h  |  18 +++-
 2 files changed, 112 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c
index 57e54d0..aba98b3 100644
--- a/drivers/mtd/spi-nor/m25p80.c
+++ b/drivers/mtd/spi-nor/m25p80.c
@@ -19,6 +19,9 @@
 struct m25p {
struct spi_slave*spi;
struct spi_nor  spi_nor;
+#ifndef CONFIG_DM_MTD_SPI_NOR
+   struct mtd_info mtd;
+#endif
 };
 
 static int spi_read_then_write(struct spi_slave *spi, const u8 *cmd,
@@ -179,16 +182,13 @@ static int m25p80_write(struct spi_nor *nor, const u8 
*cmd, size_t cmd_len,
return ret;
 }
 
-static int m25p_probe(struct udevice *dev)
+static int m25p80_spi_nor(struct spi_nor *nor)
 {
-   struct spi_slave *spi = dev_get_parent_priv(dev);
-   struct mtd_info *mtd = dev_get_uclass_priv(dev);
-   struct m25p *flash = dev_get_priv(dev);
-   struct spi_nor *nor;
+   struct mtd_info *mtd = nor->mtd;
+   struct m25p *flash = nor->priv;
+   struct spi_slave *spi = flash->spi;
int ret;
 
-   nor = >spi_nor;
-
/* install hooks */
nor->read_mmap = m25p80_read_mmap;
nor->read = m25p80_read;
@@ -196,10 +196,6 @@ static int m25p_probe(struct udevice *dev)
nor->read_reg = m25p80_read_reg;
nor->write_reg = m25p80_write_reg;
 
-   nor->mtd = mtd;
-   nor->priv = flash;
-   flash->spi = spi;
-
/* claim spi bus */
ret = spi_claim_bus(spi);
if (ret) {
@@ -251,10 +247,33 @@ err_scan:
spi_release_bus(spi);
 err_mtd:
spi_free_slave(spi);
-   device_remove(dev);
return ret;
 }
 
+#ifdef CONFIG_DM_MTD_SPI_NOR
+static int m25p_probe(struct udevice *dev)
+{
+   struct spi_slave *spi = dev_get_parent_priv(dev);
+   struct mtd_info *mtd = dev_get_uclass_priv(dev);
+   struct m25p *flash = dev_get_priv(dev);
+   struct spi_nor *nor;
+   int ret;
+
+   nor = >spi_nor;
+
+   nor->mtd = mtd;
+   nor->priv = flash;
+   flash->spi = spi;
+
+   ret = m25p80_spi_nor(nor);
+   if (ret) {
+   device_remove(dev);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct udevice_id m25p_ids[] = {
/*
 * Generic compatibility for SPI NOR that can be identified by the
@@ -271,3 +290,68 @@ U_BOOT_DRIVER(m25p80) = {
.probe  = m25p_probe,
.priv_auto_alloc_size = sizeof(struct m25p),
 };
+
+#else
+
+static struct mtd_info *m25p80_probe_tail(struct spi_slave *bus)
+{
+   struct m25p *flash;
+   struct spi_nor *nor;
+   int ret;
+
+   flash = calloc(1, sizeof(*flash));
+   if (!flash) {
+   debug("mp25p80: failed to allocate m25p\n");
+   return NULL;
+   }
+
+   nor = >spi_nor;
+   nor->mtd = >mtd;
+
+   nor->priv = flash;
+   flash->spi = bus;
+
+   ret = m25p80_spi_nor(nor);
+   if (ret) {
+   free(flash);
+   return NULL;
+   }
+
+   return nor->mtd;
+}
+
+struct mtd_info *spi_flash_probe(unsigned int busnum, unsigned int cs,
+unsigned int max_hz, unsigned int spi_mode)
+{
+   struct spi_slave *bus;
+
+   bus = spi_setup_slave(busnum, cs, max_hz, spi_mode);
+   if (!bus)
+   return NULL;
+   return m25p80_probe_tail(bus);
+}
+
+#ifdef CONFIG_OF_SPI_FLASH
+struct mtd_info *spi_flash_probe_fdt(const void *blob, int slave_node,
+int spi_node)
+{
+   struct spi_slave *bus;
+
+   bus = spi_setup_slave_fdt(blob, slave_node, spi_node);
+   if (!bus)
+   return NULL;
+   return m25p80_probe_tail(bus);
+}
+#endif
+
+void spi_flash_free(struct mtd_info *info)
+{
+   struct spi_nor *nor = info->priv;
+   struct m25p *flash = nor->priv;
+
+   del_mtd_device(info);
+   spi_free_slave(flash->spi);
+   free(flash);
+}
+
+#endif /* CONFIG_DM_MTD_SPI_NOR */
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 3bf6c17..ea04c3a 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -108,10 +108,12 @@ struct spi_flash {
 #endif
 };
 
-#if defined(CONFIG_MTD_SPI_NOR) && defined(CONFIG_DM_MTD_SPI_NOR)
+#ifdef CONFIG_MTD_SPI_NOR
 
 typedef struct mtd_info 

[U-Boot] [PATCH v7 09/76] mtd: spi-nor: Add dm spi-nor probing

[Jagan Teki]

This patch adds driver-model probe from cmd_sf through
MTD_DM_SPI_NOR which is depends on MTD and DM_SPI uclass.

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes for v7:
- Rename CONFIG_MTD_DM_SPI_NOR to CONFIG_DM_MTD_SPI_NOR
- Fix proper kconfig select for CONFIG_MTD_DM_SPI_NOR

 cmd/sf.c|  4 ++--
 common/env_sf.c |  4 ++--
 drivers/mtd/spi-nor/Kconfig |  7 +++
 drivers/mtd/spi-nor/Makefile|  2 ++
 drivers/mtd/spi-nor/spi-nor-probe.c | 30 ++
 include/spi_flash.h | 11 ++-
 6 files changed, 53 insertions(+), 5 deletions(-)
 create mode 100644 drivers/mtd/spi-nor/spi-nor-probe.c

diff --git a/cmd/sf.c b/cmd/sf.c
index 42862d9..528fc4d 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -85,7 +85,7 @@ static int do_spi_flash_probe(int argc, char * const argv[])
unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
unsigned int mode = CONFIG_SF_DEFAULT_MODE;
char *endp;
-#ifdef CONFIG_DM_SPI_FLASH
+#if defined(CONFIG_DM_SPI_FLASH) || defined (CONFIG_DM_MTD_SPI_NOR)
struct udevice *new, *bus_dev;
int ret;
 #else
@@ -118,7 +118,7 @@ static int do_spi_flash_probe(int argc, char * const argv[])
return -1;
}
 
-#ifdef CONFIG_DM_SPI_FLASH
+#if defined(CONFIG_DM_SPI_FLASH) || defined (CONFIG_DM_MTD_SPI_NOR)
/* Remove the old device, otherwise probe will just be a nop */
ret = spi_find_bus_and_cs(bus, cs, _dev, );
if (!ret) {
diff --git a/common/env_sf.c b/common/env_sf.c
index 892e6cb..652ed0b 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -52,7 +52,7 @@ int saveenv(void)
char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
u32 saved_size, saved_offset, sector = 1;
int ret;
-#ifdef CONFIG_DM_SPI_FLASH
+#if defined(CONFIG_DM_SPI_FLASH) || defined (CONFIG_DM_MTD_SPI_NOR)
struct udevice *new;
 
ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
@@ -242,7 +242,7 @@ int saveenv(void)
char*saved_buffer = NULL;
int ret = 1;
env_t   env_new;
-#ifdef CONFIG_DM_SPI_FLASH
+#if defined(CONFIG_DM_SPI_FLASH) || defined (CONFIG_DM_MTD_SPI_NOR)
struct udevice *new;
 
ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 374cdcb..342164d 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -1,5 +1,6 @@
 menuconfig MTD_SPI_NOR
tristate "SPI-NOR device support"
+   select DM_MTD_SPI_NOR if DM_SPI && MTD
help
  This is the core SPI NOR framework which can be used to interact 
SPI-NOR
  to SPI driver interface layer and the SPI-NOR controller driver.
@@ -12,6 +13,12 @@ menuconfig MTD_SPI_NOR
  SPI-NOR controller drivers for SPI-NOR device access. Note that from 
SPI-NOR
  core to SPI drivers there should be an interface layer.
 
+config DM_MTD_SPI_NOR
+   bool "MTD driver model for SPI-NOR"
+   help
+ This is enables MTD driver model support for SPI-NOR. Both MTD and SPI
+ driver models need to define for enabling this support.
+
 if MTD_SPI_NOR
 
 config MTD_M25P80
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 9ab6e3d..2f41630 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -6,6 +6,8 @@
 ifdef CONFIG_MTD_SPI_NOR
 obj-y += spi-nor.o
 obj-y += spi-nor-ids.o
+
+obj-$(CONFIG_DM_MTD_SPI_NOR)   += spi-nor-probe.o
 endif
 
 obj-$(CONFIG_MTD_M25P80)   += m25p80.o
diff --git a/drivers/mtd/spi-nor/spi-nor-probe.c 
b/drivers/mtd/spi-nor/spi-nor-probe.c
new file mode 100644
index 000..c808a7d
--- /dev/null
+++ b/drivers/mtd/spi-nor/spi-nor-probe.c
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
+  unsigned int max_hz, unsigned int spi_mode,
+  struct udevice **devp)
+{
+   struct spi_slave *slave;
+   struct udevice *bus;
+   char name[30], *str;
+   int ret;
+
+   snprintf(name, sizeof(name), "spi-nor@%d:%d", busnum, cs);
+   str = strdup(name);
+   ret = spi_get_bus_and_cs(busnum, cs, max_hz, spi_mode,
+"m25p80", str, , );
+   if (ret)
+   return ret;
+
+   *devp = slave->dev;
+   return 0;
+}
diff --git a/include/spi_flash.h b/include/spi_flash.h
index d0ce9e7..af9f89b 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -108,6 +108,14 @@ 

Re: [U-Boot] test/py main_signon

[Michal Simek]

Hi Stephen,

2016-02-16 17:39 GMT+01:00 Stephen Warren :

> On 02/16/2016 09:04 AM, Michal Simek wrote:
>
>> Hi Heiko,
>>
>> On 16.2.2016 14:32, Heiko Schocher wrote:
>>
>>> Hello Michal,
>>>
>>> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>>
 Hi Stephen,

 trying to run the latest testing on zynq board and getting this
 main_signon error.

 This is what I am running
 ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
 and getting below.

>>>
>>> Does this board has SPL support without SPL serial output?
>>>
>>
>> I do load u-boot via jtag that's why SPL logs are not visible.
>>
>> If so, can you try my patch:
>>> http://patchwork.ozlabs.org/patch/583348/
>>>
>>
>> I have applied your patch but it is still not working.
>>
>> If I run full flow with SPL then I can't see any issue.
>>
>
> I assume this is resolved then?
>

Unfortunately both cases should work because SPL is not only one first
stage bootloader
which can be used. I didn't test zynqmp but there is no SPL and the same
problem is
probably there too. Or is there any dependency that if SPL is not build
than testing system
is not expecting it?

I will look tmr at jtag boot mode with SPL if I can get it work.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] spi: omap3: Convert to driver model

[Jagan Teki]

After this conversion the driver will able to support
both dm and non-dm and code is more extensible like we
can remove the non-dm part simply without touching anycode
if all the boards which are using this driver become dm driven.

Cc: Tom Rini 
Reviewed-by: Simon Glass 
Acked-by: Christophe Ricard 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- Added dm pindir-d0-out-d1-in logic
- Updated comment about 4-wire master mode as per Linux.

 drivers/spi/omap3_spi.c | 684 +---
 1 file changed, 413 insertions(+), 271 deletions(-)

diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 8b0f665..a04340b 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -1,4 +1,6 @@
 /*
+ * Copyright (C) 2016 Jagan Teki 
+ *
  * Copyright (C) 2010 Dirk Behme 
  *
  * Driver for McSPI controller on OMAP3. Based on davinci_spi.c
@@ -15,6 +17,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -65,6 +68,8 @@
 #define OMAP3_MCSPI_CHCTRL_DIS (0 << 0)
 
 #define OMAP3_MCSPI_WAKEUPENABLE_WKEN  BIT(0)
+#define MCSPI_PINDIR_D0_IN_D1_OUT  0
+#define MCSPI_PINDIR_D0_OUT_D1_IN  1
 
 #define OMAP3_MCSPI_MAX_FREQ   4800
 #define SPI_WAIT_TIMEOUT   10
@@ -93,312 +98,123 @@ struct mcspi {
/* channel3: 0x68 - 0x78, bus 0 */
 };
 
-struct omap3_spi_slave {
-   struct spi_slave slave;
+struct omap3_spi_priv {
struct mcspi *regs;
+   unsigned int cs;
unsigned int freq;
unsigned int mode;
+   unsigned int wordlen;
+   unsigned int pin_dir:1;
 };
 
-static inline struct omap3_spi_slave *to_omap3_spi(struct spi_slave *slave)
-{
-   return container_of(slave, struct omap3_spi_slave, slave);
-}
-
-static void spi_reset(struct omap3_spi_slave *ds)
-{
-   unsigned int tmp;
-
-   writel(OMAP3_MCSPI_SYSCONFIG_SOFTRESET, >regs->sysconfig);
-   do {
-   tmp = readl(>regs->sysstatus);
-   } while (!(tmp & OMAP3_MCSPI_SYSSTATUS_RESETDONE));
-
-   writel(OMAP3_MCSPI_SYSCONFIG_AUTOIDLE |
-OMAP3_MCSPI_SYSCONFIG_ENAWAKEUP |
-OMAP3_MCSPI_SYSCONFIG_SMARTIDLE,
->regs->sysconfig);
-
-   writel(OMAP3_MCSPI_WAKEUPENABLE_WKEN, >regs->wakeupenable);
-}
-
-static void omap3_spi_write_chconf(struct omap3_spi_slave *ds, int val)
+static void omap3_spi_write_chconf(struct omap3_spi_priv *priv, int val)
 {
-   writel(val, >regs->channel[ds->slave.cs].chconf);
+   writel(val, >regs->channel[priv->cs].chconf);
/* Flash post writes to make immediate effect */
-   readl(>regs->channel[ds->slave.cs].chconf);
+   readl(>regs->channel[priv->cs].chconf);
 }
 
-static void omap3_spi_set_enable(struct omap3_spi_slave *ds, int enable)
+static void omap3_spi_set_enable(struct omap3_spi_priv *priv, int enable)
 {
-   writel(enable, >regs->channel[ds->slave.cs].chctrl);
+   writel(enable, >regs->channel[priv->cs].chctrl);
/* Flash post writes to make immediate effect */
-   readl(>regs->channel[ds->slave.cs].chctrl);
-}
-
-void spi_init()
-{
-   /* do nothing */
+   readl(>regs->channel[priv->cs].chctrl);
 }
 
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
- unsigned int max_hz, unsigned int mode)
-{
-   struct omap3_spi_slave  *ds;
-   struct mcspi *regs;
-
-   /*
-* OMAP3 McSPI (MultiChannel SPI) has 4 busses (modules)
-* with different number of chip selects (CS, channels):
-* McSPI1 has 4 CS (bus 0, cs 0 - 3)
-* McSPI2 has 2 CS (bus 1, cs 0 - 1)
-* McSPI3 has 2 CS (bus 2, cs 0 - 1)
-* McSPI4 has 1 CS (bus 3, cs 0)
-*/
-
-   switch (bus) {
-   case 0:
-   regs = (struct mcspi *)OMAP3_MCSPI1_BASE;
-   break;
-#ifdef OMAP3_MCSPI2_BASE
-   case 1:
-   regs = (struct mcspi *)OMAP3_MCSPI2_BASE;
-   break;
-#endif
-#ifdef OMAP3_MCSPI3_BASE
-   case 2:
-   regs = (struct mcspi *)OMAP3_MCSPI3_BASE;
-   break;
-#endif
-#ifdef OMAP3_MCSPI4_BASE
-   case 3:
-   regs = (struct mcspi *)OMAP3_MCSPI4_BASE;
-   break;
-#endif
-   default:
-   printf("SPI error: unsupported bus %i. \
-   Supported busses 0 - 3\n", bus);
-   return NULL;
-   }
-
-   if (((bus == 0) && (cs > 3)) ||
-   ((bus == 1) && (cs > 1)) ||
-   ((bus == 2) && (cs > 1)) ||
-   ((bus == 3) && (cs > 0))) {
-   printf("SPI error: unsupported chip select %i \
-   on bus %i\n", cs, bus);
-   return NULL;

[U-Boot] Beaglebone Black broken since commit fd61d39970b9901217efc7536d9f3a61b4e1752a

[Guillaume Gardet]

Hi,

Beaglebone black (am335x_evm_defconfig) is broken (with MMC boot and u-boot.img 
on ext4 partition).
I bisected it to commit fd61d39970b9901217efc7536d9f3a61b4e1752a
spl: mmc: add break statements in spl_mmc_load_image()
from Nikita Kiryanov (in Cc).

Working image gives:

U-Boot SPL 2016.01-rc1-00036-g483ab3d (Feb 16 2016 - 19:04:10)
bad magic
bad magic
spl_register_fat_device: fat register err - -1
spl_register_fat_device: fat register err - -1
spl_load_image_fat: error reading image u-boot.img, err - -1
spl: ext4fs_open failed
spl: ext4fs_open failed
spl_load_image_ext: error reading image uImage, err - -1


U-Boot 2016.01-rc1-00033-g9884f44 (Feb 16 2016 - 18:55:52 +0100)


Since this commit, we get:

U-Boot SPL 2016.01-rc1-00037-gfd61d39 (Feb 16 2016 - 19:01:54)
bad magic
bad magic
### ERROR ### Please RESET the board ###



Guillaume

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

[U-Boot] [PATCH] usb: gadget: composite: Correct recovery path for register

[Semen Protsenko]

From: Sam Protsenko 

In case when usb_composite_register() failed once (for whatever reason),
it will fail further even if all conditions are correct. Example:

=> fastboot 2
Invalid Controller Index
couldn't find an available UDC
g_dnl_register: failed!, error: -19
exit not allowed from main input shell.

=> fastboot 0
g_dnl_register: failed!, error: -22
exit not allowed from main input shell.

Despite that 0 is correct index for USB controller, "fastboot 0" command
will fail, because "composite" structure wasn't cleared properly on
previous fail (on "fastboot 2" command).

This patch fixes that erroneous behavior, allowing us to use composite
even after previous failure.

Signed-off-by: Sam Protsenko 
---
 drivers/usb/gadget/composite.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 60f9272..d0ee784 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1077,6 +1077,8 @@ static struct usb_gadget_driver composite_driver = {
  */
 int usb_composite_register(struct usb_composite_driver *driver)
 {
+   int res;
+
if (!driver || !driver->dev || !driver->bind || composite)
return -EINVAL;
 
@@ -1084,7 +1086,11 @@ int usb_composite_register(struct usb_composite_driver 
*driver)
driver->name = "composite";
composite = driver;
 
-   return usb_gadget_register_driver(_driver);
+   res = usb_gadget_register_driver(_driver);
+   if (res != 0)
+   composite = NULL;
+
+   return res;
 }
 
 /**
-- 
2.7.0

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

Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

[Simon Glass]

Hi Tom,

On 16 February 2016 at 09:23, Tom Warren  wrote:
> Simon,
>
>> -Original Message-
>> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>> Sent: Tuesday, February 16, 2016 9:03 AM
>> To: Tom Warren 
>> Cc: Stephen Warren ; U-Boot Mailing List > b...@lists.denx.de>; Marcel Ziswiler ; Stephen
>> Warren ; Pantelis Antoniou > consulting.com>; Marek Vasut ; Pavel Herrmann
>> ; Anatolij Gustschin 
>> Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video
>> drivers to driver model
>>
>> Hi Tom,
>>
>> On 16 February 2016 at 08:47, Tom Warren  wrote:
>> >
>> > Simon
>> >
>> > > -Original Message-
>> > > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon
>> > > Glass
>> > > Sent: Sunday, February 14, 2016 6:19 PM
>> > > To: Stephen Warren 
>> > > Cc: U-Boot Mailing List ; Marcel Ziswiler
>> > > ; Tom Warren ;
>> > > Stephen Warren ; Pantelis Antoniou
>> > > ; Marek Vasut
>> > > ; Pavel Herrmann ;
>> > > Anatolij Gustschin 
>> > > Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and
>> > > tegra124 video drivers to driver model
>> > >
>> > > Hi,
>> > >
>> > > On 1 February 2016 at 17:00, Stephen Warren 
>> > > wrote:
>> > > >
>> > > > On 01/30/2016 04:37 PM, Simon Glass wrote:
>> > > >>
>> > > >> This series moves these two drivers over to use driver model for 
>> > > >> video.
>> > > >>
>> > > >> This involves the following steps:
>> > > >> - Sync up some device tree files with Linux
>> > > >> - Implement a proper PWM driver
>> > > >> - Clean up and unify the driver code
>> > > >> - Modify the existing drivers to work with driver model
>> > > >>
>> > > >> The tegra20 display driver uses device tree bindings invented in
>> > > >> 2011 before Linux had this or anyone was able to agree a
>> > > >> standard. It seems possible to move it to the new bindings (like
>> > > >> tegra124) except for the issue of time delays between stages. It
>> > > >> isn't clear how this should work, and Linux implements this by
>> > > >> including all LCD definitions in the kernel source code, and not
>> > > >> using any delays. This causes strange display artifacts on the
>> > > >> display when starting up, but perhaps is harmless to the display.
>> > > >> Future work will sync up the device tree more for seaboard, and thus
>> tidy this up for nvidia boards.
>> > > >>
>> > > >> A bug in the keyboard driver is also fixed by this series. The
>> > > >> series is tested on seaboard and nyan-big, the two boards I have
>> > > >> which support a display.
>> > > >>
>> > > >> This series is available at u-boot-dm/tegra-working.
>> > > >
>> > > >
>> > > > This changes the name of the output device from "lcd" to "vidconsole".
>> > > Anyone who doesn't reset their environment to default when switching
>> > > to this new U-Boot will lose their display output because of this.
>> > > Is there any way to maintain compatibility?
>> > > >
>> > > > Aside from that, I don't see any issues on Springbank (Seaboard),
>> > > > Harmony, Ventana, Paz00, or p2371-2180, so the series,
>> > > > Tested-by: Stephen Warren 
>> > >
>> > > It looks like some of the patches have been applied and all Tegra
>> > > boards are now giving Kconfig warnings.
>> > >
>> > > Tom Warren, are you able to pick up the rest of the series?
>> > I had thought these had already gone in via the dm repo. If not, please 
>> > list
>> those that still need to be picked up and I'll take them in via tegra. Best 
>> to
>> assign the appropriate ones to me in patchwork. Currently it seems they're 
>> all
>> assigned to me. Which patches have already been applied?
>>
>> I think it was the follow-up patches to add the environment work-around that
>> was applied.
>>
>> 6c88b51 video: tegra: Enable the 'lcd' env variable work-around
>> a2931b3 dm: video: Add a temporary work-around for old stdout var
>>
>> I see the original v2 series here:
>>
>> http://patchwork.ozlabs.org/project/uboot/list/?delegate=4839
>>
>> so that is what needs to be applied I think. Then the Tegra config issue 
>> should
>> be fixed.
> I've applied the 23 v2 DM video patches to u-boot-tegra/master, then rebased 
> against current u-boot/master.
>
> I see the 'warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet 
> direct dependencies (DM_VIDEO)' spew for almost every board (w/MAKEALL -s 
> tegra).
>
> Am I missing some patches?

I'll make some time to look but I am tied up most of the day so it
will be later, sorry.

The original series is at u-boot-dm/rke-working if 

Re: [U-Boot] how does board_init_f() -> board_init_r?

[Stephen Warren]

On 02/16/2016 09:01 AM, Simon Glass wrote:

+Stephen who will know more

Hi,

On 13 February 2016 at 18:52, quantumlight  wrote:

I am trying to modify the bootloader code for NVIDIA's jetson board.

So I am looking at crt0.S. It seems that two builds happen, one with
CONFIG_SPL_BUILD and one without. So you end up with two file, u-boot.bin
and spl/u-boot-spl.bin.


SPL is built with ARMv4t
U-Boot proper is built with ARMv7

That's why SPL is used on Tegra. The SPL does not actually load
U-Boot. In fact both are bundle together and loaded at the same time.
SPL simply jumps to U-Boot when needed.


There's some more background on this topic at:

ftp://download.nvidia.com/tegra-public-appnotes/index.html

In particular, see the "Tegra Boot Flow" link/document.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] test/py main_signon

[Stephen Warren]

On 02/16/2016 09:04 AM, Michal Simek wrote:

Hi Heiko,

On 16.2.2016 14:32, Heiko Schocher wrote:

Hello Michal,

Am 16.02.2016 um 13:12 schrieb Michal Simek:

Hi Stephen,

trying to run the latest testing on zynq board and getting this
main_signon error.

This is what I am running
./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
and getting below.


Does this board has SPL support without SPL serial output?


I do load u-boot via jtag that's why SPL logs are not visible.


If so, can you try my patch:
http://patchwork.ozlabs.org/patch/583348/


I have applied your patch but it is still not working.

If I run full flow with SPL then I can't see any issue.


I assume this is resolved then?

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

Re: [U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses serial output

[Stephen Warren]

On 02/16/2016 05:13 AM, Heiko Schocher wrote:

check for U-Boot SPL signature only if SPL really has
a serial output. So check if CONFIG_SPL_SERIAL_SUPPORT
is active in board config.


Nit: That's wrapped really narrow. Any chance of wrapping to more like 
72-74 characters?



diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index bc2bd76..f888d5c 100644



  if self.config.buildconfig.get('config_spl', False) == 'y':
-m = self.p.expect([pattern_u_boot_spl_signon] + 
self.bad_patterns)
-if m != 0:
-raise Exception('Bad pattern found on console: ' +
-self.bad_pattern_ids[m - 1])
+if self.config.buildconfig.get('config_spl_serial_support',
+   False) == 'y':
+m = self.p.expect([pattern_u_boot_spl_signon] +
+  self.bad_patterns)
+if m != 0:
+raise Exception('Bad pattern found on console: ' +
+self.bad_pattern_ids[m - 1])


Conceptually this change looks fine. Rather than using nested ifs, why 
not write "if a and b:" and so avoid adding an extra indent level? I'd 
also introduce some variables to shorten the text a bit:


bcfg = u_boot_console.config.buildconfig
if bcfg.get('config_spl', 'n') == 'y' and
bcfg.get('config_spl_serial_support', 'n') == 'y':
...

or:

bcfg = u_boot_console.config.buildconfig
config_spl = bcfg.get('config_spl', 'n') == 'y'
config_spl_serial_support = bcfg.get('config_spl_serial_support',
'n') == 'y'
if config_spl and config_spl_serial_support:
...

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

Re: [U-Boot] [PATCH 3/3] spi: omap3: Convert to driver model

[Tom Rini]

On Tue, Feb 16, 2016 at 09:00:28AM -0700, Simon Glass wrote:
> On 11 February 2016 at 12:00, Jagan Teki  wrote:
> > After this conversion the driver will able to support
> > both dm and non-dm and code is more extensible like we
> > can remove the non-dm part simply without touching anycode
> > if all the boards which are using this driver become dm driven.
> >
> > Cc: Tom Rini 
> > Cc: Simon Glass 
> > Cc: Christophe Ricard 
> > Signed-off-by: Jagan Teki 
> > ---
> >  drivers/spi/omap3_spi.c | 678 
> > +---
> >  1 file changed, 407 insertions(+), 271 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> Can CONFIG_OMAP3_SPI_D0_D1_SWAPPED be moved to device tree for the DM version?

Yes, there is already a binding for this:
- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as
  input. The default is D0 as input and
  D1 as output.


-- 
Tom


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

Re: [U-Boot] [RFC PATCH v4 2/3] common: Convert ulong to phys_addr_t for image addresses

[Simon Glass]

Hi York,

On 12 February 2016 at 13:59, York Sun  wrote:
> When dealing with image addresses, ulong has been used. Some files
> are used by both host and target. It is OK for the target, but not
> always enough for host tools including mkimage. This patch replaces
> "ulong" with "phys_addr_t" to make sure addresses are correct for
> both the target and the host.
>
> This issue was found on 32-bit host when compiling for 64-bit target
> to support images with address higher than 32-bit space.
>
> Signed-off-by: York Sun 
>
> ---
>
> Changes in v4:
>   New patch, separated from fixing FIT image.
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/powerpc/lib/bootm.c |4 ++--
>  cmd/ximg.c   |9 +
>  common/bootm.c   |   21 +++--
>  common/bootm_os.c|   14 --
>  common/image-android.c   |6 +++---
>  common/image-fdt.c   |   16 
>  common/image-fit.c   |   27 ++-
>  common/image.c   |   17 ++---
>  include/bootm.h  |6 +++---
>  include/image.h  |   30 ++
>  tools/default_image.c|2 +-
>  11 files changed, 83 insertions(+), 69 deletions(-)
>
> diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
> index ef15e7a..794382a 100644
> --- a/arch/powerpc/lib/bootm.c
> +++ b/arch/powerpc/lib/bootm.c
> @@ -47,7 +47,7 @@ static void boot_jump_linux(bootm_headers_t *images)
>  #endif
>
> kernel = (void (*)(bd_t *, ulong, ulong, ulong,
> -  ulong, ulong, ulong))images->ep;
> +  ulong, ulong, ulong))(uintptr_t)images->ep;
> debug ("## Transferring control to Linux (at address %08lx) ...\n",
> (ulong)kernel);
>
> @@ -335,7 +335,7 @@ void boot_jump_vxworks(bootm_headers_t *images)
> WATCHDOG_RESET();
>
> ((void (*)(void *, ulong, ulong, ulong,
> -   ulong, ulong, ulong))images->ep)(images->ft_addr,
> +   ulong, ulong, ulong))(uintptr_t)images->ep)(images->ft_addr,
> 0, 0, EPAPR_MAGIC, getenv_bootm_mapsize(), 0, 0);
>  }
>  #endif
> diff --git a/cmd/ximg.c b/cmd/ximg.c
> index d033c15..70d6d14 100644
> --- a/cmd/ximg.c
> +++ b/cmd/ximg.c
> @@ -33,7 +33,8 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char * 
> const argv[])
>  {
> ulong   addr = load_addr;
> ulong   dest = 0;
> -   ulong   data, len;
> +   phys_addr_t data;
> +   ulong   len;
> int verify;
> int part = 0;
>  #if defined(CONFIG_IMAGE_FORMAT_LEGACY)
> @@ -173,7 +174,7 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char 
> * const argv[])
> return 1;
> }
>
> -   data = (ulong)fit_data;
> +   data = (phys_addr_t)(uintptr_t)fit_data;
> len = (ulong)fit_len;
> break;
>  #endif
> @@ -205,14 +206,14 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, 
> char * const argv[])
> }
>  #else  /* !(CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG) */
> printf("   Loading part %d ... ", part);
> -   memmove((char *) dest, (char *)data, len);
> +   memmove((char *)dest, (char *)(uintptr_t)data, len);
>  #endif /* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */
> break;
>  #ifdef CONFIG_GZIP
> case IH_COMP_GZIP:
> printf("   Uncompressing part %d ... ", part);
> if (gunzip((void *) dest, unc_len,
> -  (uchar *) data, ) != 0) {
> +  (uchar *)(uintptr_t)data, ) != 0) {

The uintptr_t cast presumably defeats the warning. Is the intention to
convert a 64-bit value to 32-bit?

Is it true that sizeof(phys_addr_t) is always sizeof(ulong) on the target?

> puts("GUNZIP ERROR - image not loaded\n");
> return 1;
> }
> diff --git a/common/bootm.c b/common/bootm.c
> index 99d574d..785858c 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -43,7 +43,7 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc,
>char * const argv[], bootm_headers_t 
> *images,
> -  ulong *os_data, ulong *os_len);
> +  phys_addr_t *os_data, ulong *os_len);
>
>  #ifdef CONFIG_LMB
>  static void boot_start_lmb(bootm_headers_t *images)
> @@ -325,9 +325,9 @@ static int handle_decomp_error(int comp_type, size_t 
> uncomp_size,
> return BOOTM_ERR_RESET;
>  }
>
> -int bootm_decomp_image(int comp, ulong load, ulong image_start, int type,
> -  

Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

[Tom Warren]

Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Tuesday, February 16, 2016 9:03 AM
> To: Tom Warren 
> Cc: Stephen Warren ; U-Boot Mailing List  b...@lists.denx.de>; Marcel Ziswiler ; Stephen
> Warren ; Pantelis Antoniou  consulting.com>; Marek Vasut ; Pavel Herrmann
> ; Anatolij Gustschin 
> Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video
> drivers to driver model
> 
> Hi Tom,
> 
> On 16 February 2016 at 08:47, Tom Warren  wrote:
> >
> > Simon
> >
> > > -Original Message-
> > > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon
> > > Glass
> > > Sent: Sunday, February 14, 2016 6:19 PM
> > > To: Stephen Warren 
> > > Cc: U-Boot Mailing List ; Marcel Ziswiler
> > > ; Tom Warren ;
> > > Stephen Warren ; Pantelis Antoniou
> > > ; Marek Vasut
> > > ; Pavel Herrmann ;
> > > Anatolij Gustschin 
> > > Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and
> > > tegra124 video drivers to driver model
> > >
> > > Hi,
> > >
> > > On 1 February 2016 at 17:00, Stephen Warren 
> > > wrote:
> > > >
> > > > On 01/30/2016 04:37 PM, Simon Glass wrote:
> > > >>
> > > >> This series moves these two drivers over to use driver model for video.
> > > >>
> > > >> This involves the following steps:
> > > >> - Sync up some device tree files with Linux
> > > >> - Implement a proper PWM driver
> > > >> - Clean up and unify the driver code
> > > >> - Modify the existing drivers to work with driver model
> > > >>
> > > >> The tegra20 display driver uses device tree bindings invented in
> > > >> 2011 before Linux had this or anyone was able to agree a
> > > >> standard. It seems possible to move it to the new bindings (like
> > > >> tegra124) except for the issue of time delays between stages. It
> > > >> isn't clear how this should work, and Linux implements this by
> > > >> including all LCD definitions in the kernel source code, and not
> > > >> using any delays. This causes strange display artifacts on the
> > > >> display when starting up, but perhaps is harmless to the display.
> > > >> Future work will sync up the device tree more for seaboard, and thus
> tidy this up for nvidia boards.
> > > >>
> > > >> A bug in the keyboard driver is also fixed by this series. The
> > > >> series is tested on seaboard and nyan-big, the two boards I have
> > > >> which support a display.
> > > >>
> > > >> This series is available at u-boot-dm/tegra-working.
> > > >
> > > >
> > > > This changes the name of the output device from "lcd" to "vidconsole".
> > > Anyone who doesn't reset their environment to default when switching
> > > to this new U-Boot will lose their display output because of this.
> > > Is there any way to maintain compatibility?
> > > >
> > > > Aside from that, I don't see any issues on Springbank (Seaboard),
> > > > Harmony, Ventana, Paz00, or p2371-2180, so the series,
> > > > Tested-by: Stephen Warren 
> > >
> > > It looks like some of the patches have been applied and all Tegra
> > > boards are now giving Kconfig warnings.
> > >
> > > Tom Warren, are you able to pick up the rest of the series?
> > I had thought these had already gone in via the dm repo. If not, please list
> those that still need to be picked up and I'll take them in via tegra. Best to
> assign the appropriate ones to me in patchwork. Currently it seems they're all
> assigned to me. Which patches have already been applied?
> 
> I think it was the follow-up patches to add the environment work-around that
> was applied.
> 
> 6c88b51 video: tegra: Enable the 'lcd' env variable work-around
> a2931b3 dm: video: Add a temporary work-around for old stdout var
> 
> I see the original v2 series here:
> 
> http://patchwork.ozlabs.org/project/uboot/list/?delegate=4839
> 
> so that is what needs to be applied I think. Then the Tegra config issue 
> should
> be fixed.
I've applied the 23 v2 DM video patches to u-boot-tegra/master, then rebased 
against current u-boot/master.

I see the 'warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet 
direct dependencies (DM_VIDEO)' spew for almost every board (w/MAKEALL -s 
tegra).

Am I missing some patches? 
--
nvpublic
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: zynq: Enable u-boot, dm-pre-reloc for qspi

[Michal Simek]

On 16.2.2016 14:05, Nathan Rossi wrote:
> Enable u-boot,dm-pre-reloc for qspi for zc706, zed and microzed.
> 
> Signed-off-by: Nathan Rossi 
> Cc: Albert Aribaud 
> Cc: Michal Simek 
> Cc: Simon Glass 
> ---
>  arch/arm/dts/zynq-microzed.dts | 1 +
>  arch/arm/dts/zynq-zc706.dts| 1 +
>  arch/arm/dts/zynq-zed.dts  | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
> index e841a1d..793ab44 100644
> --- a/arch/arm/dts/zynq-microzed.dts
> +++ b/arch/arm/dts/zynq-microzed.dts
> @@ -24,6 +24,7 @@
>  };
>  
>   {
> + u-boot,dm-pre-reloc;
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
> index 1ba3a1c..1610520 100644
> --- a/arch/arm/dts/zynq-zc706.dts
> +++ b/arch/arm/dts/zynq-zc706.dts
> @@ -306,6 +306,7 @@
>  };
>  
>   {
> + u-boot,dm-pre-reloc;
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/dts/zynq-zed.dts b/arch/arm/dts/zynq-zed.dts
> index 5ec59e2..ec9b2f7 100644
> --- a/arch/arm/dts/zynq-zed.dts
> +++ b/arch/arm/dts/zynq-zed.dts
> @@ -61,6 +61,7 @@
>  };
>  
>   {
> + u-boot,dm-pre-reloc;
>   status = "okay";
>  };
>  

Applied.

Thanks,
Michal
> 

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

Re: [U-Boot] [PATCH v2 3/7] drivers: block: disk-uclass: implement scsi_init()

[Simon Glass]

Hi Mugunthan and Bin,

On 14 February 2016 at 20:03, Bin Meng  wrote:
> Hi Simon,
>
> On Sun, Feb 7, 2016 at 4:29 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 3 February 2016 at 04:59, Mugunthan V N  wrote:
>>>
>>> Implement scsi_init() api to probe driver model based sata
>>> devices.
>>>
>>> Signed-off-by: Mugunthan V N 
>>> ---
>>>  drivers/block/disk-uclass.c | 39 +++
>>>  1 file changed, 39 insertions(+)
>>
>> This patch seems odd to me. I would hope that scsi_init() would go
>> away with driver model and it would happen as part of the controller
>> probe. But of course we cannot probe SCSI from UCLASS_DISK. I think
>> the uclass 'disk' is too broad to be useful.
>>
>
> I agree. I raised similar comment before that this just looks a place
> holder for the SCSI stuff.
>
>> So I am wondering whether the decision to use UCLASS_DISK instead of
>> UCLASS_AHCI was a mistake.
>>
>> Perhaps instead we should have:
>>
>> UCLASS_AHCI
>> UCLASS_SCSI
>> UCLASS_MMC
>> etc...
>>
>
> I still think UCLASS_AHCI is not a good name. Maybe UCLASS_ATA as we
> are talking about protocols here (SCSI, MMC).

UCLASS_ATA seems confusing. How would we distinguish IDE and SATA?

BTW since your email I have sent a patch to implement block devices.
>From what I can tell the above approach will work well. I think our
uclasses should mirror the current IF_TYPE values:

/* Interface types: */
#define IF_TYPE_UNKNOWN 0
#define IF_TYPE_IDE 1
#define IF_TYPE_SCSI 2
#define IF_TYPE_ATAPI 3
#define IF_TYPE_USB 4
#define IF_TYPE_DOC 5
#define IF_TYPE_MMC 6
#define IF_TYPE_SD 7
#define IF_TYPE_SATA 8
#define IF_TYPE_HOST 9

>
>> and each of these devices can have a UCLASS_BLK under them (the block 
>> device).
>>
>> Possibly we could even have a dummy UCLASS_DISK device under each of
>> the above, but I'm not sure that is useful.
>>
>> What do you think?
>>
>
> [snip]
>
> Regards,
> Bin

Since this patch is presumably destined for the current release and we
don't intend to change UCLASS_DISK for that release, I think this
patch can go in as is. We can fix it up later. Also note that
scsi_get_device() is not the same as scsi_get_dev().

It would be better to use uclass_get_device() though.

Reviewed-by: Simon Glass 

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

Re: [U-Boot] Warnings from Tegra LCD conversion?

[Simon Glass]

Hi Stephen,

On 15 February 2016 at 22:29, Stephen Warren  wrote:
> While checking on the travis-ci.org runs that include test/py testing of
> sandbox, I noticed some new warnings on AArch64 Tegra boards. See the
> log at:
>
> https://travis-ci.org/u-boot/u-boot/jobs/109471848
>
>> Building current source for 33 boards (2 threads, 1 job per thread)
>>aarch64:  +   e2220-1170
>> +warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet direct 
>> dependencies (DM_VIDEO)
>>aarch64:  +   p2571
>> +warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet direct 
>> dependencies (DM_VIDEO)
>>aarch64:  +   p2371-
>> +warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet direct 
>> dependencies (DM_VIDEO)
>>aarch64:  +   p2371-2180
>> +warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet direct 
>> dependencies (DM_VIDEO)

See the other thread - the patches for the environment work-around
were applied, but the Tegra LCD conversion was not. Hopefully Tom can
get these in and the problem should go away.

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

Re: [U-Boot] [PATCH 1/6] net: gem: Add support for reading MAC from I2C EEPROM

[Simon Glass]

Hi Joe,

On 16 February 2016 at 09:06, Joe Hershberger  wrote:
>
> Hi Simon,
>
> On Tue, Feb 16, 2016 at 9:59 AM, Simon Glass  wrote:
> > Hi,
> >
> > On 15 February 2016 at 18:06, Bin Meng  wrote:
> >> +Simon,
> >>
> >> Hi Joe,
> >>
> >> On Tue, Feb 16, 2016 at 12:01 AM, Joe Hershberger
> >>  wrote:
> >>> Hi Bin,
> >>>
> >>> On Sun, Feb 14, 2016 at 6:00 AM, Bin Meng  wrote:
>  Hi Michal,
> 
>  On Sun, Feb 14, 2016 at 6:03 PM, Michal Simek  wrote:
> > Hi Bin,
> >
> > 2016-02-14 3:25 GMT+01:00 Bin Meng :
> >>
> >> Hi Michal,
> >>
> >> On Sat, Feb 13, 2016 at 6:39 PM, Michal Simek  wrote:
> >> > Add support for reading MAC address from I2C EEPROM.
> >> >
> >>
> >> Is this a feature provided by the GEM MAC IP?
> >>
> >> > Signed-off-by: Michal Simek 
> >> > ---
> >> >
> >> >  drivers/net/zynq_gem.c | 16 
> >> >  1 file changed, 16 insertions(+)
> >> >
> >> > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> >> > index b3821c31a91d..ace60c901cb5 100644
> >> > --- a/drivers/net/zynq_gem.c
> >> > +++ b/drivers/net/zynq_gem.c
> >> > @@ -627,6 +627,21 @@ static int zynq_gem_remove(struct udevice *dev)
> >> > return 0;
> >> >  }
> >> >
> >> > +static int zynq_gem_read_rom_hwaddr(struct udevice *dev)
> >> > +{
> >> > +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
> >> > +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET)
> >> > +   struct eth_pdata *pdata = dev_get_platdata(dev);
> >> > +
> >> > +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
> >> > +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
> >> > +   pdata->enetaddr, 
> >> > ARRAY_SIZE(pdata->enetaddr)))
> >>
> >> This call to eeprom_read() looks to me a board-specific feature, that
> >> an on-board eeprom is used to store the MAC address for the GEM?
> >>
> >
> > Right. it is board specific feature I can
> > The question is if this should really go to board specific file
> > or to be the part of DT binding. I didn't look at the kernel if someone 
> > has
> > some sort of eeprom binding for this case
> > but I expect local mac addresses via DT are used. Or passing via command
> > line does it.
> >
> > Anyway there is mac_read_from_eeprom() but it is ancient one.
> > Do you any preference for the name of function?
> 
>  I think the intention of the read_rom_hwaddr op is to read the MAC
>  address via the ethernet controller defined mechanism (eg: e1000 can
>  read its MAC address from either an EEPROM or an SPI flash), or via
>  SoC defined mechanism (eg: the ethernet IP is only seen on a specific
>  SoC, and reading the MAC address only makes sense on that specific
>  SoC). If this is a board-specific mechanism, I don't think we should
>  put the codes into driver's read_rom_hwaddr(). Again, if it is
>  board-specific, we may not come up with a standard DT binding for such
>  stuff, unless we can enumerate all possible ways for storing MAC
>  address on a board (EEPROM, SPI flash, eMMC, SD)?
> >>>
> >>> Did you see this: https://patchwork.ozlabs.org/patch/573373/
> >>>
> >>
> >> I haven't noticed this before.
> >>
> >>> This is the concept I had in mind for handling this sort of thing.
> >>>
> >>
> >> Your patch looks good to me, but I added Simon, who is not a big fan
> >> of using weak in driver model :-)
> >
> > My main concern with 'weak' is using it in place of what I see as a
> > proper API. The drivers should really stand alone and not call into
> > board code, and vice versa. If the driver needs some settings, then
> > perhaps we can provide it via device tree / platform data?
>
> The problem with using the device tree is we want to share with Linux.
> Linux DTs will not describe this sort of thing. Platform data,
> maybe... but it is not something that is defined. That means it will
> be very difficult to make standard.
>
> On a side note, the same thing troubles me wrt MDIO and phy
> descriptions in DTs. It seems each MAC device tree has a different way
> to describe the relationships.
>
> > What will the other zynq boards do to read this information? How
> > different will each implementation be?
>
> That's part of the problem. It's hard to make a good API when it's
> only the first or second board that wants to do this. The next one
> will have a different requirement.
>
> > That said, since this is confined to zynq it's not a big concern.
>
> It seems like it's worth cleaning up after there is a clear need to
> have an API. Until there are a number of boards that need something
> like this, I think an informal API (like this weak stuff) is 

Re: [U-Boot] [PATCH] fdt: Try to read #address-cells/size-cells from parent

[Michal Simek]

Hi Simon,

On 16.2.2016 17:00, Simon Glass wrote:
> Hi Michal,
> 
> On 15 February 2016 at 02:58, Michal Simek  wrote:
>> Hi Simon,
>>
>> On 10.2.2016 13:04, Michal Simek wrote:
>>> Read #address-cells and #size-cells from parent if they are not present in
>>> current node.
>>>
>>> Signed-off-by: Michal Simek 
>>> ---
>>>
>>> I have code which read information about memory for zynqmp but memory
>>> node most of the time doesn't contain #address/size-cells which are
>>> present in parent node.
>>> That's why let's try to read it from parent.
>>>
>>> Also I think that we shouldn't return 2 if property is not found because
>>> it has side effect on 32bit systems with #address/size-cells = <1>;
>>>
>>> ---
>>>  lib/libfdt/fdt_addresses.c | 18 ++
>>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/libfdt/fdt_addresses.c b/lib/libfdt/fdt_addresses.c
>>> index 76054d98e5fd..b164d0988079 100644
>>> --- a/lib/libfdt/fdt_addresses.c
>>> +++ b/lib/libfdt/fdt_addresses.c
>>> @@ -19,10 +19,15 @@ int fdt_address_cells(const void *fdt, int nodeoffset)
>>>   const fdt32_t *ac;
>>>   int val;
>>>   int len;
>>> + int parent;
>>>
>>>   ac = fdt_getprop(fdt, nodeoffset, "#address-cells", );
>>> - if (!ac)
>>> - return 2;
>>> + if (!ac) {
>>> + parent = fdt_parent_offset(fdt, nodeoffset);
>>> + ac = fdt_getprop(fdt, parent, "#address-cells", );
>>> + if (!ac)
>>> + return 2;
>>> + }
>>>
>>>   if (len != sizeof(*ac))
>>>   return -FDT_ERR_BADNCELLS;
>>> @@ -39,10 +44,15 @@ int fdt_size_cells(const void *fdt, int nodeoffset)
>>>   const fdt32_t *sc;
>>>   int val;
>>>   int len;
>>> + int parent;
>>>
>>>   sc = fdt_getprop(fdt, nodeoffset, "#size-cells", );
>>> - if (!sc)
>>> - return 2;
>>> + if (!sc) {
>>> + parent = fdt_parent_offset(fdt, nodeoffset);
>>> + sc = fdt_getprop(fdt, parent, "#size-cells", );
>>> + if (!sc)
>>> + return 2;
>>> + }
>>>
>>>   if (len != sizeof(*sc))
>>>   return -FDT_ERR_BADNCELLS;
>>>
>>
>> Simon: Any comment?
> 
> It seems risky to change the behaviour here. Also fdt_parent_offset() is slow.
> 
> Can you point me to the binding / example DT that you are trying to parse?

Look at dram_init(), etc.
https://github.com/Xilinx/u-boot-xlnx/blob/master/board/xilinx/zynqmp/zynqmp.c

fdt_get_reg() is calling fdt_size_cells()


And this is DTS fragment.
#address-cells = <2>;
#size-cells = <1>;

memory {
device_type = "memory";
reg = <0x0 0x0 0x8000>, <0x8 0x 0x8000>;
};

Code is in memory node I need to work with and asking for size-cells.
Current code returns 2 instead of error and the rest of code just works
with size = 2 which is incorrect for this setup.

I have already changed size-cells = 2 in our repo because I need to
support for more than 4GB memory anyway but this should point to the
problem in that generic functions.

Thanks,
Michal

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

Re: [U-Boot] [PATCH 1/6] net: gem: Add support for reading MAC from I2C EEPROM

[Joe Hershberger]

Hi Simon,

On Tue, Feb 16, 2016 at 9:59 AM, Simon Glass  wrote:
> Hi,
>
> On 15 February 2016 at 18:06, Bin Meng  wrote:
>> +Simon,
>>
>> Hi Joe,
>>
>> On Tue, Feb 16, 2016 at 12:01 AM, Joe Hershberger
>>  wrote:
>>> Hi Bin,
>>>
>>> On Sun, Feb 14, 2016 at 6:00 AM, Bin Meng  wrote:
 Hi Michal,

 On Sun, Feb 14, 2016 at 6:03 PM, Michal Simek  wrote:
> Hi Bin,
>
> 2016-02-14 3:25 GMT+01:00 Bin Meng :
>>
>> Hi Michal,
>>
>> On Sat, Feb 13, 2016 at 6:39 PM, Michal Simek  wrote:
>> > Add support for reading MAC address from I2C EEPROM.
>> >
>>
>> Is this a feature provided by the GEM MAC IP?
>>
>> > Signed-off-by: Michal Simek 
>> > ---
>> >
>> >  drivers/net/zynq_gem.c | 16 
>> >  1 file changed, 16 insertions(+)
>> >
>> > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
>> > index b3821c31a91d..ace60c901cb5 100644
>> > --- a/drivers/net/zynq_gem.c
>> > +++ b/drivers/net/zynq_gem.c
>> > @@ -627,6 +627,21 @@ static int zynq_gem_remove(struct udevice *dev)
>> > return 0;
>> >  }
>> >
>> > +static int zynq_gem_read_rom_hwaddr(struct udevice *dev)
>> > +{
>> > +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
>> > +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET)
>> > +   struct eth_pdata *pdata = dev_get_platdata(dev);
>> > +
>> > +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
>> > +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
>> > +   pdata->enetaddr, ARRAY_SIZE(pdata->enetaddr)))
>>
>> This call to eeprom_read() looks to me a board-specific feature, that
>> an on-board eeprom is used to store the MAC address for the GEM?
>>
>
> Right. it is board specific feature I can
> The question is if this should really go to board specific file
> or to be the part of DT binding. I didn't look at the kernel if someone 
> has
> some sort of eeprom binding for this case
> but I expect local mac addresses via DT are used. Or passing via command
> line does it.
>
> Anyway there is mac_read_from_eeprom() but it is ancient one.
> Do you any preference for the name of function?

 I think the intention of the read_rom_hwaddr op is to read the MAC
 address via the ethernet controller defined mechanism (eg: e1000 can
 read its MAC address from either an EEPROM or an SPI flash), or via
 SoC defined mechanism (eg: the ethernet IP is only seen on a specific
 SoC, and reading the MAC address only makes sense on that specific
 SoC). If this is a board-specific mechanism, I don't think we should
 put the codes into driver's read_rom_hwaddr(). Again, if it is
 board-specific, we may not come up with a standard DT binding for such
 stuff, unless we can enumerate all possible ways for storing MAC
 address on a board (EEPROM, SPI flash, eMMC, SD)?
>>>
>>> Did you see this: https://patchwork.ozlabs.org/patch/573373/
>>>
>>
>> I haven't noticed this before.
>>
>>> This is the concept I had in mind for handling this sort of thing.
>>>
>>
>> Your patch looks good to me, but I added Simon, who is not a big fan
>> of using weak in driver model :-)
>
> My main concern with 'weak' is using it in place of what I see as a
> proper API. The drivers should really stand alone and not call into
> board code, and vice versa. If the driver needs some settings, then
> perhaps we can provide it via device tree / platform data?

The problem with using the device tree is we want to share with Linux.
Linux DTs will not describe this sort of thing. Platform data,
maybe... but it is not something that is defined. That means it will
be very difficult to make standard.

On a side note, the same thing troubles me wrt MDIO and phy
descriptions in DTs. It seems each MAC device tree has a different way
to describe the relationships.

> What will the other zynq boards do to read this information? How
> different will each implementation be?

That's part of the problem. It's hard to make a good API when it's
only the first or second board that wants to do this. The next one
will have a different requirement.

> That said, since this is confined to zynq it's not a big concern.

It seems like it's worth cleaning up after there is a clear need to
have an API. Until there are a number of boards that need something
like this, I think an informal API (like this weak stuff) is simpler.

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

Re: [U-Boot] test/py main_signon

[Michal Simek]

Hi Heiko,

On 16.2.2016 14:32, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>> Hi Stephen,
>>
>> trying to run the latest testing on zynq board and getting this
>> main_signon error.
>>
>> This is what I am running
>> ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
>> and getting below.
> 
> Does this board has SPL support without SPL serial output?

I do load u-boot via jtag that's why SPL logs are not visible.

> If so, can you try my patch:
> http://patchwork.ozlabs.org/patch/583348/

I have applied your patch but it is still not working.

If I run full flow with SPL then I can't see any issue.

Thanks,
Michal


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

Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

[Simon Glass]

Hi Tom,

On 16 February 2016 at 08:47, Tom Warren  wrote:
>
> Simon
>
> > -Original Message-
> > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> > Sent: Sunday, February 14, 2016 6:19 PM
> > To: Stephen Warren 
> > Cc: U-Boot Mailing List ; Marcel Ziswiler
> > ; Tom Warren ;
> > Stephen Warren ; Pantelis Antoniou  > consulting.com>; Marek Vasut ; Pavel Herrmann
> > ; Anatolij Gustschin 
> > Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video
> > drivers to driver model
> >
> > Hi,
> >
> > On 1 February 2016 at 17:00, Stephen Warren 
> > wrote:
> > >
> > > On 01/30/2016 04:37 PM, Simon Glass wrote:
> > >>
> > >> This series moves these two drivers over to use driver model for video.
> > >>
> > >> This involves the following steps:
> > >> - Sync up some device tree files with Linux
> > >> - Implement a proper PWM driver
> > >> - Clean up and unify the driver code
> > >> - Modify the existing drivers to work with driver model
> > >>
> > >> The tegra20 display driver uses device tree bindings invented in 2011
> > >> before Linux had this or anyone was able to agree a standard. It
> > >> seems possible to move it to the new bindings (like tegra124) except
> > >> for the issue of time delays between stages. It isn't clear how this
> > >> should work, and Linux implements this by including all LCD
> > >> definitions in the kernel source code, and not using any delays. This
> > >> causes strange display artifacts on the display when starting up, but
> > >> perhaps is harmless to the display. Future work will sync up the
> > >> device tree more for seaboard, and thus tidy this up for nvidia boards.
> > >>
> > >> A bug in the keyboard driver is also fixed by this series. The series
> > >> is tested on seaboard and nyan-big, the two boards I have which
> > >> support a display.
> > >>
> > >> This series is available at u-boot-dm/tegra-working.
> > >
> > >
> > > This changes the name of the output device from "lcd" to "vidconsole".
> > Anyone who doesn't reset their environment to default when switching to this
> > new U-Boot will lose their display output because of this. Is there any way 
> > to
> > maintain compatibility?
> > >
> > > Aside from that, I don't see any issues on Springbank (Seaboard),
> > > Harmony, Ventana, Paz00, or p2371-2180, so the series,
> > > Tested-by: Stephen Warren 
> >
> > It looks like some of the patches have been applied and all Tegra boards are
> > now giving Kconfig warnings.
> >
> > Tom Warren, are you able to pick up the rest of the series?
> I had thought these had already gone in via the dm repo. If not, please list 
> those that still need to be picked up and I'll take them in via tegra. Best 
> to assign the appropriate ones to me in patchwork. Currently it seems they're 
> all assigned to me. Which patches have already been applied?

I think it was the follow-up patches to add the environment
work-around that was applied.

6c88b51 video: tegra: Enable the 'lcd' env variable work-around
a2931b3 dm: video: Add a temporary work-around for old stdout var

I see the original v2 series here:

http://patchwork.ozlabs.org/project/uboot/list/?delegate=4839

so that is what needs to be applied I think. Then the Tegra config
issue should be fixed.

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

Re: [U-Boot] [RFC PATCH v4 1/3] sandbox: Fix compiling warning on 32-bit host

[Simon Glass]

+Masahiro

Hi York,

On 12 February 2016 at 13:59, York Sun  wrote:
> Fix the following compiling warning on 32-bit host
>
> disk/part_efi.c: In function 'alloc_read_gpt_entries':
> disk/part_efi.c:894:2: warning: format '%zu' expects argument of
>  type 'size_t', but argument 5 has type 'long unsigned int'
>  [-Wformat]
> disk/part_efi.c:907:4: warning: format '%zX' expects argument of
>  type 'size_t', but argument 3 has type 'long unsigned int'
>  [-Wformat]
> cmd/lzmadec.c: In function 'do_lzmadec':
> cmd/lzmadec.c:39:12: warning: passing argument 2 of
>  'lzmaBuffToBuffDecompress' from incompatible pointer type
>  [enabled by default]
> include/lzma/../../lib/lzma/LzmaTools.h:17:12: note: expected
>  'SizeT *' but argument is of type 'long unsigned int *'
> lib/hashtable.c: In function 'hexport_r':
> lib/hashtable.c:605:2: warning: format '%zu' expects argument of
>  type 'size_t', but argument 5 has type 'long unsigned int'
>  [-Wformat]
> lib/hashtable.c:661:5: warning: format '%zu' expects argument of
>  type 'size_t', but argument 2 has type 'long unsigned int'
>  [-Wformat]
> lib/hashtable.c:661:5: warning: format '%zu' expects argument of
>  type 'size_t', but argument 3 has type 'long unsigned int'
>  [-Wformat]
> lib/hashtable.c: In function 'himport_r':
> lib/hashtable.c:793:3: warning: format '%zu' expects argument of
>  type 'size_t', but argument 2 has type 'long unsigned int'
>  [-Wformat]
>
> Signed-off-by: York Sun 
>
> ---
>
> Changes in v4:
>   New patch to fix compiling warnings for sandbox built on 32-bit host
>   Still need to change CONFIG_SANDBOX_BITS_PER_LONG to 32 to avoid
>   these warnings
>   include/asm-generic/bitops/__fls.h:17:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:19:3: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:22:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:26:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:30:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:34:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:38:2: warning: left shift
>count >= width of type [enabled by default]
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/cpu.c   |3 ++-
>  arch/sandbox/include/asm/types.h |4 ++--
>  arch/sandbox/lib/bootm.c |3 ++-
>  arch/sandbox/lib/pci_io.c|2 +-
>  cmd/bootm.c  |4 ++--
>  cmd/lzmadec.c|5 +++--
>  disk/part_efi.c  |2 +-
>  include/image.h  |6 ++
>  lib/hashtable.c  |2 +-
>  9 files changed, 20 insertions(+), 11 deletions(-)

I think this makes sense. But one nit - the % is not included in the
macros in inttypes,h. What do you think about doing the same with your
macro?

>
> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
> index 196f3e1..7aad876 100644
> --- a/arch/sandbox/cpu/cpu.c
> +++ b/arch/sandbox/cpu/cpu.c
> @@ -62,7 +62,8 @@ void *map_physmem(phys_addr_t paddr, unsigned long len, 
> unsigned long flags)
> map_dev = NULL;
> if (enable_pci_map && !pci_map_physmem(paddr, , _dev, )) {
> if (plen != len) {
> -   printf("%s: Warning: partial map at %x, wanted %lx, 
> got %lx\n",
> +   printf("%s: Warning: partial map at " PRIpa
> +  ", wanted %lx, got %lx\n",
>__func__, paddr, len, plen);
> }
> map_len = len;
> diff --git a/arch/sandbox/include/asm/types.h 
> b/arch/sandbox/include/asm/types.h
> index 42c09e2..c3bb76e 100644
> --- a/arch/sandbox/include/asm/types.h
> +++ b/arch/sandbox/include/asm/types.h
> @@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
>  #define BITS_PER_LONG  CONFIG_SANDBOX_BITS_PER_LONG
>
>  typedef unsigned long dma_addr_t;
> -typedef u32 phys_addr_t;
> -typedef u32 phys_size_t;
> +typedef unsigned long phys_addr_t;
> +typedef unsigned long phys_size_t;
>
>  #endif /* __KERNEL__ */
>
> diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
> index d49c927..9ca89b5 100644
> --- a/arch/sandbox/lib/bootm.c
> +++ b/arch/sandbox/lib/bootm.c
> @@ -54,7 +54,8 @@ int do_bootm_linux(int flag, int argc, char *argv[], 
> bootm_headers_t *images)
>  {
> if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
> bootstage_mark(BOOTSTAGE_ID_RUN_OS);
> -   printf("## Transferring control to Linux (at address 
> %08lx)...\n",
> +   printf("## Transferring control to Linux (at address " PRIpa
> +  ")...\n",
>  

Re: [U-Boot] [RFC PATCH v4 3/3] common: Fix load and entry addresses in FIT image

[Simon Glass]

Hi York,

On 12 February 2016 at 13:59, York Sun  wrote:
> FIT image supports more than 32 bits in addresses by using #address-cell
> field. However the address length is not handled when parsing FIT images.
>

nit: How about saying "fix this by adding support for 64-bit
addresses" or similar

> Signed-off-by: York Sun 
>
> ---
>
> Changes in v4:
>   Separate ulong to phys_addr_t change to another patch.
>
> Changes in v3:
>   Define PRIpa for host and target in common/image-fit.c so printf works
>   properly for 32-, 64-bit targets and host tools.
>
> Changes in v2:
>   Make a common function for both load and entry addresses.
>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>   fdtdec_get_number() is not used, or too many files need to be included
> and/or twisted for host tool
>   Continue to use %08llx for print format for load and entry addresses
> because %pa does not always work for host tool (mkimage)
>
>  common/image-fit.c |   54 
> ++--
>  1 file changed, 31 insertions(+), 23 deletions(-)
>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index bfa76a2..c000475 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -433,7 +433,7 @@ void fit_image_print(const void *fit, int image_noffset, 
> const char *p)
>
> if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE) ||
> (type == IH_TYPE_RAMDISK)) {
> -   fit_image_get_entry(fit, image_noffset, );
> +   ret = fit_image_get_entry(fit, image_noffset, );
> printf("%s  Entry Point:  ", p);
> if (ret)
> printf("unavailable\n");
> @@ -675,6 +675,34 @@ int fit_image_get_comp(const void *fit, int noffset, 
> uint8_t *comp)
> return 0;
>  }
>
> +static int fit_image_get_address(const void *fit, int noffset, char *name,
> + phys_addr_t *load)
> +{
> +   int len, cell_len;
> +   const fdt32_t *cell;
> +   unsigned long long load64 = 0;
> +
> +   cell = fdt_getprop(fit, noffset, name, );
> +   if (cell == NULL) {
> +   fit_get_debug(fit, noffset, name, len);
> +   return -1;
> +   }
> +
> +   if (len > sizeof(phys_addr_t)) {
> +   printf("Unsupported %s address size\n", name);
> +   return -1;
> +   }
> +
> +   cell_len = len >> 2;
> +   /* Use load64 to avoid compiling warning for 32-bit target */
> +   while (cell_len--) {
> +   load64 = (load64 << 32) | uimage_to_cpu(*cell);
> +   cell++;
> +   }
> +   *load = (phys_addr_t)load64;
> +
> +   return 0;
> +}
>  /**
>   * fit_image_get_load() - get load addr property for given component image 
> node
>   * @fit: pointer to the FIT format image header
> @@ -690,17 +718,7 @@ int fit_image_get_comp(const void *fit, int noffset, 
> uint8_t *comp)
>   */
>  int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load)
>  {
> -   int len;
> -   const uint32_t *data;
> -
> -   data = fdt_getprop(fit, noffset, FIT_LOAD_PROP, );
> -   if (data == NULL) {
> -   fit_get_debug(fit, noffset, FIT_LOAD_PROP, len);
> -   return -1;
> -   }
> -
> -   *load = uimage_to_cpu(*data);
> -   return 0;
> +   return fit_image_get_address(fit, noffset, FIT_LOAD_PROP, load);

I think it would make sense to have your new fit_image_get_address()
in one patch, and the enhancement to support more address sizes in
another.

>  }
>
>  /**
> @@ -722,17 +740,7 @@ int fit_image_get_load(const void *fit, int noffset, 
> phys_addr_t *load)
>   */
>  int fit_image_get_entry(const void *fit, int noffset, phys_addr_t *entry)
>  {
> -   int len;
> -   const uint32_t *data;
> -
> -   data = fdt_getprop(fit, noffset, FIT_ENTRY_PROP, );
> -   if (data == NULL) {
> -   fit_get_debug(fit, noffset, FIT_ENTRY_PROP, len);
> -   return -1;
> -   }
> -
> -   *entry = uimage_to_cpu(*data);
> -   return 0;
> +   return fit_image_get_address(fit, noffset, FIT_ENTRY_PROP, entry);
>  }
>
>  /**
> --
> 1.7.9.5
>

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

Re: [U-Boot] [PATCH v2 7/7] defconfig: dra72_evm: enable disk driver model

[Simon Glass]

On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> Enable disk driver model for dra72_evm as dwc_ahci supports
> driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  configs/dra72_evm_defconfig | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v2 6/7] defconfig: dra74_evm: enable disk driver model

[Simon Glass]

On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> Enable disk driver model for dra74_evm as dwc_ahci supports
> driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  configs/dra74_evm_defconfig | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v2 4/7] arm: omap-common: sata: prepare driver for DM conversion

[Simon Glass]

On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> Prepare sata driver for DM conversion by abstracting sata phy
> init to seperate function.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  arch/arm/cpu/armv7/omap-common/sata.c | 13 +
>  include/sata.h|  2 ++
>  2 files changed, 11 insertions(+), 4 deletions(-)

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

Re: [U-Boot] how does board_init_f() -> board_init_r?

[Simon Glass]

+Stephen who will know more

Hi,

On 13 February 2016 at 18:52, quantumlight  wrote:
> I am trying to modify the bootloader code for NVIDIA's jetson board.
>
> So I am looking at crt0.S. It seems that two builds happen, one with
> CONFIG_SPL_BUILD and one without. So you end up with two file, u-boot.bin
> and spl/u-boot-spl.bin.

SPL is built with ARMv4t
U-Boot proper is built with ARMv7

That's why SPL is used on Tegra. The SPL does not actually load
U-Boot. In fact both are bundle together and loaded at the same time.
SPL simply jumps to U-Boot when needed.

>
> However, I am unable to find the code path that calls board_init_r() after
> board_init_f() finishes, although there are several candidates:
>
> 1) crt0.S - if CONFIG_SPL_BUILD was not defined, then it would fall straight
> through to board_init_r() - HOWEVER, for u-boot.bin, isn't CONFIG_SPL_BUILD
> defined in autoconf.h? Or is this some clever magic between how u-boot.bin
> and spl/u-boot-spl.bin are stitched together?

For U-Boot, CONFIG_SPL_BUILD is not defined. That define means you are
building SPL.

The clever magic is mostly 'cat'. SPL is padded a little and then
U-Boot is added on the end.

> 2) _weak board_init_f in arch/arm/lib/spl.c - HOWEVER, shouldn't this be
> overloaded by board_init_f in common/board_f.c?

The latter is only used in U-Boot proper. SPL has its own board_init_f().

> 3) board_init_f_r in common/board_f.c - HOWEVER, nothing calls
> board_init_f_r().

No, that is not used on ARM.

>
> Can someone illuminate me on how this happens?
>

See the README under Board Initialisation Flow. In brief, the link
between board_init_f() and board_init_r() is generally the crt0.S that
you found. The catch is that some boards don't implement
board_init_f() in SPL, and so use the weak one, which in fact calls
board_init_r() directly.

See also arch/arm/mach-tegra/board.c which I think contains the code
to jump to SPL.

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

Re: [U-Boot] [PATCH V2 1/2] pinctrl: imx: Introduce pinctrl driver for i.MX6

[Simon Glass]

Hi Peng,

On 15 February 2016 at 01:33, Peng Fan  wrote:
> Hi Simon,
>
> Gentle ping..

Do you mean Stefan? I reviewed the previous so did not think it
necessary to look again.

>
> Thanks,
> Peng.

Regards,
Simon

>
> On Wed, Feb 03, 2016 at 10:06:07AM +0800, Peng Fan wrote:
>>Introduce pinctrl for i.MX6
>>1. pinctrl-imx.c is for common usage. It's used by i.MX6/7.
>>2. Add PINCTRL_IMX PINCTRL_IMX6 Kconfig entry.
>>3. To the pinctrl_ops implementation, only set_state is implemented.
>>   To i.MX6/7, the pinctrl dts entry is as following:
>> {
>>pinctrl-names = "default";
>>
>>pinctrl_csi1: csi1grp {
>>fsl,pins = <
>>MX6UL_PAD_CSI_MCLK__CSI_MCLK0x1b088
>>MX6UL_PAD_CSI_PIXCLK__CSI_PIXCLK0x1b088
>>MX6UL_PAD_CSI_VSYNC__CSI_VSYNC  0x1b088
>>>;
>>};
>>
>>[.]
>>};
>>  there is no property named function or groups. So pinctrl_generic_set_state
>>  can not be used here.
>>5. This driver is a simple implementation for i.mx iomux controller,
>>   only parse the fsl,pins property and write value to registers.
>>6. With DEBUG enabled, we can see log when "i2c bus 0":
>>   "
>>   set_state_simple op missing
>>   imx_pinctrl_set_state: i2c1grp
>>   mux_reg 0x14c, conf_reg 0x3bc, input_reg 0x5d8, mux_mode 0x0, input_val 
>> 0x1, config_val 0x407f
>>   write mux: offset 0x14c val 0x10
>>   select_input: offset 0x5d8 val 0x1
>>   write config: offset 0x3bc val 0x7f
>>   mux_reg 0x148, conf_reg 0x3b8, input_reg 0x5d4, mux_mode 0x0, input_val 
>> 0x1, config_val 0x407f
>>   write mux: offset 0x148 val 0x10
>>   select_input: offset 0x5d4 val 0x1
>>   write config: offset 0x3b8 val 0x7f
>>   "
>>   this means imx6 pinctrl driver works as expected.
>>
>>Signed-off-by: Peng Fan 
>>Reviewed-by: Simon Glass 
>>---
>>
>>V2:
>> Add more details in Kconfig entry
>> Use fdt_getprop and fdtdec_get_int_array as suggested by Simon
>> Add reviewed-by Simon
>> Refer linux binding doc in code.
>>
>> drivers/pinctrl/Kconfig|   1 +
>> drivers/pinctrl/Makefile   |   1 +
>> drivers/pinctrl/nxp/Kconfig|  16 +++
>> drivers/pinctrl/nxp/Makefile   |   2 +
>> drivers/pinctrl/nxp/pinctrl-imx.c  | 241 
>> +
>> drivers/pinctrl/nxp/pinctrl-imx.h  |  50 
>> drivers/pinctrl/nxp/pinctrl-imx6.c |  41 +++
>> 7 files changed, 352 insertions(+)
>> create mode 100644 drivers/pinctrl/nxp/Kconfig
>> create mode 100644 drivers/pinctrl/nxp/Makefile
>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx.c
>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx.h
>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx6.c
>>
>>diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
>>index 57e6142..9fd8f62 100644
>>--- a/drivers/pinctrl/Kconfig
>>+++ b/drivers/pinctrl/Kconfig
>>@@ -133,6 +133,7 @@ config PINCTRL_SANDBOX
>>
>> endif
>>
>>+source "drivers/pinctrl/nxp/Kconfig"
>> source "drivers/pinctrl/uniphier/Kconfig"
>>
>> endmenu
>>diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
>>index 70d25dc..dcd20bf 100644
>>--- a/drivers/pinctrl/Makefile
>>+++ b/drivers/pinctrl/Makefile
>>@@ -5,6 +5,7 @@
>> obj-y += pinctrl-uclass.o
>> obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC)  += pinctrl-generic.o
>>
>>+obj-y += nxp/
>> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
>> obj-$(CONFIG_PINCTRL_SANDBOX) += pinctrl-sandbox.o
>>
>>diff --git a/drivers/pinctrl/nxp/Kconfig b/drivers/pinctrl/nxp/Kconfig
>>new file mode 100644
>>index 000..f1c9b92
>>--- /dev/null
>>+++ b/drivers/pinctrl/nxp/Kconfig
>>@@ -0,0 +1,16 @@
>>+config PINCTRL_IMX
>>+  bool
>>+
>>+config PINCTRL_IMX6
>>+  bool "IMX6 pinctrl driver"
>>+  depends on ARCH_MX6 && PINCTRL_FULL
>>+  select DEVRES
>>+  select PINCTRL_IMX
>>+  help
>>+Say Y here to enable the imx6 pinctrl driver
>>+
>>+This provides a simple pinctrl driver for i.MX6 SoC familiy,
>>+i.MX6DQ/SL/SX/UL/DQP. This feature depends on device tree
>>+configuration. This driver is different from the linux one,
>>+this is a simple implementation, only parses the 'fsl,pins'
>>+property and configure related registers.
>>diff --git a/drivers/pinctrl/nxp/Makefile b/drivers/pinctrl/nxp/Makefile
>>new file mode 100644
>>index 000..7fd9850
>>--- /dev/null
>>+++ b/drivers/pinctrl/nxp/Makefile
>>@@ -0,0 +1,2 @@
>>+obj-$(CONFIG_PINCTRL_IMX) += pinctrl-imx.o
>>+obj-$(CONFIG_PINCTRL_IMX6)+= pinctrl-imx6.o
>>diff --git a/drivers/pinctrl/nxp/pinctrl-imx.c 
>>b/drivers/pinctrl/nxp/pinctrl-imx.c
>>new file mode 100644
>>index 000..40b0616
>>--- /dev/null
>>+++ b/drivers/pinctrl/nxp/pinctrl-imx.c
>>@@ -0,0 +1,241 @@
>>+/*
>>+ * Copyright (C) 2016 Peng Fan 
>>+ *
>>+ * 

Re: [U-Boot] [PATCH v2 2/7] arm: omap: sata: compile out sata init apis when CONFIG_DISK is defined

[Simon Glass]

On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> Compile out sata init/reset apis as this will be implemented in
> disk-uclass driver to initialize sata devices.
>
> Signed-off-by: Mugunthan V N 
> ---
>  arch/arm/cpu/armv7/omap-common/sata.c | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v2 1/7] arm: omap: sata: move enable sata clocks to enable_basic_clocks()

[Simon Glass]

On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> All the clocks which has to be enabled has to be done in
> enable_basic_clocks(), so moving enable sata clock to common
> clocks enable function.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  arch/arm/cpu/armv7/omap-common/sata.c | 23 ---
>  arch/arm/cpu/armv7/omap5/hw_data.c| 12 
>  2 files changed, 12 insertions(+), 23 deletions(-)

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

Re: [U-Boot] [PATCH 3/4] stm32x7: add support for stm32x7 serial driver

[Simon Glass]

On 11 February 2016 at 16:47, Vikas Manocha  wrote:
> This patch adds support for stm32f7 family usart peripheral.
>
> Signed-off-by: Vikas Manocha 
> ---
>  drivers/serial/Makefile   |  1 +
>  drivers/serial/serial_stm32x7.c   | 83 
> +++
>  drivers/serial/serial_stm32x7.h   | 37 ++
>  include/dm/platform_data/serial_stm32x7.h | 17 +++
>  4 files changed, 138 insertions(+)
>  create mode 100644 drivers/serial/serial_stm32x7.c
>  create mode 100644 drivers/serial/serial_stm32x7.h
>  create mode 100644 include/dm/platform_data/serial_stm32x7.h

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

Re: [U-Boot] [PATCH 3/3] spi: omap3: Convert to driver model

[Simon Glass]

On 11 February 2016 at 12:00, Jagan Teki  wrote:
> After this conversion the driver will able to support
> both dm and non-dm and code is more extensible like we
> can remove the non-dm part simply without touching anycode
> if all the boards which are using this driver become dm driven.
>
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Christophe Ricard 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/omap3_spi.c | 678 
> +---
>  1 file changed, 407 insertions(+), 271 deletions(-)

Reviewed-by: Simon Glass 

Can CONFIG_OMAP3_SPI_D0_D1_SWAPPED be moved to device tree for the DM version?

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

Re: [U-Boot] [PATCH] fdt: Try to read #address-cells/size-cells from parent

[Simon Glass]

Hi Michal,

On 15 February 2016 at 02:58, Michal Simek  wrote:
> Hi Simon,
>
> On 10.2.2016 13:04, Michal Simek wrote:
>> Read #address-cells and #size-cells from parent if they are not present in
>> current node.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>> I have code which read information about memory for zynqmp but memory
>> node most of the time doesn't contain #address/size-cells which are
>> present in parent node.
>> That's why let's try to read it from parent.
>>
>> Also I think that we shouldn't return 2 if property is not found because
>> it has side effect on 32bit systems with #address/size-cells = <1>;
>>
>> ---
>>  lib/libfdt/fdt_addresses.c | 18 ++
>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/libfdt/fdt_addresses.c b/lib/libfdt/fdt_addresses.c
>> index 76054d98e5fd..b164d0988079 100644
>> --- a/lib/libfdt/fdt_addresses.c
>> +++ b/lib/libfdt/fdt_addresses.c
>> @@ -19,10 +19,15 @@ int fdt_address_cells(const void *fdt, int nodeoffset)
>>   const fdt32_t *ac;
>>   int val;
>>   int len;
>> + int parent;
>>
>>   ac = fdt_getprop(fdt, nodeoffset, "#address-cells", );
>> - if (!ac)
>> - return 2;
>> + if (!ac) {
>> + parent = fdt_parent_offset(fdt, nodeoffset);
>> + ac = fdt_getprop(fdt, parent, "#address-cells", );
>> + if (!ac)
>> + return 2;
>> + }
>>
>>   if (len != sizeof(*ac))
>>   return -FDT_ERR_BADNCELLS;
>> @@ -39,10 +44,15 @@ int fdt_size_cells(const void *fdt, int nodeoffset)
>>   const fdt32_t *sc;
>>   int val;
>>   int len;
>> + int parent;
>>
>>   sc = fdt_getprop(fdt, nodeoffset, "#size-cells", );
>> - if (!sc)
>> - return 2;
>> + if (!sc) {
>> + parent = fdt_parent_offset(fdt, nodeoffset);
>> + sc = fdt_getprop(fdt, parent, "#size-cells", );
>> + if (!sc)
>> + return 2;
>> + }
>>
>>   if (len != sizeof(*sc))
>>   return -FDT_ERR_BADNCELLS;
>>
>
> Simon: Any comment?

It seems risky to change the behaviour here. Also fdt_parent_offset() is slow.

Can you point me to the binding / example DT that you are trying to parse?

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

Re: [U-Boot] [PATCH 1/6] net: gem: Add support for reading MAC from I2C EEPROM

[Simon Glass]

Hi,

On 15 February 2016 at 18:06, Bin Meng  wrote:
> +Simon,
>
> Hi Joe,
>
> On Tue, Feb 16, 2016 at 12:01 AM, Joe Hershberger
>  wrote:
>> Hi Bin,
>>
>> On Sun, Feb 14, 2016 at 6:00 AM, Bin Meng  wrote:
>>> Hi Michal,
>>>
>>> On Sun, Feb 14, 2016 at 6:03 PM, Michal Simek  wrote:
 Hi Bin,

 2016-02-14 3:25 GMT+01:00 Bin Meng :
>
> Hi Michal,
>
> On Sat, Feb 13, 2016 at 6:39 PM, Michal Simek  wrote:
> > Add support for reading MAC address from I2C EEPROM.
> >
>
> Is this a feature provided by the GEM MAC IP?
>
> > Signed-off-by: Michal Simek 
> > ---
> >
> >  drivers/net/zynq_gem.c | 16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> > index b3821c31a91d..ace60c901cb5 100644
> > --- a/drivers/net/zynq_gem.c
> > +++ b/drivers/net/zynq_gem.c
> > @@ -627,6 +627,21 @@ static int zynq_gem_remove(struct udevice *dev)
> > return 0;
> >  }
> >
> > +static int zynq_gem_read_rom_hwaddr(struct udevice *dev)
> > +{
> > +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
> > +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET)
> > +   struct eth_pdata *pdata = dev_get_platdata(dev);
> > +
> > +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
> > +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
> > +   pdata->enetaddr, ARRAY_SIZE(pdata->enetaddr)))
>
> This call to eeprom_read() looks to me a board-specific feature, that
> an on-board eeprom is used to store the MAC address for the GEM?
>

 Right. it is board specific feature I can
 The question is if this should really go to board specific file
 or to be the part of DT binding. I didn't look at the kernel if someone has
 some sort of eeprom binding for this case
 but I expect local mac addresses via DT are used. Or passing via command
 line does it.

 Anyway there is mac_read_from_eeprom() but it is ancient one.
 Do you any preference for the name of function?
>>>
>>> I think the intention of the read_rom_hwaddr op is to read the MAC
>>> address via the ethernet controller defined mechanism (eg: e1000 can
>>> read its MAC address from either an EEPROM or an SPI flash), or via
>>> SoC defined mechanism (eg: the ethernet IP is only seen on a specific
>>> SoC, and reading the MAC address only makes sense on that specific
>>> SoC). If this is a board-specific mechanism, I don't think we should
>>> put the codes into driver's read_rom_hwaddr(). Again, if it is
>>> board-specific, we may not come up with a standard DT binding for such
>>> stuff, unless we can enumerate all possible ways for storing MAC
>>> address on a board (EEPROM, SPI flash, eMMC, SD)?
>>
>> Did you see this: https://patchwork.ozlabs.org/patch/573373/
>>
>
> I haven't noticed this before.
>
>> This is the concept I had in mind for handling this sort of thing.
>>
>
> Your patch looks good to me, but I added Simon, who is not a big fan
> of using weak in driver model :-)

My main concern with 'weak' is using it in place of what I see as a
proper API. The drivers should really stand alone and not call into
board code, and vice versa. If the driver needs some settings, then
perhaps we can provide it via device tree / platform data?

What will the other zynq boards do to read this information? How
different will each implementation be?

That said, since this is confined to zynq it's not a big concern.

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

Re: [U-Boot] [PATCH v2 02/18] gpio: Add support for Qualcomm gpio controller

[Simon Glass]

Hi,

On 9 February 2016 at 14:25, Jagan Teki  wrote:
> On 8 February 2016 at 02:27, Mateusz Kulikowski
>  wrote:
>> Add support for gpio controllers on Qualcomm Snapdragon devices.
>> This devices are usually called Top Level Mode Multiplexing in
>> Qualcomm documentation.
>>
>> Signed-off-by: Mateusz Kulikowski 
>> Reviewed-by: Simon Glass 
>> Tested-by: Simon Glass 
>> ---
>>
>> Changes in v3: None
>> Changes in v2:
>> - Reordered includes (again)
>> - Added newlines between returns
>> - Fixed error handling in msm_gpio_probe
>> - Added reviewed-by
>>
>> Changes in v1:
>> - Added dt binding documentation
>> - Added help to KConfig
>> - Use clrsetbits() to switch direction
>> - Fixed include order
>> - Added #defines for registers/register fields
>> - Added secondary compatible string
>>
>>  doc/device-tree-bindings/gpio/gpio-msm.txt |  22 +
>>  drivers/gpio/Kconfig   |  14 +++
>>  drivers/gpio/Makefile  |   1 +
>>  drivers/gpio/msm_gpio.c| 135 
>> +
>>  4 files changed, 172 insertions(+)
>>  create mode 100644 doc/device-tree-bindings/gpio/gpio-msm.txt
>>  create mode 100644 drivers/gpio/msm_gpio.c
>>
>> diff --git a/doc/device-tree-bindings/gpio/gpio-msm.txt 
>> b/doc/device-tree-bindings/gpio/gpio-msm.txt
>> new file mode 100644
>> index 000..966ce0a
>> --- /dev/null
>> +++ b/doc/device-tree-bindings/gpio/gpio-msm.txt
>> @@ -0,0 +1,22 @@
>> +Qualcomm Snapdragon GPIO controller
>> +
>> +Required properties:
>> +- compatible : "qcom,msm8916-pinctrl" or "qcom,apq8016-pinctrl"
>> +- reg : Physical base address and length of the controller's registers.
>> +   This controller is called "Top Level Mode Multiplexing" in
>> +   Qualcomm documentation.
>> +- #gpio-cells : Should be one (pin number).
>> +- gpio-controller : Marks the device node as a GPIO controller.
>> +- gpio-count: Number of GPIO pins.
>> +- gpio-bank-name: (optional) name of gpio bank. As default "soc" is used.
>> +
>> +Example:
>> +
>> +soc_gpios: pinctrl@100 {
>> +   compatible = "qcom,msm8916-pinctrl";
>
> Can't this driver goes into pinctrl (I mean gpio handling pincontrol),
> because Linux handle these gpio msm8916-pinctrl through pinctrl
> subsystem as per as I know, let me know in case if I miss anything
> here.

I think Mateusz is planning to add this later. It would be good to get
this in as a starting point for this platform.

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

Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

[Tom Warren]

Simon

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Sunday, February 14, 2016 6:19 PM
> To: Stephen Warren 
> Cc: U-Boot Mailing List ; Marcel Ziswiler
> ; Tom Warren ;
> Stephen Warren ; Pantelis Antoniou  consulting.com>; Marek Vasut ; Pavel Herrmann
> ; Anatolij Gustschin 
> Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video
> drivers to driver model
> 
> Hi,
> 
> On 1 February 2016 at 17:00, Stephen Warren 
> wrote:
> >
> > On 01/30/2016 04:37 PM, Simon Glass wrote:
> >>
> >> This series moves these two drivers over to use driver model for video.
> >>
> >> This involves the following steps:
> >> - Sync up some device tree files with Linux
> >> - Implement a proper PWM driver
> >> - Clean up and unify the driver code
> >> - Modify the existing drivers to work with driver model
> >>
> >> The tegra20 display driver uses device tree bindings invented in 2011
> >> before Linux had this or anyone was able to agree a standard. It
> >> seems possible to move it to the new bindings (like tegra124) except
> >> for the issue of time delays between stages. It isn't clear how this
> >> should work, and Linux implements this by including all LCD
> >> definitions in the kernel source code, and not using any delays. This
> >> causes strange display artifacts on the display when starting up, but
> >> perhaps is harmless to the display. Future work will sync up the
> >> device tree more for seaboard, and thus tidy this up for nvidia boards.
> >>
> >> A bug in the keyboard driver is also fixed by this series. The series
> >> is tested on seaboard and nyan-big, the two boards I have which
> >> support a display.
> >>
> >> This series is available at u-boot-dm/tegra-working.
> >
> >
> > This changes the name of the output device from "lcd" to "vidconsole".
> Anyone who doesn't reset their environment to default when switching to this
> new U-Boot will lose their display output because of this. Is there any way to
> maintain compatibility?
> >
> > Aside from that, I don't see any issues on Springbank (Seaboard),
> > Harmony, Ventana, Paz00, or p2371-2180, so the series,
> > Tested-by: Stephen Warren 
> 
> It looks like some of the patches have been applied and all Tegra boards are
> now giving Kconfig warnings.
> 
> Tom Warren, are you able to pick up the rest of the series?
I had thought these had already gone in via the dm repo. If not, please list 
those that still need to be picked up and I'll take them in via tegra. Best to 
assign the appropriate ones to me in patchwork. Currently it seems they're all 
assigned to me. Which patches have already been applied?

Tom

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

[U-Boot] [PATCH] dm: ns16550: Add support for reg-offset property

[Michal Simek]

reg-offset is the part of standard 8250 binding in the kernel.
It is shifting start of address space by reg-offset.
On Xilinx platform this offset is typically 0x1000.

Signed-off-by: Michal Simek 
---

 drivers/serial/ns16550.c | 6 --
 include/ns16550.h| 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 93dad338b375..28da9ddfd859 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -105,7 +105,7 @@ static void ns16550_writeb(NS16550_t port, int offset, int 
value)
 * As far as we know it doesn't make sense to support selection of
 * these options at run-time, so use the existing CONFIG options.
 */
-   serial_out_shift(addr, plat->reg_shift, value);
+   serial_out_shift(addr + plat->reg_offset, plat->reg_shift, value);
 }
 
 static int ns16550_readb(NS16550_t port, int offset)
@@ -116,7 +116,7 @@ static int ns16550_readb(NS16550_t port, int offset)
offset *= 1 << plat->reg_shift;
addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset;
 
-   return serial_in_shift(addr, plat->reg_shift);
+   return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
 }
 
 /* We can clean these up once everything is moved to driver model */
@@ -401,6 +401,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
return -EINVAL;
 
plat->base = addr;
+   plat->reg_offset = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"reg-offset", 0);
plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
 "reg-shift", 0);
plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
diff --git a/include/ns16550.h b/include/ns16550.h
index 4e620676c453..5eeacd6ff945 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -54,6 +54,7 @@
  */
 struct ns16550_platdata {
unsigned long base;
+   int reg_offset;
int reg_shift;
int clock;
 };
-- 
1.9.1

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

Re: [U-Boot] [PATCH 18/30] dm: block: Rename device number member dev to devnum

[Bin Meng]

Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> This is a device number, and we want to use 'dev' to mean a driver model
> device. Rename the member.
>
> Signed-off-by: Simon Glass 
> ---
>
>  board/sunxi/board.c  |  4 ++--
>  cmd/cbfs.c   |  1 +
>  cmd/disk.c   |  2 +-
>  cmd/fat.c|  4 ++--
>  cmd/ide.c| 12 ++--
>  cmd/mmc_spi.c|  4 ++--
>  cmd/reiser.c |  4 ++--
>  cmd/sata.c   |  6 +++---
>  cmd/scsi.c   |  6 +++---
>  cmd/usb_mass_storage.c   |  2 +-
>  cmd/zfs.c|  2 +-
>  common/env_fat.c |  4 ++--
>  common/fb_mmc.c  |  4 ++--
>  common/usb_storage.c |  6 +++---
>  disk/part.c  |  8 ++--
>  disk/part_dos.c  | 29 +
>  disk/part_efi.c  |  4 ++--
>  disk/part_iso.c  | 39 ---
>  disk/part_mac.c  | 22 +++---
>  drivers/block/sandbox.c  |  6 +++---
>  drivers/block/systemace.c|  2 +-
>  drivers/mmc/arm_pl180_mmci.c |  2 +-
>  drivers/mmc/mmc.c|  8 
>  drivers/mmc/mmc_write.c  |  4 ++--
>  drivers/mmc/mxsmmc.c | 24 
>  drivers/mmc/omap_hsmmc.c |  4 ++--
>  drivers/mmc/sdhci.c  |  2 +-
>  fs/fat/fat.c |  4 ++--
>  include/blk.h|  2 +-
>  29 files changed, 112 insertions(+), 109 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 420481a..fd0cab9 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -336,8 +336,8 @@ int board_mmc_init(bd_t *bis)
> if (!sunxi_mmc_has_egon_boot_signature(mmc0) &&
> sunxi_mmc_has_egon_boot_signature(mmc1)) {
> /* Booting from emmc / mmc2, swap */
> -   mmc0->block_dev.dev = 1;
> -   mmc1->block_dev.dev = 0;
> +   mmc0->block_dev.devnum = 1;
> +   mmc1->block_dev.devnum = 0;
> }
>  #endif
>
> diff --git a/cmd/cbfs.c b/cmd/cbfs.c
> index cdfc9b6..779e9c0 100644
> --- a/cmd/cbfs.c
> +++ b/cmd/cbfs.c
> @@ -141,6 +141,7 @@ int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
> type_name = "cmos layout";
> break;
> case -1:
> +   case 0:

Guess you didn't want this change (a git rebase ordering issue?)

> type_name = "null";
> break;
> }

[snip]

Other than that,
Reviewed-by: Bin Meng 

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

Re: [U-Boot] [PATCH 16/30] dm: cbfs: Fix handling of invalid type

[Bin Meng]

Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> The comment for file_cbfs_type() says that it returns 0 for an invalid type.
> The code appears to check for -1, except that it uses an unsigned variable
> to store the type. This results in a warning on 64-bit machines.
>
> Adjust it to make the meaning clearer. Continue to handle the -1 case since
> it may be needed.
>
> Signed-off-by: Simon Glass 
> ---
>
>  cmd/cbfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/cbfs.c b/cmd/cbfs.c
> index 35d8a7a..cdfc9b6 100644
> --- a/cmd/cbfs.c
> +++ b/cmd/cbfs.c
> @@ -103,7 +103,7 @@ int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
> printf(" size  type  name\n");
> printf("--\n");
> while (file) {
> -   u32 type = file_cbfs_type(file);
> +   int type = file_cbfs_type(file);

but file_cbfs_type() returns u32 as its type..

> char *type_name = NULL;
> const char *filename = file_cbfs_name(file);
>
> @@ -140,7 +140,7 @@ int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
> case CBFS_COMPONENT_CMOS_LAYOUT:
> type_name = "cmos layout";
> break;
> -   case -1UL:
> +   case -1:

What about: case (u32)-1UL:

> type_name = "null";
> break;
> }
> --

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

Re: [U-Boot] [PATCH 15/30] dm: part: Rename some partition functions

[Bin Meng]

Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Rename three partition functions so that they start with part_. This makes
> it clear what they relate to.
>
> Signed-off-by: Simon Glass 
> ---
>
>  board/cm5200/fwupdate.c   |  2 +-
>  cmd/ide.c |  6 +++---
>  cmd/mmc.c |  2 +-
>  cmd/part.c|  8 
>  cmd/read.c|  2 +-
>  cmd/sata.c|  6 +++---
>  cmd/scsi.c|  6 +++---
>  cmd/usb.c |  4 ++--
>  common/fb_mmc.c   | 10 +-
>  common/spl/spl_ext.c  |  6 ++
>  common/spl/spl_mmc.c  |  2 +-
>  common/usb_storage.c  |  2 +-
>  disk/part.c   | 12 ++--
>  disk/part_amiga.c |  4 ++--
>  disk/part_dos.c   | 19 +--
>  disk/part_efi.c   | 10 +-
>  disk/part_iso.c   | 17 +
>  disk/part_mac.c   |  4 ++--
>  drivers/block/pata_bfin.c |  2 +-
>  drivers/block/sandbox.c   |  2 +-
>  drivers/block/systemace.c |  2 +-
>  drivers/dfu/dfu_mmc.c |  2 +-
>  drivers/mmc/mmc.c |  2 +-
>  fs/fat/fat.c  |  2 +-
>  include/part.h| 21 ++---
>  25 files changed, 76 insertions(+), 79 deletions(-)
>

[snip]

> diff --git a/disk/part_amiga.c b/disk/part_amiga.c
> index 0f569f0..d323b4b 100644
> --- a/disk/part_amiga.c
> +++ b/disk/part_amiga.c
> @@ -291,7 +291,7 @@ static struct partition_block *find_partition(struct 
> blk_desc *dev_desc,
>  /*
>   * Get info about a partition
>   */
> -static int get_partition_info_amiga(struct blk_desc *dev_desc, int part,
> +static int part_get_info_amiga(struct blk_desc *dev_desc, int part,
> disk_partition_t *info)
>  {
>  struct partition_block *p = find_partition(dev_desc, part-1);
> @@ -382,7 +382,7 @@ static void print_part_amiga(struct blk_desc *dev_desc)
>  U_BOOT_PART_TYPE(amiga) = {
> .name   = "AMIGA",
> .part_type  = PART_TYPE_AMIGA,
> -   .get_info   = get_partition_info_amiga,
> +   .get_info   = part_get_info_amiga,
> .print  = print_part_amiga,
> .test   = test_part_amiga,

Can we rename these two to: part_print_amiga and part_test_amiga too?

>  };
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 7567ed3..4a56391 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -167,11 +167,10 @@ static void print_partition_extended(struct blk_desc 
> *dev_desc,
>
>  /*  Print a partition that is relative to its Extended partition table
>   */
> -static int get_partition_info_extended(struct blk_desc *dev_desc,
> -  lbaint_t ext_part_sector,
> -  lbaint_t relative, int part_num,
> -  int which_part, disk_partition_t *info,
> -  unsigned int disksig)
> +static int part_get_info_extended(struct blk_desc *dev_desc,
> + lbaint_t ext_part_sector, lbaint_t relative,
> + int part_num, int which_part,
> + disk_partition_t *info, unsigned int 
> disksig)
>  {
> ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
> dos_partition_t *pt;
> @@ -259,7 +258,7 @@ static int get_partition_info_extended(struct blk_desc 
> *dev_desc,
> lbaint_t lba_start
> = le32_to_int (pt->start4) + relative;
>
> -   return get_partition_info_extended (dev_desc, 
> lba_start,
> +   return part_get_info_extended(dev_desc, lba_start,
>  ext_part_sector == 0 ? lba_start : relative,
>  part_num, which_part, info, disksig);
> }
> @@ -289,16 +288,16 @@ void print_part_dos(struct blk_desc *dev_desc)
> print_partition_extended(dev_desc, 0, 0, 1, 0);
>  }
>
> -int get_partition_info_dos(struct blk_desc *dev_desc, int part,
> -  disk_partition_t *info)
> +int part_get_info_dos(struct blk_desc *dev_desc, int part,
> + disk_partition_t *info)
>  {
> -   return get_partition_info_extended(dev_desc, 0, 0, 1, part, info, 0);
> +   return part_get_info_extended(dev_desc, 0, 0, 1, part, info, 0);
>  }
>
>  U_BOOT_PART_TYPE(dos) = {
> .name   = "DOS",
> .part_type  = PART_TYPE_DOS,
> -   .get_info   = part_get_info_ptr(get_partition_info_dos),
> +   .get_info   = part_get_info_ptr(part_get_info_dos),
> .print  = part_print_ptr(print_part_dos),
> .test   = test_part_dos,

ditto.

>  };
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index 6f80877..eed8593 100644
> --- a/disk/part_efi.c
> +++ 

Re: [U-Boot] [PATCH 13/30] dm: sandbox: Enable all partition types

[Bin Meng]

Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> It is useful to have sandbox build as much code as possible to avoid having
> to build every board to detect build errors. Also we may add tests for some
> more partition types at some point.
>
> Enable all partition types in sandbox.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/configs/sandbox.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

One nits below:

> diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
> index 4bffd8d..0f02839 100644
> --- a/include/configs/sandbox.h
> +++ b/include/configs/sandbox.h
> @@ -53,8 +53,11 @@
>
>  #define CONFIG_CMD_GPT
>  #define CONFIG_PARTITION_UUIDS
> -#define CONFIG_EFI_PARTITION
> +#define CONFIG_MAC_PARTITION
>  #define CONFIG_DOS_PARTITION
> +#define CONFIG_ISO_PARTITION
> +#define CONFIG_AMIGA_PARTITION
> +#define CONFIG_EFI_PARTITION
>

Guess we can use proper alphabetical order for these partitions? Like
AMIGA, DOS, EFI, ISO, MAC ..

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

Re: [U-Boot] [PATCH 12/30] dm: part: Add a cast to avoid a compiler warning

[Bin Meng]

Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> In part_amiga.c the name is unsigned by bcpl_strcpy() requires a signed
> pointer. Add a cast to fix the warning.

is unsigned *but* bcpl_strcpy() ?

>
> Signed-off-by: Simon Glass 
> ---
>
>  disk/part_amiga.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

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

[U-Boot] [PATCH] Gracefully handle 64-bit signed-extended 32-bit Load addresses

[William Cohen]

To follow the MIPS 32-bit and 64-bit memory map conventions (*) recent
MIPS Linux kernels are using a 64-bit sign extended value
(0x8001) for the 32-bit load address (0x8001) of the
Creator CI20 board kernel.  When this 64-bit argument was passed to
mkimage running on a 32-bit machine such as the Creator CI20 board the
load address was incorrectly formed from the upper 32-bit sign-extend
bits (0x) by the strtoul instead of from the lower 32-bits
(0x8001).  The mkimage should be able to tolerate the longer
sign-extended 64-bit version of the 32-bit arguments with the use of
strtoull.  Use of the strtoll in place of the strtol in mkimage.c
resolves the issue of self hosted kernel builds for the Creator CI20
board (+) and (++).

(*) 
http://techpubs.sgi.com/library/dynaweb_docs/0620/SGI_Developer/books/DevDriver_PG/sgi_html/ch01.html
(+) https://github.com/MIPS/CI20_linux/issues/23
(++) https://github.com/MIPS/CI20_linux/issues/22

Signed-off-by: William Cohen 
---
 tools/mkimage.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 8f8b6df..facebcd 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -129,7 +129,7 @@ int main(int argc, char **argv)
case 'a':
if (--argc <= 0)
usage ();
-   params.addr = strtoul (*++argv, , 16);
+   params.addr = strtoull(*++argv, , 16);
if (*ptr) {
fprintf (stderr,
"%s: invalid load address %s\n",
@@ -146,7 +146,7 @@ int main(int argc, char **argv)
case 'e':
if (--argc <= 0)
usage ();
-   params.ep = strtoul (*++argv, , 16);
+   params.ep = strtoull(*++argv, , 16);
if (*ptr) {
fprintf (stderr,
"%s: invalid entry point %s\n",
-- 
2.5.0

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

Re: [U-Boot] [PATCH] Gracefully handle 64-bit Load Address and Entry Point Address mkimage parameters

[William Cohen]

On 02/15/2016 06:34 AM, Wolfgang Denk wrote:
> Dear William,
> 
> In message <1455506732-22307-1-git-send-email-wco...@redhat.com> you wrote:
>>
>> Recent MIPS Linux kernels are using a 64-bit value for the load
>> address (0x8001) for the Creator CI20 board kernel.  When
>> this argument was passed to the mkimage program running on a 32-bit
>> machine such as the Creator CI20 board the load address was
>> incorrectly obtained from the first half of the argument, 0x
>> by the strtoul.  The mkimage should be able to tolerate the longer,
>> 64-bit signed version of the arguments with the use of strtoull.
> 
> Hm...  I think we have multiple problems here.

Hi,

The write up in the patch wasn't as clear as it should have been. I
have revised the patch to try to make the reason for this patch
clearer.  The MIP Linux kernel is using sign-extending 32-bit values
to 64-bit values, so the truncation of the strtoll values to 32-bits
is actually desired. The revised patch now passes the linux kernel
checkpatch.pl checks.  I will be resending the patch in a moment.

-Will
> 
> First, the old legacy uImage header usersd 32 bit data types for the
> addresses.  This is a binary data structure, and there is no way to
> extend it for 64 bit addresses without breaking compatibility.
> 
> 
>> -params.addr = strtoul (*++argv, , 16);
>> +params.addr = strtoull (*++argv, , 16);
> 
> I don't see what you win here...  strtoull() returns unsigned long long,
> but params.addr is an unsigned int, so the value will be truncated to
> 32 bit.  Are you sure this is what you want?
> 
>>  fprintf (stderr,
>>  "%s: invalid load address %s\n",
>> @@ -146,7 +146,7 @@ int main(int argc, char **argv)
>>  case 'e':
>>  if (--argc <= 0)
>>  usage ();
>> -params.ep = strtoul (*++argv, , 16);
>> +params.ep = strtoull (*++argv, , 16);
> 
> Ditto...
> 
> 
> Also please note that your patch triggers a number of checkpatch
> warnings and an error, especially:
> 
> WARNING: space prohibited between function name and open parenthesis '('
> #108: FILE: tools/mkimage.c:132:
> +   params.addr = strtoull (*++argv, , 16);
> 
> WARNING: space prohibited between function name and open parenthesis '('
> #117: FILE: tools/mkimage.c:149:
> +   params.ep = strtoull (*++argv, , 16);
> 
> ERROR: Missing Signed-off-by: line(s)
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 

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

Re: [U-Boot] [PATCH 10/30] dm: blk: Rename get_device() to blk_get_device_str()

[Bin Meng]

Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> The current name is too generic. The function returns a block device based
> on a provided string. Rename it to aid searching and make its purpose
> clearer. Also add a few comments.
>
> Signed-off-by: Simon Glass 
> ---
>
>  cmd/part.c |  6 +++---
>  cmd/unzip.c|  2 +-
>  cmd/usb_mass_storage.c |  2 +-
>  disk/part.c|  6 +++---
>  include/part.h | 34 ++
>  test/dm/usb.c  |  2 +-
>  6 files changed, 39 insertions(+), 13 deletions(-)
>

Reviewed-by: Bin Meng 

One comment below

> diff --git a/cmd/part.c b/cmd/part.c
> index a572aab..f05699d 100644
> --- a/cmd/part.c
> +++ b/cmd/part.c
> @@ -81,7 +81,7 @@ static int do_part_list(int argc, char * const argv[])
> return CMD_RET_USAGE;
> }
>
> -   ret = get_device(argv[0], argv[1], );
> +   ret = blk_get_device_str(argv[0], argv[1], );
> if (ret < 0)
> return 1;
>
> @@ -128,7 +128,7 @@ static int do_part_start(int argc, char * const argv[])
>
> part = simple_strtoul(argv[2], NULL, 0);
>
> -   ret = get_device(argv[0], argv[1], );
> +   ret = blk_get_device_str(argv[0], argv[1], );
> if (ret < 0)
> return 1;
>
> @@ -162,7 +162,7 @@ static int do_part_size(int argc, char * const argv[])
>
> part = simple_strtoul(argv[2], NULL, 0);
>
> -   ret = get_device(argv[0], argv[1], );
> +   ret = blk_get_device_str(argv[0], argv[1], );
> if (ret < 0)
> return 1;
>
> diff --git a/cmd/unzip.c b/cmd/unzip.c
> index 5be1566..588fa75 100644
> --- a/cmd/unzip.c
> +++ b/cmd/unzip.c
> @@ -53,7 +53,7 @@ static int do_gzwrite(cmd_tbl_t *cmdtp, int flag,
>
> if (argc < 5)
> return CMD_RET_USAGE;
> -   ret = get_device(argv[1], argv[2], );
> +   ret = blk_get_device_str(argv[1], argv[2], );
> if (ret < 0)
> return CMD_RET_FAILURE;
>
> diff --git a/cmd/usb_mass_storage.c b/cmd/usb_mass_storage.c
> index 03b7e21..fcac389 100644
> --- a/cmd/usb_mass_storage.c
> +++ b/cmd/usb_mass_storage.c
> @@ -69,7 +69,7 @@ static int ums_init(const char *devtype, const char 
> *devnums)
> if (!devnum)
> break;
>
> -   ret = get_device(devtype, devnum, _dev);
> +   ret = blk_get_device_str(devtype, devnum, _dev);
> if (ret < 0)
> goto cleanup;
>
> diff --git a/disk/part.c b/disk/part.c
> index 2466c3e..700e505 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -449,8 +449,8 @@ int get_partition_info(struct blk_desc *dev_desc, int 
> part,
> return -1;
>  }
>
> -int get_device(const char *ifname, const char *dev_hwpart_str,
> -  struct blk_desc **dev_desc)
> +int blk_get_device_str(const char *ifname, const char *dev_hwpart_str,
> +  struct blk_desc **dev_desc)
>  {
> char *ep;
> char *dup_str = NULL;
> @@ -598,7 +598,7 @@ int get_device_and_partition(const char *ifname, const 
> char *dev_part_str,
> }
>
> /* Look up the device */
> -   dev = get_device(ifname, dev_str, dev_desc);
> +   dev = blk_get_device_str(ifname, dev_str, dev_desc);
> if (dev < 0)
> goto cleanup;
>
> diff --git a/include/part.h b/include/part.h
> index ddc4422..d05b48b 100644
> --- a/include/part.h
> +++ b/include/part.h
> @@ -101,8 +101,34 @@ int get_partition_info(struct blk_desc *dev_desc, int 
> part,
>  void print_part(struct blk_desc *dev_desc);
>  void init_part(struct blk_desc *dev_desc);
>  void dev_print(struct blk_desc *dev_desc);
> -int get_device(const char *ifname, const char *dev_str,
> -  struct blk_desc **dev_desc);
> +
> +/**
> + * blk_get_device_str() - Get a block device given its interface/ hw 
> partition

nits: need one space before /, or remove space before 'hw'?

I am not sure if blk_get_device_str() is a good name, but I cannot
think of a better name..

> + *
> + * Each interface allocates its own devices and typically struct blk_desc is
> + * contained with the interface's data structure. There is no global
> + * numbering for block devices, so the interface name must be provided.
> + *
> + * The hardware parition is not related to the normal software partitioning
> + * of a device - each hardware partition is effectively a separately
> + * accessible block device. When a hardware parition is selected on MMC the
> + * other hardware partitions become inaccessible. The same block device is
> + * used to access all hardware partitions, but its capacity may change when a
> + * different hardware partition is selected.
> + *
> + * When a hardware partition number is given, the block device switches to
> + * that hardware partition.
> + *
> + * @ifname:Interface name (e.g. "ide", 

Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot

[Tom Rini]

On Tue, Feb 16, 2016 at 09:30:44PM +0900, Masahiro Yamada wrote:
> 2016-02-16 21:17 GMT+09:00 Tom Rini :
> > On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote:
> >> Hi Simon,
> >>
> >>
> >> 2016-01-29 1:39 GMT+09:00 Simon Glass :
> >> > We need a way to support more than one board per binary in U-Boot with
> >> > device tree. Various methods have been discussed. The one that seems to 
> >> > make
> >> > the most sense is to adjust SPL so that it can load a FIT which contains
> >> > U-Boot and several device tree binaries. This is how things with with 
> >> > Linux:
> >> > load a FIT and select the correct device tree to pass to Linux.
> >>
> >> I've just skimmed over the git-logs, but I am confused.
> >>
> >>
> >> Please makes it clearer why this is useful.
> >> In your way, how SPL is handled?
> >>
> >> SPL is much more board-specific than U-Boot proper.
> >> So, I assume SPL would remain as a per-board image
> >> even after achieving one U-Boot proper for multi-boards.
> >>
> >> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot 
> >> proper.
> >>
> >> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be
> >> generated by one-shot
> >> and by one defconfig.
> >>
> >>
> >> But, we would still have to do
> >>
> >> make board_a_defconfig && make
> >> make board_b_defconfig && make
> >> make board_c_defconfig && make
> >>
> >> to generate SPL for each of the three.
> >> Is this correct?
> >>
> >>
> >> Supposing my guess is correct, this series would not contribute
> >> to decreasing the number of defconfig files.
> >>
> >>
> >>
> >> Please explain which problem you are solving with this series.
> >
> > It won't be just one board.  We need this so that we can replicate
> > existing (and very useful) functionality.  Today, am335x_evm_config
> > supports Beaglebone White, Beaglebone Black (could be faked enough for
> > U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART
> > AM335x IDK EVM.  Each of these is different enough that they have their
> > own DT that we will need to pass up to U-Boot, and their own config
> > file.  With Simon's series we'll be able to move am335x_evm_config up to
> > DM in SPL and possibly even remove some of the am335x_evm subconfigs we
> > have today, once those specific options also move to Kconfig.
> 
> So, this series is useful to merge some boards
> that are different enough to have their own DT,
> but that are similar enough to share one SPL binary, correct?

Yes.  It _may_ even be useful later on to support a more broad set of
boards than we do today (ie it's not impossible that one binary could
support the TI AM43xx EVMs as well, or all TI EVMs that have the EEPROM
that identifies the model, for some narrow scope of boot devices).

-- 
Tom


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

[U-Boot] [PATCH] ARM: zynq: Enable u-boot,dm-pre-reloc for qspi

[Nathan Rossi]

Enable u-boot,dm-pre-reloc for qspi for zc706, zed and microzed.

Signed-off-by: Nathan Rossi 
Cc: Albert Aribaud 
Cc: Michal Simek 
Cc: Simon Glass 
---
 arch/arm/dts/zynq-microzed.dts | 1 +
 arch/arm/dts/zynq-zc706.dts| 1 +
 arch/arm/dts/zynq-zed.dts  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
index e841a1d..793ab44 100644
--- a/arch/arm/dts/zynq-microzed.dts
+++ b/arch/arm/dts/zynq-microzed.dts
@@ -24,6 +24,7 @@
 };
 
  {
+   u-boot,dm-pre-reloc;
status = "okay";
 };
 
diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index 1ba3a1c..1610520 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -306,6 +306,7 @@
 };
 
  {
+   u-boot,dm-pre-reloc;
status = "okay";
 };
 
diff --git a/arch/arm/dts/zynq-zed.dts b/arch/arm/dts/zynq-zed.dts
index 5ec59e2..ec9b2f7 100644
--- a/arch/arm/dts/zynq-zed.dts
+++ b/arch/arm/dts/zynq-zed.dts
@@ -61,6 +61,7 @@
 };
 
  {
+   u-boot,dm-pre-reloc;
status = "okay";
 };
 
-- 
2.7.0

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

Re: [U-Boot] i.MX286 U-Boot fails with code HTLLCL0x8050100b

[Stuart Longland]

On 15/02/16 14:09, Stuart Longland wrote:
> I ask again: Is there somewhere else I should be looking for the cause
> of the above issue?

Well, found my issue in the end I think.  In exasperation I dd'ed one of
my working SD card images, proved that the machine booted, then dd'ed
the newly build U-Boot image over the top of the old U-Boot partition.

It worked.

So I'll put this down to the i.MX286 boot ROM being *exceptionally*
picky about partition placement.  If things aren't *exactly* right,
it'll flatly refuse to work.

I might see if I can reproduce the bad image and hex-dump it to better
understand what was "wrong".
-- 
Stuart Longland
Systems Engineer
 _ ___
\  /|_) |   T: +61 7 3535 9619
 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699
   SYSTEMSMilton QLD 4064   http://www.vrt.com.au


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

Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot

[Masahiro Yamada]

2016-02-16 21:17 GMT+09:00 Tom Rini :
> On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote:
>> Hi Simon,
>>
>>
>> 2016-01-29 1:39 GMT+09:00 Simon Glass :
>> > We need a way to support more than one board per binary in U-Boot with
>> > device tree. Various methods have been discussed. The one that seems to 
>> > make
>> > the most sense is to adjust SPL so that it can load a FIT which contains
>> > U-Boot and several device tree binaries. This is how things with with 
>> > Linux:
>> > load a FIT and select the correct device tree to pass to Linux.
>>
>> I've just skimmed over the git-logs, but I am confused.
>>
>>
>> Please makes it clearer why this is useful.
>> In your way, how SPL is handled?
>>
>> SPL is much more board-specific than U-Boot proper.
>> So, I assume SPL would remain as a per-board image
>> even after achieving one U-Boot proper for multi-boards.
>>
>> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot 
>> proper.
>>
>> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be
>> generated by one-shot
>> and by one defconfig.
>>
>>
>> But, we would still have to do
>>
>> make board_a_defconfig && make
>> make board_b_defconfig && make
>> make board_c_defconfig && make
>>
>> to generate SPL for each of the three.
>> Is this correct?
>>
>>
>> Supposing my guess is correct, this series would not contribute
>> to decreasing the number of defconfig files.
>>
>>
>>
>> Please explain which problem you are solving with this series.
>
> It won't be just one board.  We need this so that we can replicate
> existing (and very useful) functionality.  Today, am335x_evm_config
> supports Beaglebone White, Beaglebone Black (could be faked enough for
> U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART
> AM335x IDK EVM.  Each of these is different enough that they have their
> own DT that we will need to pass up to U-Boot, and their own config
> file.  With Simon's series we'll be able to move am335x_evm_config up to
> DM in SPL and possibly even remove some of the am335x_evm subconfigs we
> have today, once those specific options also move to Kconfig.

So, this series is useful to merge some boards
that are different enough to have their own DT,
but that are similar enough to share one SPL binary, correct?



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

Re: [U-Boot] [PATCH 2/3] common: env_flags: include common.h even for HOST_CC

[Tom Rini]

On Tue, Feb 16, 2016 at 11:19:43AM +, Peter Robinson wrote:
> >> When compiling with gcc 6 we get the following error due to ARRAY_SIZE 
> >> being
> >> defined elsewhere.
> >>
> >> common/env_flags.c:155: undefined reference to `ARRAY_SIZE'
> >>
> >> Signed-off-by: Peter Robinson 
> >
> > I'm going to take http://patchwork.ozlabs.org/patch/582527/ to fix this
> > instead as I don't want to say that common.h must work in the case of
> > USE_HOSTCC==true (I'm surprised it did, in fact).  Thanks!
> 
> What ever was pulled into RC2 works for me but I still needed my gcc6 patch.

Somewhere along the lines, Linux stopped having compiler-gccN.h and just
has compiler-gcc.h and compiler-clang.h.  Would you feel up to making a
pass at migrating those changes or should I?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot

[Tom Rini]

On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote:
> Hi Simon,
> 
> 
> 2016-01-29 1:39 GMT+09:00 Simon Glass :
> > We need a way to support more than one board per binary in U-Boot with
> > device tree. Various methods have been discussed. The one that seems to make
> > the most sense is to adjust SPL so that it can load a FIT which contains
> > U-Boot and several device tree binaries. This is how things with with Linux:
> > load a FIT and select the correct device tree to pass to Linux.
> 
> I've just skimmed over the git-logs, but I am confused.
> 
> 
> Please makes it clearer why this is useful.
> In your way, how SPL is handled?
> 
> SPL is much more board-specific than U-Boot proper.
> So, I assume SPL would remain as a per-board image
> even after achieving one U-Boot proper for multi-boards.
> 
> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot proper.
> 
> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be
> generated by one-shot
> and by one defconfig.
> 
> 
> But, we would still have to do
> 
> make board_a_defconfig && make
> make board_b_defconfig && make
> make board_c_defconfig && make
> 
> to generate SPL for each of the three.
> Is this correct?
> 
> 
> Supposing my guess is correct, this series would not contribute
> to decreasing the number of defconfig files.
> 
> 
> 
> Please explain which problem you are solving with this series.

It won't be just one board.  We need this so that we can replicate
existing (and very useful) functionality.  Today, am335x_evm_config
supports Beaglebone White, Beaglebone Black (could be faked enough for
U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART
AM335x IDK EVM.  Each of these is different enough that they have their
own DT that we will need to pass up to U-Boot, and their own config
file.  With Simon's series we'll be able to move am335x_evm_config up to
DM in SPL and possibly even remove some of the am335x_evm subconfigs we
have today, once those specific options also move to Kconfig.

-- 
Tom


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

[U-Boot] test/py main_signon

[Michal Simek]

Hi Stephen,

trying to run the latest testing on zynq board and getting this
main_signon error.

This is what I am running
./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
and getting below.

Thanks,
Michal

U-Boot 2016.03-rc2 (Feb 16 2016 - 13:10:03 +0100)

Model: Zynq ZC702 Development Board
Board: Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 1 GiB

Bad pattern found on console: main_signon

FAILED:
request = >

@pytest.fixture(scope='function')
def u_boot_console(request):
"""Generate the value of a test's u_boot_console fixture.

Args:
request: The pytest request.

Returns:
The fixture value.
"""

>   console.ensure_spawned()

test/py/conftest.py:311:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 

def ensure_spawned(self):
"""Ensure a connection to a correctly running U-Boot instance.

This may require spawning a new Sandbox process or resetting
target
hardware, as defined by the implementation sub-class.

This is an internal function and should not be called directly.

Args:
None.

Returns:
Nothing.
"""

if self.p:
return
try:
self.log.start_section('Starting U-Boot')
self.at_prompt = False
self.p = self.get_spawn()
# Real targets can take a long time to scroll large amounts of
# text if LCD is enabled. This value may need tweaking in the
# future, possibly per-test to be optimal. This works for 'help'
# on board 'seaboard'.
if not self.config.gdbserver:
self.p.timeout = 3
self.p.logfile_read = self.logstream
if self.config.buildconfig.get('config_spl', False) == 'y':
m = self.p.expect([pattern_u_boot_spl_signon] +
self.bad_patterns)
if m != 0:
raise Exception('Bad pattern found on console: ' +
>   self.bad_pattern_ids[m - 1])
E   Exception: Bad pattern found on
console: main_signon

test/py/u_boot_console_base.py:310: Exception

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

Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot

[Masahiro Yamada]

Hi Simon,


2016-01-29 1:39 GMT+09:00 Simon Glass :
> We need a way to support more than one board per binary in U-Boot with
> device tree. Various methods have been discussed. The one that seems to make
> the most sense is to adjust SPL so that it can load a FIT which contains
> U-Boot and several device tree binaries. This is how things with with Linux:
> load a FIT and select the correct device tree to pass to Linux.

I've just skimmed over the git-logs, but I am confused.


Please makes it clearer why this is useful.
In your way, how SPL is handled?

SPL is much more board-specific than U-Boot proper.
So, I assume SPL would remain as a per-board image
even after achieving one U-Boot proper for multi-boards.

Let's say we want to support Board-A, Board-B, Board-C with one U-Boot proper.

The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be
generated by one-shot
and by one defconfig.


But, we would still have to do

make board_a_defconfig && make
make board_b_defconfig && make
make board_c_defconfig && make

to generate SPL for each of the three.
Is this correct?


Supposing my guess is correct, this series would not contribute
to decreasing the number of defconfig files.



Please explain which problem you are solving with this series.


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

Re: [U-Boot] [PATCH 2/3] common: env_flags: include common.h even for HOST_CC

[Peter Robinson]

>> When compiling with gcc 6 we get the following error due to ARRAY_SIZE being
>> defined elsewhere.
>>
>> common/env_flags.c:155: undefined reference to `ARRAY_SIZE'
>>
>> Signed-off-by: Peter Robinson 
>
> I'm going to take http://patchwork.ozlabs.org/patch/582527/ to fix this
> instead as I don't want to say that common.h must work in the case of
> USE_HOSTCC==true (I'm surprised it did, in fact).  Thanks!

What ever was pulled into RC2 works for me but I still needed my gcc6 patch.

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

Re: [U-Boot] [PATCH 08/30] dm: blk: Add comments to a few functions

[Bin Meng]

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> The block interface is not well documented in the code. Pick two important
> functions and add comments.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/part.h | 30 ++
>  1 file changed, 30 insertions(+)
>

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