Re: [U-Boot] [PATCH] net: fix m88e1111s PHY auto negotiation timeout

[Stefan Roese]

Hi Thomas,

On 16.02.2016 07:54, Thomas Chou wrote:

After commit a058052c358c
("net: phy: do not read configuration register on reset")

both 3c120 and 10m50 devboard which use Marvel m88es PHY got this
error message,

Net:   eth0: ethernet@400
=> ping 192.168.1.5
ethernet@400 Waiting for PHY auto negotiation to complete TIMEOUT !
Using ethernet@400 device
host 192.168.1.5 is alive

This is because the auto negotiation control bit was cleared by the new
phy_reset(). But the m88es_config() does the soft-reset already,
there is no need to reset twice. The extra phy_reset() should be
removed.

Signed-off-by: Thomas Chou 
---
  drivers/net/phy/marvell.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index eab1558..5badfac 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -271,8 +271,6 @@ static int m88es_config(struct phy_device *phydev)

genphy_config_aneg(phydev);

-   phy_reset(phydev);
-
return 0;
  }




I've also stumbled over this problem on some boards equipped with the
Marvell PHY. Could you please take a look at these patches instead:

http://patchwork.ozlabs.org/patch/581316/
http://patchwork.ozlabs.org/patch/581317/

Do they work for you?

Joe, could you please make sure to push these for this release? As its
a real bugfix.

Thanks,
Stefan

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

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

[Bin Meng]

On Thu, Feb 18, 2016 at 3:13 PM, Jagan Teki  wrote:
> Hi  Bin,
>
> On 18 February 2016 at 10:54, Bin Meng  wrote:
>> On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng  wrote:
>>> Hi Jagan,
>>>
>>> On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng  wrote:
 Hi Jagan,

 On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng  wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki  wrote:
>> Hi Bin,
>>
>> On 17 February 2016 at 13:07, Jagan Teki  wrote:
>>> Hi Bin,
>>>
>>> On 17 February 2016 at 10:52, Bin Meng  wrote:
 Hi Jagan,

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

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

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

 Anything wrong?
>>>
>>>
>>
>>  I'm not getting the warning, after saveenv.
>>
>> DRAM:  ECC disabled 1 GiB
>> MMC:
>> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>> KiB, total 16 MiB
>> In:serial@e0001000
>> Out:   serial@e0001000
>> Err:   serial@e0001000
>> Model: Zynq 

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

[Jagan Teki]

Hi  Bin,

On 18 February 2016 at 10:54, Bin Meng  wrote:
> On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng  wrote:
>> Hi Jagan,
>>
>> On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng  wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng  wrote:
 Hi Jagan,

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

 Tested both DM and non-DM models

 Tested-by: Jagan Teki 
>>>
>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>> Warning - bad CRC, using default environment
>>>
>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>> KiB, total 2 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Anything wrong?
>>
>>
>
>  I'm not getting the warning, after saveenv.
>
> DRAM:  ECC disabled 1 GiB
> MMC:
> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
> KiB, total 16 MiB
> In:serial@e0001000
> Out:   serial@e0001000
> Err:   serial@e0001000
> Model: Zynq MicroZED Board
>

 Tested on another x86 board, still see the 'bad CRC' warning, log below:

 U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)

 CPU: x86, 

[U-Boot] [PATCH] pci: Fix compiler warnings in dm_pciauto_setup_device()

[Bin Meng]

Fix the following compiler warnings when DEBUG is on.

warning: 'bar_res' may be used uninitialized in this function.
drivers/pci/pci_auto.c:101:21:
   if (!enum_only && pciauto_region_allocate(bar_res, bar_size,
^

Signed-off-by: Bin Meng 
---

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

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 88bc416..ee9a854 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -30,7 +30,7 @@ void dm_pciauto_setup_device(struct udevice *dev, int 
bars_num,
u8 header_type;
int rom_addr;
pci_addr_t bar_value;
-   struct pci_region *bar_res;
+   struct pci_region *bar_res = NULL;
int found_mem64 = 0;
u16 class;
 
-- 
1.8.2.1

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

Re: [U-Boot] [PATCH] mx6ul_14x14_evk: Select CONFIG_FSL_QSPI

[Peng Fan]

Hi Fabio,

On Wed, Feb 17, 2016 at 05:32:14PM -0200, Fabio Estevam wrote:
>From: Fabio Estevam 
>
>Select CONFIG_FSL_QSPI so that the SPI can be probed:
>
>=> sf probe
>SF: Detected N25Q256 with page size 256 Bytes, erase size 64 KiB, total 32 MiB
>
>Signed-off-by: Fabio Estevam 
>---
> include/configs/mx6ul_14x14_evk.h | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/include/configs/mx6ul_14x14_evk.h 
>b/include/configs/mx6ul_14x14_evk.h
>index 4374c3a..c7e10f9 100644
>--- a/include/configs/mx6ul_14x14_evk.h
>+++ b/include/configs/mx6ul_14x14_evk.h
>@@ -195,6 +195,7 @@
> #define CONFIG_CMD_CACHE
> #endif
> 
>+#define CONFIG_FSL_QSPI
> #ifdef CONFIG_FSL_QSPI
> #define CONFIG_CMD_SF
> #define CONFIG_SPI_FLASH

Reviewed-by: Peng Fan 

Thanks,
Peng.

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

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

[Bin Meng]

On Thu, Feb 18, 2016 at 1:13 PM, Bin Meng  wrote:
> Hi Jagan,
>
> On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng  wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng  wrote:
>>> Hi Jagan,
>>>
>>> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki  wrote:
 Hi Bin,

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

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

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

 Why this framework:

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

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

 Before SPI-NOR:

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

 After SPI-NOR:

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

 SPI-NOR with MTD:

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

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

  I'm not getting the warning, after saveenv.

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

>>>
>>> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>>>
>>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>>
>>> CPU: x86, vendor Intel, device 590h
>>> DRAM:  256 MiB
>>> MMC:   Quark SDHCI: 0
>>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 
>>> 8 MiB
>>> *** Warning - bad CRC, using default environment

[U-Boot] [PATCH v2] spi-nor: Correct the logic to detect flash rw mode

[Bin Meng]

spi->mode includes all available modes for operating on SPI flashes,
and we should test each bit instead of a switch..case statement to
make the detection logic correct.

Signed-off-by: Bin Meng 

---

Changes in v2:
- Write mode detection should not be in a 'else' branch

 drivers/mtd/spi-nor/m25p80.c | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c
index 4e0a53c..8edc481 100644
--- a/drivers/mtd/spi-nor/m25p80.c
+++ b/drivers/mtd/spi-nor/m25p80.c
@@ -178,26 +178,17 @@ static int m25p80_spi_nor(struct spi_nor *nor)
return ret;
}
 
-   switch (spi->mode) {
-   case SPI_RX_SLOW:
+   if (spi->mode & SPI_RX_SLOW)
nor->read_mode = SNOR_READ;
-   break;
-   case SPI_RX_DUAL:
+   else if (spi->mode & SPI_RX_DUAL)
nor->read_mode = SNOR_READ_1_1_2;
-   break;
-   case SPI_RX_QUAD:
+   else if (spi->mode & SPI_RX_QUAD)
nor->read_mode = SNOR_READ_1_1_4;
-   break;
-   }
 
-   switch (spi->mode) {
-   case SPI_TX_BYTE:
+   if (spi->mode & SPI_TX_BYTE)
nor->mode = SNOR_WRITE_1_1_BYTE;
-   break;
-   case SPI_TX_QUAD:
+   else if (spi->mode & SPI_TX_QUAD)
nor->mode = SNOR_WRITE_1_1_4;
-   break;
-   }
 
nor->memory_map = spi->memory_map;
nor->max_write_size = spi->max_write_size;
-- 
1.8.2.1

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

Re: [U-Boot] Newbie SPL question for socfpga_sockit

[Phil Reid]

G'day George

On 18/02/2016 5:54 AM, George Broz wrote:

Hello,

Sorry for the newbie question...

I have an Altera/Terasic board (socfpga_sockit) that has issues recognizing
USB storage devices (roughly 60% good / 40% bad):

SOCFPGA_CYCLONE5 # usb start
(Re)start USB...
USB0: scanning bus 0 for devices... DW_USB: Transfer completion
interrupt timeout
Timed out waiting for channel to disable
1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found


The pre-made U-Boot SPL & image that come with the board have version:
U-Boot 2013.01.01 (Aug 08 2014 - 10:46:23)

(Old!)

I need to rebuild U-Boot for this board to add md5sum and hopefully fix the
USB issues. When I've rebuilt the u-boot.img from the 2013.01.01 branch
of the (Altera maintained) source, U-boot boots, but the USB problems
get worse (100% bad):

USB0: Core Release: 2.93a
dwc_otg_core_host_init: Unable to clear halt on channel 1 (timeout
HCCHAR 0xC000 @ffb40520)
dwc_otg_core_host_init: Unable to clear halt on channel 2 (timeout
HCCHAR 0xC000 @ffb40540

(I've confirmed that CONFIG_CMD_USB and CONFIG_USB_STORAGE are
defined and have tried turning on and off 'dcache' as suggested elsewhere
to no avail).

If I try a later release (e.g. v2016.01 which seems to support the Terasic
board explicitly) the boot process stops just after loading the SPL.

At this point I have only been changing the u-boot.img component, not the
SPL (in the a2 partition of the MMC).

The documentation from Altera about generating the SPL seems to require
using Qsys/Quartus tools which I'd really like to avoid.

I can produce u-boot-spl.bin / u-boot.img from
make socfpga_sockit_defconfig; make all.

My newbie question ... should be I able to use directly the u-boot-spl.bin
generated by the build to replace the SPL on the board?

(I'm hoping the USB issues resolve themselves when I'm able to get
the later version of U-Boot running...)



I've just gone thru the process (this week) of getting uboot 2016.01 to boot on 
our custom socfpga board.
There where a few issues in getting things going.
If your using the sd card to boot then the current memory layout is not per the 
altera documentation.
I had to make the changes below to config to match the altera docs. Otherwise 
it hangs just after the SPL.
You also need to use the -dtb image versions with 2016.01 for things to work.
Again you may need to make sure the uboot device trees match your hardware.
Not all uboot drivers appear to be using the DT as yet.

Note the SPL is tightly coupled to the board design and potentially the FPGA 
image.
If you using bridges or routing HPS resources (eg i2c etc) to the fpga the SPL 
configures the muxes.

There's a script in uboot src at arch\arm\mach-socfpga\qts-filter.sh
That will generate the qts files for you arch.

I haven't tried the USB stuff as yet.
There are some issues witht eh altera USB port trigger an Over Current event on 
device insertation.
They've modified the linux kenerl driver to use external OV current detection 
to get around the problem.
My intial workaround was to insert USB device prior to power on.
I haven't looked at the uboot USB driver yet to see what's in there.


--
Regards
Phil Reid


diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index a09e906..3a1b59b 100644 (file)
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -357,13 +357,13 @@ unsigned int cm_get_qspi_controller_clk_hz(void);

/* SPL SDMMC boot support */
#ifdef CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SPL_LIBDISK_SUPPORT
#if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 2
#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME "u-boot-dtb.img"
-#define CONFIG_SPL_LIBDISK_SUPPORT
#else
-#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 3
-#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0xa00 /* offset 2560 sect 
(1M+256k) */
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION 3
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR 0x200
#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 800 /* 400 KB */
#endif
#endif


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

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

[Bin Meng]

Hi Jagan,

On Thu, Feb 18, 2016 at 12:05 PM, Bin Meng  wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng  wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki  wrote:
>>> Hi Bin,
>>>
>>> On 17 February 2016 at 13:07, Jagan Teki  wrote:
 Hi Bin,

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


>>>
>>>  I'm not getting the warning, after saveenv.
>>>
>>> DRAM:  ECC disabled 1 GiB
>>> MMC:
>>> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>>> KiB, total 16 MiB
>>> In:serial@e0001000
>>> Out:   serial@e0001000
>>> Err:   serial@e0001000
>>> Model: Zynq MicroZED Board
>>>
>>
>> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>>
>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>
>> CPU: x86, vendor Intel, device 590h
>> DRAM:  256 MiB
>> MMC:   Quark SDHCI: 0
>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 
>> MiB
>> *** Warning - bad CRC, using default environment
>>
>> Model: Intel Galileo
>> Net:
>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>> eth0: eth_designware#0
>> Warning: eth_designware#1 (eth1) using random MAC address - 

[U-Boot] [Patch V5 0/4] Qe/Fman related patches

[Gong Qianyu]

Hi all,

This is the version 5 patchset that fixes to:
- move the code changes of fdt_fixup_fman_firmware() to a separate
 new patch [3/4].

Tested on LS1043AQDS board and P4080DS board.
Thank you for reviewing the patches.

[Patch V5 1/4] qe: move drivers/qe/qe.h to include/fsl_qe.h
[Patch V5 2/4] fm: fdt: Move fman ucode fixup to driver code
[Patch V5 3/4] driver/fm: fdt.c: fix fdt_fixup_fman_firmware() to
[Patch V5 4/4] armv8/fsl-layerscape: fdt: add fixup for Fman ucode



Regards,
Qianyu

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

[U-Boot] [Patch V5 3/4] driver/fm: fdt.c: fix fdt_fixup_fman_firmware() to support ARM platforms

[Gong Qianyu]

Use fdt32_to_cpu() to convert the data correctly for both endianness
platforms.

Signed-off-by: Gong Qianyu 
---
V5:
 - New Patch.

 drivers/net/fm/fdt.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/net/fm/fdt.c b/drivers/net/fm/fdt.c
index 830d228..9918d80 100644
--- a/drivers/net/fm/fdt.c
+++ b/drivers/net/fm/fdt.c
@@ -45,7 +45,7 @@ void fdt_fixup_fman_firmware(void *blob)
return;
 
hdr = >header;
-   length = be32_to_cpu(hdr->length);
+   length = fdt32_to_cpu(hdr->length);
 
/* Verify the firmware. */
if ((hdr->magic[0] != 'Q') || (hdr->magic[1] != 'E') ||
@@ -61,14 +61,16 @@ void fdt_fixup_fman_firmware(void *blob)
}
 
length -= sizeof(u32);  /* Subtract the size of the CRC */
-   crc = be32_to_cpu(*(u32 *)((void *)fmanfw + length));
+   crc = fdt32_to_cpu(*(u32 *)((void *)fmanfw + length));
if (crc != crc32_no_comp(0, (void *)fmanfw, length)) {
printf("Fman firmware at %p has invalid CRC\n", fmanfw);
return;
}
 
+   length += sizeof(u32);
+
/* Increase the size of the fdt to make room for the node. */
-   rc = fdt_increase_size(blob, fmanfw->header.length);
+   rc = fdt_increase_size(blob, length);
if (rc < 0) {
printf("Unable to make room for Fman firmware: %s\n",
   fdt_strerror(rc));
@@ -101,8 +103,7 @@ void fdt_fixup_fman_firmware(void *blob)
   fdt_strerror(rc));
return;
}
-   rc = fdt_setprop(blob, fwnode, "fsl,firmware", fmanfw,
-fmanfw->header.length);
+   rc = fdt_setprop(blob, fwnode, "fsl,firmware", fmanfw, length);
if (rc < 0) {
char s[64];
fdt_get_path(blob, fwnode, s, sizeof(s));
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch V5 4/4] armv8/fsl-layerscape: fdt: add fixup for Fman ucode

[Gong Qianyu]

Add fdt fixup to insert Fman firmware into the device tree.

Signed-off-by: Gong Qianyu 
---
V4-V5:
 - No change.
V3:
 - Remove fman clock fixup.
 - Revise commit message too.
V2:
 - Removed the duplicated function.

 arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index 4e4861d..9c18fd7 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -14,6 +14,9 @@
 #ifdef CONFIG_FSL_ESDHC
 #include 
 #endif
+#ifdef CONFIG_SYS_DPAA_FMAN
+#include 
+#endif
 #ifdef CONFIG_MP
 #include 
 #endif
@@ -204,4 +207,8 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_FSL_LSCH3
fdt_fixup_smmu(blob);
 #endif
+
+#ifdef CONFIG_SYS_DPAA_FMAN
+   fdt_fixup_fman_firmware(blob);
+#endif
 }
-- 
2.1.0.27.g96db324

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

[U-Boot] [Patch V5 1/4] qe: move drivers/qe/qe.h to include/fsl_qe.h

[Gong Qianyu]

As the QE firmware struct is shared with Fman, move the header file
out of drivers/qe/.

Signed-off-by: Gong Qianyu 
---
V5:
 - No change.
V4:
 - Updated and based on the latest commit.
   No code changed but fixed "git am" error.
V3:
 - Move file changes about "qe.h" to this patch.
V2:
 - New Patch.

 arch/powerpc/cpu/mpc85xx/cpu_init.c | 2 +-
 arch/powerpc/cpu/mpc85xx/fdt.c  | 2 +-
 board/freescale/common/arm_sleep.c  | 2 +-
 board/freescale/common/mpc85xx_sleep.c  | 2 +-
 board/freescale/ls1021aqds/ls1021aqds.c | 2 +-
 board/freescale/ls1021atwr/ls1021atwr.c | 2 +-
 drivers/net/fm/fm.c | 2 +-
 drivers/qe/fdt.c| 2 +-
 drivers/qe/qe.c | 2 +-
 drivers/qe/uccf.c   | 2 +-
 drivers/qe/uccf.h   | 2 +-
 drivers/qe/uec.c| 2 +-
 drivers/qe/uec.h| 2 +-
 drivers/qe/uec_phy.c| 2 +-
 drivers/qe/qe.h => include/fsl_qe.h | 0
 15 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 80bbc18..202b7c1 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -44,7 +44,7 @@
 
 #include "../../../../drivers/block/fsl_sata.h"
 #ifdef CONFIG_U_QE
-#include "../../../../drivers/qe/qe.h"
+#include 
 #endif
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 7270be1..50eef05 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -19,7 +19,7 @@
 #ifdef CONFIG_FSL_ESDHC
 #include 
 #endif
-#include "../../../../drivers/qe/qe.h" /* For struct qe_firmware */
+#include /* For struct qe_firmware */
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/board/freescale/common/arm_sleep.c 
b/board/freescale/common/arm_sleep.c
index a498c65..71ed15e 100644
--- a/board/freescale/common/arm_sleep.c
+++ b/board/freescale/common/arm_sleep.c
@@ -19,7 +19,7 @@
 
 #include "sleep.h"
 #ifdef CONFIG_U_QE
-#include "../../../drivers/qe/qe.h"
+#include 
 #endif
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/board/freescale/common/mpc85xx_sleep.c 
b/board/freescale/common/mpc85xx_sleep.c
index e9cbd51..498d770 100644
--- a/board/freescale/common/mpc85xx_sleep.c
+++ b/board/freescale/common/mpc85xx_sleep.c
@@ -8,7 +8,7 @@
 #include 
 #include "sleep.h"
 #ifdef CONFIG_U_QE
-#include "../../../drivers/qe/qe.h"
+#include 
 #endif
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c 
b/board/freescale/ls1021aqds/ls1021aqds.c
index 5f4ec9d..9dbc1b6 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -28,7 +28,7 @@
 #include "../common/qixis.h"
 #include "ls1021aqds_qixis.h"
 #ifdef CONFIG_U_QE
-#include "../../../drivers/qe/qe.h"
+#include 
 #endif
 
 #define PIN_MUX_SEL_CAN0x03
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c 
b/board/freescale/ls1021atwr/ls1021atwr.c
index 616e0bf..054a324 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -28,7 +28,7 @@
 #include 
 #include "../common/sleep.h"
 #ifdef CONFIG_U_QE
-#include "../../../drivers/qe/qe.h"
+#include 
 #endif
 #include 
 
diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
index 40fbf19..e2a8ed3 100644
--- a/drivers/net/fm/fm.c
+++ b/drivers/net/fm/fm.c
@@ -10,7 +10,7 @@
 #include 
 
 #include "fm.h"
-#include "../../qe/qe.h"   /* For struct qe_firmware */
+#include /* For struct qe_firmware */
 
 #ifdef CONFIG_SYS_QE_FMAN_FW_IN_NAND
 #include 
diff --git a/drivers/qe/fdt.c b/drivers/qe/fdt.c
index dfae4bf..4f48f98 100644
--- a/drivers/qe/fdt.c
+++ b/drivers/qe/fdt.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include "qe.h"
+#include 
 
 #ifdef CONFIG_QE
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/drivers/qe/qe.c b/drivers/qe/qe.c
index 08620b2..8f00817 100644
--- a/drivers/qe/qe.c
+++ b/drivers/qe/qe.c
@@ -12,7 +12,7 @@
 #include "asm/errno.h"
 #include "asm/io.h"
 #include "linux/immap_qe.h"
-#include "qe.h"
+#include 
 #ifdef CONFIG_LS102XA
 #include 
 #endif
diff --git a/drivers/qe/uccf.c b/drivers/qe/uccf.c
index 85386bf..e011886 100644
--- a/drivers/qe/uccf.c
+++ b/drivers/qe/uccf.c
@@ -12,8 +12,8 @@
 #include "asm/errno.h"
 #include "asm/io.h"
 #include "linux/immap_qe.h"
-#include "qe.h"
 #include "uccf.h"
+#include 
 
 void ucc_fast_transmit_on_demand(ucc_fast_private_t *uccf)
 {
diff --git a/drivers/qe/uccf.h b/drivers/qe/uccf.h
index 55941e4..aa817e7 100644
--- a/drivers/qe/uccf.h
+++ b/drivers/qe/uccf.h
@@ -11,8 +11,8 @@
 #define __UCCF_H__
 
 #include "common.h"
-#include "qe.h"
 #include "linux/immap_qe.h"
+#include 
 
 /* Fast or Giga ethernet
 */
diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
index e0ab04a..402 100644
--- a/drivers/qe/uec.c
+++ b/drivers/qe/uec.c
@@ 

[U-Boot] [Patch V5 2/4] fm: fdt: Move fman ucode fixup to driver code

[Gong Qianyu]

Not only powerpc/mpc85xx but also Freescale Layerscape platforms will
use fdt_fixup_fman_firmware() to insert Fman ucode blob into the device
tree. So move the function to Fman driver code.

Signed-off-by: Gong Qianyu 
---
V5:
 - Move the function changes to a separate patch.
V4:
 - No change.
V3:
 - Remove file changes about "qe.h".
   (Should be put in the first patch of this patchset)
V2:
 - New patch.

 arch/powerpc/cpu/mpc85xx/fdt.c | 125 ++--
 drivers/net/fm/Makefile|   1 +
 drivers/net/fm/fdt.c   | 128 +
 include/fsl_fman.h |   1 +
 4 files changed, 135 insertions(+), 120 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 50eef05..ced216c 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -19,7 +19,9 @@
 #ifdef CONFIG_FSL_ESDHC
 #include 
 #endif
-#include /* For struct qe_firmware */
+#ifdef CONFIG_SYS_DPAA_FMAN
+#include 
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -488,125 +490,6 @@ static void ft_fixup_qe_snum(void *blob)
 }
 #endif
 
-/**
- * fdt_fixup_fman_firmware -- insert the Fman firmware into the device tree
- *
- * The binding for an Fman firmware node is documented in
- * Documentation/powerpc/dts-bindings/fsl/dpaa/fman.txt.  This node contains
- * the actual Fman firmware binary data.  The operating system is expected to
- * be able to parse the binary data to determine any attributes it needs.
- */
-#ifdef CONFIG_SYS_DPAA_FMAN
-void fdt_fixup_fman_firmware(void *blob)
-{
-   int rc, fmnode, fwnode = -1;
-   uint32_t phandle;
-   struct qe_firmware *fmanfw;
-   const struct qe_header *hdr;
-   unsigned int length;
-   uint32_t crc;
-   const char *p;
-
-   /* The first Fman we find will contain the actual firmware. */
-   fmnode = fdt_node_offset_by_compatible(blob, -1, "fsl,fman");
-   if (fmnode < 0)
-   /* Exit silently if there are no Fman devices */
-   return;
-
-   /* If we already have a firmware node, then also exit silently. */
-   if (fdt_node_offset_by_compatible(blob, -1, "fsl,fman-firmware") > 0)
-   return;
-
-   /* If the environment variable is not set, then exit silently */
-   p = getenv("fman_ucode");
-   if (!p)
-   return;
-
-   fmanfw = (struct qe_firmware *) simple_strtoul(p, NULL, 16);
-   if (!fmanfw)
-   return;
-
-   hdr = >header;
-   length = be32_to_cpu(hdr->length);
-
-   /* Verify the firmware. */
-   if ((hdr->magic[0] != 'Q') || (hdr->magic[1] != 'E') ||
-   (hdr->magic[2] != 'F')) {
-   printf("Data at %p is not an Fman firmware\n", fmanfw);
-   return;
-   }
-
-   if (length > CONFIG_SYS_QE_FMAN_FW_LENGTH) {
-   printf("Fman firmware at %p is too large (size=%u)\n",
-  fmanfw, length);
-   return;
-   }
-
-   length -= sizeof(u32);  /* Subtract the size of the CRC */
-   crc = be32_to_cpu(*(u32 *)((void *)fmanfw + length));
-   if (crc != crc32_no_comp(0, (void *)fmanfw, length)) {
-   printf("Fman firmware at %p has invalid CRC\n", fmanfw);
-   return;
-   }
-
-   /* Increase the size of the fdt to make room for the node. */
-   rc = fdt_increase_size(blob, fmanfw->header.length);
-   if (rc < 0) {
-   printf("Unable to make room for Fman firmware: %s\n",
-   fdt_strerror(rc));
-   return;
-   }
-
-   /* Create the firmware node. */
-   fwnode = fdt_add_subnode(blob, fmnode, "fman-firmware");
-   if (fwnode < 0) {
-   char s[64];
-   fdt_get_path(blob, fmnode, s, sizeof(s));
-   printf("Could not add firmware node to %s: %s\n", s,
-  fdt_strerror(fwnode));
-   return;
-   }
-   rc = fdt_setprop_string(blob, fwnode, "compatible", 
"fsl,fman-firmware");
-   if (rc < 0) {
-   char s[64];
-   fdt_get_path(blob, fwnode, s, sizeof(s));
-   printf("Could not add compatible property to node %s: %s\n", s,
-  fdt_strerror(rc));
-   return;
-   }
-   phandle = fdt_create_phandle(blob, fwnode);
-   if (!phandle) {
-   char s[64];
-   fdt_get_path(blob, fwnode, s, sizeof(s));
-   printf("Could not add phandle property to node %s: %s\n", s,
-  fdt_strerror(rc));
-   return;
-   }
-   rc = fdt_setprop(blob, fwnode, "fsl,firmware", fmanfw, 
fmanfw->header.length);
-   if (rc < 0) {
-   char s[64];
-   fdt_get_path(blob, fwnode, s, sizeof(s));
-   printf("Could not add firmware property to node %s: %s\n", s,
-  

[U-Boot] [PATCH] spi-nor: Correct the logic to detect flash rw mode

[Bin Meng]

spi->mode includes all available modes for operating on SPI flashes,
and we should test each bit instead of a switch..case statement to
make the detection logic correct.

Signed-off-by: Bin Meng 
---

 drivers/mtd/spi-nor/m25p80.c | 20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c
index 4e0a53c..9d17449 100644
--- a/drivers/mtd/spi-nor/m25p80.c
+++ b/drivers/mtd/spi-nor/m25p80.c
@@ -178,26 +178,16 @@ static int m25p80_spi_nor(struct spi_nor *nor)
return ret;
}
 
-   switch (spi->mode) {
-   case SPI_RX_SLOW:
+   if (spi->mode & SPI_RX_SLOW)
nor->read_mode = SNOR_READ;
-   break;
-   case SPI_RX_DUAL:
+   else if (spi->mode & SPI_RX_DUAL)
nor->read_mode = SNOR_READ_1_1_2;
-   break;
-   case SPI_RX_QUAD:
+   else if (spi->mode & SPI_RX_QUAD)
nor->read_mode = SNOR_READ_1_1_4;
-   break;
-   }
-
-   switch (spi->mode) {
-   case SPI_TX_BYTE:
+   else if (spi->mode & SPI_TX_BYTE)
nor->mode = SNOR_WRITE_1_1_BYTE;
-   break;
-   case SPI_TX_QUAD:
+   else if (spi->mode & SPI_TX_QUAD)
nor->mode = SNOR_WRITE_1_1_4;
-   break;
-   }
 
nor->memory_map = spi->memory_map;
nor->max_write_size = spi->max_write_size;
-- 
1.8.2.1

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

Re: [U-Boot] [PATCH] RFC/BUG Workaround regression with "mkimage -T rksd".

[Simon Glass]

Hi,

On Feb 17, 2016 21:32, "Vagrant Cascadian"  wrote:
>
> While this patch allows "mkimage -T rksd" to work, boot is still
> broken in other ways, so something more needs to be fixed.
>
> Partially Reverts "rockchip: jerry: Enable EDP and HDMI video output"
>
> This partiall reverts commit 74336f7daa4b1a45d04ddc9ef05737af54ae4836.
>
> For some reason, the change made to the rk3288.dtsi broke "mkimage -T
> rksd", which resulted in a different image type that fails to boot:
>
> $ ./tools/mkimage -T rksd -n rk3288 -d spl/u-boot-spl-dtb.bin
u-boot-spl-dtb.rksd
> Warning: SPL image is too large (size 0x80ec) and will not boot
> $ ./tools/mkimage -l u-boot-spl-dtb.rksd
> Image Type:   MVEBU Boot from (null) Image
> Image version:0
> Data Size:-4 Bytes = 4194304.00 kB = 4096.00 MB
> Load Address: 
> Entry Point:  
>
> Normally, mkimage -T rksd should generate an image like this:
>
>   mkimage -l u-boot-spl-dtb.rksd
>   GP Header: Size 3b8cdcfc LoadAddr be9f9d51
>
> However, booting with the "fixed" .rksd image still fails, probably
> because of issues in the device-tree:
>
> U-Boot 2016.03-rc2 (Feb 18 2016 - 04:08:20 +)
>
> Model: Firefly-RK3288
> DRAM:  2 GiB
> Video device 'vop@ff93' cannot allocate frame buffer memory -ensure
the device is set up before relocation
> Error binding driver 'rk_vop': -28
> Video device 'vop@ff94' cannot allocate frame buffer memory -ensure
the device is set up before relocation
> Error binding driver 'rk_vop': -28
> Some drivers failed to bind
> initcall sequence 7ffb0a10 failed at call 00109f9b (err=-28)
>
> Hopefully a more complete fix will be obvious to someone, or there is
> a better way to generate boot images for firefly-rk3288.

Most likely this is just that the SPL image size is to large. Unfortunately
rockchip has a hard 32KB limit. We need to cut things down a bit.

Regards,
Simon

>
> Signed-off-by: Vagrant Cascadian 
> ---
>
>  arch/arm/dts/rk3288.dtsi | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi
> index e51c75c..e2a65be 100644
> --- a/arch/arm/dts/rk3288.dtsi
> +++ b/arch/arm/dts/rk3288.dtsi
> @@ -707,7 +707,6 @@
> iommus = <_mmu>;
> power-domains = < RK3288_PD_VIO>;
> status = "disabled";
> -   u-boot,dm-pre-reloc;
> vopl_out: port {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.1.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] RFC/BUG Workaround regression with "mkimage -T rksd".

[Vagrant Cascadian]

While this patch allows "mkimage -T rksd" to work, boot is still
broken in other ways, so something more needs to be fixed.

Partially Reverts "rockchip: jerry: Enable EDP and HDMI video output"

This partiall reverts commit 74336f7daa4b1a45d04ddc9ef05737af54ae4836.

For some reason, the change made to the rk3288.dtsi broke "mkimage -T
rksd", which resulted in a different image type that fails to boot:

$ ./tools/mkimage -T rksd -n rk3288 -d spl/u-boot-spl-dtb.bin 
u-boot-spl-dtb.rksd
Warning: SPL image is too large (size 0x80ec) and will not boot
$ ./tools/mkimage -l u-boot-spl-dtb.rksd
Image Type:   MVEBU Boot from (null) Image
Image version:0
Data Size:-4 Bytes = 4194304.00 kB = 4096.00 MB
Load Address: 
Entry Point:  

Normally, mkimage -T rksd should generate an image like this:

  mkimage -l u-boot-spl-dtb.rksd
  GP Header: Size 3b8cdcfc LoadAddr be9f9d51

However, booting with the "fixed" .rksd image still fails, probably
because of issues in the device-tree:

U-Boot 2016.03-rc2 (Feb 18 2016 - 04:08:20 +)

Model: Firefly-RK3288
DRAM:  2 GiB
Video device 'vop@ff93' cannot allocate frame buffer memory -ensure the 
device is set up before relocation
Error binding driver 'rk_vop': -28
Video device 'vop@ff94' cannot allocate frame buffer memory -ensure the 
device is set up before relocation
Error binding driver 'rk_vop': -28
Some drivers failed to bind
initcall sequence 7ffb0a10 failed at call 00109f9b (err=-28)

Hopefully a more complete fix will be obvious to someone, or there is
a better way to generate boot images for firefly-rk3288.

Signed-off-by: Vagrant Cascadian 
---

 arch/arm/dts/rk3288.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi
index e51c75c..e2a65be 100644
--- a/arch/arm/dts/rk3288.dtsi
+++ b/arch/arm/dts/rk3288.dtsi
@@ -707,7 +707,6 @@
iommus = <_mmu>;
power-domains = < RK3288_PD_VIO>;
status = "disabled";
-   u-boot,dm-pre-reloc;
vopl_out: port {
#address-cells = <1>;
#size-cells = <0>;
-- 
2.1.4

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

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

[Bin Meng]

Hi Jagan,

On Wed, Feb 17, 2016 at 5:10 PM, Bin Meng  wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki  wrote:
>> Hi Bin,
>>
>> On 17 February 2016 at 13:07, Jagan Teki  wrote:
>>> Hi Bin,
>>>
>>> On 17 February 2016 at 10:52, Bin Meng  wrote:
 Hi Jagan,

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

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

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

 Anything wrong?
>>>
>>>
>>
>>  I'm not getting the warning, after saveenv.
>>
>> DRAM:  ECC disabled 1 GiB
>> MMC:
>> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>> KiB, total 16 MiB
>> In:serial@e0001000
>> Out:   serial@e0001000
>> Err:   serial@e0001000
>> Model: Zynq MicroZED Board
>>
>
> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>
> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>
> CPU: x86, vendor Intel, device 590h
> DRAM:  256 MiB
> MMC:   Quark SDHCI: 0
> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 
> MiB
> *** Warning - bad CRC, using default environment
>
> Model: Intel Galileo
> Net:
> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
> eth0: eth_designware#0
> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
> , eth1: eth_designware#1
> Hit any key to stop autoboot:  0
> => saveenv
> Saving Environment to SPI Flash...
> Erasing SPI flash...Writing to SPI flash...done
> => reset
> resetting ...
>
>
> U-Boot 

[U-Boot] [PATCH V2] OMAP3SOM BOARD: Auto detect Logic PD Models

[Adam Ford]

Logic PD makes four different system on modules.  This patch will auto
detect the board type and identify the corresponding device tree image.

V2:
Added 'default:' case to switch statement
Since board_late_init() is defined as int, we now return 0

Signed-off-by: Derald Woods 
Signed-off-by: Adam Ford 
---
 board/logicpd/omap3som/omap3logic.c | 24 
 include/configs/omap3_logic.h   |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/board/logicpd/omap3som/omap3logic.c 
b/board/logicpd/omap3som/omap3logic.c
index b5c44f9..668f684 100644
--- a/board/logicpd/omap3som/omap3logic.c
+++ b/board/logicpd/omap3som/omap3logic.c
@@ -228,6 +228,30 @@ int board_init(void)
return 0;
 }
 
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   switch (gd->bd->bi_arch_number) {
+   case MACH_TYPE_DM3730_TORPEDO:
+   setenv("fdtimage", "logicpd-torpedo-37xx-devkit.dtb");
+   break;
+   case MACH_TYPE_DM3730_SOM_LV:
+   setenv("fdtimage", "logicpd-som-lv-37xx-devkit.dtb");
+   break;
+   case MACH_TYPE_OMAP3_TORPEDO:
+   setenv("fdtimage", "logicpd-torpedo-35xx-devkit.dtb");
+   break;
+   case MACH_TYPE_OMAP3530_LV_SOM:
+   setenv("fdtimage", "logicpd-som-lv-35xx-devkit.dtb");
+   break;
+   default:
+   /* unknown machine type */
+   break;
+   }
+   return 0;
+}
+#endif
+
 #if defined(CONFIG_GENERIC_MMC) && !defined(CONFIG_SPL_BUILD)
 int board_mmc_init(bd_t *bis)
 {
diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h
index fba2a12..0fc9d1c 100644
--- a/include/configs/omap3_logic.h
+++ b/include/configs/omap3_logic.h
@@ -40,7 +40,7 @@
 
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_DISPLAY_BOARDINFO
-
+#define CONFIG_BOARD_LATE_INIT
 #define CONFIG_MISC_INIT_R /* misc_init_r dumps the die id */
 #define CONFIG_CMDLINE_TAG /* enable passing of ATAGs */
 #define CONFIG_SETUP_MEMORY_TAGS
-- 
1.9.1

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

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

[Bin Meng]

On Thu, Feb 18, 2016 at 4:21 AM, Tom Rini  wrote:
> On Wed, Feb 17, 2016 at 05:10:33PM +0800, Bin Meng wrote:
>> Hi Jagan,
>>
>> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki  wrote:
>> > Hi Bin,
>> >
>> > On 17 February 2016 at 13:07, Jagan Teki  wrote:
>> >> Hi Bin,
>> >>
>> >> On 17 February 2016 at 10:52, Bin Meng  wrote:
>> >>> Hi Jagan,
>> >>>
>> >>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki  wrote:
>>  On 15 February 2016 at 02:16, Jagan Teki  wrote:
>> > Compared to previous patch series this series adds spi-nor
>> > core with spi-nor controller drivers are of "mtd uclass"
>> >
>> > This is whole series for all spi-nor related changes, and while
>> > series tested on spansion spi-nor chip.
>> >
>> > Know issue:
>> > - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>> >
>> > Why this framework:
>> >
>> > Some of the SPI device drivers at drivers/spi not a real
>> > spi controllers, Unlike normal/generic SPI controllers they
>> > operates only with SPI-NOR flash devices. these were technically
>> > termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>> >
>> > The problem with these were resides at drivers/spi is entire
>> > SPI layer becomes SPI-NOR flash oriented which is absolutely
>> > a wrong indication where SPI layer getting effected more with
>> > flash operations - So this SPI-NOR core will resolve this issue
>> > by separating all SPI-NOR flash operations from spi layer and
>> > creats a generic layer called SPI-NOR core which can be used to
>> > interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> > controller driver. The idea is taken from Linux spi-nor framework.
>> >
>> > Before SPI-NOR:
>> >
>> > ---
>> > cmd/sf.c
>> > ---
>> > spi_flash.c
>> > ---
>> > sf_probe.c
>> > ---
>> > spi-uclass
>> > ---
>> > spi drivers
>> > ---
>> > SPI NOR chip
>> > ---
>> >
>> > After SPI-NOR:
>> >
>> > --
>> > cmd/sf.c
>> > --
>> > spi-nor.c
>> > ---
>> > m25p80.cspi nor drivers
>> > ---
>> > spi-uclass  SPI NOR chip
>> > ---
>> > spi drivers
>> > ---
>> > SPI NOR chip
>> > ---
>> >
>> > SPI-NOR with MTD:
>> >
>> > --
>> > cmd/sf.c
>> > --
>> > MTD core
>> > --
>> > spi-nor.c
>> > ---
>> > m25p80.cspi nor drivers
>> > ---
>> > spi-uclass  SPI NOR chip
>> > ---
>> > spi drivers
>> > ---
>> > SPI NOR chip
>> > ---
>> >
>> > drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> > drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> > which is an interface layer b/w spi-nor core drivers/spi
>> > drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>> 
>>  Tested both DM and non-DM models
>> 
>>  Tested-by: Jagan Teki 
>> >>>
>> >>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>> >>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>> >>> Warning - bad CRC, using default environment
>> >>>
>> >>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>> >>> KiB, total 2 MiB
>> >>> *** Warning - bad CRC, using default environment
>> >>>
>> >>> Anything wrong?
>> >>
>> >>
>> >
>> >  I'm not getting the warning, after saveenv.
>> >
>> > DRAM:  ECC disabled 1 GiB
>> > MMC:
>> > spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
>> > KiB, total 16 MiB
>> > In:serial@e0001000
>> > Out:   serial@e0001000
>> > Err:   serial@e0001000
>> > Model: Zynq MicroZED Board
>> >
>>
>> Tested on another x86 board, still see the 'bad CRC' warning, log below:
>>
>> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
>>
>> CPU: x86, vendor Intel, device 590h
>> DRAM:  256 MiB
>> MMC:   Quark SDHCI: 0
>> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 
>> MiB
>> *** Warning - bad CRC, using default environment
>>
>> Model: Intel Galileo
>> Net:
>> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
>> eth0: 

[U-Boot] fdtgrep results in Segmentation fault for 64bit DT

[Masahiro Yamada]

Hi Simon,

I am working on U-Boot support on my new ARMv8 SoC.
I was hit by a problem with fdtgrep.

(Note: CONFIG_SPL_OF_CONTROL is on UniPhier SoC family)



  CC  spl/lib/time.o
  CC  spl/lib/rand.o
  CC  spl/lib/vsprintf.o
  CC  spl/lib/panic.o
  CC  spl/lib/strto.o
  LD  spl/lib/built-in.o
  LDS spl/u-boot-spl.lds
  LD  spl/u-boot-spl
  OBJCOPY spl/u-boot-spl-nodtb.bin
  FDTGREP spl/u-boot-spl.dtb
Error: FDT_ERR_BADMAGIC
make[2]: *** [spl/u-boot-spl.dtb] Error 1
make[1]: *** [spl/u-boot-spl] Error 2
make[1]: Leaving directory `/home/yamada/workspace/u-boot-unph'
make: *** [u-boot] Error 2



On my command line,

$ tools/fdtgrep -b u-boot,dm-pre-reloc  -RT  dts/dt.dtb  -n /chosen -O dtb
Segmentation fault (core dumped)


Could you take a look?


My DT looks like follows:
(It was taken from
linux/arch/arm/boot/dts/socionext/uniphier-ph1-ld10-ref.dts, and it is
working on Linux.
I just added "u-boot,dm-pre-reloc" to some nodes.  So it should be correct.)

yamada@beagle:~/workspace/u-boot-unph$ fdtdump dts/dt.dtb
/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x18f8 (6392)
// off_dt_struct: 0x38
// off_dt_strings: 0x178c
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 16
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x16c
// size_dt_struct: 0x1754

/ {
compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
#address-cells = <0x0002>;
#size-cells = <0x0002>;
interrupt-parent = <0x0001>;
model = "UniPhier PH1-LD10 Reference Board";
cpus {
#address-cells = <0x0002>;
#size-cells = <0x>;
cpu-map {
cluster0 {
core0 {
cpu = <0x0002>;
};
core1 {
cpu = <0x0003>;
};
};
cluster1 {
core0 {
cpu = <0x0004>;
};
core1 {
cpu = <0x0005>;
};
};
};
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a72", "arm,armv8";
reg = <0x 0x>;
enable-method = "spin-table";
cpu-release-addr = <0x 0x8100>;
linux,phandle = <0x0002>;
phandle = <0x0002>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a72", "arm,armv8";
reg = <0x 0x0001>;
enable-method = "spin-table";
cpu-release-addr = <0x 0x8100>;
linux,phandle = <0x0003>;
phandle = <0x0003>;
};
cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x 0x0100>;
enable-method = "spin-table";
cpu-release-addr = <0x 0x8100>;
linux,phandle = <0x0004>;
phandle = <0x0004>;
};
cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a53", "arm,armv8";
reg = <0x 0x0101>;
enable-method = "spin-table";
cpu-release-addr = <0x 0x8100>;
linux,phandle = <0x0005>;
phandle = <0x0005>;
};
};
clocks {
uart_clk {
#clock-cells = <0x>;
compatible = "fixed-clock";
clock-frequency = <0x038185a0>;
linux,phandle = <0x0007>;
phandle = <0x0007>;
};
i2c_clk {
#clock-cells = <0x>;
compatible = "fixed-clock";
clock-frequency = <0x02faf080>;
linux,phandle = <0x000c>;
phandle = <0x000c>;
};
};
timer {
compatible = "arm,armv8-timer";
interrupts = <0x0001 0x000d 0x0f01 0x0001
0x000e 0x0f01 0x0001 0x000b 0x0f01 0x0001
0x000a 0x0f01>;
};
soc {
compatible = "simple-bus";
#address-cells = <0x0001>;
#size-cells = <0x0001>;
ranges = <0x 0x 0x 0x>;
u-boot,dm-pre-reloc;
serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "okay";
reg = <0x54006800 0x0040>;
interrupts = <0x 0x0021 0x0004>;
pinctrl-names = "default";
pinctrl-0 = <0x0006>;
clocks = <0x0007>;
u-boot,dm-pre-reloc;
};
serial@54006900 {
compatible = "socionext,uniphier-uart";
status = "disabled";
reg = <0x54006900 0x0040>;
interrupts = <0x 0x0023 0x0004>;
pinctrl-names = "default";
pinctrl-0 = <0x0008>;
clocks 

Re: [U-Boot] [PATCH] dts: keep clock-names and clocks in SPL DTB if SPL_CLK is enabled

[Masahiro Yamada]

Simon,


Any comment on this patch?



2016-02-03 20:51 GMT+09:00 Masahiro Yamada :
> These two properties are necessary for SPL to get clocks from DT.
>
> Note:
> For now, only clock look-up by index is supported (clk_get_by_index()
> function), so "clock-names" is never parsed in U-Boot.  However, we
> may want to support something like clk_get_by_name() in the future,
> so let's keep "clock-names" as well as "clocks".
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  dts/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/dts/Kconfig b/dts/Kconfig
> index fb2d79e..d639be9 100644
> --- a/dts/Kconfig
> +++ b/dts/Kconfig
> @@ -61,7 +61,9 @@ config DEFAULT_DEVICE_TREE
>  config OF_SPL_REMOVE_PROPS
> string "List of device tree properties to drop for SPL"
> depends on SPL_OF_CONTROL
> +   default "interrupt-parent" if SPL_PINCTRL_FULL && SPL_CLK
> default "clocks clock-names interrupt-parent" if SPL_PINCTRL_FULL
> +   default "pinctrl-0 pinctrl-names interrupt-parent" if SPL_CLK
> default "pinctrl-0 pinctrl-names clocks clock-names interrupt-parent"
> help
>   Since SPL normally runs in a reduced memory space, the device tree
> --
> 1.9.1
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



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

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

[Moritz Fischer]

On Tue, Feb 16, 2016 at 11:39 PM, Michal Simek  wrote:
> Use RAM support in jtagboot mode.
>
> Signed-off-by: Michal Simek 
Reviewed-by: Moritz Fischer 

Looks good to me,

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

Re: [U-Boot] GSoC projects for Minnowboard MAX

[Bin Meng]

Hi Simon,

On Thu, Feb 18, 2016 at 12:35 AM, Simon Glass  wrote:
> +Bin
>
> Hi Hans,
>
> On 11 February 2016 at 08:44, Hans de Goede  wrote:
>> Hi,
>>
>> On 11-02-16 13:16, Simon Glass wrote:
>>>
>>> Hi,
>>>
>>> Minnowboard is looking for GSoC projects this year.
>>>
>>> http://wiki.minnowboard.org/GSoC2016
>>>
>>> There are a few things listed in README.x86 to be done. Any ideas?
>>
>>
>> Maybe speed up USB port scan ? This really needs to be parallelized
>> by using some for of cooperative multi-tasking.
>>
>> For starters just parallelizing the scanning of separate controllers
>> in drivers/usb/host/usb-uclass.c: usb_init() by splitting
>> usb_scan_bus() into a  usb_scan_bus_start() and usb_scan_bus_get_status()
>> with the latter being called repeatedly until all busses are done
>> would already help. Then do something similar for scanning all
>> ports of a hub in "parallel", etc.
>
> Yes that sounds good. There is a lot that could be done there. Are you
> interested in mentoring a student?
>
> Ideas I have are to port U-Boot to 64-bit, also enable the EFI image
> support for x86 (for running grub). Or perhaps just support the grub
> format.
>
> Bin, do you have any thoughts?
>

What about enable distro configuration for x86? If there are
limitations due to ACPI on Minnowmax, maybe we can switch to QEMU
instead?

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

[U-Boot] [PATCH] mx7dsabresd: Use Adrian's NXP email address

[Fabio Estevam]

Use the new NXP email address for the board maintainer.

Signed-off-by: Fabio Estevam 
---
 board/freescale/mx7dsabresd/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/mx7dsabresd/MAINTAINERS 
b/board/freescale/mx7dsabresd/MAINTAINERS
index 3910ee4..b96642a 100644
--- a/board/freescale/mx7dsabresd/MAINTAINERS
+++ b/board/freescale/mx7dsabresd/MAINTAINERS
@@ -1,5 +1,5 @@
 MX7DSABRESD BOARD
-M: Adrian Alonso 
+M: Adrian Alonso 
 S: Maintained
 F: board/freescale/mx7dsabresd
 F: include/configs/mx7dsabresd.h
-- 
1.9.1

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

[U-Boot] Newbie SPL question for socfpga_sockit

[George Broz]

Hello,

Sorry for the newbie question...

I have an Altera/Terasic board (socfpga_sockit) that has issues recognizing
USB storage devices (roughly 60% good / 40% bad):

SOCFPGA_CYCLONE5 # usb start
(Re)start USB...
USB0: scanning bus 0 for devices... DW_USB: Transfer completion
interrupt timeout
Timed out waiting for channel to disable
1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found


The pre-made U-Boot SPL & image that come with the board have version:
U-Boot 2013.01.01 (Aug 08 2014 - 10:46:23)

(Old!)

I need to rebuild U-Boot for this board to add md5sum and hopefully fix the
USB issues. When I've rebuilt the u-boot.img from the 2013.01.01 branch
of the (Altera maintained) source, U-boot boots, but the USB problems
get worse (100% bad):

USB0: Core Release: 2.93a
dwc_otg_core_host_init: Unable to clear halt on channel 1 (timeout
HCCHAR 0xC000 @ffb40520)
dwc_otg_core_host_init: Unable to clear halt on channel 2 (timeout
HCCHAR 0xC000 @ffb40540

(I've confirmed that CONFIG_CMD_USB and CONFIG_USB_STORAGE are
defined and have tried turning on and off 'dcache' as suggested elsewhere
to no avail).

If I try a later release (e.g. v2016.01 which seems to support the Terasic
board explicitly) the boot process stops just after loading the SPL.

At this point I have only been changing the u-boot.img component, not the
SPL (in the a2 partition of the MMC).

The documentation from Altera about generating the SPL seems to require
using Qsys/Quartus tools which I'd really like to avoid.

I can produce u-boot-spl.bin / u-boot.img from
make socfpga_sockit_defconfig; make all.

My newbie question ... should be I able to use directly the u-boot-spl.bin
generated by the build to replace the SPL on the board?

(I'm hoping the USB issues resolve themselves when I'm able to get
the later version of U-Boot running...)


Thanks for any input...

--George Broz
Moog Industrial Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] mx7dsabresd: Make 'ums' command functional

[Fabio Estevam]

When running the 'ums' command we get:

=> ums 0 mmc 0
UMS: disk start sector: 0x0, count: 0xe18000
g_dnl_register: failed!, error: -22
ERROR: g_dnl_register failed
at common/cmd_usb_mass_storage.c:107/do_usb_mass_storage()

Fix this by initializing USB OTG1 port as USB device mode instead of host.

Signed-off-by: Fabio Estevam 
---
 board/freescale/mx7dsabresd/mx7dsabresd.c | 41 ++-
 1 file changed, 18 insertions(+), 23 deletions(-)

diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c 
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index fee24e2..4d0b195 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -111,6 +112,14 @@ static iomux_v3_cfg_t const usdhc3_emmc_pads[] = {
MX7D_PAD_SD3_RESET_B__GPIO6_IO11 | MUX_PAD_CTRL(USDHC_PAD_CTRL),
 };
 
+static iomux_v3_cfg_t const usb_otg1_pads[] = {
+   MX7D_PAD_GPIO1_IO05__USB_OTG1_PWR | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
+static iomux_v3_cfg_t const usb_otg2_pads[] = {
+   MX7D_PAD_UART3_CTS_B__USB_OTG2_PWR | MUX_PAD_CTRL(NO_PAD_CTRL),
+};
+
 #define IOX_SDI IMX_GPIO_NR(1, 9)
 #define IOX_STCP IMX_GPIO_NR(1, 12)
 #define IOX_SHCP IMX_GPIO_NR(1, 13)
@@ -511,6 +520,10 @@ int board_early_init_f(void)
setup_iomux_uart();
 
setup_i2c(0, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info1);
+   imx_iomux_v3_setup_multiple_pads(usb_otg1_pads,
+ARRAY_SIZE(usb_otg1_pads));
+   imx_iomux_v3_setup_multiple_pads(usb_otg2_pads,
+ARRAY_SIZE(usb_otg2_pads));
 
return 0;
 }
@@ -602,29 +615,11 @@ int checkboard(void)
 }
 
 #ifdef CONFIG_USB_EHCI_MX7
-static iomux_v3_cfg_t const usb_otg1_pads[] = {
-   MX7D_PAD_GPIO1_IO05__USB_OTG1_PWR | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-static iomux_v3_cfg_t const usb_otg2_pads[] = {
-   MX7D_PAD_UART3_CTS_B__USB_OTG2_PWR | MUX_PAD_CTRL(NO_PAD_CTRL),
-};
-
-int board_ehci_hcd_init(int port)
+int board_usb_phy_mode(int port)
 {
-   switch (port) {
-   case 0:
-   imx_iomux_v3_setup_multiple_pads(usb_otg1_pads,
-ARRAY_SIZE(usb_otg1_pads));
-   break;
-   case 1:
-   imx_iomux_v3_setup_multiple_pads(usb_otg2_pads,
-ARRAY_SIZE(usb_otg2_pads));
-   break;
-   default:
-   printf("MXC USB port %d not yet supported\n", port);
-   return -EINVAL;
-   }
-   return 0;
+   if (port == 0)
+   return USB_INIT_DEVICE;
+   else
+   return USB_INIT_HOST;
 }
 #endif
-- 
1.9.1

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

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

[Jagan Teki]

Hi Simon,

On 18 February 2016 at 01:38, Jagan Teki  wrote:
> Hi Simon,
>
> On 18 February 2016 at 00:30, Simon Glass  wrote:
>> Hi Jagan,
>>
>> On 14 February 2016 at 13:46, Jagan Teki  wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> ---
>>> cmd/sf.c
>>> ---
>>> spi_flash.c
>>> ---
>>> sf_probe.c
>>> ---
>>> spi-uclass
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> After SPI-NOR:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> SPI-NOR with MTD:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> MTD core
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Changes for v6:
>>> - Fixed git bisectable issues, with buildman.
>>> - Fixed spi-nor compilation issues
>>> - newly designed changes.
>>>
>>> Changes for v5:
>>> - newly designed changes
>>>
>>> Testing:
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b spi-nor origin/spi-nor
>>
>> I see quite a large rodata increase at this commit. Is it necessary?
>>
>> 67: configs: Use CONFIG_SPI_NOR_MISC
>>arm: (for 1/1 boards)  all +2434.0  bss +56.0  rodata +1994.0
>> text +384.0
>>
>> There are also bisectability problems (build errors for some commits)
>> - e.g. chromebook_jerry.
>
> Yes, this I missed defining SPI_NOR config will update that.

u-boot-spi/spi-nor updated, let me know if you find any build issues.

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

Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available

[Tom Rini]

On Wed, Feb 17, 2016 at 09:09:27AM +0100, Guillaume GARDET wrote:

> Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
> spl: mmc: add break statements in spl_mmc_load_image() 
> RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW fails, 
> the
> board hangs. This patch allows to try MMCSD_MODE_FS then, if available.
> 
> It has been tested on a beaglebone black to boot on an EXT partition.
> 
> Signed-off-by: Guillaume GARDET 
> Cc: Tom Rini 
> Cc: Nikita Kiryanov 
> Cc: Igor Grinberg 
> Cc: Paul Kocialkowski 
> Cc: Pantelis Antoniou 
> Cc: Simon Glass 
> Cc: Matwey V. Kornilov 
> 
> ---
>  common/spl/spl_mmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index c3931c6..2eef0f2 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
>   if (!err)
>   return err;
>  #endif
> - break;
> + /* Fall through */
>   case MMCSD_MODE_FS:
>   debug("spl: mmc boot mode: fs\n");

This also essentially reverts fd61d399.  So Nikita, was there a specific
use case that was broken before, or was the code just unclear in
intentions here?  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] gpio: Add DM GPIO driver for Marvell MVEBU

[Kevin Smith]

On 02/12/2016 06:46 AM, Stefan Roese wrote:
> This patch adds a DM GPIO driver for the Marvell MVEBU SoCs. There are
> other non-DM drivers that might be used on these platforms. But this
> patch creates a new DM driver. Which will be used by all Armada XP/38x
> boards. Other MVEBU SoC (Kirkwood / Orion) may follow once they
> support DM as well.
>
> Signed-off-by: Stefan Roese 
> Cc: Dirk Eibach 
> Cc: Phil Sutter 
> Cc: Kevin Smith 
> Cc: Luka Perkov 
> Cc: Tom Rini 
> ---
>
Reviewed-by: Kevin Smith 
Tested-by: Kevin Smith 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Tom Rini]

On Wed, Feb 17, 2016 at 05:10:33PM +0800, Bin Meng wrote:
> Hi Jagan,
> 
> On Wed, Feb 17, 2016 at 3:38 PM, Jagan Teki  wrote:
> > Hi Bin,
> >
> > On 17 February 2016 at 13:07, Jagan Teki  wrote:
> >> Hi Bin,
> >>
> >> On 17 February 2016 at 10:52, Bin Meng  wrote:
> >>> Hi Jagan,
> >>>
> >>> On Wed, Feb 17, 2016 at 3:47 AM, Jagan Teki  wrote:
>  On 15 February 2016 at 02:16, Jagan Teki  wrote:
> > Compared to previous patch series this series adds spi-nor
> > core with spi-nor controller drivers are of "mtd uclass"
> >
> > This is whole series for all spi-nor related changes, and while
> > series tested on spansion spi-nor chip.
> >
> > Know issue:
> > - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
> >
> > Why this framework:
> >
> > Some of the SPI device drivers at drivers/spi not a real
> > spi controllers, Unlike normal/generic SPI controllers they
> > operates only with SPI-NOR flash devices. these were technically
> > termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
> >
> > The problem with these were resides at drivers/spi is entire
> > SPI layer becomes SPI-NOR flash oriented which is absolutely
> > a wrong indication where SPI layer getting effected more with
> > flash operations - So this SPI-NOR core will resolve this issue
> > by separating all SPI-NOR flash operations from spi layer and
> > creats a generic layer called SPI-NOR core which can be used to
> > interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> > controller driver. The idea is taken from Linux spi-nor framework.
> >
> > Before SPI-NOR:
> >
> > ---
> > cmd/sf.c
> > ---
> > spi_flash.c
> > ---
> > sf_probe.c
> > ---
> > spi-uclass
> > ---
> > spi drivers
> > ---
> > SPI NOR chip
> > ---
> >
> > After SPI-NOR:
> >
> > --
> > cmd/sf.c
> > --
> > spi-nor.c
> > ---
> > m25p80.cspi nor drivers
> > ---
> > spi-uclass  SPI NOR chip
> > ---
> > spi drivers
> > ---
> > SPI NOR chip
> > ---
> >
> > SPI-NOR with MTD:
> >
> > --
> > cmd/sf.c
> > --
> > MTD core
> > --
> > spi-nor.c
> > ---
> > m25p80.cspi nor drivers
> > ---
> > spi-uclass  SPI NOR chip
> > ---
> > spi drivers
> > ---
> > SPI NOR chip
> > ---
> >
> > drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> > drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> > which is an interface layer b/w spi-nor core drivers/spi
> > drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
> 
>  Tested both DM and non-DM models
> 
>  Tested-by: Jagan Teki 
> >>>
> >>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
> >>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
> >>> Warning - bad CRC, using default environment
> >>>
> >>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
> >>> KiB, total 2 MiB
> >>> *** Warning - bad CRC, using default environment
> >>>
> >>> Anything wrong?
> >>
> >>
> >
> >  I'm not getting the warning, after saveenv.
> >
> > DRAM:  ECC disabled 1 GiB
> > MMC:
> > spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
> > KiB, total 16 MiB
> > In:serial@e0001000
> > Out:   serial@e0001000
> > Err:   serial@e0001000
> > Model: Zynq MicroZED Board
> >
> 
> Tested on another x86 board, still see the 'bad CRC' warning, log below:
> 
> U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)
> 
> CPU: x86, vendor Intel, device 590h
> DRAM:  256 MiB
> MMC:   Quark SDHCI: 0
> spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 
> MiB
> *** Warning - bad CRC, using default environment
> 
> Model: Intel Galileo
> Net:
> Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
> eth0: eth_designware#0
> Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
> , eth1: eth_designware#1
> Hit any key to stop autoboot:  0
> => saveenv
> Saving Environment to SPI Flash...
> 

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

[Jagan Teki]

Hi Simon,

On 18 February 2016 at 00:30, Simon Glass  wrote:
> Hi Jagan,
>
> On 14 February 2016 at 13:46, Jagan Teki  wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> ---
>> cmd/sf.c
>> ---
>> spi_flash.c
>> ---
>> sf_probe.c
>> ---
>> spi-uclass
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> After SPI-NOR:
>>
>> --
>> cmd/sf.c
>> --
>> spi-nor.c
>> ---
>> m25p80.cspi nor drivers
>> ---
>> spi-uclass  SPI NOR chip
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> SPI-NOR with MTD:
>>
>> --
>> cmd/sf.c
>> --
>> MTD core
>> --
>> spi-nor.c
>> ---
>> m25p80.cspi nor drivers
>> ---
>> spi-uclass  SPI NOR chip
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Changes for v6:
>> - Fixed git bisectable issues, with buildman.
>> - Fixed spi-nor compilation issues
>> - newly designed changes.
>>
>> Changes for v5:
>> - newly designed changes
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor origin/spi-nor
>
> I see quite a large rodata increase at this commit. Is it necessary?
>
> 67: configs: Use CONFIG_SPI_NOR_MISC
>arm: (for 1/1 boards)  all +2434.0  bss +56.0  rodata +1994.0
> text +384.0
>
> There are also bisectability problems (build errors for some commits)
> - e.g. chromebook_jerry.

Yes, this I missed defining SPI_NOR config will update that.

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

[U-Boot] [PATCH] mx6ul_14x14_evk: Select CONFIG_FSL_QSPI

[Fabio Estevam]

From: Fabio Estevam 

Select CONFIG_FSL_QSPI so that the SPI can be probed:

=> sf probe
SF: Detected N25Q256 with page size 256 Bytes, erase size 64 KiB, total 32 MiB

Signed-off-by: Fabio Estevam 
---
 include/configs/mx6ul_14x14_evk.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/mx6ul_14x14_evk.h 
b/include/configs/mx6ul_14x14_evk.h
index 4374c3a..c7e10f9 100644
--- a/include/configs/mx6ul_14x14_evk.h
+++ b/include/configs/mx6ul_14x14_evk.h
@@ -195,6 +195,7 @@
 #define CONFIG_CMD_CACHE
 #endif
 
+#define CONFIG_FSL_QSPI
 #ifdef CONFIG_FSL_QSPI
 #define CONFIG_CMD_SF
 #define CONFIG_SPI_FLASH
-- 
1.9.1

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

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

[Jagan Teki]

Hi Simon,

On 18 February 2016 at 00:44, Jagan Teki  wrote:
> Hi Simon,
>
> On 18 February 2016 at 00:30, Simon Glass  wrote:
>> Hi Jagan,
>>
>> On 14 February 2016 at 13:46, Jagan Teki  wrote:
>>> Compared to previous patch series this series adds spi-nor
>>> core with spi-nor controller drivers are of "mtd uclass"
>>>
>>> This is whole series for all spi-nor related changes, and while
>>> series tested on spansion spi-nor chip.
>>>
>>> Know issue:
>>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>>
>>> Why this framework:
>>>
>>> Some of the SPI device drivers at drivers/spi not a real
>>> spi controllers, Unlike normal/generic SPI controllers they
>>> operates only with SPI-NOR flash devices. these were technically
>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>>
>>> The problem with these were resides at drivers/spi is entire
>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>>> a wrong indication where SPI layer getting effected more with
>>> flash operations - So this SPI-NOR core will resolve this issue
>>> by separating all SPI-NOR flash operations from spi layer and
>>> creats a generic layer called SPI-NOR core which can be used to
>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>>> controller driver. The idea is taken from Linux spi-nor framework.
>>>
>>> Before SPI-NOR:
>>>
>>> ---
>>> cmd/sf.c
>>> ---
>>> spi_flash.c
>>> ---
>>> sf_probe.c
>>> ---
>>> spi-uclass
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> After SPI-NOR:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> SPI-NOR with MTD:
>>>
>>> --
>>> cmd/sf.c
>>> --
>>> MTD core
>>> --
>>> spi-nor.c
>>> ---
>>> m25p80.cspi nor drivers
>>> ---
>>> spi-uclass  SPI NOR chip
>>> ---
>>> spi drivers
>>> ---
>>> SPI NOR chip
>>> ---
>>>
>>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>>> which is an interface layer b/w spi-nor core drivers/spi
>>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>>
>>> Changes for v6:
>>> - Fixed git bisectable issues, with buildman.
>>> - Fixed spi-nor compilation issues
>>> - newly designed changes.
>>>
>>> Changes for v5:
>>> - newly designed changes
>>>
>>> Testing:
>>> $ git clone git://git.denx.de/u-boot-spi.git
>>> $ cd u-boot-spi
>>> $ git checkout -b spi-nor origin/spi-nor
>>
>> I see quite a large rodata increase at this commit. Is it necessary?
>
> If ie the case then we need to revert the vendor configs w/o add them
> into CONFIG_SPI_NOR_MISC.
>
>>
>> 67: configs: Use CONFIG_SPI_NOR_MISC
>>arm: (for 1/1 boards)  all +2434.0  bss +56.0  rodata +1994.0
>> text +384.0

I couldn't find rodata section for this commit[1] am I missing anything?

[1] http://paste.ubuntu.com/15101966/

>>
>> There are also bisectability problems (build errors for some commits)
>> - e.g. chromebook_jerry.
>
> Did you pick u-boot-spi/spi-nor?

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

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

[Jagan Teki]

Hi Simon,

On 18 February 2016 at 00:30, Simon Glass  wrote:
> Hi Jagan,
>
> On 14 February 2016 at 13:46, Jagan Teki  wrote:
>> Compared to previous patch series this series adds spi-nor
>> core with spi-nor controller drivers are of "mtd uclass"
>>
>> This is whole series for all spi-nor related changes, and while
>> series tested on spansion spi-nor chip.
>>
>> Know issue:
>> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>>
>> Why this framework:
>>
>> Some of the SPI device drivers at drivers/spi not a real
>> spi controllers, Unlike normal/generic SPI controllers they
>> operates only with SPI-NOR flash devices. these were technically
>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>>
>> The problem with these were resides at drivers/spi is entire
>> SPI layer becomes SPI-NOR flash oriented which is absolutely
>> a wrong indication where SPI layer getting effected more with
>> flash operations - So this SPI-NOR core will resolve this issue
>> by separating all SPI-NOR flash operations from spi layer and
>> creats a generic layer called SPI-NOR core which can be used to
>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
>> controller driver. The idea is taken from Linux spi-nor framework.
>>
>> Before SPI-NOR:
>>
>> ---
>> cmd/sf.c
>> ---
>> spi_flash.c
>> ---
>> sf_probe.c
>> ---
>> spi-uclass
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> After SPI-NOR:
>>
>> --
>> cmd/sf.c
>> --
>> spi-nor.c
>> ---
>> m25p80.cspi nor drivers
>> ---
>> spi-uclass  SPI NOR chip
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> SPI-NOR with MTD:
>>
>> --
>> cmd/sf.c
>> --
>> MTD core
>> --
>> spi-nor.c
>> ---
>> m25p80.cspi nor drivers
>> ---
>> spi-uclass  SPI NOR chip
>> ---
>> spi drivers
>> ---
>> SPI NOR chip
>> ---
>>
>> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
>> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
>> which is an interface layer b/w spi-nor core drivers/spi
>> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)
>>
>> Changes for v6:
>> - Fixed git bisectable issues, with buildman.
>> - Fixed spi-nor compilation issues
>> - newly designed changes.
>>
>> Changes for v5:
>> - newly designed changes
>>
>> Testing:
>> $ git clone git://git.denx.de/u-boot-spi.git
>> $ cd u-boot-spi
>> $ git checkout -b spi-nor origin/spi-nor
>
> I see quite a large rodata increase at this commit. Is it necessary?

If ie the case then we need to revert the vendor configs w/o add them
into CONFIG_SPI_NOR_MISC.

>
> 67: configs: Use CONFIG_SPI_NOR_MISC
>arm: (for 1/1 boards)  all +2434.0  bss +56.0  rodata +1994.0
> text +384.0
>
> There are also bisectability problems (build errors for some commits)
> - e.g. chromebook_jerry.

Did you pick u-boot-spi/spi-nor?

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

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

[Simon Glass]

Hi Jagan,

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

I see quite a large rodata increase at this commit. Is it necessary?

67: configs: Use CONFIG_SPI_NOR_MISC
   arm: (for 1/1 boards)  all +2434.0  bss +56.0  rodata +1994.0
text +384.0

There are also bisectability problems (build errors for some commits)
- e.g. chromebook_jerry.

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

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

[Simon Glass]

On 17 February 2016 at 00:55, Jeffy Chen  wrote:
>
> From: Lin Huang 
>
> emac may use dpll as clock parent, and it request the clock frequency
> multiples of 50, so change ddr frequency to 400M.
>
> Signed-off-by: Lin Huang 
> Signed-off-by: Jeffy Chen 
>
> ---
>
>  arch/arm/mach-rockchip/rk3036/sdram_rk3036.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)


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

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

[Simon Glass]

On 16 February 2016 at 15:29, Andreas Bießmann
 wrote:
> Since OpenSSL is deprecated on OS X in favour of Common Crypto API disable the
> warning for this host OS.
>
> Another solution would be to add some glue layer for crypto stuff, but I think
> this is not worth the effort.
>
> Signed-off-by: Andreas Bießmann 
> ---
>
>  tools/Makefile | 8 
>  1 file changed, 8 insertions(+)

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

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

[Stephen Warren]

On 02/17/2016 10:32 AM, Heiko Schocher wrote:

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


Tested-by: Stephen Warren 
Reviewed-by: Stephen Warren 

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

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

[Heiko Schocher]

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

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

Changes in v3:
- add comments from Stephen Warren:
  change incorrect "bcfg = u_boot_console.config.buildconfig"
  init into "bcfg = self.config.buildconfig"

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

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

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

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

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

[Heiko Schocher]

Hello Stephen,

Am 17.02.2016 um 17:45 schrieb Stephen Warren:

On 02/16/2016 11:48 PM, Heiko Schocher wrote:

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


I suspect you didn't test this; it causes all tests to fail on all platforms...


Damn, yes, seems I overlooked this issue, while trying to get
test/py running for the smartweb board.


diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py



+bcfg = u_boot_console.config.buildconfig


I think that should be self.config.buildconfig instead; there is no 
u_boot_console variable at this
point in the code.


fixed.

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

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

[Stephen Warren]

On 02/16/2016 11:48 PM, Heiko Schocher wrote:

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


I suspect you didn't test this; it causes all tests to fail on all 
platforms...



diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py



+bcfg = u_boot_console.config.buildconfig


I think that should be self.config.buildconfig instead; there is no 
u_boot_console variable at this point in the code.

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

Re: [U-Boot] GSoC projects for Minnowboard MAX

[Simon Glass]

+Bin

Hi Hans,

On 11 February 2016 at 08:44, Hans de Goede  wrote:
> Hi,
>
> On 11-02-16 13:16, Simon Glass wrote:
>>
>> Hi,
>>
>> Minnowboard is looking for GSoC projects this year.
>>
>> http://wiki.minnowboard.org/GSoC2016
>>
>> There are a few things listed in README.x86 to be done. Any ideas?
>
>
> Maybe speed up USB port scan ? This really needs to be parallelized
> by using some for of cooperative multi-tasking.
>
> For starters just parallelizing the scanning of separate controllers
> in drivers/usb/host/usb-uclass.c: usb_init() by splitting
> usb_scan_bus() into a  usb_scan_bus_start() and usb_scan_bus_get_status()
> with the latter being called repeatedly until all busses are done
> would already help. Then do something similar for scanning all
> ports of a hub in "parallel", etc.

Yes that sounds good. There is a lot that could be done there. Are you
interested in mentoring a student?

Ideas I have are to port U-Boot to 64-bit, also enable the EFI image
support for x86 (for running grub). Or perhaps just support the grub
format.

Bin, do you have any thoughts?

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

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

[Stephen Warren]

On 02/16/2016 06:09 PM, Simon Glass wrote:

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


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

[U-Boot] [PATCH 3/4] Fix FreeBSD loader API so that it works on both 32-bit and 64-bit targets.

[Stanislav Galabov]

Specifically tested on MIPS under QEMU (works with all  combination of bit-ness 
and endian-ness)

Signed-off-by: Stanislav Galabov 
---
 api/api.c | 58 +--
 examples/api/Makefile |  4 
 examples/api/crt0.S   | 13 ++--
 examples/api/glue.c   | 18 
 4 files changed, 49 insertions(+), 44 deletions(-)

diff --git a/api/api.c b/api/api.c
index c5f6edb..ae1160c 100644
--- a/api/api.c
+++ b/api/api.c
@@ -52,7 +52,7 @@ static int API_getc(va_list ap)
 {
int *c;
 
-   if ((c = (int *)va_arg(ap, u_int32_t)) == NULL)
+   if ((c = (int *)va_arg(ap, uintptr_t)) == NULL)
return API_EINVAL;
 
*c = getc();
@@ -68,7 +68,7 @@ static int API_tstc(va_list ap)
 {
int *t;
 
-   if ((t = (int *)va_arg(ap, u_int32_t)) == NULL)
+   if ((t = (int *)va_arg(ap, uintptr_t)) == NULL)
return API_EINVAL;
 
*t = tstc();
@@ -84,7 +84,7 @@ static int API_putc(va_list ap)
 {
char *c;
 
-   if ((c = (char *)va_arg(ap, u_int32_t)) == NULL)
+   if ((c = (char *)va_arg(ap, uintptr_t)) == NULL)
return API_EINVAL;
 
putc(*c);
@@ -100,7 +100,7 @@ static int API_puts(va_list ap)
 {
char *s;
 
-   if ((s = (char *)va_arg(ap, u_int32_t)) == NULL)
+   if ((s = (char *)va_arg(ap, uintptr_t)) == NULL)
return API_EINVAL;
 
puts(s);
@@ -132,7 +132,7 @@ static int API_get_sys_info(va_list ap)
 {
struct sys_info *si;
 
-   si = (struct sys_info *)va_arg(ap, u_int32_t);
+   si = (struct sys_info *)va_arg(ap, uintptr_t);
if (si == NULL)
return API_ENOMEM;
 
@@ -148,7 +148,7 @@ static int API_udelay(va_list ap)
 {
unsigned long *d;
 
-   if ((d = (unsigned long *)va_arg(ap, u_int32_t)) == NULL)
+   if ((d = (unsigned long *)va_arg(ap, unsigned long)) == NULL)
return API_EINVAL;
 
udelay(*d);
@@ -164,11 +164,11 @@ static int API_get_timer(va_list ap)
 {
unsigned long *base, *cur;
 
-   cur = (unsigned long *)va_arg(ap, u_int32_t);
+   cur = (unsigned long *)va_arg(ap, unsigned long);
if (cur == NULL)
return API_EINVAL;
 
-   base = (unsigned long *)va_arg(ap, u_int32_t);
+   base = (unsigned long *)va_arg(ap, unsigned long);
if (base == NULL)
return API_EINVAL;
 
@@ -199,7 +199,7 @@ static int API_dev_enum(va_list ap)
struct device_info *di;
 
/* arg is ptr to the device_info struct we are going to fill out */
-   di = (struct device_info *)va_arg(ap, u_int32_t);
+   di = (struct device_info *)va_arg(ap, uintptr_t);
if (di == NULL)
return API_EINVAL;
 
@@ -233,7 +233,7 @@ static int API_dev_open(va_list ap)
int err = 0;
 
/* arg is ptr to the device_info struct */
-   di = (struct device_info *)va_arg(ap, u_int32_t);
+   di = (struct device_info *)va_arg(ap, uintptr_t);
if (di == NULL)
return API_EINVAL;
 
@@ -265,7 +265,7 @@ static int API_dev_close(va_list ap)
int err = 0;
 
/* arg is ptr to the device_info struct */
-   di = (struct device_info *)va_arg(ap, u_int32_t);
+   di = (struct device_info *)va_arg(ap, uintptr_t);
if (di == NULL)
return API_EINVAL;
 
@@ -319,7 +319,7 @@ static int API_dev_write(va_list ap)
int err = 0;
 
/* 1. arg is ptr to the device_info struct */
-   di = (struct device_info *)va_arg(ap, u_int32_t);
+   di = (struct device_info *)va_arg(ap, uintptr_t);
if (di == NULL)
return API_EINVAL;
 
@@ -329,12 +329,12 @@ static int API_dev_write(va_list ap)
return API_ENODEV;
 
/* 2. arg is ptr to buffer from where to get data to write */
-   buf = (void *)va_arg(ap, u_int32_t);
+   buf = (void *)va_arg(ap, uintptr_t);
if (buf == NULL)
return API_EINVAL;
 
/* 3. arg is length of buffer */
-   len = (int *)va_arg(ap, u_int32_t);
+   len = (int *)va_arg(ap, uintptr_t);
if (len == NULL)
return API_EINVAL;
if (*len <= 0)
@@ -387,7 +387,7 @@ static int API_dev_read(va_list ap)
int *len_net, *act_len_net;
 
/* 1. arg is ptr to the device_info struct */
-   di = (struct device_info *)va_arg(ap, u_int32_t);
+   di = (struct device_info *)va_arg(ap, uintptr_t);
if (di == NULL)
return API_EINVAL;
 
@@ -397,23 +397,23 @@ static int API_dev_read(va_list ap)
return API_ENODEV;
 
/* 2. arg is ptr to buffer from where to put the read data */
-   buf = (void *)va_arg(ap, u_int32_t);
+   buf = (void *)va_arg(ap, uintptr_t);
if (buf == NULL)
return API_EINVAL;
 
if (di->type & DEV_TYP_STOR) {
/* 3. arg - ptr to var with # of 

[U-Boot] [PATCH 4/4] Add support for 64-bit MIPS to examples/standalone

[Stanislav Galabov]

Signed-off-by: Stanislav Galabov 
---
 examples/standalone/stubs.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
index 920a0a9..0d62067 100644
--- a/examples/standalone/stubs.c
+++ b/examples/standalone/stubs.c
@@ -65,6 +65,23 @@ gd_t *global_data;
: : "i"(offsetof(gd_t, jt)), "i"(FO(x)) : "ip");
 #endif
 #elif defined(CONFIG_MIPS)
+#ifdef CONFIG_CPU_MIPS64
+/*
+ * k0 ($26) holds the pointer to the global_data; t9 ($25) is a call-
+ * clobbered register that is also used to set gp ($26). Note that the
+ * jr instruction also executes the instruction immediately following
+ * it; however, GCC/mips generates an additional `nop' after each asm
+ * statement
+ */
+#define EXPORT_FUNC(f, a, x, ...) \
+   asm volatile (  \
+"  .globl " #x "\n"\
+#x ":\n"   \
+"  ld  $25, %0($26)\n" \
+"  ld  $25, %1($25)\n" \
+"  jr  $25\n"  \
+: : "i"(offsetof(gd_t, jt)), "i"(FO(x)) : "t9");
+#else
 /*
  * k0 ($26) holds the pointer to the global_data; t9 ($25) is a call-
  * clobbered register that is also used to set gp ($26). Note that the
@@ -80,6 +97,7 @@ gd_t *global_data;
 "  lw  $25, %1($25)\n" \
 "  jr  $25\n"  \
: : "i"(offsetof(gd_t, jt)), "i"(FO(x)) : "t9");
+#endif
 #elif defined(CONFIG_NIOS2)
 /*
  * gp holds the pointer to the global_data, r8 is call-clobbered
-- 
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/4] Use CONFIG_IDE_SWAP_IO when running on big-endian MIPS (32 or 64-bit) in QEMU so that IDE transfers work properly

[Stanislav Galabov]

Signed-off-by: Stanislav Galabov 
---
 include/configs/qemu-mips.h   | 4 
 include/configs/qemu-mips64.h | 4 
 2 files changed, 8 insertions(+)

diff --git a/include/configs/qemu-mips.h b/include/configs/qemu-mips.h
index 5a043d5..d31706c 100644
--- a/include/configs/qemu-mips.h
+++ b/include/configs/qemu-mips.h
@@ -61,6 +61,10 @@
 #define CONFIG_CMD_IDE
 #define CONFIG_DOS_PARTITION
 
+#ifdef CONFIG_SYS_BIG_ENDIAN
+#define CONFIG_IDE_SWAP_IO
+#endif
+
 #define CONFIG_SYS_IDE_MAXBUS  2
 #define CONFIG_SYS_ATA_IDE0_OFFSET 0x1f0
 #define CONFIG_SYS_ATA_IDE1_OFFSET 0x170
diff --git a/include/configs/qemu-mips64.h b/include/configs/qemu-mips64.h
index 070b5de..90551e8 100644
--- a/include/configs/qemu-mips64.h
+++ b/include/configs/qemu-mips64.h
@@ -61,6 +61,10 @@
 #define CONFIG_CMD_IDE
 #define CONFIG_DOS_PARTITION
 
+#ifdef CONFIG_SYS_BIG_ENDIAN
+#define CONFIG_IDE_SWAP_IO
+#endif
+
 #define CONFIG_SYS_IDE_MAXBUS  2
 #define CONFIG_SYS_ATA_IDE0_OFFSET 0x1f0
 #define CONFIG_SYS_ATA_IDE1_OFFSET 0x170
-- 
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 0/4] QEMU (qemu-mips) and MIPS 64-bit changes

[Stanislav Galabov]

Stanislav Galabov (4):
  - Properly calculate ATA_SECTORWORDS, using a fixed-size integer, so it
works for both 32-bit and 64-bit targets
  - Use CONFIG_IDE_SWAP_IO when running on big-endian MIPS (32 or 64-bit)
in QEMU so that IDE transfers work properly
  - Fix FreeBSD loader API so that it works on both 32-bit and 64-bit
targets. Specifically tested on MIPS under QEMU (works with all
combination of bit-ness and endian-ness)
  - Add support for 64-bit MIPS to examples/standalone

 api/api.c | 58 +--
 examples/api/Makefile |  4 +++
 examples/api/crt0.S   | 13 +-
 examples/api/glue.c   | 18 +++---
 examples/standalone/stubs.c   | 18 ++
 include/ata.h |  2 +-
 include/configs/qemu-mips.h   |  4 +++
 include/configs/qemu-mips64.h |  4 +++
 8 files changed, 76 insertions(+), 45 deletions(-)

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

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

[Belisko Marek]

Hi Simon,


On Thu, Jan 28, 2016 at 5:39 PM, Simon Glass  wrote:
> We need a way to support more than one board per binary in U-Boot with
> device tree. Various methods have been discussed. The one that seems to make
> the most sense is to adjust SPL so that it can load a FIT which contains
> U-Boot and several device tree binaries. This is how things with with Linux:
> load a FIT and select the correct device tree to pass to Linux.
Some time ago I rise question [0] to load FIT kernel directly in SPL
using falcon mode.
I did look at your patches and I have a feeling that with small
adaptions it should be possible?
Am I right or it's impossible? (Trying to use it on am33xx boards). Many thanks.
>
> This series:
>
> - Adjusts the build system to optionally build a u-boot.img in FIT format
> that includes the U-Boot binary and >1 device tree files
> - Adjusts SPL to support loading this
> - Adds a way for SPL to determine which device tree to select (by calling a
> board-specific function)
> - Adjusts SPL to pass this selected device tree to U-Boot when it starts
>
> It would be painful to require an .its file for each board just to support
> this feature. In any case various people have commented that it would be
> nice not to have to write this file in general. Therefore, this series
> enhances mkimage to automatically generate a FIT without a .its file. So far
> it understands how to add a main image and a number of device tree files. It
> does not support hashing or verified boot as yet.
>
> One problem with the FIT format as it stands is that all the data is inline.
> This means that the entire file must be read in order to figure out what
> device-tree files are available. It is then possible to copy the images into
> place.
>
> This is not really suitable for SPL since copying can be slow, and reading
> unnecessary data would make the FIT format less efficient than the legacy
> format.
>
> Therefore this series adds a new feature to FIT which allows the images to
> be stored immediately after the FIT itself ends. This makes the FIT very
> small. It can be read quickly and in its entirety. Then the images can be
> loaded one by one as needed. This allows SPL to support FITs containing lots
> of images very efficiently.
>
> To achieve this, mkimage is enhanced to convert between the 'normal' and
> 'external' version of a FIT file. The latter is only used for the SPL loader.
> The main difference is that viewing an 'external' FIT will not show the
> contents of each image.
>
> This series also includes a few other tidy-ups, such as moving mkimage's
> tricky argument-processing code to use getopt().
>
> NOTE: There are a few problems remaining with the Kconfig conversion. I'm
> still fiddling with this but thought it best to send this series out for
> comment in the meantime.
>
> This series is available at u-boot-fdt/spl-working.
>

[0] - http://lists.denx.de/pipermail/u-boot/2015-February/203938.html
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot


BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v7 70/76] x86: Drop using spi_flash_dm_ops

[Jagan Teki]

Since spi-nor flash is part of MTD uclass, so replaced
UCLASS_SPI_FLASH with UCLASS_MTD and use respective
spi_flash operations as well.

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes for v7:
- fix to use dm_spi_flash_ops.

 arch/arm/mach-rockchip/rk3288-board-spl.c | 2 +-
 arch/x86/lib/mrccache.c   | 9 -
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3288-board-spl.c 
b/arch/arm/mach-rockchip/rk3288-board-spl.c
index 6a54368..3ba2382 100644
--- a/arch/arm/mach-rockchip/rk3288-board-spl.c
+++ b/arch/arm/mach-rockchip/rk3288-board-spl.c
@@ -53,7 +53,7 @@ u32 spl_boot_device(void)
}
debug("Found device %s\n", dev->name);
switch (device_get_uclass_id(dev)) {
-   case UCLASS_SPI_FLASH:
+   case UCLASS_MTD:
return BOOT_DEVICE_SPI;
case UCLASS_MMC:
return BOOT_DEVICE_MMC1;
diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c
index 67bace4..dca3d84 100644
--- a/arch/x86/lib/mrccache.c
+++ b/arch/x86/lib/mrccache.c
@@ -109,6 +109,7 @@ static struct mrc_data_container 
*find_next_mrc_cache(struct mrc_region *entry,
 int mrccache_update(struct udevice *sf, struct mrc_region *entry,
struct mrc_data_container *cur)
 {
+   struct mtd_info *mtd = dev_get_uclass_priv(sf);
struct mrc_data_container *cache;
ulong offset;
ulong base_addr;
@@ -139,7 +140,7 @@ int mrccache_update(struct udevice *sf, struct mrc_region 
*entry,
debug("Erasing the MRC cache region of %x bytes at %x\n",
  entry->length, entry->offset);
 
-   ret = spi_flash_erase_dm(sf, entry->offset, entry->length);
+   ret = spi_flash_erase(mtd, entry->offset, entry->length);
if (ret) {
debug("Failed to erase flash region\n");
return ret;
@@ -150,8 +151,7 @@ int mrccache_update(struct udevice *sf, struct mrc_region 
*entry,
/* Write the data out */
offset = (ulong)cache - base_addr + entry->offset;
debug("Write MRC cache update to flash at %lx\n", offset);
-   ret = spi_flash_write_dm(sf, offset, cur->data_size + sizeof(*cur),
-cur);
+   ret = spi_flash_write(mtd, offset, cur->data_size + sizeof(*cur), cur);
if (ret) {
debug("Failed to write to SPI flash\n");
return ret;
@@ -216,8 +216,7 @@ int mrccache_get_region(struct udevice **devp, struct 
mrc_region *entry)
entry->length = reg[1];
 
if (devp) {
-   ret = uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node,
-devp);
+   ret = uclass_get_device_by_of_offset(UCLASS_MTD, node, devp);
debug("ret = %d\n", ret);
if (ret)
return ret;
-- 
1.9.1

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

Re: [U-Boot] [PATCH v6 65/76] configs: Use CONFIG_SPI_NOR_MISC

[Jagan Teki]

Hi Bin,

On 17 February 2016 at 14:39, Bin Meng  wrote:
> Hi Jagan,
>
> On Wed, Feb 17, 2016 at 5:05 PM, Jagan Teki  wrote:
>> Hi Bin,
>>
>> On 17 February 2016 at 14:23, Bin Meng  wrote:
>>> Hi Jagan,
>>>
>>> On Mon, Feb 15, 2016 at 4:49 AM, Jagan Teki  wrote:
 CONFIG_SPI_FLASH_ATMEL
 CONFIG_SPI_FLASH_EON
 CONFIG_SPI_FLASH_GIGADEVICE
 CONFIG_SPI_FLASH_ISSI

 All these configs are grouped in CONFIG_SPI_NOR_MISC
>>>
>>> So these 4 configs are no longer needed? But I see they are still in
>>> the x86 config files, like the one we discussed here [1]. Should we
>>> remove them?
>>
>> I have updated them as well, in all x86 files too.
>>
>> diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
>> index dfc6b0f..2ebee29 100644 (file)
>> --- a/configs/crownbay_defconfig
>> +++ b/configs/crownbay_defconfig
>> @@ -20,7 +20,7 @@ CONFIG_OF_CONTROL=y
>>  CONFIG_CPU=y
>>  CONFIG_MTD_SPI_NOR=y
>>  CONFIG_MTD_M25P80=y
>> -CONFIG_SPI_FLASH_GIGADEVICE=y
>> +CONFIG_SPI_NOR_MISC=y
>>  CONFIG_SPI_NOR_MACRONIX=y
>>  CONFIG_SPI_NOR_SST=y
>>  CONFIG_SPI_NOR_WINBOND=y
>>
>
> So how about the others? Looks a follow-up patch is needed to clean up
> the other configs? Each x86 board just have one type of SPI flash (and
> one driver instead)

Since the other configs have dependent code on spi-nor core, i have
not touched that.

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

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

[Bin Meng]

Hi Jagan,

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

 Tested both DM and non-DM models

 Tested-by: Jagan Teki 
>>>
>>> My test shows on Intel Crown Bay, ''saveenv" does write U-Boot env to
>>> the SPI flash correctly, however after "reset" U-Boot still shows: ***
>>> Warning - bad CRC, using default environment
>>>
>>> spi-nor: detected sst25vf016b with page size 256 Bytes, erase size 4
>>> KiB, total 2 MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Anything wrong?
>>
>>
>
>  I'm not getting the warning, after saveenv.
>
> DRAM:  ECC disabled 1 GiB
> MMC:
> spi-nor: detected s25fl128s with page size 256 Bytes, erase size 64
> KiB, total 16 MiB
> In:serial@e0001000
> Out:   serial@e0001000
> Err:   serial@e0001000
> Model: Zynq MicroZED Board
>

Tested on another x86 board, still see the 'bad CRC' warning, log below:

U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)

CPU: x86, vendor Intel, device 590h
DRAM:  256 MiB
MMC:   Quark SDHCI: 0
spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
*** Warning - bad CRC, using default environment

Model: Intel Galileo
Net:
Warning: eth_designware#0 (eth0) using random MAC address - 5a:58:ba:e9:22:fb
eth0: eth_designware#0
Warning: eth_designware#1 (eth1) using random MAC address - c6:a3:69:ff:b7:2e
, eth1: eth_designware#1
Hit any key to stop autoboot:  0
=> saveenv
Saving Environment to SPI Flash...
Erasing SPI flash...Writing to SPI flash...done
=> reset
resetting ...


U-Boot 2016.03-rc1-00254-gaba43ff (Feb 17 2016 - 17:03:54 +0800)

CPU: x86, vendor Intel, device 590h
DRAM:  256 MiB
MMC:   Quark SDHCI: 0
spi-nor: detected w25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
*** Warning - bad CRC, using default environment

Re: [U-Boot] [PATCH v7 77/77] x86: Drop using spi_flash_dm_ops

[Jagan Teki]

Hi Bin,

On Wednesday 17 February 2016 02:37 PM, Bin Meng wrote:

Hi Jagan,

On Wed, Feb 17, 2016 at 4:27 PM, Jagan Teki  wrote:

spi_flash_erase_dm
spi_flash_write_dm

These spi_flash_dm_ops never no longer available on new
spi-nor changes, so use spi_flash_erase/write ops with
mtd uclass changes.

Cc: Simon Glass 
Cc: Bin Meng 
Signed-off-by: Jagan Teki 
---
Changes for v7:
 - newly added patch

This patch is on top of spi-nor core changes, will send this
again with the series.


Yes, you need squash this patch somewhere in the middle of your whole
series, otherwise buildman will complain.


Sure I will do that and send the patch.

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

Re: [U-Boot] [PATCH v7 77/77] x86: Drop using spi_flash_dm_ops

[Bin Meng]

Hi Jagan,

On Wed, Feb 17, 2016 at 4:27 PM, Jagan Teki  wrote:
> spi_flash_erase_dm
> spi_flash_write_dm
>
> These spi_flash_dm_ops never no longer available on new
> spi-nor changes, so use spi_flash_erase/write ops with
> mtd uclass changes.
>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Signed-off-by: Jagan Teki 
> ---
> Changes for v7:
> - newly added patch
>
> This patch is on top of spi-nor core changes, will send this
> again with the series.

Yes, you need squash this patch somewhere in the middle of your whole
series, otherwise buildman will complain.

>
>  arch/x86/lib/mrccache.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c
> index 8c08c14..dca3d84 100644
> --- a/arch/x86/lib/mrccache.c
> +++ b/arch/x86/lib/mrccache.c
> @@ -109,6 +109,7 @@ static struct mrc_data_container 
> *find_next_mrc_cache(struct mrc_region *entry,
>  int mrccache_update(struct udevice *sf, struct mrc_region *entry,
> struct mrc_data_container *cur)
>  {
> +   struct mtd_info *mtd = dev_get_uclass_priv(sf);
> struct mrc_data_container *cache;
> ulong offset;
> ulong base_addr;
> @@ -139,7 +140,7 @@ int mrccache_update(struct udevice *sf, struct mrc_region 
> *entry,
> debug("Erasing the MRC cache region of %x bytes at %x\n",
>   entry->length, entry->offset);
>
> -   ret = spi_flash_erase_dm(sf, entry->offset, entry->length);
> +   ret = spi_flash_erase(mtd, entry->offset, entry->length);
> if (ret) {
> debug("Failed to erase flash region\n");
> return ret;
> @@ -150,8 +151,7 @@ int mrccache_update(struct udevice *sf, struct mrc_region 
> *entry,
> /* Write the data out */
> offset = (ulong)cache - base_addr + entry->offset;
> debug("Write MRC cache update to flash at %lx\n", offset);
> -   ret = spi_flash_write_dm(sf, offset, cur->data_size + sizeof(*cur),
> -cur);
> +   ret = spi_flash_write(mtd, offset, cur->data_size + sizeof(*cur), 
> cur);
> if (ret) {
> debug("Failed to write to SPI flash\n");
> return ret;
> --

I confirm this fixed the build error.

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

Re: [U-Boot] [PATCH v6 65/76] configs: Use CONFIG_SPI_NOR_MISC

[Jagan Teki]

Hi Bin,

On 17 February 2016 at 14:23, Bin Meng  wrote:
> Hi Jagan,
>
> On Mon, Feb 15, 2016 at 4:49 AM, Jagan Teki  wrote:
>> CONFIG_SPI_FLASH_ATMEL
>> CONFIG_SPI_FLASH_EON
>> CONFIG_SPI_FLASH_GIGADEVICE
>> CONFIG_SPI_FLASH_ISSI
>>
>> All these configs are grouped in CONFIG_SPI_NOR_MISC
>
> So these 4 configs are no longer needed? But I see they are still in
> the x86 config files, like the one we discussed here [1]. Should we
> remove them?

I have updated them as well, in all x86 files too.

diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
index dfc6b0f..2ebee29 100644 (file)
--- a/configs/crownbay_defconfig
+++ b/configs/crownbay_defconfig
@@ -20,7 +20,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_CPU=y
 CONFIG_MTD_SPI_NOR=y
 CONFIG_MTD_M25P80=y
-CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_NOR_MISC=y
 CONFIG_SPI_NOR_MACRONIX=y
 CONFIG_SPI_NOR_SST=y
 CONFIG_SPI_NOR_WINBOND=y

>
>>
>> Cc: Simon Glass 
>> Cc: Bin Meng 
>> Cc: Mugunthan V N 
>> Cc: Michal Simek 
>> Cc: Siva Durga Prasad Paladugu 
>> Signed-off-by: Jagan Teki 
>> ---
>
> [1] http://patchwork.ozlabs.org/patch/549644/

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

Re: [U-Boot] test/py main_signon

[Heiko Schocher]

Hello Michal,

Am 17.02.2016 um 09:42 schrieb Michal Simek:

Hi Stephen,

On 16.2.2016 22:38, Stephen Warren wrote:

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

Hi Stephen,

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

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

 Hi Heiko,

 On 16.2.2016 14:32, Heiko Schocher wrote:

 Hello Michal,

 Am 16.02.2016 um 13:12 schrieb Michal Simek:

 Hi Stephen,

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

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


 Does this board has SPL support without SPL serial output?


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

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


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

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


 I assume this is resolved then?


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

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


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

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

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

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

spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)


ok. I see. Anyway I have done this change locally and it is working good.
Heiko: Are you able to add this one more checking to your patch? Or
should I wait till you add your patch to the tree?


I just posted a v2 of my patch ... I vote, that you send your patch
based on mine to the ML.

bye,
Heiko


Stephen: Do you have your u-boot-test-hooks for qemu?

Thanks,
Michal



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

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

[Jagan Teki]

Hi Bin,

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

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

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

 Why this framework:

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

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

 Before SPI-NOR:

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

 After SPI-NOR:

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

 SPI-NOR with MTD:

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

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

Can you try the u-boot-spi/spi-nor tree again, I have fixed with the patch.

BTW - I couldn't get any build error with buildman without the fix
[1], am I missing anything?

[1] http://paste.ubuntu.com/15099249/

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

Re: [U-Boot] [PATCH v6 65/76] configs: Use CONFIG_SPI_NOR_MISC

[Bin Meng]

Hi Jagan,

On Mon, Feb 15, 2016 at 4:49 AM, Jagan Teki  wrote:
> CONFIG_SPI_FLASH_ATMEL
> CONFIG_SPI_FLASH_EON
> CONFIG_SPI_FLASH_GIGADEVICE
> CONFIG_SPI_FLASH_ISSI
>
> All these configs are grouped in CONFIG_SPI_NOR_MISC

So these 4 configs are no longer needed? But I see they are still in
the x86 config files, like the one we discussed here [1]. Should we
remove them?

>
> Cc: Simon Glass 
> Cc: Bin Meng 
> Cc: Mugunthan V N 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Signed-off-by: Jagan Teki 
> ---

[1] http://patchwork.ozlabs.org/patch/549644/

[snip]

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

[U-Boot] [PATCH] x86: doc: Update to include Intel Bayley Bay board instructions

[Bin Meng]

Update existing documentation to mention Intel Bayley Bay board
instructions, an additional Bay Trail based board to MinnowMax.

This also adds a minor change to QEMU section to indicate clearly
the instructions are for bare mode.

Signed-off-by: Bin Meng 
---

 doc/README.x86 | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86
index 948deca..d3fea5d 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -154,18 +154,28 @@ all set. For programming U-Boot we just need to program 
SPI-1 flash.
 
 ---
 
-Intel Minnowboard Max instructions for bare mode:
+Intel Bay Trail based board instructions for bare mode:
 
 This uses as FSP as with Crown Bay, except it is for the Atom E3800 series.
+Two boards that use this configuration are Bayley Bay and Minnowboard MAX.
 Download this and get the .fd file (BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd at
-the time of writing). Put it in the board directory:
-board/intel/minnowmax/fsp.bin
+the time of writing). Put it in the corresponding board directory and rename
+it to fsp.bin.
 
 Obtain the VGA RAM (Vga.dat at the time of writing) and put it into the same
-directory: board/intel/minnowmax/vga.bin
+board directory as vga.bin.
 
-You still need two more binary blobs. The first comes from the original
-firmware image available from:
+You still need two more binary blobs. For Bayley Bay, they can be extracted
+from the sample SPI image provided in the FSP (SPI.bin at the time of writing).
+
+   $ ./tools/ifdtool -x BayleyBay/SPI.bin
+   $ cp flashregion_0_flashdescriptor.bin board/intel/bayleybay/descriptor.bin
+   $ cp flashregion_2_intel_me.bin board/intel/bayleybay/me.bin
+
+For Minnowboard MAX, we can reuse the same ME firmware above, but for flash
+descriptor, we need get that somewhere else, as the one above does not seem to
+work, probably because it is not designed for the Minnowboard MAX. Now download
+the original firmware image for this board from:
 
 
http://firmware.intel.com/sites/default/files/2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip
 
@@ -182,16 +192,8 @@ This will provide the descriptor file - copy this into the 
correct place:
 
$ cp flashregion_0_flashdescriptor.bin board/intel/minnowmax/descriptor.bin
 
-Then do the same with the sample SPI image provided in the FSP (SPI.bin at
-the time of writing) to obtain the last image. Note that this will also
-produce a flash descriptor file, but it does not seem to work, probably
-because it is not designed for the Minnowmax. That is why you need to get
-the flash descriptor from the original firmware as above.
-
-   $ ./tools/ifdtool -x BayleyBay/SPI.bin
-   $ cp flashregion_2_intel_me.bin board/intel/minnowmax/me.bin
-
 Now you can build U-Boot and obtain u-boot.rom
+Note: below are examples/information for Minnowboard MAX.
 
 $ make minnowmax_defconfig
 $ make all
@@ -242,7 +244,9 @@ Now you can build U-Boot and obtain u-boot.rom
 $ make galileo_defconfig
 $ make all
 
-QEMU x86 target instructions:
+---
+
+QEMU x86 target instructions for bare mode:
 
 To build u-boot.rom for QEMU x86 targets, just simply run
 
-- 
1.8.2.1

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

Re: [U-Boot] test/py main_signon

[Michal Simek]

Hi Stephen,

On 16.2.2016 22:38, Stephen Warren wrote:
> On 02/16/2016 12:08 PM, Michal Simek wrote:
>> Hi Stephen,
>>
>> 2016-02-16 17:39 GMT+01:00 Stephen Warren > >:
>>
>> On 02/16/2016 09:04 AM, Michal Simek wrote:
>>
>> Hi Heiko,
>>
>> On 16.2.2016 14:32, Heiko Schocher wrote:
>>
>> Hello Michal,
>>
>> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>
>> Hi Stephen,
>>
>> trying to run the latest testing on zynq board and
>> getting this
>> main_signon error.
>>
>> This is what I am running
>> ./test/py/test.py --bd zynq_zc702  --build
>> --board-identity zc702
>> and getting below.
>>
>>
>> Does this board has SPL support without SPL serial output?
>>
>>
>> I do load u-boot via jtag that's why SPL logs are not visible.
>>
>> If so, can you try my patch:
>> http://patchwork.ozlabs.org/patch/583348/
>>
>>
>> I have applied your patch but it is still not working.
>>
>> If I run full flow with SPL then I can't see any issue.
>>
>>
>> I assume this is resolved then?
>>
>>
>> Unfortunately both cases should work because SPL is not only one first
>> stage bootloader
>> which can be used. I didn't test zynqmp but there is no SPL and the same
>> problem is
>> probably there too. Or is there any dependency that if SPL is not build
>> than testing system
>> is not expecting it?
>>
>> I will look tmr at jtag boot mode with SPL if I can get it work.
> 
> The test scripts currently assume that if SPL is enabled in the U-Boot
> configuration file, then U-Boot SPL will run and print its signon
> message to the serial console. If you're starting U-Boot using a
> technique that invalidates this assumption, it won't work currently, as
> you found.
> 
> It's pretty easy to add a flag in the boardenv file to tell the system
> not to expect SPL signon. If you take a look at my second suggestion in:
> 
> http://lists.denx.de/pipermail/u-boot/2016-February/245759.html
> [U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses
> serial output
> 
> ... then it's probably a simple as adding a third variable into the if
> condition, where that variable gets looks up from the "board
> environment", similar to:
> 
> spl_skipped = u_boot_console.config.env.get('env__spl_skipped', False)

ok. I see. Anyway I have done this change locally and it is working good.
Heiko: Are you able to add this one more checking to your patch? Or
should I wait till you add your patch to the tree?

Stephen: Do you have your u-boot-test-hooks for qemu?

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

[U-Boot] [PATCH v7 77/77] x86: Drop using spi_flash_dm_ops

[Jagan Teki]

spi_flash_erase_dm
spi_flash_write_dm

These spi_flash_dm_ops never no longer available on new
spi-nor changes, so use spi_flash_erase/write ops with
mtd uclass changes.

Cc: Simon Glass 
Cc: Bin Meng 
Signed-off-by: Jagan Teki 
---
Changes for v7:
- newly added patch

This patch is on top of spi-nor core changes, will send this
again with the series.

 arch/x86/lib/mrccache.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c
index 8c08c14..dca3d84 100644
--- a/arch/x86/lib/mrccache.c
+++ b/arch/x86/lib/mrccache.c
@@ -109,6 +109,7 @@ static struct mrc_data_container 
*find_next_mrc_cache(struct mrc_region *entry,
 int mrccache_update(struct udevice *sf, struct mrc_region *entry,
struct mrc_data_container *cur)
 {
+   struct mtd_info *mtd = dev_get_uclass_priv(sf);
struct mrc_data_container *cache;
ulong offset;
ulong base_addr;
@@ -139,7 +140,7 @@ int mrccache_update(struct udevice *sf, struct mrc_region 
*entry,
debug("Erasing the MRC cache region of %x bytes at %x\n",
  entry->length, entry->offset);
 
-   ret = spi_flash_erase_dm(sf, entry->offset, entry->length);
+   ret = spi_flash_erase(mtd, entry->offset, entry->length);
if (ret) {
debug("Failed to erase flash region\n");
return ret;
@@ -150,8 +151,7 @@ int mrccache_update(struct udevice *sf, struct mrc_region 
*entry,
/* Write the data out */
offset = (ulong)cache - base_addr + entry->offset;
debug("Write MRC cache update to flash at %lx\n", offset);
-   ret = spi_flash_write_dm(sf, offset, cur->data_size + sizeof(*cur),
-cur);
+   ret = spi_flash_write(mtd, offset, cur->data_size + sizeof(*cur), cur);
if (ret) {
debug("Failed to write to SPI flash\n");
return ret;
-- 
1.9.1

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

Re: [U-Boot] [PATCH] x86: fix memalign() parameter order

[Bin Meng]

On Wed, Feb 17, 2016 at 4:20 PM, Bin Meng  wrote:
> On Sun, Feb 14, 2016 at 11:19 AM, Simon Glass  wrote:
>> On 12 February 2016 at 14:27, Stephen Warren  wrote:
>>> From: Stephen Warren 
>>>
>>> Purely by code inspection, it looks like the parameter order to memalign()
>>> is swapped; its parameters are (align, size). 4096 is a likely desired
>>> alignment, and a variable named size sounds like a size:-)
>>>
>>> Fixes: 45b5a37836d5 ("x86: Add multi-processor init")
>>> Signed-off-by: Stephen Warren 
>>> ---
>>> I've taken a quick look at all the other memalign() calls in U-Boot, and
>>> I /think/ they're all correct.
>>> ---
>>> arch/x86/cpu/mp_init.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
>>> index 7917350bff26..fc2fb5bf445c 100644
>>> --- a/arch/x86/cpu/mp_init.c
>>> +++ b/arch/x86/cpu/mp_init.c
>>> @@ -243,7 +243,7 @@ static int load_sipi_vector(atomic_t **ap_countp, int
>>> num_cpus)
>>>
>>> params->stack_size = CONFIG_AP_STACK_SIZE;
>>> size = params->stack_size * num_cpus;
>>> - stack = memalign(size, 4096);
>>> + stack = memalign(4096, size);
>>> if (!stack)
>>> return -ENOMEM;
>>> params->stack_top = (u32)(stack + size);
>>> --
>>> 2.7.0
>>>
>>
>> Reviewed-by: Simon Glass 
>>
>> Thanks. I'm a little surprised this hasn't caused problems with CPU
>> start-up!
>
> Tested on QEMU
> Tested-by: Bin Meng 

applied to u-boot-x86/master, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] x86: fix memalign() parameter order

[Bin Meng]

On Sun, Feb 14, 2016 at 11:19 AM, Simon Glass  wrote:
> On 12 February 2016 at 14:27, Stephen Warren  wrote:
>> From: Stephen Warren 
>>
>> Purely by code inspection, it looks like the parameter order to memalign()
>> is swapped; its parameters are (align, size). 4096 is a likely desired
>> alignment, and a variable named size sounds like a size:-)
>>
>> Fixes: 45b5a37836d5 ("x86: Add multi-processor init")
>> Signed-off-by: Stephen Warren 
>> ---
>> I've taken a quick look at all the other memalign() calls in U-Boot, and
>> I /think/ they're all correct.
>> ---
>> arch/x86/cpu/mp_init.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/cpu/mp_init.c b/arch/x86/cpu/mp_init.c
>> index 7917350bff26..fc2fb5bf445c 100644
>> --- a/arch/x86/cpu/mp_init.c
>> +++ b/arch/x86/cpu/mp_init.c
>> @@ -243,7 +243,7 @@ static int load_sipi_vector(atomic_t **ap_countp, int
>> num_cpus)
>>
>> params->stack_size = CONFIG_AP_STACK_SIZE;
>> size = params->stack_size * num_cpus;
>> - stack = memalign(size, 4096);
>> + stack = memalign(4096, size);
>> if (!stack)
>> return -ENOMEM;
>> params->stack_top = (u32)(stack + size);
>> --
>> 2.7.0
>>
>
> Reviewed-by: Simon Glass 
>
> Thanks. I'm a little surprised this hasn't caused problems with CPU
> start-up!

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

[U-Boot] [PATCH v3 1/5] x86: ivybridge: Add FSP support

[Bin Meng]

IvyBridge FSP package is built with a base address at 0xfff8,
and does not use UPD data region. This adds basic FSP support.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 
Tested on link (ivybridge non-FSP)
Tested-by: Simon Glass 

---

Changes in v3: None
Changes in v2:
- Drop patches which were already applied
- Rebase on top of u-boot-x86/master
- Change fsp files license from Intel to GPL-2.0+

 arch/x86/cpu/ivybridge/Kconfig |  8 
 arch/x86/cpu/ivybridge/Makefile|  4 ++
 arch/x86/cpu/ivybridge/fsp_configs.c   | 45 ++
 arch/x86/cpu/ivybridge/ivybridge.c | 22 +++
 .../include/asm/arch-ivybridge/fsp/fsp_configs.h   | 40 +++
 arch/x86/include/asm/arch-ivybridge/fsp/fsp_vpd.h  | 12 ++
 6 files changed, 131 insertions(+)
 create mode 100644 arch/x86/cpu/ivybridge/fsp_configs.c
 create mode 100644 arch/x86/cpu/ivybridge/ivybridge.c
 create mode 100644 arch/x86/include/asm/arch-ivybridge/fsp/fsp_configs.h
 create mode 100644 arch/x86/include/asm/arch-ivybridge/fsp/fsp_vpd.h

diff --git a/arch/x86/cpu/ivybridge/Kconfig b/arch/x86/cpu/ivybridge/Kconfig
index 1768a26..b9f290a 100644
--- a/arch/x86/cpu/ivybridge/Kconfig
+++ b/arch/x86/cpu/ivybridge/Kconfig
@@ -71,4 +71,12 @@ config ENABLE_VMX
  will be unable to support virtualisation, or it will run very
  slowly.
 
+config FSP_ADDR
+   hex
+   default 0xfff8
+
+config FSP_USE_UPD
+   bool
+   default n
+
 endif
diff --git a/arch/x86/cpu/ivybridge/Makefile b/arch/x86/cpu/ivybridge/Makefile
index 45ef141..d7332ff 100644
--- a/arch/x86/cpu/ivybridge/Makefile
+++ b/arch/x86/cpu/ivybridge/Makefile
@@ -4,6 +4,9 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+ifdef CONFIG_HAVE_FSP
+obj-y += fsp_configs.o ivybridge.o
+else
 obj-y += bd82x6x.o
 obj-y += car.o
 obj-y += cpu.o
@@ -17,3 +20,4 @@ obj-y += northbridge.o
 obj-y += report_platform.o
 obj-y += sata.o
 obj-y += sdram.o
+endif
diff --git a/arch/x86/cpu/ivybridge/fsp_configs.c 
b/arch/x86/cpu/ivybridge/fsp_configs.c
new file mode 100644
index 000..c7f475b
--- /dev/null
+++ b/arch/x86/cpu/ivybridge/fsp_configs.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (C) 2016, Bin Meng 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void update_fsp_configs(struct fsp_config_data *config,
+   struct fspinit_rtbuf *rt_buf)
+{
+   struct platform_config *plat_config = >plat_config;
+   struct memory_config *mem_config = >mem_config;
+   const void *blob = gd->fdt_blob;
+   int node;
+
+   node = fdtdec_next_compatible(blob, 0, COMPAT_INTEL_IVYBRIDGE_FSP);
+   if (node < 0) {
+   debug("%s: Cannot find FSP node\n", __func__);
+   return;
+   }
+
+   plat_config->enable_ht =
+   fdtdec_get_bool(blob, node, "fsp,enable-ht");
+   plat_config->enable_turbo =
+   fdtdec_get_bool(blob, node, "fsp,enable-turbo");
+   plat_config->enable_memory_down =
+   fdtdec_get_bool(blob, node, "fsp,enable-memory-down");
+   plat_config->enable_fast_boot =
+   fdtdec_get_bool(blob, node, "fsp,enable-fast-boot");
+
+   /* Initialize runtime buffer for fsp_init() */
+   rt_buf->stack_top = config->common.stack_top - 32;
+   rt_buf->boot_mode = config->common.boot_mode;
+   rt_buf->plat_config = plat_config;
+
+   if (plat_config->enable_memory_down)
+   rt_buf->mem_config = mem_config;
+   else
+   rt_buf->mem_config = NULL;
+}
diff --git a/arch/x86/cpu/ivybridge/ivybridge.c 
b/arch/x86/cpu/ivybridge/ivybridge.c
new file mode 100644
index 000..c770b53
--- /dev/null
+++ b/arch/x86/cpu/ivybridge/ivybridge.c
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2016, Bin Meng 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+int arch_cpu_init(void)
+{
+   int ret;
+
+   post_code(POST_CPU_INIT);
+
+   ret = x86_cpu_init_f();
+   if (ret)
+   return ret;
+
+   return 0;
+}
diff --git a/arch/x86/include/asm/arch-ivybridge/fsp/fsp_configs.h 
b/arch/x86/include/asm/arch-ivybridge/fsp/fsp_configs.h
new file mode 100644
index 000..9b0613d
--- /dev/null
+++ b/arch/x86/include/asm/arch-ivybridge/fsp/fsp_configs.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (C) 2016, Bin Meng 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __FSP_CONFIGS_H__
+#define __FSP_CONFIGS_H__
+
+struct platform_config {
+   u8 enable_ht;
+   u8 enable_turbo;
+   u8 enable_memory_down;
+   u8 enable_fast_boot;
+};
+
+/*
+ * Dummy structure for now as currently only SPD is verified in U-Boot.
+ *
+ * We can add the missing parameters when adding support on a board with
+ * memory down 

[U-Boot] [PATCH v3 4/5] x86: ivybridge: bd82x6x: Support FSP enabled configuration

[Bin Meng]

Wrap initialization codes with #ifndef CONFIG_HAVE_FSP #endif,
and enable the build for both FSP and non-FSP configurations.

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

Changes in v3: None
Changes in v2: None

 arch/x86/cpu/ivybridge/Makefile  | 2 +-
 arch/x86/cpu/ivybridge/bd82x6x.c | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/x86/cpu/ivybridge/Makefile b/arch/x86/cpu/ivybridge/Makefile
index d7332ff..9203219 100644
--- a/arch/x86/cpu/ivybridge/Makefile
+++ b/arch/x86/cpu/ivybridge/Makefile
@@ -7,7 +7,6 @@
 ifdef CONFIG_HAVE_FSP
 obj-y += fsp_configs.o ivybridge.o
 else
-obj-y += bd82x6x.o
 obj-y += car.o
 obj-y += cpu.o
 obj-y += early_me.o
@@ -21,3 +20,4 @@ obj-y += report_platform.o
 obj-y += sata.o
 obj-y += sdram.o
 endif
+obj-y += bd82x6x.o
diff --git a/arch/x86/cpu/ivybridge/bd82x6x.c b/arch/x86/cpu/ivybridge/bd82x6x.c
index 996707b..9972b0a 100644
--- a/arch/x86/cpu/ivybridge/bd82x6x.c
+++ b/arch/x86/cpu/ivybridge/bd82x6x.c
@@ -22,6 +22,7 @@
 #define GPIO_BASE  0x48
 #define BIOS_CTRL  0xdc
 
+#ifndef CONFIG_HAVE_FSP
 static int pch_revision_id = -1;
 static int pch_type = -1;
 
@@ -170,6 +171,7 @@ static int bd82x6x_probe(struct udevice *dev)
 
return 0;
 }
+#endif /* CONFIG_HAVE_FSP */
 
 static int bd82x6x_pch_get_spi_base(struct udevice *dev, ulong *sbasep)
 {
@@ -247,6 +249,8 @@ U_BOOT_DRIVER(bd82x6x_drv) = {
.name   = "bd82x6x",
.id = UCLASS_PCH,
.of_match   = bd82x6x_ids,
+#ifndef CONFIG_HAVE_FSP
.probe  = bd82x6x_probe,
+#endif
.ops= _pch_ops,
 };
-- 
1.8.2.1

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

[U-Boot] [PATCH v3 2/5] superio: Add SMSC SIO1007 driver

[Bin Meng]

The SMSC SIO1007 superio chipset integrates two ns16550 compatible
serial ports for legacy applications, 16 GPIO pins and some other
functionalities like power management.

This adds a simple driver to enable serial port and handle GPIO.

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

Changes in v3: None
Changes in v2: None

 drivers/misc/Makefile   |   1 +
 drivers/misc/smsc_sio1007.c | 126 
 include/smsc_sio1007.h  | 115 
 3 files changed, 242 insertions(+)
 create mode 100644 drivers/misc/smsc_sio1007.c
 create mode 100644 include/smsc_sio1007.h

diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e1e3c6b..f2b08ab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -32,6 +32,7 @@ ifdef CONFIG_DM_I2C
 obj-$(CONFIG_SANDBOX) += i2c_eeprom_emul.o
 endif
 obj-$(CONFIG_SMSC_LPC47M) += smsc_lpc47m.o
+obj-$(CONFIG_SMSC_SIO1007) += smsc_sio1007.o
 obj-$(CONFIG_STATUS_LED) += status_led.o
 obj-$(CONFIG_SANDBOX) += swap_case.o
 obj-$(CONFIG_SANDBOX) += syscon_sandbox.o
diff --git a/drivers/misc/smsc_sio1007.c b/drivers/misc/smsc_sio1007.c
new file mode 100644
index 000..ec53533
--- /dev/null
+++ b/drivers/misc/smsc_sio1007.c
@@ -0,0 +1,126 @@
+/*
+ * Copyright (C) 2016, Bin Meng 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static inline u8 sio1007_read(int port, int reg)
+{
+   outb(reg, port);
+
+   return inb(port + 1);
+}
+
+static inline void sio1007_write(int port, int reg, int val)
+{
+   outb(reg, port);
+   outb(val, port + 1);
+}
+
+static inline void sio1007_clrsetbits(int port, int reg, u8 clr, u8 set)
+{
+   sio1007_write(port, reg, (sio1007_read(port, reg) & ~clr) | set);
+}
+
+void sio1007_enable_serial(int port, int num, int iobase, int irq)
+{
+   if (num < 0 || num > SIO1007_UART_NUM)
+   return;
+
+   /* enter configuration state */
+   outb(0x55, port);
+
+   /* power on serial port and set up its i/o base & irq */
+   if (!num) {
+   sio1007_clrsetbits(port, DEV_POWER_CTRL, 0, UART1_POWER_ON);
+   sio1007_clrsetbits(port, UART1_IOBASE, 0xfe, iobase >> 2);
+   sio1007_clrsetbits(port, UART_IRQ, 0xf0, irq << 4);
+   } else {
+   sio1007_clrsetbits(port, DEV_POWER_CTRL, 0, UART2_POWER_ON);
+   sio1007_clrsetbits(port, UART2_IOBASE, 0xfe, iobase >> 2);
+   sio1007_clrsetbits(port, UART_IRQ, 0x0f, irq);
+   }
+
+   /* exit configuration state */
+   outb(0xaa, port);
+}
+
+void sio1007_enable_runtime(int port, int iobase)
+{
+   /* enter configuration state */
+   outb(0x55, port);
+
+   /* set i/o base for the runtime register block */
+   sio1007_clrsetbits(port, RTR_IOBASE_LOW, 0, iobase >> 4);
+   sio1007_clrsetbits(port, RTR_IOBASE_HIGH, 0, iobase >> 12);
+   /* turn on address decoding for this block */
+   sio1007_clrsetbits(port, DEV_ACTIVATE, 0, RTR_EN);
+
+   /* exit configuration state */
+   outb(0xaa, port);
+}
+
+void sio1007_gpio_config(int port, int gpio, int dir, int pol, int type)
+{
+   int reg = GPIO0_DIR;
+
+   if (gpio < 0 || gpio > SIO1007_GPIO_NUM)
+   return;
+   if (gpio >= GPIO_NUM_PER_GROUP) {
+   reg = GPIO1_DIR;
+   gpio -= GPIO_NUM_PER_GROUP;
+   }
+
+   /* enter configuration state */
+   outb(0x55, port);
+
+   /* set gpio pin direction, polority and type */
+   sio1007_clrsetbits(port, reg, 1 << gpio, dir << gpio);
+   sio1007_clrsetbits(port, reg + 1, 1 << gpio, pol << gpio);
+   sio1007_clrsetbits(port, reg + 2, 1 << gpio, type << gpio);
+
+   /* exit configuration state */
+   outb(0xaa, port);
+}
+
+int sio1007_gpio_get_value(int port, int gpio)
+{
+   int reg = GPIO0_DATA;
+   int val;
+
+   if (gpio < 0 || gpio > SIO1007_GPIO_NUM)
+   return -EINVAL;
+   if (gpio >= GPIO_NUM_PER_GROUP) {
+   reg = GPIO1_DATA;
+   gpio -= GPIO_NUM_PER_GROUP;
+   }
+
+   val = inb(port + reg);
+   if (val & (1 << gpio))
+   return 1;
+   else
+   return 0;
+}
+
+void sio1007_gpio_set_value(int port, int gpio, int val)
+{
+   int reg = GPIO0_DATA;
+   u8 data;
+
+   if (gpio < 0 || gpio > SIO1007_GPIO_NUM)
+   return;
+   if (gpio >= GPIO_NUM_PER_GROUP) {
+   reg = GPIO1_DATA;
+   gpio -= GPIO_NUM_PER_GROUP;
+   }
+
+   data = inb(port + reg);
+   data &= ~(1 << gpio);
+   data |= (val << gpio);
+   outb(data, port + reg);
+}
diff --git a/include/smsc_sio1007.h b/include/smsc_sio1007.h
new file mode 100644
index 000..805fa0e
--- /dev/null
+++ b/include/smsc_sio1007.h
@@ -0,0 +1,115 @@
+/*
+ * Copyright (C) 2016, Bin 

[U-Boot] [PATCH v3 3/5] x86: fsp: Make sure HOB list is not overwritten by U-Boot

[Bin Meng]

Intel IvyBridge FSP seems to be buggy that it does not report memory
used by FSP itself as reserved in the resource descriptor HOB. The
FSP specification does not describe how resource descriptor HOBs are
generated by the FSP to describe what memory regions. It looks newer
FSPs like Queensbay and BayTrail do not have such issue. This causes
U-Boot relocation overwrites the important boot service data which is
used by FSP, and the subsequent call to fsp_notify() will fail.

To resolve this, we find out the lowest memory base address allocated
by FSP for the boot service data when walking through the HOB list in
fsp_get_usable_lowmem_top(). Check whether the memory top address is
below the FSP HOB list, and if not, use the lowest memory base address
allocated by FSP as the memory top address.

Signed-off-by: Bin Meng 
Acked-by: Simon Glass 
Tested on link (ivybridge non-FSP)
Tested-by: Simon Glass 

---

Changes in v3: None
Changes in v2:
- Introduce a Kconfig option to wrap these codes

 arch/x86/Kconfig   | 10 ++
 arch/x86/lib/fsp/fsp_support.c | 33 +
 2 files changed, 43 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 49e173c..a0bd344 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -248,6 +248,16 @@ config FSP_USE_UPD
  are still some FSPs that might not even have UPD. For such FSPs,
  override this to n in their platform Kconfig files.
 
+config FSP_BROKEN_HOB
+   bool
+   depends on HAVE_FSP
+   help
+ Indicate some buggy FSPs that does not report memory used by FSP
+ itself as reserved in the resource descriptor HOB. Select this to
+ tell U-Boot to do some additional work to ensure U-Boot relocation
+ do not overwrite the important boot service data which is used by
+ FSP, otherwise the subsequent call to fsp_notify() will fail.
+
 config ENABLE_MRC_CACHE
bool "Enable MRC cache"
depends on !EFI && !SYS_COREBOOT
diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
index 29fa060..b05dced 100644
--- a/arch/x86/lib/fsp/fsp_support.c
+++ b/arch/x86/lib/fsp/fsp_support.c
@@ -225,6 +225,10 @@ u32 fsp_get_usable_lowmem_top(const void *hob_list)
struct hob_res_desc *res_desc;
phys_addr_t phys_start;
u32 top;
+#ifdef CONFIG_FSP_BROKEN_HOB
+   struct hob_mem_alloc *res_mem;
+   phys_addr_t mem_base = 0;
+#endif
 
/* Get the HOB list for processing */
hdr = hob_list;
@@ -242,9 +246,38 @@ u32 fsp_get_usable_lowmem_top(const void *hob_list)
top += (u32)(res_desc->len);
}
}
+
+#ifdef CONFIG_FSP_BROKEN_HOB
+   /*
+* Find out the lowest memory base address allocated by FSP
+* for the boot service data
+*/
+   if (hdr->type == HOB_TYPE_MEM_ALLOC) {
+   res_mem = (struct hob_mem_alloc *)hdr;
+   if (!mem_base)
+   mem_base = res_mem->mem_base;
+   if (res_mem->mem_base < mem_base)
+   mem_base = res_mem->mem_base;
+   }
+#endif
+
hdr = get_next_hob(hdr);
}
 
+#ifdef CONFIG_FSP_BROKEN_HOB
+   /*
+* Check whether the memory top address is below the FSP HOB list.
+* If not, use the lowest memory base address allocated by FSP as
+* the memory top address. This is to prevent U-Boot relocation
+* overwrites the important boot service data which is used by FSP,
+* otherwise the subsequent call to fsp_notify() will fail.
+*/
+   if (top > (u32)hob_list) {
+   debug("Adjust memory top address due to a buggy FSP\n");
+   top = (u32)mem_base;
+   }
+#endif
+
return top;
 }
 
-- 
1.8.2.1

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

[U-Boot] [PATCH v3 0/5] x86: ivybridge: Add Intel FSP support

[Bin Meng]

This series adds Intel FSP support to IvyBridge processor and
Panther Point chipset (aka Chief River platform), and is validated
on Intel Cougar Canyon 2 board.

This only adds basic features like serial, keyboard, RTC, timer,
SPI, GPIO, PCI, SATA, USB. Other features will be enabled in future
patch set.

Changes in v3:
- Update README.x86 to include intructions for this board

Changes in v2:
- Drop patches which were already applied
- Rebase on top of u-boot-x86/master
- Change fsp files license from Intel to GPL-2.0+
- Introduce a Kconfig option to wrap these codes
- Change include order -  go after the normal includes
- Use PCH uclass driver and change to use dm pci config APIs

Bin Meng (5):
  x86: ivybridge: Add FSP support
  superio: Add SMSC SIO1007 driver
  x86: fsp: Make sure HOB list is not overwritten by U-Boot
  x86: ivybridge: bd82x6x: Support FSP enabled configuration
  x86: Add Intel Cougar Canyon 2 board

 arch/x86/Kconfig   |  10 ++
 arch/x86/cpu/ivybridge/Kconfig |  12 ++
 arch/x86/cpu/ivybridge/Makefile|   6 +-
 arch/x86/cpu/ivybridge/bd82x6x.c   |   4 +
 arch/x86/cpu/ivybridge/fsp_configs.c   |  45 
 arch/x86/cpu/ivybridge/ivybridge.c |  22 
 arch/x86/dts/Makefile  |   1 +
 arch/x86/dts/cougarcanyon2.dts | 104 +
 .../include/asm/arch-ivybridge/fsp/fsp_configs.h   |  40 +++
 arch/x86/include/asm/arch-ivybridge/fsp/fsp_vpd.h  |  12 ++
 arch/x86/lib/fsp/fsp_support.c |  33 ++
 board/intel/Kconfig|   9 ++
 board/intel/cougarcanyon2/Kconfig  |  25 
 board/intel/cougarcanyon2/MAINTAINERS  |   6 +
 board/intel/cougarcanyon2/Makefile |   7 ++
 board/intel/cougarcanyon2/cougarcanyon2.c  |  58 ++
 board/intel/cougarcanyon2/start.S  |   9 ++
 configs/cougarcanyon2_defconfig|  20 
 doc/README.x86 |  21 
 drivers/misc/Makefile  |   1 +
 drivers/misc/smsc_sio1007.c| 126 +
 include/configs/cougarcanyon2.h|  34 ++
 include/smsc_sio1007.h | 115 +++
 23 files changed, 719 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/cpu/ivybridge/fsp_configs.c
 create mode 100644 arch/x86/cpu/ivybridge/ivybridge.c
 create mode 100644 arch/x86/dts/cougarcanyon2.dts
 create mode 100644 arch/x86/include/asm/arch-ivybridge/fsp/fsp_configs.h
 create mode 100644 arch/x86/include/asm/arch-ivybridge/fsp/fsp_vpd.h
 create mode 100644 board/intel/cougarcanyon2/Kconfig
 create mode 100644 board/intel/cougarcanyon2/MAINTAINERS
 create mode 100644 board/intel/cougarcanyon2/Makefile
 create mode 100644 board/intel/cougarcanyon2/cougarcanyon2.c
 create mode 100644 board/intel/cougarcanyon2/start.S
 create mode 100644 configs/cougarcanyon2_defconfig
 create mode 100644 drivers/misc/smsc_sio1007.c
 create mode 100644 include/configs/cougarcanyon2.h
 create mode 100644 include/smsc_sio1007.h

-- 
1.8.2.1

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

[U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available

[Guillaume GARDET]

Since commit fd61d39970b9901217efc7536d9f3a61b4e1752a:
spl: mmc: add break statements in spl_mmc_load_image() 
RAW and FS boot modes are now exclusive again. So, if MMCSD_MODE_RAW fails, the
board hangs. This patch allows to try MMCSD_MODE_FS then, if available.

It has been tested on a beaglebone black to boot on an EXT partition.

Signed-off-by: Guillaume GARDET 
Cc: Tom Rini 
Cc: Nikita Kiryanov 
Cc: Igor Grinberg 
Cc: Paul Kocialkowski 
Cc: Pantelis Antoniou 
Cc: Simon Glass 
Cc: Matwey V. Kornilov 

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

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index c3931c6..2eef0f2 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -284,7 +284,7 @@ int spl_mmc_load_image(u32 boot_device)
if (!err)
return err;
 #endif
-   break;
+   /* Fall through */
case MMCSD_MODE_FS:
debug("spl: mmc boot mode: fs\n");
 
-- 
1.8.4.5

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