[U-Boot] [PATCH v2] sunxi: Add Linksprite_pcDuino3_Nano board / defconfig

2015-01-26 Thread Adam Sampson
This is a low-cost Allwinner A20 board with Arduino-style GPIO headers;
it features 1G RAM, 4G NAND flash, 1 micro-SD, 2 USB sockets, 1 micro
USB socket for OTG and another for power in, HDMI, SATA, 5V power for
SATA devices, gigabit Ethernet, an IR receiver, 3.5mm audio out and a
MIPI camera connector.

For more details, see: http://linux-sunxi.org/LinkSprite_pcDuino3_Nano

Signed-off-by: Adam Sampson 
---
 board/sunxi/MAINTAINERS|  5 +
 configs/Linksprite_pcDuino3_Nano_defconfig | 11 +++
 2 files changed, 16 insertions(+)
 create mode 100644 configs/Linksprite_pcDuino3_Nano_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 743e7f5..479d147 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -100,3 +100,8 @@ MELE M5 BOARD
 M: Ian Campbell 
 S: Maintained
 F: configs/Mele_M5_defconfig
+
+LINKSPRITE-PCDUINO3-NANO BOARD
+M: Adam Sampson 
+S: Maintained
+F: configs/Linksprite_pcDuino3_Nano_defconfig
diff --git a/configs/Linksprite_pcDuino3_Nano_defconfig 
b/configs/Linksprite_pcDuino3_Nano_defconfig
new file mode 100644
index 000..e3ea713
--- /dev/null
+++ b/configs/Linksprite_pcDuino3_Nano_defconfig
@@ -0,0 +1,11 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI"
+CONFIG_FDTFILE="sun7i-a20-pcduino3-nano.dtb"
+CONFIG_USB1_VBUS_PIN="PH11"
++S:CONFIG_ARM=y
++S:CONFIG_ARCH_SUNXI=y
++S:CONFIG_MACH_SUN7I=y
++S:CONFIG_TARGET_PCDUINO3_NANO=y
++S:CONFIG_DRAM_CLK=408
++S:CONFIG_DRAM_ZQ=122
++S:CONFIG_DRAM_EMR1=4
-- 
2.2.2

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


Re: [U-Boot] [PATCH] sunxi: Add Linksprite_pcDuino3_Nano board / defconfig

2015-01-26 Thread Adam Sampson
Hi Christophe,

On Mon, Jan 26, 2015 at 07:15:20AM -0800, christophe.le.rou...@gmail.com wrote:
> > +CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI"
> 
> What do you think about adding "RGMII" in the CONFIG_SYS_EXTRA_OPTIONS
> like other gigabit A20 board ?

Good catch -- I'll respin the patch!

Thanks very much,

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


[U-Boot] [PATCH v7] Export redesign

2015-01-26 Thread Simon Glass
From: Martin Dorwig 

this is an atempt to make the export of functions typesafe.
I replaced the jumptable void ** by a struct (jt_funcs) with function pointers.
The EXPORT_FUNC macro now has 3 fixed parameters and one
variadic parameter
The first is the name of the exported function,
the rest of the parameters are used to format a functionpointer
in the jumptable,

the EXPORT_FUNC macros are expanded three times,
1. to declare the members of the struct
2. to initialize the structmember pointers
3. to call the functions in stubs.c

Signed-off-by: Martin Dorwig 
Acked-by: Simon Glass 

Signed-off-by: Simon Glass 
(resending to the list since my tweaks are not quite trivial)

---

Changes in v7:
- Really increase the API version number (sorry)

Changes in v6:
- Increase the API version number

Changes in v5:
- Update to deal with I2C moving to driver model

 arch/blackfin/cpu/cpu.c   |  3 +-
 board/BuS/eb_cpux9k2/cpux9k2.c|  2 +-
 common/cmd_load.c |  2 +-
 common/console.c  | 20 
 common/exports.c  | 29 ++--
 doc/README.standalone | 41 +++-
 examples/standalone/stubs.c   | 64 +
 include/_exports.h| 99 +++
 include/asm-generic/global_data.h |  2 +-
 include/exports.h | 22 +
 10 files changed, 163 insertions(+), 121 deletions(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index b7f1188..91aa5cc 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -24,6 +24,7 @@
 
 #include "cpu.h"
 #include "initcode.h"
+#include "exports.h"
 
 ulong bfin_poweron_retx;
 DECLARE_GLOBAL_DATA_PTR;
@@ -121,7 +122,7 @@ static void display_global_data(void)
printf(" |-ram_size: %lx\n", gd->ram_size);
printf(" |-env_addr: %lx\n", gd->env_addr);
printf(" |-env_valid: %lx\n", gd->env_valid);
-   printf(" |-jt(%p): %p\n", gd->jt, *(gd->jt));
+   printf(" |-jt(%p): %p\n", gd->jt, gd->jt->get_version);
printf(" \\-bd: %p\n", gd->bd);
printf("   |-bi_boot_params: %lx\n", bd->bi_boot_params);
printf("   |-bi_memstart: %lx\n", bd->bi_memstart);
diff --git a/board/BuS/eb_cpux9k2/cpux9k2.c b/board/BuS/eb_cpux9k2/cpux9k2.c
index 5e4778e..76ad7c4 100644
--- a/board/BuS/eb_cpux9k2/cpux9k2.c
+++ b/board/BuS/eb_cpux9k2/cpux9k2.c
@@ -98,7 +98,7 @@ int misc_init_r(void)
puts("Error: invalid MAC at EEPROM\n");
}
}
-   gd->jt[XF_do_reset] = (void *) do_reset;
+   gd->jt->do_reset = do_reset;
 
 #ifdef CONFIG_STATUS_LED
status_led_set(STATUS_LED_BOOT, STATUS_LED_BLINKING);
diff --git a/common/cmd_load.c b/common/cmd_load.c
index f6e522c..d043e6d 100644
--- a/common/cmd_load.c
+++ b/common/cmd_load.c
@@ -222,7 +222,7 @@ static int read_record(char *buf, ulong len)
}
 
/* Check for the console hangup (if any different from serial) */
-   if (gd->jt[XF_getc] != getc) {
+   if (gd->jt->getc != getc) {
if (ctrlc()) {
return (-1);
}
diff --git a/common/console.c b/common/console.c
index fc1963b..3f25e76 100644
--- a/common/console.c
+++ b/common/console.c
@@ -125,13 +125,13 @@ static int console_setfile(int file, struct stdio_dev * 
dev)
 */
switch (file) {
case stdin:
-   gd->jt[XF_getc] = getc;
-   gd->jt[XF_tstc] = tstc;
+   gd->jt->getc = getc;
+   gd->jt->tstc = tstc;
break;
case stdout:
-   gd->jt[XF_putc] = putc;
-   gd->jt[XF_puts] = puts;
-   gd->jt[XF_printf] = printf;
+   gd->jt->putc  = putc;
+   gd->jt->puts  = puts;
+   gd->jt->printf = printf;
break;
}
break;
@@ -758,11 +758,11 @@ int console_init_r(void)
 #endif
 
/* set default handlers at first */
-   gd->jt[XF_getc] = serial_getc;
-   gd->jt[XF_tstc] = serial_tstc;
-   gd->jt[XF_putc] = serial_putc;
-   gd->jt[XF_puts] = serial_puts;
-   gd->jt[XF_printf] = serial_printf;
+   gd->jt->getc  = serial_getc;
+   gd->jt->tstc  = serial_tstc;
+   gd->jt->putc  = serial_putc;
+   gd->jt->puts  = serial_puts;
+   gd->jt->printf = serial_printf;
 
/* stdin stdout and stderr are in environment */
/* scan for it */
diff --git a/common/exports.c b/common/exports.c
index 459e18c..333107c 100644
--- a/common/exports.c
+++ b/common/exports.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -13,34 +14,10 @@ unsigned long get_version(void)
return XF_VERSION;
 }
 
-/* Reuse _exports.h with a little t

Re: [U-Boot] [PATCH 1/5] nand: Use common read function instead of verify_buf()

2015-01-26 Thread Scott Wood
On Mon, 2015-01-26 at 16:24 -0600, Peter Tyser wrote:
> The driver-specific verify_buf() function can be replaced with the
> standard read_page_raw() function to verify writes.  This will allow
> verify_buf() to be removed from individual drivers.  verify_buf() is no
> longer supported in mainline Linux, so it is a pain to continue
> supporting.

Any reason not to just remove this feature from U-Boot, as Linux has
done?

-Scott


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


Re: [U-Boot] [PATCH 1/5] nand: Use common read function instead of verify_buf()

2015-01-26 Thread Peter Tyser

On Mon, 2015-01-26 at 16:33 -0600, Scott Wood wrote:
> On Mon, 2015-01-26 at 16:24 -0600, Peter Tyser wrote:
> > The driver-specific verify_buf() function can be replaced with the
> > standard read_page_raw() function to verify writes.  This will 
> > allow
> > verify_buf() to be removed from individual drivers.  verify_buf() 
> > is no
> > longer supported in mainline Linux, so it is a pain to continue
> > supporting.
> 
> Any reason not to just remove this feature from U-Boot, as Linux has
> done?

The Linux change for reference: 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=657f28f8811c92724db10d18bbbec70d540147d6

I waffled about removing it, but leaned towards leaving it in because:
- I didn't want to change the existing U-Boot behavior for other 
users.  A google of 'u-boot "nand write"' shows a lot of examples that 
don't include verification of writes, and they should if we remove 
auto-verification.

- The reason it was removed in Linux was "Both UBI and JFFS2 are able 
to read verify what they wrote already.  There are also MTD tests 
which do this verification."  I thought U-Boot was more likely than 
Linux to use raw NAND writes without a filesystem, so leaving it in U-
Boot made sense since the UBI/JFFS2 logic didn't apply as much here.



- I didn't think a lot of people would know they have to explicitly 
verify NAND contents after a write, since they'd assume it was like 
other memories that aren't as lossy.

- The penalty of slightly different code from Linux and a small 
performance hit was worth the gain of auto-verification to me.  I 
viewed consolidating it into one small chunk of code as a happy medium.


The philosophical side of me said to remove it altogether, so I can 
see that perspective too.
Peter
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 24/26] dm: cros_ec: Move cros_ec_i2c over to driver model

2015-01-26 Thread Simon Glass
On 26 January 2015 at 13:14, Simon Glass  wrote:
> On 25 January 2015 at 08:27, Simon Glass  wrote:
>> Update the driver model support, and remove the old code. Change snow to
>> use this new support.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v3: None
>> Changes in v2:
>> - Add patches to tidy up cros_ec using new I2C/SPI features
>>
>>  drivers/misc/cros_ec_i2c.c | 107 
>> +
>>  include/configs/snow.h |   5 +++
>>  2 files changed, 45 insertions(+), 67 deletions(-)
>
> Applied to -u-boot-dm

Sorry, I'm getting ahead of myself. I cannot apply this until the
Samsung I2C driver is applied. So I'm leaving this patch out for now
and will revisit hopefully later in the week.

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


[U-Boot] [PATCH 0/23] x86: Add bare support for Intel Minnowboard Max

2015-01-26 Thread Simon Glass
This series adds support for the Intel Minnowboard Max (called Minnowmax
for short). Along the way a few refactors and additions are made:

- The Intel Firmware Support Package support is moved from queensbay to a
common location
- PCI support for XHCI is added
- A few tweaks are made to the PCI support
- Support for the debug UART (early debug output) is provided
- The microcode tool now also supports reading in header files

This board has been lightly tested. The following seem to work:

- USB2 on the blue port (not USB3), e.g. for keyboard
- Ethernet
- HDMI out and console
- UART
- uSD card
- SPI

SATA is detected but I have not attached a drive to try it. USB3 shows signs
of life but does not detect a USB stick, and crashes when trying to use a
USB Ethernet adaptor.

For SPI some parts cannot be read and others cannot be written. This seems
to be a feature of the Intel hardware configuration. It may be possible to
fix this using the SPI registers but I cannot work out how / lost interest
trying. So far, addresses from 50 to 70 can be used.

I have not tried the ICH GPIO driver but it likely needs work before it will
function. I2C is not supported as there is currently no U-Boot driver for
this.

The zboot command can be used to start a bzImage kernel. Verified boot is
supported - use mkimage to sign images as described in this walk-through:
doc/uImage.FIT/beaglebone_vboot.txt

Boot time is grim:
- 1423ms to set up display (Intel FSP)
- 454ms to scan AHCI (when no devices are connected)
- ~1000ms to power up and start cache-as-RAM init (Intel FSP)
 (this is not benchmarked, may be inaccurate)
- ~950ms to set up memory and initial machine configuration (Intel FSP)
 (this is not benchmarked, may be inaccurate)

So it takes over 4 seconds to get to booting a kernel.

Implementing the Memory Reference Code (MRC) cache should improve this
slightly (perhaps a reduction of 500-1000ms). This cache is implemented for
ivybridge so that code needs to be moved into a generic x86 directory and
plumbed into the FSP code. This has not been done in this series. Also the
video and SATA/AHCI can be disabled if preferred.

It is also possible to run as a coreboot payload. See the instructions in
README.x86 for this. In this case video does not work since coreboot does
not pass through the VESA display information.

To support the single-core 1GB variant, changes would need to be made to
arch/x86/cpu/baytrail/fsp_configs.c to select different values for the
memory. The microcode update may need to change also.

This series is available at u-boot-x86 branch minnow-working.


Simon Glass (23):
  x86: Enhance the microcode tool to support header files as input
  pci: Add a function to find a device by class
  x86: pci: Add PCI IDs for Minnowboard Max
  x86: video: Enable video for Minnowboard Max
  usb: pci: Use pci_find_class() to find the device
  usb: pci: Add XHCI driver for PCI
  x86: Add an option to enabling building a ROM file
  x86: Make MMCONF_BASE_ADDRESS common across x86
  x86: video: Allow video ROM execution to fall back to the other method
  x86: bootstage: Add time measurement for vesa start-up
  x86: Move common FSP code into a common location
  x86: Adjust the FSP types slightly
  x86: Make CAR and DRAM FSP code common
  x86: Move common FSP functions into a common file
  x86: Remove unnecessary casts and fix comment typos
  x86: Allow FSP Kconfig settings for all x86
  x86: Define cache line size
  x86: Allow a UART to be set up before the FSP is ready
  x86: spi: Support ValleyView in ICH SPI driver
  scsi: bootstage: Measure time taken to scan the bus
  x86: Enable bootstage features
  x86: Add some documentation on how to port U-Boot on x86
  x86: Add support for Intel Minnowboard Max

 Makefile   |5 +-
 arch/x86/Kconfig   |   62 +
 arch/x86/cpu/Makefile  |1 +
 arch/x86/cpu/baytrail/Kconfig  |9 +
 arch/x86/cpu/baytrail/Makefile |   10 +
 arch/x86/cpu/baytrail/early_uart.c |   82 +
 arch/x86/cpu/baytrail/fsp_configs.c|  156 +
 arch/x86/cpu/baytrail/pci.c|   47 +
 arch/x86/cpu/baytrail/valleyview.c |   37 +
 arch/x86/cpu/ivybridge/gma.c   |3 +-
 arch/x86/cpu/queensbay/Kconfig |   38 -
 arch/x86/cpu/queensbay/Makefile|4 +-
 arch/x86/cpu/queensbay/fsp_configs.c   |2 +-
 arch/x86/cpu/queensbay/tnc.c   |   29 +-
 arch/x86/cpu/queensbay/tnc_pci.c   |   17 +-
 arch/x86/cpu/queensbay/topcliff.c  |   32 +-
 arch/x86/dts/Makefile  |3 +-
 arch/x86/dts/microcode/m0130673322.dtsi| 3284 
 arch/x86/dts/minnowmax.dts |   45 +
 arch/x86/dts/serial.dtsi 

[U-Boot] [PATCH 15/23] x86: Remove unnecessary casts and fix comment typos

2015-01-26 Thread Simon Glass
Tidy up the FSP support code a little.

Signed-off-by: Simon Glass 
---

 arch/x86/lib/fsp/fsp_support.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
index bf37807..8b639f7 100644
--- a/arch/x86/lib/fsp/fsp_support.c
+++ b/arch/x86/lib/fsp/fsp_support.c
@@ -124,25 +124,25 @@ void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf)
struct fsp_init_params *params_ptr;
struct upd_region *fsp_upd;
 
-   fsp_hdr = (struct fsp_header *)find_fsp_header();
+   fsp_hdr = find_fsp_header();
if (fsp_hdr == NULL) {
/* No valid FSP info header was found */
panic("Invalid FSP header");
}
 
-   fsp_upd = (struct upd_region *)&shared_data.fsp_upd;
+   fsp_upd = &shared_data.fsp_upd;
memset(&rt_buf, 0, sizeof(struct fspinit_rtbuf));
 
/* Reserve a gap in stack top */
rt_buf.common.stack_top = (u32 *)stack_top - 32;
rt_buf.common.boot_mode = boot_mode;
-   rt_buf.common.upd_data = (struct upd_region *)fsp_upd;
+   rt_buf.common.upd_data = fsp_upd;
 
/* Get VPD region start */
fsp_vpd = (struct vpd_region *)(fsp_hdr->img_base +
fsp_hdr->cfg_region_off);
 
-   /* Verifify the VPD data region is valid */
+   /* Verify the VPD data region is valid */
assert((fsp_vpd->img_rev == VPD_IMAGE_REV) &&
   (fsp_vpd->sign == VPD_IMAGE_ID));
 
@@ -150,7 +150,7 @@ void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf)
memcpy(fsp_upd, (void *)(fsp_hdr->img_base + fsp_vpd->upd_offset),
   sizeof(struct upd_region));
 
-   /* Verifify the UPD data region is valid */
+   /* Verify the UPD data region is valid */
assert(fsp_upd->terminator == UPD_TERMINATOR);
 
/* Override any UPD setting if required */
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 01/23] x86: Enhance the microcode tool to support header files as input

2015-01-26 Thread Simon Glass
Sometimes microcode is delivered as a header file. Allow the tool to
support this as well as collecting multiple microcode blocks into a
single update.

Signed-off-by: Simon Glass 
---

 tools/microcode-tool.py | 90 ++---
 1 file changed, 70 insertions(+), 20 deletions(-)

diff --git a/tools/microcode-tool.py b/tools/microcode-tool.py
index 003716d..71c2e91 100755
--- a/tools/microcode-tool.py
+++ b/tools/microcode-tool.py
@@ -76,6 +76,35 @@ def ParseFile(fname):
 microcodes[name] = Microcode(name, data)
 return date, license_text, microcodes
 
+def ParseHeaderFiles(fname_list):
+"""Parse a list of header files and return the component parts
+
+Args:
+fname_list: List of files to parse
+Returns:
+date: String containing date from the file's header
+license_text: List of text lines for the license file
+microcodes:   List of Microcode objects from the file
+"""
+microcodes = {}
+license_text = []
+date = ''
+name = None
+for fname in fname_list:
+name = os.path.basename(fname).lower()
+name = os.path.splitext(name)[0]
+data = []
+with open(fname) as fd:
+for line in fd:
+line = line.rstrip()
+
+# Omit anything after the last comma
+words = line.split(',')[:-1]
+data += [word + ',' for word in words]
+microcodes[name] = Microcode(name, data)
+return date, license_text, microcodes
+
+
 def List(date, microcodes, model):
 """List the available microcode chunks
 
@@ -129,13 +158,13 @@ def FindMicrocode(microcodes, model):
 break
 return found, tried
 
-def CreateFile(date, license_text, mcode, outfile):
+def CreateFile(date, license_text, mcodes, outfile):
 """Create a microcode file in U-Boot's .dtsi format
 
 Args:
 date:   String containing date of original microcode file
 license:List of text lines for the license file
-mcode:  Microcode object to write
+mcodes:  Microcode objects to write (normally only 1)
 outfile:Filename to write to ('-' for stdout)
 """
 out = '''/*%s
@@ -159,15 +188,22 @@ intel,processor-flags = <%#x>;
 data = <%s
 \t>;'''
 words = ''
-for i in range(len(mcode.words)):
-if not (i & 3):
-words += '\n'
-val = mcode.words[i]
-# Change each word so it will be little-endian in the FDT
-# This data is needed before RAM is available on some platforms so we
-# cannot do an endianness swap on boot.
-val = struct.unpack("I", val))[0]
-words += '\t%#010x' % val
+add_comments = len(mcodes) > 1
+for mcode in mcodes:
+if add_comments:
+words += '\n/* %s */' % mcode.name
+for i in range(len(mcode.words)):
+if not (i & 3):
+words += '\n'
+val = mcode.words[i]
+# Change each word so it will be little-endian in the FDT
+# This data is needed before RAM is available on some platforms so
+# we cannot do an endianness swap on boot.
+val = struct.unpack("I", val))[0]
+words += '\t%#010x' % val
+
+# Use the first microcode for the headers
+mcode = mcodes[0]
 
 # Take care to avoid adding a space before a tab
 text = ''
@@ -187,8 +223,8 @@ data = <%s
 print >> sys.stderr, "Creating directory '%s'" % MICROCODE_DIR
 os.makedirs(MICROCODE_DIR)
 outfile = os.path.join(MICROCODE_DIR, mcode.name + '.dtsi')
-print >> sys.stderr, "Writing microcode for '%s' to '%s'" % (
- mcode.name, outfile)
+print >> sys.stderr, "Writing microcode for '%s' to '%s'" % (
+', '.join([mcode.name for mcode in mcodes]), outfile)
 with open(outfile, 'w') as fd:
 print >> fd, out % tuple(args)
 
@@ -198,8 +234,12 @@ def MicrocodeTool():
 parser = OptionParser()
 parser.add_option('-d', '--mcfile', type='string', action='store',
 help='Name of microcode.dat file')
+parser.add_option('-H', '--headerfile', type='string', action='append',
+help='Name of .h file containing microcode')
 parser.add_option('-m', '--model', type='string', action='store',
-help='Model name to extract')
+help="Model name to extract ('all' for all)")
+parser.add_option('-M', '--multiple', type='string', action='store',
+help="Allow output of multiple models")
 parser.add_option('-o', '--outfile', type='string', action='store',
 help='Filename to use for output (- for stdout), default 
is'
 ' %s/.dtsi' % MICROCODE_DIR)
@@ -224,9 +264,14 @@ def MicrocodeTool():
 if cmd not in commands:
 parser.error("U

[U-Boot] [PATCH 06/23] usb: pci: Add XHCI driver for PCI

2015-01-26 Thread Simon Glass
Add a driver which locates the available XHCI controllers on the PCI bus
and makes them available.

Signed-off-by: Simon Glass 
---

 drivers/usb/host/Makefile   |  1 +
 drivers/usb/host/xhci-pci.c | 60 +
 2 files changed, 61 insertions(+)
 create mode 100644 drivers/usb/host/xhci-pci.c

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index c11b551..66d6e9a 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_USB_XHCI) += xhci.o xhci-mem.o xhci-ring.o
 obj-$(CONFIG_USB_XHCI_KEYSTONE) += xhci-keystone.o
 obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
 obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
+obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 
 # designware
 obj-$(CONFIG_USB_DWC2) += dwc2.o
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
new file mode 100644
index 000..361fcce
--- /dev/null
+++ b/drivers/usb/host/xhci-pci.c
@@ -0,0 +1,60 @@
+/*
+ * Copyright (c) 2015, Google, Inc
+ * Written by Simon Glass 
+ * All rights reserved.
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "xhci.h"
+
+/*
+ * Create the appropriate control structures to manage a new XHCI host
+ * controller.
+ */
+int xhci_hcd_init(int index, struct xhci_hccr **ret_hccr,
+ struct xhci_hcor **ret_hcor)
+{
+   struct xhci_hccr *hccr;
+   struct xhci_hcor *hcor;
+   pci_dev_t pdev;
+   uint32_t cmd;
+   int len;
+
+   pdev = pci_find_class(PCI_CLASS_SERIAL_USB_XHCI, index);
+   if (pdev < 0) {
+   printf("XHCI host controller not found\n");
+   return -1;
+   }
+
+   hccr = (struct xhci_hccr *)pci_map_bar(pdev,
+   PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
+   len = HC_LENGTH(xhci_readl(&hccr->cr_capbase));
+   hcor = (struct xhci_hcor *)((uint32_t)hccr + len);
+
+   debug("XHCI-PCI init hccr 0x%x and hcor 0x%x hc_length %d\n",
+ (uint32_t)hccr, (uint32_t)hcor, len);
+
+   *ret_hccr = hccr;
+   *ret_hcor = hcor;
+
+   /* enable busmaster */
+   pci_read_config_dword(pdev, PCI_COMMAND, &cmd);
+   cmd |= PCI_COMMAND_MASTER;
+   pci_write_config_dword(pdev, PCI_COMMAND, cmd);
+
+   return 0;
+}
+
+/*
+ * Destroy the appropriate control structures corresponding * to the XHCI host
+ * controller
+ */
+void xhci_hcd_stop(int index)
+{
+}
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 16/23] x86: Allow FSP Kconfig settings for all x86

2015-01-26 Thread Simon Glass
While queensbay is the first chip with these settings, others will want to
use them too. Make them common.

Signed-off-by: Simon Glass 
---

 arch/x86/Kconfig   | 38 ++
 arch/x86/cpu/queensbay/Kconfig | 38 --
 2 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1523c91..73a7392 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -344,6 +344,44 @@ config TSC_FREQ_IN_MHZ
help
  The running frequency in MHz of Time-Stamp Counter (TSC).
 
+config HAVE_FSP
+   bool "Add an Firmware Support Package binary"
+   help
+ Select this option to add an Firmware Support Package binary to
+ the resulting U-Boot image. It is a binary blob which U-Boot uses
+ to set up SDRAM and other chipset specific initialization.
+
+ Note: Without this binary U-Boot will not be able to set up its
+ SDRAM so will not boot.
+
+config FSP_FILE
+   string "Firmware Support Package binary filename"
+   depends on HAVE_FSP
+   default "fsp.bin"
+   help
+ The filename of the file to use as Firmware Support Package binary
+ in the board directory.
+
+config FSP_ADDR
+   hex "Firmware Support Package binary location"
+   depends on HAVE_FSP
+   default 0xfffc
+   help
+ FSP is not Position Independent Code (PIC) and the whole FSP has to
+ be rebased if it is placed at a location which is different from the
+ perferred base address specified during the FSP build. Use Intel's
+ Binary Configuration Tool (BCT) to do the rebase.
+
+ The default base address of 0xfffc indicates that the binary must
+ be located at offset 0xc from the beginning of a 1MB flash device.
+
+config FSP_TEMP_RAM_ADDR
+   hex
+   default 0x200
+   help
+ Stack top address which is used in FspInit after DRAM is ready and
+ CAR is disabled.
+
 source "arch/x86/cpu/coreboot/Kconfig"
 
 source "arch/x86/cpu/ivybridge/Kconfig"
diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig
index f6b5201..397e599 100644
--- a/arch/x86/cpu/queensbay/Kconfig
+++ b/arch/x86/cpu/queensbay/Kconfig
@@ -11,44 +11,6 @@ config INTEL_QUEENSBAY
 
 if INTEL_QUEENSBAY
 
-config HAVE_FSP
-   bool "Add an Firmware Support Package binary"
-   help
- Select this option to add an Firmware Support Package binary to
- the resulting U-Boot image. It is a binary blob which U-Boot uses
- to set up SDRAM and other chipset specific initialization.
-
- Note: Without this binary U-Boot will not be able to set up its
- SDRAM so will not boot.
-
-config FSP_FILE
-   string "Firmware Support Package binary filename"
-   depends on HAVE_FSP
-   default "fsp.bin"
-   help
- The filename of the file to use as Firmware Support Package binary
- in the board directory.
-
-config FSP_ADDR
-   hex "Firmware Support Package binary location"
-   depends on HAVE_FSP
-   default 0xfffc
-   help
- FSP is not Position Independent Code (PIC) and the whole FSP has to
- be rebased if it is placed at a location which is different from the
- perferred base address specified during the FSP build. Use Intel's
- Binary Configuration Tool (BCT) to do the rebase.
-
- The default base address of 0xfffc indicates that the binary must
- be located at offset 0xc from the beginning of a 1MB flash device.
-
-config FSP_TEMP_RAM_ADDR
-   hex
-   default 0x200
-   help
- Stack top address which is used in FspInit after DRAM is ready and
- CAR is disabled.
-
 config HAVE_CMC
bool "Add a Chipset Micro Code state machine binary"
help
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 05/23] usb: pci: Use pci_find_class() to find the device

2015-01-26 Thread Simon Glass
Use the new utility function instead of local code.

Signed-off-by: Simon Glass 
---

 drivers/usb/host/ehci-pci.c | 53 +
 1 file changed, 1 insertion(+), 52 deletions(-)

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 991b199..b9eabc5 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -34,57 +34,6 @@ static struct pci_device_id ehci_pci_ids[] = {
{0, 0}
 };
 #else
-static pci_dev_t ehci_find_class(int index)
-{
-   int bus;
-   int devnum;
-   pci_dev_t bdf;
-   uint32_t class;
-
-   for (bus = 0; bus <= pci_last_busno(); bus++) {
-   for (devnum = 0; devnum < PCI_MAX_PCI_DEVICES-1; devnum++) {
-   pci_read_config_dword(PCI_BDF(bus, devnum, 0),
- PCI_CLASS_REVISION, &class);
-   if (class >> 16 == 0x)
-   continue;
-
-   for (bdf = PCI_BDF(bus, devnum, 0);
-   bdf <= PCI_BDF(bus, devnum,
-   PCI_MAX_PCI_FUNCTIONS - 1);
-   bdf += PCI_BDF(0, 0, 1)) {
-   pci_read_config_dword(bdf, PCI_CLASS_REVISION,
- &class);
-   class >>= 8;
-   /*
-* Here be dragons! In case we have multiple
-* PCI EHCI controllers, this function will
-* be called multiple times as well. This
-* function will scan the PCI busses, always
-* starting from bus 0, device 0, function 0,
-* until it finds an USB controller. The USB
-* stack gives us an 'index' of a controller
-* that is currently being registered, which
-* is a number, starting from 0 and growing
-* in ascending order as controllers are added.
-* To avoid probing the same controller in tne
-* subsequent runs of this function, we will
-* skip 'index - 1' detected controllers and
-* report the index'th controller.
-*/
-   if (class != PCI_CLASS_SERIAL_USB_EHCI)
-   continue;
-   if (index) {
-   index--;
-   continue;
-   }
-   /* Return index'th controller. */
-   return bdf;
-   }
-   }
-   }
-
-   return -ENODEV;
-}
 #endif
 
 /*
@@ -102,7 +51,7 @@ int ehci_hcd_init(int index, enum usb_init_type init,
 #ifdef CONFIG_PCI_EHCI_DEVICE
pdev = pci_find_devices(ehci_pci_ids, CONFIG_PCI_EHCI_DEVICE);
 #else
-   pdev = ehci_find_class(index);
+   pdev = pci_find_class(PCI_CLASS_SERIAL_USB_EHCI, index);
 #endif
if (pdev < 0) {
printf("EHCI host controller not found\n");
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 04/23] x86: video: Enable video for Minnowboard Max

2015-01-26 Thread Simon Glass
This board uses a new PCI ID.

Signed-off-by: Simon Glass 
---

 drivers/video/vesa_fb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/vesa_fb.c b/drivers/video/vesa_fb.c
index 3dacafd..3a0fea2 100644
--- a/drivers/video/vesa_fb.c
+++ b/drivers/video/vesa_fb.c
@@ -23,6 +23,7 @@ struct pci_device_id vesa_video_ids[] = {
{ .vendor = 0x1002, .device = 0x5159 },
{ .vendor = 0x1002, .device = 0x4752 },
{ .vendor = 0x1002, .device = 0x5452 },
+   { .vendor = 0x8086, .device = 0x0f31 },
{},
 };
 
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 03/23] x86: pci: Add PCI IDs for Minnowboard Max

2015-01-26 Thread Simon Glass
This board includes a few IDs we have not seen before.

Signed-off-by: Simon Glass 
---

 include/pci_ids.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/pci_ids.h b/include/pci_ids.h
index 26f4748..1012abe 100644
--- a/include/pci_ids.h
+++ b/include/pci_ids.h
@@ -1346,6 +1346,7 @@
 
 #define PCI_VENDOR_ID_REALTEK  0x10ec
 #define PCI_DEVICE_ID_REALTEK_8139 0x8139
+#define PCI_DEVICE_ID_REALTEK_8168 0x8168
 
 #define PCI_VENDOR_ID_XILINX   0x10ee
 #define PCI_DEVICE_ID_RME_DIGI96   0x3fc0
@@ -2594,6 +2595,10 @@
 #define PCI_DEVICE_ID_INTEL_I960   0x0960
 #define PCI_DEVICE_ID_INTEL_I960RM 0x0962
 #define PCI_DEVICE_ID_INTEL_CENTERTON_ILB  0x0c60
+#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_SDIO0x0f15
+#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_SDCARD  0x0f16
+#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_LPC 0x0f1c
+#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_SATA0x0f23
 #define PCI_DEVICE_ID_INTEL_82541ER0x1078
 #define PCI_DEVICE_ID_INTEL_82541GI_LF 0x107c
 #define PCI_DEVICE_ID_INTEL_82542  0x1000
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 02/23] pci: Add a function to find a device by class

2015-01-26 Thread Simon Glass
There is an existing function prototype in the header file but it is not
implemented. Implement something similar.

Signed-off-by: Simon Glass 
---

 drivers/pci/pci.c | 38 ++
 include/pci.h |  3 +--
 2 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 950a247..215a092 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -15,6 +15,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -236,6 +237,43 @@ pci_dev_t pci_find_devices(struct pci_device_id *ids, int 
index)
return -1;
 }
 
+pci_dev_t pci_find_class(uint find_class, int index)
+{
+   int bus;
+   int devnum;
+   pci_dev_t bdf;
+   uint32_t class;
+
+   for (bus = 0; bus <= pci_last_busno(); bus++) {
+   for (devnum = 0; devnum < PCI_MAX_PCI_DEVICES-1; devnum++) {
+   pci_read_config_dword(PCI_BDF(bus, devnum, 0),
+ PCI_CLASS_REVISION, &class);
+   if (class >> 16 == 0x)
+   continue;
+
+   for (bdf = PCI_BDF(bus, devnum, 0);
+   bdf <= PCI_BDF(bus, devnum,
+   PCI_MAX_PCI_FUNCTIONS - 1);
+   bdf += PCI_BDF(0, 0, 1)) {
+   pci_read_config_dword(bdf, PCI_CLASS_REVISION,
+ &class);
+   class >>= 8;
+
+   if (class != find_class)
+   continue;
+   if (index) {
+   index--;
+   continue;
+   }
+   /* Return index'th controller. */
+   return bdf;
+   }
+   }
+   }
+
+   return -ENODEV;
+}
+
 pci_dev_t pci_find_device(unsigned int vendor, unsigned int device, int index)
 {
struct pci_device_id ids[2] = { {}, {0, 0} };
diff --git a/include/pci.h b/include/pci.h
index 4fbb8f6..004a048 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -644,8 +644,7 @@ extern int pciauto_config_device(struct pci_controller 
*hose, pci_dev_t dev);
 
 extern pci_dev_t pci_find_device (unsigned int vendor, unsigned int device, 
int index);
 extern pci_dev_t pci_find_devices (struct pci_device_id *ids, int index);
-extern pci_dev_t pci_find_class(int wanted_class, int wanted_sub_code,
-   int wanted_prog_if, int index);
+pci_dev_t pci_find_class(unsigned int find_class, int index);
 
 extern int pci_hose_config_device(struct pci_controller *hose,
  pci_dev_t dev,
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 20/23] scsi: bootstage: Measure time taken to scan the bus

2015-01-26 Thread Simon Glass
On some hardware this time can be significant. Add bootstage support for
measuring this. The result can be obtained using 'bootstage report' or
passed on to the Linux via the device tree.

Signed-off-by: Simon Glass 
---

 common/cmd_scsi.c   | 2 ++
 include/bootstage.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/common/cmd_scsi.c b/common/cmd_scsi.c
index cbc107e..a0a62eb 100644
--- a/common/cmd_scsi.c
+++ b/common/cmd_scsi.c
@@ -217,8 +217,10 @@ void scsi_init(void)
   (busdevfunc >> 8) & 0x7);
}
 #endif
+   bootstage_start(BOOTSTAGE_ID_ACCUM_SCSI, "ahci");
scsi_low_level_init(busdevfunc);
scsi_scan(1);
+   bootstage_accum(BOOTSTAGE_ID_ACCUM_SCSI);
 }
 #endif
 
diff --git a/include/bootstage.h b/include/bootstage.h
index df13ab2..6b7588d 100644
--- a/include/bootstage.h
+++ b/include/bootstage.h
@@ -194,6 +194,7 @@ enum bootstage_id {
BOOTSTAGE_ID_MAIN_CPU_READY,
 
BOOTSTAGE_ID_ACCUM_LCD,
+   BOOTSTAGE_ID_ACCUM_SCSI,
 
/* a few spare for the user, from here */
BOOTSTAGE_ID_USER,
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 17/23] x86: Define cache line size

2015-01-26 Thread Simon Glass
This avoids a warning in the Realtek Ethernet driver. The value may not
matter on x86.

Signed-off-by: Simon Glass 
---

 arch/x86/include/asm/cache.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/include/asm/cache.h b/arch/x86/include/asm/cache.h
index 508b63f..fff1edd 100644
--- a/arch/x86/include/asm/cache.h
+++ b/arch/x86/include/asm/cache.h
@@ -7,6 +7,8 @@
 #ifndef __X86_CACHE_H__
 #define __X86_CACHE_H__
 
+#define CONFIG_SYS_CACHELINE_SIZE  16
+
 /*
  * If CONFIG_SYS_CACHELINE_SIZE is defined use it for DMA alignment.  Otherwise
  * use 64-bytes, a safe default for x86.
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 21/23] x86: Enable bootstage features

2015-01-26 Thread Simon Glass
Allow measuring of boot time using bootstage.

Signed-off-by: Simon Glass 
---

 include/configs/x86-common.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h
index ecedfc3..66d4894 100644
--- a/include/configs/x86-common.h
+++ b/include/configs/x86-common.h
@@ -245,6 +245,9 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
+#define CONFIG_BOOTSTAGE
+#define CONFIG_CMD_BOOTSTAGE
+
 #define CONFIG_CMD_USB
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 08/23] x86: Make MMCONF_BASE_ADDRESS common across x86

2015-01-26 Thread Simon Glass
This setting will be used by more than just ivybridge so make it common.

Signed-off-by: Simon Glass 
---

 arch/x86/Kconfig | 12 
 board/google/chromebook_link/Kconfig |  1 -
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 90e828a..1523c91 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -356,4 +356,16 @@ source "board/google/chromebook_link/Kconfig"
 
 source "board/intel/crownbay/Kconfig"
 
+config MMCONF_BASE_ADDRESS
+   hex
+default 0xe000
+   help
+ This is the address of PCI configuration space. It can be set up
+ amost anywhere. Before it is set up, it is possible to access PCI
+ configuration space through I/O access, but memory access is more
+ convenient. Using this, PCI can be scanned and configured. This
+ should be set to a region that does not conflict with memory
+ assigned to PCI devices - i.e. the memory and prefetch regions, as
+ passed to pci_set_region().
+
 endmenu
diff --git a/board/google/chromebook_link/Kconfig 
b/board/google/chromebook_link/Kconfig
index 33a31f3..948af59 100644
--- a/board/google/chromebook_link/Kconfig
+++ b/board/google/chromebook_link/Kconfig
@@ -23,7 +23,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
select BOARD_ROMSIZE_KB_8192
 
 config MMCONF_BASE_ADDRESS
-   hex
default 0xf000
 
 config EARLY_POST_CROS_EC
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 12/23] x86: Adjust the FSP types slightly

2015-01-26 Thread Simon Glass
To avoid casts, find_fsp_header() should return a pointer. Add asmlinkage
to two API functions which use that convention. UPD_TERMINATOR is common
so move it into a common file.

Signed-off-by: Simon Glass 
---

 arch/x86/include/asm/arch-queensbay/fsp/fsp_vpd.h | 2 --
 arch/x86/include/asm/fsp/fsp_api.h| 6 --
 arch/x86/include/asm/fsp/fsp_support.h| 4 +++-
 arch/x86/lib/fsp/fsp_support.c| 4 ++--
 4 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/arch-queensbay/fsp/fsp_vpd.h 
b/arch/x86/include/asm/arch-queensbay/fsp/fsp_vpd.h
index bce58b1..3c57558 100644
--- a/arch/x86/include/asm/arch-queensbay/fsp/fsp_vpd.h
+++ b/arch/x86/include/asm/arch-queensbay/fsp/fsp_vpd.h
@@ -10,8 +10,6 @@
 #ifndef __VPDHEADER_H__
 #define __VPDHEADER_H__
 
-#define UPD_TERMINATOR 0x55AA
-
 struct __packed upd_region {
u64 sign;   /* Offset 0x */
u64 reserved;   /* Offset 0x0008 */
diff --git a/arch/x86/include/asm/fsp/fsp_api.h 
b/arch/x86/include/asm/fsp/fsp_api.h
index a9d7156..2d34d13 100644
--- a/arch/x86/include/asm/fsp/fsp_api.h
+++ b/arch/x86/include/asm/fsp/fsp_api.h
@@ -8,6 +8,8 @@
 #ifndef __FSP_API_H__
 #define __FSP_API_H__
 
+#include 
+
 /*
  * FspInit continuation function prototype.
  * Control will be returned to this callback function after FspInit API call.
@@ -47,9 +49,9 @@ struct fsp_notify_params {
 };
 
 /* FspInit API function prototype */
-typedef u32 (*fsp_init_f)(struct fsp_init_params *params);
+typedef asmlinkage u32 (*fsp_init_f)(struct fsp_init_params *params);
 
 /* FspNotify API function prototype */
-typedef u32 (*fsp_notify_f)(struct fsp_notify_params *params);
+typedef asmlinkage u32 (*fsp_notify_f)(struct fsp_notify_params *params);
 
 #endif
diff --git a/arch/x86/include/asm/fsp/fsp_support.h 
b/arch/x86/include/asm/fsp/fsp_support.h
index 6329cfe..c6c7dc0 100644
--- a/arch/x86/include/asm/fsp/fsp_support.h
+++ b/arch/x86/include/asm/fsp/fsp_support.h
@@ -26,6 +26,8 @@ struct shared_data {
 
 #define FSP_LOWMEM_BASE0x10UL
 #define FSP_HIGHMEM_BASE   0x1ULL
+#define UPD_TERMINATOR 0x55AA
+
 
 /**
  * FSP Continuation assembly helper routine
@@ -61,7 +63,7 @@ void fsp_continue(struct shared_data *shared_data, u32 status,
  *
  * @retval: the offset of FSP header. If signature is invalid, returns 0.
  */
-u32 find_fsp_header(void);
+struct fsp_header *find_fsp_header(void);
 
 /**
  * FSP initialization wrapper function.
diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
index f6ae85a..bf37807 100644
--- a/arch/x86/lib/fsp/fsp_support.c
+++ b/arch/x86/lib/fsp/fsp_support.c
@@ -30,7 +30,7 @@ static bool compare_guid(const struct efi_guid *guid1,
return false;
 }
 
-u32 __attribute__((optimize("O0"))) find_fsp_header(void)
+struct fsp_header *__attribute__((optimize("O0"))) find_fsp_header(void)
 {
/*
 * This function may be called before the a stack is established,
@@ -84,7 +84,7 @@ u32 __attribute__((optimize("O0"))) find_fsp_header(void)
fsp = 0;
}
 
-   return (u32)fsp;
+   return (struct fsp_header *)fsp;
 }
 
 void fsp_continue(struct shared_data *shared_data, u32 status, void *hob_list)
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 07/23] x86: Add an option to enabling building a ROM file

2015-01-26 Thread Simon Glass
Rather than requiring the Makefile to be modified, provide a build option to
enable the ROM to be built.

We cannot do this by default since it requires binary blobs. Without these
the build will fail.

Signed-off-by: Simon Glass 
---

 Makefile   |  5 +++--
 doc/README.x86 | 10 ++
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/Makefile b/Makefile
index a876f1f..c6e4ad1 100644
--- a/Makefile
+++ b/Makefile
@@ -729,8 +729,9 @@ ALL-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
 endif
 ALL-$(CONFIG_REMAKE_ELF) += u-boot.elf
 
-# We can't do this yet due to the need for binary blobs
-# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+ifneq ($(BUILD_ROM),)
+ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+endif
 
 # enable combined SPL/u-boot/dtb rules for tegra
 ifneq ($(CONFIG_TEGRA),)
diff --git a/doc/README.x86 b/doc/README.x86
index 7df8cc5..809a291 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -51,9 +51,11 @@ Building ROM version of U-Boot (hereafter referred to as 
u-boot.rom) is a
 little bit tricky, as generally it requires several binary blobs which are not
 shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is
 not turned on by default in the U-Boot source tree. Firstly, you need turn it
-on by uncommenting the following line in the main U-Boot Makefile:
+on by enabling the ROM board:
 
-# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+$ export BUILD_ROM=y
+
+This tells the Makefile to build u-boot.rom as a target.
 
 Link-specific instructions:
 
@@ -126,11 +128,11 @@ Make sure 0x111 matches CONFIG_SYS_TEXT_BASE and 
0x1110015 matches the
 symbol address of _start (in arch/x86/cpu/start.S).
 
 If you want to use ELF as the coreboot payload, change U-Boot configuration to
-use CONFIG_OF_EMBED.
+use CONFIG_OF_EMBED instead of CONFIG_OF_SEPARATE.
 
 CPU Microcode
 -
-Modern CPU usually requires a special bit stream called microcode [5] to be
+Modern CPUs usually requires a special bit stream called microcode [5] to be
 loaded on the processor after power up in order to function properly. U-Boot
 has already integrated these as hex dumps in the source tree.
 
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 14/23] x86: Move common FSP functions into a common file

2015-01-26 Thread Simon Glass
Since these board functions seem to be the same for all boards which use
FSP, move them into a common file. We can adjust this later if future FSPs
need more flexibility.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/queensbay/tnc.c  | 27 
 arch/x86/cpu/queensbay/tnc_pci.c  | 15 ---
 arch/x86/cpu/queensbay/topcliff.c | 32 +-
 arch/x86/include/asm/u-boot-x86.h | 17 
 arch/x86/lib/fsp/Makefile |  1 +
 arch/x86/lib/fsp/fsp_common.c | 88 +++
 6 files changed, 108 insertions(+), 72 deletions(-)
 create mode 100644 arch/x86/lib/fsp/fsp_common.c

diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
index f9b3bfa..30ab725 100644
--- a/arch/x86/cpu/queensbay/tnc.c
+++ b/arch/x86/cpu/queensbay/tnc.c
@@ -43,30 +43,3 @@ int arch_cpu_init(void)
 
return 0;
 }
-
-int print_cpuinfo(void)
-{
-   post_code(POST_CPU_INFO);
-   return default_print_cpuinfo();
-}
-
-void reset_cpu(ulong addr)
-{
-   /* cold reset */
-   outb(0x06, PORT_RESET);
-}
-
-void board_final_cleanup(void)
-{
-   u32 status;
-
-   /* call into FspNotify */
-   debug("Calling into FSP (notify phase INIT_PHASE_BOOT): ");
-   status = fsp_notify(NULL, INIT_PHASE_BOOT);
-   if (status != FSP_SUCCESS)
-   debug("fail, error code %x\n", status);
-   else
-   debug("OK\n");
-
-   return;
-}
diff --git a/arch/x86/cpu/queensbay/tnc_pci.c b/arch/x86/cpu/queensbay/tnc_pci.c
index 9b0b725..6c291f9 100644
--- a/arch/x86/cpu/queensbay/tnc_pci.c
+++ b/arch/x86/cpu/queensbay/tnc_pci.c
@@ -44,18 +44,3 @@ void board_pci_setup_hose(struct pci_controller *hose)
 
hose->region_count = 4;
 }
-
-int board_pci_post_scan(struct pci_controller *hose)
-{
-   u32 status;
-
-   /* call into FspNotify */
-   debug("Calling into FSP (notify phase INIT_PHASE_PCI): ");
-   status = fsp_notify(NULL, INIT_PHASE_PCI);
-   if (status != FSP_SUCCESS)
-   debug("fail, error code %x\n", status);
-   else
-   debug("OK\n");
-
-   return 0;
-}
diff --git a/arch/x86/cpu/queensbay/topcliff.c 
b/arch/x86/cpu/queensbay/topcliff.c
index b01422a..25032cc 100644
--- a/arch/x86/cpu/queensbay/topcliff.c
+++ b/arch/x86/cpu/queensbay/topcliff.c
@@ -5,43 +5,15 @@
  */
 
 #include 
-#include 
-#include 
-#include 
 #include 
-#include 
 
 static struct pci_device_id mmc_supported[] = {
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_0 },
{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_SDIO_1 },
-   { }
 };
 
 int cpu_mmc_init(bd_t *bis)
 {
-   struct sdhci_host *mmc_host;
-   pci_dev_t devbusfn;
-   u32 iobase;
-   int ret;
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(mmc_supported); i++) {
-   devbusfn =  pci_find_devices(mmc_supported, i);
-   if (devbusfn == -1)
-   return -ENODEV;
-
-   mmc_host = (struct sdhci_host *)malloc(sizeof(struct 
sdhci_host));
-   if (!mmc_host)
-   return -ENOMEM;
-
-   mmc_host->name = "Topcliff SDHCI";
-   pci_read_config_dword(devbusfn, PCI_BASE_ADDRESS_0, &iobase);
-   mmc_host->ioaddr = (void *)iobase;
-   mmc_host->quirks = 0;
-   ret = add_sdhci(mmc_host, 0, 0);
-   if (ret)
-   return ret;
-   }
-
-   return 0;
+   return fsp_cpu_mmc_init("Topcliff SDHCI", mmc_supported,
+   ARRAY_SIZE(mmc_supported));
 }
diff --git a/arch/x86/include/asm/u-boot-x86.h 
b/arch/x86/include/asm/u-boot-x86.h
index b98afa8..44c24ff 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -45,6 +45,23 @@ ulong board_get_usable_ram_top(ulong total_size);
 void dram_init_banksize(void);
 int default_print_cpuinfo(void);
 
+struct pci_device_id;
+
+/**
+ * fsp_cpu_mmc_init() - set up PCI MMC devices
+ *
+ * This finds all the matching PCI IDs and sets them up as MMC devices.
+ *
+ * @name:  Name to use for devices
+ * @mmc_supported: PCI IDs to search for
+ * @num_ids:   Number of elements in @mmc_supported
+ */
+int fsp_cpu_mmc_init(const char *name, struct pci_device_id mmc_supported[],
+int num_ids);
+
+/* Set up a UART which can be used with printch(), printhex8(), etc. */
+int setup_early_uart(void);
+
 void setup_pcat_compatibility(void);
 
 void isa_unmap_rom(u32 addr);
diff --git a/arch/x86/lib/fsp/Makefile b/arch/x86/lib/fsp/Makefile
index 3a2bac0..5b12c12 100644
--- a/arch/x86/lib/fsp/Makefile
+++ b/arch/x86/lib/fsp/Makefile
@@ -5,5 +5,6 @@
 #
 
 obj-y += fsp_car.o
+obj-y += fsp_common.o
 obj-y += fsp_dram.o
 obj-y += fsp_support.o
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
new file mode 100644
index 000..846c136
--- /dev/null
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -0,0

[U-Boot] [PATCH 19/23] x86: spi: Support ValleyView in ICH SPI driver

2015-01-26 Thread Simon Glass
The base address is found in a different way and the protection bit is also
in a different place. Otherwise it is very similar.

Signed-off-by: Simon Glass 
---

 drivers/spi/ich.c | 56 ---
 drivers/spi/ich.h | 11 ++-
 2 files changed, 47 insertions(+), 20 deletions(-)

diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index fdff158..da85779 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -7,6 +7,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +22,7 @@
 struct ich_ctlr {
pci_dev_t dev;  /* PCI device number */
int ich_version;/* Controller version, 7 or 9 */
+   bool use_sbase; /* Use SBASE instead of RCB */
int ichspi_lock;
int locked;
uint8_t *opmenu;
@@ -145,7 +147,7 @@ struct spi_slave *spi_setup_slave(unsigned int bus, 
unsigned int cs,
 * ICH 7 SPI controller only supports array read command
 * and byte program command for SST flash
 */
-   if (ctlr.ich_version == 7) {
+   if (ctlr.ich_version == 7 || ctlr.use_sbase) {
ich->slave.op_mode_rx = SPI_OPM_RX_AS;
ich->slave.op_mode_tx = SPI_OPM_TX_BP;
}
@@ -181,7 +183,8 @@ static int get_ich_version(uint16_t device_id)
if ((device_id >= PCI_DEVICE_ID_INTEL_COUGARPOINT_LPC_MIN &&
 device_id <= PCI_DEVICE_ID_INTEL_COUGARPOINT_LPC_MAX) ||
(device_id >= PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MIN &&
-device_id <= PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MAX))
+device_id <= PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MAX) ||
+   device_id == PCI_DEVICE_ID_INTEL_VALLEYVIEW_LPC)
return 9;
 
return 0;
@@ -204,14 +207,14 @@ static int ich9_can_do_33mhz(pci_dev_t dev)
return speed == 1;
 }
 
-static int ich_find_spi_controller(pci_dev_t *devp, int *ich_versionp)
+static int ich_find_spi_controller(struct ich_ctlr *ich)
 {
int last_bus = pci_last_busno();
int bus;
 
if (last_bus == -1) {
debug("No PCI busses?\n");
-   return -1;
+   return -ENODEV;
}
 
for (bus = 0; bus <= last_bus; bus++) {
@@ -225,24 +228,33 @@ static int ich_find_spi_controller(pci_dev_t *devp, int 
*ich_versionp)
device_id = ids >> 16;
 
if (vendor_id == PCI_VENDOR_ID_INTEL) {
-   *devp = dev;
-   *ich_versionp = get_ich_version(device_id);
-   return 0;
+   ich->dev = dev;
+   ich->ich_version = get_ich_version(device_id);
+   if (device_id == PCI_DEVICE_ID_INTEL_VALLEYVIEW_LPC)
+   ich->use_sbase = true;
+   return ich->ich_version == 0 ? -ENODEV : 0;
}
}
 
debug("ICH SPI: No ICH found.\n");
-   return -1;
+   return -ENODEV;
 }
 
 static int ich_init_controller(struct ich_ctlr *ctlr)
 {
uint8_t *rcrb; /* Root Complex Register Block */
uint32_t rcba; /* Root Complex Base Address */
+   uint32_t sbase_addr;
+   uint8_t *sbase;
 
pci_read_config_dword(ctlr->dev, 0xf0, &rcba);
/* Bits 31-14 are the base address, 13-1 are reserved, 0 is enable. */
rcrb = (uint8_t *)(rcba & 0xc000);
+
+   /* SBASE is similar */
+   pci_read_config_dword(ctlr->dev, 0x54, &sbase_addr);
+   sbase = (uint8_t *)(sbase_addr & 0xfe00);
+
if (ctlr->ich_version == 7) {
struct ich7_spi_regs *ich7_spi;
 
@@ -262,7 +274,10 @@ static int ich_init_controller(struct ich_ctlr *ctlr)
} else if (ctlr->ich_version == 9) {
struct ich9_spi_regs *ich9_spi;
 
-   ich9_spi = (struct ich9_spi_regs *)(rcrb + 0x3800);
+   if (ctlr->use_sbase)
+   ich9_spi = (struct ich9_spi_regs *)sbase;
+   else
+   ich9_spi = (struct ich9_spi_regs *)(rcrb + 0x3800);
ctlr->ichspi_lock = ich_readw(&ich9_spi->hsfs) & HSFS_FLOCKDN;
ctlr->opmenu = ich9_spi->opmenu;
ctlr->menubytes = sizeof(ich9_spi->opmenu);
@@ -282,12 +297,13 @@ static int ich_init_controller(struct ich_ctlr *ctlr)
  ctlr->ich_version);
return -1;
}
-   debug("ICH SPI: Version %d detected\n", ctlr->ich_version);
 
/* Work out the maximum speed we can support */
ctlr->max_speed = 2000;
if (ctlr->ich_version == 9 && ich9_can_do_33mhz(ctlr->dev))
ctlr->max_speed = 3300;
+   debug("ICH SPI: Version %d detected at %p, speed %ld\n",
+ ctlr->ich_version, ctlr->base, ctlr->max_speed);
 
ich_set_bbar(ctlr, 0);
 
@@ -298,7 +314,7 @@ void spi_init(void)
 {
uint8_t bios_cntl;
 
-   if (ich_find_spi_controller(&ct

[U-Boot] [PATCH 09/23] x86: video: Allow video ROM execution to fall back to the other method

2015-01-26 Thread Simon Glass
If the BIOS emulator is not available, allow use of native execution if
available, and vice versa. This can be controlled by the caller.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/ivybridge/gma.c |  3 ++-
 drivers/pci/pci_rom.c| 32 +---
 drivers/video/vesa_fb.c  |  6 +++---
 include/pci_rom.h| 15 +--
 4 files changed, 43 insertions(+), 13 deletions(-)

diff --git a/arch/x86/cpu/ivybridge/gma.c b/arch/x86/cpu/ivybridge/gma.c
index 6cf9654..821ea25 100644
--- a/arch/x86/cpu/ivybridge/gma.c
+++ b/arch/x86/cpu/ivybridge/gma.c
@@ -758,7 +758,8 @@ int gma_func0_init(pci_dev_t dev, struct pci_controller 
*hose,
 
 #ifdef CONFIG_VIDEO
start = get_timer(0);
-   ret = pci_run_vga_bios(dev, int15_handler, false);
+   ret = pci_run_vga_bios(dev, int15_handler, PCI_ROM_USE_NATIVE |
+  PCI_ROM_ALLOW_FALLBACK);
debug("BIOS ran in %lums\n", get_timer(start));
 #endif
/* Post VBIOS init */
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index eb76591..0796179 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -228,11 +228,12 @@ int vbe_get_video_info(struct graphic_device *gdev)
 #endif
 }
 
-int pci_run_vga_bios(pci_dev_t dev, int (*int15_handler)(void), bool emulate)
+int pci_run_vga_bios(pci_dev_t dev, int (*int15_handler)(void), int 
exec_method)
 {
struct pci_rom_header *rom, *ram;
int vesa_mode = -1;
uint16_t class;
+   bool emulate;
int ret;
 
/* Only execute VGA ROMs */
@@ -262,6 +263,29 @@ int pci_run_vga_bios(pci_dev_t dev, int 
(*int15_handler)(void), bool emulate)
vesa_mode = CONFIG_FRAMEBUFFER_VESA_MODE;
 #endif
debug("Selected vesa mode %#x\n", vesa_mode);
+
+   if (exec_method & PCI_ROM_USE_NATIVE) {
+#ifdef CONFIG_X86
+   emulate = false;
+#else
+   if (!(exec_method & PCI_ROM_ALLOW_FALLBACK)) {
+   printf("BIOS native execution is only available on 
x86\n");
+   return -ENOSYS;
+   }
+   emulate = true;
+#endif
+   } else {
+#ifdef CONFIG_BIOSEMU
+   emulate = true;
+#else
+   if (!(exec_method & PCI_ROM_ALLOW_FALLBACK)) {
+   printf("BIOS emulation not available - see 
CONFIG_BIOSEMU\n");
+   return -ENOSYS;
+   }
+   emulate = false;
+#endif
+   }
+
if (emulate) {
 #ifdef CONFIG_BIOSEMU
BE_VGAInfo *info;
@@ -274,9 +298,6 @@ int pci_run_vga_bios(pci_dev_t dev, int 
(*int15_handler)(void), bool emulate)
  vesa_mode, &mode_info);
if (ret)
return ret;
-#else
-   printf("BIOS emulation not available - see CONFIG_BIOSEMU\n");
-   return -ENOSYS;
 #endif
} else {
 #ifdef CONFIG_X86
@@ -284,9 +305,6 @@ int pci_run_vga_bios(pci_dev_t dev, int 
(*int15_handler)(void), bool emulate)
 
bios_run_on_x86(dev, (unsigned long)ram, vesa_mode,
&mode_info);
-#else
-   printf("BIOS native execution is only available on x86\n");
-   return -ENOSYS;
 #endif
}
debug("Final vesa mode %#x\n", mode_info.video_mode);
diff --git a/drivers/video/vesa_fb.c b/drivers/video/vesa_fb.c
index 3a0fea2..9164f8d 100644
--- a/drivers/video/vesa_fb.c
+++ b/drivers/video/vesa_fb.c
@@ -42,8 +42,8 @@ void *video_hw_init(void)
printf("no card detected\n");
return NULL;
}
-   printf("bdf %x\n", dev);
-   ret = pci_run_vga_bios(dev, NULL, true);
+   ret = pci_run_vga_bios(dev, NULL, PCI_ROM_USE_NATIVE |
+  PCI_ROM_ALLOW_FALLBACK);
if (ret) {
printf("failed to run video BIOS: %d\n", ret);
return NULL;
@@ -59,7 +59,7 @@ void *video_hw_init(void)
sprintf(gdev->modeIdent, "%dx%dx%d", gdev->winSizeX, gdev->winSizeY,
bits_per_pixel);
printf("%s\n", gdev->modeIdent);
-   debug("Framex buffer at %x\n", gdev->pciBase);
+   debug("Frame buffer at %x\n", gdev->pciBase);
 
return (void *)gdev;
 }
diff --git a/include/pci_rom.h b/include/pci_rom.h
index 4ba36eb..d24c52a 100644
--- a/include/pci_rom.h
+++ b/include/pci_rom.h
@@ -33,14 +33,25 @@ struct pci_rom_data {
uint16_t reserved_2;
 };
 
+/*
+ * Determines which execution method is used and whether we allow falling back
+ * to the other if the requested method is not available.
+ */
+enum pci_rom_emul_t {
+   PCI_ROM_EMULATE = 0 << 0,
+   PCI_ROM_USE_NATIVE  = 1 << 0,
+   PCI_ROM_ALLOW_FALLBACK  = 1 << 1,
+};
+
  /**
  * pci_run_vga_bios() - Run the VGA BIOS in an x86 PC
  *
  * @dev:   Video device containing the BIOS
  * 

[U-Boot] [PATCH 18/23] x86: Allow a UART to be set up before the FSP is ready

2015-01-26 Thread Simon Glass
Since the FSP is a black box it helps to have some sort of debugging
available to check its inputs. If the debug UART is in use, set it up
after CAR is available.

Signed-off-by: Simon Glass 
---

 arch/x86/include/asm/u-boot-x86.h | 3 +++
 arch/x86/lib/fsp/fsp_support.c| 4 
 2 files changed, 7 insertions(+)

diff --git a/arch/x86/include/asm/u-boot-x86.h 
b/arch/x86/include/asm/u-boot-x86.h
index 44c24ff..85fafc0 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -62,6 +62,9 @@ int fsp_cpu_mmc_init(const char *name, struct pci_device_id 
mmc_supported[],
 /* Set up a UART which can be used with printch(), printhex8(), etc. */
 int setup_early_uart(void);
 
+/* Set up a UART which can be used with printch(), printhex8(), etc. */
+int setup_early_uart(void);
+
 void setup_pcat_compatibility(void);
 
 void isa_unmap_rom(u32 addr);
diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
index 8b639f7..5f96da1 100644
--- a/arch/x86/lib/fsp/fsp_support.c
+++ b/arch/x86/lib/fsp/fsp_support.c
@@ -124,6 +124,10 @@ void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf)
struct fsp_init_params *params_ptr;
struct upd_region *fsp_upd;
 
+#ifdef CONFIG_DEBUG_UART
+   setup_early_uart();
+#endif
+
fsp_hdr = find_fsp_header();
if (fsp_hdr == NULL) {
/* No valid FSP info header was found */
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 22/23] x86: Add some documentation on how to port U-Boot on x86

2015-01-26 Thread Simon Glass
Some information has been gleaned on tools and procedures for porting
U-Boot to different x86 platforms. Add a few notes to start things off.

Signed-off-by: Simon Glass 
---

 doc/README.x86 | 63 ++
 1 file changed, 63 insertions(+)

diff --git a/doc/README.x86 b/doc/README.x86
index 809a291..0e4628a 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -164,6 +164,69 @@ mtrr - List and set the Memory Type Range Registers 
(MTRR). These are used to
 mode to use. U-Boot sets up some reasonable values but you can
 adjust then with this command.
 
+Development Flow
+
+
+These notes are for those who want to port U-Boot to a new x86 platform.
+
+Since x86 CPUs boot from SPI flash, a SPI flash emulator is a good investment.
+The Dediprog em100 can be used on Linux. The em100 tool is available here:
+
+   http://review.coreboot.org/p/em100.git
+
+On Minnowboard Max the following command line can be used:
+
+   sudo em100 -s -p LOW -d u-boot.rom -c W25Q64DW -r
+
+A suitable clip for connecting over the SPI flash chip is here:
+
+   http://www.dediprog.com/pd/programmer-accessories/EM-TC-8
+
+This allows you to override the SPI flash contents for development purposes.
+Typically you can write to the em100 in around 1200ms, considerably faster
+than programming the real flash device each time. The only important
+limitation of the em100 is that it only supports SPI bus speeds up to 20MHz.
+This means that images must be set to boot with that speed (Intel-specific
+feature).
+
+If your chip/board uses an Intel Firmware Support Package (FSP) it is fairly
+easy to fit it in. You can follow the Minnowboard Max implementation, for
+example. Hopefully you will just need to create new files similar to those
+in arch/x86/cpu/baytrail which provide Bay Trail support.
+
+If you are not using an FSP you have more freedom and more responsibility.
+The ivybridge support works this way, although it still uses a ROM for
+graphics and still has binary blobs containing Intel code. You should aim to
+support all important peripherals on your platform including video and storage.
+Use the device tree for configuration where possible.
+
+For the microcode you can create a suitable device tree file using the
+microcode tool:
+
+  ./tools/microcode-tool -d microcode.dat create 
+
+or if you only have header files and not the full Intel microcode.dat database:
+
+  ./tools/microcode-tool -H BAY_TRAIL_FSP_KIT/Microcode/M0130673322.h \
+   -H BAY_TRAIL_FSP_KIT/Microcode/M0130679901.h \
+   create all
+
+These are written to arch/x86/dts/microcode/ by default.
+
+Note that it is possible to just add the micrcode for your CPU if you know its
+model. U-Boot prints this information when it starts
+
+   CPU: x86_64, vendor Intel, device 30673h
+
+so here we can use the M0130673322 file.
+
+If you platform can display POST codes on two little 7-segment displays on
+the board, then you can use post_code() calls from C or assembler to monitor
+boot progress. This can be good for debugging.
+
+If not, you can try to get serial working as early as possible. The early
+debug serial port may be useful here. See setup_early_uart() for an example.
+
 TODO List
 -
 - Audio
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH v2 3/3] serial: ns16550: Support debug UART

2015-01-26 Thread Simon Glass
Add debug UART functions to permit ns16550 to provide an early debug UART.
Try to avoid using the stack so that this can be called from assembler before
a stack is set up (at least on ARM and PowerPC).

Signed-off-by: Simon Glass 
---

Changes in v2:
- Split series out on its own
- Add x86 support (asmlinkage, so it still needs a stack at present)
- Add better cover letter

 drivers/serial/Kconfig   | 13 +
 drivers/serial/ns16550.c | 50 ++--
 2 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 268bb42..9d0d4c3 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -31,6 +31,19 @@ config DEBUG_UART
  serial drivers are up and running (done in serial_init()). Otherwise
  the drivers may conflict and you will get strange output.
 
+choice
+   prompt "Select which UART will provide the debug UART"
+   depends on DEBUG_UART
+
+config DEBUG_UART_NS16550
+   bool "ns16550"
+   help
+ Select this to enable a debug UART using the ns16550 driver. You
+ will need to provide parameters to make this work. The driver will
+ be available until the real driver model serial is running.
+
+endchoice
+
 config DEBUG_UART_BASE
hex "Base address of UART"
depends on DEBUG_UART
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 57e6125..eb00f1c 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -118,10 +118,15 @@ static int ns16550_readb(NS16550_t port, int offset)
ns16550_readb(com_port, addr - (unsigned char *)com_port)
 #endif
 
-int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
+static inline int calc_divisor(NS16550_t port, int clock, int baudrate)
 {
const unsigned int mode_x_div = 16;
 
+   return DIV_ROUND_CLOSEST(clock, mode_x_div * baudrate);
+}
+
+int ns16550_calc_divisor(NS16550_t port, int clock, int baudrate)
+{
 #ifdef CONFIG_OMAP1510
/* If can't cleanly clock 115200 set div to 1 */
if ((clock == 1200) && (baudrate == 115200)) {
@@ -131,7 +136,7 @@ int ns16550_calc_divisor(NS16550_t port, int clock, int 
baudrate)
port->osc_12m_sel = 0;  /* clear if previsouly set */
 #endif
 
-   return DIV_ROUND_CLOSEST(clock, mode_x_div * baudrate);
+   return calc_divisor(port, clock, baudrate);
 }
 
 static void NS16550_setbrg(NS16550_t com_port, int baud_divisor)
@@ -231,6 +236,47 @@ int NS16550_tstc(NS16550_t com_port)
 
 #endif /* CONFIG_NS16550_MIN_FUNCTIONS */
 
+#ifdef CONFIG_DEBUG_UART_NS16550
+
+#include 
+
+void debug_uart_init(void)
+{
+   struct NS16550 *com_port = (struct NS16550 *)CONFIG_DEBUG_UART_BASE;
+   int baud_divisor;
+
+   /*
+* We copy the code from above because it is already horribly messy.
+* Trying to refactor to nicely remove the duplication doesn't seem
+* feasible. The better fix is to move all users of this driver to
+* driver model.
+*/
+   baud_divisor = calc_divisor(com_port, CONFIG_DEBUG_UART_CLOCK,
+   CONFIG_BAUDRATE);
+
+   serial_out_shift(&com_port->ier, 0, CONFIG_SYS_NS16550_IER);
+   serial_out_shift(&com_port->mcr, 0, UART_MCRVAL);
+   serial_out_shift(&com_port->fcr, 0, UART_FCRVAL);
+
+   serial_out_shift(&com_port->lcr, 0, UART_LCR_BKSE | UART_LCRVAL);
+   serial_out_shift(&com_port->dll, 0, baud_divisor & 0xff);
+   serial_out_shift(&com_port->dlm, 0, (baud_divisor >> 8) & 0xff);
+   serial_out_shift(&com_port->lcr, 0, UART_LCRVAL);
+}
+
+static inline void _debug_uart_putc(int ch)
+{
+   struct NS16550 *com_port = (struct NS16550 *)CONFIG_DEBUG_UART_BASE;
+
+   while (!(serial_in_shift(&com_port->lsr, 0) & UART_LSR_THRE))
+   ;
+   serial_out_shift(&com_port->thr, 0, ch);
+}
+
+DEBUG_UART_FUNCS
+
+#endif
+
 #ifdef CONFIG_DM_SERIAL
 static int ns16550_serial_putc(struct udevice *dev, const char ch)
 {
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH v2 1/3] serial: Support an early UART for debugging

2015-01-26 Thread Simon Glass
This came up in a discussion on the mailing list here:

https://patchwork.ozlabs.org/patch/384613/

My concerns at the time were:
- it doesn't need to be written in assembler
- it doesn't need to be ARM-specific

This patch provides a possible alternative. It works by allowing any serial
driver to export one init function and provide a putc() function. These
can be used to output debug data before the real serial driver is available.

This implementation does not depend on driver model, and it is possible for
it to operate without a stack on some architectures (e.g. PowerPC, ARM). It
provides the same features as the ARM-specific debug.S but with more UART
and architecture support.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Add asmlinkage to exported functions

 drivers/serial/Kconfig |  46 
 include/debug_uart.h   | 139 +
 2 files changed, 185 insertions(+)
 create mode 100644 include/debug_uart.h

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index a0b6e02..268bb42 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -5,6 +5,52 @@ config DM_SERIAL
  If you want to use driver model for serial drivers, say Y.
  To use legacy serial drivers, say N.
 
+config DEBUG_UART
+   bool "Enable an early debug UART for debugging"
+   help
+ The debug UART is intended for use very early in U-Boot to debug
+ problems when an ICE or other debug mechanism is not available.
+
+ To use it you should:
+ - Make sure your UART supports this interface
+ - Enable CONFIG_DEBUG_UART
+ - Enable the CONFIG for your UART to tell it to provide this interface
+   (e.g. CONFIG_DEBUG_UART_NS16550)
+ - Define the required settings as needed (see below)
+ - Call debug_uart_init() before use
+ - Call debug_uart_putc() to output a character
+
+ Depending on your platform it may be possible to use this UART before
+ a stack is available.
+
+ If your UART does not support this interface you can probably add
+ support quite easily. Remember that you cannot use driver model and
+ it is preferred to use no stack.
+
+ You must not use this UART once driver model is working and the
+ serial drivers are up and running (done in serial_init()). Otherwise
+ the drivers may conflict and you will get strange output.
+
+config DEBUG_UART_BASE
+   hex "Base address of UART"
+   depends on DEBUG_UART
+   help
+ This is the base address of your UART for memory-mapped UARTs.
+
+ A default should be provided by your board, but if not you will need
+ to use the correct value here.
+
+config DEBUG_UART_CLOCK
+   int "UART input clock"
+   depends on DEBUG_UART
+   help
+ The UART input clock determines the speed of the internal UART
+ circuitry. The baud rate is derived from this by dividing the input
+ clock down.
+
+ A default should be provided by your board, but if not you will need
+ to use the correct value here.
+
 config UNIPHIER_SERIAL
bool "UniPhier on-chip UART support"
depends on ARCH_UNIPHIER && DM_SERIAL
diff --git a/include/debug_uart.h b/include/debug_uart.h
new file mode 100644
index 000..f56797b
--- /dev/null
+++ b/include/debug_uart.h
@@ -0,0 +1,139 @@
+/*
+ * Early debug UART support
+ *
+ * (C) Copyright 2014 Google, Inc
+ * Writte by Simon Glass 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _DEBUG_UART_H
+#define _DEBUG_UART_H
+
+#include 
+
+/*
+ * The debug UART is intended for use very early in U-Boot to debug problems
+ * when an ICE or other debug mechanism is not available.
+ *
+ * To use it you should:
+ * - Make sure your UART supports this interface
+ * - Enable CONFIG_DEBUG_UART
+ * - Enable the CONFIG for your UART to tell it to provide this interface
+ *   (e.g. CONFIG_DEBUG_UART_NS16550)
+ * - Define the required settings as needed (see below)
+ * - Call debug_uart_init() before use
+ * - Call printch() to output a character
+ *
+ * Depending on your platform it may be possible to use this UART before a
+ * stack is available.
+ *
+ * If your UART does not support this interface you can probably add support
+ * quite easily. Remember that you cannot use driver model and it is preferred
+ * to use no stack.
+ *
+ * You must not use this UART once driver model is working and the serial
+ * drivers are up and running (done in serial_init()). Otherwise the drivers
+ * may conflict and you will get strange output.
+ *
+ *
+ * To enable the debug UART in your serial driver:
+ *
+ * - #include 
+ * - Define debug_uart_init(), trying to avoid using the stack
+ * - Define _debug_uart_putc() as static inline (avoiding stack usage)
+ * - Immediately afterwards, add DEBUG_UART_FUNCS to define the rest of the
+ * functionality (printch(), et

[U-Boot] [PATCH v2 0/3] Add generic early debug UART feature

2015-01-26 Thread Simon Glass
This series adds debug UART infrastructure which can in principle be used on
any architecture. It works best with those that don't need a stack to call
functions (e.g. ARM, PowerPC).

This came up in a discussion on the mailing list here:

https://patchwork.ozlabs.org/patch/384613/

My concerns at the time were:
- it doesn't need to be written in assembler
- it doesn't need to be ARM-specific
- it only supports one serial driver

This potentially creates a problem where to support n architectures and m
serial drivers we need n * m lots of assembler-coded functions. For example,
in Linux for ARM we have:

../plat-spear/include/plat/debug-macro.S
../mach-s5pc100/include/mach/debug-macro.S
../mach-shark/include/mach/debug-macro.S
../mach-spear3xx/include/mach/debug-macro.S
../mach-sa1100/include/mach/debug-macro.S
../mach-l7200/include/mach/debug-macro.S
../mach-mv78xx0/include/mach/debug-macro.S
../mach-realview/include/mach/debug-macro.S
../mach-mmp/include/mach/debug-macro.S
../mach-s3c64xx/include/mach/debug-macro.S
../mach-s5pv210/include/mach/debug-macro.S
../mach-clps711x/include/mach/debug-macro.S
../mach-versatile/include/mach/debug-macro.S
../mach-iop32x/include/mach/debug-macro.S
../mach-ebsa110/include/mach/debug-macro.S
../mach-ux500/include/mach/debug-macro.S
../mach-orion5x/include/mach/debug-macro.S
../mach-lpc32xx/include/mach/debug-macro.S
../mach-vt8500/include/mach/debug-macro.S
../mach-rpc/include/mach/debug-macro.S
../mach-kirkwood/include/mach/debug-macro.S
../mach-spear6xx/include/mach/debug-macro.S
../mach-footbridge/include/mach/debug-macro.S
../mach-davinci/include/mach/debug-macro.S
../plat-samsung/include/plat/debug-macro.S
../mach-spear13xx/include/mach/debug-macro.S
../mach-exynos/include/mach/debug-macro.S
../mach-exynos/include/mach/regs-debug.h
../mach-dove/include/mach/debug-macro.S
../mach-omap1/include/mach/debug-macro.S
../mach-u300/include/mach/debug-macro.S
../mach-bcm2835/include/mach/debug-macro.S
../mach-h720x/include/mach/debug-macro.S
../mach-ep93xx/include/mach/debug-macro.S
../mach-gemini/include/mach/debug-macro.S
../mach-s3c24xx/include/mach/debug-macro.S
../mach-at91/include/mach/debug-macro.S
../mach-ixp4xx/include/mach/debug-macro.S
../mach-nomadik/include/mach/debug-macro.S
../mach-cns3xxx/include/mach/debug-macro.S
../mach-mxs/include/mach/debug-macro.S
../mach-iop33x/include/mach/debug-macro.S
../mach-ks8695/include/mach/debug-macro.S
../mach-netx/include/mach/debug-macro.S
../mach-iop13xx/include/mach/debug-macro.S
../mach-integrator/include/mach/debug-macro.S
../mach-msm/include/mach/debug-macro.S
../mach-pxa/include/mach/debug-macro.S
../mach-s5p64x0/include/mach/debug-macro.S
../mach-prima2/include/mach/debug-macro.S
../mach-omap2/include/mach/debug-macro.S

This series provides a possible alternative. It works by allowing any serial
driver to export one init function and provide a putc() function. These
can be used to output debug data before the real serial driver is available.
Only one debug UART can be used at a time, and its address and serial clock
must be provided statically in Kconfig.

This implementation does not depend on driver model being set up, and it is
possible for it to operate without a stack on some architectures (e.g.
PowerPC, ARM). It provides the same features as the ARM-specific debug.S but
with more UART and architecture support.

As an example, here is the code generated for printch() by gcc 4.8 on ARM
using the ns16550 driver (Tegra Seaboard):

0013b3b0 :
  13b3b0:   e59f201cldr r2, [pc, #28]   ; 13b3d4 
  13b3b4:   e5d23305ldrbr3, [r2, #773]  ; 0x305
  13b3b8:   e6ef3073uxtbr3, r3
  13b3bc:   e3130020tst r3, #32
  13b3c0:   0afbbeq 13b3b4 
  13b3c4:   e6ef0070uxtbr0, r0
  13b3c8:   e59f3004ldr r3, [pc, #4]; 13b3d4 
  13b3cc:   e5c30300strbr0, [r3, #768]  ; 0x300
  13b3d0:   e12fff1ebx  lr
  13b3d4:   70006000.word   0x70006000

The PowerPC 4xx code (ELDK-5.3) for printhex8() is this:

0102db44 :
 102db44:   3c c0 ef 60 lis r6,-4256
 102db48:   3c e0 ef 60 lis r7,-4256
 102db4c:   39 20 00 1c li  r9,28
 102db50:   60 c6 03 05 ori r6,r6,773
 102db54:   60 e7 03 00 ori r7,r7,768
 102db58:   7c 6a 4c 30 srw r10,r3,r9
 102db5c:   55 4a 07 3e clrlwi  r10,r10,28
 102db60:   2b 8a 00 09 cmplwi  cr7,r10,9
 102db64:   39 0a 00 30 addir8,r10,48
 102db68:   40 9d 00 08 ble-cr7,102db70 
 102db6c:   39 0a 00 57 addir8,r10,87
 102db70:   7c 00 04 ac sync
 102db74:   89 46 00 00 lbz r10,0(r6)
 102db78:   0c 0a 00 00 twi 0,r10,0
 102db7c:   4c 00 01 2c isync
 102db80:   55 4a 06 b4 rlwinm  r10,r10,0,26,26
 102db84:   71 45 00 ff andi.   r5,r10,255
 102db88:   41 82 ff e8 beq+102db70 
 10

[U-Boot] [PATCH v2 2/3] serial: ns16550: Add access functions that don't need platdata

2015-01-26 Thread Simon Glass
For the debug UART we need to be able to provide any parameters before
driver model is set up. Add parameters to the low-level access functions
to make this possible.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 drivers/serial/ns16550.c | 48 ++--
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 70c9462..57e6125 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -55,17 +55,9 @@ DECLARE_GLOBAL_DATA_PTR;
 #endif /* CONFIG_SYS_NS16550_IER */
 
 #ifdef CONFIG_DM_SERIAL
-static void ns16550_writeb(NS16550_t port, int offset, int value)
-{
-   struct ns16550_platdata *plat = port->plat;
-   unsigned char *addr;
 
-   offset *= 1 << plat->reg_shift;
-   addr = map_sysmem(plat->base, 0) + offset;
-   /*
-* As far as we know it doesn't make sense to support selection of
-* these options at run-time, so use the existing CONFIG options.
-*/
+static inline void serial_out_shift(unsigned char *addr, int shift, int value)
+{
 #ifdef CONFIG_SYS_NS16550_PORT_MAPPED
outb(value, (ulong)addr);
 #elif defined(CONFIG_SYS_NS16550_MEM32) && !defined(CONFIG_SYS_BIG_ENDIAN)
@@ -73,19 +65,14 @@ static void ns16550_writeb(NS16550_t port, int offset, int 
value)
 #elif defined(CONFIG_SYS_NS16550_MEM32) && defined(CONFIG_SYS_BIG_ENDIAN)
out_be32(addr, value);
 #elif defined(CONFIG_SYS_BIG_ENDIAN)
-   writeb(value, addr + (1 << plat->reg_shift) - 1);
+   writeb(value, addr + (1 << shift) - 1);
 #else
writeb(value, addr);
 #endif
 }
 
-static int ns16550_readb(NS16550_t port, int offset)
+static inline int serial_in_shift(unsigned char *addr, int shift)
 {
-   struct ns16550_platdata *plat = port->plat;
-   unsigned char *addr;
-
-   offset *= 1 << plat->reg_shift;
-   addr = map_sysmem(plat->base, 0) + offset;
 #ifdef CONFIG_SYS_NS16550_PORT_MAPPED
return inb((ulong)addr);
 #elif defined(CONFIG_SYS_NS16550_MEM32) && !defined(CONFIG_SYS_BIG_ENDIAN)
@@ -93,12 +80,37 @@ static int ns16550_readb(NS16550_t port, int offset)
 #elif defined(CONFIG_SYS_NS16550_MEM32) && defined(CONFIG_SYS_BIG_ENDIAN)
return in_be32(addr);
 #elif defined(CONFIG_SYS_BIG_ENDIAN)
-   return readb(addr + (1 << plat->reg_shift) - 1);
+   return readb(addr + (1 << reg_shift) - 1);
 #else
return readb(addr);
 #endif
 }
 
+static void ns16550_writeb(NS16550_t port, int offset, int value)
+{
+   struct ns16550_platdata *plat = port->plat;
+   unsigned char *addr;
+
+   offset *= 1 << plat->reg_shift;
+   addr = map_sysmem(plat->base, 0) + offset;
+   /*
+* As far as we know it doesn't make sense to support selection of
+* these options at run-time, so use the existing CONFIG options.
+*/
+   serial_out_shift(addr, plat->reg_shift, value);
+}
+
+static int ns16550_readb(NS16550_t port, int offset)
+{
+   struct ns16550_platdata *plat = port->plat;
+   unsigned char *addr;
+
+   offset *= 1 << plat->reg_shift;
+   addr = map_sysmem(plat->base, 0) + offset;
+
+   return serial_in_shift(addr, plat->reg_shift);
+}
+
 /* We can clean these up once everything is moved to driver model */
 #define serial_out(value, addr)\
ns16550_writeb(com_port, addr - (unsigned char *)com_port, value)
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 11/23] x86: Move common FSP code into a common location

2015-01-26 Thread Simon Glass
Signed-off-by: Simon Glass 
---

 arch/x86/cpu/queensbay/Makefile| 2 +-
 arch/x86/cpu/queensbay/fsp_configs.c   | 2 +-
 arch/x86/cpu/queensbay/tnc.c   | 2 +-
 arch/x86/cpu/queensbay/tnc_dram.c  | 2 +-
 arch/x86/cpu/queensbay/tnc_pci.c   | 2 +-
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_api.h| 0
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_bootmode.h   | 0
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_ffs.h| 0
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_fv.h | 0
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_hob.h| 0
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_infoheader.h | 0
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_platform.h   | 0
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_support.h| 2 +-
 arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_types.h  | 0
 arch/x86/lib/Makefile  | 1 +
 arch/x86/lib/cmd_hob.c | 2 +-
 arch/x86/lib/fsp/Makefile  | 7 +++
 arch/x86/{cpu/queensbay => lib/fsp}/fsp_support.c  | 2 +-
 18 files changed, 16 insertions(+), 8 deletions(-)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_api.h (100%)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_bootmode.h (100%)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_ffs.h (100%)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_fv.h (100%)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_hob.h (100%)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_infoheader.h (100%)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_platform.h (100%)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_support.h (99%)
 rename arch/x86/include/asm/{arch-queensbay => }/fsp/fsp_types.h (100%)
 create mode 100644 arch/x86/lib/fsp/Makefile
 rename arch/x86/{cpu/queensbay => lib/fsp}/fsp_support.c (99%)

diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
index 2c2ec01..b3e7d87 100644
--- a/arch/x86/cpu/queensbay/Makefile
+++ b/arch/x86/cpu/queensbay/Makefile
@@ -5,5 +5,5 @@
 #
 
 obj-y += tnc_car.o tnc_dram.o tnc.o topcliff.o
-obj-y += fsp_configs.o fsp_support.o
+obj-y += fsp_configs.o
 obj-$(CONFIG_PCI) += tnc_pci.o
diff --git a/arch/x86/cpu/queensbay/fsp_configs.c 
b/arch/x86/cpu/queensbay/fsp_configs.c
index af28e45..78bc966 100644
--- a/arch/x86/cpu/queensbay/fsp_configs.c
+++ b/arch/x86/cpu/queensbay/fsp_configs.c
@@ -6,7 +6,7 @@
  */
 
 #include 
-#include 
+#include 
 
 void update_fsp_upd(struct upd_region *fsp_upd)
 {
diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
index 8637cdc..f9b3bfa 100644
--- a/arch/x86/cpu/queensbay/tnc.c
+++ b/arch/x86/cpu/queensbay/tnc.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 static void unprotect_spi_flash(void)
diff --git a/arch/x86/cpu/queensbay/tnc_dram.c 
b/arch/x86/cpu/queensbay/tnc_dram.c
index df79a39..4c0a7c8 100644
--- a/arch/x86/cpu/queensbay/tnc_dram.c
+++ b/arch/x86/cpu/queensbay/tnc_dram.c
@@ -5,7 +5,7 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/arch/x86/cpu/queensbay/tnc_pci.c b/arch/x86/cpu/queensbay/tnc_pci.c
index 39bff49..9b0b725 100644
--- a/arch/x86/cpu/queensbay/tnc_pci.c
+++ b/arch/x86/cpu/queensbay/tnc_pci.c
@@ -7,7 +7,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
diff --git a/arch/x86/include/asm/arch-queensbay/fsp/fsp_api.h 
b/arch/x86/include/asm/fsp/fsp_api.h
similarity index 100%
rename from arch/x86/include/asm/arch-queensbay/fsp/fsp_api.h
rename to arch/x86/include/asm/fsp/fsp_api.h
diff --git a/arch/x86/include/asm/arch-queensbay/fsp/fsp_bootmode.h 
b/arch/x86/include/asm/fsp/fsp_bootmode.h
similarity index 100%
rename from arch/x86/include/asm/arch-queensbay/fsp/fsp_bootmode.h
rename to arch/x86/include/asm/fsp/fsp_bootmode.h
diff --git a/arch/x86/include/asm/arch-queensbay/fsp/fsp_ffs.h 
b/arch/x86/include/asm/fsp/fsp_ffs.h
similarity index 100%
rename from arch/x86/include/asm/arch-queensbay/fsp/fsp_ffs.h
rename to arch/x86/include/asm/fsp/fsp_ffs.h
diff --git a/arch/x86/include/asm/arch-queensbay/fsp/fsp_fv.h 
b/arch/x86/include/asm/fsp/fsp_fv.h
similarity index 100%
rename from arch/x86/include/asm/arch-queensbay/fsp/fsp_fv.h
rename to arch/x86/include/asm/fsp/fsp_fv.h
diff --git a/arch/x86/include/asm/arch-queensbay/fsp/fsp_hob.h 
b/arch/x86/include/asm/fsp/fsp_hob.h
similarity index 100%
rename from arch/x86/include/asm/arch-queensbay/fsp/fsp_hob.h
rename to arch/x86/include/asm/fsp/fsp_hob.h
diff --git a/arch/x86/include/asm/arch-queensbay/fsp/fsp_infoheader.h 
b/arch/x86/include/asm/fsp/fsp_infoheader.h
similarity index 100%
rename from arch/x86/include/asm/arch-queensbay/fsp/fsp_in

[U-Boot] [PATCH 13/23] x86: Make CAR and DRAM FSP code common

2015-01-26 Thread Simon Glass
For now this code seems to be the same for all FSP platforms. Make it
common until we see what differences are required.

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/queensbay/Makefile   | 2 +-
 arch/x86/lib/fsp/Makefile | 2 ++
 arch/x86/{cpu/queensbay/tnc_car.S => lib/fsp/fsp_car.S}   | 0
 arch/x86/{cpu/queensbay/tnc_dram.c => lib/fsp/fsp_dram.c} | 0
 4 files changed, 3 insertions(+), 1 deletion(-)
 rename arch/x86/{cpu/queensbay/tnc_car.S => lib/fsp/fsp_car.S} (100%)
 rename arch/x86/{cpu/queensbay/tnc_dram.c => lib/fsp/fsp_dram.c} (100%)

diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
index b3e7d87..d8761fd 100644
--- a/arch/x86/cpu/queensbay/Makefile
+++ b/arch/x86/cpu/queensbay/Makefile
@@ -4,6 +4,6 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y += tnc_car.o tnc_dram.o tnc.o topcliff.o
 obj-y += fsp_configs.o
+obj-y += tnc.o topcliff.o
 obj-$(CONFIG_PCI) += tnc_pci.o
diff --git a/arch/x86/lib/fsp/Makefile b/arch/x86/lib/fsp/Makefile
index 1b9b0e2..3a2bac0 100644
--- a/arch/x86/lib/fsp/Makefile
+++ b/arch/x86/lib/fsp/Makefile
@@ -4,4 +4,6 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+obj-y += fsp_car.o
+obj-y += fsp_dram.o
 obj-y += fsp_support.o
diff --git a/arch/x86/cpu/queensbay/tnc_car.S b/arch/x86/lib/fsp/fsp_car.S
similarity index 100%
rename from arch/x86/cpu/queensbay/tnc_car.S
rename to arch/x86/lib/fsp/fsp_car.S
diff --git a/arch/x86/cpu/queensbay/tnc_dram.c b/arch/x86/lib/fsp/fsp_dram.c
similarity index 100%
rename from arch/x86/cpu/queensbay/tnc_dram.c
rename to arch/x86/lib/fsp/fsp_dram.c
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH 10/23] x86: bootstage: Add time measurement for vesa start-up

2015-01-26 Thread Simon Glass
Since we must run a PCI BIOS ROM, and this can take a calamitous amount of
time, measure it using bootstage.

Signed-off-by: Simon Glass 
---

 drivers/video/vesa_fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/vesa_fb.c b/drivers/video/vesa_fb.c
index 9164f8d..47f824a 100644
--- a/drivers/video/vesa_fb.c
+++ b/drivers/video/vesa_fb.c
@@ -42,8 +42,10 @@ void *video_hw_init(void)
printf("no card detected\n");
return NULL;
}
+   bootstage_start(BOOTSTAGE_ID_ACCUM_LCD, "vesa display");
ret = pci_run_vga_bios(dev, NULL, PCI_ROM_USE_NATIVE |
   PCI_ROM_ALLOW_FALLBACK);
+   bootstage_accum(BOOTSTAGE_ID_ACCUM_LCD);
if (ret) {
printf("failed to run video BIOS: %d\n", ret);
return NULL;
-- 
2.2.0.rc0.207.ga3a616c

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


Re: [U-Boot] [PATCH 1/5] nand: Use common read function instead of verify_buf()

2015-01-26 Thread Scott Wood
On Mon, 2015-01-26 at 17:17 -0600, Peter Tyser wrote:
> On Mon, 2015-01-26 at 16:33 -0600, Scott Wood wrote:
> > On Mon, 2015-01-26 at 16:24 -0600, Peter Tyser wrote:
> > > The driver-specific verify_buf() function can be replaced with the
> > > standard read_page_raw() function to verify writes.  This will 
> > > allow
> > > verify_buf() to be removed from individual drivers.  verify_buf() 
> > > is no
> > > longer supported in mainline Linux, so it is a pain to continue
> > > supporting.
> > 
> > Any reason not to just remove this feature from U-Boot, as Linux has
> > done?
> 
> The Linux change for reference: 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=657f28f8811c92724db10d18bbbec70d540147d6
> 
> I waffled about removing it, but leaned towards leaving it in because:
> - I didn't want to change the existing U-Boot behavior for other 
> users.  A google of 'u-boot "nand write"' shows a lot of examples that 
> don't include verification of writes, and they should if we remove 
> auto-verification.

How many configs actually enable this option?  I don't see many beyond
the FSL PPC boards (which are so full of copy-and-paste that it probably
wasn't deliberate).

> - The reason it was removed in Linux was "Both UBI and JFFS2 are able 
> to read verify what they wrote already.  There are also MTD tests 
> which do this verification."  I thought U-Boot was more likely than 
> Linux to use raw NAND writes without a filesystem, so leaving it in U-
> Boot made sense since the UBI/JFFS2 logic didn't apply as much here.

Right, though raw writes ought to be limited to blocks that aren't
written often enough to fail.

> - I didn't think a lot of people would know they have to explicitly 
> verify NAND contents after a write, since they'd assume it was like 
> other memories that aren't as lossy.
> 
> - The penalty of slightly different code from Linux and a small 
> performance hit was worth the gain of auto-verification to me.  I 
> viewed consolidating it into one small chunk of code as a happy medium.

The davinci patches show that there can still be driver dependencies
depending on what the driver overrides.  I'm not hugely opposed, but it
seems like it would be better to do it at a higher level (e.g. in
nand_util.c with a flag to enable, and either make support mandatory, or
if you try to use that command variant without support it fails rather
than silently not verifying).

-Scott


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


[U-Boot] [PATCH v5 0/3] pmic:pfuze support buck regulator mode switch

2015-01-26 Thread Peng Fan
This patch set is to support buck regulator can
working in different switching modes. To improve
system efficiency the buck regulators can operate
in different switching modes.

patch 1/3 is to add related bit definitions and registers.
patch 2/3 is to implement the switching mode init function.
patch 3/3 is to add related mode init function in board code.

mx6slevk board is not included in this patch set, since power
and i2c interface are not implemented for it. These patches
are at:
https://patchwork.ozlabs.org/patch/426961/
https://patchwork.ozlabs.org/patch/426962/
https://patchwork.ozlabs.org/patch/426963/

Added "Acked-by: Przemyslaw Marczak " in this patch
set. Added "Reviewed-by: Stefano Babic " for patch 1/3.
There is no major changes for this patch version. Only defined a macro
SWITCH_SIZE to replace the constant in patch 2/3.

Peng Fan (3):
  pmic:pfuz100 add switch mode and more registers
  pmic:pfuze implement pmic_mode_init
  imx:mx6 set normal APS and standby PFM mode

 board/freescale/common/pfuze.c| 37 ++
 board/freescale/common/pfuze.h|  1 +
 board/freescale/mx6qsabreauto/mx6qsabreauto.c |  6 +++
 board/freescale/mx6sabresd/mx6sabresd.c   |  6 ++-
 board/freescale/mx6sxsabresd/mx6sxsabresd.c   |  6 ++-
 include/power/pfuze100_pmic.h | 55 +++
 6 files changed, 109 insertions(+), 2 deletions(-)

-- 
1.8.4


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


[U-Boot] [PATCH v5 1/3] pmic:pfuz100 add switch mode and more registers

2015-01-26 Thread Peng Fan
Add more pfuze register offset.
And switch mode definition.
Add a macro SWITCH_SIZE

Signed-off-by: Peng Fan 
Acked-by: Przemyslaw Marczak 
Reviewed-by: Stefano Babic 
---

Changes v5:
 add "Acked-by: Przemyslaw Marczak " and
 "Reviewed-by: Stefano Babic "
 define a SWITCH_SIZE macro to replace constant in patch 2/3

Changes v4:
 none

Changes v3:
 none

Changes v2:
 none

 include/power/pfuze100_pmic.h | 55 +++
 1 file changed, 55 insertions(+)

diff --git a/include/power/pfuze100_pmic.h b/include/power/pfuze100_pmic.h
index 1118489..41aa3c4 100644
--- a/include/power/pfuze100_pmic.h
+++ b/include/power/pfuze100_pmic.h
@@ -16,14 +16,34 @@ enum {
 
PFUZE100_SW1ABVOL   = 0x20,
PFUZE100_SW1ABSTBY  = 0x21,
+   PFUZE100_SW1ABOFF   = 0x22,
+   PFUZE100_SW1ABMODE  = 0x23,
PUZE_100_SW1ABCONF  = 0x24,
PFUZE100_SW1CVOL= 0x2e,
PFUZE100_SW1CSTBY   = 0x2f,
+   PFUZE100_SW1COFF= 0x30,
+   PFUZE100_SW1CMODE   = 0x31,
PFUZE100_SW1CCONF   = 0x32,
PFUZE100_SW2VOL = 0x35,
+   PFUZE100_SW2STBY= 0x36,
+   PFUZE100_SW2OFF = 0x37,
+   PFUZE100_SW2MODE= 0x38,
+   PFUZE100_SW2CONF= 0x39,
PFUZE100_SW3AVOL= 0x3c,
+   PFUZE100_SW3ASTBY   = 0x3D,
+   PFUZE100_SW3AOFF= 0x3E,
+   PFUZE100_SW3AMODE   = 0x3F,
+   PFUZE100_SW3ACONF   = 0x40,
PFUZE100_SW3BVOL= 0x43,
+   PFUZE100_SW3BSTBY   = 0x44,
+   PFUZE100_SW3BOFF= 0x45,
+   PFUZE100_SW3BMODE   = 0x46,
+   PFUZE100_SW3BCONF   = 0x47,
PFUZE100_SW4VOL = 0x4a,
+   PFUZE100_SW4STBY= 0x4b,
+   PFUZE100_SW4OFF = 0x4c,
+   PFUZE100_SW4MODE= 0x4d,
+   PFUZE100_SW4CONF= 0x4e,
PFUZE100_SWBSTCON1  = 0x66,
PFUZE100_VREFDDRCON = 0x6a,
PFUZE100_VSNVSVOL   = 0x6b,
@@ -177,5 +197,40 @@ enum {
 #define SWBST_MODE_AUTO(2 << 2)
 #define SWBST_MODE_APS (2 << 3)
 
+/*
+ * Regulator Mode Control
+ *
+ * OFF: The regulator is switched off and the output voltage is discharged.
+ * PFM: In this mode, the regulator is always in PFM mode, which is useful
+ *  at light loads for optimized efficiency.
+ * PWM: In this mode, the regulator is always in PWM mode operation
+ * regardless of load conditions.
+ * APS: In this mode, the regulator moves automatically between pulse
+ * skipping mode and PWM mode depending on load conditions.
+ *
+ * SWxMODE[3:0]
+ * Normal Mode  |  Standby Mode|  value
+ *   OFF   OFF 0x0
+ *   PWM   OFF 0x1
+ *   PFM   OFF 0x3
+ *   APS   OFF 0x4
+ *   PWM   PWM 0x5
+ *   PWM   APS 0x6
+ *   APS   APS 0x8
+ *   APS   PFM 0xc
+ *   PWM   PFM 0xd
+ */
+#define OFF_OFF0x0
+#define PWM_OFF0x1
+#define PFM_OFF0x3
+#define APS_OFF0x4
+#define PWM_PWM0x5
+#define PWM_APS0x6
+#define APS_APS0x8
+#define APS_PFM0xc
+#define PWM_PFM0xd
+
+#define SWITCH_SIZE0x7
+
 int power_pfuze100_init(unsigned char bus);
 #endif
-- 
1.8.4


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


[U-Boot] [PATCH v5 3/3] imx:mx6 set normal APS and standby PFM mode

2015-01-26 Thread Peng Fan
To normal mode, use APS switching mode.
To standy mode, use PFM switching mode.

Signed-off-by: Peng Fan 
Acked-by: Przemyslaw Marczak 
---

Changes v5:
 Add Acked-by: Przemyslaw Marczak 

Changes v4:
 none

Changes v3:
 Following Fabio's comments, correct return value

Changes v2:
 none

 board/freescale/mx6qsabreauto/mx6qsabreauto.c | 6 ++
 board/freescale/mx6sabresd/mx6sabresd.c   | 6 +-
 board/freescale/mx6sxsabresd/mx6sxsabresd.c   | 6 +-
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/board/freescale/mx6qsabreauto/mx6qsabreauto.c 
b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
index 59387ff..b12e74e 100644
--- a/board/freescale/mx6qsabreauto/mx6qsabreauto.c
+++ b/board/freescale/mx6qsabreauto/mx6qsabreauto.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "../common/pfuze.h"
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -515,11 +516,16 @@ int board_spi_cs_gpio(unsigned bus, unsigned cs)
 int power_init_board(void)
 {
struct pmic *p;
+   unsigned int ret;
 
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
 
+   ret = pfuze_mode_init(p, APS_PFM);
+   if (ret < 0)
+   return ret;
+
return 0;
 }
 
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c 
b/board/freescale/mx6sabresd/mx6sabresd.c
index 2f7198d..bb2dd96 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -631,12 +631,16 @@ int board_init(void)
 int power_init_board(void)
 {
struct pmic *p;
-   unsigned int reg;
+   unsigned int reg, ret;
 
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
 
+   ret = pfuze_mode_init(p, APS_PFM);
+   if (ret < 0)
+   return ret;
+
/* Increase VGEN3 from 2.5 to 2.8V */
pmic_reg_read(p, PFUZE100_VGEN3VOL, ®);
reg &= ~LDO_VOL_MASK;
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c 
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index a2c9aae..2ff960e 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -199,12 +199,16 @@ static struct i2c_pads_info i2c_pad_info1 = {
 int power_init_board(void)
 {
struct pmic *p;
-   unsigned int reg;
+   unsigned int reg, ret;
 
p = pfuze_common_init(I2C_PMIC);
if (!p)
return -ENODEV;
 
+   ret = pfuze_mode_init(p, APS_PFM);
+   if (ret < 0)
+   return ret;
+
/* Enable power of VGEN5 3V3, needed for SD3 */
pmic_reg_read(p, PFUZE100_VGEN5VOL, ®);
reg &= ~LDO_VOL_MASK;
-- 
1.8.4


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


[U-Boot] [PATCH v5 2/3] pmic:pfuze implement pmic_mode_init

2015-01-26 Thread Peng Fan
This patch is to implement pmic_mode_init function, and add prototype
in header file.

This function is to set switching mode for pmic buck regulators to
improve system efficiency.

Mode:
OFF: The regulator is switched off and the output voltage is discharged.
PFM: In this mode, the regulator is always in PFM mode, which
 is useful at light loads for optimized efficiency.
PWM: In this mode, the regulator is always in PWM mode operation
 regardless of load conditions.
APS: In this mode, the regulator moves automatically between
 pulse skipping mode and PWM mode depending on load conditions.

Signed-off-by: Peng Fan 
Acked-by: Przemyslaw Marczak 
---

Changes v5:
 Add Acked-by: Przemyslaw Marczak 
 replace the constant 7 using macro SWITCH_SIZE which defined in header file.
 Include "errno.h" to avoid compile error.

Changes v4:
 Take Fabio's comments, fix return value using -EINVAL when error.

Changes v3:
 delete the new feature, it is fine to use the original v1 patch version

Changes v2:
 implement new feature to configure one regulator

 board/freescale/common/pfuze.c | 38 ++
 board/freescale/common/pfuze.h |  1 +
 2 files changed, 39 insertions(+)

diff --git a/board/freescale/common/pfuze.c b/board/freescale/common/pfuze.c
index 2cd1794..4980bf7 100644
--- a/board/freescale/common/pfuze.c
+++ b/board/freescale/common/pfuze.c
@@ -5,9 +5,47 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
+int pfuze_mode_init(struct pmic *p, u32 mode)
+{
+   unsigned char offset, i, switch_num;
+   u32 id, ret;
+
+   pmic_reg_read(p, PFUZE100_DEVICEID, &id);
+   id = id & 0xf;
+
+   if (id == 0) {
+   switch_num = 6;
+   offset = PFUZE100_SW1CMODE;
+   } else if (id == 1) {
+   switch_num = 4;
+   offset = PFUZE100_SW2MODE;
+   } else {
+   printf("Not supported, id=%d\n", id);
+   return -EINVAL;
+   }
+
+   ret = pmic_reg_write(p, PFUZE100_SW1ABMODE, mode);
+   if (ret < 0) {
+   printf("Set SW1AB mode error!\n");
+   return ret;
+   }
+
+   for (i = 0; i < switch_num - 1; i++) {
+   ret = pmic_reg_write(p, offset + i * SWITCH_SIZE, mode);
+   if (ret < 0) {
+   printf("Set switch 0x%x mode error!\n",
+  offset + i * SWITCH_SIZE);
+   return ret;
+   }
+   }
+
+   return ret;
+}
+
 struct pmic *pfuze_common_init(unsigned char i2cbus)
 {
struct pmic *p;
diff --git a/board/freescale/common/pfuze.h b/board/freescale/common/pfuze.h
index 7a4126c..53cfc99 100644
--- a/board/freescale/common/pfuze.h
+++ b/board/freescale/common/pfuze.h
@@ -8,5 +8,6 @@
 #define __PFUZE_BOARD_HELPER__
 
 struct pmic *pfuze_common_init(unsigned char i2cbus);
+int pfuze_mode_init(struct pmic *p, u32 mode);
 
 #endif
-- 
1.8.4


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


[U-Boot] [PATCH] net: configure DWMAC DMA by default AXI burst length

2015-01-26 Thread sonic.adi
From: Sonic Zhang 

Board can define its own AXI burst length to improve DWMAC DMA performance.

Signed-off-by: Sonic Zhang 
---

 drivers/net/designware.c |2 ++
 drivers/net/designware.h |5 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 9ded895..d8d6792 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -256,6 +256,8 @@ static int dw_eth_init(struct eth_device *dev, bd_t *bis)
 
writel(readl(&dma_p->opmode) | RXSTART | TXSTART, &dma_p->opmode);
 
+   writel((CONFIG_DW_AXI_BURST_LEN & 0x1FF >> 1), &dma_p->axibus);
+
/* Start up the PHY */
if (phy_startup(priv->phydev)) {
printf("Could not initialize PHY %s\n",
diff --git a/drivers/net/designware.h b/drivers/net/designware.h
index ce51102..d8bd84d 100644
--- a/drivers/net/designware.h
+++ b/drivers/net/designware.h
@@ -102,6 +102,11 @@ struct eth_dma_regs {
 #define TXSECONDFRAME  (1 << 2)
 #define RXSTART(1 << 1)
 
+/* Default AXI BUS Burst length */
+#ifndef CONFIG_DW_AXI_BURST_LEN
+#define CONFIG_DW_AXI_BURST_LEN 0
+#endif
+
 /* Descriptior related definitions */
 #define MAC_MAX_FRAME_SZ   (1600)
 
-- 
1.7.9.5

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


Re: [U-Boot] [PATCH] drivers/net/e1000.c: fix compile warning under 64bit mode

2015-01-26 Thread Lian Minghuan-B31939

Hi York,

We can not use phys_addr_t and phys_size_t here.

If  CONFIG_PHYS_64BIT is defined and uboot is compiled as 32bit like 
PowerPC64 arch,
phys_addr_t and phys_size_t will be defined as 64bit, but the pointer is 
still 32bit size.
we could not convert  directly between phys_addr_t and a pointer without 
compile warning.

To avoid warning,  virt_to_phys and phys_to_virt are needed.
However, some architectures do not implemented them.

Thanks,
Minghuan


On 2015年01月26日 23:25, York Sun wrote:


On 01/21/2015 11:21 PM, Minghuan Lian wrote:

Fix this:
warning: cast from pointer to integer of different size

Signed-off-by: Minghuan Lian 
---
  drivers/net/e1000.c | 31 +--
  1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
index 6531030..cd44222 100644
--- a/drivers/net/e1000.c
+++ b/drivers/net/e1000.c
@@ -4927,22 +4927,23 @@ void
  fill_rx(struct e1000_hw *hw)
  {
struct e1000_rx_desc *rd;
-   uint32_t flush_start, flush_end;
+   unsigned long flush_start, flush_end;
  
  	rx_last = rx_tail;

rd = rx_base + rx_tail;
rx_tail = (rx_tail + 1) % 8;
memset(rd, 0, 16);
-   rd->buffer_addr = cpu_to_le64((u32)packet);
+   rd->buffer_addr = cpu_to_le64((unsigned long)packet);
  
  	/*

 * Make sure there are no stale data in WB over this area, which
 * might get written into the memory while the e1000 also writes
 * into the same memory area.
 */
-   invalidate_dcache_range((u32)packet, (u32)packet + 4096);
+   invalidate_dcache_range((unsigned long)packet,
+   (unsigned long)packet + 4096);
/* Dump the DMA descriptor into RAM. */
-   flush_start = ((u32)rd) & ~(ARCH_DMA_MINALIGN - 1);
+   flush_start = ((unsigned long)rd) & ~(ARCH_DMA_MINALIGN - 1);
flush_end = flush_start + roundup(sizeof(*rd), ARCH_DMA_MINALIGN);
flush_dcache_range(flush_start, flush_end);
  
@@ -4963,7 +4964,7 @@ e1000_configure_tx(struct e1000_hw *hw)

unsigned long tipg, tarc;
uint32_t ipgr1, ipgr2;
  
-	E1000_WRITE_REG(hw, TDBAL, (u32) tx_base);

+   E1000_WRITE_REG(hw, TDBAL, (unsigned long)tx_base);
E1000_WRITE_REG(hw, TDBAH, 0);
  
  	E1000_WRITE_REG(hw, TDLEN, 128);

@@ -5107,7 +5108,7 @@ e1000_configure_rx(struct e1000_hw *hw)
E1000_WRITE_FLUSH(hw);
}
/* Setup the Base and Length of the Rx Descriptor Ring */
-   E1000_WRITE_REG(hw, RDBAL, (u32) rx_base);
+   E1000_WRITE_REG(hw, RDBAL, (unsigned long)rx_base);
E1000_WRITE_REG(hw, RDBAH, 0);
  
  	E1000_WRITE_REG(hw, RDLEN, 128);

@@ -5138,14 +5139,14 @@ e1000_poll(struct eth_device *nic)
  {
struct e1000_hw *hw = nic->priv;
struct e1000_rx_desc *rd;
-   uint32_t inval_start, inval_end;
+   unsigned long inval_start, inval_end;
uint32_t len;
  
  	/* return true if there's an ethernet packet ready to read */

rd = rx_base + rx_last;
  
  	/* Re-load the descriptor from RAM. */

-   inval_start = ((u32)rd) & ~(ARCH_DMA_MINALIGN - 1);
+   inval_start = ((unsigned long)rd) & ~(ARCH_DMA_MINALIGN - 1);
inval_end = inval_start + roundup(sizeof(*rd), ARCH_DMA_MINALIGN);
invalidate_dcache_range(inval_start, inval_end);
  
@@ -5154,8 +5155,9 @@ e1000_poll(struct eth_device *nic)

/*DEBUGOUT("recv: packet len=%d \n", rd->length); */
/* Packet received, make sure the data are re-loaded from RAM. */
len = le32_to_cpu(rd->length);
-   invalidate_dcache_range((u32)packet,
-   (u32)packet + roundup(len, ARCH_DMA_MINALIGN));
+   invalidate_dcache_range((unsigned long)packet,
+   (unsigned long)packet +
+   roundup(len, ARCH_DMA_MINALIGN));
NetReceive((uchar *)packet, len);
fill_rx(hw);
return 1;
@@ -5170,7 +5172,7 @@ static int e1000_transmit(struct eth_device *nic, void 
*txpacket, int length)
struct e1000_hw *hw = nic->priv;
struct e1000_tx_desc *txp;
int i = 0;
-   uint32_t flush_start, flush_end;
+   unsigned long flush_start, flush_end;
  
  	txp = tx_base + tx_tail;

tx_tail = (tx_tail + 1) % 8;
@@ -5180,10 +5182,11 @@ static int e1000_transmit(struct eth_device *nic, void 
*txpacket, int length)
txp->upper.data = 0;
  
  	/* Dump the packet into RAM so e1000 can pick them. */

-   flush_dcache_range((u32)nv_packet,
-  (u32)nv_packet + roundup(length, ARCH_DMA_MINALIGN));
+   flush_dcache_range((unsigned long)nv_packet,
+  (unsigned long)nv_packet +
+  roundup(length, ARCH_DMA_MINALIGN));
/* Dump the descriptor into RAM as well. */
-   flush_start = ((u32)txp) & ~(ARCH_DMA_MINALIGN - 1);
+   flush_start = ((unsigned long)txp) & ~(ARCH_DMA_MINALIGN - 1

Re: [U-Boot] [PATCH 01/18] arndale: config: disable max77686 support

2015-01-26 Thread Simon Glass
On 8 January 2015 at 04:33, Przemyslaw Marczak  wrote:
> There is no MAX77686 pmic on this board,
> so the driver support should be removed.
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Minkyu Kang 
> ---
>  include/configs/arndale.h | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/include/configs/arndale.h b/include/configs/arndale.h
> index d68993b..3ad4a9b 100644
> --- a/include/configs/arndale.h
> +++ b/include/configs/arndale.h
> @@ -51,8 +51,6 @@
>  /* PMIC */
>  #define CONFIG_PMIC
>  #define CONFIG_POWER_I2C
> -#define CONFIG_POWER_MAX77686
> -
>
>  #define CONFIG_PREBOOT
>
> --
> 1.9.1
>

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 02/18] exynos5250: config: disable max77686 driver

2015-01-26 Thread Simon Glass
On 8 January 2015 at 04:33, Przemyslaw Marczak  wrote:
> This PMIC is not common for all Exynos5250
> based boards, so should be romoved from
> common config.
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Simon Glass 
> Cc: Minkyu Kang 
> ---
>  include/configs/exynos5250-common.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/include/configs/exynos5250-common.h 
> b/include/configs/exynos5250-common.h
> index 6714313..ae0e5ff 100644
> --- a/include/configs/exynos5250-common.h
> +++ b/include/configs/exynos5250-common.h
> @@ -28,9 +28,6 @@
>
>  #define CONFIG_SYS_INIT_SP_ADDRCONFIG_IRAM_STACK
>
> -/* PMIC */
> -#define CONFIG_POWER_MAX77686
> -
>  /* Sound */
>  #define CONFIG_CMD_SOUND
>  #ifdef CONFIG_CMD_SOUND
> --
> 1.9.1
>

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 04/18] exynos4: dts: add missing i2c properties

2015-01-26 Thread Simon Glass
On 8 January 2015 at 04:33, Przemyslaw Marczak  wrote:
> This patch modify i2c nodes in exynos4.dtsi with:
> - adding proper interrupts arrays for each i2c node,
>   which allows to decode periph id
> - add reg address for each i2c node for i2c driver internal use
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Minkyu Kang 
> Cc: Lukasz Majewski 
> ---
>  arch/arm/dts/exynos4.dtsi | 24 
>  1 file changed, 16 insertions(+), 8 deletions(-)

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 v2 09/10] odroid u3: enable dm i2c support

2015-01-26 Thread Simon Glass
On 26 January 2015 at 08:21, Przemyslaw Marczak  wrote:
> This patch enables CONFIG_DM_I2C and also CONFIG_DM_I2C_COMPAT.
> The last one should be removed when the dm pmic framework will
> be finished.
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Minkyu Kang 
>
> ---
> Changes v2:
> - new patch
> ---
>  board/samsung/odroid/odroid.c | 14 +-
>  include/configs/odroid.h  |  5 ++---
>  2 files changed, 3 insertions(+), 16 deletions(-)

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 05/18] arndale: dts: add missing i2c aliases

2015-01-26 Thread Simon Glass
On 8 January 2015 at 04:33, Przemyslaw Marczak  wrote:
> Without this alias setting, the seq numbers
> of the i2c devices are wrong.
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Simon Glass 
> Cc: Minkyu Kang 
> ---
>  arch/arm/dts/exynos5250-arndale.dts | 8 
>  1 file changed, 8 insertions(+)

This might be fixed now, but still I think aliases are a good idea.

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 03/18] smdk5250: config: enable max77686 driver support

2015-01-26 Thread Simon Glass
On 8 January 2015 at 04:33, Przemyslaw Marczak  wrote:
> This commit enable support for the above driver,
> which was disabled in common config.
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Simon Glass 
> Cc: Minkyu Kang 
> ---
>  include/configs/smdk5250.h | 2 ++
>  1 file changed, 2 insertions(+)

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 06/18] exynos5: pinmux: check flag for i2c config

2015-01-26 Thread Simon Glass
Hi Przemyslaw,

On 8 January 2015 at 04:33, Przemyslaw Marczak  wrote:
> Some versions of Exynos5 supports High-Speed I2C,
> on few interfaces, this change allows support this.
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Simon Glass 
> Cc: Akshay Saraswat 
> Cc: Minkyu Kang 
> ---
>  arch/arm/cpu/armv7/exynos/pinmux.c | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)

As mentioned in the other flag you should add a flag for high speed so
that it is explicit. See pinmux.h for what other devices do.

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


Re: [U-Boot] [PATCH v2 08/10] odroid u3: dts: add missing i2c aliases

2015-01-26 Thread Simon Glass
On 26 January 2015 at 08:21, Przemyslaw Marczak  wrote:
> This change fixes i2c bus numbering for Odroid U3.
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Minkyu Kang 
>
> ---
> Changes v2:
> - new patch
> ---
>  arch/arm/dts/exynos4412-odroid.dts | 7 +++
>  1 file changed, 7 insertions(+)

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 v2 07/10] dm: i2c: s3c24x0: adjust to dm-i2c api

2015-01-26 Thread Simon Glass
Hi Przemyslaw,

On 26 January 2015 at 08:21, Przemyslaw Marczak  wrote:
> This commit adjusts the s3c24x0 driver to new i2c api
> based on driver-model. The driver supports standard
> and high-speed i2c as previous.
>
> Tested on Trats2, Odroid U3, Arndale, Odroid XU3
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Simon Glass 
> Cc: Heiko Schocher 
> Cc: Minkyu Kang 
>

Tested on snow:

Tested-by: Simon Glass 

This looks right to me, but I have a number of nits, mostly code that
can be deleted, Please see below.

If you can respin this I will pick it up.

> ---
> Changes v2:
> - use consistent return values on errors
> - decrease transaction status timeout, because the previous one was too big
> ---
>  drivers/i2c/s3c24x0_i2c.c | 275 
> +++---
>  1 file changed, 233 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/i2c/s3c24x0_i2c.c b/drivers/i2c/s3c24x0_i2c.c
> index fd328f0..c82640d 100644
> --- a/drivers/i2c/s3c24x0_i2c.c
> +++ b/drivers/i2c/s3c24x0_i2c.c
> @@ -9,8 +9,9 @@
>   * as they seem to have the same I2C controller inside.
>   * The different address mapping is handled by the s3c24xx.h files below.
>   */
> -
>  #include 
> +#include 
> +#include 
>  #include 
>  #if (defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
>  #include 
> @@ -111,9 +112,9 @@
>  #define I2C_START_STOP 0x20/* START / STOP */
>  #define I2C_TXRX_ENA   0x10/* I2C Tx/Rx enable */
>
> -#define I2C_TIMEOUT_MS 1000/* 1 second */
> +#define I2C_TIMEOUT_MS 10  /* 10 ms */
>
> -#defineHSI2C_TIMEOUT_US 10 /* 100 ms, finer granularity */
> +#defineHSI2C_TIMEOUT_US 1 /* 10 ms, finer granularity */

Why change the timeouts? In any case that should be a separate patch.

>
>
>  /* To support VCMA9 boards and other who dont define max_i2c_num */
> @@ -121,13 +122,23 @@
>  #define CONFIG_MAX_I2C_NUM 1
>  #endif
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  /*
>   * For SPL boot some boards need i2c before SDRAM is initialised so force
>   * variables to live in SRAM
>   */
> +#ifdef CONFIG_SYS_I2C
>  static struct s3c24x0_i2c_bus i2c_bus[CONFIG_MAX_I2C_NUM]
> __attribute__((section(".data")));
> +#endif
> +
> +enum exynos_i2c_type {
> +   EXYNOS_I2C_STD,
> +   EXYNOS_I2C_HS,
> +};
>
> +#ifdef CONFIG_SYS_I2C
>  /**
>   * Get a pointer to the given bus index
>   *
> @@ -147,6 +158,7 @@ static struct s3c24x0_i2c_bus *get_bus(unsigned int 
> bus_idx)
> debug("Undefined bus: %d\n", bus_idx);
> return NULL;
>  }
> +#endif
>
>  #if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
>  static int GetI2CSDA(void)
> @@ -251,6 +263,7 @@ static void ReadWriteByte(struct s3c24x0_i2c *i2c)
> writel(readl(&i2c->iiccon) & ~I2CCON_IRPND, &i2c->iiccon);
>  }
>
> +#ifdef CONFIG_SYS_I2C
>  static struct s3c24x0_i2c *get_base_i2c(int bus)
>  {
>  #ifdef CONFIG_EXYNOS4
> @@ -267,6 +280,7 @@ static struct s3c24x0_i2c *get_base_i2c(int bus)
> return s3c24x0_get_base_i2c();
>  #endif
>  }
> +#endif
>
>  static void i2c_ch_init(struct s3c24x0_i2c *i2c, int speed, int slaveadd)
>  {
> @@ -326,7 +340,7 @@ static int hsi2c_get_clk_details(struct s3c24x0_i2c_bus 
> *i2c_bus)
> return 0;
> }
> }
> -   return -1;
> +   return -EINVAL;
>  }
>
>  static void hsi2c_ch_init(struct s3c24x0_i2c_bus *i2c_bus)
> @@ -398,18 +412,20 @@ static void exynos5_i2c_reset(struct s3c24x0_i2c_bus 
> *i2c_bus)
> hsi2c_ch_init(i2c_bus);
>  }
>
> +#ifdef CONFIG_SYS_I2C
>  static void s3c24x0_i2c_init(struct i2c_adapter *adap, int speed, int 
> slaveadd)
>  {
> struct s3c24x0_i2c *i2c;
> struct s3c24x0_i2c_bus *bus;
> -
>  #if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5)
> struct s3c24x0_gpio *gpio = s3c24x0_get_base_gpio();
>  #endif
> ulong start_time = get_timer(0);
>
> -   /* By default i2c channel 0 is the current bus */
> i2c = get_base_i2c(adap->hwadapnr);
> +   bus = &i2c_bus[adap->hwadapnr];
> +   if (!bus)
> +   return;
>
> /*
>  * In case the previous transfer is still going, wait to give it a
> @@ -470,12 +486,13 @@ static void s3c24x0_i2c_init(struct i2c_adapter *adap, 
> int speed, int slaveadd)
>  #endif
> }
>  #endif /* #if !(defined CONFIG_EXYNOS4 || defined CONFIG_EXYNOS5) */
> +
> i2c_ch_init(i2c, speed, slaveadd);
>
> -   bus = &i2c_bus[adap->hwadapnr];
> bus->active = true;
> bus->regs = i2c;
>  }
> +#endif /* CONFIG_SYS_I2C */
>
>  /*
>   * Poll the appropriate bit of the fifo status register until the interface 
> is
> @@ -698,40 +715,40 @@ static int hsi2c_read(struct exynos5_hsi2c *i2c,
> return rv;
>  }
>
> +#ifdef CONFIG_SYS_I2C
>  static unsigned int s3c24x0_i2c_set_bus_speed(struct i2c_adapter *adap,
> - unsigned int speed)
> + unsigne

Re: [U-Boot] [PATCH v2 10/10] exynos5: enable dm i2c

2015-01-26 Thread Simon Glass
On 26 January 2015 at 08:21, Przemyslaw Marczak  wrote:
> This patch enables CONFIG_DM_I2C and also CONFIG_DM_I2C_COMPAT.
> The last one should be removed when all the i2c peripheral
> drivers will use dm i2c framework.
>
> Signed-off-by: Przemyslaw Marczak 
> Cc: Akshay Saraswat 
> Cc: Minkyu Kang 
> Cc: Simon Glass 
>
> ---
> Changes v2:
> - new patch

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] drivers/net/e1000.c: fix compile warning under 64bit mode

2015-01-26 Thread York Sun
Minghuan,

On 01/26/2015 09:12 PM, Lian Minghuan-B31939 wrote:
> Hi York,
> 
> We can not use phys_addr_t and phys_size_t here.
> 
> If  CONFIG_PHYS_64BIT is defined and uboot is compiled as 32bit like 
> PowerPC64 arch,
> phys_addr_t and phys_size_t will be defined as 64bit, but the pointer is 
> still 32bit size.

I take unsigned long is a good alternative.

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


[U-Boot] [PATCH v4 0/4] dm: i2c: Convert cros_ec_i2c over to driver model

2015-01-26 Thread Simon Glass
This series sits on top of Przemyslaw's recent driver model conversion for
Exynos. It changes the cros_ec_i2c driver to use driver model.

Also a new device tree property is added to support offset length, a U-Boot
I2C concept but a feature of the hardware.

Changes in v4:
- Bring in the correct patch version
- Add patches to support offset length in device tree
- Rebase on top of exynos I2C series

Simon Glass (4):
  dm: i2c: dts: Support an offset-len device tree property
  dm: exynos: dts: Set the offset length for cros_ec
  dm: i2c: Add two more I2C init functions to the compatibility layer
  dm: cros_ec: Convert cros_ec_i2c over to driver model

 arch/arm/dts/exynos5250-snow.dts |  1 +
 doc/device-tree-bindings/i2c/i2c.txt | 28 
 drivers/i2c/i2c-uclass-compat.c  | 16 +--
 drivers/i2c/i2c-uclass.c |  3 +-
 drivers/misc/cros_ec_i2c.c   | 82 +---
 include/configs/snow.h   |  1 +
 include/i2c.h| 17 +++-
 7 files changed, 90 insertions(+), 58 deletions(-)
 create mode 100644 doc/device-tree-bindings/i2c/i2c.txt

-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH v4 4/4] dm: cros_ec: Convert cros_ec_i2c over to driver model

2015-01-26 Thread Simon Glass
Move this driver to use driver model and update the snow configuration to
match.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Add patches to support offset length in device tree
- Rebase on top of exynos I2C series

 drivers/misc/cros_ec_i2c.c | 82 --
 include/configs/snow.h |  1 +
 2 files changed, 30 insertions(+), 53 deletions(-)

diff --git a/drivers/misc/cros_ec_i2c.c b/drivers/misc/cros_ec_i2c.c
index 513cdb1..f9bc975 100644
--- a/drivers/misc/cros_ec_i2c.c
+++ b/drivers/misc/cros_ec_i2c.c
@@ -14,6 +14,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -23,11 +24,11 @@
 #define debug_trace(fmt, b...)
 #endif
 
-int cros_ec_i2c_command(struct cros_ec_dev *dev, uint8_t cmd, int cmd_version,
-const uint8_t *dout, int dout_len,
-uint8_t **dinp, int din_len)
+static int cros_ec_i2c_command(struct udevice *udev, uint8_t cmd,
+  int cmd_version, const uint8_t *dout,
+  int dout_len, uint8_t **dinp, int din_len)
 {
-   int old_bus = 0;
+   struct cros_ec_dev *dev = udev->uclass_priv;
/* version8, cmd8, arglen8, out8[dout_len], csum8 */
int out_bytes = dout_len + 4;
/* response8, arglen8, in8[din_len], checksum8 */
@@ -37,8 +38,6 @@ int cros_ec_i2c_command(struct cros_ec_dev *dev, uint8_t cmd, 
int cmd_version,
uint8_t *in_ptr;
int len, csum, ret;
 
-   old_bus = i2c_get_bus_num();
-
/*
 * Sanity-check I/O sizes given transaction overhead in internal
 * buffers.
@@ -86,36 +85,24 @@ int cros_ec_i2c_command(struct cros_ec_dev *dev, uint8_t 
cmd, int cmd_version,
*ptr++ = (uint8_t)
cros_ec_calc_checksum(dev->dout, dout_len + 3);
 
-   /* Set to the proper i2c bus */
-   if (i2c_set_bus_num(dev->bus_num)) {
-   debug("%s: Cannot change to I2C bus %d\n", __func__,
-   dev->bus_num);
-   return -1;
-   }
-
/* Send output data */
cros_ec_dump_data("out", -1, dev->dout, out_bytes);
-   ret = i2c_write(dev->addr, 0, 0, dev->dout, out_bytes);
+   ret = dm_i2c_write(udev, 0, dev->dout, out_bytes);
if (ret) {
-   debug("%s: Cannot complete I2C write to 0x%x\n",
-   __func__, dev->addr);
+   debug("%s: Cannot complete I2C write to %s\n", __func__,
+ udev->name);
ret = -1;
}
 
if (!ret) {
-   ret = i2c_read(dev->addr, 0, 0, in_ptr, in_bytes);
+   ret = dm_i2c_read(udev, 0, in_ptr, in_bytes);
if (ret) {
-   debug("%s: Cannot complete I2C read from 0x%x\n",
-   __func__, dev->addr);
+   debug("%s: Cannot complete I2C read from %s\n",
+ __func__, udev->name);
ret = -1;
}
}
 
-   /* Return to original bus number */
-   i2c_set_bus_num(old_bus);
-   if (ret)
-   return ret;
-
if (*in_ptr != EC_RES_SUCCESS) {
debug("%s: Received bad result code %d\n", __func__, *in_ptr);
return -(int)*in_ptr;
@@ -142,35 +129,24 @@ int cros_ec_i2c_command(struct cros_ec_dev *dev, uint8_t 
cmd, int cmd_version,
return din_len;
 }
 
-int cros_ec_i2c_decode_fdt(struct cros_ec_dev *dev, const void *blob)
+static int cros_ec_probe(struct udevice *dev)
 {
-   /* Decode interface-specific FDT params */
-   dev->max_frequency = fdtdec_get_int(blob, dev->node,
-   "i2c-max-frequency", 10);
-   dev->bus_num = i2c_get_bus_num_fdt(dev->parent_node);
-   if (dev->bus_num == -1) {
-   debug("%s: Failed to read bus number\n", __func__);
-   return -1;
-   }
-   dev->addr = fdtdec_get_int(blob, dev->node, "reg", -1);
-   if (dev->addr == -1) {
-   debug("%s: Failed to read device address\n", __func__);
-   return -1;
-   }
-
-   return 0;
+   return cros_ec_register(dev);
 }
 
-/**
- * Initialize I2C protocol.
- *
- * @param dev  CROS_EC device
- * @param blob Device tree blob
- * @return 0 if ok, -1 on error
- */
-int cros_ec_i2c_init(struct cros_ec_dev *dev, const void *blob)
-{
-   i2c_init(dev->max_frequency, dev->addr);
-
-   return 0;
-}
+static struct dm_cros_ec_ops cros_ec_ops = {
+   .command = cros_ec_i2c_command,
+};
+
+static const struct udevice_id cros_ec_ids[] = {
+   { .compatible = "google,cros-ec" },
+   { }
+};
+
+U_BOOT_DRIVER(cros_ec_i2c) = {
+   .name   = "cros_ec",
+   .id = UCLASS_CROS_EC,
+   .of_match   = cros_ec_ids,
+   .probe  = cros_ec_probe,
+   .ops= &cros_ec_ops,
+};
diff --git a/include/configs/snow.h b/include/con

[U-Boot] [PATCH v4 3/4] dm: i2c: Add two more I2C init functions to the compatibility layer

2015-01-26 Thread Simon Glass
These functions are useful in case the board calls them. Also fix a missing
parameter caused by applying the wrong patch (actually I failed to send v2
and applied v1 by mistake).

Signed-off-by: Simon Glass 
---

Changes in v4:
- Bring in the correct patch version

 drivers/i2c/i2c-uclass-compat.c | 16 +---
 include/i2c.h   | 17 -
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/i2c-uclass-compat.c b/drivers/i2c/i2c-uclass-compat.c
index 11239da..223f238 100644
--- a/drivers/i2c/i2c-uclass-compat.c
+++ b/drivers/i2c/i2c-uclass-compat.c
@@ -17,13 +17,13 @@ static int i2c_compat_get_device(uint chip_addr, int alen,
struct dm_i2c_chip *chip;
int ret;
 
-   ret = i2c_get_chip_for_busnum(cur_busnum, chip_addr, devp);
+   ret = i2c_get_chip_for_busnum(cur_busnum, chip_addr, alen, devp);
if (ret)
return ret;
chip = dev_get_parent_platdata(*devp);
if (chip->offset_len != alen) {
-   printf("Requested alen %d does not match chip offset_len %d\n",
-  alen, chip->offset_len);
+   printf("I2C chip %x: requested alen %d does not match chip 
offset_len %d\n",
+  chip_addr, alen, chip->offset_len);
return -EADDRNOTAVAIL;
}
 
@@ -96,3 +96,13 @@ int i2c_set_bus_num(unsigned int bus)
 
return 0;
 }
+
+void i2c_init(int speed, int slaveaddr)
+{
+   /* Nothing to do here - the init happens through driver model */
+}
+
+void board_i2c_init(const void *blob)
+{
+   /* Nothing to do here - the init happens through driver model */
+}
diff --git a/include/i2c.h b/include/i2c.h
index 95d6f28..27fe00f 100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -225,7 +225,7 @@ int i2c_get_bus_num_fdt(int node);
 unsigned int i2c_get_bus_num(void);
 
 /**
- * i2c_set_bus_num(): Compatibility function for driver model
+ * i2c_set_bus_num() - Compatibility function for driver model
  *
  * Sets the 'current' bus
  */
@@ -241,6 +241,21 @@ static inline unsigned int I2C_GET_BUS(void)
return i2c_get_bus_num();
 }
 
+/**
+ * i2c_init() - Compatibility function for driver model
+ *
+ * This function does nothing.
+ */
+void i2c_init(int speed, int slaveaddr);
+
+/**
+ * board_i2c_init() - Compatibility function for driver model
+ *
+ * @param blob  Device tree blbo
+ * @return the number of I2C bus
+ */
+void board_i2c_init(const void *blob);
+
 #endif
 
 /*
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH v4 2/4] dm: exynos: dts: Set the offset length for cros_ec

2015-01-26 Thread Simon Glass
The EC has no concept of offset, so use a value of 0.

Signed-off-by: Simon Glass 
---

Changes in v4: None

 arch/arm/dts/exynos5250-snow.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/exynos5250-snow.dts b/arch/arm/dts/exynos5250-snow.dts
index 649e4bd..7d8be69 100644
--- a/arch/arm/dts/exynos5250-snow.dts
+++ b/arch/arm/dts/exynos5250-snow.dts
@@ -44,6 +44,7 @@
reg = <0x1e>;
compatible = "google,cros-ec";
i2c-max-frequency = <10>;
+   u-boot,i2c-offset-len = <0>;
ec-interrupt = <&gpx1 6 GPIO_ACTIVE_LOW>;
};
 
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH v4 1/4] dm: i2c: dts: Support an offset-len device tree property

2015-01-26 Thread Simon Glass
Since U-Boot can support different offset lengths (0-4 bytes), add a device
tree property to specify this. This avoids hard-coding it in the driver.

Signed-off-by: Simon Glass 
---

Changes in v4: None

 doc/device-tree-bindings/i2c/i2c.txt | 28 
 drivers/i2c/i2c-uclass.c |  3 ++-
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 doc/device-tree-bindings/i2c/i2c.txt

diff --git a/doc/device-tree-bindings/i2c/i2c.txt 
b/doc/device-tree-bindings/i2c/i2c.txt
new file mode 100644
index 000..ea918dd
--- /dev/null
+++ b/doc/device-tree-bindings/i2c/i2c.txt
@@ -0,0 +1,28 @@
+U-Boot I2C
+--
+
+U-Boot's I2C model has the concept of an offset within a chip (I2C target
+device). The offset can be up to 4 bytes long, but is normally 1 byte,
+meaning that offsets from 0 to 255 are supported by the chip. This often
+corresponds to register numbers.
+
+Apart from the controller-specific I2C bindings, U-Boot supports a special
+property which allows the chip offset length to be selected.
+
+Optional properties:
+- u-boot,i2c-offset-len - length of chip offset in bytes. If omitted the
+default value of 1 is used.
+
+
+Example
+---
+
+i2c4: i2c@12ca {
+   cros-ec@1e {
+   reg = <0x1e>;
+   compatible = "google,cros-ec";
+   i2c-max-frequency = <10>;
+   u-boot,i2c-offset-len = <0>;
+   ec-interrupt = <&gpx1 6 GPIO_ACTIVE_LOW>;
+   };
+};
diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
index 393cd6f..eafa457 100644
--- a/drivers/i2c/i2c-uclass.c
+++ b/drivers/i2c/i2c-uclass.c
@@ -420,7 +420,8 @@ int i2c_deblock(struct udevice *bus)
 int i2c_chip_ofdata_to_platdata(const void *blob, int node,
struct dm_i2c_chip *chip)
 {
-   chip->offset_len = 1;   /* default */
+   chip->offset_len = fdtdec_get_int(gd->fdt_blob, node,
+ "u-boot,i2c-offset-len", 1);
chip->flags = 0;
chip->chip_addr = fdtdec_get_int(gd->fdt_blob, node, "reg", -1);
if (chip->chip_addr == -1) {
-- 
2.2.0.rc0.207.ga3a616c

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


Re: [U-Boot] [PATCH] patman: Make dry-run output match real functionality

2015-01-26 Thread Simon Glass
Hi Peter,

On 26 January 2015 at 10:42, Peter Tyser  wrote:
> When run with the --dry-run argument patman prints out information
> showing what it would do.  This information currently doesn't line up
> with what patman/git send-email really do.  Some basic examples:
> - If an email address is addressed via "Series-cc" and "Patch-cc" patman
>   shows that email address would be CC-ed two times.
> - If an email address is addressed via "Series-to" and "Patch-cc" patman
>   shows that email address would be sent TO and CC-ed.
> - If an email address is addressed from a combination of tag aliases,
>   get_maintainer.pl output, "Series-cc", "Patch-cc", etc patman shows
>   that the email address would be CC-ed multiple times.
>
> Patman currently does try to send duplicate emails like the --dry-run
> output shows, but "git send-email" intelligently removes duplicate
> addresses so this patch shouldn't change the non-dry-run functionality.
>
> Change patman's output and email addressing to line up with the
> "git send-email" logic.  This trims down patman's dry-run output and
> prevents confusion about what patman will do when emails are actually
> sent.

Thanks for the patch, it's good to match up with git send-email.

Are the rules that git send-email follows documented or obtained by
trial and error?

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


Re: [U-Boot] usb flash boot on am335x machines

2015-01-26 Thread matti kaasinen
2015-01-26 17:46 GMT+02:00 Jon Cormier :

> 26.1.8.6


Thanks Jon!

My interpretation from codes was pretty much what you described that USB
boot really was "modified network boot". I'm not too sure that this was HW
restriction (=CPU) but merely u-boot boot strategy decision as am335x does
have boot order strapping also for USB boot. It would be nice if I could
find clear reason why USB flash boot won't work apart from the fact that
u-boot code for am335x is not currently written in that way.

If it turns out that usb flash boot could be made possible by u-boot
patching, it would be also nice if anyone knew if this
https://gitorious.org/rowboat/u-boot/commit/aaa9d5c083252218fd89afa68161f96bb7daa04c
worked, so that I would not waste my time trying to modify them for u-boot
2013.10 if they did not work.

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


Re: [U-Boot] [PATCH 1/3] ARmv7: Add a soc_init hook to start.S

2015-01-26 Thread Albert ARIBAUD
Hello Tom,

On Thu, 22 Jan 2015 11:20:58 -0500, Tom Rini  wrote:
> On Wed, Jan 21, 2015 at 09:03:25PM +0100, Hans de Goede wrote:
> 
> > On some SoCs / ARMv7 CPU cores we need to do some setup before enabling the
> > icache, etc. Add a soc_init hook with a weak default which just calls
> > cpu_init_cp15.
> > 
> > This way different implementations can be provided to do some extra work
> > before or after cpu_init_cp15, or completely replacing cpu_init_cp15.
> > 
> > Signed-off-by: Hans de Goede 
> > ---
> >  arch/arm/cpu/armv7/start.S | 18 +-
> >  1 file changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> > index fdc05b9..9882b20 100644
> > --- a/arch/arm/cpu/armv7/start.S
> > +++ b/arch/arm/cpu/armv7/start.S
> > @@ -64,7 +64,7 @@ reset:
> >  
> > /* the mask ROM code should have PLL and others stable */
> >  #ifndef CONFIG_SKIP_LOWLEVEL_INIT
> > -   bl  cpu_init_cp15
> > +   bl  soc_init
> > bl  cpu_init_crit
> >  #endif
> 
> I like the direction here.

I don't like all of it, specifically the double call, to cpu_init_cp15
then soc_init, for two reasons:

0) soc_init might touch cp15, but it's hidden in the name whereas it is
   shown in cpu_init_cp15. Either both names should explicitly say they
   are touching cp15, or both should not.

1) we cannot tell if cpu_init_cp15 should always happen before
   soc_init. Having a single call to soc_init, with the understanding
   that it will handle the cpu_init_cp15 call itself, makes it
   possible for soc_init yo decide whether it wants to call
   cpu_init_cp15 first, last or at all.

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


[U-Boot] [GIT PULL] Zynq SoC changes v2

2015-01-26 Thread Michal Simek
Hi Tom,

here is the second pull request for Zynq.
I have tested all patches by buildman(log below) with a kernel toolchain

[u-boot]$ arm-unknown-linux-gnueabi-gcc --version
arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.

I have put together that config.mk patch and enabling neon instructions.

I have also added that 2 patches for serial. Zynq is only platfrom
which is using this driver.

Thanks,
Michal

[u-boot]$ ./tools/buildman/buildman -b xnext/zynq zynq -sSe
boards.cfg is up to date. Nothing to do.
Summary of 15 commits for 7 boards (7 threads, 2 jobs per thread)
01: Prepare v2015.01
02: ARM: zynq: Enable the Neon instructions
   arm: (for 7/7 boards)  all +51.4  bss -0.6  rodata +20.0  
spl/u-boot-spl:all +52.0  spl/u-boot-spl:rodata +20.0  spl/u-boot-spl:text 
+32.0  text +32.0
03: ARM: zynq: Remove empty line
04: ARM: zynq: ddrc: Setup half of memory only for ECC case
   arm: (for 7/7 boards)  all +12.6  bss +0.6  text +12.0
05: ARM: zynq: slcr: Dont modify the reserved bits
06: ARM: zynq: List nand, qspi and jtag boot modes
   arm: (for 7/7 boards)  spl/u-boot-spl:all +47.4  spl/u-boot-spl:text 
+47.4
07: ARM: zynq: List qspi, smc and nand baseaddresses
08: ARM: zynq: Show board information by default
   arm: (for 7/7 boards)  all +66.3  bss +2.3  data +4.0  rodata +20.0  
text +40.0
09: ARM: zynq: Use CMD_FS_GENERIC
   arm: (for 7/7 boards)  all +972.0  bss -0.6  data +80.0  rodata +732.6  
text +160.0
10: ARM: zynq: Group ethernet configuration options together
   arm: (for 7/7 boards)  all +26.3  bss +0.6  rodata +2.3  text +23.4
11: ARM: zynq: provide config option to select emio
12: ARM: zynq: Enable DFU functionality in zynq
   arm: (for 7/7 boards)  all +1804167.1  bss +1797574.9  data +181.7  
rodata +822.0  text +5588.6
13: ARM: zynq: Add USB lthor download protocol support
   arm: (for 7/7 boards)  all +2383.7  bss +148.6  data +54.9  rodata 
+447.7  text +1732.6
14: serial: zynq: Use global baudrate instead of hardcoded one
   arm: (for 7/7 boards)  all -26.3  bss -2.3  rodata -8.0  
spl/u-boot-spl:all -16.0  spl/u-boot-spl:rodata -8.0  spl/u-boot-spl:text -8.0  
text -16.0
15: serial: Extend structure comments with register offset
(no errors to report)


The following changes since commit 92fa7f53f1f3f03296f8ffb14bdf1baefab83368:

  Prepare v2015.01 (2015-01-12 09:39:08 -0500)

are available in the git repository at:

  git://www.denx.de/git/u-boot-microblaze.git zynq

for you to fetch changes up to a2425e6207d7c75906a15410f4c8c0a5d0519349:

  serial: Extend structure comments with register offset (2015-01-26 08:55:59 
+0100)


Michal Simek (10):
  ARM: zynq: Enable the Neon instructions
  ARM: zynq: Remove empty line
  ARM: zynq: ddrc: Setup half of memory only for ECC case
  ARM: zynq: List nand, qspi and jtag boot modes
  ARM: zynq: List qspi, smc and nand baseaddresses
  ARM: zynq: Show board information by default
  ARM: zynq: Use CMD_FS_GENERIC
  ARM: zynq: Group ethernet configuration options together
  serial: zynq: Use global baudrate instead of hardcoded one
  serial: Extend structure comments with register offset

Siva Durga Prasad Paladugu (4):
  ARM: zynq: slcr: Dont modify the reserved bits
  ARM: zynq: provide config option to select emio
  ARM: zynq: Enable DFU functionality in zynq
  ARM: zynq: Add USB lthor download protocol support

 arch/arm/cpu/armv7/zynq/Makefile  |  1 +
 arch/arm/cpu/armv7/zynq/config.mk |  7 +++
 arch/arm/cpu/armv7/zynq/cpu.c |  4 
 arch/arm/cpu/armv7/zynq/ddrc.c|  2 ++
 arch/arm/cpu/armv7/zynq/lowlevel_init.S   | 26 ++
 arch/arm/cpu/armv7/zynq/slcr.c|  2 +-
 arch/arm/cpu/armv7/zynq/spl.c |  9 +
 arch/arm/include/asm/arch-zynq/hardware.h |  5 +
 board/xilinx/zynq/board.c | 14 --
 drivers/serial/serial_zynq.c  | 30 +++---
 include/configs/zynq-common.h | 77 
+++--
 11 files changed, 137 insertions(+), 40 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/zynq/config.mk
 create mode 100644 arch/arm/cpu/armv7/zynq/lowlevel_init.S

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




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


Re: [U-Boot] [PATCH 2/4] usb: add 'bcm_udc_otg' support

2015-01-26 Thread Lukasz Majewski
Hi Marek,

> On Saturday, January 24, 2015 at 12:48:15 AM, Steve Rae wrote:
> > On 15-01-21 11:05 PM, Marek Vasut wrote:
> > > On Tuesday, January 20, 2015 at 11:42:08 PM, Steve Rae wrote:
> > >> Implement the UDC support for the USB OTG interface.
> > >> 
> > >> Signed-off-by: Steve Rae 
> > >> ---
> > > 
> > > General question -- this bcm controller you're adding here isn't
> > > by any chance a DWC2 controller, or is it ? There's already a
> > > driver for DWC2 in drivers/usb/gadget/s3c_udc_otg.c . This driver
> > > should really be properly renamed though ;-/
> > > 
> > > If this is not DWC2, do you know what controller this is please ?
> > 
> > yes -- it is a DWC2
> > 
> > So, I have had a quick look at the s3c_udc_otg*.c code
> > 
> > First observation is that there is a completely different
> > philosophy in the implementation. For example, the the interrupt
> > handler routine(s), Broadcom is using #defines (sysmap.h which BTW
> > are autogenerated by our Device Team) whereas "S3C" is using a
> > "s3c_usbotg_reg" structure for the 'address' and #defines for the
> > 'data/masks'. I'm not suggesting that one is better than the other,
> > they are just different.
> 
> Hi!
> 
> The later is accepted by U-Boot as the preferred way, so the s3c is
> doing things right.
> 
> > So, how do we proceed?
> 
> At this point, the Altera SoCFPGA and Samsung Exynos both use this s3c
> driver to operate the DWC2 core in gadget mode. It should be trivial
> to add support for the boardcom SoC, just follow the Altera example.
> 
> I would like to avoid situation where we have two drivers for a single
> IP block.
> 
> > - is the ultimate goal to get to a proper gadget driver for DWC2? (I
> > don't really know enough about this yet, so I apologize for these
> > questions)
> 
> Yes, but we already have one to my knowledge.
> 
> > - is the "S3C" code a proper 'gadget' driver and/or is it a better
> > starting point to get to a gadget driver?
> 
> Yes, and it's thoroughly tested already.
> 
> > - I don't have enough time right now to really investigate the
> > existing "S3C" and implement it on our board(s); they are
> > significantly different and it looks like it will take a lot of
> > effort - is there someone (Denx or community) that could assist me?
> 
> Sure, just start asking the questions.
> 
> > - Could we continue to review this patchset and accept it; then
> > establish a team to provide a "DWC2 gadget" that could be used going
> > forward?
> 
> No, unless there's a convincing technical argument that the currently
> mainline DWC2 gadget driver (the s3c one) can absolutelly not be used
> for the broadcom SoC, I want to avoid having two drivers for the same
> IP core in mainline, sorry.

Maybe it is a highest time to think about renaming s3c_* to dwc2_* and
avoid further confusion.

> 
> [...]
> 
> Sorry, at this point I have to push back a little.
> 
> Best regards,
> Marek Vasut



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 15/19] dm: powerpc: ppc4xx: Move glacier to use driver model for serial

2015-01-26 Thread Stefan Roese
Hi Simon,

finally I'm testing your patchset. Again sorry for the big delay
here.

On 15.12.2014 15:19, Simon Glass wrote:
> Adjust Kconfig to default to driver model for glacier, canyonlands and
> arches.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>   board/amcc/canyonlands/Kconfig | 9 +
>   1 file changed, 9 insertions(+)
> 
> diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig
> index 0fc6877..cbc5ff9 100644
> --- a/board/amcc/canyonlands/Kconfig
> +++ b/board/amcc/canyonlands/Kconfig
> @@ -29,4 +29,13 @@ config ARCHES
>   
>   endchoice
>   
> +config DM
> + default y
> +
> +config DM_SERIAL
> + default y
> +
> +config SYS_MALLOC_F_LEN
> + default 0x400
> +

Hmmm. This does not seem to work. With your patch series applied on
current top-of-tree I get this error (for glacier_ramboot or
canyonlands):

$ make -s -j10
board/amcc/canyonlands/Kconfig:38:warning: config symbol defined without type
drivers/serial/serial-uclass.c:29:2: error: #error "Serial is required before 
relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work"
make[1]: *** [drivers/serial/serial-uclass.o] Error 1

Somehow the CONFIG_SYS_MALLOC_F_LEN define is not available in the
.config used. Do you have any idea why it might be missing?

Thanks,
Stefan

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


Re: [U-Boot] [PATCH 15/19] dm: powerpc: ppc4xx: Move glacier to use driver model for serial

2015-01-26 Thread Stefan Roese

On 26.01.2015 10:23, Stefan Roese wrote:

diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig
index 0fc6877..cbc5ff9 100644
--- a/board/amcc/canyonlands/Kconfig
+++ b/board/amcc/canyonlands/Kconfig
@@ -29,4 +29,13 @@ config ARCHES

   endchoice

+config DM
+   default y
+
+config DM_SERIAL
+   default y
+
+config SYS_MALLOC_F_LEN
+   default 0x400
+


Hmmm. This does not seem to work. With your patch series applied on
current top-of-tree I get this error (for glacier_ramboot or
canyonlands):

$ make -s -j10
board/amcc/canyonlands/Kconfig:38:warning: config symbol defined without type
drivers/serial/serial-uclass.c:29:2: error: #error "Serial is required before 
relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work"
make[1]: *** [drivers/serial/serial-uclass.o] Error 1

Somehow the CONFIG_SYS_MALLOC_F_LEN define is not available in the
.config used. Do you have any idea why it might be missing?


Okay. Found it. Its the missing type here. I'll send some follow-up 
patches once I have all tested on canyonlands here.


Thanks,
Stefan

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


Re: [U-Boot] [RFC] m68k: generic board

2015-01-26 Thread Huan Wang
Hi, Tom,

> On Thu, Jan 15, 2015 at 04:08:40PM +0100, Angelo Dureghello wrote:
> > Dear all,
> >
> > i would like to post a patch with the m68k generic board support,
> > tested and working here, but of course not tested for all the other
> > m68k boards except mine.
> >
> > My coldfire board is the "amcore" board not yet accepted.
> >
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/193661
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/193660
> >
> > I need some suggestions on how to proceed now.
> >
> > I already modified my board config to work with generic board support.
> >
> > So my thought is to post 2 separate patches:
> > 1
> > - add generic board (1/1). Each board maintainer should then test it
> > and report for feedbacks.
> > 2
> > Re-post a 2/2 patch (v8) of amcore using generic board:
> > - amcore board (1),
> > - mcf5307 support (2),
> >
> > This amcore board is the coldfire base i use here for all the general
> > m68k tests.
> >
> > With your help commenting on this patch until it is conformant to the
> > last recent coding guidelines could help me and Alison to know what
> > has to be purged / changed, (eventually, if needed) in all other m68k
> > boards code.
> >
> > What do you think ?
> 
> Lets go with #2 and we'll purge the rest of the boards that you don't
> want to convert and compile test after -rc1.  Thanks!
> 
[Alison Wang] Do you mean you will purge the rest of the boards if they are not 
converted and tested?

I have these boards, such as m52277evb, m5253demo, m53017evb, m5329evb, 
m5373evb, m54418twr, m54451evb, m54455evb, m547xevb and m548xevb. I think I 
really need some time to convert and test them.


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


Re: [U-Boot] [RFC PATCH 14/21] ARM: at91: move SoC headers to mach-at91/include/mach

2015-01-26 Thread Andreas Bießmann
Dear Masahiro Yamada,

On 01/25/2015 07:11 AM, Masahiro Yamada wrote:
> Move arch/arm/include/asm/arch-at91/*
>   -> arch/arm/mach-at91/include/mach/*
> 
> Signed-off-by: Masahiro Yamada 
> Cc: Andreas Bießmann 

Acked-by: Andreas Bießmann 

I wonder if we should move arch/arm/cpu/at91-common with this patch also.

Best regards

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


[U-Boot] [PULL] u-boot-atmel/master -> u-boot/master

2015-01-26 Thread Andreas Bießmann
The following changes since commit ab77f24119e80257de4ab017b877f92f96980562:

  Merge branch 'master' of git://git.denx.de/u-boot-ti (2015-01-16 10:25:01 
-0500)

are available in the git repository at:


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

for you to fetch changes up to 52305a829cd927aca2eb4a15985c567e98f562b9:

  ARM: atmel: sama5d4_xplained: enable usb ethernet gadget (2015-01-19 15:02:48 
+0100)


Bo Shen (6):
  ARM: atmel: sama5d4: add usb platform data
  ARM: atmel: sama5d4: add usb device initial code
  ARM: atmel: sama5d4ek: add option for usb ethernet gadget
  ARM: atmel: sama5d4ek: enable usb ethernet gadget
  ARM: atmel: sama5d4_xplained: add option for usb ethernet gadget
  ARM: atmel: sama5d4_xplained: enable usb ethernet gadget

Heiko Schocher (5):
  arm, arm926ejs: make thumb mode compileable
  arm, at91: enable thumb mode for taurus board in SPL
  taurus, spl: erase also spi flash if recovery button is pressed
  arm, at91: corvus board updates
  arm, at91, axm: add SPL support for axm

Simon Glass (1):
  arm: at91: snapper9260: Drop invalid CONFIG_SKIP_RELOCATE_UBOOT

Wu, Josh (1):
  ARM: at91: sama5d3_xplained: spl: enable PMECC header generation

 arch/arm/cpu/arm926ejs/cpu.c|2 ++
 arch/arm/cpu/armv7/at91/sama5d4_devices.c   |   16 +++
 arch/arm/include/asm/arch-at91/atmel_usba_udc.h |2 +-
 arch/arm/lib/cache.c|2 ++
 board/atmel/sama5d4_xplained/sama5d4_xplained.c |   11 +++
 board/atmel/sama5d4ek/sama5d4ek.c   |   11 +++
 board/siemens/corvus/board.c|   12 +++-
 board/siemens/taurus/taurus.c   |   24 ++-
 configs/axm_defconfig   |5 +++--
 include/configs/corvus.h|4 ++--
 include/configs/sama5d3_xplained.h  |1 +
 include/configs/sama5d4_xplained.h  |8 
 include/configs/sama5d4ek.h |8 
 include/configs/snapper9260.h   |1 -
 include/configs/taurus.h|   23 +-
 15 files changed, 109 insertions(+), 21 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] ARmv7: Add a soc_init hook to start.S

2015-01-26 Thread Hans de Goede

Hi,

On 26-01-15 09:09, Albert ARIBAUD wrote:

Hello Tom,

On Thu, 22 Jan 2015 11:20:58 -0500, Tom Rini  wrote:

On Wed, Jan 21, 2015 at 09:03:25PM +0100, Hans de Goede wrote:


On some SoCs / ARMv7 CPU cores we need to do some setup before enabling the
icache, etc. Add a soc_init hook with a weak default which just calls
cpu_init_cp15.

This way different implementations can be provided to do some extra work
before or after cpu_init_cp15, or completely replacing cpu_init_cp15.

Signed-off-by: Hans de Goede 
---
  arch/arm/cpu/armv7/start.S | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index fdc05b9..9882b20 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -64,7 +64,7 @@ reset:

/* the mask ROM code should have PLL and others stable */
  #ifndef CONFIG_SKIP_LOWLEVEL_INIT
-   bl  cpu_init_cp15
+   bl  soc_init
bl  cpu_init_crit
  #endif


I like the direction here.


I don't like all of it, specifically the double call, to cpu_init_cp15
then soc_init, for two reasons:

0) soc_init might touch cp15, but it's hidden in the name whereas it is
shown in cpu_init_cp15. Either both names should explicitly say they
are touching cp15, or both should not.

1) we cannot tell if cpu_init_cp15 should always happen before
soc_init. Having a single call to soc_init, with the understanding
that it will handle the cpu_init_cp15 call itself, makes it
possible for soc_init yo decide whether it wants to call
cpu_init_cp15 first, last or at all.


There is no double call, the call to cpu_init_cp15 is being replaced with
a call to soc_init, which then can call cpu_init_cp15 at any time it likes.

Also see the discussion further in the thread about replacing soc_init
with a call to lowlevel_init which then call s_init which may then call
cpu_init_cp15 at a convenient time, the advantage of this approach is that
the soc / board specific code can be written in C rather then in asm.

Regards,

Hans

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


Re: [U-Boot] [PATCH v4 2/2] fastboot: handle flash write to GPT partitions

2015-01-26 Thread Lukasz Majewski
Hi Rob,

> On Fri, Dec 12, 2014 at 5:51 PM, Steve Rae  wrote:
> > Implement a feature to allow fastboot to write the downloaded image
> > to the space reserved for the Protective MBR and the Primary GUID
> > Partition Table.
> > Additionally, prepare and write the Backup GUID Partition Table.
> 
> I've been looking at how to do the same thing here. This is an area
> that suffers from each vendor doing whatever they want. Using vendor
> download/flash tools here is painful. They are all different because
> that is where the value add is. ;) What tool do you use on the host
> side to create the image? I have seen some vendor code to do it, or
> you could use parted plus a disk file and extract the partition table
> from it. I find either method a bit fragile and non-standard IMHO.
> 
> The 2 options I've come up with are 1) enable USB MS and use whatever
> host side tool you like or 2) use the existing "gpt write" command in
> u-boot and tie that into fastboot "oem format" command. The advantage
> and disadvantage of the latter is that it hides the partitioning
> details in u-boot from the user, but requires changing the u-boot env
> to change partition layout. The partitioning requirements are pretty
> SOC specific it seems.
> 
> I'm not saying we can't support both, but having some standardization
> here would be good.

On Exynos4/5 it is possible to use both. One can use mass storage (UMS)
and also gpt write.

Moreover, there is the dfu (which is slow but standardized) support in
u-boot, which seems SoC vendor agnostic. One can use dfu-util tools on
host side too.

I can share one way to update GPT by using dfu with 'gpt write' u-boot
command.

1. It is possible to extract default variables when u-boot is build:
{
# Generate params.bin
cp `find . -name "env_common.o"` copy_env_common.o

objcopy -O binary --only-section=.rodata.default_environment `find .
-name "copy_env_common.o"` tr '\0' '\n' < copy_env_common.o >
default_envs.txt mkenvimage -s 16384 -o params.bin default_envs.txt

rm copy_env_common.o default_envs.txt
}

2. Store params.bin in a known location (the location is soc dependent).
3. Reset board and execute 'gpt write mmc 0 $partitions' to default
$partitions from params.bin

This works on Exynos.

Another option would be to add special alt setting for dfu - GPT and
MBR which would accept binary partition layout and store them to proper
location.

> 
> Rob
> 
> >
> > Signed-off-by: Steve Rae 
> > ---
> >
> > Changes in v4:
> > fix bug with partition_entry_lba in Backup GPT
> > use common static functions
> >
> > Changes in v3:
> > - prefer leXX_to_cpu() over cpu_to_leXX()
> > - enhance calculation of pointer to GPT Entries
> > - prepare and write the Backup GPT
> >(requested by: Lukasz Majewski )
> >
> > Changes in v2:
> > add validation of the GPT before writing to flash
> > (suggested by: Lukasz Majewski )
> >
> >  README  |  9 ++
> >  common/fb_mmc.c | 26 ++--
> >  disk/part_efi.c | 93
> > +
> > include/part.h  | 20 + 4 files changed, 145
> > insertions(+), 3 deletions(-)
> >
> > diff --git a/README b/README
> > index 4ca04d0..42ece99 100644
> > --- a/README
> > +++ b/README
> > @@ -1773,6 +1773,15 @@ The following options need to be configured:
> > regarding the non-volatile storage device. Define
> > this to the eMMC device that fastboot should use to store the image.
> >
> > +   CONFIG_FASTBOOT_GPT_NAME
> > +   The fastboot "flash" command supports writing the
> > downloaded
> > +   image to the Protective MBR and the Primary GUID
> > Partition
> > +   Table. (Additionally, this downloaded image is
> > post-processed
> > +   to generate and write the Backup GUID Partition
> > Table.)
> > +   This occurs when the specified "partition name" on
> > the
> > +   "fastboot flash" command line matches this value.
> > +   Default is GPT_ENTRY_NAME (currently "gpt") if
> > undefined. +
> >  - Journaling Flash filesystem support:
> > CONFIG_JFFS2_NAND, CONFIG_JFFS2_NAND_OFF,
> > CONFIG_JFFS2_NAND_SIZE, CONFIG_JFFS2_NAND_DEV
> > diff --git a/common/fb_mmc.c b/common/fb_mmc.c
> > index fb06d8a..6ea3938 100644
> > --- a/common/fb_mmc.c
> > +++ b/common/fb_mmc.c
> > @@ -4,12 +4,17 @@
> >   * SPDX-License-Identifier:GPL-2.0+
> >   */
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >
> > +#ifndef CONFIG_FASTBOOT_GPT_NAME
> > +#define CONFIG_FASTBOOT_GPT_NAME GPT_ENTRY_NAME
> > +#endif
> > +
> >  /* The 64 defined bytes plus the '\0' */
> >  #define RESPONSE_LEN   (64 + 1)
> >
> > @@ -62,7 +67,6 @@ static void write_raw_image(block_dev_desc_t
> > *dev_desc, disk_partition_t *info, void fb_mmc_flash_write(const
> > char *cmd, void *download_buffer, unsigned int download_bytes, char
> > *response) {
> > -   int ret;
> > b

Re: [U-Boot] u-boot tools and build system

2015-01-26 Thread Otavio Salvador
On Thu, Jan 22, 2015 at 11:11 AM, Raphael Philipe  wrote:
> Thank you Wolfgang,
>
> For the especific case of the env tool, One can build it to run on the
> host to produce a environment variables binary file for the target
> (This can be used while building some image to be written in a sd
> card, spi flash or the like). For this specific case I'm in doubt on
> how to compile it. I'm trying to compile it for beaglebone black.
>
> I was able to compile it, but I'm not sure if I did it properly.
> Moreover I would like to know the role of HOSTCC in it and if it is
> correct to access it directly.
>
> I used the following commands:
>
> make am335x_evm_config CROSS_COMPILE=arm-poky-linux-gnueabi-
> HOSTCC="gcc " CC="arm-poky-linux-gnueabi-gcc  -march=armv7-a
> -mfloat-abi=hard -mfpu=neon -mtune=cortex-a8 "
> make env CROSS_COMPILE=arm-poky-linux-gnueabi- HOSTCC="gcc "
> CC="arm-poky-linux-gnueabi-gcc  -march=armv7-a -mfloat-abi=hard
> -mfpu=neon -mtune=cortex-a8 "
>
> Using this approach, I can compile code for the host that is dependent
> on the target architecture.
>
> All of this makes sense?

It does as the env tools rely on the target setup (environment size,
offset, ...) to do its job. So it does make sense.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] usb: add 'bcm_udc_otg' support

2015-01-26 Thread Marek Vasut
On Monday, January 26, 2015 at 09:38:28 AM, Lukasz Majewski wrote:
> Hi Marek,

Hi!

[...]

> > No, unless there's a convincing technical argument that the currently
> > mainline DWC2 gadget driver (the s3c one) can absolutelly not be used
> > for the broadcom SoC, I want to avoid having two drivers for the same
> > IP core in mainline, sorry.
> 
> Maybe it is a highest time to think about renaming s3c_* to dwc2_* and
> avoid further confusion.

The time was ripe for a while now ;-) Do you want to do it or shall I send
a patch ?

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


Re: [U-Boot] SPI driver convert to Driver Model

2015-01-26 Thread Simon Glass
Hi,

On 25 January 2015 at 20:44, haikun.w...@freescale.com
 wrote:
> Hi,
>
> My driver should support ls1021aqds, ls1021atwr, mcf5445x, mcf5227x, mcf52x2.

Please avoid top-posting.

The first one at least supports generic board. It doesn't look like
mcf5445x does though, so you should move that over ASAP (the deadline
has actually passed). There may be pending patches I don't know about.
Once you do that you can use drive model.

For device tree you can see a PowerPC conversion at u-boot-dm branch ppc-working

http://git.denx.de/?p=u-boot/u-boot-dm.git;a=shortlog;h=refs/heads/ppc-working

This should help you get it running on m68k. Sorry there are several
patches there that don't relate to this. These ones seem relevant.

1a83894 powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards
d70d614 powerpc: ppc4xx: Allow the end of u-boot.bin to be found
bfd89eb powerpc: ppc4xx: Call board_init_f_mem() for generic board
44c9942 powerpc: ppc4xx: dts: Bring in canyonlands device tree files
529e967 powerpc: ppc4xx: canyonlands: Move to generic board
3a17e68 powerpc: ppc4xx: Move CANYONLANDS/GLACIER/ARCHES to Kconfig
4bfa397 powerpc: Permit device tree control of U-Boot (CONFIG_OF_CONTROL)
4eda9b6 Introduce board_init_f_mem() to handle early memory layout

You should be able to create simple files with just the SPI interfaces
that you need. You can always expand them later.

If I had a board I would be happy to help.

Regards,
Simon

>
> Best regards,
> Wang Haikun
>
>
> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Friday, January 23, 2015 6:36 AM
> To: Wang Haikun-B53464
> Cc: U-Boot Mailing List
> Subject: Re: SPI driver convert to Driver Model
>
> (copying the list)
>
> Hi,
>
> On 19 January 2015 at 22:38, haikun.w...@freescale.com 
>  wrote:
>> Hi Simon,
>>
>>
>>
>> I am working for converting my SPI driver to driver model.
>>
>> I encountered some problems.
>>
>> My driver need to support many old platforms, such as m68k serials and
>> there is no DTS file for them in kernel now.
>>
>> It seems that compiling couldn’t be completed successfully  with
>> enable CONFIG_DM_SPI and disable CONFIG_OF_CONTROL
>>
>> because of some functions in file driver/spi/spi-uclass.c call DTS’s
>> interfaces .
>>
>> So are you working for supporting SPI DM works correctly in some
>> platforms without creating new DTS file for them such as m68k?
>>
>> Or can you give me some advice?
>
> One suggestion is to add a simple device tree for the platform. If you only 
> need to support serial and SPI it might be quite simple.
>
> Specifically what boards are you supporting?
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] usb: add 'bcm_udc_otg' support

2015-01-26 Thread Lukasz Majewski
Hi Marek,

> On Monday, January 26, 2015 at 09:38:28 AM, Lukasz Majewski wrote:
> > Hi Marek,
> 
> Hi!
> 
> [...]
> 
> > > No, unless there's a convincing technical argument that the
> > > currently mainline DWC2 gadget driver (the s3c one) can
> > > absolutelly not be used for the broadcom SoC, I want to avoid
> > > having two drivers for the same IP core in mainline, sorry.
> > 
> > Maybe it is a highest time to think about renaming s3c_* to dwc2_*
> > and avoid further confusion.
> 
> The time was ripe for a while now ;-) Do you want to do it or shall I
> send a patch ?

I do know that I will test it :-), so feel free to send the patch.

> 
> Best regards,
> Marek Vasut



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH 03/21] ARM: at91: collect SoC sources into mach-at91

2015-01-26 Thread Andreas Bießmann
Dear Masahiro Yamada,

On 01/25/2015 07:11 AM, Masahiro Yamada wrote:
> This commit moves source files as follows:
> 
>   arch/arm/cpu/arm920t/at91/*   -> arch/arm/mach-at91/arm920t/*
>   arch/arm/cpu/arm926ejs/at91/* -> arch/arm/mach-at91/arm926ejs/*
>   arch/arm/cpu/armv7/at91/* -> arch/arm/mach-at91/armv7/*
>   arch/arm/cpu/at91-common/*-> arch/arm/mach-at91/*
> 
> Signed-off-by: Masahiro Yamada 
> Cc: Andreas Bießmann 

Acked-by: Andreas Bießmann 

I should have read this mail first ;)

Best regards

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


Re: [U-Boot] [RFC PATCH 07/21] ARM: kirkwood: move SOC sources to mach-kirkwood

2015-01-26 Thread Stefan Roese

On 25.01.2015 07:11, Masahiro Yamada wrote:

Move
arch/arm/cpu/arm926ejs/kirkwood/* -> arch/arm/mach-kirkwood/*

Note:
  Perhaps, can we merge arch/arm/mach-kirkwood and
  arch/arm/mvebu-common into arch/arm/mach-mvebu, like Linux?


Yes. This might need a bit work but definitely should be done. And at 
some time also move orion over to mach-mvebu as well.


Thanks for this work.


Signed-off-by: Masahiro Yamada 
Cc: Prafulla Wadaskar 
Cc: Luka Perkov 
Cc: Stefan Roese 


Acked-by: Stefan Roese 

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


Re: [U-Boot] [RFC PATCH 01/21] ARM: at91: move board select menu and common settings

2015-01-26 Thread Andreas Bießmann
On 01/25/2015 07:11 AM, Masahiro Yamada wrote:
> The board select menu in arch/arm/Kconfig is still big.
> To slim down it, this commit moves AT91 boards to
> arch/arm/mach-at91/Kconfig.
> Also, consolidate "config SYS_SOC" in each board Kconfig.
> 
> The Kconfig files under board/ directory were modified with the
> following command:
> 
> find board -name Kconfig | xargs sed -i -e '
> /config SYS_SOC/ {
> N
> /default "at91"/ {
> N
> d
> }
> }
> '
> 
> Signed-off-by: Masahiro Yamada 

Acked-by: Andreas Bießmann 

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


[U-Boot] Dallas 1-wire support in u-boot

2015-01-26 Thread Andrea Scian

Dear u-boot developers,

I'm looking for support of 1-wire protocol in this bootloader, without 
luck up until now


I already search list archive with gmane and found only this old reference

http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/117292

I also found some board implementation, not as a generic driver but as 
simple routines inside board file to read a thermal chip (unfortunately 
I've missed the reference now).


Is there any staging patch or RFC for this protocol support in our 
beloved embedded bootloader?


Currently I'm implementing this feature into an old 2013.10 version but 
I think it should be easy to adapt this kind of drivers between 
different u-boot releases.


Best Regards and TIA,

--

Andrea SCIAN

DAVE Embedded Systems

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


Re: [U-Boot] [PATCH 12/19] powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards

2015-01-26 Thread Stefan Roese

On 15.12.2014 15:19, Simon Glass wrote:

Enable CONFIG_OF_CONTROL so that U-Boot on these three boards uses a device
tree for its configuration.

Signed-off-by: Simon Glass 


This need further work on the ppc4xx platforms to get it booting from 
flash. As now the dtb is appended to the "normal" U-Boot image. And this 
image is fine-tuned to fit into currently 512KiB. With the last word 
(reset vector of the ppc4xx) located at 0x.fffc. So we need to 
include this dtb into the image this way:


0xfff8. U-Boot code / text etc
...
dtb
0x.fffc reset vector

Looking for the current options shows that perhaps CONFIG_OF_EMBED seems 
to be exactly what we are need. I'll got it working on Canyonlands after 
a bit of debugging. I'll post the necessary small patches soon...


Thanks,
Stefan

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


[U-Boot] [PATCH] fix ARM DCC support for ARMv7 based cores (e.g. CortexA)

2015-01-26 Thread Alexander Merkle
Signed-off-by: Alexander Merkle 
---

 drivers/serial/arm_dcc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/arm_dcc.c b/drivers/serial/arm_dcc.c
index 5dfb02f..e37 100644
--- a/drivers/serial/arm_dcc.c
+++ b/drivers/serial/arm_dcc.c
@@ -29,9 +29,9 @@
 #include 
 #include 
 
-#if defined(CONFIG_CPU_V6)
+#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_V7)
 /*
- * ARMV6
+ * ARMV6 & ARMV7
  */
 #define DCC_RBIT   (1 << 30)
 #define DCC_WBIT   (1 << 29)
-- 
2.1.4

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


[U-Boot] [PATCH 0/1] fix ARM DCC support for ARMv7 based cores (e.g. CortexA)

2015-01-26 Thread Alexander Merkle

arm_dcc.c supported ARMv4 (ARM7) to ARMv6 (ARM11) correctly. All recent
CortexA/ARMv7 based cores share the mrc/mcr coprocessor calls of ARMv6.
Due to the missing #ifdef the ARM7/ARMv4 calls are used as soon as
CONFIG_CPU_V7 is defined. This results in an undefined instruction exception.


Alexander Merkle (1):
  fix ARM DCC support for ARMv7 based cores (e.g. CortexA)

 drivers/serial/arm_dcc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.1.4

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


Re: [U-Boot] [PATCH 12/19] powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards

2015-01-26 Thread Simon Glass
Hi Stefan,

On 26 January 2015 at 06:17, Stefan Roese  wrote:
> On 15.12.2014 15:19, Simon Glass wrote:
>>
>> Enable CONFIG_OF_CONTROL so that U-Boot on these three boards uses a
>> device
>> tree for its configuration.
>>
>> Signed-off-by: Simon Glass 
>
>
> This need further work on the ppc4xx platforms to get it booting from flash.
> As now the dtb is appended to the "normal" U-Boot image. And this image is
> fine-tuned to fit into currently 512KiB. With the last word (reset vector of
> the ppc4xx) located at 0x.fffc. So we need to include this dtb into the
> image this way:
>
> 0xfff8. U-Boot code / text etc
> ...
> dtb
> 0x.fffc reset vector
>
> Looking for the current options shows that perhaps CONFIG_OF_EMBED seems to
> be exactly what we are need. I'll got it working on Canyonlands after a bit
> of debugging. I'll post the necessary small patches soon...

Sounds good, thanks!

It almost feels like you should have a mkimage image for this, to
create a 512KB blob from u-boot.bin and u-boot.dtb. There must be
linker magic to make this all hold together. But yes the embed option
will build it in, so avoiding that.

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


Re: [U-Boot] [PATCH 15/19] dm: powerpc: ppc4xx: Move glacier to use driver model for serial

2015-01-26 Thread Simon Glass
Hi Stefan,

On 26 January 2015 at 02:35, Stefan Roese  wrote:
> On 26.01.2015 10:23, Stefan Roese wrote:
>>>
>>> diff --git a/board/amcc/canyonlands/Kconfig
>>> b/board/amcc/canyonlands/Kconfig
>>> index 0fc6877..cbc5ff9 100644
>>> --- a/board/amcc/canyonlands/Kconfig
>>> +++ b/board/amcc/canyonlands/Kconfig
>>> @@ -29,4 +29,13 @@ config ARCHES
>>>
>>>endchoice
>>>
>>> +config DM
>>> +   default y
>>> +
>>> +config DM_SERIAL
>>> +   default y
>>> +
>>> +config SYS_MALLOC_F_LEN
>>> +   default 0x400
>>> +
>>
>>
>> Hmmm. This does not seem to work. With your patch series applied on
>> current top-of-tree I get this error (for glacier_ramboot or
>> canyonlands):
>>
>> $ make -s -j10
>> board/amcc/canyonlands/Kconfig:38:warning: config symbol defined without
>> type
>> drivers/serial/serial-uclass.c:29:2: error: #error "Serial is required
>> before relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work"
>> make[1]: *** [drivers/serial/serial-uclass.o] Error 1
>>
>> Somehow the CONFIG_SYS_MALLOC_F_LEN define is not available in the
>> .config used. Do you have any idea why it might be missing?
>
>
> Okay. Found it. Its the missing type here. I'll send some follow-up patches
> once I have all tested on canyonlands here.

OK good. Also see u-boot-dm branch ppc-working if you need more context.

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


[U-Boot] [PATCH 4/4] powerpc: ppc4xx: Enable CONFIG_DISPLAY_BOARDINFO

2015-01-26 Thread Stefan Roese
This also displays the "Board:" line in the bootup text with the
generic board support code.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
 board/amcc/canyonlands/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig
index 97df3f8..3dc76ae 100644
--- a/board/amcc/canyonlands/Kconfig
+++ b/board/amcc/canyonlands/Kconfig
@@ -29,6 +29,10 @@ config ARCHES
 
 endchoice
 
+config DISPLAY_BOARDINFO
+   bool
+   default y
+
 config DM
default y
 
-- 
2.2.2

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


[U-Boot] [PATCH 3/4] powerpc: ppc4xx: Add defaults for DT based booting to really work

2015-01-26 Thread Stefan Roese
These additional nodes need to be provided to get U-Boot to boot correctly
on the Canyonlands / Glacier board:

- chosen path to the console-uart
- reg-shift set to 0 in the uart device nodes

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
 arch/powerpc/dts/canyonlands.dts | 6 ++
 arch/powerpc/dts/glacier.dts | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/powerpc/dts/canyonlands.dts b/arch/powerpc/dts/canyonlands.dts
index 2ec9762..0a2f5d7 100644
--- a/arch/powerpc/dts/canyonlands.dts
+++ b/arch/powerpc/dts/canyonlands.dts
@@ -22,6 +22,10 @@
serial1 = &UART1;
};
 
+   chosen {
+   stdout-path = &UART0;
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -280,6 +284,7 @@
 
UART0: serial@ef600300 {
device_type = "serial";
+   reg-shift = <0>;
compatible = "ns16550";
reg = <0xef600300 0x0008>;
virtual-reg = <0xef600300>;
@@ -291,6 +296,7 @@
 
UART1: serial@ef600400 {
device_type = "serial";
+   reg-shift = <0>;
compatible = "ns16550";
reg = <0xef600400 0x0008>;
virtual-reg = <0xef600400>;
diff --git a/arch/powerpc/dts/glacier.dts b/arch/powerpc/dts/glacier.dts
index 3e7ce2c..bb4e819 100644
--- a/arch/powerpc/dts/glacier.dts
+++ b/arch/powerpc/dts/glacier.dts
@@ -251,6 +251,7 @@
 
UART1: serial@ef600400 {
device_type = "serial";
+   reg-shift = <0>;
compatible = "ns16550";
reg = <0xef600400 0x0008>;
virtual-reg = <0xef600400>;
@@ -262,6 +263,7 @@
 
UART2: serial@ef600500 {
device_type = "serial";
+   reg-shift = <0>;
compatible = "ns16550";
reg = <0xef600500 0x0008>;
virtual-reg = <0xef600500>;
@@ -273,6 +275,7 @@
 
UART3: serial@ef600600 {
device_type = "serial";
+   reg-shift = <0>;
compatible = "ns16550";
reg = <0xef600600 0x0008>;
virtual-reg = <0xef600600>;
-- 
2.2.2

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


[U-Boot] [PATCH 1/4] powerpc: ppc4xx: Add missing type for SYS_MALLOC_F_LEN in Kconfig

2015-01-26 Thread Stefan Roese
Otherwise this symbol will not be created in the .config.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
 board/amcc/canyonlands/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/amcc/canyonlands/Kconfig b/board/amcc/canyonlands/Kconfig
index bfdf17a..97df3f8 100644
--- a/board/amcc/canyonlands/Kconfig
+++ b/board/amcc/canyonlands/Kconfig
@@ -36,6 +36,7 @@ config DM_SERIAL
default y
 
 config SYS_MALLOC_F_LEN
+   hex "Size of the malloc() pool for use before relocation."
default 0x400
 
 config DEBUG_UART_BASE
-- 
2.2.2

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


[U-Boot] [PATCH 2/4] powerpc: ppc4xx: Change from OF_SEPARATE to OF_EMBED

2015-01-26 Thread Stefan Roese
This is necessary, as ppc4xx has the reset vector located at the end
of the U-Boot image. This needs to be flashed to the end of the NOR
flash. Adding the dtb to the main U-Boot image will break booting
on ppc4xx. This patch now embeds the dtb in the U-Boot image instead.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
 configs/canyonlands_defconfig | 2 +-
 configs/glacier_defconfig | 2 +-
 configs/glacier_ramboot_defconfig | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/canyonlands_defconfig b/configs/canyonlands_defconfig
index 6f6cf14..44d4fbd 100644
--- a/configs/canyonlands_defconfig
+++ b/configs/canyonlands_defconfig
@@ -4,4 +4,4 @@ CONFIG_TARGET_CANYONLANDS=y
 CONFIG_CANYONLANDS=y
 CONFIG_DEFAULT_DEVICE_TREE="canyonlands"
 CONFIG_OF_CONTROL=y
-CONFIG_OF_SEPARATE=y
+CONFIG_OF_EMBED=y
diff --git a/configs/glacier_defconfig b/configs/glacier_defconfig
index e67fa32..d318f82 100644
--- a/configs/glacier_defconfig
+++ b/configs/glacier_defconfig
@@ -4,4 +4,4 @@ CONFIG_TARGET_CANYONLANDS=y
 CONFIG_GLACIER=y
 CONFIG_DEFAULT_DEVICE_TREE="glacier"
 CONFIG_OF_CONTROL=y
-CONFIG_OF_SEPARATE=y
+CONFIG_OF_EMBED=y
diff --git a/configs/glacier_ramboot_defconfig 
b/configs/glacier_ramboot_defconfig
index e5b402e..f8363b2 100644
--- a/configs/glacier_ramboot_defconfig
+++ b/configs/glacier_ramboot_defconfig
@@ -5,4 +5,4 @@ CONFIG_TARGET_CANYONLANDS=y
 CONFIG_GLACIER=y
 CONFIG_DEFAULT_DEVICE_TREE="glacier"
 CONFIG_OF_CONTROL=y
-CONFIG_OF_SEPARATE=y
+CONFIG_OF_EMBED=y
-- 
2.2.2

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


Re: [U-Boot] [PATCH v3 4/4] dm:gpio:mxc add DT support

2015-01-26 Thread Simon Glass
Hi Peng,

On 24 January 2015 at 07:34, Peng Fan  wrote:
> Hi Simon,
>
>
> On 1/23/2015 5:26 AM, Simon Glass wrote:
>>
>> Hi Peng,
>>
>> On 21 January 2015 at 04:09, Peng Fan  wrote:
>>>
>>> This patch add DT support for mxc gpio driver.
>>>
>>> There are one place using CONFIG_OF_CONTROL macro.
>>> 1. The U_BOOT_DEVICES and mxc_plat array are complied out. To DT,
>>> platdata is alloced using calloc, so there is no need to use
>>> mxc_plat.
>>>
>>> The following situations are tested, and all work fine:
>>> 1. with DM, without DT
>>> 2. with DM and DT
>>> 3. without DM
>>> Since device tree has not been upstreamed, if want to test this patch.
>>> The followings need to be done.
>>>   + pieces of code does not gpio_request when using gpio_direction_xxx
>>> and
>>> etc, need to request gpio.
>>>   + move the gpio settings from board_early_init_f to board_init
>>>   + define CONFIG_DM ,CONFIG_DM_GPIO and CONFIG_OF_CONTROL
>>>   + Add device tree file and do related configuration in
>>> `make ARCH=arm menuconfig`
>>> These will be done in future patches by step.
>>>
>>> Signed-off-by: Peng Fan 
>>> ---
>>>   drivers/gpio/mxc_gpio.c | 69
>>> +
>>>   1 file changed, 52 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/drivers/gpio/mxc_gpio.c b/drivers/gpio/mxc_gpio.c
>>> index c52dd19..0766b78 100644
>>> --- a/drivers/gpio/mxc_gpio.c
>>> +++ b/drivers/gpio/mxc_gpio.c
>>> @@ -151,6 +151,9 @@ int gpio_direction_output(unsigned gpio, int value)
>>>   #endif
>>>
>>>   #ifdef CONFIG_DM_GPIO
>>> +#include 
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>>   static int mxc_gpio_is_output(struct gpio_regs *regs, int offset)
>>>   {
>>>  u32 val;
>>> @@ -259,23 +262,6 @@ static const struct dm_gpio_ops gpio_mxc_ops = {
>>>  .get_function   = mxc_gpio_get_function,
>>>   };
>>>
>>> -static const struct mxc_gpio_plat mxc_plat[] = {
>>> -   { 0, (struct gpio_regs *)GPIO1_BASE_ADDR },
>>> -   { 1, (struct gpio_regs *)GPIO2_BASE_ADDR },
>>> -   { 2, (struct gpio_regs *)GPIO3_BASE_ADDR },
>>> -#if defined(CONFIG_MX25) || defined(CONFIG_MX27) || defined(CONFIG_MX51)
>>> || \
>>> -   defined(CONFIG_MX53) || defined(CONFIG_MX6)
>>> -   { 3, (struct gpio_regs *)GPIO4_BASE_ADDR },
>>> -#endif
>>> -#if defined(CONFIG_MX27) || defined(CONFIG_MX53) || defined(CONFIG_MX6)
>>> -   { 4, (struct gpio_regs *)GPIO5_BASE_ADDR },
>>> -   { 5, (struct gpio_regs *)GPIO6_BASE_ADDR },
>>> -#endif
>>> -#if defined(CONFIG_MX53) || defined(CONFIG_MX6)
>>> -   { 6, (struct gpio_regs *)GPIO7_BASE_ADDR },
>>> -#endif
>>> -};
>>> -
>>>   static int mxc_gpio_probe(struct udevice *dev)
>>>   {
>>>  struct mxc_bank_info *bank = dev_get_priv(dev);
>>> @@ -296,12 +282,60 @@ static int mxc_gpio_probe(struct udevice *dev)
>>>  return 0;
>>>   }
>>>
>>> +static int mxc_gpio_bind(struct udevice *device)
>>
>> s/device/dev/ as that is the convention.
>
> Will fix this.
>>
>>
>>> +{
>>> +   struct mxc_gpio_plat *plat = device->platdata;
>>> +   struct gpio_regs *regs;
>>> +
>>> +   if (plat)
>>> +   return 0;
>>
>> Please add a comment as to why.
>
> Ok.
>>
>>
>>> +
>>> +   regs = dev_get_addr(device);
>>> +   if (!regs)
>>> +   return -ENXIO;
>>
>> -ENODEV I think?
>
> Yeah. Right.
>>>
>>> +
>>> +   plat = calloc(1, sizeof(*plat));
>>> +   if (!plat)
>>> +   return -ENOMEM;
>>
>> Can you use the auto-alloc feature instead? Trying to keep memory
>> allocations out of drivers unless it is for buffers, etc.
>
> I want the DM code can support DT and no DT. To no DT, platdata is defined
> in U_BOOT_DEVICES.
> If using auto-alloc feature, but DT is not supported, is it conflict with
> platdata in U_BOOT_DEVICES?

Yes it will. But please add a TODO in the code to remove this when
every board is converted to driver model and you don't need this.

>>
>>
>>> +
>>> +   plat->regs = regs;
>>> +   plat->bank_index = device->req_seq;
>>
>> Why store this? You can access it anytime using the device pointer.
>
> To no DT, bank_index is statically intialized  in mxc_plat array. I do not
> want to introudce `#ifdef CONFIG_OF_CONTROL` in probe function and introudce
> `if (dev->of_offset == -1)`, so
> store it to bank_index.
> To no DT, `if(plat) return 0;` will return. So plat->bank_index =
> device->req_seq will only effects for DT.
> Just want to support DT and no DT.

OK  I think I understand.

>>
>>
>>> +   device->platdata = plat;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +static const struct udevice_id mxc_gpio_ids[] = {
>>> +   { .compatible = "fsl,imx35-gpio" },
>>> +   { }
>>> +};
>>> +
>>>   U_BOOT_DRIVER(gpio_mxc) = {
>>>  .name   = "gpio_mxc",
>>>  .id = UCLASS_GPIO,
>>>  .ops= &gpio_mxc_ops,
>>>  .probe  = mxc_gpio_probe,
>>>  .priv_auto_alloc_size = sizeof(struct mxc_bank_info),
>>> +   .of_match = mx

Re: [U-Boot] [PATCH 15/19] dm: powerpc: ppc4xx: Move glacier to use driver model for serial

2015-01-26 Thread Stefan Roese

Hi Simon,

On 26.01.2015 14:33, Simon Glass wrote:

Hmmm. This does not seem to work. With your patch series applied on
current top-of-tree I get this error (for glacier_ramboot or
canyonlands):

$ make -s -j10
board/amcc/canyonlands/Kconfig:38:warning: config symbol defined without
type
drivers/serial/serial-uclass.c:29:2: error: #error "Serial is required
before relocation - define CONFIG_SYS_MALLOC_F_LEN to make this work"
make[1]: *** [drivers/serial/serial-uclass.o] Error 1

Somehow the CONFIG_SYS_MALLOC_F_LEN define is not available in the
.config used. Do you have any idea why it might be missing?



Okay. Found it. Its the missing type here. I'll send some follow-up patches
once I have all tested on canyonlands here.


OK good. Also see u-boot-dm branch ppc-working if you need more context.


I just posted 4 patches that are needed on top of your patchset from mid 
December. Please either include them in your next patchset or fold them 
into your patches. With these patches on top I can boot Canyonlands from 
NOR flash. So for the complete patch series:


Tested-by: Stefan Roese 

Thanks,
Stefan

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


Re: [U-Boot] [PATCH 01/10][v6] rsa: Split the rsa-verify to separate the modular exponentiation

2015-01-26 Thread Simon Glass
On 23 January 2015 at 03:31, Ruchika Gupta  wrote:
> Public exponentiation which is required in rsa verify functionality is
> tightly integrated with verification code in rsa_verify.c. The patch
> splits the file into twp separating the modular exponentiation.
>
> 1. rsa-verify.c
> - The file parses device tree keys node to fill a keyprop structure.
> The keyprop structure can then be converted to implementation specific
> format.
> (struct rsa_pub_key for sw implementation)
> - The parsed device tree node is then passed to a generic rsa_mod_exp
> function.
>
> 2. rsa-mod-exp.c
> Move the software specific functions related to modular exponentiation
> from rsa-verify.c to this file.
>
> Signed-off-by: Ruchika Gupta 
> CC: Simon Glass 
> ---
> Changes in v6:
> No changes
>
> Changes in v5:
> Reverted change in rsa_mod_exp_sw function to add pointer to output length
> Addressed other comments by Simon
>
> Changes in v4:
> Modified rsa_mod_exp_sw function to add pointer to output length
>
> Changes in v3:
> Kconfig moved to separate patch. This patch just splits the file now
>
> Changes in v2:
> Addressed few of Simon Glass's comments:
> - Kconfig option added for RSA
> - Comments added for new keyprop struct
>
>  include/u-boot/rsa-mod-exp.h |  43 ++
>  lib/rsa/Makefile |   2 +-
>  lib/rsa/rsa-mod-exp.c| 303 +++
>  lib/rsa/rsa-verify.c | 329 
> ---
>  tools/Makefile   |   3 +-
>  5 files changed, 404 insertions(+), 276 deletions(-)
>  create mode 100644 include/u-boot/rsa-mod-exp.h
>  create mode 100644 lib/rsa/rsa-mod-exp.c

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 06/10][v6] DM: crypto/fsl - Add Freescale rsa DM driver

2015-01-26 Thread Simon Glass
On 23 January 2015 at 03:31, Ruchika Gupta  wrote:
> Driver added for RSA Modular Exponentiation using Freescale Hardware
> Accelerator CAAM. The driver uses UCLASS_MOD_EXP
>
> Signed-off-by: Ruchika Gupta 
> CC: Simon Glass 
> ---
> Changes in v6:
> No Changes
>
> Changes in v5:
> Reverted mod_exp not to use output length
>
> Changes in v4:
> Modified for the changes in op function of rsa class mod_exp
>
> Changes in v3:
> Moved to integrate with RSA UCLASS
>
>  drivers/crypto/Kconfig|  1 +
>  drivers/crypto/fsl/Kconfig|  6 +
>  drivers/crypto/fsl/Makefile   |  1 +
>  drivers/crypto/fsl/fsl_rsa.c  | 60 
> +++
>  drivers/crypto/fsl/jobdesc.c  | 28 
>  drivers/crypto/fsl/jobdesc.h  |  5 
>  drivers/crypto/fsl/rsa_caam.h | 28 
>  7 files changed, 129 insertions(+)
>  create mode 100644 drivers/crypto/fsl/Kconfig
>  create mode 100644 drivers/crypto/fsl/fsl_rsa.c
>  create mode 100644 drivers/crypto/fsl/rsa_caam.h

I don't see what you want inline functions in jobdesc.h, but I suppose
that is your business.

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 03/10][v6] DM: crypto/rsa_mod_exp: Add rsa Modular Exponentiation DM driver

2015-01-26 Thread Simon Glass
Hi Ruchika,

On 23 January 2015 at 03:31, Ruchika Gupta  wrote:
> Add a new rsa uclass for performing modular exponentiation and implement
> the software driver basing on this uclass.
>
> Signed-off-by: Ruchika Gupta 
> CC: Simon Glass 
> ---
> Changes in v6:
> No Changes
>
> Changes in v5:
> Changed UCLASS name to UCLASS_MOD_EXP
>
> Changes in v4:
> Removed Kconfig option for DM_RSA
> Corrected driver name for sw rsa driver
> Updated the rsa_mod_exp operation to have output length
>
> Changes in v3:
> New patch with driver model for RSA UCLASS
>
>  drivers/crypto/Makefile |  1 +
>  drivers/crypto/rsa_mod_exp/Kconfig  |  5 
>  drivers/crypto/rsa_mod_exp/Makefile |  7 ++
>  drivers/crypto/rsa_mod_exp/mod_exp_sw.c | 39 
> +
>  drivers/crypto/rsa_mod_exp/mod_exp_uclass.c | 31 +++
>  include/dm/uclass-id.h  |  1 +
>  include/u-boot/rsa-mod-exp.h| 34 -
>  7 files changed, 117 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/crypto/rsa_mod_exp/Kconfig
>  create mode 100644 drivers/crypto/rsa_mod_exp/Makefile
>  create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_sw.c
>  create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_uclass.c

Acked-by: Simon Glass 

Just in case there is a v7:

> +++ b/drivers/crypto/rsa_mod_exp/mod_exp_uclass.c
> @@ -0,0 +1,31 @@
> +/*
> + * (C) Copyright 2014 Freescale Semiconductor, Inc
> + * Author: Ruchika Gupta 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +

You can trim headers here.

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


Re: [U-Boot] [PATCH 12/19] powerpc: ppc4xx: Use CONFIG_OF_CONTROL for canyonlands boards

2015-01-26 Thread Bin Meng
Hi Simon,

On Mon, Jan 26, 2015 at 9:31 PM, Simon Glass  wrote:
> Hi Stefan,
>
> On 26 January 2015 at 06:17, Stefan Roese  wrote:
>> On 15.12.2014 15:19, Simon Glass wrote:
>>>
>>> Enable CONFIG_OF_CONTROL so that U-Boot on these three boards uses a
>>> device
>>> tree for its configuration.
>>>
>>> Signed-off-by: Simon Glass 
>>
>>
>> This need further work on the ppc4xx platforms to get it booting from flash.
>> As now the dtb is appended to the "normal" U-Boot image. And this image is
>> fine-tuned to fit into currently 512KiB. With the last word (reset vector of
>> the ppc4xx) located at 0x.fffc. So we need to include this dtb into the
>> image this way:
>>
>> 0xfff8. U-Boot code / text etc
>> ...
>> dtb
>> 0x.fffc reset vector
>>
>> Looking for the current options shows that perhaps CONFIG_OF_EMBED seems to
>> be exactly what we are need. I'll got it working on Canyonlands after a bit
>> of debugging. I'll post the necessary small patches soon...
>
> Sounds good, thanks!
>

We need do the same for Freescale BookE powerpc series too.

> It almost feels like you should have a mkimage image for this, to
> create a 512KB blob from u-boot.bin and u-boot.dtb. There must be
> linker magic to make this all hold together. But yes the embed option
> will build it in, so avoiding that.
>

Or maybe we can extend x86 solution (like ifdtool) to non-x86
architectures like BookE powerpc?

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


Re: [U-Boot] [PATCH 09/10][v6] Use hash.c in mkimage

2015-01-26 Thread Simon Glass
On 23 January 2015 at 03:31, Ruchika Gupta  wrote:
> Signed-off-by: Ruchika Gupta 
> CC: Simon Glass 
> ---
> Changes in v6:
> Fixed compilation error in this file for tools when FIT_SIGNATURE not enabled
>
> Changes in v5:
> New patch based on WIP patch by Simon.
>
>  common/hash.c  | 81 
> +-
>  include/hash.h | 34 
>  tools/Makefile |  1 +
>  3 files changed, 65 insertions(+), 51 deletions(-)

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 10/10][v6] rsa: Use checksum algorithms from struct hash_algo

2015-01-26 Thread Simon Glass
On 23 January 2015 at 03:31, Ruchika Gupta  wrote:
> Currently the hash functions used in RSA are called directly from the sha1
> and sha256 libraries. Change the RSA checksum library to use the progressive
> hash API's registered with struct hash_algo. This will allow the checksum
> library to use the hardware accelerated progressive hash API's once available.
>
> Signed-off-by: Ruchika Gupta 
> CC: Simon Glass 
> ---
> Changes in v6:
> Removed changes in ls1021aqds.h accidently included in this patch
>
> Changes in v5:
> Both tools and uboot use the same code in rsa-checksum.c
>
> Changes in v4:
> No changes in this patch. Still under discussion
>
> Changes in v3:
> Modified rsa-verify to check for return from checksum function
>
> Changes in v2:
> Added generic function hash_calculate. Pass an additional
> argument as name of algorithm.
>
>  common/image-sig.c|  6 +++---
>  include/image.h   |  5 +++--
>  include/u-boot/rsa-checksum.h | 17 +++
>  lib/rsa/rsa-checksum.c| 50 
> ++-
>  lib/rsa/rsa-verify.c  |  7 +-
>  5 files changed, 55 insertions(+), 30 deletions(-)

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 08/10][v6] hash: Add function to find hash_algo struct with progressive hash

2015-01-26 Thread Simon Glass
On 23 January 2015 at 03:31, Ruchika Gupta  wrote:
> The hash_algo structure has some implementations in which progressive hash
> API's are not defined. These are basically the hardware based implementations
> of SHA. An API is added to find the algo which has progressive hash API's
> defined. This can then be integrated with RSA checksum library which uses
> Progressive Hash API's.
>
> Signed-off-by: Ruchika Gupta 
> CC: Simon Glass 
> ---
> Changes in v6:
> No Changes
>
> Changes in v5:
> None
>
> Changes in v4:
> Few cosmetic changes. Currently I have not replaced CONFIG_SHA1  with 
> CONFIG_CMD_SHA1SUM.
> Waiting for reply from Simon and Denx for the same.
>
> Changes in v3 :
> Corrected ifdef for SHA1
>
> Changes in v2 :
> Added commit message
>
>  common/hash.c  | 33 -
>  include/hash.h | 14 ++
>  2 files changed, 38 insertions(+), 9 deletions(-)

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 05/10][v6] lib/rsa: Modify rsa to use DM driver

2015-01-26 Thread Simon Glass
On 23 January 2015 at 03:31, Ruchika Gupta  wrote:
> Modify rsa_verify to use the rsa driver of DM library .The tools
> will continue to use the same RSA sw library.
>
> CONFIG_RSA is now dependent on CONFIG_DM. All configurations which
> enable FIT based signatures have been modified to enable CONFIG_DM
> by default.
>
> Signed-off-by: Ruchika Gupta 
> CC: Simon Glass 
> ---
> Changes in v6:
> No Changes
>
> Changes in v5:
> Added signature option in am335x_boneblack_vboot_defconfig
> Made changes in rsa-verify.c as suggested by Simon
>
> Changes in v4:
> Make CONFIG_RSA always depenedent on Driver Model.
> Add CONFIG_DM in defconfigs of the platforms which enable CONFIG_FIT_SIGNATURE
>
> Changes in v3:
> New patch
>
>  README   |  7 ++-
>  configs/am335x_boneblack_vboot_defconfig |  4 
>  configs/ids8313_defconfig|  1 +
>  configs/sandbox_defconfig|  1 +
>  configs/zynq_microzed_defconfig  |  1 +
>  configs/zynq_zc70x_defconfig |  1 +
>  configs/zynq_zc770_xm010_defconfig   |  1 +
>  configs/zynq_zc770_xm012_defconfig   |  1 +
>  configs/zynq_zc770_xm013_defconfig   |  1 +
>  configs/zynq_zed_defconfig   |  1 +
>  configs/zynq_zybo_defconfig  |  1 +
>  include/configs/am335x_evm.h |  6 ++
>  include/configs/sandbox.h|  1 -
>  lib/rsa/rsa-verify.c | 14 ++
>  14 files changed, 35 insertions(+), 6 deletions(-)
>

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 07/10][v6] lib/rsa: Add Kconfig for devices supporting RSA Modular Exponentiation

2015-01-26 Thread Simon Glass
On 23 January 2015 at 03:31, Ruchika Gupta  wrote:
> Kconfig option added for devices which support RSA Verification.
> 1. RSA_SOFTWARE_EXP
> Enables driver for supporting RSA Modular Exponentiation in Software
> 2. RSA_FREESCALE_EXP
> Enables driver for supporting RSA Modular Exponentiation using Freescale 
> specific
> driver
>
> The above drivers use RSA uclass
>
> Signed-off-by: Ruchika Gupta 
> CC: Simon Glass 
> ---
> Changes in v6:
> No Changes
>
> Changes in v5:
> No changes
>
> Changes in v4:
> Introduced 2 options when CONFIG_RSA is selected:
> RSA_SOFTWARE_EXP
> RSA_FREESCALE_EXP
>
> Removed RSA_HW. Changes the name pf RSA_SW to RSA_SOFTWARE_EXP
>
> Changes in v3:
> New patch
>  lib/Kconfig |  7 +--
>  lib/rsa/Kconfig | 28 
>  2 files changed, 29 insertions(+), 6 deletions(-)
>  create mode 100644 lib/rsa/Kconfig

Acked-by: Simon Glass 

(note the duplicated line in your Kconfig if you issue a new version,
but I can clean that up when applying it)


+++ b/lib/rsa/Kconfig
> @@ -0,0 +1,28 @@
> +config RSA
> +   bool "Use RSA Library"
> +   select RSA_FREESCALE_EXP if FSL_CAAM
> +   select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP
> +   help
> + RSA support. This enables the RSA algorithm used for FIT image
> + verification in U-Boot.
> + See doc/uImage.FIT/signature.txt for more details.
> + See doc/uImage.FIT/signature.txt for more details.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 03/10][v6] DM: crypto/rsa_mod_exp: Add rsa Modular Exponentiation DM driver

2015-01-26 Thread Simon Glass
Hi Ruchika,

On 26 January 2015 at 06:39, Simon Glass  wrote:
> Hi Ruchika,
>
> On 23 January 2015 at 03:31, Ruchika Gupta  
> wrote:
>> Add a new rsa uclass for performing modular exponentiation and implement
>> the software driver basing on this uclass.
>>
>> Signed-off-by: Ruchika Gupta 
>> CC: Simon Glass 
>> ---
>> Changes in v6:
>> No Changes
>>
>> Changes in v5:
>> Changed UCLASS name to UCLASS_MOD_EXP
>>
>> Changes in v4:
>> Removed Kconfig option for DM_RSA
>> Corrected driver name for sw rsa driver
>> Updated the rsa_mod_exp operation to have output length
>>
>> Changes in v3:
>> New patch with driver model for RSA UCLASS
>>
>>  drivers/crypto/Makefile |  1 +
>>  drivers/crypto/rsa_mod_exp/Kconfig  |  5 
>>  drivers/crypto/rsa_mod_exp/Makefile |  7 ++
>>  drivers/crypto/rsa_mod_exp/mod_exp_sw.c | 39 
>> +
>>  drivers/crypto/rsa_mod_exp/mod_exp_uclass.c | 31 +++
>>  include/dm/uclass-id.h  |  1 +
>>  include/u-boot/rsa-mod-exp.h| 34 -
>>  7 files changed, 117 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/crypto/rsa_mod_exp/Kconfig
>>  create mode 100644 drivers/crypto/rsa_mod_exp/Makefile
>>  create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_sw.c
>>  create mode 100644 drivers/crypto/rsa_mod_exp/mod_exp_uclass.c
>
> Acked-by: Simon Glass 
>
> Just in case there is a v7:
>
>> +++ b/drivers/crypto/rsa_mod_exp/mod_exp_uclass.c
>> @@ -0,0 +1,31 @@
>> +/*
>> + * (C) Copyright 2014 Freescale Semiconductor, Inc
>> + * Author: Ruchika Gupta 
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>
> You can trim headers here.

There are a few nits I mentioned in your patches.

To avoid further delay and testing I would like to pick these patches
up as is, but if you like you could send a follow-on patch.

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


[U-Boot] [PATCH v5] Export redesign

2015-01-26 Thread Simon Glass
From: Martin Dorwig 

this is an atempt to make the export of functions typesafe.
I replaced the jumptable void ** by a struct (jt_funcs) with function pointers.
The EXPORT_FUNC macro now has 3 fixed parameters and one
variadic parameter
The first is the name of the exported function,
the rest of the parameters are used to format a functionpointer
in the jumptable,

the EXPORT_FUNC macros are expanded three times,
1. to declare the members of the struct
2. to initialize the structmember pointers
3. to call the functions in stubs.c

Signed-off-by: Martin Dorwig 
Acked-by: Simon Glass 

Signed-off-by: Simon Glass 
(resending to the list since my tweaks are not quite trivial)

---

Changes in v5:
- Update to deal with I2C moving to driver model

 arch/blackfin/cpu/cpu.c   |  3 +-
 board/BuS/eb_cpux9k2/cpux9k2.c|  2 +-
 common/cmd_load.c |  2 +-
 common/console.c  | 20 
 common/exports.c  | 29 ++--
 doc/README.standalone | 41 +++-
 examples/standalone/stubs.c   | 64 +
 include/_exports.h| 99 +++
 include/asm-generic/global_data.h |  2 +-
 include/exports.h | 20 
 10 files changed, 162 insertions(+), 120 deletions(-)

diff --git a/arch/blackfin/cpu/cpu.c b/arch/blackfin/cpu/cpu.c
index b7f1188..91aa5cc 100644
--- a/arch/blackfin/cpu/cpu.c
+++ b/arch/blackfin/cpu/cpu.c
@@ -24,6 +24,7 @@
 
 #include "cpu.h"
 #include "initcode.h"
+#include "exports.h"
 
 ulong bfin_poweron_retx;
 DECLARE_GLOBAL_DATA_PTR;
@@ -121,7 +122,7 @@ static void display_global_data(void)
printf(" |-ram_size: %lx\n", gd->ram_size);
printf(" |-env_addr: %lx\n", gd->env_addr);
printf(" |-env_valid: %lx\n", gd->env_valid);
-   printf(" |-jt(%p): %p\n", gd->jt, *(gd->jt));
+   printf(" |-jt(%p): %p\n", gd->jt, gd->jt->get_version);
printf(" \\-bd: %p\n", gd->bd);
printf("   |-bi_boot_params: %lx\n", bd->bi_boot_params);
printf("   |-bi_memstart: %lx\n", bd->bi_memstart);
diff --git a/board/BuS/eb_cpux9k2/cpux9k2.c b/board/BuS/eb_cpux9k2/cpux9k2.c
index 5e4778e..76ad7c4 100644
--- a/board/BuS/eb_cpux9k2/cpux9k2.c
+++ b/board/BuS/eb_cpux9k2/cpux9k2.c
@@ -98,7 +98,7 @@ int misc_init_r(void)
puts("Error: invalid MAC at EEPROM\n");
}
}
-   gd->jt[XF_do_reset] = (void *) do_reset;
+   gd->jt->do_reset = do_reset;
 
 #ifdef CONFIG_STATUS_LED
status_led_set(STATUS_LED_BOOT, STATUS_LED_BLINKING);
diff --git a/common/cmd_load.c b/common/cmd_load.c
index f6e522c..d043e6d 100644
--- a/common/cmd_load.c
+++ b/common/cmd_load.c
@@ -222,7 +222,7 @@ static int read_record(char *buf, ulong len)
}
 
/* Check for the console hangup (if any different from serial) */
-   if (gd->jt[XF_getc] != getc) {
+   if (gd->jt->getc != getc) {
if (ctrlc()) {
return (-1);
}
diff --git a/common/console.c b/common/console.c
index fc1963b..3f25e76 100644
--- a/common/console.c
+++ b/common/console.c
@@ -125,13 +125,13 @@ static int console_setfile(int file, struct stdio_dev * 
dev)
 */
switch (file) {
case stdin:
-   gd->jt[XF_getc] = getc;
-   gd->jt[XF_tstc] = tstc;
+   gd->jt->getc = getc;
+   gd->jt->tstc = tstc;
break;
case stdout:
-   gd->jt[XF_putc] = putc;
-   gd->jt[XF_puts] = puts;
-   gd->jt[XF_printf] = printf;
+   gd->jt->putc  = putc;
+   gd->jt->puts  = puts;
+   gd->jt->printf = printf;
break;
}
break;
@@ -758,11 +758,11 @@ int console_init_r(void)
 #endif
 
/* set default handlers at first */
-   gd->jt[XF_getc] = serial_getc;
-   gd->jt[XF_tstc] = serial_tstc;
-   gd->jt[XF_putc] = serial_putc;
-   gd->jt[XF_puts] = serial_puts;
-   gd->jt[XF_printf] = serial_printf;
+   gd->jt->getc  = serial_getc;
+   gd->jt->tstc  = serial_tstc;
+   gd->jt->putc  = serial_putc;
+   gd->jt->puts  = serial_puts;
+   gd->jt->printf = serial_printf;
 
/* stdin stdout and stderr are in environment */
/* scan for it */
diff --git a/common/exports.c b/common/exports.c
index 459e18c..333107c 100644
--- a/common/exports.c
+++ b/common/exports.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -13,34 +14,10 @@ unsigned long get_version(void)
return XF_VERSION;
 }
 
-/* Reuse _exports.h with a little trickery to avoid bitrot */
-#define EXPORT_FUNC(sym) gd->jt[XF_##sym] = (void *)sym;
-
-#if !defined(CONFIG_X86) && 

Re: [U-Boot] [PATCH v5] Export redesign

2015-01-26 Thread Wolfgang Denk
Dear Simon,

In message <1422279795-3052-1-git-send-email-...@chromium.org> you wrote:
> From: Martin Dorwig 
> 
> this is an atempt to make the export of functions typesafe.
> I replaced the jumptable void ** by a struct (jt_funcs) with function 
> pointers.
> The EXPORT_FUNC macro now has 3 fixed parameters and one
> variadic parameter
> The first is the name of the exported function,
> the rest of the parameters are used to format a functionpointer
> in the jumptable,
> 
> the EXPORT_FUNC macros are expanded three times,
> 1. to declare the members of the struct
> 2. to initialize the structmember pointers
> 3. to call the functions in stubs.c
> 
> Signed-off-by: Martin Dorwig 
> Acked-by: Simon Glass 
> 
> Signed-off-by: Simon Glass 
> (resending to the list since my tweaks are not quite trivial)

Is this a 100% binary compatible change?  If not, should we not also
increment XF_VERSION ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Where people stand is not as important as which way they face.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: Add Linksprite_pcDuino3_Nano board / defconfig

2015-01-26 Thread Hans de Goede

Hi,

On 25-01-15 16:24, Adam Sampson wrote:

This is a low-cost Allwinner A20 board with Arduino-style GPIO headers;
it features 1G RAM, 4G NAND flash, 1 micro-SD, 2 USB sockets, 1 micro
USB socket for OTG and another for power in, HDMI, SATA, 5V power for
SATA devices, gigabit Ethernet, an IR receiver, 3.5mm audio out and a
MIPI camera connector.

For more details, see: http://linux-sunxi.org/LinkSprite_pcDuino3_Nano

Signed-off-by: Adam Sampson 


Thanks, I've queued this up for merging in u-boot-sunxi/next

Regards,

Hans



---
  board/sunxi/MAINTAINERS|5 +
  configs/Linksprite_pcDuino3_Nano_defconfig |   11 +++
  2 files changed, 16 insertions(+)
  create mode 100644 configs/Linksprite_pcDuino3_Nano_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 743e7f5..479d147 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -100,3 +100,8 @@ MELE M5 BOARD
  M:Ian Campbell 
  S:Maintained
  F:configs/Mele_M5_defconfig
+
+LINKSPRITE-PCDUINO3-NANO BOARD
+M: Adam Sampson 
+S: Maintained
+F: configs/Linksprite_pcDuino3_Nano_defconfig
diff --git a/configs/Linksprite_pcDuino3_Nano_defconfig 
b/configs/Linksprite_pcDuino3_Nano_defconfig
new file mode 100644
index 000..22435eb
--- /dev/null
+++ b/configs/Linksprite_pcDuino3_Nano_defconfig
@@ -0,0 +1,11 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPH(2),USB_EHCI"
+CONFIG_FDTFILE="sun7i-a20-pcduino3-nano.dtb"
+CONFIG_USB1_VBUS_PIN="PH11"
++S:CONFIG_ARM=y
++S:CONFIG_ARCH_SUNXI=y
++S:CONFIG_MACH_SUN7I=y
++S:CONFIG_TARGET_PCDUINO3_NANO=y
++S:CONFIG_DRAM_CLK=408
++S:CONFIG_DRAM_ZQ=122
++S:CONFIG_DRAM_EMR1=4


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


  1   2   >