date:20150531

Re: [U-Boot] [PATCH] MIPS: fix missing semicolon in cacheops.h

2015-05-31 Thread Daniel Schwierzeck



Am 30.05.2015 um 09:02 schrieb Tony Wu:
 Fix missing semicolon in cacheops.h introduced in commit
 2b8bcc5a2 (MIPS: avoid .set ISA for cache operations)
 
 Signed-off-by: Tony Wu tung7...@gmail.com
 Cc: Paul Burton paul.bur...@imgtec.com
 

applied to u-boot-mips, thanks

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

Re: [U-Boot] Booting Wandboard through USB

2015-05-31 Thread Nikolay Dimitrov


Hi guys,

Here's a proposal how to avoid changing the host boot software for the
SPL case:

- Power on
- Boot ROM announces usb device (0x15a2:0x0054 or 0x15a2:0x0054 or
0x15a2:0x0063)
- Host software uploads SPL over OTG
- Board initializes DDR
- Board initializes USB-OTG and announces again as a usb device with
slightly different PID (0x15a2:0x0055 or 0x15a2:0x0056 or
0x15a2:0x0064) or a special PID (0x15a2:0x), thus needs to
implement FSL boot protocol
- Both imx-usb-loader and mfgtool already have easy mechanism to detect
boards' by vid-pid and to sequence actions based on it. So basically
we'll just need an additional config for the host boot programs, which
need to feed the 2nd boot stage (one more file for imx-usb-loader, and
one more config section for the mfgtool), but otherwise it will be
quite straight-forward.

Overall, from the PC host this boot sequence will look like 2 boot
sequences for 2 separate usb devices (1 for SPL, 1 for u-boot.img).

Probably the most important question is how easy is to implement the
FSL boot protocol in the remaining OCRAM free space. What do you think?

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

Re: [U-Boot] [PATCH 1/2] serial_sh: Add OF support

2015-05-31 Thread Nobuhiro Iwamatsu

Hi!

015-05-21 15:31 GMT+09:00 Yoshinori Sato ys...@users.sourceforge.jp:
 Add device tree support.

 Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
 ---
  doc/device-tree-bindings/serial/sh.txt |  6 ++
  drivers/serial/serial_sh.c | 28 
  2 files changed, 34 insertions(+)
  create mode 100644 doc/device-tree-bindings/serial/sh.txt

2015-05-21 15:31 GMT+09:00 Yoshinori Sato ys...@users.sourceforge.jp:
 Add support for standard type SCI (without FIFO) port.

 Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
 ---
  doc/device-tree-bindings/serial/sh.txt | 2 +-
  drivers/serial/serial_sh.c | 8 
  2 files changed, 9 insertions(+), 1 deletion(-)


Thanks for your patch.
Sorry, your patch can not apply u-boot/master HEAD.
Could you rebase and resend this patch?

Best regards,
  Nobuhiro

2015-05-21 15:31 GMT+09:00 Yoshinori Sato ys...@users.sourceforge.jp:
 Add device tree support.

 Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
 ---
  doc/device-tree-bindings/serial/sh.txt |  6 ++
  drivers/serial/serial_sh.c | 28 
  2 files changed, 34 insertions(+)
  create mode 100644 doc/device-tree-bindings/serial/sh.txt

 diff --git a/doc/device-tree-bindings/serial/sh.txt 
 b/doc/device-tree-bindings/serial/sh.txt
 new file mode 100644
 index 000..b23b135
 --- /dev/null
 +++ b/doc/device-tree-bindings/serial/sh.txt
 @@ -0,0 +1,6 @@
 +* Renesas SCI serial interface
 +
 +Required properties:
 +- compatible: must be renesas,scif or renesas,scifa
 +- reg: exactly one register range with length
 +- clock: input clock frequency for the SCI unit
 diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
 index 8693c1e..32b2bf0 100644
 --- a/drivers/serial/serial_sh.c
 +++ b/drivers/serial/serial_sh.c
 @@ -17,6 +17,8 @@
  #include dm/platform_data/serial_sh.h
  #include serial_sh.h

 +DECLARE_GLOBAL_DATA_PTR;
 +
  #if defined(CONFIG_CPU_SH7760) || \
 defined(CONFIG_CPU_SH7780) || \
 defined(CONFIG_CPU_SH7785) || \
 @@ -201,10 +203,35 @@ static const struct dm_serial_ops sh_serial_ops = {
 .setbrg = sh_serial_setbrg,
  };

 +#ifdef CONFIG_OF_CONTROL
 +static const struct udevice_id sh_serial_id[] = {
 +   {.compatible = renesas,scif, .data = PORT_SCIF},
 +   {.compatible = renesas,scifa, .data = PORT_SCIFA},
 +   {}
 +};
 +
 +static int sh_serial_ofdata_to_platdata(struct udevice *dev)
 +{
 +   struct sh_serial_platdata *plat = dev_get_platdata(dev);
 +   fdt_addr_t addr;
 +
 +   addr = fdtdec_get_addr(gd-fdt_blob, dev-of_offset, reg);
 +   if (addr == FDT_ADDR_T_NONE)
 +   return -EINVAL;
 +
 +   plat-base = addr;
 +   plat-clk = fdtdec_get_int(gd-fdt_blob, dev-of_offset, clock, 1);
 +   plat-type = dev_get_driver_data(dev);
 +   return 0;
 +}
 +#endif
 +
  U_BOOT_DRIVER(serial_sh) = {
 .name   = serial_sh,
 .id = UCLASS_SERIAL,
 +   .of_match = of_match_ptr(sh_serial_id),
 +   .ofdata_to_platdata = of_match_ptr(sh_serial_ofdata_to_platdata),
 +   .platdata_auto_alloc_size = sizeof(struct sh_serial_platdata),
 .probe  = sh_serial_probe,
 .ops= sh_serial_ops,
 .flags  = DM_FLAG_PRE_RELOC,
 --
 2.1.4




-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Booting Wandboard through USB

2015-05-31 Thread Nikolay Dimitrov


Hi all,

On 05/30/2015 11:09 PM, Eric Nelson wrote:

On 05/30/2015 10:24 AM, Vincent Stehlé wrote:

On 05/30/2015 06:49 PM, Tom Rini wrote:
..

The second would be trying to fake things such that for
imx_usb_loader you can pass both SPL and u-boot.img, and SPL is
run, inits memory and just exists and then u-boot.img is loaded
and run, similar to how with the non-SPL case you can use the
loader to pass in u-boot.imx as well as a kernel, ramdisk, etc,
into DDR.


I wonder if we could use the i.MX6 ROM plugin[1] mechanism with u-boot
SPL, to download it through USB, have it configure the DDR and return to
the ROM, in a way that would allow us to resume downloading the second
stage u-boot through USB...

Best regards,

V.

[1] Chapter 8.8 Plugin Image of the i.MX6D/Q Reference Manual.


;) This is an even older idea:
http://lists.denx.de/pipermail/u-boot/2012-September/thread.html#13

In my earlier e-mail, I said that this was more complicated because
it involves hacking the image creation process (and perhaps some
linker scripts).

It also requires that SPL images have some form of flag telling them
not to boot, but return to the ROM boot loader after initializing DDR
(i.e. they need to optionally act like a plugin).


According to the RM, the plugin image is expected to load the actual
boot image in memory and report the start/len/ivt parameters to the
boot ROM. Then I see 2 problems:

1. It seems that at this exact point if the plugin returned success
the boot ROM will start executing the downloaded image and there's no
intent to download anything else from USB.

2. Even if there was a way for the boot ROM to download more data, the
previous communication sequence ends with jump header (in imx-usb-
loader jargon) which means we can't differentiate between boot ROM
returning for more boot data, and a fresh new boot session.

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

[U-Boot] Pull request: u-boot-sh/rmobile

2015-05-31 Thread Nobuhiro Iwamatsu

Dear Tom Rini.

Please pull u-boot-sh rmobile branch.

The following changes since commit 012681b1fa822492bb8fdc5c2dd3d24d6092e110:

  am33xx, spl, siemens: enable debug uart output again (2015-05-28
08:18:25 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-sh.git rmobile

for you to fetch changes up to a5aef732066c6de0d2466174fb017e8a6fb0267a:

  arm: rmobile: alt: Update to QoS revision 0.31 and 0.321 (2015-06-01
08:56:34 +0900)


Mitsuhiro Kimura (1):
  arm: rmobile: alt: Add ethernet function B support

Nobuhiro Iwamatsu (4):
  arm: rmobile: lager: Update to QoS revision 0.973
  arm: rmobile: koelsch: Update to QoS revision 0.411
  arm: rmobile: gose: Update to QoS revision 0.311
  arm: rmobile: alt: Update to QoS revision 0.31 and 0.321

 arch/arm/cpu/armv7/rmobile/Kconfig  |  22 ++
 arch/arm/include/asm/arch-rmobile/r8a7794.h |   4 +++
 board/renesas/alt/Kconfig   |   9 ++
 board/renesas/alt/alt.c |  17 ++-
 board/renesas/alt/qos.c |  76
++
 board/renesas/gose/qos.c|  72
+++
 board/renesas/koelsch/qos.c | 104
+++
 board/renesas/lager/qos.c   |  69
++
 8 files changed, 323 insertions(+), 50 deletions(-)

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Missing patches in patchwork

2015-05-31 Thread York Sun



On 05/31/2015 01:59 AM, Wolfgang Denk wrote:
 Dear York,
 
 In message 556921af.90...@ozlabs.org Jeremy Kerr wrote:

 Yes - I'd sent the mail (below) out yesterday. If you can send me a mbox 
 from the list, I'll import the missing mail.
 
 I sent the data to Jeremy, and he imported it.
 
 Can you please check if everything you expect is now there?
 

Thanks. I checked the patches To or CC me. They are in patchwork.

York

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

Re: [U-Boot] Building u-boot.rom for Minnowboard

2015-05-31 Thread Simon Glass

Hi Saket,

On May 31, 2015 1:08 AM, Bin Meng bmeng...@gmail.com wrote:

 Hi Saket,

 On Sun, May 31, 2015 at 2:19 PM, Saket Sinha saket.sinh...@gmail.com
wrote:
  Hi Bin,
 
  If you can have a look at  this issue.
 
  I am currently stuck on this issue with u-boot.rom not giving me any
  output on the serial.
 
  When I am flashing MinnowBoard.MAX.X64.080.D01.bin I get the all the
  UEFI prompt and the booting messages but when I flash u-boot.rom, I do
  not get anything on the serial port.
 
  Let me know if I am missing out something in the build process of
u-boot.rom
 
  While running the following commands, I seem to get the errors-
 
  c) ./tools/ifdtool -x BayleyBay/SPI.bin
  root@saket-HP-PC:# /u-boot-x86/tools/ifdtool -x BayleyBay/SPI.bin
Flash Region 0 (Flash Descriptor):  - 0fff
Flash Region 1 (BIOS): 0050 - 007f
Flash Region 2 (Intel ME): 1000 - 004f
Flash Region 3 (GbE): 00fff000 - 0fff (unused)
  Error while writing: Bad address
Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
  Error while writing: Bad address
 
  AND
 
 
  a)./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin
  root@saket-PC:# /u-boot-x86/tools/ifdtool -x
  MNW2MAX1.X64.0073.R02.1409160934.bin
Flash Region 0 (Flash Descriptor):  - 0fff
Flash Region 1 (BIOS): 0050 - 007f
Flash Region 2 (Intel ME): 1000 - 004f
Flash Region 3 (GbE):  - 0fff
Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
  Error while writing: Bad address
 
 
 
  These may be the reason for the u-boot.rom not getting built properly.
 
  I have  described the entire build process for u-boot.rom int my
  previous mail below -
 
 
  I am building u-boot.rom for MinnowboardMax as per the steps mentioned
  in the README.x86.
 
  1. Downloading BAY_TRAIL_FSP_KIT_GOLD3.tgz
 
  a) copying BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd  as
  board/intel/minnowmax/fsp.bin
 
  b) copying Vga.dat as board/intel/minnowmax/vga.bin
 
  c) ./tools/ifdtool -x BayleyBay/SPI.bin
 
  From the generted files, copying flashregion_2_intel_me.bin as
  board/intel/minnowmax/me.bin
 
  Though the o/p files are generated, I get the following error  after
  this command -
  root@saket-HP-PC:# /u-boot-x86/tools/ifdtool -x BayleyBay/SPI.bin
Flash Region 0 (Flash Descriptor):  - 0fff
Flash Region 1 (BIOS): 0050 - 007f
Flash Region 2 (Intel ME): 1000 - 004f
Flash Region 3 (GbE): 00fff000 - 0fff (unused)
  Error while writing: Bad address
Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
  Error while writing: Bad address

 I've seen this error before. It is a bug of the ifdtool, but I think
 it can be ignored. I have a patch sent out. Please check
 http://patchwork.ozlabs.org/patch/478590/

 
  2. Downloading 2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip
 
  a)./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin
  From the generted files, copying flashregion_0_flashdescriptor.bin  as
  board/intel/minnowmax/descriptor.bin
 
  Though the o/p files are generated, I get the following error  after
  this command -
  root@saket-PC:# /u-boot-x86/tools/ifdtool -x
  MNW2MAX1.X64.0073.R02.1409160934.bin
Flash Region 0 (Flash Descriptor):  - 0fff
Flash Region 1 (BIOS): 0050 - 007f
Flash Region 2 (Intel ME): 1000 - 004f
Flash Region 3 (GbE):  - 0fff
Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
  Error while writing: Bad address
 
  3. Building u-boot.rom
   export BUILD_ROM=y
   make minnowmax_defconfig
   make all
 

 Looks that your instructions are correct according to README.x86

  4. Flashing u-boot.rom to Minnowmax by desiprog sf100
   ./flashrom -p dediprog -w u-boot.rom
 

 Can you confirm that you have setup the flashrom tool correctly? I
 don't use flashrom on Linux as I normally do the SPI flash programming
 on a Windows machine. Can you dump the whole SPI flash image back
 after you program the u-boot.rom and compare the dumped file with the
 u-boot.rom you generated to see whether they are exactly the same?

  5. Now when I am powering Minnowmax and collecting the output on
serial -
  Nothing appears.
 
  Kindly let me know, if I am missing something here.
 

 Sorry but I don't have a MinnowMax board here, so cannot try it on my
side.

I'm on holiday but should be able to try this on Monday or Tuesday.

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

[U-Boot] [PATCH v2 2/2] serial_sh: Add standrad SCI (w/o FIFO) support

2015-05-31 Thread Yoshinori Sato

Add support for standard type SCI (without FIFO) port.

Changes v2:
rebased for v2015.07-rc1

Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
---
 doc/device-tree-bindings/serial/sh.txt | 2 +-
 drivers/serial/serial_sh.c | 3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/device-tree-bindings/serial/sh.txt 
b/doc/device-tree-bindings/serial/sh.txt
index b23b135..99634a5 100644
--- a/doc/device-tree-bindings/serial/sh.txt
+++ b/doc/device-tree-bindings/serial/sh.txt
@@ -1,6 +1,6 @@
 * Renesas SCI serial interface
 
 Required properties:
-- compatible: must be renesas,scif or renesas,scifa
+- compatible: must be renesas,scif, renesas,scifa or renesas,sci
 - reg: exactly one register range with length
 - clock: input clock frequency for the SCI unit
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 32b2bf0..ef7cf0f 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -205,6 +205,7 @@ static const struct dm_serial_ops sh_serial_ops = {
 
 #ifdef CONFIG_OF_CONTROL
 static const struct udevice_id sh_serial_id[] ={
+   {.compatible = renesas,sci, .data = PORT_SCI},
{.compatible = renesas,scif, .data = PORT_SCIF},
{.compatible = renesas,scifa, .data = PORT_SCIFA},
{}
@@ -262,6 +263,8 @@ U_BOOT_DRIVER(serial_sh) = {
 
 #if defined(CONFIG_SCIF_A)
#define SCIF_BASE_PORT  PORT_SCIFA
+#elif defined(CONFIG_SCI)
+   #define SCIF_BASE_PORT  PORT_SCI
 #else
#define SCIF_BASE_PORT  PORT_SCIF
 #endif
-- 
2.1.4

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

Re: [U-Boot] [PATCH 1/2] serial_sh: Add OF support

2015-05-31 Thread Yoshinori Sato

On Mon, 01 Jun 2015 09:08:55 +0900,
Nobuhiro Iwamatsu wrote:
 
 Hi!
 
 015-05-21 15:31 GMT+09:00 Yoshinori Sato ys...@users.sourceforge.jp:
  Add device tree support.
 
  Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
  ---
   doc/device-tree-bindings/serial/sh.txt |  6 ++
   drivers/serial/serial_sh.c | 28 
   2 files changed, 34 insertions(+)
   create mode 100644 doc/device-tree-bindings/serial/sh.txt
 
 2015-05-21 15:31 GMT+09:00 Yoshinori Sato ys...@users.sourceforge.jp:
  Add support for standard type SCI (without FIFO) port.
 
  Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
  ---
   doc/device-tree-bindings/serial/sh.txt | 2 +-
   drivers/serial/serial_sh.c | 8 
   2 files changed, 9 insertions(+), 1 deletion(-)
 
 
 Thanks for your patch.
 Sorry, your patch can not apply u-boot/master HEAD.
 Could you rebase and resend this patch?


Oh. I'm Sorry.
I will rebase and resend.
Thanks.

 Best regards,
   Nobuhiro
 
 2015-05-21 15:31 GMT+09:00 Yoshinori Sato ys...@users.sourceforge.jp:
  Add device tree support.
 
  Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
  ---
   doc/device-tree-bindings/serial/sh.txt |  6 ++
   drivers/serial/serial_sh.c | 28 
   2 files changed, 34 insertions(+)
   create mode 100644 doc/device-tree-bindings/serial/sh.txt
 
  diff --git a/doc/device-tree-bindings/serial/sh.txt 
  b/doc/device-tree-bindings/serial/sh.txt
  new file mode 100644
  index 000..b23b135
  --- /dev/null
  +++ b/doc/device-tree-bindings/serial/sh.txt
  @@ -0,0 +1,6 @@
  +* Renesas SCI serial interface
  +
  +Required properties:
  +- compatible: must be renesas,scif or renesas,scifa
  +- reg: exactly one register range with length
  +- clock: input clock frequency for the SCI unit
  diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
  index 8693c1e..32b2bf0 100644
  --- a/drivers/serial/serial_sh.c
  +++ b/drivers/serial/serial_sh.c
  @@ -17,6 +17,8 @@
   #include dm/platform_data/serial_sh.h
   #include serial_sh.h
 
  +DECLARE_GLOBAL_DATA_PTR;
  +
   #if defined(CONFIG_CPU_SH7760) || \
  defined(CONFIG_CPU_SH7780) || \
  defined(CONFIG_CPU_SH7785) || \
  @@ -201,10 +203,35 @@ static const struct dm_serial_ops sh_serial_ops = {
  .setbrg = sh_serial_setbrg,
   };
 
  +#ifdef CONFIG_OF_CONTROL
  +static const struct udevice_id sh_serial_id[] = {
  +   {.compatible = renesas,scif, .data = PORT_SCIF},
  +   {.compatible = renesas,scifa, .data = PORT_SCIFA},
  +   {}
  +};
  +
  +static int sh_serial_ofdata_to_platdata(struct udevice *dev)
  +{
  +   struct sh_serial_platdata *plat = dev_get_platdata(dev);
  +   fdt_addr_t addr;
  +
  +   addr = fdtdec_get_addr(gd-fdt_blob, dev-of_offset, reg);
  +   if (addr == FDT_ADDR_T_NONE)
  +   return -EINVAL;
  +
  +   plat-base = addr;
  +   plat-clk = fdtdec_get_int(gd-fdt_blob, dev-of_offset, clock, 
  1);
  +   plat-type = dev_get_driver_data(dev);
  +   return 0;
  +}
  +#endif
  +
   U_BOOT_DRIVER(serial_sh) = {
  .name   = serial_sh,
  .id = UCLASS_SERIAL,
  +   .of_match = of_match_ptr(sh_serial_id),
  +   .ofdata_to_platdata = of_match_ptr(sh_serial_ofdata_to_platdata),
  +   .platdata_auto_alloc_size = sizeof(struct sh_serial_platdata),
  .probe  = sh_serial_probe,
  .ops= sh_serial_ops,
  .flags  = DM_FLAG_PRE_RELOC,
  --
  2.1.4
 
 
 
 
 -- 
 Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6

-- 
Yoshinori Sato
ys...@users.sourceforge.jp
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/2] serial_sh: Add OF support

2015-05-31 Thread Yoshinori Sato

Add device tree support.

Changes v2:
rebased v2015.07-rc1

Signed-off-by: Yoshinori Sato ys...@users.sourceforge.jp
---
 doc/device-tree-bindings/serial/sh.txt |  6 ++
 drivers/serial/serial_sh.c | 28 
 2 files changed, 34 insertions(+)
 create mode 100644 doc/device-tree-bindings/serial/sh.txt

diff --git a/doc/device-tree-bindings/serial/sh.txt 
b/doc/device-tree-bindings/serial/sh.txt
new file mode 100644
index 000..b23b135
--- /dev/null
+++ b/doc/device-tree-bindings/serial/sh.txt
@@ -0,0 +1,6 @@
+* Renesas SCI serial interface
+
+Required properties:
+- compatible: must be renesas,scif or renesas,scifa
+- reg: exactly one register range with length
+- clock: input clock frequency for the SCI unit
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index 8693c1e..32b2bf0 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -17,6 +17,8 @@
 #include dm/platform_data/serial_sh.h
 #include serial_sh.h
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #if defined(CONFIG_CPU_SH7760) || \
defined(CONFIG_CPU_SH7780) || \
defined(CONFIG_CPU_SH7785) || \
@@ -201,9 +203,35 @@ static const struct dm_serial_ops sh_serial_ops = {
.setbrg = sh_serial_setbrg,
 };
 
+#ifdef CONFIG_OF_CONTROL
+static const struct udevice_id sh_serial_id[] ={
+   {.compatible = renesas,scif, .data = PORT_SCIF},
+   {.compatible = renesas,scifa, .data = PORT_SCIFA},
+   {}
+};
+
+static int sh_serial_ofdata_to_platdata(struct udevice *dev)
+{
+   struct sh_serial_platdata *plat = dev_get_platdata(dev);
+   fdt_addr_t addr;
+
+   addr = fdtdec_get_addr(gd-fdt_blob, dev-of_offset, reg);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   plat-base = addr;
+   plat-clk = fdtdec_get_int(gd-fdt_blob, dev-of_offset, clock, 1);
+   plat-type = dev_get_driver_data(dev);
+   return 0;
+}
+#endif
+
 U_BOOT_DRIVER(serial_sh) = {
.name   = serial_sh,
.id = UCLASS_SERIAL,
+   .of_match = of_match_ptr(sh_serial_id),
+   .ofdata_to_platdata = of_match_ptr(sh_serial_ofdata_to_platdata),
+   .platdata_auto_alloc_size = sizeof(struct sh_serial_platdata),
.probe  = sh_serial_probe,
.ops= sh_serial_ops,
.flags  = DM_FLAG_PRE_RELOC,
-- 
2.1.4

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

Re: [U-Boot] [PATCH 2/2] net: Move the CMD_NET config to defconfigs

2015-05-31 Thread Michal Simek

On 05/30/2015 02:53 AM, Joe Hershberger wrote:
 This also selects CONFIG_NET for any CONFIG_CMD_NET board.
 
 Remove the imx default for CONFIG_NET.
 
 This moves the config that was defined by 60296a8.

IRC The latest checkpatch.pl also checks this and reports that this is
not the way how you should point to specific patch.
Please add there also patch subject.

Thanks,
Michal

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





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

Re: [U-Boot] Building u-boot.rom for Minnowboard

2015-05-31 Thread Saket Sinha

Hi Bin,

Please find my response inline.

  root@saket-HP-PC:# /u-boot-x86/tools/ifdtool -x BayleyBay/SPI.bin
Flash Region 0 (Flash Descriptor):  - 0fff
Flash Region 1 (BIOS): 0050 - 007f
Flash Region 2 (Intel ME): 1000 - 004f
Flash Region 3 (GbE): 00fff000 - 0fff (unused)
  Error while writing: Bad address
Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
  Error while writing: Bad address
 
 
  a)./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin
  From the generted files, copying flashregion_0_flashdescriptor.bin  as
  board/intel/minnowmax/descriptor.bin
 
  Though the o/p files are generated, I get the following error  after
  this command -
  root@saket-PC:# /u-boot-x86/tools/ifdtool -x
  MNW2MAX1.X64.0073.R02.1409160934.bin
Flash Region 0 (Flash Descriptor):  - 0fff
Flash Region 1 (BIOS): 0050 - 007f
Flash Region 2 (Intel ME): 1000 - 004f
Flash Region 3 (GbE):  - 0fff
Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
  Error while writing: Bad address
 

 I've seen this error before. It is a bug of the ifdtool, but I think
 it can be ignored. I have a patch sent out. Please check
 http://patchwork.ozlabs.org/patch/478590/


Your patch fixes the Error message but still I do not  get any o/p on
serial with the resulting u-boot.rom



  4. Flashing u-boot.rom to Minnowmax by desiprog sf100
   ./flashrom -p dediprog -w u-boot.rom
 

 Can you confirm that you have setup the flashrom tool correctly? I
 don't use flashrom on Linux as I normally do the SPI flash programming
 on a Windows machine. Can you dump the whole SPI flash image back
 after you program the u-boot.rom and compare the dumped file with the
 u-boot.rom you generated to see whether they are exactly the same?


I only way I have dumped SPI flash has been through flashrom only.
How else can I do it on Linux?

As of now I am trying to burn u-boot.rom with SPI programmer/software
on Windows to check the sanity of my flashrom setup.


  5. Now when I am powering Minnowmax and collecting the output on serial
  -
  Nothing appears.
 
  Kindly let me know, if I am missing something here.
 

 Sorry but I don't have a MinnowMax board here, so cannot try it on my
 side.

 I'm on holiday but should be able to try this on Monday or Tuesday.


Thanks Simon.


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

Re: [U-Boot] [PATCH 00/11] Add GPIO driver for Freescale Vybrid platform

2015-05-31 Thread Bhuvanchandra DV


Hello,

On 05/26/2015 04:57 PM, Stefano Babic wrote:

Hi,

On 24/05/2015 21:34, Bhuvanchandra DV wrote:

Hello Stefano,

On 05/18/2015 06:36 PM, Bhuvanchandra DV wrote:

This patch-set adds GPIO driver, DSPI and device tree support
for Freescale Vybrid platform and Toradex Colibri Vybrid VF50,
VF61 modules.

Following cases are tested with Vybrid GPIO driver:
- with DM, without DT
- with DM and DT
Both the above cases were tested on Toradex Colibri Vybrid VF50, VF61
modules and both works fine.

- The patchset is based and tested on the latest master branch.

Bhuvanchandra DV (9):
dm: gpio: uclass: Add flag to control sequence numbering
dm: gpio: vf610: Add GPIO driver support
colibri_vf: Add pinmux entries for GPIOs
colibri_vf: Enable GPIO support
arm: vf610: Add clock support for DSPI
arm: vf610: Add iomux support for DSPI
vf610: dts: Add device tree support
colibri-vf: Enable SPI support
colibri_vf: Add separate defconfig for device tree support

Sanchayan Maity (2):
usb: ehci-vf: Add weak function for board specific initialisation
colibri_vf: Enable board specific USB initialisation for USB pen gpio


Submitted these patches in single series, as few of the patches are
interdependent, thought it would be easy to keep them in same series.

Shall we split this patchset as per the custodian maintainers to pick?

Patchset 1: Add GPIO driver support for Freescale Vybrid platform,
enable support for GPIO support on Toradex Colibri VF50, VF61 modules.

Patchset 2: Add device tree support for Freescale Vybrid Platform,
Toradex Colibri VF50, VF61 modules.

Patchset 3: Add DSPI support for Toradex Colibri VF50, VF61 modules.

Patchset 4: Add weak function for board specific USB initialization
for Freescale Vybrid platform.


Generally, if a maintainer acks a patch, the patch could then be applied
into another tree if this makes sense and avoid to introduce breakage,
maybe in both trees. You patchset is related to u-boot-imx with
exception for the USB part, but Marek has already acked it. I will check
you patches soon, but I think it is ok if the whole patchset flows into
u-boot-imx.


Ping!


Best regards,
Stefano Babic



Best regards,
Bhuvan

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

Re: [U-Boot] Query on weak function for board specific initialisation

2015-05-31 Thread maitysanchayan

Hello Jeroen,

On 15-05-30 16:44:32, Jeroen Hofstee wrote:
 Hello Maity,
 
 On 30-04-15 14:57, maitysancha...@gmail.com wrote:
 Hello,
 
 I am trying to use a weak function in able to provide a board specific
 initialisation. To be more specific, I am trying to use the __weak
 board_ehci_hcd_init function in the usb driver code which is called in
 ehci_hcd_init, the strong function being defined in the board file.
 This is on lines similar to what I see in the ehci-mx6 driver and some
 mx6 board files like nitrogen's.
 
 Getting a linker error on compiling which is perplexing me at the
 moment.
 
 [snip]
 drivers/usb/host/built-in.o: In function `ehci_hcd_init':
 /home/sanchayan/uboot/u-boot/drivers/usb/host/ehci-vf.c:185:
 undefined reference to `board_echi_hcd_init'
 /home/sanchayan/gcc-linaro/bin/arm-linux-gnueabihf-ld.bfd: BFD
 (crosstool-NG linaro-1.13.1-2012.09-20120921 - Linaro GCC 2012.09) 2.22
 assertion fail
 /cbuild/slaves/oort14/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-2.22/bfd/elf32-arm.c:7498
 /home/sanchayan/gcc-linaro/bin/arm-linux-gnueabihf-ld.bfd: BFD
 (crosstool-NG linaro-1.13.1-2012.09-20120921 - Linaro GCC 2012.09) 2.22
 assertion fail
 /cbuild/slaves/oort14/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-2.22/bfd/elf32-arm.c:13830
 /bin/sh: line 1:  1110 Segmentation fault  (core dumped)
 
 Perhaps I am overlooking something trivial?
 
 
 I suppose you found this already, but for completeness, you made a typo:
 
 board_ehci_hcd_init
 board_echi_hcd_init
 
 To prevent trouble like this, the compiler should actually be set to warn
 if there is no prototype...

Yes, I found the error and also posted the patch. Thanks for the tip, I do
not have that switch turned on, will do so. Lack of sleep and resulting
lack of attention to detail resulted in the trivial noise post :).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] x86: baytrail: PCI is not always mapped to end of ram

2015-05-31 Thread Bin Meng

Hi Andrew,

On Sat, May 30, 2015 at 2:27 AM, Andrew Bradford
and...@bradfordembedded.com wrote:
 Hi Bin,

 On 05/29 13:00, Bin Meng wrote:
 Hi Andrew,

 On Wed, May 27, 2015 at 7:53 PM, Andrew Bradford
 and...@bradfordembedded.com wrote:
  Hi Bin,
 
  On 05/27 12:21, Bin Meng wrote:
  Hi Andrew,
 
  On Tue, May 26, 2015 at 8:17 PM, Andrew Bradford
  and...@bradfordembedded.com wrote:
   Hi Bin,
  
   On 05/23 23:50, Bin Meng wrote:
   +Simon.
  
   Hi Andrew,
  
   On Sat, May 23, 2015 at 3:09 AM,  and...@bradfordembedded.com wrote:
From: Andrew Bradford andrew.bradf...@kodakalaris.com
   
PCI on Intel Baytrail is mapped to 0x8000, which is not always at
the end of SDRAM, such as when running with 4 GiB of SDRAM.  The PCI 
bus
memory mapping must stay within low memory and so when running with 
2 GiB of SDRAM, there is a hole in the SDRAM between 2 GiB and 4 GiB 
for
memory mapped IO, such as PCI.
  
   Are you saying that if we mount 4GB DDR DIMM on the MinnowMax board,
   the Intel FSP will only put 0~2G as system RAM space, and leave 2G~4G
   as PCI address and other I/Os?
  
   Yes.  If you mount 4 GiB of SDRAM onto an E3800 processor, then physical
   addresses from 0 to just below 2 GiB will be SDRAM (as per the HOBs) and
   also from 4 GiB to 6 GiB (also verified via the HOBs).  The space from 2
   GiB to 4 GiB will be mapped as various other regions.
 
  Ah, that's exactly the information I want :)
 
   If you see section 4.1.1.1 (page 71 in the January 2015, Revision 3.6)
   E3800 datasheet, it shows that from 2 GiB to 4 GiB is mapped for PCI,
   Abort Page, Local APIC, and the Boot Vector.  There's a lot of space in
   this area which appears unused, so I'm unsure as to why the area is so
   large.
  
   I have an Intel Valley Island board with E3825 and a 4 GiB SODIMM.  I'm
   working on getting patches ready for this board but found that if I
   enabled all 4 GiB of SDRAM that the PCI bus would not function
   correctly.  With this patch then the PCI bus functions (I'm able to do
   network operations with the RTL8111 Ethernet adapter).
  
   I see from minnowmax.h, the PCI address starts from 0xd000.
  
   #define CONFIG_PCI_MEM_BUS  0xd000
   #define CONFIG_PCI_MEM_PHYS CONFIG_PCI_MEM_BUS
   #define CONFIG_PCI_MEM_SIZE 0x1000
  
   #define CONFIG_PCI_PREF_BUS 0xc000
   #define CONFIG_PCI_PREF_PHYSCONFIG_PCI_PREF_BUS
   #define CONFIG_PCI_PREF_SIZE0x1000
  
   I see that hose-regions+0 is set to CONFIG_PCI_MEM_BUS and
   hose-regions+2 is set to CONFIG_PCI_PREF_BUS.  However I'm modifying
   hose-regions+3.  So the values from minnowmax.h *are* being used.  I'm
   not yet that familiar with PCI configuration, so likely I'm not fully
   understanding how u-boot sets this up.
  
 
  The regions+3 is used by the inbound access, eg: PCI device access to
  system memory.
 
   Possibly my address of 0x8000 is not correct, even though it works
   for me.  But 0x8000 is where it was being placed before, since it
   was going at the end of SDRAM (2GiB on minnowmax).
  
 
  You understanding is correct. We should only open 2GiB inbound memory
  window for PCI devices.
 
  But, if you have less than 2 GiB of memory, my patch in theory *could*
  break things, right?.  It seems like a better approach would be to limit
  the size to the lesser of 0x8000 and gd-ram_size.  Does that make
  sense?
 

 I think 2GB is a safe value and won't break things. Region 0 and
 region 3 should not overlap.

   If I artificially limit the amount of SDRAM by setting the fsp
   configuration to memory-down and then setting the DRAM configuration
   values such that I mimmic 1 GiB or 2 GiB of SDRAM, having my patch still
   provides access to the PCI bus, so with my patch there should be no
   adverse affects on E3800 systems that have less than 4 GiB of SDRAM.
   But without my patch, when running with =4 GiB of SDRAM, PCI accesses
   end up returning pci_hose_bus_to_phys: invalid physical address
   errors.

 Can you add some printf to show all of the pci_hose_bus_to_phys()
 parameters' value here when 4GB RAM is mounted? I'd like to understand
 how the message pci_hose_bus_to_phys: invalid physical address is
 produced.

 Patch of my changes to enable reporting of physical addresses being
 used looks like:

 diff --git a/drivers/pci/pci_common.c b/drivers/pci/pci_common.c
 index b9ff23f..3babcb7 100644
 --- a/drivers/pci/pci_common.c
 +++ b/drivers/pci/pci_common.c
 @@ -205,7 +205,7 @@ int __pci_hose_bus_to_phys(struct pci_controller *hose,
 return 0;
 }
 }
 -
 +   printf(__pci_hose_bus_to_phys() failed!\n);
 return 1;
  }

 @@ -237,6 +237,7 @@ phys_addr_t pci_hose_bus_to_phys(struct pci_controller 
 *hose,
 if (ret)
 puts(pci_hose_bus_to_phys: invalid physical address\n);

 +   printf(bus_addr:

[U-Boot] [PATCH] tools: ifdtool: Do not write region while its size is negative

2015-05-31 Thread Bin Meng

We should ignore those regions whose size is negative. These are
typically optional and unused regions (like GbE and platform data).

Signed-off-by: Bin Meng bmeng...@gmail.com
---

 tools/ifdtool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/ifdtool.c b/tools/ifdtool.c
index 590ccc9..1d61df1 100644
--- a/tools/ifdtool.c
+++ b/tools/ifdtool.c
@@ -462,7 +462,7 @@ static int write_regions(char *image, int size)
if (ret)
return ret;
dump_region(i, frba);
-   if (region.size == 0)
+   if (region.size = 0)
continue;
region_fd = open(region_filename(i),
 O_WRONLY | O_CREAT | O_TRUNC, S_IRUSR |
-- 
1.8.2.1

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

Re: [U-Boot] Building u-boot.rom for Minnowboard

2015-05-31 Thread Bin Meng

Hi Saket,

On Sun, May 31, 2015 at 2:19 PM, Saket Sinha saket.sinh...@gmail.com wrote:
 Hi Bin,

 If you can have a look at  this issue.

 I am currently stuck on this issue with u-boot.rom not giving me any
 output on the serial.

 When I am flashing MinnowBoard.MAX.X64.080.D01.bin I get the all the
 UEFI prompt and the booting messages but when I flash u-boot.rom, I do
 not get anything on the serial port.

 Let me know if I am missing out something in the build process of u-boot.rom

 While running the following commands, I seem to get the errors-

 c) ./tools/ifdtool -x BayleyBay/SPI.bin
 root@saket-HP-PC:# /u-boot-x86/tools/ifdtool -x BayleyBay/SPI.bin
   Flash Region 0 (Flash Descriptor):  - 0fff
   Flash Region 1 (BIOS): 0050 - 007f
   Flash Region 2 (Intel ME): 1000 - 004f
   Flash Region 3 (GbE): 00fff000 - 0fff (unused)
 Error while writing: Bad address
   Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
 Error while writing: Bad address

 AND


 a)./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin
 root@saket-PC:# /u-boot-x86/tools/ifdtool -x
 MNW2MAX1.X64.0073.R02.1409160934.bin
   Flash Region 0 (Flash Descriptor):  - 0fff
   Flash Region 1 (BIOS): 0050 - 007f
   Flash Region 2 (Intel ME): 1000 - 004f
   Flash Region 3 (GbE):  - 0fff
   Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
 Error while writing: Bad address



 These may be the reason for the u-boot.rom not getting built properly.

 I have  described the entire build process for u-boot.rom int my
 previous mail below -


 I am building u-boot.rom for MinnowboardMax as per the steps mentioned
 in the README.x86.

 1. Downloading BAY_TRAIL_FSP_KIT_GOLD3.tgz

 a) copying BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd  as
 board/intel/minnowmax/fsp.bin

 b) copying Vga.dat as board/intel/minnowmax/vga.bin

 c) ./tools/ifdtool -x BayleyBay/SPI.bin

 From the generted files, copying flashregion_2_intel_me.bin as
 board/intel/minnowmax/me.bin

 Though the o/p files are generated, I get the following error  after
 this command -
 root@saket-HP-PC:# /u-boot-x86/tools/ifdtool -x BayleyBay/SPI.bin
   Flash Region 0 (Flash Descriptor):  - 0fff
   Flash Region 1 (BIOS): 0050 - 007f
   Flash Region 2 (Intel ME): 1000 - 004f
   Flash Region 3 (GbE): 00fff000 - 0fff (unused)
 Error while writing: Bad address
   Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
 Error while writing: Bad address

I've seen this error before. It is a bug of the ifdtool, but I think
it can be ignored. I have a patch sent out. Please check
http://patchwork.ozlabs.org/patch/478590/


 2. Downloading 2014-WW42.4-MinnowBoardMax.73-64-bit.bin_Release.zip

 a)./tools/ifdtool -x MNW2MAX1.X64.0073.R02.1409160934.bin
 From the generted files, copying flashregion_0_flashdescriptor.bin  as
 board/intel/minnowmax/descriptor.bin

 Though the o/p files are generated, I get the following error  after
 this command -
 root@saket-PC:# /u-boot-x86/tools/ifdtool -x
 MNW2MAX1.X64.0073.R02.1409160934.bin
   Flash Region 0 (Flash Descriptor):  - 0fff
   Flash Region 1 (BIOS): 0050 - 007f
   Flash Region 2 (Intel ME): 1000 - 004f
   Flash Region 3 (GbE):  - 0fff
   Flash Region 4 (Platform Data): 00fff000 - 0fff (unused)
 Error while writing: Bad address

 3. Building u-boot.rom
  export BUILD_ROM=y
  make minnowmax_defconfig
  make all


Looks that your instructions are correct according to README.x86

 4. Flashing u-boot.rom to Minnowmax by desiprog sf100
  ./flashrom -p dediprog -w u-boot.rom


Can you confirm that you have setup the flashrom tool correctly? I
don't use flashrom on Linux as I normally do the SPI flash programming
on a Windows machine. Can you dump the whole SPI flash image back
after you program the u-boot.rom and compare the dumped file with the
u-boot.rom you generated to see whether they are exactly the same?

 5. Now when I am powering Minnowmax and collecting the output on serial -
 Nothing appears.

 Kindly let me know, if I am missing something here.


Sorry but I don't have a MinnowMax board here, so cannot try it on my side.

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

Re: [U-Boot] Missing patches in patchwork

2015-05-31 Thread Wolfgang Denk

Dear York,

In message 556921af.90...@ozlabs.org Jeremy Kerr wrote:
 
 Yes - I'd sent the mail (below) out yesterday. If you can send me a mbox 
 from the list, I'll import the missing mail.

I sent the data to Jeremy, and he imported it.

Can you please check if everything you expect is now there?

Thanks.

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
Consistency requires you to be as ignorant today as you were a  year
ago.  - Bernard Berenson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Missing patches in patchwork

2015-05-31 Thread Bin Meng

Hi Wolfgang,

On Sun, May 31, 2015 at 4:59 PM, Wolfgang Denk w...@denx.de wrote:
 Dear York,

 In message 556921af.90...@ozlabs.org Jeremy Kerr wrote:

 Yes - I'd sent the mail (below) out yesterday. If you can send me a mbox
 from the list, I'll import the missing mail.

 I sent the data to Jeremy, and he imported it.

 Can you please check if everything you expect is now there?


I noticed there are several patches with messy submitter names, for example:

http://patchwork.ozlabs.org/patch/478600/
http://patchwork.ozlabs.org/patch/478626/
http://patchwork.ozlabs.org/patch/478627/
http://patchwork.ozlabs.org/patch/478637/

Looks like the submitter has name which is UTF-8 encoded and patchwork
has something wrong with the decoding.

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

Re: [U-Boot] [PATCH] MIPS: fix missing semicolon in cacheops.h

Re: [U-Boot] Booting Wandboard through USB

Re: [U-Boot] [PATCH 1/2] serial_sh: Add OF support

Re: [U-Boot] Booting Wandboard through USB

[U-Boot] Pull request: u-boot-sh/rmobile

Re: [U-Boot] Missing patches in patchwork

Re: [U-Boot] Building u-boot.rom for Minnowboard

[U-Boot] [PATCH v2 2/2] serial_sh: Add standrad SCI (w/o FIFO) support

Re: [U-Boot] [PATCH 1/2] serial_sh: Add OF support

[U-Boot] [PATCH v2 1/2] serial_sh: Add OF support

Re: [U-Boot] [PATCH 2/2] net: Move the CMD_NET config to defconfigs

Re: [U-Boot] Building u-boot.rom for Minnowboard

Re: [U-Boot] [PATCH 00/11] Add GPIO driver for Freescale Vybrid platform

Re: [U-Boot] Query on weak function for board specific initialisation

Re: [U-Boot] [PATCH] x86: baytrail: PCI is not always mapped to end of ram

[U-Boot] [PATCH] tools: ifdtool: Do not write region while its size is negative

Re: [U-Boot] Building u-boot.rom for Minnowboard

Re: [U-Boot] Missing patches in patchwork

Re: [U-Boot] Missing patches in patchwork

19 matches

Site Navigation

Mail list logo

Footer information