Re: [U-Boot] [PATCH 2/6] sf: Optimize flash features code

[Jagan Teki]

Hi Marek,

Please ignore the last sent!

On Tue, Jan 21, 2014 at 1:09 PM, Jagan Teki  wrote:
> Hi Marek,
>
> On Tue, Jan 21, 2014 at 4:31 AM, Marek Vasut  wrote:
>> On Monday, January 20, 2014 at 02:32:27 PM, Jagan Teki wrote:
>>> On Mon, Jan 20, 2014 at 6:49 PM, Marek Vasut  wrote:
>>> > On Saturday, January 18, 2014 at 09:51:56 PM, Jagan Teki wrote:
>>> >> On Sun, Jan 19, 2014 at 2:09 AM, Marek Vasut  wrote:
>>> >> > On Saturday, January 18, 2014 at 09:06:29 PM, Jagannadha Sutradharudu
>>> >> > Teki
>>> >> >
>>> >> > wrote:
>>> >> >> - Shrink spi_slave {}
>>> >> >> - Shrink spi_flash_params {}
>>> >> >> - Documentation for sf features
>>> >> >>
>>> >> >> Signed-off-by: Jagannadha Sutradharudu Teki 
>>> >> >> Cc: Marek Vasut 
>>> >> >> ---
>>> >> >>
>>> >> >>  doc/SPI/README.sf-features| 122 ++
>>> >> >>  drivers/mtd/spi/sf.c  |   4 +-
>>> >> >>  drivers/mtd/spi/sf_internal.h |   1 -
>>> >> >>  drivers/mtd/spi/sf_ops.c  |   8 +-
>>> >> >>  drivers/mtd/spi/sf_params.c   | 172
>>> >> >>
>>> >> >> +- drivers/mtd/spi/sf_probe.c
>>> >> >>
>>> >> >>  71 -
>>> >> >>  include/spi.h |  42 ---
>>> >> >>  include/spi_flash.h   |  24 +++---
>>> >> >>  8 files changed, 270 insertions(+), 174 deletions(-)
>>> >> >>  create mode 100644 doc/SPI/README.sf-features
>>> >> >>
>>> >> >> diff --git a/doc/SPI/README.sf-features b/doc/SPI/README.sf-features
>>> >> >> new file mode 100644
>>> >> >> index 000..d35f56d
>>> >> >> --- /dev/null
>>> >> >> +++ b/doc/SPI/README.sf-features
>>> >> >> @@ -0,0 +1,122 @@
>>> >> >> +SPI FLASH feature enhancements:
>>> >> >> +==
>>> >> >> +
>>> >> >> +This document describes how to extend the current data structures in
>>> >> >> spi subsystem +for making use of new flash features/operations w.r.t
>>> >> >> to controller driver support. +
>>> >> >> +1. spi_slave:
>>> >> >> +
>>> >> >> +struct spi_slave {
>>> >> >> +..
>>> >> >> +u32 mode_bits;
>>> >> >> +
>>> >> >> +};
>>> >> >> +
>>> >> >> +@mode_bits can be used to expose the SPI RX/TX operation modes, bus
>>> >> >> options and +few flags which are used to extended the flash specific
>>> >> >> features/operations +- include/spi.h
>>> >> >> +
>>> >> >> +mode_bits:
>>> >> >> +- SPI_TX_QPP: 4-Wire tx transfer operation quad page program
>>> >> >> +- SPI_RX_SLOW: 1-wire rx transfer operation array slow read
>>> >> >> +- SPI_RX_DUAL: 2-wire rx transfer operation dual fast read
>>> >> >> +- SPI_RX_DUAL_IO: 2-wire rx transfer operation dual io fast read
>>> >> >> +- SPI_RX_QUAD: 4-wire rx transfer operation quad fast read
>>> >> >> +- SPI_RX_QUAD_IO: 4-wire rx transfer operation quad io fast read
>>> >> >> +- SPI_SHARED: dual flash devices are connected in shared bus
>>> >> >> connection +- SPI_SEPARATED: dual flash devices are connected in
>>> >> >> separate bus connection +- SPI_U_PAGE: select the upper flash in
>>> >> >> dual flash shared bus connection [1] +
>>> >> >
>>> >> > A generic SPI controller _does_ _not_ _care_ about any SPI flash crud.
>>> >> > The SPI bus controller (which is what this is for) and SPI-NOR
>>> >> > controller are two different things and must have two different slave
>>> >> > structures.
>>> >>
>>> >> You mean mode_bits need to move in one more structure.
>>> >> Just leave about new SPI-NOR as of now for this release we discuss more
>>> >> soon.
>>> >
>>> > The mode_bits have no place in this structure. The slave can indicate
>>> > whether it can be connected over 1,2,4... lines , but must not indicate
>>> > that it supports some SPI-flash specific properties.
>>>
>>> What do you mean by this - can you elaborate.
>>
>> I mean there do exist SPI controllers which can output data via more than one
>> (MOSI) line . They do support 1, 2 or even 4 lines. This comes useful when
>> driving SPI flashes indeed, _BUT_ (!) this is not tied to driving SPI 
>> flashes.
>> On the contrary, you can connect any device which can be driven over such
>> "parallelised" SPI and it will work. And only such property shall also land 
>> in
>> the struct spi_slave {} .
>>
>> Properties like "let's assume the SPI slave is a SPI NOR and it supports SPI 
>> NOR
>> command FOO" do not go into struct spi_slave.
>>
>>> As of now drivers in drivers/spi need to inform the flash through spi_slave
>>> {} no other alternative ie way remaining flash properties memory_map etc..
>>> handle. Even Linux follow the same w/o new SPI-NOR framework.
>>
>> Linux is now going for a separate SPI-NOR controller framework and this is 
>> what
>> we will do as well. The SF layer will be only a unifying layer providing 
>> access
>> to either SPI-NOR API (for the SPI-NOR controllers) or a translation layer to
>> communicate SPI-NOR commands over generic SPI API (for the old-school regular
>> way of doing SPI NOR connection to SPI bus).

Just take an example of ti qspi controller 

Re: [U-Boot] [PATCH 2/6] sf: Optimize flash features code

[Jagan Teki]

Hi Marek,

On Tue, Jan 21, 2014 at 4:31 AM, Marek Vasut  wrote:
> On Monday, January 20, 2014 at 02:32:27 PM, Jagan Teki wrote:
>> On Mon, Jan 20, 2014 at 6:49 PM, Marek Vasut  wrote:
>> > On Saturday, January 18, 2014 at 09:51:56 PM, Jagan Teki wrote:
>> >> On Sun, Jan 19, 2014 at 2:09 AM, Marek Vasut  wrote:
>> >> > On Saturday, January 18, 2014 at 09:06:29 PM, Jagannadha Sutradharudu
>> >> > Teki
>> >> >
>> >> > wrote:
>> >> >> - Shrink spi_slave {}
>> >> >> - Shrink spi_flash_params {}
>> >> >> - Documentation for sf features
>> >> >>
>> >> >> Signed-off-by: Jagannadha Sutradharudu Teki 
>> >> >> Cc: Marek Vasut 
>> >> >> ---
>> >> >>
>> >> >>  doc/SPI/README.sf-features| 122 ++
>> >> >>  drivers/mtd/spi/sf.c  |   4 +-
>> >> >>  drivers/mtd/spi/sf_internal.h |   1 -
>> >> >>  drivers/mtd/spi/sf_ops.c  |   8 +-
>> >> >>  drivers/mtd/spi/sf_params.c   | 172
>> >> >>
>> >> >> +- drivers/mtd/spi/sf_probe.c
>> >> >>
>> >> >>  71 -
>> >> >>  include/spi.h |  42 ---
>> >> >>  include/spi_flash.h   |  24 +++---
>> >> >>  8 files changed, 270 insertions(+), 174 deletions(-)
>> >> >>  create mode 100644 doc/SPI/README.sf-features
>> >> >>
>> >> >> diff --git a/doc/SPI/README.sf-features b/doc/SPI/README.sf-features
>> >> >> new file mode 100644
>> >> >> index 000..d35f56d
>> >> >> --- /dev/null
>> >> >> +++ b/doc/SPI/README.sf-features
>> >> >> @@ -0,0 +1,122 @@
>> >> >> +SPI FLASH feature enhancements:
>> >> >> +==
>> >> >> +
>> >> >> +This document describes how to extend the current data structures in
>> >> >> spi subsystem +for making use of new flash features/operations w.r.t
>> >> >> to controller driver support. +
>> >> >> +1. spi_slave:
>> >> >> +
>> >> >> +struct spi_slave {
>> >> >> +..
>> >> >> +u32 mode_bits;
>> >> >> +
>> >> >> +};
>> >> >> +
>> >> >> +@mode_bits can be used to expose the SPI RX/TX operation modes, bus
>> >> >> options and +few flags which are used to extended the flash specific
>> >> >> features/operations +- include/spi.h
>> >> >> +
>> >> >> +mode_bits:
>> >> >> +- SPI_TX_QPP: 4-Wire tx transfer operation quad page program
>> >> >> +- SPI_RX_SLOW: 1-wire rx transfer operation array slow read
>> >> >> +- SPI_RX_DUAL: 2-wire rx transfer operation dual fast read
>> >> >> +- SPI_RX_DUAL_IO: 2-wire rx transfer operation dual io fast read
>> >> >> +- SPI_RX_QUAD: 4-wire rx transfer operation quad fast read
>> >> >> +- SPI_RX_QUAD_IO: 4-wire rx transfer operation quad io fast read
>> >> >> +- SPI_SHARED: dual flash devices are connected in shared bus
>> >> >> connection +- SPI_SEPARATED: dual flash devices are connected in
>> >> >> separate bus connection +- SPI_U_PAGE: select the upper flash in
>> >> >> dual flash shared bus connection [1] +
>> >> >
>> >> > A generic SPI controller _does_ _not_ _care_ about any SPI flash crud.
>> >> > The SPI bus controller (which is what this is for) and SPI-NOR
>> >> > controller are two different things and must have two different slave
>> >> > structures.
>> >>
>> >> You mean mode_bits need to move in one more structure.
>> >> Just leave about new SPI-NOR as of now for this release we discuss more
>> >> soon.
>> >
>> > The mode_bits have no place in this structure. The slave can indicate
>> > whether it can be connected over 1,2,4... lines , but must not indicate
>> > that it supports some SPI-flash specific properties.
>>
>> What do you mean by this - can you elaborate.
>
> I mean there do exist SPI controllers which can output data via more than one
> (MOSI) line . They do support 1, 2 or even 4 lines. This comes useful when
> driving SPI flashes indeed, _BUT_ (!) this is not tied to driving SPI flashes.
> On the contrary, you can connect any device which can be driven over such
> "parallelised" SPI and it will work. And only such property shall also land in
> the struct spi_slave {} .
>
> Properties like "let's assume the SPI slave is a SPI NOR and it supports SPI 
> NOR
> command FOO" do not go into struct spi_slave.
>
>> As of now drivers in drivers/spi need to inform the flash through spi_slave
>> {} no other alternative ie way remaining flash properties memory_map etc..
>> handle. Even Linux follow the same w/o new SPI-NOR framework.
>
> Linux is now going for a separate SPI-NOR controller framework and this is 
> what
> we will do as well. The SF layer will be only a unifying layer providing 
> access
> to either SPI-NOR API (for the SPI-NOR controllers) or a translation layer to
> communicate SPI-NOR commands over generic SPI API (for the old-school regular
> way of doing SPI NOR connection to SPI bus).

Please correct me logic here!
Just take an example of ti qspi controller.

cmd_sf.c

spi_flash.h
--
sf (_probe, _ops), sf.c
---
drivers/spi/ti_qspi.c (inform flash info mode_bits through s

[U-Boot] [PATCH 2/2] powerpc/t2081qds: Add T2081 QDS board support

[Shengzhou Liu]

T2081 QDS is a high-performance computing evaluation, development and
test platform supporting the T2081 QorIQ Power Architecture processor.

T2081QDS board Overview
---
- T2081 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
- 2MB shared L2 and 512KB L3 CoreNet platform cache (CPC)
- CoreNet fabric supporting coherent and noncoherent transactions with
  prioritization and bandwidth allocation
- 32-/64-bit DDR3/DDR3LP SDRAM memory controller with ECC and interleaving
- Ethernet interfaces:
  - Two on-board 10M/100M/1G bps RGMII ports
  - Four 10Gbps XFI with an on-board quad SFP+ cage
  - 1Gbps/2.5Gbps SGMII Riser card
  - 10Gbps XAUI Riser card
- Accelerator:
  - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
- SerDes:
  - 16 lanes up to 10.3125GHz
  - Supports SATA, SGMII, sRIO, HiGig, XFI, XAUI and Aurora debug,
- IFC:
  - 512MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA
- eSPI:
  - Three SPI flash (16MB N25Q128A + 16MB EN25S64 + 512KB SST25WF040)
- USB:
  - Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB)
- PCIE:
  - Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0 with SR-IOV)
- eSDHC:
  - Supports various SD/SDHC/SDXC/eMMC devices with adapter cards and
voltage translators
- I2C:
  - Four I2C controllers.
- UART:
  - Dual 4-pins UART serial ports

Signed-off-by: Shengzhou Liu 
---
 board/freescale/{t2080qds => t208xqds}/Makefile|   6 +-
 board/freescale/{t2080qds => t208xqds}/ddr.c   |   0
 board/freescale/{t2080qds => t208xqds}/ddr.h   |   0
 .../eth_t2080qds.c => t208xqds/eth_t208xqds.c} | 106 ++---
 board/freescale/{t2080qds => t208xqds}/law.c   |   0
 board/freescale/{t2080qds => t208xqds}/pci.c   |   0
 .../freescale/{t2080qds => t208xqds}/t2080_pbi.cfg |   0
 .../freescale/{t2080qds => t208xqds}/t2080_rcw.cfg |   0
 .../{t2080qds/t2080qds.c => t208xqds/t208xqds.c}   |  56 ++-
 .../{t2080qds/t2080qds.h => t208xqds/t208xqds.h}   |   0
 .../t2080qds_qixis.h => t208xqds/t208xqds_qixis.h} |   8 +-
 board/freescale/{t2080qds => t208xqds}/tlb.c   |   0
 boards.cfg |  15 ++-
 include/configs/{T2080QDS.h => T208xQDS.h} |   6 +-
 14 files changed, 148 insertions(+), 49 deletions(-)
 rename board/freescale/{t2080qds => t208xqds}/Makefile (53%)
 rename board/freescale/{t2080qds => t208xqds}/ddr.c (100%)
 rename board/freescale/{t2080qds => t208xqds}/ddr.h (100%)
 rename board/freescale/{t2080qds/eth_t2080qds.c => t208xqds/eth_t208xqds.c} 
(81%)
 rename board/freescale/{t2080qds => t208xqds}/law.c (100%)
 rename board/freescale/{t2080qds => t208xqds}/pci.c (100%)
 rename board/freescale/{t2080qds => t208xqds}/t2080_pbi.cfg (100%)
 rename board/freescale/{t2080qds => t208xqds}/t2080_rcw.cfg (100%)
 rename board/freescale/{t2080qds/t2080qds.c => t208xqds/t208xqds.c} (85%)
 rename board/freescale/{t2080qds/t2080qds.h => t208xqds/t208xqds.h} (100%)
 rename board/freescale/{t2080qds/t2080qds_qixis.h => 
t208xqds/t208xqds_qixis.h} (90%)
 rename board/freescale/{t2080qds => t208xqds}/tlb.c (100%)
 rename include/configs/{T2080QDS.h => T208xQDS.h} (99%)

diff --git a/board/freescale/t2080qds/Makefile 
b/board/freescale/t208xqds/Makefile
similarity index 53%
rename from board/freescale/t2080qds/Makefile
rename to board/freescale/t208xqds/Makefile
index 0b8747b..947b7f7 100644
--- a/board/freescale/t2080qds/Makefile
+++ b/board/freescale/t208xqds/Makefile
@@ -4,8 +4,10 @@
 # SPDX-License-Identifier:  GPL-2.0+
 #
 
-obj-$(CONFIG_T2080QDS) += t2080qds.o
-obj-$(CONFIG_T2080QDS) += eth_t2080qds.o
+obj-$(CONFIG_T2080QDS) += t208xqds.o
+obj-$(CONFIG_T2080QDS) += eth_t208xqds.o
+obj-$(CONFIG_T2081QDS) += t208xqds.o
+obj-$(CONFIG_T2081QDS) += eth_t208xqds.o
 obj-$(CONFIG_PCI)  += pci.o
 obj-y   += ddr.o
 obj-y   += law.o
diff --git a/board/freescale/t2080qds/ddr.c b/board/freescale/t208xqds/ddr.c
similarity index 100%
rename from board/freescale/t2080qds/ddr.c
rename to board/freescale/t208xqds/ddr.c
diff --git a/board/freescale/t2080qds/ddr.h b/board/freescale/t208xqds/ddr.h
similarity index 100%
rename from board/freescale/t2080qds/ddr.h
rename to board/freescale/t208xqds/ddr.h
diff --git a/board/freescale/t2080qds/eth_t2080qds.c 
b/board/freescale/t208xqds/eth_t208xqds.c
similarity index 81%
rename from board/freescale/t2080qds/eth_t2080qds.c
rename to board/freescale/t208xqds/eth_t208xqds.c
index 3e4ab8f..011514d 100644
--- a/board/freescale/t2080qds/eth_t2080qds.c
+++ b/board/freescale/t208xqds/eth_t208xqds.c
@@ -25,21 +25,27 @@
 #include 
 #include "../common/qixis.h"
 #include "../common/fman.h"
-#include "t2080qds_qixis.h"
+#include "t208xqds_qixis.h"
 
 #define EMI_NONE   0x
 #define EMI1_RGMII10
-#define EMI1_RGMII2 1
+#define EMI1_RGMII21
 #define EMI1_SLOT1 2
+#if defined(CONFIG_T2080QDS)
 #define EMI1_SLOT2 6
 #define EMI1_SLOT3 3
 #define EMI1_SLOT4 4
 #defi

[U-Boot] [PATCH 2/2] powerpc/t2081qds: Add T2081 QDS board support

[Shengzhou Liu]

T2081 QDS is a high-performance computing evaluation, development and
test platform supporting the T2081 QorIQ Power Architecture processor.

T2081QDS board Overview
---
- T2081 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
- 2MB shared L2 and 512KB L3 CoreNet platform cache (CPC)
- CoreNet fabric supporting coherent and noncoherent transactions with
  prioritization and bandwidth allocation
- 32-/64-bit DDR3/DDR3LP SDRAM memory controller with ECC and interleaving
- Ethernet interfaces:
  - Two on-board 10M/100M/1G bps RGMII ports
  - Four 10Gbps XFI with an on-board quad SFP+ cage
  - 1Gbps/2.5Gbps SGMII Riser card
  - 10Gbps XAUI Riser card
- Accelerator:
  - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
- SerDes:
  - 16 lanes up to 10.3125GHz
  - Supports SATA, SGMII, sRIO, HiGig, XFI, XAUI and Aurora debug,
- IFC:
  - 512MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA
- eSPI:
  - Three SPI flash (16MB N25Q128A + 16MB EN25S64 + 512KB SST25WF040)
- USB:
  - Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB)
- PCIE:
  - Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0 with SR-IOV)
- eSDHC:
  - Supports various SD/SDHC/SDXC/eMMC devices with adapter cards and
voltage translators
- I2C:
  - Four I2C controllers.
- UART:
  - Dual 4-pins UART serial ports

Signed-off-by: Shengzhou Liu 
---
 board/freescale/{t2080qds => t208xqds}/Makefile|   6 +-
 board/freescale/{t2080qds => t208xqds}/ddr.c   |   0
 board/freescale/{t2080qds => t208xqds}/ddr.h   |   0
 .../eth_t2080qds.c => t208xqds/eth_t208xqds.c} | 122 ++---
 board/freescale/{t2080qds => t208xqds}/law.c   |   0
 board/freescale/{t2080qds => t208xqds}/pci.c   |   0
 .../freescale/{t2080qds => t208xqds}/t2080_pbi.cfg |   0
 .../freescale/{t2080qds => t208xqds}/t2080_rcw.cfg |   0
 .../{t2080qds/t2080qds.c => t208xqds/t208xqds.c}   |  56 +-
 .../{t2080qds/t2080qds.h => t208xqds/t208xqds.h}   |   0
 .../t2080qds_qixis.h => t208xqds/t208xqds_qixis.h} |   8 +-
 board/freescale/{t2080qds => t208xqds}/tlb.c   |   0
 boards.cfg |  15 ++-
 include/configs/{T2080QDS.h => T208xQDS.h} |   6 +-
 14 files changed, 156 insertions(+), 57 deletions(-)
 rename board/freescale/{t2080qds => t208xqds}/Makefile (53%)
 rename board/freescale/{t2080qds => t208xqds}/ddr.c (100%)
 rename board/freescale/{t2080qds => t208xqds}/ddr.h (100%)
 rename board/freescale/{t2080qds/eth_t2080qds.c => t208xqds/eth_t208xqds.c} 
(80%)
 rename board/freescale/{t2080qds => t208xqds}/law.c (100%)
 rename board/freescale/{t2080qds => t208xqds}/pci.c (100%)
 rename board/freescale/{t2080qds => t208xqds}/t2080_pbi.cfg (100%)
 rename board/freescale/{t2080qds => t208xqds}/t2080_rcw.cfg (100%)
 rename board/freescale/{t2080qds/t2080qds.c => t208xqds/t208xqds.c} (85%)
 rename board/freescale/{t2080qds/t2080qds.h => t208xqds/t208xqds.h} (100%)
 rename board/freescale/{t2080qds/t2080qds_qixis.h => 
t208xqds/t208xqds_qixis.h} (90%)
 rename board/freescale/{t2080qds => t208xqds}/tlb.c (100%)
 rename include/configs/{T2080QDS.h => T208xQDS.h} (99%)

diff --git a/board/freescale/t2080qds/Makefile 
b/board/freescale/t208xqds/Makefile
similarity index 53%
rename from board/freescale/t2080qds/Makefile
rename to board/freescale/t208xqds/Makefile
index 0b8747b..947b7f7 100644
--- a/board/freescale/t2080qds/Makefile
+++ b/board/freescale/t208xqds/Makefile
@@ -4,8 +4,10 @@
 # SPDX-License-Identifier:  GPL-2.0+
 #
 
-obj-$(CONFIG_T2080QDS) += t2080qds.o
-obj-$(CONFIG_T2080QDS) += eth_t2080qds.o
+obj-$(CONFIG_T2080QDS) += t208xqds.o
+obj-$(CONFIG_T2080QDS) += eth_t208xqds.o
+obj-$(CONFIG_T2081QDS) += t208xqds.o
+obj-$(CONFIG_T2081QDS) += eth_t208xqds.o
 obj-$(CONFIG_PCI)  += pci.o
 obj-y   += ddr.o
 obj-y   += law.o
diff --git a/board/freescale/t2080qds/ddr.c b/board/freescale/t208xqds/ddr.c
similarity index 100%
rename from board/freescale/t2080qds/ddr.c
rename to board/freescale/t208xqds/ddr.c
diff --git a/board/freescale/t2080qds/ddr.h b/board/freescale/t208xqds/ddr.h
similarity index 100%
rename from board/freescale/t2080qds/ddr.h
rename to board/freescale/t208xqds/ddr.h
diff --git a/board/freescale/t2080qds/eth_t2080qds.c 
b/board/freescale/t208xqds/eth_t208xqds.c
similarity index 80%
rename from board/freescale/t2080qds/eth_t2080qds.c
rename to board/freescale/t208xqds/eth_t208xqds.c
index 3e4ab8f..6d292a1 100644
--- a/board/freescale/t2080qds/eth_t2080qds.c
+++ b/board/freescale/t208xqds/eth_t208xqds.c
@@ -25,35 +25,53 @@
 #include 
 #include "../common/qixis.h"
 #include "../common/fman.h"
-#include "t2080qds_qixis.h"
+#include "t208xqds_qixis.h"
 
 #define EMI_NONE   0x
 #define EMI1_RGMII10
-#define EMI1_RGMII2 1
+#define EMI1_RGMII21
 #define EMI1_SLOT1 2
+#if defined(CONFIG_T2080QDS)
 #define EMI1_SLOT2 6
 #define EMI1_SLOT3 3
 #define EMI1_SLOT4 4
 #defin

[U-Boot] [PATCH 1/2] powerpc/t208x: some update to support t2081

[Shengzhou Liu]

- fix serdes definition for t2081.
- fix clock speed for t2081.
- update ids, as CONFIG_FSL_SATA_V2 is needed only for t2080,
  T2081 has no SATA.

Signed-off-by: Shengzhou Liu 
---
 arch/powerpc/cpu/mpc85xx/speed.c| 3 ++-
 arch/powerpc/cpu/mpc85xx/t2080_ids.c| 2 ++
 arch/powerpc/cpu/mpc85xx/t2080_serdes.c | 3 +--
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 35867df..adf09ef 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -151,7 +151,8 @@ void get_sys_info(sys_info_t *sys_info)
sys_info->freq_processor[cpu] =
 freq_c_pll[cplx_pll] / core_cplx_pll_div[c_pll_sel];
}
-#if defined(CONFIG_PPC_B4860) || defined(CONFIG_PPC_T2080)
+#if defined(CONFIG_PPC_B4860) || defined(CONFIG_PPC_T2080) || \
+   defined(CONFIG_PPC_T2081)
 #define FM1_CLK_SEL0xe000
 #define FM1_CLK_SHIFT  29
 #else
diff --git a/arch/powerpc/cpu/mpc85xx/t2080_ids.c 
b/arch/powerpc/cpu/mpc85xx/t2080_ids.c
index 068e1f2..0bfd447 100644
--- a/arch/powerpc/cpu/mpc85xx/t2080_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/t2080_ids.c
@@ -53,8 +53,10 @@ struct liodn_id_table liodn_tbl[] = {
SET_USB_LIODN(1, "fsl-usb2-mph", 553),
SET_USB_LIODN(2, "fsl-usb2-dr", 554),
 
+#ifdef CONFIG_FSL_SATA_V2
SET_SATA_LIODN(1, 555),
SET_SATA_LIODN(2, 556),
+#endif
 
SET_PCI_LIODN_BASE(CONFIG_SYS_FSL_PCIE_COMPAT, 1, 148),
SET_PCI_LIODN_BASE(CONFIG_SYS_FSL_PCIE_COMPAT, 2, 228),
diff --git a/arch/powerpc/cpu/mpc85xx/t2080_serdes.c 
b/arch/powerpc/cpu/mpc85xx/t2080_serdes.c
index f2fbdeb..07e27de 100644
--- a/arch/powerpc/cpu/mpc85xx/t2080_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/t2080_serdes.c
@@ -43,7 +43,6 @@ static const struct serdes_config serdes1_cfg_tbl[] = {
{0x6C, {XFI_FM1_MAC9, XFI_FM1_MAC10,
SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2,
PCIE4, PCIE4, PCIE4, PCIE4} },
-#if defined(CONFIG_PPC_T2080)
{0x1C, {SGMII_FM1_DTSEC9, SGMII_FM1_DTSEC10,
SGMII_FM1_DTSEC1, SGMII_FM1_DTSEC2,
SGMII_FM1_DTSEC3, SGMII_FM1_DTSEC4,
@@ -129,7 +128,7 @@ static const struct serdes_config serdes1_cfg_tbl[] = {
XFI_FM1_MAC1, XFI_FM1_MAC2,
PCIE4, PCIE4, PCIE4, PCIE4} },
 
-#elif defined(CONFIG_PPC_T2081)
+#if defined(CONFIG_PPC_T2081)
{0xAA, {PCIE3, PCIE3, PCIE3, PCIE3,
PCIE4, PCIE4, PCIE4, PCIE4} },
{0xCA, {PCIE3, SGMII_FM1_DTSEC10, SGMII_FM1_DTSEC1,
-- 
1.8.0


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

Re: [U-Boot] [PATCH][v2] driver/ifc:Change accessor function to take care of endianness

[Prabhakar Kushwaha]

On 1/21/2014 12:04 PM, Wolfgang Denk wrote:

Dear Scott,

In message <20140121054228.de994382...@gemini.denx.de> I wrote:

I fear that more IP blocks will follow that have similar requirements,
and if we implemnt similar wrappers for each of them separately, we
will have a mess of hard to maintain code.  For example, it will then
be impossible to share common parts of code because driver A uses
A_out32() and driver B uses B_out32().

We should rather try and find a generic solution where the same
functions can be used by mulltiple drivers which have the same needs.

On second thought, I also think we should avoid solutions where the
BE/LE test has to be done for each and every I/O accessor call again
and again.  We should rather do this just once, and for example set
function pointers as needed (hoping that this driver will only be
needed after relocation, so we have writable data segment).




Thanks Wolfgang for this suggestion.

As far I understand, you are suggesting to have global structure with 
function pointer to accessor function depending upon IP's endiannes..
but i afraid,  for IFC we do have scenario where these accessor function 
are used before relocation.


Regards,
Prabhakar



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

Re: [U-Boot] [PATCH][v2] driver/ifc:Change accessor function to take care of endianness

[York Sun]

Dear Wolfgang,

On Jan 20, 2014, at 10:34 PM, Wolfgang Denk wrote:

> Dear Scott,
> 
> In message <20140121054228.de994382...@gemini.denx.de> I wrote:
>> 
>> I fear that more IP blocks will follow that have similar requirements,
>> and if we implemnt similar wrappers for each of them separately, we
>> will have a mess of hard to maintain code.  For example, it will then
>> be impossible to share common parts of code because driver A uses
>> A_out32() and driver B uses B_out32().
>> 
>> We should rather try and find a generic solution where the same
>> functions can be used by mulltiple drivers which have the same needs.
> 
> On second thought, I also think we should avoid solutions where the
> BE/LE test has to be done for each and every I/O accessor call again
> and again.  We should rather do this just once, and for example set
> function pointers as needed (hoping that this driver will only be
> needed after relocation, so we have writable data segment).

I like the idea of setting it just once, but I don't see how to implement it. A 
pointer is probably not the solution, because we do need some drivers before 
relocation.

York

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

Re: [U-Boot] [PATCH][v2] driver/ifc:Change accessor function to take care of endianness

[Wolfgang Denk]

Dear Scott,

In message <20140121054228.de994382...@gemini.denx.de> I wrote:
> 
> I fear that more IP blocks will follow that have similar requirements,
> and if we implemnt similar wrappers for each of them separately, we
> will have a mess of hard to maintain code.  For example, it will then
> be impossible to share common parts of code because driver A uses
> A_out32() and driver B uses B_out32().
> 
> We should rather try and find a generic solution where the same
> functions can be used by mulltiple drivers which have the same needs.

On second thought, I also think we should avoid solutions where the
BE/LE test has to be done for each and every I/O accessor call again
and again.  We should rather do this just once, and for example set
function pointers as needed (hoping that this driver will only be
needed after relocation, so we have writable data segment).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Mike's Law: For a lumber company employing two men and a cut-off saw,
the marginal product of labor for any number  of  additional  workers
equals  zero  until the acquisition of another cut-off saw. Let's not
even consider a chainsaw.
- Mike Dennison [You could always  schedule the saw, though - ed.]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH][v2] driver/ifc:Change accessor function to take care of endianness

[Wolfgang Denk]

Dear Scott,

In message <1390258263.24905.337.ca...@snotra.buserror.net> you wrote:
>
> > As is, you are only adding dead code, as there is no place anywhere in
> > the mainline code that defines CONFIG_SYS_FSL_IFC_LE
> 
> Yes, consider it RFC until we have patches for a target that needs LE.

This shouldbe noted in the Subject: then!

> > I seriously dislike the idea of introducing special I/O accessors for
> > a single device driver.  If more drivers would follow that example, we
> > will soon have a serious mess.
> 
> As the changelog says, we have chips coming out on which these registers
> are little-endian, and thus we can't hardcode big-endian in the
> driver.  

I'm not discussing the need for a way to switch endianess, only the
current implementation.

> What sort of mess are you envisioning?  This isn't implementing
> accessors from scratch; it's just a wrapper.  It's local to IFC code.

I fear that more IP blocks will follow that have similar requirements,
and if we implemnt similar wrappers for each of them separately, we
will have a mess of hard to maintain code.  For example, it will then
be impossible to share common parts of code because driver A uses
A_out32() and driver B uses B_out32().

We should rather try and find a generic solution where the same
functions can be used by mulltiple drivers which have the same needs.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
An age is called Dark not because  the  light  fails  to  shine,  but
because people refuse to see it.   -- James Michener, "Space"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] PPC 85xx: Detect e500v2 / e500mc during runtime

[Scott Wood]

On Sun, 2014-01-19 at 16:19 +0100, Alexander Graf wrote:
> With the qemu-ppce500 machine type we can run the same board with
> either an e500v2 or an e500mc core plugged in.
> 
> This means that the IVOR setup can't be based on compile time decisions,
> so instead we have to do a runtime check which CPU generation we're
> running on.

Is this really the only place where you ran into this?

Also consider that you'll be adding extra size, and some of our 85xx
targets are pretty close to the limit as is (though at least this code
isn't used in SPLs).

I guess nobody ever bothered to set IVORs for e6500-specific exceptions.

For that matter, I don't see why we need this code at all.  These aren't
the addresses that U-Boot keeps its exception vectors at; it's setting
them up for the OS, apparently trying to imitate some other type of
book3e chip that has fixed ivors.  Apparently U-Boot has done this only
since 2009 (commit 26f4cdba6b51deab4ec99d60be381244068ef950), so it's
not even something that an OS could depend on (and certainly Linux
doesn't).  So I don't see the point.

-Scott


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

Re: [U-Boot] [PATCH 3/3] PPC 85xx: Add qemu-ppce500 machine

[Scott Wood]

On Sun, 2014-01-19 at 16:19 +0100, Alexander Graf wrote:
> For KVM we have a special PV machine type called "ppce500". This machine
> is inspired by the MPC8544DS board, but implements a lot less features
> than that one.
> 
> It also provides more PCI slots and is supposed to be enumerated by
> device tree only.
> 
> This patch adds support for the current generation ppce500 machine as
> it is implemented today.
> 
> Signed-off-by: Alexander Graf 
> ---
>  arch/powerpc/cpu/mpc85xx/start.S|7 +
>  arch/powerpc/include/asm/config_mpc85xx.h   |4 +
>  board/freescale/qemu-ppce500/Makefile   |   10 ++
>  board/freescale/qemu-ppce500/qemu-ppce500.c |  260 
> +++
>  board/freescale/qemu-ppce500/tlb.c  |   59 ++
>  boards.cfg  |1 +
>  include/configs/qemu-ppce500.h  |  235 
>  7 files changed, 576 insertions(+)
>  create mode 100644 board/freescale/qemu-ppce500/Makefile
>  create mode 100644 board/freescale/qemu-ppce500/qemu-ppce500.c
>  create mode 100644 board/freescale/qemu-ppce500/tlb.c
>  create mode 100644 include/configs/qemu-ppce500.h
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/start.S 
> b/arch/powerpc/cpu/mpc85xx/start.S
> index db84d10..ccbcc03 100644
> --- a/arch/powerpc/cpu/mpc85xx/start.S
> +++ b/arch/powerpc/cpu/mpc85xx/start.S
> @@ -80,6 +80,13 @@ _start_e500:
>   li  r1,MSR_DE
>   mtmsr   r1
>  
> +#ifdef CONFIG_QEMU_E500
> + /* Save our ePAPR device tree off before we clobber it */
> + lis r2, CONFIG_QEMU_DT_ADDR@h
> + ori r2, r2, CONFIG_QEMU_DT_ADDR@l
> + stw r3, 0(r2)
> +#endif

r2 has a special purpose -- please don't use it for other things, even
if it's too early to be a problem and other code is similarly bad.

Instead of saving the DT pointer in some random hardcoded address, how
about sticking it in a callee-saved register until you're able to store
it in the global data struct?

> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
> b/arch/powerpc/include/asm/config_mpc85xx.h
> index 54ce2f0..a0ab453 100644
> --- a/arch/powerpc/include/asm/config_mpc85xx.h
> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
> @@ -776,6 +776,10 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022)
>  #define CONFIG_SYS_CCSRBAR_DEFAULT   0xff70
>  #define CONFIG_SYS_FSL_ERRATUM_A005125
>  
> +#elif defined(CONFIG_QEMU_E500)
> +#define CONFIG_MAX_CPUS  1
> +#define CONFIG_SYS_CCSRBAR_DEFAULT   0xe000

This is supposed to come from the device tree.  We will want to change
that address eventually to support larger guest memory.

> diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c 
> b/board/freescale/qemu-ppce500/qemu-ppce500.c
> new file mode 100644
> index 000..c6c4b4a
> --- /dev/null
> +++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
> @@ -0,0 +1,260 @@
> +/*
> + * Copyright 2007,2009-2014 Freescale Semiconductor, Inc.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Do you really need all these headers?  miiphy?

> +int checkboard(void)
> +{
> + return 0;
> +}
> +
> +static struct pci_controller pci1_hose;
> +
> +void pci_init_board(void)
> +{
> + volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
> + struct fsl_pci_info pci_info;
> + u32 devdisr, pordevsr;
> + u32 porpllsr, pci_agent, pci_speed, pci_32, pci_arb, pci_clk_sel;
> + int first_free_busno = 0;
> +
> + devdisr = in_be32(&gur->devdisr);
> + pordevsr = in_be32(&gur->pordevsr);
> + porpllsr = in_be32(&gur->porpllsr);

Why are you reading registers that don't exist in QEMU?

> +int last_stage_init(void)
> +{
> + int ret;
> + int len = 0;
> + const void *prop;
> + int chosen;
> +uint32_t *dt_base_ptr = (void*)CONFIG_QEMU_DT_ADDR;

Whitespace

> + uint32_t dt_base = *dt_base_ptr;
> + uint32_t dt_size;
> + void *fdt;
> +
> + dt_size = fdt_totalsize((void*)dt_base);

Please put a space before the * in casts.

> + /* Reserve 4k for dtb tweaks */
> + dt_size += 4096;
> + fdt = malloc(dt_size);
> +
> + /* Open device tree */
> + ret = fdt_open_into((void*)dt_base, fdt, dt_size);
> + if (ret) {
> + printf("Couldn't open fdt at %x\n", dt_base);
> + return -EIO;
> + }
> +
> + chosen = fdt_path_offset(fdt, "/chosen");
> + if (chosen < 0) {
> + printf("Couldn't find /chosen node in fdt\n");
> + return -EIO;
> + }
> +
> + prop = fdt_getprop(fdt, chosen, "qemu,boot-kernel", &len);
> + if (prop && (len >= 8)) {
> + /* -kernel boot */
> + setenv_hex("kernel_addr", *(uint64_t*)prop);

Don't cast away the const.  This looks like the only place

Re: [U-Boot] how to get u-boot code with arm64: core support

[TigerLiu]

Hi, Bhupesh:
>U-boot doesn't have ARM trusted firmware support as of now. U-boot for
ARMv8 starts in EL3,
>whereas UEFI starts in EL2 as trusted firmware itself is working in
EL3.

Do you mean: when FVP run, the first instruction would be fetched from
u-boot.elf?

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

[U-Boot] [ANN] U-Boot v2014.01 released

[Tom Rini]

Hey all,

I've pushed v2014.01 out to the repository and tarballs should exist
soon.

As always, lots of nice little fixes here and there and everywhere.  One
big change of note this release is initial arm64 (aka aarch64) support.
It's a little rough around the edges with respect to passing data in,
but we'll get that smoothed out for the next release.

The merge window is now open until Feb 08 2014.

Thanks all!

-- 
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 2/6] sf: Optimize flash features code

[Marek Vasut]

On Monday, January 20, 2014 at 02:32:27 PM, Jagan Teki wrote:
> On Mon, Jan 20, 2014 at 6:49 PM, Marek Vasut  wrote:
> > On Saturday, January 18, 2014 at 09:51:56 PM, Jagan Teki wrote:
> >> On Sun, Jan 19, 2014 at 2:09 AM, Marek Vasut  wrote:
> >> > On Saturday, January 18, 2014 at 09:06:29 PM, Jagannadha Sutradharudu
> >> > Teki
> >> > 
> >> > wrote:
> >> >> - Shrink spi_slave {}
> >> >> - Shrink spi_flash_params {}
> >> >> - Documentation for sf features
> >> >> 
> >> >> Signed-off-by: Jagannadha Sutradharudu Teki 
> >> >> Cc: Marek Vasut 
> >> >> ---
> >> >> 
> >> >>  doc/SPI/README.sf-features| 122 ++
> >> >>  drivers/mtd/spi/sf.c  |   4 +-
> >> >>  drivers/mtd/spi/sf_internal.h |   1 -
> >> >>  drivers/mtd/spi/sf_ops.c  |   8 +-
> >> >>  drivers/mtd/spi/sf_params.c   | 172
> >> >> 
> >> >> +- drivers/mtd/spi/sf_probe.c
> >> >> 
> >> >>  71 -
> >> >>  include/spi.h |  42 ---
> >> >>  include/spi_flash.h   |  24 +++---
> >> >>  8 files changed, 270 insertions(+), 174 deletions(-)
> >> >>  create mode 100644 doc/SPI/README.sf-features
> >> >> 
> >> >> diff --git a/doc/SPI/README.sf-features b/doc/SPI/README.sf-features
> >> >> new file mode 100644
> >> >> index 000..d35f56d
> >> >> --- /dev/null
> >> >> +++ b/doc/SPI/README.sf-features
> >> >> @@ -0,0 +1,122 @@
> >> >> +SPI FLASH feature enhancements:
> >> >> +==
> >> >> +
> >> >> +This document describes how to extend the current data structures in
> >> >> spi subsystem +for making use of new flash features/operations w.r.t
> >> >> to controller driver support. +
> >> >> +1. spi_slave:
> >> >> +
> >> >> +struct spi_slave {
> >> >> +..
> >> >> +u32 mode_bits;
> >> >> +
> >> >> +};
> >> >> +
> >> >> +@mode_bits can be used to expose the SPI RX/TX operation modes, bus
> >> >> options and +few flags which are used to extended the flash specific
> >> >> features/operations +- include/spi.h
> >> >> +
> >> >> +mode_bits:
> >> >> +- SPI_TX_QPP: 4-Wire tx transfer operation quad page program
> >> >> +- SPI_RX_SLOW: 1-wire rx transfer operation array slow read
> >> >> +- SPI_RX_DUAL: 2-wire rx transfer operation dual fast read
> >> >> +- SPI_RX_DUAL_IO: 2-wire rx transfer operation dual io fast read
> >> >> +- SPI_RX_QUAD: 4-wire rx transfer operation quad fast read
> >> >> +- SPI_RX_QUAD_IO: 4-wire rx transfer operation quad io fast read
> >> >> +- SPI_SHARED: dual flash devices are connected in shared bus
> >> >> connection +- SPI_SEPARATED: dual flash devices are connected in
> >> >> separate bus connection +- SPI_U_PAGE: select the upper flash in
> >> >> dual flash shared bus connection [1] +
> >> > 
> >> > A generic SPI controller _does_ _not_ _care_ about any SPI flash crud.
> >> > The SPI bus controller (which is what this is for) and SPI-NOR
> >> > controller are two different things and must have two different slave
> >> > structures.
> >> 
> >> You mean mode_bits need to move in one more structure.
> >> Just leave about new SPI-NOR as of now for this release we discuss more
> >> soon.
> > 
> > The mode_bits have no place in this structure. The slave can indicate
> > whether it can be connected over 1,2,4... lines , but must not indicate
> > that it supports some SPI-flash specific properties.
> 
> What do you mean by this - can you elaborate.

I mean there do exist SPI controllers which can output data via more than one 
(MOSI) line . They do support 1, 2 or even 4 lines. This comes useful when 
driving SPI flashes indeed, _BUT_ (!) this is not tied to driving SPI flashes. 
On the contrary, you can connect any device which can be driven over such 
"parallelised" SPI and it will work. And only such property shall also land in 
the struct spi_slave {} .

Properties like "let's assume the SPI slave is a SPI NOR and it supports SPI 
NOR 
command FOO" do not go into struct spi_slave.

> As of now drivers in drivers/spi need to inform the flash through spi_slave
> {} no other alternative ie way remaining flash properties memory_map etc..
> handle. Even Linux follow the same w/o new SPI-NOR framework.

Linux is now going for a separate SPI-NOR controller framework and this is what 
we will do as well. The SF layer will be only a unifying layer providing access 
to either SPI-NOR API (for the SPI-NOR controllers) or a translation layer to 
communicate SPI-NOR commands over generic SPI API (for the old-school regular 
way of doing SPI NOR connection to SPI bus).

> If your question, like need a separate structure for flash specific
> properties please wait will wound-up all these in new framework.
> 
> I'm planning to push in today release.

I doubt anything is going in today's release ;-)

Actually, you need to really start discerning which _must_ go into a release 
and 
which simply does not go into a release and waits for -next. This is important 
role of a maintainer an

Re: [U-Boot] board:universal: fix i2c adapter

[Tom Rini]

On Tue, Jan 14, 2014 at 08:15:07AM +0100, Piotr Wilczek wrote:

> Universal uses only one adapter I2C_0.
> 
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> Acked-by: Przemyslaw Marczak 

Applied to u-boot/master, 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] [U-Boot, v2, 1/4] spl: common: Properly ignore spl/Makefile in .gitignore

[Tom Rini]

On Thu, Jan 16, 2014 at 11:23:28AM -0600, Dan Murphy wrote:

> The spl directory is ignored by git as these objects are created
> during spl creation.  The only file not created is the Makefile.
> 
> This file can be modified and checked in via git.
> 
> Due to the order of rule precedence having the whole directory
> ignored first then indicating not to ignore the Makefile is not correct
> the message to force adding the Makefile is still shown.
> 
> So reorder the .gitignore for the Makefile and indicate that the Makefile
> does not need to be ignored first and then indicate everything else in spl
> should be ignored after wards.
> 
> Signed-off-by: Dan Murphy 

Applied to u-boot/master, 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] yaffs2: Remove block number check from summary verification

[Tom Rini]

On Mon, Jan 20, 2014 at 03:51:59PM +1300, Charles Manning wrote:

> The summary already has other verification. This one is not needed.
> 
> The check caused summaries to be ignored if they were not on the
> numbered block. This caused problems when a summary was embedded in an
> image and the image is written to a flash with bad blocks.
> 
> Signed-off-by: Charles Manning 

Applied to u-boot/master, 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] .gitignore: ignore u-boot.elf and tools/relocate-rela

[Tom Rini]

On Tue, Jan 14, 2014 at 10:39:34AM +0900, Masahiro Yamada wrote:

> Signed-off-by: Masahiro Yamada 

Applied to u-boot/master, 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] [U-Boot,2/2] ext4fs: fix "invalid extent block" error

[Tom Rini]

On Mon, Jan 13, 2014 at 12:00:08PM +0100, Ionut Nicu wrote:

> For files where we actually have extent indexes following
> an extent header (ext_block->eh_depth != 0), the do/while
> loop from ext4fs_get_extent_block() does not select the
> proper extent index structure.
> 
> For example, if we have:
> 
> ext_block->eh_depth = 1
> ext_block->eh_entries = 1
> fileblock = 0
> index[0].ei_block = 0
> 
> the do/while loop will exit with i set to 0 and the
> ext4fs_get_extent_block() function will return 0, even if
> there was a valid extent index structure following the
> header.
> 
> Signed-off-by: Ionut Nicu 
> Signed-off-by: Mathias Rulf 

Applied to u-boot/master, 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] [U-Boot, 1/2] ext4fs: use EXT2_BLOCK_SIZE instead of fs->blksz

[Tom Rini]

On Mon, Jan 13, 2014 at 11:59:24AM +0100, Ionut Nicu wrote:

> Using fs->blksz in ext4fs_get_extent_block() is not
> correct since fs->blksz is not initialized on the
> read path. Use EXT2_BLOCK_SIZE() instead which will
> produce the desired output.
> 
> Signed-off-by: Ionut Nicu 
> Signed-off-by: Mathias Rulf 

Applied to u-boot/master, 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] fs/ext4: fix calling put_ext4 with truncated offset

[Tom Rini]

On Wed, Jan 08, 2014 at 08:15:33AM +0800, Ma Haijun wrote:

> Curently, we are using 32 bit multiplication to calculate the offset,
> so the result will always be 32 bit.
> This can silently cause file system corruption when performing a write
> operation on partition larger than 4 GiB.
> 
> This patch address the issue by simply promoting the terms to 64 bit,
> and let compilers decide how to do the multiplication efficiently.
> 
> Signed-off-by: Ma Haijun 

Applied to u-boot/master, 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] fs/ext4: fix partition size get truncated in calculation

[Tom Rini]

On Wed, Jan 08, 2014 at 06:49:43AM +0800, Ma Haijun wrote:

> It may cause file system corruption when do a write operation.
> This issue only affects boards that use 32 bit lbaint_t.
> 
> Signed-off-by: Ma Haijun 

Applied to u-boot/master, 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] [U-Boot, REPOST4, 2/2] ARM: bcm2835: fix mailbox timeout

[Tom Rini]

On Mon, Jan 13, 2014 at 07:50:12PM -0700, Stephen Warren wrote:

> My original intention was to have a 100ms timeout. However, the timer
> operations used return values in ms not us, so we ended up with a 100s
> timeout instead. Fixing this exposes that some operations need longer
> to operate than 100ms, so bump the timeout up to a whole second.
> 
> Reported-by: Andre Heider 
> Reviewed-by: Andre Heider 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, 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] [PULL] : Please pull u-boot-imx

[Tom Rini]

On Fri, Jan 17, 2014 at 10:26:24AM +0100, Stefano Babic wrote:

> Hi Albert,
> 
> Commit 022298278 (mx6: soc: Disable VDDPU regulator) does not let boot
> kernel with enabled GPU (i.MX6). It is unclear at the moment if the fix
> should be done in U-Boot or in kernel, so it is better to revert it for
> the release. Please pull from u-boot-imx, thanks !
> 
> The following changes since commit 3a21773129f6ef218f1978d05a1a5d5cf6801ab6:
> 
>   mx6: Add initial support for the Hummingboard solo (2014-01-15
> 10:33:25 +0100)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git master
> 
> for you to fetch changes up to be2a3bb39adf1fdd274fc427e30ef62eb86441a1:
> 
>   mx6: Revert "mx6: soc: Disable VDDPU regulator" (2014-01-17 10:16:48
> +0100)
> 
> 
> Fabio Estevam (1):
>   mx6: Revert "mx6: soc: Disable VDDPU regulator"
> 
>  arch/arm/cpu/armv7/mx6/soc.c |   41
> --
>  arch/arm/include/asm/arch-mx6/crm_regs.h |1 -
>  arch/arm/include/asm/arch-mx6/imx-regs.h |   23 -
>  3 files changed, 65 deletions(-)

Applied to u-boot/master, 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] [U-Boot, REPOST4, 1/2] ARM: rpi_b: power on SDHCI and USB HW modules

[Tom Rini]

On Mon, Jan 13, 2014 at 07:50:11PM -0700, Stephen Warren wrote:

> Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
> For SDHCI this isn't needed in practice, since the firmware already
> turned on the power in order to load U-Boot. However, it's best to be
> explicit. For USB, this is necessary, since the module isn't powered
> otherwise. This will allow the kernel USB driver to work.
> 
> Signed-off-by: Stephen Warren 

Applied to u-boot/master, 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] [i2c] v2 Pull request

[Tom Rini]

On Mon, Jan 20, 2014 at 10:45:58AM +0100, Heiko Schocher wrote:

> Hello Tom
> 
> Updated pull request for u-boot-i2c, as the zynq patches had problems,
> see:
> 
> http://lists.denx.de/pipermail/u-boot/2014-January/171352.html
> 
> So, here the correct pull-request:
> 
> The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 
> -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> for you to fetch changes up to dccacbe01968f9e682cb1dc9b7d43c831897cbec:
> 
>   i2c: fti2c010: fix compiler warning on paddr[] (2014-01-13 08:18:38 +0100)
> 
> 
> Alexey Brodkin (2):
>   env_eeprom - fix bus recovery for "eeprom_bus_read"
>   drivers/designware_i2c - add suppor of 
> CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
> 
> Darwin Rambo (1):
>   i2c: Fix i2c speed command
> 
> Hisashi Nakamura (1):
>   rcar_i2c: Fix receiving wait condition
> 
> Kuo-Jung Su (1):
>   i2c: fti2c010: fix compiler warning on paddr[]
> 
> Nobuhiro Iwamatsu (1):
>   rcar_i2c: Clear status before start master receive
> 
>  common/env_eeprom.c  |  5 ++---
>  drivers/i2c/designware_i2c.c | 38 ++
>  drivers/i2c/fti2c010.c   |  4 ++--
>  drivers/i2c/i2c_core.c   |  2 +-
>  drivers/i2c/rcar_i2c.c   |  6 --
>  5 files changed, 47 insertions(+), 8 deletions(-)

Applied to u-boot/master, 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 1/5] tools: mkimage: add support for gpimage format

[Tom Rini]

On Mon, Jan 20, 2014 at 11:46:49PM +0100, Wolfgang Denk wrote:
> Dear Murali Karicheri,
> 
> In message <1390255810-19486-2-git-send-email-m-kariche...@ti.com> you wrote:
> > This patch add support for gpimage format as a preparatory
> > patch for porting u-boot for keystone2 devices and is
> > based on omapimage format. It re-uses gph header to store the
> > size and loadaddr as done in omapimage.c
> ...
> > --- a/common/image.c
> > +++ b/common/image.c
> > @@ -137,6 +137,7 @@ static const table_entry_t uimage_type[] = {
> > {   IH_TYPE_STANDALONE, "standalone", "Standalone Program", },
> > {   IH_TYPE_UBLIMAGE,   "ublimage",   "Davinci UBL image",},
> > {   IH_TYPE_MXSIMAGE,   "mxsimage",   "Freescale MXS Boot Image",},
> > +   {   IH_TYPE_GPIMAGE,"gpimage","TI KeyStone SPL Image",},
> > {   -1, "",   "",   },
> 
> Please keep the list sorted.  While you are at it, please also fi the
> incorrect placement of the IH_TYPE_MXSIMAGE entry.
> 
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -84,7 +84,9 @@ NOPED_OBJ_FILES-y += imagetool.o
> >  NOPED_OBJ_FILES-y += mkenvimage.o
> >  NOPED_OBJ_FILES-y += mkimage.o
> >  NOPED_OBJ_FILES-y += mxsimage.o
> > +NOPED_OBJ_FILES-y += gpimage-common.o
> >  NOPED_OBJ_FILES-y += omapimage.o
> > +NOPED_OBJ_FILES-y += gpimage.o
> >  NOPED_OBJ_FILES-y += os_support.o
> 
> Please keep the list sorted.
> 
> > @@ -219,7 +221,9 @@ $(obj)dumpimage$(SFX):  $(obj)aisimage.o \
> > $(obj)dumpimage.o \
> > $(obj)md5.o \
> > $(obj)mxsimage.o \
> > +   $(obj)gpimage-common.o \
> > $(obj)omapimage.o \
> > +   $(obj)gpimage.o \
> 
> Ditto.  Please fix this issue globally.
> 
> 
> > +uint32_t gpimage_swap32(uint32_t data)
> > +{
> > +   return cpu_to_be32(data);
> > +}
> 
> The function name is misleading.  Also it is not clear why you need
> this function at all.  You can use cpu_to_be32() directly - that will
> make the code much easier to read.
> 
> > +/* TODO: do we need the below 2 functions?? */
> > +int valid_gph_size(uint32_t size)
> > +{
> > +   return size;
> > +}
> > +
> > +int valid_gph_load_addr(uint32_t load_addr)
> > +{
> > +   return load_addr;
> > +}
> 
> These functions are obviously bogus.  Please dump them.
> 
> > +int gph_verify_header(struct gp_header *gph, int do_swap32)
> > +{
> > +   uint32_t gph_size, gph_load_addr;
> > +
> > +   if (do_swap32) {
> > +   gph_size = gpimage_swap32(gph->size);
> > +   gph_load_addr = gpimage_swap32(gph->load_addr);
> > +   } else {
> > +   gph_size = gph->size;
> > +   gph_load_addr = gph->load_addr;
> > +   }
> 
> I think it should be possible top write this code in such a way that
> you can avoid both the if-else and passing the  do_swap32  parameter.
> It is my impression that the whole endianess handling needs some
> refinemant.
> 
> Actually I cannot see a place where do_swap32=0 is used..

This appears to be a blind re-use of the omap code where we do have a
case where we have to do this kind of swap.

-- 
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][v2] driver/ifc:Change accessor function to take care of endianness

[Scott Wood]

On Sat, 2014-01-18 at 09:24 +0100, Wolfgang Denk wrote:
> Dear Prabhakar Kushwaha,
> 
> In message <1390028310-30861-1-git-send-email-prabha...@freescale.com> you 
> wrote:
> > IFC registers can be of type Little Endian or big Endian depending upon
> > Freescale SoC. Here SoC defines the register type of IFC IP.
> 
> As is, you are only adding dead code, as there is no place anywhere in
> the mainline code that defines CONFIG_SYS_FSL_IFC_LE

Yes, consider it RFC until we have patches for a target that needs LE.

> > /* Program ROW0/COL0 */
> > -   out_be32(&ifc->ifc_nand.row0, page_addr);
> > -   out_be32(&ifc->ifc_nand.col0, (oob ? IFC_NAND_COL_MS : 0) | column);
> > +   ifc_out32(&ifc->ifc_nand.row0, page_addr);
> > +   ifc_out32(&ifc->ifc_nand.col0, (oob ? IFC_NAND_COL_MS : 0) | column);
> 
> I seriously dislike the idea of introducing special I/O accessors for
> a single device driver.  If more drivers would follow that example, we
> will soon have a serious mess.

As the changelog says, we have chips coming out on which these registers
are little-endian, and thus we can't hardcode big-endian in the
driver.  

I don't know whether there's something more generic we could key off of
than IFC, but in Linux (and maybe U-Boot) we'll want to make this driven
by the device tree rather than at compile time (it's not as simple as
PPC versus ARM), so getting the knowledge from something other than the
IFC node would be awkward -- and it would be good to keep this code
similar between U-Boot and Linux.

What sort of mess are you envisioning?  This isn't implementing
accessors from scratch; it's just a wrapper.  It's local to IFC code.

-Scott


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

Re: [U-Boot] [PATCH 5/5] NAND: DaVinci: allow forced disable of subpage writes

[Wolfgang Denk]

Dear Murali Karicheri,

In message <1390255810-19486-6-git-send-email-m-kariche...@ti.com> you wrote:
> This patch introduces a configurable mechanism to disable subpage writes
> in the DaVinci NAND driver.
> 
> Signed-off-by: Vitaly Andrianov 
> Signed-off-by: Murali Karicheri 
> ---
>  drivers/mtd/nand/davinci_nand.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
> index 5b17d7b..75b03a7 100644
> --- a/drivers/mtd/nand/davinci_nand.c
> +++ b/drivers/mtd/nand/davinci_nand.c
> @@ -609,6 +609,9 @@ void davinci_nand_init(struct nand_chip *nand)
>  #ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
>   nand->bbt_options |= NAND_BBT_USE_FLASH;
>  #endif
> +#ifdef CONFIG_SYS_NAND_NO_SUBPAGE_WRITE
> + nand->options |= NAND_NO_SUBPAGE_WRITE;
> +#endif
>  #ifdef CONFIG_SYS_NAND_HW_ECC
>   nand->ecc.mode = NAND_ECC_HW;
>   nand->ecc.size = 512;

New CONFIG_ options MUSt be documented in the README.

Also, you are just adding dead code.  There are no users for this
option.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
While most peoples' opinions change, the conviction of their correct-
ness never does.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] arm: add support for arch timer

[Wolfgang Denk]

Dear Murali Karicheri,

In message <1390255810-19486-5-git-send-email-m-kariche...@ti.com> you wrote:
> This patch add basic support for the architecture timer found on recent
> ARMv7 based SoCs.

Are we adding dead code here?  Or where exactly is this code being
used?


> --- /dev/null
> +++ b/arch/arm/lib/arch_timer.c
> @@ -0,0 +1,69 @@
> +/*
> + * Copyright (c) 2012, Texas Instruments 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */

Please use SPDX License tag instead.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The world is coming to an end -- save your buffers!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] fdt_support.c: Correct linux, initrd-start/end setting

[Tom Rini]

The change to add 64bit initrd support broke 32bit initrd support as it
always set 64bits worth of data into the properties, even on 32bit
systems.  The fix is to use addr_cell_len (which already says how much
data is in 'tmp') to set the property, rather than always setting 8.
Thanks to Stephen Warren for pointing out the fix here.

Reported-by: Otavio Salvador 
Signed-off-by: Tom Rini 
---
 common/fdt_support.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index b9dce99..f9f358e 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -204,7 +204,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
initrd_end, int force)
if ((path == NULL) || force) {
write_cell((u8 *)&tmp, initrd_start, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
-   "linux,initrd-start", &tmp, sizeof(tmp));
+   "linux,initrd-start", &tmp, addr_cell_len);
if (err < 0) {
printf("WARNING: "
"could not set linux,initrd-start %s.\n",
@@ -213,7 +213,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
initrd_end, int force)
}
write_cell((u8 *)&tmp, initrd_end, addr_cell_len);
err = fdt_setprop(fdt, nodeoffset,
-   "linux,initrd-end", &tmp, sizeof(tmp));
+   "linux,initrd-end", &tmp, addr_cell_len);
if (err < 0) {
printf("WARNING: could not set linux,initrd-end %s.\n",
fdt_strerror(err));
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 1/5] tools: mkimage: add support for gpimage format

[Wolfgang Denk]

Dear Murali Karicheri,

In message <1390255810-19486-2-git-send-email-m-kariche...@ti.com> you wrote:
> This patch add support for gpimage format as a preparatory
> patch for porting u-boot for keystone2 devices and is
> based on omapimage format. It re-uses gph header to store the
> size and loadaddr as done in omapimage.c
...
> --- a/common/image.c
> +++ b/common/image.c
> @@ -137,6 +137,7 @@ static const table_entry_t uimage_type[] = {
>   {   IH_TYPE_STANDALONE, "standalone", "Standalone Program", },
>   {   IH_TYPE_UBLIMAGE,   "ublimage",   "Davinci UBL image",},
>   {   IH_TYPE_MXSIMAGE,   "mxsimage",   "Freescale MXS Boot Image",},
> + {   IH_TYPE_GPIMAGE,"gpimage","TI KeyStone SPL Image",},
>   {   -1, "",   "",   },

Please keep the list sorted.  While you are at it, please also fi the
incorrect placement of the IH_TYPE_MXSIMAGE entry.

> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -84,7 +84,9 @@ NOPED_OBJ_FILES-y += imagetool.o
>  NOPED_OBJ_FILES-y += mkenvimage.o
>  NOPED_OBJ_FILES-y += mkimage.o
>  NOPED_OBJ_FILES-y += mxsimage.o
> +NOPED_OBJ_FILES-y += gpimage-common.o
>  NOPED_OBJ_FILES-y += omapimage.o
> +NOPED_OBJ_FILES-y += gpimage.o
>  NOPED_OBJ_FILES-y += os_support.o

Please keep the list sorted.

> @@ -219,7 +221,9 @@ $(obj)dumpimage$(SFX):$(obj)aisimage.o \
>   $(obj)dumpimage.o \
>   $(obj)md5.o \
>   $(obj)mxsimage.o \
> + $(obj)gpimage-common.o \
>   $(obj)omapimage.o \
> + $(obj)gpimage.o \

Ditto.  Please fix this issue globally.


> +uint32_t gpimage_swap32(uint32_t data)
> +{
> + return cpu_to_be32(data);
> +}

The function name is misleading.  Also it is not clear why you need
this function at all.  You can use cpu_to_be32() directly - that will
make the code much easier to read.

> +/* TODO: do we need the below 2 functions?? */
> +int valid_gph_size(uint32_t size)
> +{
> + return size;
> +}
> +
> +int valid_gph_load_addr(uint32_t load_addr)
> +{
> + return load_addr;
> +}

These functions are obviously bogus.  Please dump them.

> +int gph_verify_header(struct gp_header *gph, int do_swap32)
> +{
> + uint32_t gph_size, gph_load_addr;
> +
> + if (do_swap32) {
> + gph_size = gpimage_swap32(gph->size);
> + gph_load_addr = gpimage_swap32(gph->load_addr);
> + } else {
> + gph_size = gph->size;
> + gph_load_addr = gph->load_addr;
> + }

I think it should be possible top write this code in such a way that
you can avoid both the if-else and passing the  do_swap32  parameter.
It is my impression that the whole endianess handling needs some
refinemant.

Actually I cannot see a place where do_swap32=0 is used..

> +void gph_print_header(const struct gp_header *gph, int do_swap32)
> +{
> + uint32_t gph_size, gph_load_addr;
> +
> + if (do_swap32) {
> + gph_size = gpimage_swap32(gph->size);
> + gph_load_addr = gpimage_swap32(gph->load_addr);
> + } else {
> + gph_size = gph->size;
> + gph_load_addr = gph->load_addr;
> + }

This is repeasted code.  Get rid of it.

> +void gph_set_header(struct gp_header *gph, uint32_t size, uint32_t load_addr,
> + int do_swap32)
> +{
> + if (do_swap32) {
> + gph->size = gpimage_swap32(size);
> + gph->load_addr = gpimage_swap32(load_addr);
> + } else {
> + gph->size = size;
> + gph->load_addr = load_addr;
> + }

And again.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"The X11 source code style is ATROCIOUS and should not be used  as  a
model."   - Doug Gwyn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/5] tools: mkimage: add support for gpimage format

[Murali Karicheri]

This patch add support for gpimage format as a preparatory
patch for porting u-boot for keystone2 devices and is
based on omapimage format. It re-uses gph header to store the
size and loadaddr as done in omapimage.c

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Murali Karicheri 
---
 - Tested only on keystone. Need help to test on OMAP since this is 
   impacted.

 common/image.c |1 +
 include/image.h|1 +
 tools/Makefile |6 +++
 tools/gpheader.h   |   41 +++
 tools/gpimage-common.c |  103 
 tools/gpimage.c|   78 
 tools/imagetool.c  |2 +
 tools/imagetool.h  |1 +
 tools/omapimage.c  |   97 +++--
 tools/omapimage.h  |5 ---
 10 files changed, 248 insertions(+), 87 deletions(-)
 create mode 100644 tools/gpheader.h
 create mode 100644 tools/gpimage-common.c
 create mode 100644 tools/gpimage.c

diff --git a/common/image.c b/common/image.c
index ae95c3f..52ee840 100644
--- a/common/image.c
+++ b/common/image.c
@@ -137,6 +137,7 @@ static const table_entry_t uimage_type[] = {
{   IH_TYPE_STANDALONE, "standalone", "Standalone Program", },
{   IH_TYPE_UBLIMAGE,   "ublimage",   "Davinci UBL image",},
{   IH_TYPE_MXSIMAGE,   "mxsimage",   "Freescale MXS Boot Image",},
+   {   IH_TYPE_GPIMAGE,"gpimage","TI KeyStone SPL Image",},
{   -1, "",   "",   },
 };
 
diff --git a/include/image.h b/include/image.h
index 7de2bb2..0a3d346 100644
--- a/include/image.h
+++ b/include/image.h
@@ -214,6 +214,7 @@ struct lmb;
 #define IH_TYPE_KERNEL_NOLOAD  14  /* OS Kernel Image, can run from any 
load address */
 #define IH_TYPE_PBLIMAGE   15  /* Freescale PBL Boot Image */
 #define IH_TYPE_MXSIMAGE   16  /* Freescale MXSBoot Image  */
+#define IH_TYPE_GPIMAGE17  /* TI Keystone GPHeader Image   
*/
 
 /*
  * Compression Types
diff --git a/tools/Makefile b/tools/Makefile
index 328cea3..cbbe479 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -84,7 +84,9 @@ NOPED_OBJ_FILES-y += imagetool.o
 NOPED_OBJ_FILES-y += mkenvimage.o
 NOPED_OBJ_FILES-y += mkimage.o
 NOPED_OBJ_FILES-y += mxsimage.o
+NOPED_OBJ_FILES-y += gpimage-common.o
 NOPED_OBJ_FILES-y += omapimage.o
+NOPED_OBJ_FILES-y += gpimage.o
 NOPED_OBJ_FILES-y += os_support.o
 NOPED_OBJ_FILES-y += pblimage.o
 NOPED_OBJ_FILES-y += proftool.o
@@ -219,7 +221,9 @@ $(obj)dumpimage$(SFX):  $(obj)aisimage.o \
$(obj)dumpimage.o \
$(obj)md5.o \
$(obj)mxsimage.o \
+   $(obj)gpimage-common.o \
$(obj)omapimage.o \
+   $(obj)gpimage.o \
$(obj)os_support.o \
$(obj)pblimage.o \
$(obj)sha1.o \
@@ -248,7 +252,9 @@ $(obj)mkimage$(SFX):$(obj)aisimage.o \
$(obj)md5.o \
$(obj)mkimage.o \
$(obj)mxsimage.o \
+   $(obj)gpimage-common.o \
$(obj)omapimage.o \
+   $(obj)gpimage.o \
$(obj)os_support.o \
$(obj)pblimage.o \
$(obj)sha1.o \
diff --git a/tools/gpheader.h b/tools/gpheader.h
new file mode 100644
index 000..0bfc0c2
--- /dev/null
+++ b/tools/gpheader.h
@@ -0,0 +1,41 @@
+/*
+ * (C) Copyright 2014
+ * Texas Instruments Incorporated
+ * Refactored common functions in to gpimage-common.c. Include this common
+ * header file
+ *
+ * (C) Copyright 2010
+ * Linaro LTD, www.linaro.org
+ * Author: John Rigby 
+ * Based on TI's signGP.c
+ *
+ * (C) Copyright 2009
+ * Stefano Babic, DENX Software Engineering, sba...@denx.de.
+ *
+ * (C) Copyright 2008
+ * Marvell Semiconductor 
+ * Written-by: Prafulla Wadaskar 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _GPIMAGE_H_
+#define _GPIMAGE_H_
+
+/* common headers for gpimage and omapimage formats */
+struct gp_header {
+   uint32_t size;
+   uint32_t load_addr;
+};
+#define GPIMAGE_HDR_SIZE (sizeof(struct gp_header))
+
+/* common functions across gpimage and omapimage handlers */
+uint32_t gpimage_swap32(uint32_t data);
+int valid_gph_size(uint32_t size);
+int valid_gph_load_addr(uint32_t load_addr);
+int gph_verify_header(struct gp_header *gph, int do_swap32);
+void gph_print_header(const struct gp_header *gph, int do_swap32);
+void gph_set_header(struct gp_header *gph, uint32_t size, uint32_t load_addr,
+   int do_swap32);
+int gpimage_check_params(struct image_tool_params *params);
+#endif
diff --git a/tools/gpimage-common.c b/tools/gpimage-common.c
new file mode 100644
index 000..85b9819
--- /dev/null
+++ b/tools/gpimage-common.c
@@

[U-Boot] [PATCH 3/5] ubifs: return filesize from ubifs load operations

[Murali Karicheri]

This patch extends the ubifs load implementation to return the size of
the file loaded from the filesystem.  The ubifs command implementation
has also been modified to set the filesize environment variable
accordingly.

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Murali Karicheri 
---
 common/cmd_ubifs.c |7 +--
 fs/ubifs/ubifs.c   |   14 +++---
 fs/ubifs/ubifs.h   |2 +-
 3 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/common/cmd_ubifs.c b/common/cmd_ubifs.c
index fdc8bfe..a2926e0 100644
--- a/common/cmd_ubifs.c
+++ b/common/cmd_ubifs.c
@@ -110,6 +110,7 @@ int do_ubifs_load(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
int ret;
u32 addr;
u32 size = 0;
+   char buf[32];
 
if (!ubifs_mounted) {
printf("UBIFS not mounted, use ubifs mount to mount volume 
first!\n");
@@ -132,12 +133,14 @@ int do_ubifs_load(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
}
debug("Loading file '%s' to address 0x%08x (size %d)\n", filename, 
addr, size);
 
-   ret = ubifs_load(filename, addr, size);
+   ret = ubifs_load(filename, addr, &size);
if (ret) {
printf("** File not found %s **\n", filename);
ret = CMD_RET_FAILURE;
+   } else {
+   sprintf(buf, "%X", size);
+   setenv("filesize", buf);
}
-
return ret;
 }
 
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 273c0a9..4f1d5c7 100644
--- a/fs/ubifs/ubifs.c
+++ b/fs/ubifs/ubifs.c
@@ -677,7 +677,7 @@ error:
return err;
 }
 
-int ubifs_load(char *filename, u32 addr, u32 size)
+int ubifs_load(char *filename, u32 addr, u32 *size)
 {
struct ubifs_info *c = ubifs_sb->s_fs_info;
unsigned long inum;
@@ -711,12 +711,12 @@ int ubifs_load(char *filename, u32 addr, u32 size)
 * If no size was specified or if size bigger than filesize
 * set size to filesize
 */
-   if ((size == 0) || (size > inode->i_size))
-   size = inode->i_size;
+   if ((*size == 0) || (*size > inode->i_size))
+   *size = inode->i_size;
 
-   count = (size + UBIFS_BLOCK_SIZE - 1) >> UBIFS_BLOCK_SHIFT;
+   count = (*size + UBIFS_BLOCK_SIZE - 1) >> UBIFS_BLOCK_SHIFT;
printf("Loading file '%s' to addr 0x%08x with size %d (0x%08x)...\n",
-  filename, addr, size, size);
+  filename, addr, *size, *size);
 
page.addr = (void *)addr;
page.index = 0;
@@ -725,8 +725,8 @@ int ubifs_load(char *filename, u32 addr, u32 size)
/*
 * Make sure to not read beyond the requested size
 */
-   if (((i + 1) == count) && (size < inode->i_size))
-   last_block_size = size - (i * PAGE_SIZE);
+   if (((i + 1) == count) && (*size < inode->i_size))
+   last_block_size = *size - (i * PAGE_SIZE);
 
err = do_readpage(c, inode, &page, last_block_size);
if (err)
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 2213201..00485b3 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -2142,7 +2142,7 @@ int ubifs_init(void);
 int ubifs_mount(char *vol_name);
 void ubifs_umount(struct ubifs_info *c);
 int ubifs_ls(char *dir_name);
-int ubifs_load(char *filename, u32 addr, u32 size);
+int ubifs_load(char *filename, u32 addr, u32 *size);
 
 #include "debug.h"
 #include "misc.h"
-- 
1.7.9.5

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

[U-Boot] [PATCH 0/5] preparation to intriduce keystone support

[Murali Karicheri]

The Texas Instruments Keystone SOC u-boot support requires some
common code modifications to be done before introducing the
support itself.

This series of patches makes these modifications.

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Murali Karicheri 

Murali Karicheri (5):
  tools: mkimage: add support for gpimage format
  ubifs: fix checkpatch warning
  ubifs: return filesize from ubifs load operations
  arm: add support for arch timer
  NAND: DaVinci: allow forced disable of subpage writes

 arch/arm/lib/Makefile   |1 +
 arch/arm/lib/arch_timer.c   |   69 ++
 common/cmd_ubifs.c  |   16 ++
 common/image.c  |1 +
 drivers/mtd/nand/davinci_nand.c |3 ++
 fs/ubifs/ubifs.c|   14 +++---
 fs/ubifs/ubifs.h|7 +++
 include/image.h |1 +
 tools/Makefile  |6 +++
 tools/gpheader.h|   41 
 tools/gpimage-common.c  |  103 +++
 tools/gpimage.c |   78 +
 tools/imagetool.c   |2 +
 tools/imagetool.h   |1 +
 tools/omapimage.c   |   97 ++--
 tools/omapimage.h   |5 --
 16 files changed, 340 insertions(+), 105 deletions(-)
 create mode 100644 arch/arm/lib/arch_timer.c
 create mode 100644 tools/gpheader.h
 create mode 100644 tools/gpimage-common.c
 create mode 100644 tools/gpimage.c

-- 
1.7.9.5

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

[U-Boot] [PATCH 4/5] arm: add support for arch timer

[Murali Karicheri]

This patch add basic support for the architecture timer found on recent
ARMv7 based SoCs.

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Murali Karicheri 
---
 arch/arm/lib/Makefile |1 +
 arch/arm/lib/arch_timer.c |   69 +
 2 files changed, 70 insertions(+)
 create mode 100644 arch/arm/lib/arch_timer.c

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 321997c..58d58f8 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -42,6 +42,7 @@ obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
 else
 obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
 endif
+COBJS-$(CONFIG_SYS_ARCH_TIMER) += arch_timer.o
 
 ifdef CONFIG_ARM64
 obj-y  += interrupts_64.o
diff --git a/arch/arm/lib/arch_timer.c b/arch/arm/lib/arch_timer.c
new file mode 100644
index 000..6ffa650
--- /dev/null
+++ b/arch/arm/lib/arch_timer.c
@@ -0,0 +1,69 @@
+/*
+ * Copyright (c) 2012, Texas Instruments 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int timer_init(void)
+{
+   gd->arch.tbl = 0;
+   gd->arch.tbu = 0;
+
+   gd->arch.timer_rate_hz = CONFIG_SYS_HZ_CLOCK / CONFIG_SYS_HZ;
+
+   return 0;
+}
+
+unsigned long long get_ticks(void)
+{
+   ulong nowl, nowu;
+
+   asm volatile("mrrc p15, 0, %0, %1, c14" : "=r" (nowl), "=r" (nowu));
+
+   gd->arch.tbl = nowl;
+   gd->arch.tbu = nowu;
+
+   return (((unsigned long long)gd->arch.tbu) << 32) | gd->arch.tbl;
+}
+
+
+ulong get_timer(ulong base)
+{
+   return lldiv(get_ticks(), gd->arch.timer_rate_hz) - base;
+}
+
+void __udelay(unsigned long usec)
+{
+   unsigned long long endtime;
+
+   endtime = lldiv((unsigned long long)usec * gd->arch.timer_rate_hz,
+   1000UL);
+
+   endtime += get_ticks();
+
+   while (get_ticks() < endtime)
+   ;
+}
+
+ulong get_tbclk(void)
+{
+   return gd->arch.timer_rate_hz;
+}
-- 
1.7.9.5

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

[U-Boot] [PATCH 2/5] ubifs: fix checkpatch warning

[Murali Karicheri]

Fix the following checkpatch warning:-

WARNING: externs should be avoided in .c files

Signed-off-by: Murali Karicheri 
---
 common/cmd_ubifs.c |9 -
 fs/ubifs/ubifs.h   |7 +++
 2 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/common/cmd_ubifs.c b/common/cmd_ubifs.c
index d9af023..fdc8bfe 100644
--- a/common/cmd_ubifs.c
+++ b/common/cmd_ubifs.c
@@ -21,15 +21,6 @@
 static int ubifs_initialized;
 static int ubifs_mounted;
 
-extern struct super_block *ubifs_sb;
-
-/* Prototypes */
-int ubifs_init(void);
-int ubifs_mount(char *vol_name);
-void ubifs_umount(struct ubifs_info *c);
-int ubifs_ls(char *dir_name);
-int ubifs_load(char *filename, u32 addr, u32 size);
-
 int do_ubifs_mount(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
char *vol_name;
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 633631e..2213201 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -2137,6 +2137,13 @@ void ubifs_compress(const void *in_buf, int in_len, void 
*out_buf, int *out_len,
 int ubifs_decompress(const void *buf, int len, void *out, int *out_len,
 int compr_type);
 
+/* these are used in cmd_ubifs.c */
+int ubifs_init(void);
+int ubifs_mount(char *vol_name);
+void ubifs_umount(struct ubifs_info *c);
+int ubifs_ls(char *dir_name);
+int ubifs_load(char *filename, u32 addr, u32 size);
+
 #include "debug.h"
 #include "misc.h"
 #include "key.h"
-- 
1.7.9.5

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

[U-Boot] [PATCH 5/5] NAND: DaVinci: allow forced disable of subpage writes

[Murali Karicheri]

This patch introduces a configurable mechanism to disable subpage writes
in the DaVinci NAND driver.

Signed-off-by: Vitaly Andrianov 
Signed-off-by: Murali Karicheri 
---
 drivers/mtd/nand/davinci_nand.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 5b17d7b..75b03a7 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -609,6 +609,9 @@ void davinci_nand_init(struct nand_chip *nand)
 #ifdef CONFIG_SYS_NAND_USE_FLASH_BBT
nand->bbt_options |= NAND_BBT_USE_FLASH;
 #endif
+#ifdef CONFIG_SYS_NAND_NO_SUBPAGE_WRITE
+   nand->options |= NAND_NO_SUBPAGE_WRITE;
+#endif
 #ifdef CONFIG_SYS_NAND_HW_ECC
nand->ecc.mode = NAND_ECC_HW;
nand->ecc.size = 512;
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 2/2][v2] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS

[Scott Wood]

On Mon, 2014-01-20 at 13:08 +0530, Aneesh Bansal wrote:
> diff --git a/arch/powerpc/include/asm/fsl_secure_boot.h 
> b/arch/powerpc/include/asm/fsl_secure_boot.h
> index 4c7f0b1..db124df 100644
> --- a/arch/powerpc/include/asm/fsl_secure_boot.h
> +++ b/arch/powerpc/include/asm/fsl_secure_boot.h
> @@ -15,5 +15,11 @@
>  #endif
>  #define CONFIG_SYS_PBI_FLASH_WINDOW  0xcff8
>  
> +#if CONFIG_SYS_FSL_ISBC_VER > 1
> +#define CONFIG_SECURE_HKAREA_CPC
> +#undef CONFIG_SYS_INIT_L3_ADDR
> +#define CONFIG_SYS_INIT_L3_ADDR  0xbff0
> +#endif

Where is CONFIG_SECURE_HKAREA_CPC documented?  Shouldn't it be in
CONFIG_SYS?

-Scott


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

Re: [U-Boot] [PATCH 3/3] powerpc/mpc85xx: SECURE BOOT- Disable law 0 for non PBL platforms

[Scott Wood]

On Mon, 2014-01-20 at 14:57 +0530, Aneesh Bansal wrote:
> ISBC creates a LAW 0 entry for non PBL platforms, which is not
> disabled before transferring the control to uboot.
> The LAW 0 entry has to be disabled.
> 
> Signed-off-by: Aneesh Bansal 
> ---
>  arch/powerpc/cpu/mpc85xx/start.S | 58 
> 
>  1 file changed, 58 insertions(+)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/start.S 
> b/arch/powerpc/cpu/mpc85xx/start.S
> index 5440bf5..2b2c4dd 100644
> --- a/arch/powerpc/cpu/mpc85xx/start.S
> +++ b/arch/powerpc/cpu/mpc85xx/start.S
> @@ -116,6 +116,64 @@ _start_e500:
>   mtspr   SPRN_HDBCR0, r3
>  #endif
>  
> +#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_E500) && \
> + !defined(CONFIG_E500MC)

CONFIG_E500 can be assumed in this file.

> + /* ISBC creates a LAW 0 entry for non PBL platforms,
> +  * which is not disabled before transferring the control to uboot.
> +  * Disable the LAW 0 entry here.
> +  */

Could you explain what this LAW 0 entry is for, why we don't need it,
and why we can't wait until later to clear it?

-Scott


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

Re: [U-Boot] [PATCH 2/3] powerpc/p1010rdb: SECURE BOOT- enable workaround for IFC errata A003399

[Scott Wood]

On Mon, 2014-01-20 at 14:57 +0530, Aneesh Bansal wrote:
> The workaround for IFC errata A003399 was not enabled
> in case of secure boot. So, secure boot from NOR was not
> working.
> 
> Signed-off-by: Aneesh Bansal 
> ---
>  include/configs/P1010RDB.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
> index c21cf07..b0e51fb 100644
> --- a/include/configs/P1010RDB.h
> +++ b/include/configs/P1010RDB.h
> @@ -455,8 +455,7 @@ extern unsigned long get_sdram_size(void);
>  #endif
>  
>  #ifdef CONFIG_SYS_FSL_ERRATUM_IFC_A003399
> -#if !defined(CONFIG_SPL) && !defined(CONFIG_SYS_RAMBOOT)\
> - && !defined(CONFIG_SECURE_BOOT)
> +#if !defined(CONFIG_SPL) && !defined(CONFIG_SYS_RAMBOOT)
>  #define CONFIG_A003399_NOR_WORKAROUND
>  #endif
>  #endif

Why do you need the workaround?  Doesn't secure boot involve the bootrom
loading U-Boot into SRAM, rather than execute-in-place from NOR?

-Scott


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

Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot

[Scott Wood]

On Mon, 2014-01-20 at 14:55 +0530, Aneesh Bansal wrote:
> In case of secure boot, boot from NAND is ramboot.
> It was removed by some other commit. So defining it again.

In case of not-secure-boot, it's not ramboot.

What user of CONFIG_SYS_RAMBOOT are you concerned about?  Many of them
look like this:

#elif !defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SECURE_BOOT)

...which doesn't make sense if secure boot is always considered ramboot.

-Scott


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

Re: [U-Boot] Help

[Jeroen Hofstee]

Hello Raheel,

On 01/20/2014 09:37 PM, Moon Moon wrote:

Hello Sir,
 I have a development board smdk6400.When i switch on my 
power my lcd shows only white colour.and nothing boot please help me.
   


1) don't turn it on, that should solve all issues
2) have a look at doc/README.scrapyard

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

[U-Boot] Help

[Moon Moon]

Hello Sir,
                    I have a development board smdk6400.When i switch on my 
power my lcd shows only white colour.and nothing boot please help me.
                                                                                
                                                                                
                Thanks,
                                                                                
                                                                                
                Raheel___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH REPOST4 1/2] ARM: rpi_b: power on SDHCI and USB HW modules

[Stephen Warren]

On 01/13/2014 07:50 PM, Stephen Warren wrote:
> Send RPC commands to the VideoCore to turn on the SDHCI and USB modules.
> For SDHCI this isn't needed in practice, since the firmware already
> turned on the power in order to load U-Boot. However, it's best to be
> explicit. For USB, this is necessary, since the module isn't powered
> otherwise. This will allow the kernel USB driver to work.
> 
> Signed-off-by: Stephen Warren 
> ---
> Could this please be applied for v2014.01? I know I did first post it
> after the merge window closed (by just a few hours...) but there's always
> plenty of other stuff that's accepted under similar timing.

Albert, sorry for responding to the patch rather than your mail, but for
some reason I didn't get your response on Jan 14 where you wrote:

> I'm not against taking this in as this affects only a single board (and
> provided Tom is OK too).

Tom, is this patch OK?

> Also, I'd really like to know whether the three reposts are actually
> versions (in which case I'd have liked a version history, even limited
> to "vN: rebase" if such is the case) or pings (in which case I'd prefer
> "ping?" replies, as these replies do not create patch entries in
> patchwork).

It's the same patch, with no changes. I reposted since there was no
response, so figured it must have been lost.

In other cases where I sent pings in replies to the patch, I was asked
to repost the patch instead. Admittedly the particular case I'm thinking
of here was Linux kernel patches, but the process ought to be the same;
it's hard on submitters to have to remember some table of
maintainer/project -> ping/repost style and similar things:-(
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-spi/master

[Jagan Teki]

Hi Marek,

Waited your response since last couple of hours.!

On Tue, Jan 21, 2014 at 1:07 AM, Marek Vasut  wrote:
> On Monday, January 20, 2014 at 06:53:58 PM, Jagannadha Sutradharudu Teki 
> wrote:
>> Hi Tom,
>>
>> SF code optimized stuff and few fixes.
>>
>> --
>> Thanks,
>> Jagan.
>>
>> The following changes since commit
>> 5c9038b6af1a93410af966999638eabb81efcd0f:
>>
>>   omap3_beagle: use omap3-beagle.dtb for the C4 revision (2014-01-17
>> 11:03:04 -0500)
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-spi.git master
>>
>> for you to fetch changes up to 83ba605953162443b054d5ad60535468b46558bd:
>>
>>   sf: Update bank configuration (2014-01-20 22:30:35 +0530)
>>
>> 
>> Jagannadha Sutradharudu Teki (5):
>>   sf: ops: Squash the malloc+memset combo
Agree this for -next

>>   sf: Optimize flash features code
>>   sf: Use mode_bits for dual_flash connection
>>   doc: SPI: Update the dual_flash info
>>   sf: Update bank configuration
>
> This is for -next.

Better to keep this in release - as code optimized at-least for
current framework, I'm OK with this.

>
>> Marek Vasut (3):
>>   sf: Squash the malloc+memset combo
>
> This is definitelly for -next.
>
>>   sf: Fix entries for S25FL256S_256K and S25FL512S_256K
>
> This is the only one I would let into current , since it's an actual bugfix .
> The rest are just adjustments.
>
>>   sf: Add S25FL128S_256K IDs
>
> This is an adjustment, can wait for -next.
>
>>
>>  doc/SPI/README.dual-flash |   5 +-
>>  doc/SPI/README.sf-features| 125 ++
>>  drivers/mtd/spi/sf.c  |   4 +-
>>  drivers/mtd/spi/sf_internal.h |   1 -
>>  drivers/mtd/spi/sf_ops.c  |  16 ++--
>>  drivers/mtd/spi/sf_params.c   | 171
>> +- drivers/mtd/spi/sf_probe.c|
>> 104 -
>>  include/spi.h |  42 ---
>>  include/spi_flash.h   |  24 +++---
>>  9 files changed, 301 insertions(+), 191 deletions(-)
>>  create mode 100644 doc/SPI/README.sf-features

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

Re: [U-Boot] Pull request: u-boot-spi/master

[Marek Vasut]

On Monday, January 20, 2014 at 06:53:58 PM, Jagannadha Sutradharudu Teki wrote:
> Hi Tom,
> 
> SF code optimized stuff and few fixes.
> 
> --
> Thanks,
> Jagan.
> 
> The following changes since commit
> 5c9038b6af1a93410af966999638eabb81efcd0f:
> 
>   omap3_beagle: use omap3-beagle.dtb for the C4 revision (2014-01-17
> 11:03:04 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 83ba605953162443b054d5ad60535468b46558bd:
> 
>   sf: Update bank configuration (2014-01-20 22:30:35 +0530)
> 
> 
> Jagannadha Sutradharudu Teki (5):
>   sf: ops: Squash the malloc+memset combo
>   sf: Optimize flash features code
>   sf: Use mode_bits for dual_flash connection
>   doc: SPI: Update the dual_flash info
>   sf: Update bank configuration

This is for -next.

> Marek Vasut (3):
>   sf: Squash the malloc+memset combo

This is definitelly for -next.

>   sf: Fix entries for S25FL256S_256K and S25FL512S_256K

This is the only one I would let into current , since it's an actual bugfix . 
The rest are just adjustments.

>   sf: Add S25FL128S_256K IDs

This is an adjustment, can wait for -next.

> 
>  doc/SPI/README.dual-flash |   5 +-
>  doc/SPI/README.sf-features| 125 ++
>  drivers/mtd/spi/sf.c  |   4 +-
>  drivers/mtd/spi/sf_internal.h |   1 -
>  drivers/mtd/spi/sf_ops.c  |  16 ++--
>  drivers/mtd/spi/sf_params.c   | 171
> +- drivers/mtd/spi/sf_probe.c|
> 104 -
>  include/spi.h |  42 ---
>  include/spi_flash.h   |  24 +++---
>  9 files changed, 301 insertions(+), 191 deletions(-)
>  create mode 100644 doc/SPI/README.sf-features

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] booting os 'Unknown OS' (1) is not supported

[Wolfgang Denk]

Dear Alexander,

In message  
you wrote:
>
> link to my u-boot https://github.com/fedya/u-boot-yse5250

Sorry, but I do not really care about out of tree code.

> Changed to this
> bootcmd=md 4080 10;imi 4080;bootm 4080

OK, lets's go through this step by step.

Note that
> [YSE5250@omv]# boot
> 4080: 56190527 ba6b0d61 9850d952 08484800'..Va.k.R.P..HH.
> 40800010: 00800040 00800040 8a221c4c 00020205@...@...L.".
> 40800020: 756e694c 2e332d78 302e3331 3863722dLinux-3.13.0-rc8
> 40800030:    

The header (struct image_header) is defined in "include/image.h".  we
have:

237 typedef struct image_header {
238 __be32  ih_magic;   /* Image Header Magic Number*/
56190527 => 0x27051956 OK
239 __be32  ih_hcrc;/* Image Header CRC Checksum*/
ba6b0d61
240 __be32  ih_time;/* Image Creation Timestamp */
9850d952 => 0x52d95098 = 1389973656 = Fri Jan 17 16:47:36 2014
241 __be32  ih_size;/* Image Data Size  */
08484800 => 0x00484808 = 4737032
242 __be32  ih_load;/* Data  Load  Address  */
00800040 = 0x40008000 OK
243 __be32  ih_ep;  /* Entry Point Address  */
00800040 = 0x40008000 OK
244 __be32  ih_dcrc;/* Image Data CRC Checksum  */
8a221c4c
245 uint8_t ih_os;  /* Operating System */
05 = IH_OS_LINUX OK
246 uint8_t ih_arch;/* CPU architecture */
02 = IH_ARCH_ARM OK
247 uint8_t ih_type;/* Image Type   */
02 = IH_TYPE_KERNEL OK
248 uint8_t ih_comp;/* Compression Type */
00 = IH_COMP_NONE OK
249 uint8_t ih_name[IH_NMLEN];  /* Image Name   */
Linux-3.13.0-rc8
250 } image_header_t;

This all looks perfectly OK to me.

> ## Checking Image at 4080 ...
>Legacy image found
>Image Name:   Linux-3.13.0-rc8
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4737032 Bytes = 4626 KiB
>Load Address: 40008000
>Entry Point:  40008000
>Verifying Checksum ... OK

This is the "iminfo" output. All looks perfectly fine. Note
especially that the image gets correctly decoded as "ARM Linux Kernel
Image (uncompressed)".

> ## Booting kernel from Legacy Image at 4080 ...
>Image Name:   Linux-3.13.0-rc8
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4737032 Bytes = 4626 KiB
>Load Address: 40008000
>Entry Point:  40008000
>Verifying Checksum ... OK

This is the regular "bootm" image output. So far it looks perfectly
fine.

>kernel data at 0x40800040, len = 0x00484808 (4737032)
> ## No init Ramdisk
>ramdisk start = 0x, ramdisk end = 0x
>Loading Kernel Image ... OK
> OK
>kernel loaded at 0x40008000, end = 0x4048c808

0x40008000 + 0x00484808 (size) = 0x4048c808 ==> looks perfectly fine,
too, and is far enough away from your load address at 4080

> ERROR: booting os 'Unknown OS' (1) is not supported

This code comes from "common/cmd_bootm.c":

 691 if (boot_fn == NULL && need_boot_fn) {
 692 if (iflag)
 693 enable_interrupts();
 694 printf("ERROR: booting os '%s' (%d) is not supported\n",
 695genimg_get_os_name(images->os.os), images->os.os);
...

images->os.os has the value 1 here, not the expected 5 (IH_OS_LINUX)
we had before.  Somenting must have overwritten the header
information / parts of your RAM.

> >movi
> string from help
> 
> movi- movi  - sd/mmc r/w sub system for SMDK board
> 
> and same command for o-droid
> http://lists.denx.de/pipermail/u-boot/2013-February/146047.html

I have not the lightest idea why they would invent something new
instead of what is being used in mainline.


I have no idea where your memory gets corrupted, or why, and with
out-of-tree code it's difficult to even guess.  But there is a good
chance that parts of your code base are simply broken.

If I were you, I would run this code under control of GDB (with a
JTAG debugger attached).  Then set a watchpoint on the images.os.os
address and check where it gets corrupted.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I must follow the people.  Am I not their leader? - Benjamin Disraeli
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How to perform a secure boot on ARM Linux

[Marek Vasut]

On Monday, January 20, 2014 at 01:40:52 PM, rakesh ranjan wrote:
> Hi,
> 
> I have a beagle board and want to create a u-boot that verifies the kernel
> and rootfs before booting it. Any pointers on how it can be achieved will
> be appreciated.
> 
> Rakesh

See doc/uImage.FIT/verified-boot.txt and doc/uImage.FIT/signature.txt in the 
source tree .

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How to perform a secure boot on ARM Linux

[Jagan Teki]

On Mon, Jan 20, 2014 at 8:46 PM, Detlev Zundel  wrote:
> Hi Rakesh,
>
>> I have a beagle board and want to create a u-boot that verifies the kernel
>> and rootfs before booting it. Any pointers on how it can be achieved will
>> be appreciated.
>
> You can start here by reading the provided documentation:
>
> http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt;hb=HEAD
>
> There's also a ELCE 2013 presentation by Simon Glass:
>
> http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf
>
> And a paper by Jagan Teki from the U-Boot Mini Summit
>
> http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/U-Boot_verified_RSA_boot_flow_on_arm_target.pdf
>
> The mailing list is surely the right place for further questions ;)

One more paper to Detlev pointers!
http://www.denx.de/wiki/pub/U-Boot/OpenSourceIndia2013/Multi_image_booting_scenarios.pdf

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

[U-Boot] Pull request: u-boot-spi/master

[Jagannadha Sutradharudu Teki]

Hi Tom,

SF code optimized stuff and few fixes.

--
Thanks,
Jagan.

The following changes since commit 5c9038b6af1a93410af966999638eabb81efcd0f:

  omap3_beagle: use omap3-beagle.dtb for the C4 revision (2014-01-17 11:03:04 
-0500)

are available in the git repository at:

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

for you to fetch changes up to 83ba605953162443b054d5ad60535468b46558bd:

  sf: Update bank configuration (2014-01-20 22:30:35 +0530)


Jagannadha Sutradharudu Teki (5):
  sf: ops: Squash the malloc+memset combo
  sf: Optimize flash features code
  sf: Use mode_bits for dual_flash connection
  doc: SPI: Update the dual_flash info
  sf: Update bank configuration

Marek Vasut (3):
  sf: Squash the malloc+memset combo
  sf: Fix entries for S25FL256S_256K and S25FL512S_256K
  sf: Add S25FL128S_256K IDs

 doc/SPI/README.dual-flash |   5 +-
 doc/SPI/README.sf-features| 125 ++
 drivers/mtd/spi/sf.c  |   4 +-
 drivers/mtd/spi/sf_internal.h |   1 -
 drivers/mtd/spi/sf_ops.c  |  16 ++--
 drivers/mtd/spi/sf_params.c   | 171 +-
 drivers/mtd/spi/sf_probe.c| 104 -
 include/spi.h |  42 ---
 include/spi_flash.h   |  24 +++---
 9 files changed, 301 insertions(+), 191 deletions(-)
 create mode 100644 doc/SPI/README.sf-features


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

[U-Boot] [PATCH] Revert "fdt_support: 64bit initrd start address support"

[Otavio Salvador]

This reverts commit f77a606a0602be5d1fe23e8dcdfa5defde51dfd7 as it
breaks 32bit initrd use as it uses #address-cells as '2'.

Signed-off-by: Otavio Salvador 
---
 common/fdt_support.c | 66 +---
 1 file changed, 32 insertions(+), 34 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index b9dce99..4e32b02 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -21,34 +21,6 @@
  */
 DECLARE_GLOBAL_DATA_PTR;
 
-/*
- * Get cells len in bytes
- * if #-cells property is 2 then len is 8
- * otherwise len is 4
- */
-static int get_cells_len(void *blob, char *nr_cells_name)
-{
-   const fdt32_t *cell;
-
-   cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
-   if (cell && fdt32_to_cpu(*cell) == 2)
-   return 8;
-
-   return 4;
-}
-
-/*
- * Write a 4 or 8 byte big endian cell
- */
-static void write_cell(u8 *addr, u64 val, int size)
-{
-   int shift = (size - 1) * 8;
-   while (size-- > 0) {
-   *addr++ = (val >> shift) & 0xff;
-   shift -= 8;
-   }
-}
-
 /**
  * fdt_getprop_u32_default - Find a node and return it's property or a default
  *
@@ -159,9 +131,9 @@ static int fdt_fixup_stdout(void *fdt, int chosenoff)
 
 int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end, int force)
 {
-   int   nodeoffset, addr_cell_len;
+   int   nodeoffset;
int   err, j, total;
-   fdt64_t  tmp;
+   fdt32_t  tmp;
const char *path;
uint64_t addr, size;
 
@@ -198,11 +170,9 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
initrd_end, int force)
return err;
}
 
-   addr_cell_len = get_cells_len(fdt, "#address-cells");
-
path = fdt_getprop(fdt, nodeoffset, "linux,initrd-start", NULL);
if ((path == NULL) || force) {
-   write_cell((u8 *)&tmp, initrd_start, addr_cell_len);
+   tmp = cpu_to_fdt32(initrd_start);
err = fdt_setprop(fdt, nodeoffset,
"linux,initrd-start", &tmp, sizeof(tmp));
if (err < 0) {
@@ -211,7 +181,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
initrd_end, int force)
fdt_strerror(err));
return err;
}
-   write_cell((u8 *)&tmp, initrd_end, addr_cell_len);
+   tmp = cpu_to_fdt32(initrd_end);
err = fdt_setprop(fdt, nodeoffset,
"linux,initrd-end", &tmp, sizeof(tmp));
if (err < 0) {
@@ -373,6 +343,34 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, &tmp, 4, create);
 }
 
+/*
+ * Get cells len in bytes
+ * if #-cells property is 2 then len is 8
+ * otherwise len is 4
+ */
+static int get_cells_len(void *blob, char *nr_cells_name)
+{
+   const fdt32_t *cell;
+
+   cell = fdt_getprop(blob, 0, nr_cells_name, NULL);
+   if (cell && fdt32_to_cpu(*cell) == 2)
+   return 8;
+
+   return 4;
+}
+
+/*
+ * Write a 4 or 8 byte big endian cell
+ */
+static void write_cell(u8 *addr, u64 val, int size)
+{
+   int shift = (size - 1) * 8;
+   while (size-- > 0) {
+   *addr++ = (val >> shift) & 0xff;
+   shift -= 8;
+   }
+}
+
 #ifdef CONFIG_NR_DRAM_BANKS
 #define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
 #else
-- 
1.8.5.2

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

[U-Boot] [PATCH v3] sf: Update bank configuration

[Jagannadha Sutradharudu Teki]

Updated bank configuration code to more readable.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
Changes for v3:
- remove  bank_curr = 0 for non bank case
Changes for v2:
- none

 drivers/mtd/spi/sf_probe.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index a5f3046..53995e4 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -217,21 +217,22 @@ static struct spi_flash *spi_flash_validate_params(struct 
spi_slave *spi,
 
/* Configure the BAR - discover bank cmds and read current bank */
 #ifdef CONFIG_SPI_FLASH_BAR
-   u8 curr_bank = 0;
if (flash->size > SPI_FLASH_16MB_BOUN) {
-   flash->bank_read_cmd = (idcode[0] == 0x01) ?
-   CMD_BANKADDR_BRRD : CMD_EXTNADDR_RDEAR;
-   flash->bank_write_cmd = (idcode[0] == 0x01) ?
-   CMD_BANKADDR_BRWR : CMD_EXTNADDR_WREAR;
+   switch (idcode[0]) {
+   case SPI_FLASH_CFI_MFR_SPANSION:
+   flash->bank_read_cmd = CMD_BANKADDR_BRRD;
+   flash->bank_write_cmd = CMD_BANKADDR_BRWR;
+   break;
+   default:
+   flash->bank_read_cmd = CMD_EXTNADDR_RDEAR;
+   flash->bank_write_cmd = CMD_EXTNADDR_WREAR;
+   }
 
if (spi_flash_read_common(flash, &flash->bank_read_cmd, 1,
- &curr_bank, 1)) {
-   debug("SF: fail to read bank addr register\n");
+   &flash->bank_curr, 1)) {
+   debug("SF: Fail to read bank addr register\n");
return NULL;
}
-   flash->bank_curr = curr_bank;
-   } else {
-   flash->bank_curr = curr_bank;
}
 #endif
 
-- 
1.8.3


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

[U-Boot] [PATCH v3] sf: ops: Squash the malloc+memset combo

[Jagannadha Sutradharudu Teki]

Squash the malloc()+memset() combo in favor of calloc().

Signed-off-by: Jagannadha Sutradharudu Teki 
---
Changes for v3:
- Use errno.h
Changes for v2:
- used debug()

 drivers/mtd/spi/sf_ops.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 1f1bb36..ef91b92 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -381,8 +382,11 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
}
 
cmdsz = SPI_FLASH_CMD_LEN + flash->dummy_byte;
-   cmd = malloc(cmdsz);
-   memset(cmd, 0, cmdsz);
+   cmd = calloc(1, cmdsz);
+   if (!cmd) {
+   debug("SF: Failed to allocate cmd\n");
+   return -ENOMEM;
+   }
 
cmd[0] = flash->read_cmd;
while (len) {
-- 
1.8.3


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

[U-Boot] [PATCH] doc: README: Correct file name of signature verification documentation

[Detlev Zundel]

Signed-off-by: Detlev Zundel 
---
 README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README b/README
index aea82be..edf5fe4 100644
--- a/README
+++ b/README
@@ -2832,7 +2832,7 @@ CBFS (Coreboot Filesystem) support
CONFIG_RSA
 
This enables the RSA algorithm used for FIT image verification
-   in U-Boot. See doc/uImage/signature for more information.
+   in U-Boot. See doc/uImage.FIT/signature.txt for more 
information.
 
The signing part is build into mkimage regardless of this
option.
-- 
1.8.3.1

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

Re: [U-Boot] How to perform a secure boot on ARM Linux

[Detlev Zundel]

Hi Rakesh,

> I have a beagle board and want to create a u-boot that verifies the kernel
> and rootfs before booting it. Any pointers on how it can be achieved will
> be appreciated.

You can start here by reading the provided documentation:

http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt;hb=HEAD

There's also a ELCE 2013 presentation by Simon Glass:

http://events.linuxfoundation.org/sites/events/files/slides/chromeos_and_diy_vboot_0.pdf

And a paper by Jagan Teki from the U-Boot Mini Summit

http://www.denx.de/wiki/pub/U-Boot/MiniSummitELCE2013/U-Boot_verified_RSA_boot_flow_on_arm_target.pdf

The mailing list is surely the right place for further questions ;)

Cheers
  Detlev

-- 
There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/5] sf: ops: Squash the malloc+memset combo

[Jagan Teki]

On Mon, Jan 20, 2014 at 8:17 PM, Fabio Estevam  wrote:
> On Mon, Jan 20, 2014 at 12:40 PM, Jagan Teki  wrote:
>>> Shouldn't you return -ENOMEM instead?
>>
>> Yes - we can but anyway ret is -1 by default.
>> and sf code doesn't use -ve macros' as of now.
>
> -1 is not an propriate return error value in this case.

Yes it should be -11 - then we need to use -ENOMEM

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

Re: [U-Boot] [PATCH v2 1/5] sf: ops: Squash the malloc+memset combo

[Fabio Estevam]

On Mon, Jan 20, 2014 at 12:40 PM, Jagan Teki  wrote:
>> Shouldn't you return -ENOMEM instead?
>
> Yes - we can but anyway ret is -1 by default.
> and sf code doesn't use -ve macros' as of now.

-1 is not an propriate return error value in this case.

Regards,

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

Re: [U-Boot] [PATCH v2 1/5] sf: ops: Squash the malloc+memset combo

[Jagan Teki]

On Mon, Jan 20, 2014 at 8:05 PM, Fabio Estevam  wrote:
> On Mon, Jan 20, 2014 at 12:29 PM, Jagannadha Sutradharudu Teki
>  wrote:
>> Squash the malloc()+memset() combo in favor of calloc().
>>
>> Signed-off-by: Jagannadha Sutradharudu Teki 
>> Cc: Marek Vasut 
>> ---
>>  drivers/mtd/spi/sf_ops.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
>> index 1f1bb36..abdb0ef 100644
>> --- a/drivers/mtd/spi/sf_ops.c
>> +++ b/drivers/mtd/spi/sf_ops.c
>> @@ -381,8 +381,11 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
>> offset,
>> }
>>
>> cmdsz = SPI_FLASH_CMD_LEN + flash->dummy_byte;
>> -   cmd = malloc(cmdsz);
>> -   memset(cmd, 0, cmdsz);
>> +   cmd = calloc(1, cmdsz);
>> +   if (!cmd) {
>> +   debug("SF: Failed to allocate cmd\n");
>> +   return ret;
>
> Shouldn't you return -ENOMEM instead?

Yes - we can but anyway ret is -1 by default.
and sf code doesn't use -ve macros' as of now.

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

Re: [U-Boot] [PATCH v2 1/5] sf: ops: Squash the malloc+memset combo

[Fabio Estevam]

On Mon, Jan 20, 2014 at 12:29 PM, Jagannadha Sutradharudu Teki
 wrote:
> Squash the malloc()+memset() combo in favor of calloc().
>
> Signed-off-by: Jagannadha Sutradharudu Teki 
> Cc: Marek Vasut 
> ---
>  drivers/mtd/spi/sf_ops.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
> index 1f1bb36..abdb0ef 100644
> --- a/drivers/mtd/spi/sf_ops.c
> +++ b/drivers/mtd/spi/sf_ops.c
> @@ -381,8 +381,11 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
> offset,
> }
>
> cmdsz = SPI_FLASH_CMD_LEN + flash->dummy_byte;
> -   cmd = malloc(cmdsz);
> -   memset(cmd, 0, cmdsz);
> +   cmd = calloc(1, cmdsz);
> +   if (!cmd) {
> +   debug("SF: Failed to allocate cmd\n");
> +   return ret;

Shouldn't you return -ENOMEM instead?

Regards,

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

Re: [U-Boot] [PATCH 4/6] sf: Update read/write command macros

[Detlev Zundel]

Hi Jagan,

[...]

> I don't think nothing much gone the readability with these updated:
> CMD_READ_ARRAY_FAST has updated CMD_RD_FAST and it seems like easy to
> understand. and anyway I have added comments for full name as well.

Comments in a far away place cannot compensate for self-explaining
constructs at the location where they are used.  Stating that a
constants needs comments to explain it is actually a good sign that its
name is not chosen carefully enough.

Really, naming constants and variables for readable and maintainable
code is a much harder problem than it looks (cf. my signature) and
unfortunately not easily measurable.  But I assure you that good names
can make a world of a difference.  That's why Marek and me are so
passionate about this seemingly "trivial" change.

> Few of the flashes can be call this as array fast read and fewer call
> this as fast read and few more call this as high frequency
> read. CMD_RD_FAST will suits all these names.
>
> Comments please!

When we change code, we don't do this for the sake of changing it, but
in order to improve one aspect of it, i.e. the performance, the
maintainability or the features.  When everything "stays the same", we
are even _opposed_ to a change because there is nothing to outweigh the
effort to adjusting to the new things.

To summarize - we need proof that a change _improves_ something.
Showing that we "do not loose something" is clearly not enough.

Now in this specific case, we have multiple people voicing the concern
that the renaming looses vital information, thus effectively making
reading and maintining the code harder.  On the other hand even you
agree that "something" although "not much" will be gone after the
rename.  So taking this into account we have only "saving of a few
keystorkes" on the positive side and substantial degradation on
readability and maintainability on the negative side.

Best wishes
  Detlev

-- 
There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/5] sf: ops: Squash the malloc+memset combo

[Jagannadha Sutradharudu Teki]

Squash the malloc()+memset() combo in favor of calloc().

Signed-off-by: Jagannadha Sutradharudu Teki 
Cc: Marek Vasut 
---
 drivers/mtd/spi/sf_ops.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 1f1bb36..abdb0ef 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -381,8 +381,11 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
}
 
cmdsz = SPI_FLASH_CMD_LEN + flash->dummy_byte;
-   cmd = malloc(cmdsz);
-   memset(cmd, 0, cmdsz);
+   cmd = calloc(1, cmdsz);
+   if (!cmd) {
+   debug("SF: Failed to allocate cmd\n");
+   return ret;
+   }
 
cmd[0] = flash->read_cmd;
while (len) {
-- 
1.8.3


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

[U-Boot] [PATCH v2 3/5] sf: Use mode_bits for dual_flash connection

[Jagannadha Sutradharudu Teki]

SF uses mode_bits from driver side for informing whether
flash can operated in single or dual connections.

Signed-off-by: Jagannadha Sutradharudu Teki 
Cc: Marek Vasut 
---
 drivers/mtd/spi/sf_probe.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index abde69b..a5f3046 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -123,7 +123,6 @@ static struct spi_flash *spi_flash_validate_params(struct 
spi_slave *spi,
flash->spi = spi;
flash->name = params->name;
flash->memory_map = spi->memory_map;
-   flash->dual_flash = flash->spi->option;
 
/* Assign spi_flash ops */
flash->read = spi_flash_cmd_read_ops;
@@ -133,7 +132,13 @@ static struct spi_flash *spi_flash_validate_params(struct 
spi_slave *spi,
if (params->flags & SST_WP)
flash->write = sst_write_wp;
 #endif
-
+   /* Get the dual flash connection modes */
+#ifdef CONFIG_SF_DUAL_FLASH
+   if (flash->spi->mode_bits & SPI_SHARED)
+   flash->dual_flash = SF_DUAL_STACKED_FLASH;
+   else if (flash->spi->mode_bits & SPI_SEPARATED)
+   flash->dual_flash = SF_DUAL_PARALLEL_FLASH;
+#endif
/* Compute the flash size */
flash->shift = (flash->dual_flash & SF_DUAL_PARALLEL_FLASH) ? 1 : 0;
flash->page_size = ((ext_jedec == 0x4d00) ? 512 : 256) << flash->shift;
-- 
1.8.3


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

[U-Boot] [PATCH v2 2/5] sf: Optimize flash features code

[Jagannadha Sutradharudu Teki]

From: Jagannadha Sutradharudu Teki 

- Shrink spi_slave {}
- Shrink spi_flash_params {}
- Documentation for sf features

Signed-off-by: Jagannadha Sutradharudu Teki 
Cc: Marek Vasut 
---
 doc/SPI/README.sf-features| 122 ++
 drivers/mtd/spi/sf.c  |   4 +-
 drivers/mtd/spi/sf_internal.h |   1 -
 drivers/mtd/spi/sf_ops.c  |   8 +-
 drivers/mtd/spi/sf_params.c   | 172 +-
 drivers/mtd/spi/sf_probe.c|  71 -
 include/spi.h |  42 ---
 include/spi_flash.h   |  24 +++---
 8 files changed, 270 insertions(+), 174 deletions(-)
 create mode 100644 doc/SPI/README.sf-features

diff --git a/doc/SPI/README.sf-features b/doc/SPI/README.sf-features
new file mode 100644
index 000..d35f56d
--- /dev/null
+++ b/doc/SPI/README.sf-features
@@ -0,0 +1,122 @@
+SPI FLASH feature enhancements:
+==
+
+This document describes how to extend the current data structures in spi 
subsystem
+for making use of new flash features/operations w.r.t to controller driver 
support.
+
+1. spi_slave:
+
+struct spi_slave {
+..
+u32 mode_bits;
+
+};
+
+@mode_bits can be used to expose the SPI RX/TX operation modes, bus options and
+few flags which are used to extended the flash specific features/operations
+- include/spi.h
+
+mode_bits:
+- SPI_TX_QPP: 4-Wire tx transfer operation quad page program
+- SPI_RX_SLOW: 1-wire rx transfer operation array slow read
+- SPI_RX_DUAL: 2-wire rx transfer operation dual fast read
+- SPI_RX_DUAL_IO: 2-wire rx transfer operation dual io fast read
+- SPI_RX_QUAD: 4-wire rx transfer operation quad fast read
+- SPI_RX_QUAD_IO: 4-wire rx transfer operation quad io fast read
+- SPI_SHARED: dual flash devices are connected in shared bus connection
+- SPI_SEPARATED: dual flash devices are connected in separate bus connection
+- SPI_U_PAGE: select the upper flash in dual flash shared bus connection [1]
+
+2. spi_flash_params:
+
+struct spi_flash_params {
+
+u16 flags;
+..
+};
+
+@flags can be use to verify the flash supported features/operations with 
respect
+to controller driven through @mode_bits and also some internal flash specific
+operations - include/spi_flash.h
+
+flags:
+- SST_WP: SST flash write protection
+- SECT_4K: 4K erase sector
+- SECT_32K: 32 erase sector
+- E_FSR: Flag status register for erase/write for micron < 256MB flash
+- WR_QPP: Quad page program
+- RD_SLOW: Array slow read
+- RD_DUAL: Dual fast read
+- RD_DUAL_IO: Dual IO read
+- RD_QUAD: Quad fast read
+- RD_QUAD_IO: Quad IO read
+- RD_2WIRE: All 2-wire read commands
+- RD_FULL: All read commands
+- ALL_CMDS: All read and write commands [2]
+
+3. spi_flash:
+
+struct spi_flash {
+...
+   u8 dual_flash;
+u8 shift;
+   u8 poll_cmd;
+u8 erase_cmd;
+u8 read_cmd;
+u8 write_cmd;
+u8 dummy_byte;
+
+};
+
+Few varibles from spi_flash {} can be used to perform the internal operations
+based on the selected flash features/operations from spi_slave {} and
+spi_flash_params {} - include/spi_flash.h
+
+@dual_flash: flash can be operated in dual flash [3]
+@shift: variable shift operator useful for dual parallel
+@poll_cmd: find the read_status or flag_status for polling erase/write 
operations
+@erase_cmd: discovered erase command
+@read_cmd: discovered read command
+@write_cmd: discovered write command
+@dummy_byte: read dummy_byte based on read dummy_cycles.
+
+dummy byte is determined based on the dummy cycles of a particular command.
+Fast commands - dummy_byte = dummy_cycles/8
+I/O commands- dummy_byte = (dummy_cycles * no.of lines)/8
+For I/O commands except cmd[0] everything goes on no.of lines based on
+particular command but in case of fast commands except data all go on
+single line irrespective of command.
+
+4. Usage:
+
+In drivers/spi/*.c assign spi_slave {} with supported features through 
mode_bits.
+Ex: drivers/spi/ti_qspi.c
+
+struct ti_qspi_slave {
+   
+   struct spi_slave slave;
+   ..
+}
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+  unsigned int max_hz, unsigned int mode)
+{
+   .
+
+   qslave = spi_alloc_slave(struct ti_qspi_slave, bus, cs);
+   if (!qslave) {
+   printf("SPI_error: Fail to allocate ti_qspi_slave\n");
+   return NULL;
+   }
+
+   qslave->slave.mode_bits = SPI_TX_QPP | SPI_RX_QUAD;
+   
+}
+
+[1] 
http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
+[2] http://www.spansion.com/Support/Datasheets/S25FL128S_256S_00.pdf
+[3] doc/SPI/README.dual-flash
+
+--
+Jagannadha Sutradharudu Teki 
+Sat Jan 18 14:44:28 IST 2014
diff --git a/drivers/mtd/spi/sf.c b/drivers/mtd/spi/sf.c
index 664e860..fb91ac6 100644
--- a/drivers/mtd/spi/sf.

[U-Boot] [PATCH v2 0/5] sf: Optimize spi_flash features code

[Jagannadha Sutradharudu Teki]

Shrinked spi_slave and spi_flash code with respect to added
flash features.

Jagannadha Sutradharudu Teki (5):
  sf: ops: Squash the malloc+memset combo
  sf: Optimize flash features code
  sf: Use mode_bits for dual_flash connection
  doc: SPI: Update the dual_flash info
  sf: Update bank configuration

 doc/SPI/README.dual-flash |   5 +-
 doc/SPI/README.sf-features| 125 ++
 drivers/mtd/spi/sf.c  |   4 +-
 drivers/mtd/spi/sf_internal.h |   1 -
 drivers/mtd/spi/sf_ops.c  |  15 ++--
 drivers/mtd/spi/sf_params.c   | 172 +-
 drivers/mtd/spi/sf_probe.c| 102 -
 include/spi.h |  42 ---
 include/spi_flash.h   |  24 +++---
 9 files changed, 300 insertions(+), 190 deletions(-)
 create mode 100644 doc/SPI/README.sf-features

-- 
1.8.3


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

[U-Boot] [PATCH v2 4/5] doc: SPI: Update the dual_flash info

[Jagannadha Sutradharudu Teki]

Updated the dual_flash documentation as it uses
mode_bits from spi drivers to inform the sf framework.

Signed-off-by: Jagannadha Sutradharudu Teki 
Cc: Marek Vasut 
---
 doc/SPI/README.dual-flash  | 5 +++--
 doc/SPI/README.sf-features | 3 +++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/doc/SPI/README.dual-flash b/doc/SPI/README.dual-flash
index 6c88d65..05b875f 100644
--- a/doc/SPI/README.dual-flash
+++ b/doc/SPI/README.dual-flash
@@ -9,7 +9,8 @@ to a given controller with single chip select line, but there 
are some
 hw logics(ex: xilinx zynq qspi) that describes two/dual memories are
 connected with a single chip select line from a controller.
 
-"dual_flash" from include/spi.h describes these types of connection mode
+"dual_flash" from include/spi_flash.h describes these types of connection mode
+in spi flash side and "mode_bits" options for controller driver.
 
 Possible connections:
 
@@ -54,7 +55,7 @@ SF_DUAL_STACKED_FLASH:
by default, if U_PAGE is unset lower memory should accessible,
once user wants to access upper memory need to set U_PAGE.
 
-SPI_FLASH_CONN_DUALPARALLEL:
+SF_DUAL_PARALLEL_FLASH:
- dual spi/qspi flash memories are connected with a single chipselect
  line and these two memories are operating parallel with separate 
buses.
- xilinx zynq qspi controller has implemented this feature [1]
diff --git a/doc/SPI/README.sf-features b/doc/SPI/README.sf-features
index d35f56d..4047e95 100644
--- a/doc/SPI/README.sf-features
+++ b/doc/SPI/README.sf-features
@@ -73,6 +73,9 @@ based on the selected flash features/operations from 
spi_slave {} and
 spi_flash_params {} - include/spi_flash.h
 
 @dual_flash: flash can be operated in dual flash [3]
+- SF_SINGLE_FLASH: default connection single flash
+- SF_DUAL_STACKED_FLASH: dual flash with dual stacked connection
+- SF_DUAL_PARALLEL_FLASH: dual flash with dual parallel connection
 @shift: variable shift operator useful for dual parallel
 @poll_cmd: find the read_status or flag_status for polling erase/write 
operations
 @erase_cmd: discovered erase command
-- 
1.8.3


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

[U-Boot] [PATCH v2 5/5] sf: Update bank configuration

[Jagannadha Sutradharudu Teki]

Updated bank configuration code to more readable.

Signed-off-by: Jagannadha Sutradharudu Teki 
---
 drivers/mtd/spi/sf_probe.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index a5f3046..10d183d 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -217,21 +217,23 @@ static struct spi_flash *spi_flash_validate_params(struct 
spi_slave *spi,
 
/* Configure the BAR - discover bank cmds and read current bank */
 #ifdef CONFIG_SPI_FLASH_BAR
-   u8 curr_bank = 0;
+   flash->bank_curr = 0;
if (flash->size > SPI_FLASH_16MB_BOUN) {
-   flash->bank_read_cmd = (idcode[0] == 0x01) ?
-   CMD_BANKADDR_BRRD : CMD_EXTNADDR_RDEAR;
-   flash->bank_write_cmd = (idcode[0] == 0x01) ?
-   CMD_BANKADDR_BRWR : CMD_EXTNADDR_WREAR;
+   switch (idcode[0]) {
+   case SPI_FLASH_CFI_MFR_SPANSION:
+   flash->bank_read_cmd = CMD_BANKADDR_BRRD;
+   flash->bank_write_cmd = CMD_BANKADDR_BRWR;
+   break;
+   default:
+   flash->bank_read_cmd = CMD_EXTNADDR_RDEAR;
+   flash->bank_write_cmd = CMD_EXTNADDR_WREAR;
+   }
 
if (spi_flash_read_common(flash, &flash->bank_read_cmd, 1,
- &curr_bank, 1)) {
-   debug("SF: fail to read bank addr register\n");
+   &flash->bank_curr, 1)) {
+   debug("SF: Fail to read bank addr register\n");
return NULL;
}
-   flash->bank_curr = curr_bank;
-   } else {
-   flash->bank_curr = curr_bank;
}
 #endif
 
-- 
1.8.3


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

Re: [U-Boot] [PATCH] board:universal: fix i2c adapter

[Przemyslaw Marczak]

Hello Tom,

On 01/14/2014 09:19 AM, Przemyslaw Marczak wrote:

Hi,

On 01/14/2014 08:15 AM, Piotr Wilczek wrote:

Universal uses only one adapter I2C_0.

Signed-off-by: Piotr Wilczek 
Signed-off-by: Kyungmin Park 
---
  board/samsung/universal_c210/universal.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/samsung/universal_c210/universal.c
b/board/samsung/universal_c210/universal.c
index 54d0e1e..3feef3f 100644
--- a/board/samsung/universal_c210/universal.c
+++ b/board/samsung/universal_c210/universal.c
@@ -49,7 +49,7 @@ int power_init_board(void)
   * For PMIC the I2C bus is named as I2C5, but it is connected
   * to logical I2C adapter 0
   */
-ret = pmic_init(I2C_5);
+ret = pmic_init(I2C_0);
  if (ret)
  return ret;




Acked-by: Przemyslaw Marczak 

Thank you,


This patch was missed, could you please apply this to the release?

Thank you,
--
Przemyslaw Marczak
Samsung R&D Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] am43xx_evm.h: Correct SPL max size

[Tom Rini]

Upon further inspection of relevant parts of the architecture, the
maximum SPL binary size is 220KiB.

Cc: Lokesh Vutla 
Signed-off-by: Tom Rini 
---
 include/configs/am43xx_evm.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h
index 4de495a..83431a4 100644
--- a/include/configs/am43xx_evm.h
+++ b/include/configs/am43xx_evm.h
@@ -34,7 +34,7 @@
 
 /* SPL defines. */
 #define CONFIG_SPL_TEXT_BASE   0x40300350
-#define CONFIG_SPL_MAX_SIZE(0x40337C00 - CONFIG_SPL_TEXT_BASE)
+#define CONFIG_SPL_MAX_SIZE(220 << 10) /* 220KB */
 #define CONFIG_SPL_YMODEM_SUPPORT
 
 /* Enabling L2 Cache */
-- 
1.7.9.5

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

Re: [U-Boot] [PATCH 3/6] sf: Renames on dual_flash stuff

[Jagan Teki]

On Mon, Jan 20, 2014 at 6:46 PM, Marek Vasut  wrote:
> On Saturday, January 18, 2014 at 09:49:11 PM, Jagan Teki wrote:
>> On Sun, Jan 19, 2014 at 2:07 AM, Marek Vasut  wrote:
>> > On Saturday, January 18, 2014 at 09:06:30 PM, Jagannadha Sutradharudu
>> > Teki
>> >
>> > wrote:
>> >> - Used small names for dual_flash macros
>> >> - Updated doc/SPI/README.dual-flash
>> >>
>> >> Signed-off-by: Jagannadha Sutradharudu Teki 
>> >> Cc: Marek Vasut 
>> >
>> > I agree with the documentation, but disagree with the rename. Please
>> > split the patch into multiple logical blocks so these can be reviewed
>> > separatelly. One would be the documentation, the next the rename and I
>> > also see some new #ifdef in the code, which would be a third block.
>>
>> I don't think we need to separate here! as documentation got changed
>> because of rename of macros' and also new #ifdef is already added one
>> CONFIG_SF_DUAL_FLASH which is also dual_flash specific.
>
> I still see documentation fixes, renames and even newly added code. This 
> really
> makes no sense to me to meld all these into a single patch.

Will be clear in next series for sure!

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

Re: [U-Boot] [PATCH 2/6] sf: Optimize flash features code

[Jagan Teki]

On Mon, Jan 20, 2014 at 6:49 PM, Marek Vasut  wrote:
> On Saturday, January 18, 2014 at 09:51:56 PM, Jagan Teki wrote:
>> On Sun, Jan 19, 2014 at 2:09 AM, Marek Vasut  wrote:
>> > On Saturday, January 18, 2014 at 09:06:29 PM, Jagannadha Sutradharudu
>> > Teki
>> >
>> > wrote:
>> >> - Shrink spi_slave {}
>> >> - Shrink spi_flash_params {}
>> >> - Documentation for sf features
>> >>
>> >> Signed-off-by: Jagannadha Sutradharudu Teki 
>> >> Cc: Marek Vasut 
>> >> ---
>> >>
>> >>  doc/SPI/README.sf-features| 122 ++
>> >>  drivers/mtd/spi/sf.c  |   4 +-
>> >>  drivers/mtd/spi/sf_internal.h |   1 -
>> >>  drivers/mtd/spi/sf_ops.c  |   8 +-
>> >>  drivers/mtd/spi/sf_params.c   | 172
>> >>
>> >> +- drivers/mtd/spi/sf_probe.c
>> >> |
>> >>
>> >>  71 -
>> >>  include/spi.h |  42 ---
>> >>  include/spi_flash.h   |  24 +++---
>> >>  8 files changed, 270 insertions(+), 174 deletions(-)
>> >>  create mode 100644 doc/SPI/README.sf-features
>> >>
>> >> diff --git a/doc/SPI/README.sf-features b/doc/SPI/README.sf-features
>> >> new file mode 100644
>> >> index 000..d35f56d
>> >> --- /dev/null
>> >> +++ b/doc/SPI/README.sf-features
>> >> @@ -0,0 +1,122 @@
>> >> +SPI FLASH feature enhancements:
>> >> +==
>> >> +
>> >> +This document describes how to extend the current data structures in
>> >> spi subsystem +for making use of new flash features/operations w.r.t to
>> >> controller driver support. +
>> >> +1. spi_slave:
>> >> +
>> >> +struct spi_slave {
>> >> +..
>> >> +u32 mode_bits;
>> >> +
>> >> +};
>> >> +
>> >> +@mode_bits can be used to expose the SPI RX/TX operation modes, bus
>> >> options and +few flags which are used to extended the flash specific
>> >> features/operations +- include/spi.h
>> >> +
>> >> +mode_bits:
>> >> +- SPI_TX_QPP: 4-Wire tx transfer operation quad page program
>> >> +- SPI_RX_SLOW: 1-wire rx transfer operation array slow read
>> >> +- SPI_RX_DUAL: 2-wire rx transfer operation dual fast read
>> >> +- SPI_RX_DUAL_IO: 2-wire rx transfer operation dual io fast read
>> >> +- SPI_RX_QUAD: 4-wire rx transfer operation quad fast read
>> >> +- SPI_RX_QUAD_IO: 4-wire rx transfer operation quad io fast read
>> >> +- SPI_SHARED: dual flash devices are connected in shared bus connection
>> >> +- SPI_SEPARATED: dual flash devices are connected in separate bus
>> >> connection +- SPI_U_PAGE: select the upper flash in dual flash shared
>> >> bus connection [1] +
>> >
>> > A generic SPI controller _does_ _not_ _care_ about any SPI flash crud.
>> > The SPI bus controller (which is what this is for) and SPI-NOR
>> > controller are two different things and must have two different slave
>> > structures.
>>
>> You mean mode_bits need to move in one more structure.
>> Just leave about new SPI-NOR as of now for this release we discuss more
>> soon.
>
> The mode_bits have no place in this structure. The slave can indicate whether 
> it
> can be connected over 1,2,4... lines , but must not indicate that it supports
> some SPI-flash specific properties.

What do you mean by this - can you elaborate.
As of now drivers in drivers/spi need to inform the flash through spi_slave {}
no other alternative ie way remaining flash properties memory_map etc.. handle.
Even Linux follow the same w/o new SPI-NOR framework.

If your question, like need a separate structure for flash specific properties
please wait will wound-up all these in new framework.

I'm planning to push in today release.

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

Re: [U-Boot] [PATCH 2/6] sf: Optimize flash features code

[Marek Vasut]

On Saturday, January 18, 2014 at 09:51:56 PM, Jagan Teki wrote:
> On Sun, Jan 19, 2014 at 2:09 AM, Marek Vasut  wrote:
> > On Saturday, January 18, 2014 at 09:06:29 PM, Jagannadha Sutradharudu
> > Teki
> > 
> > wrote:
> >> - Shrink spi_slave {}
> >> - Shrink spi_flash_params {}
> >> - Documentation for sf features
> >> 
> >> Signed-off-by: Jagannadha Sutradharudu Teki 
> >> Cc: Marek Vasut 
> >> ---
> >> 
> >>  doc/SPI/README.sf-features| 122 ++
> >>  drivers/mtd/spi/sf.c  |   4 +-
> >>  drivers/mtd/spi/sf_internal.h |   1 -
> >>  drivers/mtd/spi/sf_ops.c  |   8 +-
> >>  drivers/mtd/spi/sf_params.c   | 172
> >> 
> >> +- drivers/mtd/spi/sf_probe.c   
> >> |
> >> 
> >>  71 -
> >>  include/spi.h |  42 ---
> >>  include/spi_flash.h   |  24 +++---
> >>  8 files changed, 270 insertions(+), 174 deletions(-)
> >>  create mode 100644 doc/SPI/README.sf-features
> >> 
> >> diff --git a/doc/SPI/README.sf-features b/doc/SPI/README.sf-features
> >> new file mode 100644
> >> index 000..d35f56d
> >> --- /dev/null
> >> +++ b/doc/SPI/README.sf-features
> >> @@ -0,0 +1,122 @@
> >> +SPI FLASH feature enhancements:
> >> +==
> >> +
> >> +This document describes how to extend the current data structures in
> >> spi subsystem +for making use of new flash features/operations w.r.t to
> >> controller driver support. +
> >> +1. spi_slave:
> >> +
> >> +struct spi_slave {
> >> +..
> >> +u32 mode_bits;
> >> +
> >> +};
> >> +
> >> +@mode_bits can be used to expose the SPI RX/TX operation modes, bus
> >> options and +few flags which are used to extended the flash specific
> >> features/operations +- include/spi.h
> >> +
> >> +mode_bits:
> >> +- SPI_TX_QPP: 4-Wire tx transfer operation quad page program
> >> +- SPI_RX_SLOW: 1-wire rx transfer operation array slow read
> >> +- SPI_RX_DUAL: 2-wire rx transfer operation dual fast read
> >> +- SPI_RX_DUAL_IO: 2-wire rx transfer operation dual io fast read
> >> +- SPI_RX_QUAD: 4-wire rx transfer operation quad fast read
> >> +- SPI_RX_QUAD_IO: 4-wire rx transfer operation quad io fast read
> >> +- SPI_SHARED: dual flash devices are connected in shared bus connection
> >> +- SPI_SEPARATED: dual flash devices are connected in separate bus
> >> connection +- SPI_U_PAGE: select the upper flash in dual flash shared
> >> bus connection [1] +
> > 
> > A generic SPI controller _does_ _not_ _care_ about any SPI flash crud.
> > The SPI bus controller (which is what this is for) and SPI-NOR
> > controller are two different things and must have two different slave
> > structures.
> 
> You mean mode_bits need to move in one more structure.
> Just leave about new SPI-NOR as of now for this release we discuss more
> soon.

The mode_bits have no place in this structure. The slave can indicate whether 
it 
can be connected over 1,2,4... lines , but must not indicate that it supports 
some SPI-flash specific properties.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/6] sf: Renames on dual_flash stuff

[Marek Vasut]

On Saturday, January 18, 2014 at 09:49:11 PM, Jagan Teki wrote:
> On Sun, Jan 19, 2014 at 2:07 AM, Marek Vasut  wrote:
> > On Saturday, January 18, 2014 at 09:06:30 PM, Jagannadha Sutradharudu
> > Teki
> > 
> > wrote:
> >> - Used small names for dual_flash macros
> >> - Updated doc/SPI/README.dual-flash
> >> 
> >> Signed-off-by: Jagannadha Sutradharudu Teki 
> >> Cc: Marek Vasut 
> > 
> > I agree with the documentation, but disagree with the rename. Please
> > split the patch into multiple logical blocks so these can be reviewed
> > separatelly. One would be the documentation, the next the rename and I
> > also see some new #ifdef in the code, which would be a third block.
> 
> I don't think we need to separate here! as documentation got changed
> because of rename of macros' and also new #ifdef is already added one
> CONFIG_SF_DUAL_FLASH which is also dual_flash specific.

I still see documentation fixes, renames and even newly added code. This really 
makes no sense to me to meld all these into a single patch.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] sf: Update read/write command macros

[Jagan Teki]

On Mon, Jan 20, 2014 at 6:40 PM, Jagan Teki  wrote:
> On Mon, Jan 20, 2014 at 6:36 PM, Marek Vasut  wrote:
>> On Monday, January 20, 2014 at 12:46:07 PM, Jagan Teki wrote:
>>> On Mon, Jan 20, 2014 at 4:43 PM, Detlev Zundel  wrote:
>>> > Hi Jagan,
>>> >
>>> >> On Sun, Jan 19, 2014 at 2:06 AM, Marek Vasut  wrote:
>>> >>> On Saturday, January 18, 2014 at 09:06:31 PM, Jagannadha
>>> >>> Sutradharudu Teki
>>> >>>
>>> >>> wrote:
>>>  - Used readable names for read/write command macros
>>>  - Added comments for the same
>>> 
>>>  Signed-off-by: Jagannadha Sutradharudu Teki 
>>>  Cc: Marek Vasut 
>>>  Cc: Simon Glass 
>>> >>>
>>> >>> Does this patch have any impact other than making the code harder to
>>> >>> understand
>>> >>> ? :-(
>>> >>>
>>> >>> What's the rationale for making the code more cryptic ?
>>> >>
>>> >> No issues I guess with the readability as each macro we can easily
>>> >> understand.
>>> >> like CMD_RD_QUAD --> command_read_quad
>>> >>
>>> >>   CMD_WR_PAGE --> command_write_page_program
>>> >>
>>> >> And this will minimize the macro length - good for in coding and more
>>> >> over description is added in drivers/mtd/spi/sf_internal.h anyway.
>>> >
>>> > Again I agree with Marek that readability of code is more important than
>>> > saving a few characters while coding.  This is especially true as
>>> > editors can support you in coding (Emacs has lots of packages to help
>>> > here for example).
>>>
>>> I don't think nothing much gone the readability with these updated:
>>> CMD_READ_ARRAY_FAST has updated CMD_RD_FAST and it seems like
>>> easy to understand. and anyway I have added comments for full name as well.
>>
>> CMD_READ_ARRAY_FAST contains all the necessary bits for me to understand what
>> the macro means. CMD_RD_FAST does not. I fail to see the rationale behind
>> changing the names.
>>
>>> Few of the flashes can be call this as array fast read and fewer call
>>> this as fast read
>>> and few more call this as high frequency read. CMD_RD_FAST will suits
>>> all these names.
>>>
>>> Comments please!
>>
>> If you want to align the names with anything, align then with linux's 
>> m25p80.c
>> driver . But I see this change as moot and confusing, sorry.
>
> No issues, we can skip these as of now for this release.!

Just fyi: if we need a reference of m25p80.c the name as OPCODE_NORM_READ
which is similar to what i did :)

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

Re: [U-Boot] [PATCH 4/6] sf: Update read/write command macros

[Jagan Teki]

On Mon, Jan 20, 2014 at 6:36 PM, Marek Vasut  wrote:
> On Monday, January 20, 2014 at 12:46:07 PM, Jagan Teki wrote:
>> On Mon, Jan 20, 2014 at 4:43 PM, Detlev Zundel  wrote:
>> > Hi Jagan,
>> >
>> >> On Sun, Jan 19, 2014 at 2:06 AM, Marek Vasut  wrote:
>> >>> On Saturday, January 18, 2014 at 09:06:31 PM, Jagannadha
>> >>> Sutradharudu Teki
>> >>>
>> >>> wrote:
>>  - Used readable names for read/write command macros
>>  - Added comments for the same
>> 
>>  Signed-off-by: Jagannadha Sutradharudu Teki 
>>  Cc: Marek Vasut 
>>  Cc: Simon Glass 
>> >>>
>> >>> Does this patch have any impact other than making the code harder to
>> >>> understand
>> >>> ? :-(
>> >>>
>> >>> What's the rationale for making the code more cryptic ?
>> >>
>> >> No issues I guess with the readability as each macro we can easily
>> >> understand.
>> >> like CMD_RD_QUAD --> command_read_quad
>> >>
>> >>   CMD_WR_PAGE --> command_write_page_program
>> >>
>> >> And this will minimize the macro length - good for in coding and more
>> >> over description is added in drivers/mtd/spi/sf_internal.h anyway.
>> >
>> > Again I agree with Marek that readability of code is more important than
>> > saving a few characters while coding.  This is especially true as
>> > editors can support you in coding (Emacs has lots of packages to help
>> > here for example).
>>
>> I don't think nothing much gone the readability with these updated:
>> CMD_READ_ARRAY_FAST has updated CMD_RD_FAST and it seems like
>> easy to understand. and anyway I have added comments for full name as well.
>
> CMD_READ_ARRAY_FAST contains all the necessary bits for me to understand what
> the macro means. CMD_RD_FAST does not. I fail to see the rationale behind
> changing the names.
>
>> Few of the flashes can be call this as array fast read and fewer call
>> this as fast read
>> and few more call this as high frequency read. CMD_RD_FAST will suits
>> all these names.
>>
>> Comments please!
>
> If you want to align the names with anything, align then with linux's m25p80.c
> driver . But I see this change as moot and confusing, sorry.

No issues, we can skip these as of now for this release.!

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

Re: [U-Boot] [PATCH 4/6] sf: Update read/write command macros

[Marek Vasut]

On Monday, January 20, 2014 at 12:46:07 PM, Jagan Teki wrote:
> On Mon, Jan 20, 2014 at 4:43 PM, Detlev Zundel  wrote:
> > Hi Jagan,
> > 
> >> On Sun, Jan 19, 2014 at 2:06 AM, Marek Vasut  wrote:
> >>> On Saturday, January 18, 2014 at 09:06:31 PM, Jagannadha
> >>> Sutradharudu Teki
> >>> 
> >>> wrote:
>  - Used readable names for read/write command macros
>  - Added comments for the same
>  
>  Signed-off-by: Jagannadha Sutradharudu Teki 
>  Cc: Marek Vasut 
>  Cc: Simon Glass 
> >>> 
> >>> Does this patch have any impact other than making the code harder to
> >>> understand
> >>> ? :-(
> >>> 
> >>> What's the rationale for making the code more cryptic ?
> >> 
> >> No issues I guess with the readability as each macro we can easily
> >> understand.
> >> like CMD_RD_QUAD --> command_read_quad
> >> 
> >>   CMD_WR_PAGE --> command_write_page_program
> >> 
> >> And this will minimize the macro length - good for in coding and more
> >> over description is added in drivers/mtd/spi/sf_internal.h anyway.
> > 
> > Again I agree with Marek that readability of code is more important than
> > saving a few characters while coding.  This is especially true as
> > editors can support you in coding (Emacs has lots of packages to help
> > here for example).
> 
> I don't think nothing much gone the readability with these updated:
> CMD_READ_ARRAY_FAST has updated CMD_RD_FAST and it seems like
> easy to understand. and anyway I have added comments for full name as well.

CMD_READ_ARRAY_FAST contains all the necessary bits for me to understand what 
the macro means. CMD_RD_FAST does not. I fail to see the rationale behind 
changing the names.

> Few of the flashes can be call this as array fast read and fewer call
> this as fast read
> and few more call this as high frequency read. CMD_RD_FAST will suits
> all these names.
> 
> Comments please!

If you want to align the names with anything, align then with linux's m25p80.c 
driver . But I see this change as moot and confusing, sorry.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] How to perform a secure boot on ARM Linux

[rakesh ranjan]

Hi,

I have a beagle board and want to create a u-boot that verifies the kernel
and rootfs before booting it. Any pointers on how it can be achieved will
be appreciated.

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

Re: [U-Boot] booting os 'Unknown OS' (1) is not supported

[Andreas Bießmann]

Dear Alexander Khryukin,

On 01/20/2014 01:08 PM, Alexander Khryukin wrote:
> methinks that the problem in kernel.
> I can boot "original" android kernel from any place: emmc, SD, fat
> partition, USB-device, etc.

well, maybe has your special u-boot special handling for your special
android kernel? Therefore would be the problem your special u-boot
variant (as pointed out before).

Best regards

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

Re: [U-Boot] booting os 'Unknown OS' (1) is not supported

[Alexander Khryukin]

methinks that the problem in kernel.
I can boot "original" android kernel from any place: emmc, SD, fat
partition, USB-device, etc.



2014/1/20 Detlev Zundel 

> Hi Alexander,
>
> > link to my u-boot https://github.com/fedya/u-boot-yse5250
> >
> >>Please change the boot command and include the commands
> >
> > Changed to this
> > bootcmd=md 4080 10;imi 4080;bootm 4080
> >
> > [YSE5250@omv]# boot
> > 4080: 56190527 ba6b0d61 9850d952 08484800'..Va.k.R.P..HH.
> > 40800010: 00800040 00800040 8a221c4c 00020205@...@...L.".
> > 40800020: 756e694c 2e332d78 302e3331 3863722dLinux-3.13.0-rc8
> > 40800030:    
> >
> > ## Checking Image at 4080 ...
> >Legacy image found
> >Image Name:   Linux-3.13.0-rc8
> >Image Type:   ARM Linux Kernel Image (uncompressed)
> >Data Size:4737032 Bytes = 4626 KiB
> >Load Address: 40008000
> >Entry Point:  40008000
> >Verifying Checksum ... OK
> > ## Current stack ends at 0xc3cfbcc8 *  kernel: cmdline image address =
> > 0x4080
> > ## Booting kernel from Legacy Image at 4080 ...
> >Image Name:   Linux-3.13.0-rc8
> >Image Type:   ARM Linux Kernel Image (uncompressed)
> >Data Size:4737032 Bytes = 4626 KiB
> >Load Address: 40008000
> >Entry Point:  40008000
> >Verifying Checksum ... OK
> >kernel data at 0x40800040, len = 0x00484808 (4737032)
> > ## No init Ramdisk
> >ramdisk start = 0x, ramdisk end = 0x
> >Loading Kernel Image ... OK
> > OK
> >kernel loaded at 0x40008000, end = 0x4048c808
> > ERROR: booting os 'Unknown OS' (1) is not supported
>
> This is really weird and I am pretty sure that this is not supposed to
> happen with the code that we have in mainline.  I think you have two
> options here:
>
> 1. Get mainline U-Boot running on your board that works with the uImage
>that os created from mainline Linux
>
> 2. Debug your U-Boot version why it does not handle the uImage like it
>is supposed to.
>
> Option 1 will be the more rewarding alternative of course.
>
> Best wishes
>   Detlev
>
> --
> insults:  If set, sudo will insult users when they enter an incorrect
> password.  This flag is off by default.
>-- man sudoers
> --
> DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] how to get u-boot code with arm64: core support

[bhupesh.sha...@freescale.com]

> -Original Message-
> From: tiger...@viatech.com.cn [mailto:tiger...@viatech.com.cn]
> Sent: Monday, January 20, 2014 4:24 PM
> To: Wood Scott-B07421; Sharma Bhupesh-B45370
> Cc: feng...@phytium.com.cn; tr...@ti.com; u-boot@lists.denx.de
> Subject: Re: Re: [U-Boot] how to get u-boot code with arm64: core support
> 
> Hi, Scott:
> >After changing to u-boot.elf, it could be run in FVP model.
> If I run "./Foundation_v8 --image ./u-boot.elf --cores=4 --no-secure-
> memory", Uboot could be run with FVP model.
> But no ARM trusted firmware boot info appeared.
> Such as:
> Booting trusted firmware boot loader stage 1 ..
> 
> If I run "./Foundation_v8 --cores=4 --no-secure-memory --no-gicv3
> --data="./bl1.bin"@0x0 --nsdata="./u-boot.elf"@0x8000",
> ARM trusted firmware boot info could appear, but failed to load and run
> u-boot.elf.
> 
> So, if I want to use ARM trusted firmware to boot u-boot.elf, any ideas?
> 

U-boot doesn't have ARM trusted firmware support as of now. U-boot for ARMv8 
starts in EL3,
whereas UEFI starts in EL2 as trusted firmware itself is working in EL3.

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

Re: [U-Boot] [PATCH 4/6] sf: Update read/write command macros

[Jagan Teki]

On Mon, Jan 20, 2014 at 4:43 PM, Detlev Zundel  wrote:
> Hi Jagan,
>
>> On Sun, Jan 19, 2014 at 2:06 AM, Marek Vasut  wrote:
>>> On Saturday, January 18, 2014 at 09:06:31 PM, Jagannadha
>>> Sutradharudu Teki
>>> wrote:
 - Used readable names for read/write command macros
 - Added comments for the same

 Signed-off-by: Jagannadha Sutradharudu Teki 
 Cc: Marek Vasut 
 Cc: Simon Glass 
>>>
>>> Does this patch have any impact other than making the code harder to
>>> understand
>>> ? :-(
>>>
>>> What's the rationale for making the code more cryptic ?
>>
>> No issues I guess with the readability as each macro we can easily
>> understand.
>> like CMD_RD_QUAD --> command_read_quad
>>   CMD_WR_PAGE --> command_write_page_program
>>
>> And this will minimize the macro length - good for in coding and more over
>> description is added in drivers/mtd/spi/sf_internal.h anyway.
>
> Again I agree with Marek that readability of code is more important than
> saving a few characters while coding.  This is especially true as
> editors can support you in coding (Emacs has lots of packages to help
> here for example).

I don't think nothing much gone the readability with these updated:
CMD_READ_ARRAY_FAST has updated CMD_RD_FAST and it seems like
easy to understand. and anyway I have added comments for full name as well.

Few of the flashes can be call this as array fast read and fewer call
this as fast read
and few more call this as high frequency read. CMD_RD_FAST will suits
all these names.

Comments please!

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

Re: [U-Boot] [PATCH 3/3] sf: Use shortcut names

[Jagan Teki]

On Mon, Jan 20, 2014 at 4:35 PM, Detlev Zundel  wrote:
> Hi Jagan and Marek,
>
>> On Friday, January 17, 2014 at 03:41:47 PM, Jagannadha Sutradharudu
>> Teki wrote:
>>> - SPI_FLASH -> SF
>>> - ARRAY_SLOW -> AS
>>> - ARRAY_FAST -> AF
>>> - DUAL_OUTPUT_FAST -> DOF
>>> - DUAL_IO_FAST - DIOF
>>> - QUAD_OUTPUT_FAST - QOF
>>> - QUAD_IO_FAST - QIOF
>>
>> Now this really makes the code impossible to understand :-(
>
> I totally agree with Marek that this is the wrong way to go.  Doing a
> change like this is a change to the worse as it removes understandable
> constants and replaces them with adhoc abbreviations.
>
> Please don't do that.

Just ignore this these were updated in
[PATCH 4/6] sf: Update read/write command macros

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

Re: [U-Boot] booting os 'Unknown OS' (1) is not supported

[Detlev Zundel]

Hi Alexander,

> link to my u-boot https://github.com/fedya/u-boot-yse5250
>
>>Please change the boot command and include the commands
>
> Changed to this
> bootcmd=md 4080 10;imi 4080;bootm 4080
>
> [YSE5250@omv]# boot
> 4080: 56190527 ba6b0d61 9850d952 08484800'..Va.k.R.P..HH.
> 40800010: 00800040 00800040 8a221c4c 00020205@...@...L.".
> 40800020: 756e694c 2e332d78 302e3331 3863722dLinux-3.13.0-rc8
> 40800030:    
>
> ## Checking Image at 4080 ...
>Legacy image found
>Image Name:   Linux-3.13.0-rc8
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4737032 Bytes = 4626 KiB
>Load Address: 40008000
>Entry Point:  40008000
>Verifying Checksum ... OK
> ## Current stack ends at 0xc3cfbcc8 *  kernel: cmdline image address =
> 0x4080
> ## Booting kernel from Legacy Image at 4080 ...
>Image Name:   Linux-3.13.0-rc8
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4737032 Bytes = 4626 KiB
>Load Address: 40008000
>Entry Point:  40008000
>Verifying Checksum ... OK
>kernel data at 0x40800040, len = 0x00484808 (4737032)
> ## No init Ramdisk
>ramdisk start = 0x, ramdisk end = 0x
>Loading Kernel Image ... OK
> OK
>kernel loaded at 0x40008000, end = 0x4048c808
> ERROR: booting os 'Unknown OS' (1) is not supported

This is really weird and I am pretty sure that this is not supposed to
happen with the code that we have in mainline.  I think you have two
options here:

1. Get mainline U-Boot running on your board that works with the uImage
   that os created from mainline Linux

2. Debug your U-Boot version why it does not handle the uImage like it
   is supposed to.

Option 1 will be the more rewarding alternative of course.

Best wishes
  Detlev

-- 
insults:  If set, sudo will insult users when they enter an incorrect
password.  This flag is off by default.
   -- man sudoers
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] sf: Update read/write command macros

[Detlev Zundel]

Hi Jagan,

> On Sun, Jan 19, 2014 at 2:06 AM, Marek Vasut  wrote:
>> On Saturday, January 18, 2014 at 09:06:31 PM, Jagannadha
>> Sutradharudu Teki
>> wrote:
>>> - Used readable names for read/write command macros
>>> - Added comments for the same
>>>
>>> Signed-off-by: Jagannadha Sutradharudu Teki 
>>> Cc: Marek Vasut 
>>> Cc: Simon Glass 
>>
>> Does this patch have any impact other than making the code harder to
>> understand
>> ? :-(
>>
>> What's the rationale for making the code more cryptic ?
>
> No issues I guess with the readability as each macro we can easily
> understand.
> like CMD_RD_QUAD --> command_read_quad
>   CMD_WR_PAGE --> command_write_page_program
>
> And this will minimize the macro length - good for in coding and more over
> description is added in drivers/mtd/spi/sf_internal.h anyway.

Again I agree with Marek that readability of code is more important than
saving a few characters while coding.  This is especially true as
editors can support you in coding (Emacs has lots of packages to help
here for example).

Cheers
  Detlev

-- 
(7)  It is always something
(7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three).
   -- The Twelve Networking Truths (RFC 1925)
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] sf: Use shortcut names

[Detlev Zundel]

Hi Jagan and Marek,

> On Friday, January 17, 2014 at 03:41:47 PM, Jagannadha Sutradharudu
> Teki wrote:
>> - SPI_FLASH -> SF
>> - ARRAY_SLOW -> AS
>> - ARRAY_FAST -> AF
>> - DUAL_OUTPUT_FAST -> DOF
>> - DUAL_IO_FAST - DIOF
>> - QUAD_OUTPUT_FAST - QOF
>> - QUAD_IO_FAST - QIOF
>
> Now this really makes the code impossible to understand :-(

I totally agree with Marek that this is the wrong way to go.  Doing a
change like this is a change to the worse as it removes understandable
constants and replaces them with adhoc abbreviations.

Please don't do that.

Thanks
  Detlev

-- 
Men are born ignorant, not stupid; they are made stupid by education.
  --Bertrand Russell
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] how to get u-boot code with arm64: core support

[TigerLiu]

Hi, Scott:
>After changing to u-boot.elf, it could be run in FVP model.
If I run "./Foundation_v8 --image ./u-boot.elf --cores=4
--no-secure-memory", Uboot could be run with FVP model.
But no ARM trusted firmware boot info appeared.
Such as:
Booting trusted firmware boot loader stage 1
..

If I run "./Foundation_v8 --cores=4 --no-secure-memory --no-gicv3
--data="./bl1.bin"@0x0 --nsdata="./u-boot.elf"@0x8000",
ARM trusted firmware boot info could appear, but failed to load and run
u-boot.elf.

So, if I want to use ARM trusted firmware to boot u-boot.elf, any ideas?

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

Re: [U-Boot] booting os 'Unknown OS' (1) is not supported

[Alexander Khryukin]

link to my u-boot https://github.com/fedya/u-boot-yse5250

>Please change the boot command and include the commands

Changed to this
bootcmd=md 4080 10;imi 4080;bootm 4080

[YSE5250@omv]# boot
4080: 56190527 ba6b0d61 9850d952 08484800'..Va.k.R.P..HH.
40800010: 00800040 00800040 8a221c4c 00020205@...@...L.".
40800020: 756e694c 2e332d78 302e3331 3863722dLinux-3.13.0-rc8
40800030:    

## Checking Image at 4080 ...
   Legacy image found
   Image Name:   Linux-3.13.0-rc8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4737032 Bytes = 4626 KiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
## Current stack ends at 0xc3cfbcc8 *  kernel: cmdline image address =
0x4080
## Booting kernel from Legacy Image at 4080 ...
   Image Name:   Linux-3.13.0-rc8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4737032 Bytes = 4626 KiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   kernel data at 0x40800040, len = 0x00484808 (4737032)
## No init Ramdisk
   ramdisk start = 0x, ramdisk end = 0x
   Loading Kernel Image ... OK
OK
   kernel loaded at 0x40008000, end = 0x4048c808
ERROR: booting os 'Unknown OS' (1) is not supported




>movi
string from help

movi- movi  - sd/mmc r/w sub system for SMDK board

and same command for o-droid
http://lists.denx.de/pipermail/u-boot/2013-February/146047.html




2014/1/20 Wolfgang Denk 

> Dear Alexander Khryukin,
>
> In message <
> cabtoafz3e-ee3v73th6u4bjsqixu6sy3h1tdng2fx-phdf0...@mail.gmail.com> you
> wrote:
> >
> > As you said i changed my bootcmd to
> > *bootcmd=movi read kernel 0 4080;bootm 408*
>
> I really wonder which sort of U-Boot you are running.  "movi" is not a
> command present in mainline, not in any vendor port I am aware of.
> What exactly is this command supposed to do?
>
> Please change the boot command and include the commands
>
> md 408 10;imi 408
>
> before the "bootm" part.
>
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Hacking's just another word for nothing left to kludge.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] board_r - fixup functions table after relocation

[Alexey Brodkin]

This is only required for "PIC" relocation and doesn't apply to modern
"PIE" relocation which does data relocation as well as code.

"init_sequence_r" is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to "void" to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.

As a consequence on execution after relocation "initcall_run_list" will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.

Signed-off-by: Alexey Brodkin 

Cc: Tom Rini 
Cc: Simon Glass 
Cc: Masahiro Yamada 
Cc: Doug Anderson 
Cc: Thomas Langer 
Cc: Albert ARIBAUD 

Changes to v2:
 * Use ARRAY_SIZE as suggested by Simon Glass
 * Added CONFIG_NEEDS_MANUAL_RELOC wrapper for temporary index variable
"i" to fix compile-time warning for boards without
CONFIG_NEEDS_MANUAL_RELOC
---
 common/board_r.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..c2d0763 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -903,9 +903,19 @@ init_fnc_t init_sequence_r[] = {
 
 void board_init_r(gd_t *new_gd, ulong dest_addr)
 {
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+   int i;
+#endif
+
 #ifndef CONFIG_X86
gd = new_gd;
 #endif
+
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+   for (i = 0; i < ARRAY_SIZE(init_sequence_r); i++)
+   init_sequence_r[i] += gd->reloc_off;
+#endif
+
if (initcall_run_list(init_sequence_r))
hang();
 
-- 
1.8.4.2

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

Re: [U-Boot] [PATCH] ARM: tegra20: Add a missing entry in the pullid enum

[Alban Bedel]

On Wed, 15 Jan 2014 11:36:03 -0700
Stephen Warren  wrote:

> On 01/15/2014 07:55 AM, Alban Bedel wrote:
> > It seems two entries were merged in one when this file has been
> > created. The GPSLXAU entries is obviously a mix of GPU and SLXA which
> > are next to each other according to the datasheet. Moreover it can be
> > noticed because the APB_MISC_PP_PULLUPDOWN_REG_B_0 register only have
> > 15 entries instead of 16.
> > 
> > Also fix the pin group descriptions that were using these buggy
> > entries. In particular SLXA that needed to used CRTP to actually
> > write the SLXA register.
> 
> This does appear to match the kernel's pinctrl driver, so,
> Acked-by: Stephen Warren 
> 
> I wonder how many more similar issues there are. Did you check the whole
> file for this kind of issue, or just debug a problem with one particular
> pin/group?

I found this while trying to get the internal pull up enabled on UARTD.
Afterwards I checked the whole enum and the table but everything else
seems to be correct.

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

Re: [U-Boot] [PATCH v2] board_r - fixup functions table after relocation

[Masahiro Yamada]

Hello Alexey,


> diff --git a/common/board_r.c b/common/board_r.c
> index 86ca1cb..3462590 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -903,9 +903,16 @@ init_fnc_t init_sequence_r[] = {
>  
>  void board_init_r(gd_t *new_gd, ulong dest_addr)
>  {
> + int i;

This emits a warning if CONFIG_NEED_MANUAL_RELOC is not defined.

For example, arndale board:

board_r.c: In function 'board_init_r':
board_r.c:906:6: warning: unused variable 'i' [-Wunused-variable]


>  #ifndef CONFIG_X86
>   gd = new_gd;
>  #endif
> +
> +#ifdef CONFIG_NEEDS_MANUAL_RELOC
> + for (i = 0; i < sizeof(init_sequence_r)/sizeof(void *); i++)
> + init_sequence_r[i] += gd->reloc_off;
> +#endif
> +

Please use ARRAY_SIZE as Simon suggested.


Best Regards
Masahiro Yamada

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

Re: [U-Boot] booting os 'Unknown OS' (1) is not supported

[Wolfgang Denk]

Dear Alexander Khryukin,

In message  
you wrote:
>
> As you said i changed my bootcmd to
> *bootcmd=movi read kernel 0 4080;bootm 408*

I really wonder which sort of U-Boot you are running.  "movi" is not a
command present in mainline, not in any vendor port I am aware of.
What exactly is this command supposed to do?

Please change the boot command and include the commands

md 408 10;imi 408

before the "bootm" part.



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Hacking's just another word for nothing left to kludge.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Uboot_Header_Modification_by_CVS

[Wolfgang Denk]

Dear Arun,

In message <82cf479d9040c547849e3005e77f780024b...@svfrwexch1.ikanos.com> you 
wrote:
>
> 1) Downloaded u-boot-2010.09 source code. 
> (u-boot-2010.09.tar.bz2)
> 2) Some files, have version & header information along with the source code.
...
> 3) When I do a check in for these files, using CVS, these header information 
> is changed.
> CVS is  automatically modifying these headers.

May I ask why you are using CVS?  CVS is hopelessly obsolete and has
been replaced by much more powerfull tools many, many years ago.

I'm asking this especially because your question indicates that you
are not exactly an experienced CVS user, so it makes not much of a
difference whether you familiarize yourself with CVS or with aanother
tool like git.

Do yourself (and us) a favour and use git instead like everybody else.

> 1. Why only few files have these kind of header information in Uboot 
> repository ?

Because these files have been imported from another project where they
used such ID strings.

> 2. If I do a check in via CVS, the headers will be modified,
>So will it be a violation to GPL ?
>
> 3.  If it is a Violation , please help me with a solution .

Th ebest you can to is to get rid of CVS and use git instead.  You can
then simply clone the mainline git repository.

If you really, really insist on using CVS, then you will have to go
through the process of familiarizing yourself with this tool.  Please
read the manual, and eventually some of the tutorials.  Please pay
special attention to the "-k" flag which controls keyword substitution
in CVS.  For working with U-Boot code, you want to switch off keyword
substitution.

Um... and please do not expect further help on CVS on this mailing
list.  We left it behind a decade ago, and never ever missed it since.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Everyone, in some small sacred sanctuary of the self, is nuts.
 - Leo Rosten
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2][v2] powerpc/mpc85xx: SECURE BOOT- add version info for ISBC

[Wolfgang Denk]

Dear Aneesh Bansal,

In message <1390203451-8561-1-git-send-email-aneesh.ban...@freescale.com> you 
wrote:
> T4/B4 SoC's have a different version of ISBC. The secure boot
> functionality is different with the new version of ISBC
> compared to the earlier SoC's. So the version information is added
> in file config_mpc85xx.h

Same comment as V1:  please do not define new CONFIG options without
need.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"The question of whether a computer can think is no more  interesting
than the question of whether a submarine can swim"
- Edsgar W.  Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [i2c] v2 Pull request

[Heiko Schocher]

Hello Tom

Updated pull request for u-boot-i2c, as the zynq patches had problems,
see:

http://lists.denx.de/pipermail/u-boot/2014-January/171352.html

So, here the correct pull-request:

The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca:

  Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 10:56:00 
-0500)

are available in the git repository at:


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

for you to fetch changes up to dccacbe01968f9e682cb1dc9b7d43c831897cbec:

  i2c: fti2c010: fix compiler warning on paddr[] (2014-01-13 08:18:38 +0100)


Alexey Brodkin (2):
  env_eeprom - fix bus recovery for "eeprom_bus_read"
  drivers/designware_i2c - add suppor of CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW

Darwin Rambo (1):
  i2c: Fix i2c speed command

Hisashi Nakamura (1):
  rcar_i2c: Fix receiving wait condition

Kuo-Jung Su (1):
  i2c: fti2c010: fix compiler warning on paddr[]

Nobuhiro Iwamatsu (1):
  rcar_i2c: Clear status before start master receive

 common/env_eeprom.c  |  5 ++---
 drivers/i2c/designware_i2c.c | 38 ++
 drivers/i2c/fti2c010.c   |  4 ++--
 drivers/i2c/i2c_core.c   |  2 +-
 drivers/i2c/rcar_i2c.c   |  6 --
 5 files changed, 47 insertions(+), 8 deletions(-)

Thanks!

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
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 1/2] SECURE BOOT: add version info for ISBC

[Wolfgang Denk]

Dear Aneesh Bansal,

In message <1390202676-8167-1-git-send-email-aneesh.ban...@freescale.com> you 
wrote:
> T4/B4 SoC's have a different version of ISBC. The secure boot
> functionality is different with the new version of ISBC
> compared to the earlier SoC's. So the version information is added
> in file config_mpc85xx.h
> 
> Signed-off-by: Ruchika Gupta 
> Signed-off-by: Aneesh Bansal 
> ---
>  README| 3 +++
>  arch/powerpc/include/asm/config_mpc85xx.h | 9 +
>  2 files changed, 12 insertions(+)
> 
> diff --git a/README b/README
> index aea82be..6c3a8d1 100644
> --- a/README
> +++ b/README
> @@ -423,6 +423,9 @@ The following options need to be configured:
>   CONFIG_SYS_FSL_DSP_CCSRBAR_DEFAULT
>   This value denotes start offset of DSP CCSR space.
>  
> + CONFIG_SYS_FSL_ISBC_VER
> + This value indicates the major ISBC version on the platform.
> +
>   CONFIG_SYS_FSL_SINGLE_SOURCE_CLK
>   Single Source Clock is clocking mode present in some of FSL 
> SoC's.
>   In this mode, a single differential clock is used to supply

You already have all relevant information present in the current
configuration.  There is no need to add yet another CONFIG_SYS_
option; the information can easily be derived from the existing data.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Ernest asks Frank how long he has been working for the company.
"Ever since they threatened to fire me."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] board_r - fixup functions table after relocation

[Alexey Brodkin]

This is only required for "PIC" relocation and doesn't apply to modern
"PIE" relocation which does data relocation as well as code.

"init_sequence_r" is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to "void" to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.

As a consequence on execution after relocation "initcall_run_list" will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.

Signed-off-by: Alexey Brodkin 

Cc: Tom Rini 
Cc: Simon Glass 
Cc: Masahiro Yamada 
Cc: Doug Anderson 
Cc: Thomas Langer 
Cc: Albert ARIBAUD 

Changes to v1:
 * Added CONFIG_NEEDS_MANUAL_RELOC wrapper so this change only applies
to "PIC" relocation.
---
 common/board_r.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..3462590 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -903,9 +903,16 @@ init_fnc_t init_sequence_r[] = {
 
 void board_init_r(gd_t *new_gd, ulong dest_addr)
 {
+   int i;
 #ifndef CONFIG_X86
gd = new_gd;
 #endif
+
+#ifdef CONFIG_NEEDS_MANUAL_RELOC
+   for (i = 0; i < sizeof(init_sequence_r)/sizeof(void *); i++)
+   init_sequence_r[i] += gd->reloc_off;
+#endif
+
if (initcall_run_list(init_sequence_r))
hang();
 
-- 
1.8.4.2

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

Re: [U-Boot] [U-Boot, v1, 2/2] i2c: zynq: Add support for the second i2c controller

[Heiko Schocher]

Hello Michal,

Am 20.01.2014 10:22, schrieb Michal Simek:

On 01/17/2014 07:43 AM, Heiko Schocher wrote:

Hello Michal,

Am 13.01.2014 09:23, schrieb Michal Simek:

On 01/13/2014 09:10 AM, Heiko Schocher wrote:

Hello Michael,

Am 13.01.2014 08:53, schrieb Michal Simek:

On 01/13/2014 08:32 AM, Heiko Schocher wrote:

Hello Michel,

Am 03.01.2014 10:45, schrieb Michal Simek:

From: Michael Burr

Initialize the second i2c controller.

Signed-off-by: Michael Burr
Signed-off-by: Michal Simek

---
Changes in v1:
- Based on original thread from Michael Burr
  http://lists.denx.de/pipermail/u-boot/2013-October/165017.html
  Heiko did some changes in this mainline patch
  "i2c, zynq: convert zynq i2c driver to new multibus/multiadapter 
framework"
  (sha1: 0bdffe71fddeaa46768a39305797e4512dee0f15)
- MS rebase on latest&greatest

 drivers/i2c/zynq_i2c.c | 46 --
 include/configs/zynq.h |  7 +++
 2 files changed, 31 insertions(+), 22 deletions(-)


I could not apply your patch on top of current tree

commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca
Merge: 8401bfa 10a147b
Author: Tom Rini
Date:   Fri Jan 10 10:56:00 2014 -0500

   Merge branch 'master' of git://git.denx.de/u-boot-arm

Problem is the change in "include/configs/zynq.h", as this file does
not longer exist in mainline ... I think, your change should be done
in "include/configs/zynq-common.h", right?

Is it OK, if I fix this, or would you send a v2 (prefered, as I could
not test this)?


yes, zynq.h was renamed to zynq-common.h.
That will be great if you can fix it yourself.


Done, see:
http://git.denx.de/?p=u-boot/u-boot-i2c.git;a=commit;h=8e0b3c020057b3f7345b6696029a80eaf162e7f3

Please test and give me feedback. If my fix is not perfect, please
post a v2, thanks!



Looks good to me. We will test it and I will let you know if we see any problem.


Do you find some time for tests? I want to send a pull request for
pending i2c patches (inclusive this patch).


Sorry for delay. I have retest it and I see that I have totally messed up
the first patch.
"i2c: zynq: Support for 0-length register address"

This is the origin patch.
http://lists.denx.de/pipermail/u-boot/2013-October/165019.html

Interesting is that I really don't know what I have tested before. :-(

Would it be possible to remove this patch. Feel free to remove both
I will resend them.


I havd removed both patches from u-boot-i2c.git. Please repost them,
thanks!

bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
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] [i2c] Pull request

[Michal Simek]

On 01/20/2014 10:34 AM, Alexey Brodkin wrote:
> On Mon, 2014-01-20 at 10:24 +0100, Michal Simek wrote:
>> Hi Tom,
>>
>> look below.
>>
>> On 01/18/2014 08:28 AM, Heiko Schocher wrote:
>>> Hello Tom,
>>>
>>> please pull some small fixes from u-boot-i2c.git
>>>
>>> Thanks!
>>>
>>> The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca:
>>>
>>>   Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 
>>> 10:56:00 -0500)
>>>
>>> are available in the git repository at:
>>>
>>>
>>>   git://git.denx.de/u-boot-i2c.git master
>>>
>>> for you to fetch changes up to 8e0b3c020057b3f7345b6696029a80eaf162e7f3:
>>>
>>>   i2c: zynq: Add support for the second i2c controller (2014-01-13 09:06:08 
>>> +0100)
>>>
>>> 
>>> Alexey Brodkin (2):
>>>   env_eeprom - fix bus recovery for "eeprom_bus_read"
>>>   drivers/designware_i2c - add suppor of 
>>> CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
>>>
>>> Darwin Rambo (1):
>>>   i2c: Fix i2c speed command
>>>
>>> Hisashi Nakamura (1):
>>>   rcar_i2c: Fix receiving wait condition
>>>
>>> Kuo-Jung Su (1):
>>>   i2c: fti2c010: fix compiler warning on paddr[]
>>>
>>> Michael Burr (2):
>>>   i2c: zynq: Support for 0-length register address
>>
>> I have found that I cherry-picked this patch incorrectly from origin one
>> and it is breaking current functionality.
>> I have already sent email to Heiko that this is patch is wrong.
>>
>> I don't know if Heiko wants to send new pull request or you can
>> just remove that 2 patches on the top of Heiko's tree.
> 
> Hi Michal,
> 
> could you please clarify which particular patches from mentioned
> pull-request break current functionality?

This one: "i2c: zynq: Support for 0-length register address"
It is not your fault just mine. I wrongly resolved conflicts
which there was and I don't know why testing passed in that time.
(I probably tested any incorrect version).

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




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

Re: [U-Boot] [i2c] Pull request

[Alexey Brodkin]

On Mon, 2014-01-20 at 10:24 +0100, Michal Simek wrote:
> Hi Tom,
> 
> look below.
> 
> On 01/18/2014 08:28 AM, Heiko Schocher wrote:
> > Hello Tom,
> > 
> > please pull some small fixes from u-boot-i2c.git
> > 
> > Thanks!
> > 
> > The following changes since commit 7f673c99c2d8d1aa21996c5b914f06d784b080ca:
> > 
> >   Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-01-10 
> > 10:56:00 -0500)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.denx.de/u-boot-i2c.git master
> > 
> > for you to fetch changes up to 8e0b3c020057b3f7345b6696029a80eaf162e7f3:
> > 
> >   i2c: zynq: Add support for the second i2c controller (2014-01-13 09:06:08 
> > +0100)
> > 
> > 
> > Alexey Brodkin (2):
> >   env_eeprom - fix bus recovery for "eeprom_bus_read"
> >   drivers/designware_i2c - add suppor of 
> > CONFIG_SYS_I2C_EEPROM_ADDR_OVERFLOW
> > 
> > Darwin Rambo (1):
> >   i2c: Fix i2c speed command
> > 
> > Hisashi Nakamura (1):
> >   rcar_i2c: Fix receiving wait condition
> > 
> > Kuo-Jung Su (1):
> >   i2c: fti2c010: fix compiler warning on paddr[]
> > 
> > Michael Burr (2):
> >   i2c: zynq: Support for 0-length register address
> 
> I have found that I cherry-picked this patch incorrectly from origin one
> and it is breaking current functionality.
> I have already sent email to Heiko that this is patch is wrong.
> 
> I don't know if Heiko wants to send new pull request or you can
> just remove that 2 patches on the top of Heiko's tree.

Hi Michal,

could you please clarify which particular patches from mentioned
pull-request break current functionality?

-Alexey

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

Re: [U-Boot] booting os 'Unknown OS' (1) is not supported

[Alexander Khryukin]

Good day!
I'm here again with short report.

As you said i changed my bootcmd to
*bootcmd=movi read kernel 0 4080;bootm 408*
with default bootargs options
bootargs=console=ttySAC1,115200n8 vmalloc=512M androidboot.console=ttySAC

And i see same result

[YSE5250@omv]# boot
reading kernel..device 0 Start 1063, Count 16384
MMC read: dev # 0, block # 1063, count 16384 ... 16384 blocks read: OK
completed
## Current stack ends at 0xc3cfbcc8 *  kernel: cmdline image address =
0x4080
## Booting kernel from Legacy Image at 4080 ...
   Image Name:   Linux-3.13.0-rc8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4737032 Bytes = 4626 KiB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... OK
   kernel data at 0x40800040, len = 0x00484808 (4737032)
## No init Ramdisk
   ramdisk start = 0x, ramdisk end = 0x
   Loading Kernel Image ... OK
OK
   kernel loaded at 0x40008000, end = 0x4048c808
ERROR: booting os 'Unknown OS' (1) is not supported







2014/1/17 Detlev Zundel 

> Hi Alexander,
>
> > You have any suggestion how i can fix or hack it?
> > I really have no clue what's wrong and why it's working with android
> kernel
> > and not with mainline.
>
> Well, potentially, there can be worlds of differences between such
> kernels.  I don't know your platform at all, but is it expected to work
> with a mainline kernel?
>
> The only thing that I can think of to get more information is to edit
> your bootcmd to only boot the kernel without any ramdisk and see if the
> loading of the latter is the problem, i.e. something like that:
>
> bootcmd=movi read kernel 0 4080;bootm 4080
>
> Even though this cannot fully work, it may give us new input.
>
> Cheers
>   Detlev
>
> --
> ;; Self-replicator in ELisp
> ((lambda (l) (prin1-to-string (list l (list (quote quote) l
>  (quote (lambda (l) (prin1-to-string (list l (list (quote quote) l))
> --
> DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot