Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Stephen Warren]

On 08/14/2015 09:12 PM, Bin Meng wrote:
> On Sat, Aug 15, 2015 at 10:57 AM, Stephen Warren  
> wrote:
>> On 08/14/2015 05:18 PM, Simon Glass wrote:
>>> Hi,
>>>
>>> On 14 August 2015 at 16:51, Stephen Warren  wrote:
 On 08/14/2015 04:40 PM, Bin Meng wrote:
>
> On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:
>>
>> Hi Stephen,
>>
>> On 14 August 2015 at 10:58, Stephen Warren  wrote:
>>>
>>> On 08/14/2015 10:50 AM, Simon Glass wrote:


 Hi Bin,

 On 14 August 2015 at 03:18, Bin Meng  wrote:
>
>
> Hi,
>
> Currently there are 5 dm serial drivers, all of which are ns16550
> compatible drivers. They are:
>
> serial_omap.c
> serial_dw.c
> serial_tegra.c
> serial_x86.c
> serial_ppc.c
>
> All these drivers are pretty much similar. I think we can justmerge
> these into one ns16550 driver.
>
> If you think this is necessary, I will send a patch series to do this.



 The tegra one is there because it needs an input clock and Stephen
 didn't want to add this to the device tree binding (the kernel has a
 clock framework which gets around this problem).

 After that I followed the same pattern. I would support updating the
 binding to support an input clock. Even with the new clock framework
 in U-Boot it might be painful to fit it into SPL in some cases.
>>>
>>>
>>>
>>> The clock is already in the DT, in both Linux and U-Boot's copy, at
>>> least
>>> for Tegra DTs:
>>>
>>>  uarta: serial@0,70006000 {
>>>  compatible = "nvidia,tegra124-uart", ...
>>> ...
>>>  clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>>>
>>
>> I mean the clock-frequency property. However if there is a plan to
>> implement the clock framework in U-Boot that would be good too.
>>
>
> The clock-frequency is a fixed value on x86 super i/o chipset, and
> fixed on the PCI bus too. But for ARM and PPC, it might get
> dynamically calculated due to different PLL settings. We can implement
> a _weak function like the one in serial_ppc.c get_serial_clock() to
> initialize plat->clock with its return value. The _weak function gets
> clock-frequency from device tree. If there is not, platform codes
> which uses the ns16550 driver should provide the implementation of
> get_serial_clock(). Thoughts?


 There is no clock-frequency property in DT, at least for the Tegra DT
 binding. It looks like some other bindings have it. To obtain the clock
 frequency from DT for Tegra, you'd need to parse the clocks property, find
 the clock driver associated with the phandle in DT, and go and ask that
 clock driver what the clock frequency is.

 I'd prefer not to have a weak function that parses clock-frequency, since
 it's too easy to accidentally use it on systems where parsing that property
 is incorrect.

 Certainly, a generic UART driver can call out to a platform-supplied
 function to retrieve the clock, and we can provide driver-specific
 implementations for x86 super IO and PCI, and generic implementations that
 appropriate drivers can call to parse the clocks or clock-frequency 
 property
 from DT, and finally for Tegra if we can't parse the clocks property right
 now, call the Tegra clock driver directly to look up the value.
>>>
>>> I'm not a big fan of weak functions either. In fact I think with
>>> driver model we should avoid them. If we can't call a uclass to get
>>> the info then perhaps we should wait until we can.
>>>
>>> Pragmatically I wonder if a UART clock frequency would not be a useful
>>> compromise? Some bindings have it, some do not. Maybe we should just
>>> add it?
>>
>> There's no need for it; the binding already has a clocks property, from
>> which the data can be derived. Adding a clock-frequency property would
>> just result in two sources of the same data. In all likelihood, all
>> that'd happen is that the two would get out-of-sync, and code wouldn't
>> know which to trust.
>>
> 
> I agree. So what's our next step? So far I still think using _weak is
> the easiest approach. Adding clock uclass for fixed clock-frequency
> chipset like x86 super i/o and PCI UART does not make sense. The clock
> uclass is only helpful when dealing with dynamic clock frequency
> platforms on PPC and ARM SoC.

I think having the core UART driver call a function to get the clock
rate is perfectly fine. Just don't provide a _weak version of the
function. This will require all users of the generic UART driver to make
an explicit choice about how to implement this "callback" or "hook",
which makes it most likely that it'll be correctly implemented on 

Re: [U-Boot] [U-Boot, V3] kconfig: add config option for shell prompt

[York Sun]

On 08/13/2015 06:23 AM, Tom Rini wrote:
> On Mon, Aug 03, 2015 at 12:36:58PM +0300, Nikita Kiryanov wrote:
> 
>> Add option to set shell prompt string from menuconfig and migrate
>> boards globally.
>>
>> The migration is done as follows:
>> - Boards that explicitly and unconditionally set CONFIG_SYS_PROMPT had the
>>   entry moved to their defconfig files.
>> - Boards that defined some kind of #ifdef logic which selects the
>>   CONFIG_SYS_PROMPT (for example qemu-mips) got an #undef CONFIG_SYS_PROMPT
>>   right before the #ifdef logic and were left alone.
>> - This change forces CONFIG_SYS_PROMPT to be a per board decision, and thus
>>   CONFIG_SYS_PROMPT was removed from all _common.h and _common.h
>>   files. This results in a streamlined default value across platforms, and
>>   includes the following files: spear-common, sunxi-common, mv-common,
>>   ti_armv7_common, tegra-common, at91-sama5_common, and zynq-common.
>> - Boards that relied on _common.h values of CONFIG_SYS_PROMPT were
>>   not updated in their respective defconfig files under the assumption that
>>   since they did not explicitly define a value, they're fine with whatever
>>   the default is.
>> - On the other hand, boards that relied on a value defined in some
>>   _common.h file such as woodburn_common, rpi-common,
>>   bur_am335x_common, ls2085a_common, siemens_am33x_common, and
>>   omap3_evm_common, had their values moved to the respective defconfig files.
>> - The define V_PROMPT was removed, since it is not used anywhere except for
>>   assigning a value for CONFIG_SYS_PROMPT.
>>
>> Cc: Tom Rini 
>> Cc: Masahiro Yamada 
>> Cc: Stefano Babic 
>> Cc: Igor Grinberg 
>> Signed-off-by: Nikita Kiryanov 
> 
> Applied to u-boot/master, thanks!
> 

Tom,

Looks like an extra file was committed during the merge

include/configs/odroid_xu3.h.rej

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

Re: [U-Boot] [PATCH v3 06/11] arm: rpi: Enable device tree control for Rasberry Pi

[Stephen Warren]

On 08/14/2015 01:20 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On 10 August 2015 at 21:47, Stephen Warren  wrote:
>> On 08/07/2015 07:42 AM, Simon Glass wrote:
>>> Enable device tree control so that we can use driver model fully and avoid
>>> using platform data.
>>
>> I'm still not convinced about this change.
>>
>> Re: the commit message about: What about the driver model is not being
>> fully used without DT?
> 
> Device tree control?

I am not convince about that argument. It seems rather self-fulfilling,
and irrelevant to me.

The fact that a feature exists shouldn't necessarily mean that it
absolutely must be used in all cases. There needs to be some benefit
from using the feature. What stability, performance, ... benefit does DT
give to a maintainer or user?

On a system that sources device information from ACPI, must DT still be
used because DM has that feature and without using it, DM isn't being
fully used?

I would strongly hope that DM is not tied to any particular source of
device information. A device model should be generic. The actions of
enumerating what devices exist (via C structures, DT, ACPI, ...) should
be completely independent from the process that then manages all of
those devices once they're enumerating/instantiated.

>> Overall: What advantage does using DT have to either a developer or an
>> end-user?
>>
>> I don't believe this patch fixes and bugs or enables any new features
>> for an end-user.
>>
>> From the maintainer perspective: It seems to me that it's far simpler to
>> have a tiny struct for each device in the C code than to pull in a whole
>> slew of DT parsing cruft just to work out the same struct at run-time.
>> As such, this patch can only make it harder to maintain the code since
>> there's more of it, and it's more complex.
>>
>> I just don't see the advantage of switching to DT for U-Boot control.
> 
> It allows us to share configuration with the kernel (same device tree
> file). This should be more familiar to people coming from there than
> our own configuration system. It's nice to have all the configuration
> in one place. We can then avoid using platform data in U-Boot unless
> it is necessary.

But at the cost of extra complexity in the U-Boot code that I don't
think is warranted. Equally, U-Boot's DT support is built on some
assumptions about DT structure and parsing rules that are inaccurate
(e.g. not honoring #address-cells, not parsing the DT in a hierarchical
manner thus not ensuring correct driver "probe" ordering, missing
features such as clock frameworks with pushback on supporting the
standard clock bindings rather than implementing U-Boot-specific
properties, etc.). It's not quite DT, but almost. It's quite unlikely
that any Linux DT will "just work". Once it doesn't always just work,
the advantage of similarity with kernel DTs is lost. As someone who's
ported U-Boot to various Tegra and RPi SoCs/boards, I honestly don't
think that using DT rather the C structures would have saved me any
time, and likely has caused me to spend more time debugging and fixing
DT issues in U-Boot.

> I really don't like the idea of filling up the code with platform data
> when that approach has already been rejected by Linux.

The Linux situation is entirely different from U-Boot.

Linux distros want to distribute a single generic Linux kernel binary
(and indeed generic install media, etc.) that runs on arbitrary systems
without having to worry about system-specific details. Ideally, the
distro can ship a single OS image which will work on arbitrary systems,
provided the system vendor ships the DT as part of the firmware and
provides it to the kernel. Of course, that hasn't actually happened yet
since the DTs are still in the kernel source tree and DT ABI isn't
anywhere near universal.

A bootloader or firmware is by definition system-specific. There's no
concept of a single image working across *arbitrary* systems. (Of
course, some U-Boot builds run on a small number of boards via runtime
detection, but by no means is any U-Boot binary entirely generic).
There's no need for it to be generic, since system vendors or
enterprising users build and install the firmware for a specific known
board/system.

As such, any arguments about Linux having chosen to use DT are likely
irrelevant to whether a firmware or bootloader should use it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] git fetch fails, and patchwork not updating

[Bin Meng]

Hi,

I noticed that this morning when I do git fetch it always fails with
"Connection reset by peer" message.

$ git fetch x86
fatal: read error: Connection reset by peer

Also patchwork is not updating any new patches. I guess the denx.ge
server is running into some problems again.

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

Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Stephen Warren]

On 08/14/2015 04:40 PM, Bin Meng wrote:

On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:

Hi Stephen,

On 14 August 2015 at 10:58, Stephen Warren  wrote:

On 08/14/2015 10:50 AM, Simon Glass wrote:


Hi Bin,

On 14 August 2015 at 03:18, Bin Meng  wrote:


Hi,

Currently there are 5 dm serial drivers, all of which are ns16550
compatible drivers. They are:

serial_omap.c
serial_dw.c
serial_tegra.c
serial_x86.c
serial_ppc.c

All these drivers are pretty much similar. I think we can justmerge
these into one ns16550 driver.

If you think this is necessary, I will send a patch series to do this.



The tegra one is there because it needs an input clock and Stephen
didn't want to add this to the device tree binding (the kernel has a
clock framework which gets around this problem).

After that I followed the same pattern. I would support updating the
binding to support an input clock. Even with the new clock framework
in U-Boot it might be painful to fit it into SPL in some cases.



The clock is already in the DT, in both Linux and U-Boot's copy, at least
for Tegra DTs:

 uarta: serial@0,70006000 {
 compatible = "nvidia,tegra124-uart", ...
...
 clocks = <&tegra_car TEGRA124_CLK_UARTA>;



I mean the clock-frequency property. However if there is a plan to
implement the clock framework in U-Boot that would be good too.



The clock-frequency is a fixed value on x86 super i/o chipset, and
fixed on the PCI bus too. But for ARM and PPC, it might get
dynamically calculated due to different PLL settings. We can implement
a _weak function like the one in serial_ppc.c get_serial_clock() to
initialize plat->clock with its return value. The _weak function gets
clock-frequency from device tree. If there is not, platform codes
which uses the ns16550 driver should provide the implementation of
get_serial_clock(). Thoughts?


There is no clock-frequency property in DT, at least for the Tegra DT 
binding. It looks like some other bindings have it. To obtain the clock 
frequency from DT for Tegra, you'd need to parse the clocks property, 
find the clock driver associated with the phandle in DT, and go and ask 
that clock driver what the clock frequency is.


I'd prefer not to have a weak function that parses clock-frequency, 
since it's too easy to accidentally use it on systems where parsing that 
property is incorrect.


Certainly, a generic UART driver can call out to a platform-supplied 
function to retrieve the clock, and we can provide driver-specific 
implementations for x86 super IO and PCI, and generic implementations 
that appropriate drivers can call to parse the clocks or clock-frequency 
property from DT, and finally for Tegra if we can't parse the clocks 
property right now, call the Tegra clock driver directly to look up the 
value.

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

[U-Boot] [v3 4/4] spi: cadence_qspi: get fifo width from device tree

[Vikas Manocha]

Fifo width could be different on different socs, e.g. stv0991 & altera soc
have different fifo width.

Signed-off-by: Vikas Manocha 
---

Changes in v3: none
Changes in v2: Rebased to master

 arch/arm/dts/socfpga.dtsi  |1 +
 arch/arm/dts/stv0991.dts   |1 +
 drivers/spi/cadence_qspi.c |1 +
 drivers/spi/cadence_qspi.h |1 +
 drivers/spi/cadence_qspi_apb.c |   24 ++--
 5 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 25053ec..265a5b8 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -640,6 +640,7 @@
ext-decoder = <0>;  /* external decoder */
num-cs = <4>;
fifo-depth = <128>;
+   fifo-width = <4>;
sram-size = <128>;
bus-num = <2>;
status = "disabled";
diff --git a/arch/arm/dts/stv0991.dts b/arch/arm/dts/stv0991.dts
index e23d4fd..f0f450b 100644
--- a/arch/arm/dts/stv0991.dts
+++ b/arch/arm/dts/stv0991.dts
@@ -34,6 +34,7 @@
<0x4000 0x010>;
clocks = <375>;
sram-size = <256>;
+   fifo-width = <8>;
status = "okay";
 
flash0: n25q32@0 {
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 01eff71..54b3c36 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -311,6 +311,7 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
plat->tchsh_ns = fdtdec_get_int(blob, subnode, "tchsh-ns", 20);
plat->tslch_ns = fdtdec_get_int(blob, subnode, "tslch-ns", 20);
plat->sram_size = fdtdec_get_int(blob, node, "sram-size", 128);
+   plat->fifo_width = fdtdec_get_int(blob, node, "fifo-width", 4);
 
debug("%s: regbase=%p flashbase=%p trigger_base=%p max-frequency=%d 
page-size=%d\n",
__func__, plat->regbase, plat->flashbase, plat->trigger_base,
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 7341339..91f38f1 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -27,6 +27,7 @@ struct cadence_spi_platdata {
u32 tchsh_ns;
u32 tslch_ns;
u32 sram_size;
+   u32 fifo_width;
 };
 
 struct cadence_spi_priv {
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 25a7ed2..e534c06 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -34,8 +34,6 @@
 #define CQSPI_REG_RETRY(1)
 #define CQSPI_POLL_IDLE_RETRY  (3)
 
-#define CQSPI_FIFO_WIDTH   (4)
-
 #define CQSPI_REG_SRAM_THRESHOLD_WORDS (50)
 
 /* Transfer mode */
@@ -48,9 +46,6 @@
 #define CQSPI_DUMMY_CLKS_PER_BYTE  (8)
 #define CQSPI_DUMMY_BYTES_MAX  (4)
 
-
-#define CQSPI_REG_SRAM_FILL_THRESHOLD  \
-   ((CQSPI_REG_SRAM_SIZE_WORD / 2) * CQSPI_FIFO_WIDTH)
 /
  * Controller's configuration and status register (offset from QSPI_BASE)
  /
@@ -214,7 +209,7 @@ static void cadence_qspi_apb_read_fifo_data(void *dest,
 }
 
 static void cadence_qspi_apb_write_fifo_data(const void *dest_ahb_addr,
-   const void *src, unsigned int bytes)
+   const void *src, unsigned int fifo_width, unsigned int bytes)
 {
unsigned int temp = 0;
int i;
@@ -222,11 +217,11 @@ static void cadence_qspi_apb_write_fifo_data(const void 
*dest_ahb_addr,
unsigned int *dest_ptr = (unsigned int *)dest_ahb_addr;
unsigned int *src_ptr = (unsigned int *)src;
 
-   while (remaining >= CQSPI_FIFO_WIDTH) {
-   for (i = CQSPI_FIFO_WIDTH/sizeof(src_ptr) - 1; i >= 0; i--)
+   while (remaining >= fifo_width) {
+   for (i = fifo_width/sizeof(src_ptr) - 1; i >= 0; i--)
writel(*(src_ptr+i), dest_ptr+i);
-   src_ptr += CQSPI_FIFO_WIDTH/sizeof(src_ptr);
-   remaining -= CQSPI_FIFO_WIDTH;
+   src_ptr += fifo_width/sizeof(src_ptr);
+   remaining -= fifo_width;
}
if (remaining) {
/* dangling bytes */
@@ -241,7 +236,7 @@ static void cadence_qspi_apb_write_fifo_data(const void 
*dest_ahb_addr,
 
 /* Read from SRAM FIFO with polling SRAM fill level. */
 static int qspi_read_sram_fifo_poll(const void *reg_base, void *dest_addr,
-   const void *src_addr,  unsigned int num_bytes)
+   const void *src_addr, unsigned int fifo_width, unsigned int num_bytes)
 {
unsigned int remaining = num_bytes;
unsigned int retry;
@@ -263,7 +258,7 @@ s

[U-Boot] [v3 2/4] spi: cadence_qspi: fix indirect read/write start address

[Vikas Manocha]

Indirect read/write start addresses are flash start addresses for indirect read
or write transfers. These should be absolute flash addresses instead of
offsets.

Signed-off-by: Vikas Manocha 
---

Changes in v3: none
Changes in v2: Rebased to master

 drivers/spi/cadence_qspi_apb.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index b46e5fe..6b5ae30 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -705,7 +705,8 @@ int cadence_qspi_apb_indirect_read_setup(struct 
cadence_spi_platdata *plat,
 
/* Get address */
addr_value = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes);
-   writel(addr_value, plat->regbase + CQSPI_REG_INDIRECTRDSTARTADDR);
+   writel((u32)plat->ahbbase + addr_value,
+   plat->regbase + CQSPI_REG_INDIRECTRDSTARTADDR);
 
/* The remaining lenght is dummy bytes. */
dummy_bytes = cmdlen - addr_bytes - 1;
@@ -795,7 +796,8 @@ int cadence_qspi_apb_indirect_write_setup(struct 
cadence_spi_platdata *plat,
 
/* Setup write address. */
reg = cadence_qspi_apb_cmd2addr(&cmdbuf[1], addr_bytes);
-   writel(reg, plat->regbase + CQSPI_REG_INDIRECTWRSTARTADDR);
+   writel((u32)plat->ahbbase + reg,
+   plat->regbase + CQSPI_REG_INDIRECTWRSTARTADDR);
 
reg = readl(plat->regbase + CQSPI_REG_SIZE);
reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
-- 
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 V2 00/10] Replace the FAT filesystem code

[Stephen Warren]

On 08/12/2015 08:56 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On 11 August 2015 at 08:55, Stephen Warren  wrote:
>> The existing FAT filesystem implementation in U-Boot has some bugs that
>> are tricky to fix cleanly without significant rework of the code. For
>> example, see:
>>
>> http://lists.denx.de/pipermail/u-boot/2015-July/221054.html
>> [PATCH] fat: handle paths that include ../
>>
>> This series replaces U-Boot's FAT filesystem implementation with the "ff"
>> project; http://elm-chan.org/fsw/ff/00index_e.html. This project appears
>> to be actively maintained, does not have at least the bug referenced in
>> the patch link above, and is quite easy to integrate into U-Boot. An
>> earlier version is also used in Barebox, so presumably it's had some
>> level of testing/exposure there.
>>
> 
> This seems like a good idea to me. Are there some standard tests for
> FAT that we can bring in also? Perhaps using sandbox? At present we
> have fs-test.sh which is a start.

This series does pass fs-test.sh, which caught a couple of bugs. It
would be nice to ensure that the image fs-test.sh creates cause all of
FAT12/16/32 to be parsed. It'd also be nice to extend it with a check
for the bug that triggered me to start fiddling with FAT; /foo/../xxx
where xxx is past the first sector (cluster?) of the root directory. We
could likely test for volume ID retrieval, ls output, ... too. Many
options to extend the test; all will take time though.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/6] net: e1000: Convert to driver model

[Bin Meng]

Hi Simon,

On Tue, Aug 11, 2015 at 9:39 PM, Simon Glass  wrote:
> Update this driver to support driver model.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  drivers/net/e1000.c | 137 
> 
>  drivers/net/e1000.h |   4 ++
>  2 files changed, 141 insertions(+)
>
> diff --git a/drivers/net/e1000.c b/drivers/net/e1000.c
> index 11bf9ca..25d0b39 100644
> --- a/drivers/net/e1000.c
> +++ b/drivers/net/e1000.c
> @@ -30,6 +30,7 @@ tested on both gig copper and gig fiber boards
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "e1000.h"
> @@ -47,12 +48,21 @@ tested on both gig copper and gig fiber boards
>  /* Intel i210 needs the DMA descriptor rings aligned to 128b */
>  #define E1000_BUFFER_ALIGN 128
>
> +/*
> + * TODO(s...@chromium.org): Even with driver model we share these buffers.
> + * Concurrent receiving on multiple active Ethernet devices will not work.
> + * Normally U-Boot does not support this anyway. To fix it in this driver,
> + * nove these buffers and the tx/rx pointers to struct e1000_hw.
> + */
>  DEFINE_ALIGN_BUFFER(struct e1000_tx_desc, tx_base, 16, E1000_BUFFER_ALIGN);
>  DEFINE_ALIGN_BUFFER(struct e1000_rx_desc, rx_base, 16, E1000_BUFFER_ALIGN);
>  DEFINE_ALIGN_BUFFER(unsigned char, packet, 4096, E1000_BUFFER_ALIGN);
>
>  static int tx_tail;
>  static int rx_tail, rx_last;
> +#ifdef CONFIG_DM_ETH
> +static int num_cards;  /* Number of E1000 devices seen so far */
> +#endif
>
>  static struct pci_device_id e1000_supported[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82542) },
> @@ -5279,8 +5289,10 @@ void e1000_get_bus_type(struct e1000_hw *hw)
> }
>  }
>
> +#ifndef CONFIG_DM_ETH
>  /* A list of all registered e1000 devices */
>  static LIST_HEAD(e1000_hw_list);
> +#endif
>
>  static int e1000_init_one(struct e1000_hw *hw, int cardnum, pci_dev_t devno,
>   unsigned char enetaddr[6])
> @@ -5367,6 +5379,7 @@ static void e1000_name(char *str, int cardnum)
> sprintf(str, "e1000#%u", cardnum);
>  }
>
> +#ifndef CONFIG_DM_ETH
>  /**
>  TRANSMIT - Transmit a frame
>  ***/
> @@ -5479,13 +5492,22 @@ struct e1000_hw *e1000_find_card(unsigned int cardnum)
>
> return NULL;
>  }
> +#endif /* nCONFIG_DM_ETH */
>
>  #ifdef CONFIG_CMD_E1000
>  static int do_e1000(cmd_tbl_t *cmdtp, int flag,
> int argc, char * const argv[])
>  {
> unsigned char *mac = NULL;
> +#ifdef CONFIG_DM_ETH
> +   struct eth_pdata *plat;
> +   struct udevice *dev;
> +   char name[30];
> +   int ret;
> +#else
> struct e1000_hw *hw;
> +#endif
> +   int cardnum;
>
> if (argc < 3) {
> cmd_usage(cmdtp);
> @@ -5494,9 +5516,18 @@ static int do_e1000(cmd_tbl_t *cmdtp, int flag,
>
> /* Make sure we can find the requested e1000 card */
> cardnum = simple_strtoul(argv[1], NULL, 10);
> +#ifdef CONFIG_DM_ETH
> +   e1000_name(name, cardnum);
> +   ret = uclass_get_device_by_name(UCLASS_ETH, name, &dev);
> +   if (!ret) {
> +   plat = dev_get_platdata(dev);
> +   mac = plat->enetaddr;
> +   }
> +#else
> hw = e1000_find_card(cardnum);
> if (hw)
> mac = hw->nic->enetaddr;
> +#endif
> if (!mac) {
> printf("e1000: ERROR: No such device: e1000#%s\n", argv[1]);
> return 1;
> @@ -5531,3 +5562,109 @@ U_BOOT_CMD(
> "   - Manage the Intel E1000 PCI device"
>  );
>  #endif /* not CONFIG_CMD_E1000 */
> +
> +#ifdef CONFIG_DM_ETH
> +static int e1000_eth_start(struct udevice *dev)
> +{
> +   struct eth_pdata *plat = dev_get_platdata(dev);
> +   struct e1000_hw *hw = dev_get_priv(dev);
> +
> +   return _e1000_init(hw, plat->enetaddr);
> +}
> +
> +static void e1000_eth_stop(struct udevice *dev)
> +{
> +   struct e1000_hw *hw = dev_get_priv(dev);
> +
> +   _e1000_disable(hw);
> +}
> +
> +static int e1000_eth_send(struct udevice *dev, void *packet, int length)
> +{
> +   struct e1000_hw *hw = dev_get_priv(dev);
> +   int ret;
> +
> +   ret = _e1000_transmit(hw, packet, length);
> +
> +   return ret ? 0 : -ETIMEDOUT;
> +}
> +
> +static int e1000_eth_recv(struct udevice *dev, int flags, uchar **packetp)
> +{
> +   struct e1000_hw *hw = dev_get_priv(dev);
> +   int len;
> +
> +   len = _e1000_poll(hw);
> +   if (len)
> +   *packetp = packet;
> +
> +   return len ? len : -EAGAIN;
> +}
> +
> +static int e1000_free_pkt(struct udevice *dev, uchar *packet, int length)
> +{
> +   struct e1000_hw *hw = dev_get_priv(dev);
> +
> +   fill_rx(hw);
> +
> +   return 0;
> +}
> +
> +static int e1000_eth_probe(struct udevice *dev)
> +{
> +   struct eth_pdata *plat = dev_get_platdata(dev)

Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Bin Meng]

On Sat, Aug 15, 2015 at 10:56 AM, Stephen Warren  wrote:
> On 08/14/2015 05:57 PM, Bin Meng wrote:
>> Hi,
>>
>> On Sat, Aug 15, 2015 at 7:18 AM, Simon Glass  wrote:
>>> Hi,
>>>
>>> On 14 August 2015 at 16:51, Stephen Warren  wrote:
 On 08/14/2015 04:40 PM, Bin Meng wrote:
>
> On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:
>>
>> Hi Stephen,
>>
>> On 14 August 2015 at 10:58, Stephen Warren  wrote:
>>>
>>> On 08/14/2015 10:50 AM, Simon Glass wrote:


 Hi Bin,

 On 14 August 2015 at 03:18, Bin Meng  wrote:
>
>
> Hi,
>
> Currently there are 5 dm serial drivers, all of which are ns16550
> compatible drivers. They are:
>
> serial_omap.c
> serial_dw.c
> serial_tegra.c
> serial_x86.c
> serial_ppc.c
>
> All these drivers are pretty much similar. I think we can justmerge
> these into one ns16550 driver.
>
> If you think this is necessary, I will send a patch series to do this.



 The tegra one is there because it needs an input clock and Stephen
 didn't want to add this to the device tree binding (the kernel has a
 clock framework which gets around this problem).

 After that I followed the same pattern. I would support updating the
 binding to support an input clock. Even with the new clock framework
 in U-Boot it might be painful to fit it into SPL in some cases.
>>>
>>>
>>>
>>> The clock is already in the DT, in both Linux and U-Boot's copy, at
>>> least
>>> for Tegra DTs:
>>>
>>>  uarta: serial@0,70006000 {
>>>  compatible = "nvidia,tegra124-uart", ...
>>> ...
>>>  clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>>>
>>
>> I mean the clock-frequency property. However if there is a plan to
>> implement the clock framework in U-Boot that would be good too.
>>
>
> The clock-frequency is a fixed value on x86 super i/o chipset, and
> fixed on the PCI bus too. But for ARM and PPC, it might get
> dynamically calculated due to different PLL settings. We can implement
> a _weak function like the one in serial_ppc.c get_serial_clock() to
> initialize plat->clock with its return value. The _weak function gets
> clock-frequency from device tree. If there is not, platform codes
> which uses the ns16550 driver should provide the implementation of
> get_serial_clock(). Thoughts?


 There is no clock-frequency property in DT, at least for the Tegra DT
 binding. It looks like some other bindings have it. To obtain the clock
 frequency from DT for Tegra, you'd need to parse the clocks property, find
 the clock driver associated with the phandle in DT, and go and ask that
 clock driver what the clock frequency is.

 I'd prefer not to have a weak function that parses clock-frequency, since
 it's too easy to accidentally use it on systems where parsing that property
 is incorrect.

 Certainly, a generic UART driver can call out to a platform-supplied
 function to retrieve the clock, and we can provide driver-specific
 implementations for x86 super IO and PCI, and generic implementations that
 appropriate drivers can call to parse the clocks or clock-frequency 
 property
 from DT, and finally for Tegra if we can't parse the clocks property right
 now, call the Tegra clock driver directly to look up the value.
>>>
>>> I'm not a big fan of weak functions either. In fact I think with
>>> driver model we should avoid them. If we can't call a uclass to get
>>> the info then perhaps we should wait until we can.
>>>
>>> Pragmatically I wonder if a UART clock frequency would not be a useful
>>> compromise? Some bindings have it, some do not. Maybe we should just
>>> add it?
>>>
>>
>> I am not sure which bindings you are looking at,
>
> The binding for nvidia,tegra20-uart. In the kernel tree, that's at
> Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt.
>
>> but I checked the
>> Power.org ePAPR spec v1.1, the clock-frequency is there specially
>> listed for NS16550 compatible nodes.
>>
>> clock-frequency R  Specifies the frequency (in Hz) of the baud
>> rate generator’s input clock
>>
>> If you don't have such clock-frequency in your device tree, I would
>> say you don't follow the spec.
>
> The binding for Tegra UARTs doesn't inherit from the generic NS16550
> binding, so there's that binding isn't relevant.

The kernel bindings has more like dma channels for Tegra hsuart.
U-Boot does not need this as we just need it as a serial console. We
are not going to transfer some big chunk of data via serial line in
U-Boot. In essence if it is NS16550 compatible device, it should just
use that device binding. But I

Re: [U-Boot] [PATCH v3 2/7] armv8: Add SMC calls infrastructure

[Sergei Temerkhanov]

On Fri, Aug 14, 2015 at 9:56 PM, Simon Glass  wrote:
> Hi,
>
> On 13 August 2015 at 09:14, Sergey Temerkhanov  
> wrote:
>> This commit adds functions issuing calls to firmware. This allows
>> to use services such as PSCI provided by firmware, e.g. ATF
>
> What is PSCI? ATF? SMC? What firmware? Please try to make your commit
> message more helpful to people trying to understand the code you are
> adding.
>

These abbreviations have been introduced by ARM and are used in their
docs. These
functions basically issue calls to the secure monitor (SMC) or
hypervisor (HVC). PSCI
is the Power State Coordination Interface and ATF is ARM Trusted Firmware. SMC/
HVC calls conform to the Calling Convention specification. I'll add
the comments to the
next version of this patch
>>
>> The SMC call can destroy all registers declared temporary by the
>> calling conventions. The clobber list is "x0..x17" because of
>> this
>>
>> Signed-off-by: Sergey Temerkhanov 
>> Signed-off-by: Corey Minyard 
>> Signed-off-by: Radha Mohan Chintakuntla 
>>
>> ---
>>
>> Changes in v3:
>> - Fixed clobber lists (thanks to Corey)
>>
>> Changes in v2: None
>>
>>  arch/arm/cpu/armv8/Makefile   |  1 +
>>  arch/arm/cpu/armv8/fwcall.c   | 77 
>> +++
>>  arch/arm/include/asm/system.h |  8 +
>>  3 files changed, 86 insertions(+)
>>  create mode 100644 arch/arm/cpu/armv8/fwcall.c
>>
>> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
>> index 6466ebb..39a6ce7 100644
>> --- a/arch/arm/cpu/armv8/Makefile
>> +++ b/arch/arm/cpu/armv8/Makefile
>> @@ -14,6 +14,7 @@ obj-y += exceptions.o
>>  obj-y  += cache.o
>>  obj-y  += tlb.o
>>  obj-y  += transition.o
>> +obj-y  += fwcall.o
>>
>>  obj-$(CONFIG_FSL_LSCH3) += fsl-lsch3/
>>  obj-$(CONFIG_ARCH_ZYNQMP) += zynqmp/
>> diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c
>> new file mode 100644
>> index 000..ff0caba
>> --- /dev/null
>> +++ b/arch/arm/cpu/armv8/fwcall.c
>> @@ -0,0 +1,77 @@
>> +/**
>> + * (C) Copyright 2014, Cavium Inc.
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> +**/
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
>> +
>> +/*
>> + * void hvc_call(arg0, arg1...arg7)
>> + *
>> + * issue the hypervisor call
>> + *
>> + * x0~x7: argument list
>> + */
>> +void hvc_call(struct pt_regs *args)
>> +{
>> +   asm volatile(
>> +   "ldr x0, %0\n"
>> +   "ldr x1, %1\n"
>> +   "ldr x2, %2\n"
>> +   "ldr x3, %3\n"
>> +   "ldr x4, %4\n"
>> +   "ldr x5, %5\n"
>> +   "ldr x6, %6\n"
>> +   "ldr x7, %7\n"
>> +   "hvc#0\n"
>> +   "str x0, %0\n"
>> +   "str x1, %1\n"
>> +   "str x2, %2\n"
>> +   "str x3, %3\n"
>> +   : "+m" (args->regs[0]), "+m" (args->regs[1]),
>> + "+m" (args->regs[2]), "+m" (args->regs[3])
>> +   : "m" (args->regs[4]), "m" (args->regs[5]),
>> + "m" (args->regs[6]), "m" (args->regs[7])
>> +   : "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
>> + "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
>> + "x16", "x17");
>> +}
>> +
>> +/*
>> + * void smc_call(arg0, arg1...arg7)
>> + *
>> + * issue the secure monitor call
>> + *
>> + * x0~x7: argument list
>> + */
>> +
>> +void smc_call(struct pt_regs *args)
>> +{
>> +   asm volatile(
>> +   "ldr x0, %0\n"
>> +   "ldr x1, %1\n"
>> +   "ldr x2, %2\n"
>> +   "ldr x3, %3\n"
>> +   "ldr x4, %4\n"
>> +   "ldr x5, %5\n"
>> +   "ldr x6, %6\n"
>> +   "smc#0\n"
>> +   "str x0, %0\n"
>> +   "str x1, %1\n"
>> +   "str x2, %2\n"
>> +   "str x3, %3\n"
>> +   : "+m" (args->regs[0]), "+m" (args->regs[1]),
>> + "+m" (args->regs[2]), "+m" (args->regs[3])
>> +   : "m" (args->regs[4]), "m" (args->regs[5]),
>> + "m" (args->regs[6])
>> +   : "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
>> + "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
>> + "x16", "x17");
>> +}
>> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
>> index 9803686..6b21d90 100644
>> --- a/arch/arm/include/asm/system.h
>> +++ b/arch/arm/include/asm/system.h
>> @@ -1,6 +1,9 @@
>>  #ifndef __ASM_ARM_SYSTEM_H
>>  #define __ASM_ARM_SYSTEM_H
>>
>> +#include 
>> +#include 
>> +
>>  #ifdef CONFIG_ARM64
>>
>>  /*
>> @@ -93,6 +96,11 @@ void smp_kick_all_cpus(void);
>>
>>  void flush_l3_cache(void);
>>
>> +#define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
>> +
>> +void hvc_call(struct pt_regs *args);
>> +void smc_call(struct pt_regs *args);
>
> Please add comments here. W

Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Stephen Warren]

On 08/14/2015 05:57 PM, Bin Meng wrote:
> Hi,
> 
> On Sat, Aug 15, 2015 at 7:18 AM, Simon Glass  wrote:
>> Hi,
>>
>> On 14 August 2015 at 16:51, Stephen Warren  wrote:
>>> On 08/14/2015 04:40 PM, Bin Meng wrote:

 On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:
>
> Hi Stephen,
>
> On 14 August 2015 at 10:58, Stephen Warren  wrote:
>>
>> On 08/14/2015 10:50 AM, Simon Glass wrote:
>>>
>>>
>>> Hi Bin,
>>>
>>> On 14 August 2015 at 03:18, Bin Meng  wrote:


 Hi,

 Currently there are 5 dm serial drivers, all of which are ns16550
 compatible drivers. They are:

 serial_omap.c
 serial_dw.c
 serial_tegra.c
 serial_x86.c
 serial_ppc.c

 All these drivers are pretty much similar. I think we can justmerge
 these into one ns16550 driver.

 If you think this is necessary, I will send a patch series to do this.
>>>
>>>
>>>
>>> The tegra one is there because it needs an input clock and Stephen
>>> didn't want to add this to the device tree binding (the kernel has a
>>> clock framework which gets around this problem).
>>>
>>> After that I followed the same pattern. I would support updating the
>>> binding to support an input clock. Even with the new clock framework
>>> in U-Boot it might be painful to fit it into SPL in some cases.
>>
>>
>>
>> The clock is already in the DT, in both Linux and U-Boot's copy, at
>> least
>> for Tegra DTs:
>>
>>  uarta: serial@0,70006000 {
>>  compatible = "nvidia,tegra124-uart", ...
>> ...
>>  clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>>
>
> I mean the clock-frequency property. However if there is a plan to
> implement the clock framework in U-Boot that would be good too.
>

 The clock-frequency is a fixed value on x86 super i/o chipset, and
 fixed on the PCI bus too. But for ARM and PPC, it might get
 dynamically calculated due to different PLL settings. We can implement
 a _weak function like the one in serial_ppc.c get_serial_clock() to
 initialize plat->clock with its return value. The _weak function gets
 clock-frequency from device tree. If there is not, platform codes
 which uses the ns16550 driver should provide the implementation of
 get_serial_clock(). Thoughts?
>>>
>>>
>>> There is no clock-frequency property in DT, at least for the Tegra DT
>>> binding. It looks like some other bindings have it. To obtain the clock
>>> frequency from DT for Tegra, you'd need to parse the clocks property, find
>>> the clock driver associated with the phandle in DT, and go and ask that
>>> clock driver what the clock frequency is.
>>>
>>> I'd prefer not to have a weak function that parses clock-frequency, since
>>> it's too easy to accidentally use it on systems where parsing that property
>>> is incorrect.
>>>
>>> Certainly, a generic UART driver can call out to a platform-supplied
>>> function to retrieve the clock, and we can provide driver-specific
>>> implementations for x86 super IO and PCI, and generic implementations that
>>> appropriate drivers can call to parse the clocks or clock-frequency property
>>> from DT, and finally for Tegra if we can't parse the clocks property right
>>> now, call the Tegra clock driver directly to look up the value.
>>
>> I'm not a big fan of weak functions either. In fact I think with
>> driver model we should avoid them. If we can't call a uclass to get
>> the info then perhaps we should wait until we can.
>>
>> Pragmatically I wonder if a UART clock frequency would not be a useful
>> compromise? Some bindings have it, some do not. Maybe we should just
>> add it?
>>
> 
> I am not sure which bindings you are looking at,

The binding for nvidia,tegra20-uart. In the kernel tree, that's at
Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt.

> but I checked the
> Power.org ePAPR spec v1.1, the clock-frequency is there specially
> listed for NS16550 compatible nodes.
>
> clock-frequency R  Specifies the frequency (in Hz) of the baud
> rate generator’s input clock
> 
> If you don't have such clock-frequency in your device tree, I would
> say you don't follow the spec.

The binding for Tegra UARTs doesn't inherit from the generic NS16550
binding, so there's that binding isn't relevant.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Bin Meng]

Hi,

On Sat, Aug 15, 2015 at 7:18 AM, Simon Glass  wrote:
> Hi,
>
> On 14 August 2015 at 16:51, Stephen Warren  wrote:
>> On 08/14/2015 04:40 PM, Bin Meng wrote:
>>>
>>> On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:

 Hi Stephen,

 On 14 August 2015 at 10:58, Stephen Warren  wrote:
>
> On 08/14/2015 10:50 AM, Simon Glass wrote:
>>
>>
>> Hi Bin,
>>
>> On 14 August 2015 at 03:18, Bin Meng  wrote:
>>>
>>>
>>> Hi,
>>>
>>> Currently there are 5 dm serial drivers, all of which are ns16550
>>> compatible drivers. They are:
>>>
>>> serial_omap.c
>>> serial_dw.c
>>> serial_tegra.c
>>> serial_x86.c
>>> serial_ppc.c
>>>
>>> All these drivers are pretty much similar. I think we can justmerge
>>> these into one ns16550 driver.
>>>
>>> If you think this is necessary, I will send a patch series to do this.
>>
>>
>>
>> The tegra one is there because it needs an input clock and Stephen
>> didn't want to add this to the device tree binding (the kernel has a
>> clock framework which gets around this problem).
>>
>> After that I followed the same pattern. I would support updating the
>> binding to support an input clock. Even with the new clock framework
>> in U-Boot it might be painful to fit it into SPL in some cases.
>
>
>
> The clock is already in the DT, in both Linux and U-Boot's copy, at
> least
> for Tegra DTs:
>
>  uarta: serial@0,70006000 {
>  compatible = "nvidia,tegra124-uart", ...
> ...
>  clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>

 I mean the clock-frequency property. However if there is a plan to
 implement the clock framework in U-Boot that would be good too.

>>>
>>> The clock-frequency is a fixed value on x86 super i/o chipset, and
>>> fixed on the PCI bus too. But for ARM and PPC, it might get
>>> dynamically calculated due to different PLL settings. We can implement
>>> a _weak function like the one in serial_ppc.c get_serial_clock() to
>>> initialize plat->clock with its return value. The _weak function gets
>>> clock-frequency from device tree. If there is not, platform codes
>>> which uses the ns16550 driver should provide the implementation of
>>> get_serial_clock(). Thoughts?
>>
>>
>> There is no clock-frequency property in DT, at least for the Tegra DT
>> binding. It looks like some other bindings have it. To obtain the clock
>> frequency from DT for Tegra, you'd need to parse the clocks property, find
>> the clock driver associated with the phandle in DT, and go and ask that
>> clock driver what the clock frequency is.
>>
>> I'd prefer not to have a weak function that parses clock-frequency, since
>> it's too easy to accidentally use it on systems where parsing that property
>> is incorrect.
>>
>> Certainly, a generic UART driver can call out to a platform-supplied
>> function to retrieve the clock, and we can provide driver-specific
>> implementations for x86 super IO and PCI, and generic implementations that
>> appropriate drivers can call to parse the clocks or clock-frequency property
>> from DT, and finally for Tegra if we can't parse the clocks property right
>> now, call the Tegra clock driver directly to look up the value.
>
> I'm not a big fan of weak functions either. In fact I think with
> driver model we should avoid them. If we can't call a uclass to get
> the info then perhaps we should wait until we can.
>
> Pragmatically I wonder if a UART clock frequency would not be a useful
> compromise? Some bindings have it, some do not. Maybe we should just
> add it?
>

I am not sure which bindings you are looking at, but I checked the
Power.org ePAPR spec v1.1, the clock-frequency is there specially
listed for NS16550 compatible nodes.

clock-frequency R  Specifies the frequency (in Hz) of the baud
rate generator’s input clock

If you don't have such clock-frequency in your device tree, I would
say you don't follow the spec.

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

[U-Boot] [v3 0/4] spi: cadence_qspi: optimize & fix indirect rd-writes

[Vikas Manocha]

This patchset:
- fixes trigger base & transfer start address register programming. This fix
superseeds the previous patch "spi: cadence_qspi: Fix the indirect ahb trigger
address setting".
- adds support to get fifo width from device tree

Changes in v3:
- removed two patches which were bypassing the sram level check.
- format string in patch corrected 3/4
- added commit message in patch 1/4

Changes in v2:
- rebased to master.
- removed patch "spi: cadence_qspi: read can be independent of fifo width", it
  was implemented in other patchset, in mainline now.

Vikas Manocha (4):
  spi: cadence_qspi: move trigger base configuration in init
  spi: cadence_qspi: fix indirect read/write start address
  spi: cadence_qspi: fix base trigger address & transfer start address
  spi: cadence_qspi: get fifo width from device tree

 arch/arm/dts/socfpga.dtsi  |4 +++-
 arch/arm/dts/stv0991.dts   |4 +++-
 drivers/spi/cadence_qspi.c |   15 +++---
 drivers/spi/cadence_qspi.h |6 --
 drivers/spi/cadence_qspi_apb.c |   42 
 5 files changed, 35 insertions(+), 36 deletions(-)

-- 
1.7.9.5

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

Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Bin Meng]

On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:
> Hi Stephen,
>
> On 14 August 2015 at 10:58, Stephen Warren  wrote:
>> On 08/14/2015 10:50 AM, Simon Glass wrote:
>>>
>>> Hi Bin,
>>>
>>> On 14 August 2015 at 03:18, Bin Meng  wrote:

 Hi,

 Currently there are 5 dm serial drivers, all of which are ns16550
 compatible drivers. They are:

serial_omap.c
serial_dw.c
serial_tegra.c
serial_x86.c
serial_ppc.c

 All these drivers are pretty much similar. I think we can justmerge
 these into one ns16550 driver.

 If you think this is necessary, I will send a patch series to do this.
>>>
>>>
>>> The tegra one is there because it needs an input clock and Stephen
>>> didn't want to add this to the device tree binding (the kernel has a
>>> clock framework which gets around this problem).
>>>
>>> After that I followed the same pattern. I would support updating the
>>> binding to support an input clock. Even with the new clock framework
>>> in U-Boot it might be painful to fit it into SPL in some cases.
>>
>>
>> The clock is already in the DT, in both Linux and U-Boot's copy, at least
>> for Tegra DTs:
>>
>> uarta: serial@0,70006000 {
>> compatible = "nvidia,tegra124-uart", ...
>> ...
>> clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>>
>
> I mean the clock-frequency property. However if there is a plan to
> implement the clock framework in U-Boot that would be good too.
>

The clock-frequency is a fixed value on x86 super i/o chipset, and
fixed on the PCI bus too. But for ARM and PPC, it might get
dynamically calculated due to different PLL settings. We can implement
a _weak function like the one in serial_ppc.c get_serial_clock() to
initialize plat->clock with its return value. The _weak function gets
clock-frequency from device tree. If there is not, platform codes
which uses the ns16550 driver should provide the implementation of
get_serial_clock(). Thoughts?

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

Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Stephen Warren]

On 08/14/2015 05:18 PM, Simon Glass wrote:
> Hi,
> 
> On 14 August 2015 at 16:51, Stephen Warren  wrote:
>> On 08/14/2015 04:40 PM, Bin Meng wrote:
>>>
>>> On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:

 Hi Stephen,

 On 14 August 2015 at 10:58, Stephen Warren  wrote:
>
> On 08/14/2015 10:50 AM, Simon Glass wrote:
>>
>>
>> Hi Bin,
>>
>> On 14 August 2015 at 03:18, Bin Meng  wrote:
>>>
>>>
>>> Hi,
>>>
>>> Currently there are 5 dm serial drivers, all of which are ns16550
>>> compatible drivers. They are:
>>>
>>> serial_omap.c
>>> serial_dw.c
>>> serial_tegra.c
>>> serial_x86.c
>>> serial_ppc.c
>>>
>>> All these drivers are pretty much similar. I think we can justmerge
>>> these into one ns16550 driver.
>>>
>>> If you think this is necessary, I will send a patch series to do this.
>>
>>
>>
>> The tegra one is there because it needs an input clock and Stephen
>> didn't want to add this to the device tree binding (the kernel has a
>> clock framework which gets around this problem).
>>
>> After that I followed the same pattern. I would support updating the
>> binding to support an input clock. Even with the new clock framework
>> in U-Boot it might be painful to fit it into SPL in some cases.
>
>
>
> The clock is already in the DT, in both Linux and U-Boot's copy, at
> least
> for Tegra DTs:
>
>  uarta: serial@0,70006000 {
>  compatible = "nvidia,tegra124-uart", ...
> ...
>  clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>

 I mean the clock-frequency property. However if there is a plan to
 implement the clock framework in U-Boot that would be good too.

>>>
>>> The clock-frequency is a fixed value on x86 super i/o chipset, and
>>> fixed on the PCI bus too. But for ARM and PPC, it might get
>>> dynamically calculated due to different PLL settings. We can implement
>>> a _weak function like the one in serial_ppc.c get_serial_clock() to
>>> initialize plat->clock with its return value. The _weak function gets
>>> clock-frequency from device tree. If there is not, platform codes
>>> which uses the ns16550 driver should provide the implementation of
>>> get_serial_clock(). Thoughts?
>>
>>
>> There is no clock-frequency property in DT, at least for the Tegra DT
>> binding. It looks like some other bindings have it. To obtain the clock
>> frequency from DT for Tegra, you'd need to parse the clocks property, find
>> the clock driver associated with the phandle in DT, and go and ask that
>> clock driver what the clock frequency is.
>>
>> I'd prefer not to have a weak function that parses clock-frequency, since
>> it's too easy to accidentally use it on systems where parsing that property
>> is incorrect.
>>
>> Certainly, a generic UART driver can call out to a platform-supplied
>> function to retrieve the clock, and we can provide driver-specific
>> implementations for x86 super IO and PCI, and generic implementations that
>> appropriate drivers can call to parse the clocks or clock-frequency property
>> from DT, and finally for Tegra if we can't parse the clocks property right
>> now, call the Tegra clock driver directly to look up the value.
> 
> I'm not a big fan of weak functions either. In fact I think with
> driver model we should avoid them. If we can't call a uclass to get
> the info then perhaps we should wait until we can.
> 
> Pragmatically I wonder if a UART clock frequency would not be a useful
> compromise? Some bindings have it, some do not. Maybe we should just
> add it?

There's no need for it; the binding already has a clocks property, from
which the data can be derived. Adding a clock-frequency property would
just result in two sources of the same data. In all likelihood, all
that'd happen is that the two would get out-of-sync, and code wouldn't
know which to trust.

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

[U-Boot] [PATCH v2] efi: Update README.efi to clarify build and test instructions

[Bin Meng]

The doc has a misleading 'make menuconfig' when building the EFI
application and payload. Clarify this and also update information
on test with QEMU.

Signed-off-by: Bin Meng 

---

Changes in v2:
- incorporate comments from Igor, clarify boolean options

 doc/README.efi | 32 +---
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/doc/README.efi b/doc/README.efi
index 7c95579..38b9ab1 100644
--- a/doc/README.efi
+++ b/doc/README.efi
@@ -47,20 +47,25 @@ machine. You can use devices, boot a kernel, etc.
 Build Instructions
 --
 First choose a board that has EFI support and obtain an EFI implementation
-for that board. It will be either 32-bit or 64-bit.
+for that board. It will be either 32-bit or 64-bit. Alternatively, you can
+opt for using QEMU [1] and the OVMF [2], as detailed below.
 
-To build U-Boot as an EFI application (32-bit EFI required), enable
-CONFIG_EFI and CONFIG_EFI_APP. The efi-x86 config is set up for this.
+To build U-Boot as an EFI application (32-bit EFI required), enable CONFIG_EFI
+and CONFIG_EFI_APP. The efi-x86 config (efi-x86_defconfig) is set up for this.
 
-To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), adjust
-an existing config to enable CONFIG_EFI, CONFIG_EFI_STUB and either
-CONFIG_EFI_STUB_32BIT or CONFIG_EFI_STUB_64BIT.
+To build U-Boot as an EFI payload (32-bit or 64-bit EFI can be used), adjust an
+existing config (like qemu-x86_defconfig) to enable CONFIG_EFI, CONFIG_EFI_STUB
+and either CONFIG_EFI_STUB_32BIT or CONFIG_EFI_STUB_64BIT. All of these are
+boolean Kconfig options.
 
 Then build U-Boot as normal, e.g.
 
+For building an EFI application, run:
+   make efi-x86_defconfig
+   make
+
+For building an EFI payload, run:
make qemu-x86_defconfig
-   make menuconfig(or make xconfig if you prefer)
-   # change the settings as above
make
 
 You will end up with one of these files:
@@ -71,8 +76,9 @@ You will end up with one of these files:
 
 Trying it out
 -
-Qemu is an emulator and it can emulate an x86 machine. You can run the
-payload with something like this:
+QEMU is an emulator and it can emulate an x86 machine. Please make sure your
+QEMU version is 2.3.0 or above to test this. You can run the payload with
+something like this:
 
mkdir /tmp/efi
cp /path/to/u-boot*.efi /tmp/efi
@@ -80,7 +86,8 @@ payload with something like this:
 
 Add -nographic if you want to use the terminal for output. Once it starts
 type 'fs0:u-boot-payload.efi' to run the payload or 'fs0:u-boot-app.efi' to
-run the application. 'bios.bin' is the EFI 'BIOS'.
+run the application. 'bios.bin' is the EFI 'BIOS'. Check [2] to obtain a
+prebuilt EFI BIOS for QEMU or you can build one from source as well.
 
 To try it on real hardware, put u-boot-app.efi on a suitable boot medium,
 such as a USB stick. Then you can type something like this to start it:
@@ -235,3 +242,6 @@ common/cmd_efi.c
 Ben Stoltz, Simon Glass
 Google, Inc
 July 2015
+
+[1] http://www.qemu.org
+[2] http://www.tianocore.org/ovmf/
-- 
1.8.2.1

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

Re: [U-Boot] [U-Boot, V3] kconfig: add config option for shell prompt

[Tom Rini]

On Fri, Aug 14, 2015 at 02:59:30PM -0700, York Sun wrote:
 
> On 08/13/2015 06:23 AM, Tom Rini wrote:
> > On Mon, Aug 03, 2015 at 12:36:58PM +0300, Nikita Kiryanov wrote:
> > 
> >> Add option to set shell prompt string from menuconfig and migrate
> >> boards globally.
> >>
> >> The migration is done as follows:
> >> - Boards that explicitly and unconditionally set CONFIG_SYS_PROMPT had the
> >>   entry moved to their defconfig files.
> >> - Boards that defined some kind of #ifdef logic which selects the
> >>   CONFIG_SYS_PROMPT (for example qemu-mips) got an #undef CONFIG_SYS_PROMPT
> >>   right before the #ifdef logic and were left alone.
> >> - This change forces CONFIG_SYS_PROMPT to be a per board decision, and thus
> >>   CONFIG_SYS_PROMPT was removed from all _common.h and _common.h
> >>   files. This results in a streamlined default value across platforms, and
> >>   includes the following files: spear-common, sunxi-common, mv-common,
> >>   ti_armv7_common, tegra-common, at91-sama5_common, and zynq-common.
> >> - Boards that relied on _common.h values of CONFIG_SYS_PROMPT 
> >> were
> >>   not updated in their respective defconfig files under the assumption that
> >>   since they did not explicitly define a value, they're fine with whatever
> >>   the default is.
> >> - On the other hand, boards that relied on a value defined in some
> >>   _common.h file such as woodburn_common, rpi-common,
> >>   bur_am335x_common, ls2085a_common, siemens_am33x_common, and
> >>   omap3_evm_common, had their values moved to the respective defconfig 
> >> files.
> >> - The define V_PROMPT was removed, since it is not used anywhere except for
> >>   assigning a value for CONFIG_SYS_PROMPT.
> >>
> >> Cc: Tom Rini 
> >> Cc: Masahiro Yamada 
> >> Cc: Stefano Babic 
> >> Cc: Igor Grinberg 
> >> Signed-off-by: Nikita Kiryanov 
> > 
> > Applied to u-boot/master, thanks!
> > 
> 
> Tom,
> 
> Looks like an extra file was committed during the merge
> 
> include/configs/odroid_xu3.h.rej

Thanks, I'll push a delete with my next changes.

-- 
Tom


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

Re: [U-Boot] [PATCH] dm: simplify uclass_foreach_dev() implementation

[Simon Glass]

On 12 August 2015 at 08:15, Simon Glass  wrote:
> On 10 August 2015 at 10:09, Masahiro Yamada
>  wrote:
>> This can be simply written with list_for_each_entry(), maybe
>> this macro was not necessary in the first place.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  include/dm/uclass.h | 9 ++---
>>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> Acked-by: Simon Glass 

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

Re: [U-Boot] [PATCH v2] usb: xhci: Fix a potential NULL pointer dereference

[Sergei Temerkhanov]

On Fri, Aug 14, 2015 at 11:46 PM, Marek Vasut  wrote:
> On Friday, August 14, 2015 at 05:14:09 PM, Sergey Temerkhanov wrote:
>> This patch fixes a potential NULL pointer dereference arising on
>> non-present/non-initialized xHCI controllers and adds some error
>> handling to xHCI code
>>
>> Signed-off-by: Sergey Temerkhanov 
>> Signed-off-by: Radha Mohan Chintakuntla 
>>
>> ---
>>
>> Changes in v2:
>> - Add return value check with setting hccr and hcor to NULL
>>
>>  drivers/usb/host/xhci.c | 15 +++
>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
>> index 0b09643..f8e2d70 100644
>> --- a/drivers/usb/host/xhci.c
>> +++ b/drivers/usb/host/xhci.c
>> @@ -199,7 +199,7 @@ int xhci_reset(struct xhci_hcor *hcor)
>>   int ret;
>>
>>   /* Halting the Host first */
>> - debug("// Halt the HC\n");
>> + debug("// Halt the HC: %p\n", hcor);
>>   state = xhci_readl(&hcor->or_usbsts) & STS_HALT;
>>   if (!state) {
>>   cmd = xhci_readl(&hcor->or_usbcmd);
>> @@ -1079,6 +1079,11 @@ int usb_lowlevel_init(int index, enum usb_init_type
>> init, void **controller)
>>
>>   *controller = &xhcic[index];
>>
>> + if (ret) {
>> + ctrl->hccr = NULL;
>> + ctrl->hcor = NULL;
>
> Controller should be set to NULL too, for the sake of being completely 
> precise,
> don't you think so ?

Maybe. Though the only place it's actually used at the moment (there
is also some USB gadget stuff
which seems to rely on EHCI) passes a pointer to a local variable and
checks the return value.
>
>> + }
>> +
>>   return ret;
>>  }
>>
>> @@ -1093,9 +1098,11 @@ int usb_lowlevel_stop(int index)
>>  {
>>   struct xhci_ctrl *ctrl = (xhcic + index);
>>
>> - xhci_lowlevel_stop(ctrl);
>> - xhci_hcd_stop(index);
>> - xhci_cleanup(ctrl);
>> + if (ctrl->hcor) {
>> + xhci_lowlevel_stop(ctrl);
>> + xhci_hcd_stop(index);
>> + xhci_cleanup(ctrl);
>> + }
>>
>>   return 0;
>>  }
>
> Good job, thanks :)
>
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] usb: xhci: Fix a potential NULL pointer dereference

[Marek Vasut]

On Friday, August 14, 2015 at 05:14:09 PM, Sergey Temerkhanov wrote:
> This patch fixes a potential NULL pointer dereference arising on
> non-present/non-initialized xHCI controllers and adds some error
> handling to xHCI code
> 
> Signed-off-by: Sergey Temerkhanov 
> Signed-off-by: Radha Mohan Chintakuntla 
> 
> ---
> 
> Changes in v2:
> - Add return value check with setting hccr and hcor to NULL
> 
>  drivers/usb/host/xhci.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> index 0b09643..f8e2d70 100644
> --- a/drivers/usb/host/xhci.c
> +++ b/drivers/usb/host/xhci.c
> @@ -199,7 +199,7 @@ int xhci_reset(struct xhci_hcor *hcor)
>   int ret;
> 
>   /* Halting the Host first */
> - debug("// Halt the HC\n");
> + debug("// Halt the HC: %p\n", hcor);
>   state = xhci_readl(&hcor->or_usbsts) & STS_HALT;
>   if (!state) {
>   cmd = xhci_readl(&hcor->or_usbcmd);
> @@ -1079,6 +1079,11 @@ int usb_lowlevel_init(int index, enum usb_init_type
> init, void **controller)
> 
>   *controller = &xhcic[index];
> 
> + if (ret) {
> + ctrl->hccr = NULL;
> + ctrl->hcor = NULL;

Controller should be set to NULL too, for the sake of being completely precise,
don't you think so ?

> + }
> +
>   return ret;
>  }
> 
> @@ -1093,9 +1098,11 @@ int usb_lowlevel_stop(int index)
>  {
>   struct xhci_ctrl *ctrl = (xhcic + index);
> 
> - xhci_lowlevel_stop(ctrl);
> - xhci_hcd_stop(index);
> - xhci_cleanup(ctrl);
> + if (ctrl->hcor) {
> + xhci_lowlevel_stop(ctrl);
> + xhci_hcd_stop(index);
> + xhci_cleanup(ctrl);
> + }
> 
>   return 0;
>  }

Good job, thanks :)

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

[U-Boot] [PATCH 1/8] dm: pci: Support selected device/driver binding before relocation

[Bin Meng]

On some platforms pci devices behind bridge need to be probed (eg:
a pci uart on recent x86 chipset) before relocation. But we won't
bind all devices found during the enumeration. Only devices whose
driver with DM_FLAG_PRE_RELOC set will be bound. Any other generic
devices except bridges won't be bound.

Signed-off-by: Bin Meng 
---

 drivers/pci/pci-uclass.c | 41 ++---
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 7d41d56..4160274 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -461,6 +461,7 @@ static int pci_find_and_bind_driver(struct udevice *parent,
int n_ents;
int ret;
char name[30], *str;
+   bool bridge;
 
*devp = NULL;
 
@@ -480,6 +481,17 @@ static int pci_find_and_bind_driver(struct udevice *parent,
continue;
 
drv = entry->driver;
+
+   /*
+* In the pre-relocation phase, we only bind devices
+* whose driver has the DM_FLAG_PRE_RELOC set, to save
+* precious memory space as on some platforms as that
+* space is pretty limited (ie: using Cache As RAM).
+*/
+   if (!(gd->flags & GD_FLG_RELOC) &&
+   !(drv->flags & DM_FLAG_PRE_RELOC))
+   return 0;
+
/*
 * We could pass the descriptor to the driver as
 * platdata (instead of NULL) and allow its bind()
@@ -499,14 +511,23 @@ static int pci_find_and_bind_driver(struct udevice 
*parent,
}
}
 
+   bridge = (find_id->class >> 8) == PCI_CLASS_BRIDGE_PCI;
+   /*
+* In the pre-relocation phase, we only bind bridge devices to save
+* precious memory space as on some platforms as that space is pretty
+* limited (ie: using Cache As RAM).
+*/
+   if (!(gd->flags & GD_FLG_RELOC) && !bridge)
+   return 0;
+
/* Bind a generic driver so that the device can be used */
sprintf(name, "pci_%x:%x.%x", parent->seq, PCI_DEV(bdf),
PCI_FUNC(bdf));
str = strdup(name);
if (!str)
return -ENOMEM;
-   drv = (find_id->class >> 8) == PCI_CLASS_BRIDGE_PCI ? "pci_bridge_drv" :
-   "pci_generic_drv";
+   drv = bridge ? "pci_bridge_drv" : "pci_generic_drv";
+
ret = device_bind_driver(parent, drv, str, devp);
if (ret) {
debug("%s: Failed to bind generic driver: %d", __func__, ret);
@@ -589,11 +610,13 @@ int pci_bind_bus_devices(struct udevice *bus)
return ret;
 
/* Update the platform data */
-   pplat = dev_get_parent_platdata(dev);
-   pplat->devfn = PCI_MASK_BUS(bdf);
-   pplat->vendor = vendor;
-   pplat->device = device;
-   pplat->class = class;
+   if (dev) {
+   pplat = dev_get_parent_platdata(dev);
+   pplat->devfn = PCI_MASK_BUS(bdf);
+   pplat->vendor = vendor;
+   pplat->device = device;
+   pplat->class = class;
+   }
}
 
return 0;
@@ -717,10 +740,6 @@ static int pci_uclass_post_probe(struct udevice *bus)
 {
int ret;
 
-   /* Don't scan buses before relocation */
-   if (!(gd->flags & GD_FLG_RELOC))
-   return 0;
-
debug("%s: probing bus %d\n", __func__, bus->seq);
ret = pci_bind_bus_devices(bus);
if (ret)
-- 
1.8.2.1

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

[U-Boot] [PATCH 2/8] dm: pci: Only allow serial device to be bound before relocation

[Bin Meng]

To further limit the memory space, we only allow serial device
to be bound before relocation.

Signed-off-by: Bin Meng 
---

 drivers/pci/pci-uclass.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 4160274..b7dca0f 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -487,9 +487,13 @@ static int pci_find_and_bind_driver(struct udevice *parent,
 * whose driver has the DM_FLAG_PRE_RELOC set, to save
 * precious memory space as on some platforms as that
 * space is pretty limited (ie: using Cache As RAM).
+*
+* To further limit the memory space, we only allow
+* serial device to be bound.
 */
if (!(gd->flags & GD_FLG_RELOC) &&
-   !(drv->flags & DM_FLAG_PRE_RELOC))
+   !(drv->flags & DM_FLAG_PRE_RELOC) &&
+   (drv->id != UCLASS_SERIAL))
return 0;
 
/*
-- 
1.8.2.1

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

[U-Boot] [PATCH 4/8] x86: fsp: Enlarge the size of malloc() pool before relocation

[Bin Meng]

After fsp_init() returns, the stack has already been switched to a
place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
Enlarge the size of malloc() pool before relocation since we have
plenty of memory now.

Signed-off-by: Bin Meng 
---

 arch/x86/Kconfig  | 7 +++
 arch/x86/cpu/start.S  | 8 
 arch/x86/lib/fsp/fsp_common.c | 6 +-
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 065bbe4..687208f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -232,6 +232,13 @@ config FSP_TEMP_RAM_ADDR
  Stack top address which is used in FspInit after DRAM is ready and
  CAR is disabled.
 
+config FSP_SYS_MALLOC_F_LEN
+   hex
+   depends on HAVE_FSP
+   default 0x10
+   help
+ Additional size of malloc() pool before relocation.
+
 config SMP
bool "Enable Symmetric Multiprocessing"
default n
diff --git a/arch/x86/cpu/start.S b/arch/x86/cpu/start.S
index e94ddc4..e2b5ef4 100644
--- a/arch/x86/cpu/start.S
+++ b/arch/x86/cpu/start.S
@@ -141,6 +141,14 @@ car_init_ret:
jz  skip_hob
movl%esi, GD_HOB_LIST(%edx)
 
+   /*
+* After fsp_init() returns, the stack has already been switched to a
+* place within system memory as defined by CONFIG_FSP_TEMP_RAM_ADDR.
+* Enlarge the size of malloc() pool before relocation since we have
+* plenty of memory now.
+*/
+   subl$CONFIG_FSP_SYS_MALLOC_F_LEN, %esp
+   movl%esp, GD_MALLOC_BASE(%edx)
 skip_hob:
 #else
/* Store table pointer */
diff --git a/arch/x86/lib/fsp/fsp_common.c b/arch/x86/lib/fsp/fsp_common.c
index 6f72c6d..9c316d4 100644
--- a/arch/x86/lib/fsp/fsp_common.c
+++ b/arch/x86/lib/fsp/fsp_common.c
@@ -56,8 +56,12 @@ void board_final_cleanup(void)
 
 int x86_fsp_init(void)
 {
-   if (!gd->arch.hob_list)
+   if (!gd->arch.hob_list) {
fsp_init(CONFIG_FSP_TEMP_RAM_ADDR, BOOT_FULL_CONFIG, NULL);
+   } else {
+   /* We should adjust gd->malloc_limit here */
+   gd->malloc_limit += CONFIG_FSP_SYS_MALLOC_F_LEN;
+   }
 
return 0;
 }
-- 
1.8.2.1

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

Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Simon Glass]

Hi,

On 14 August 2015 at 16:51, Stephen Warren  wrote:
> On 08/14/2015 04:40 PM, Bin Meng wrote:
>>
>> On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 14 August 2015 at 10:58, Stephen Warren  wrote:

 On 08/14/2015 10:50 AM, Simon Glass wrote:
>
>
> Hi Bin,
>
> On 14 August 2015 at 03:18, Bin Meng  wrote:
>>
>>
>> Hi,
>>
>> Currently there are 5 dm serial drivers, all of which are ns16550
>> compatible drivers. They are:
>>
>> serial_omap.c
>> serial_dw.c
>> serial_tegra.c
>> serial_x86.c
>> serial_ppc.c
>>
>> All these drivers are pretty much similar. I think we can justmerge
>> these into one ns16550 driver.
>>
>> If you think this is necessary, I will send a patch series to do this.
>
>
>
> The tegra one is there because it needs an input clock and Stephen
> didn't want to add this to the device tree binding (the kernel has a
> clock framework which gets around this problem).
>
> After that I followed the same pattern. I would support updating the
> binding to support an input clock. Even with the new clock framework
> in U-Boot it might be painful to fit it into SPL in some cases.



 The clock is already in the DT, in both Linux and U-Boot's copy, at
 least
 for Tegra DTs:

  uarta: serial@0,70006000 {
  compatible = "nvidia,tegra124-uart", ...
 ...
  clocks = <&tegra_car TEGRA124_CLK_UARTA>;

>>>
>>> I mean the clock-frequency property. However if there is a plan to
>>> implement the clock framework in U-Boot that would be good too.
>>>
>>
>> The clock-frequency is a fixed value on x86 super i/o chipset, and
>> fixed on the PCI bus too. But for ARM and PPC, it might get
>> dynamically calculated due to different PLL settings. We can implement
>> a _weak function like the one in serial_ppc.c get_serial_clock() to
>> initialize plat->clock with its return value. The _weak function gets
>> clock-frequency from device tree. If there is not, platform codes
>> which uses the ns16550 driver should provide the implementation of
>> get_serial_clock(). Thoughts?
>
>
> There is no clock-frequency property in DT, at least for the Tegra DT
> binding. It looks like some other bindings have it. To obtain the clock
> frequency from DT for Tegra, you'd need to parse the clocks property, find
> the clock driver associated with the phandle in DT, and go and ask that
> clock driver what the clock frequency is.
>
> I'd prefer not to have a weak function that parses clock-frequency, since
> it's too easy to accidentally use it on systems where parsing that property
> is incorrect.
>
> Certainly, a generic UART driver can call out to a platform-supplied
> function to retrieve the clock, and we can provide driver-specific
> implementations for x86 super IO and PCI, and generic implementations that
> appropriate drivers can call to parse the clocks or clock-frequency property
> from DT, and finally for Tegra if we can't parse the clocks property right
> now, call the Tegra clock driver directly to look up the value.

I'm not a big fan of weak functions either. In fact I think with
driver model we should avoid them. If we can't call a uclass to get
the info then perhaps we should wait until we can.

Pragmatically I wonder if a UART clock frequency would not be a useful
compromise? Some bindings have it, some do not. Maybe we should just
add it?

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

[U-Boot] [PATCH 5/8] drivers: serial: Add ns16550 compatible pci uart driver

[Bin Meng]

This adds a new driver to support National Semiconductor 16550
compatible UART device with PCI interface. The initial support
only adds device IDs for Intel Topcliff chipset UART devices.

Signed-off-by: Bin Meng 
---

 drivers/serial/Kconfig  |  9 ++
 drivers/serial/Makefile |  1 +
 drivers/serial/serial_pci.c | 75 +
 3 files changed, 85 insertions(+)
 create mode 100644 drivers/serial/serial_pci.c

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index fd126a8..f2eccdd 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -128,3 +128,12 @@ config X86_SERIAL
  enabled in the device tree with the correct input clock frequency
  provided (default 1843200). Enable this to obtain serial console
  output.
+
+config PCI_SERIAL
+   bool "Support for 16550 serial port on PCI bus"
+   depends on DM_PCI
+   default n
+   help
+ This is the UART driver for ns16550 compatible chipset with PCI
+ interface. This can be enabled in the device tree with the correct
+ properties provided. If unsure, say N.
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 1d1f036..a7e2cd2 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_TEGRA_SERIAL) += serial_tegra.o
 obj-$(CONFIG_UNIPHIER_SERIAL) += serial_uniphier.o
 obj-$(CONFIG_OMAP_SERIAL) += serial_omap.o
 obj-$(CONFIG_X86_SERIAL) += serial_x86.o
+obj-$(CONFIG_PCI_SERIAL) += serial_pci.o
 obj-$(CONFIG_STM32_SERIAL) += serial_stm32.o
 
 ifndef CONFIG_SPL_BUILD
diff --git a/drivers/serial/serial_pci.c b/drivers/serial/serial_pci.c
new file mode 100644
index 000..bc87c9a
--- /dev/null
+++ b/drivers/serial/serial_pci.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2015, Bin Meng 
+ *
+ * This driver aims to support National Semiconductor 16550 compatible
+ * UART device with PCI interface.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static struct pci_device_id supported[] = {
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_UART_0) },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_UART_1) },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_UART_2) },
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_TCF_UART_3) },
+   {}
+};
+
+static const struct udevice_id pci_serial_ids[] = {
+   { .compatible = "pci-uart" },
+   { }
+};
+
+static int pci_serial_ofdata_to_platdata(struct udevice *dev)
+{
+   struct ns16550_platdata *plat = dev_get_platdata(dev);
+   struct fdt_pci_addr pci_addr;
+   u32 bar;
+   int ret;
+
+   /* we prefer to use a memory-mapped register */
+   ret = fdtdec_get_pci_addr(gd->fdt_blob, dev->of_offset,
+ FDT_PCI_SPACE_MEM32, "reg", &pci_addr);
+   if (ret) {
+   /* try if there is any i/o-mapped register */
+   ret = fdtdec_get_pci_addr(gd->fdt_blob, dev->of_offset,
+ FDT_PCI_SPACE_IO, "reg", &pci_addr);
+   if (ret)
+   return ret;
+   }
+
+   ret = fdtdec_get_pci_bar32(gd->fdt_blob, dev->of_offset,
+  &pci_addr, &bar);
+   if (ret)
+   return ret;
+
+   plat->base = bar;
+   plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"reg-shift", 1);
+   plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"clock-frequency", 1843200);
+
+   return 0;
+}
+
+U_BOOT_DRIVER(serial_pci) = {
+   .name = "serial_pci",
+   .id = UCLASS_SERIAL,
+   .of_match = pci_serial_ids,
+   .ofdata_to_platdata = pci_serial_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct ns16550_platdata),
+   .priv_auto_alloc_size = sizeof(struct NS16550),
+   .probe = ns16550_serial_probe,
+   .ops = &ns16550_serial_ops,
+   .flags = DM_FLAG_PRE_RELOC,
+};
+
+U_BOOT_PCI_DEVICE(serial_pci, supported);
-- 
1.8.2.1

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

[U-Boot] [PATCH 01/15] sunxi_nand_spl: Fix CONFIG_SPL_NAND_SUNXI handling

[Hans de Goede]

CONFIG_SPL_NAND_SUPPORT gets used via IS_ENABLED so it must be defined
to 1, rather then just being defined.

While at remove 2 other unused NAND related defines from sunxi-common.h.

Signed-off-by: Hans de Goede 
---
 include/configs/sunxi-common.h | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 1abf73c..3735afb 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -138,15 +138,10 @@
 #define CONFIG_SERIAL_TAG
 
 #if defined(CONFIG_SPL_NAND_SUNXI)
-#define CONFIG_SPL_NAND_DRIVERS
-#define CONFIG_SPL_NAND_SUPPORT
-
-#define CONFIG_SYS_NAND_SPL_KERNEL_OFFS 0x28
+#define CONFIG_SPL_NAND_SUPPORT 1
 #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x008000
-
 #endif
 
-
 /* mmc config */
 #if !defined(CONFIG_UART0_PORT_F)
 #define CONFIG_MMC
-- 
2.4.3

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

[U-Boot] [PATCH 3/8] x86: fsp: Delay x86_fsp_init() call a little bit

[Bin Meng]

Move x86_fsp_init() call after initf_malloc() so that we can fix up
the gd->malloc_limit later.

Signed-off-by: Bin Meng 
---

 common/board_f.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/board_f.c b/common/board_f.c
index c959774..5155013 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -765,9 +765,6 @@ static init_fnc_t init_sequence_f[] = {
 #ifdef CONFIG_OF_CONTROL
fdtdec_setup,
 #endif
-#if defined(CONFIG_X86) && defined(CONFIG_HAVE_FSP)
-   x86_fsp_init,
-#endif
 #ifdef CONFIG_TRACE
trace_early_init,
 #endif
@@ -776,6 +773,9 @@ static init_fnc_t init_sequence_f[] = {
/* TODO: can this go into arch_cpu_init()? */
probecpu,
 #endif
+#if defined(CONFIG_X86) && defined(CONFIG_HAVE_FSP)
+   x86_fsp_init,
+#endif
arch_cpu_init,  /* basic arch cpu dependent setup */
mark_bootstage,
initf_dm,
-- 
1.8.2.1

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

[U-Boot] [PATCH 6/8] drivers: serial: Remove special handling for pci uart in the ns16550 driver

[Bin Meng]

Now we have a dedicated PCI UART driver, remove previous special
handling for PCI UART in the ns16550 driver.

Signed-off-by: Bin Meng 
---

 drivers/serial/ns16550.c | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index c8a77e2..8a5db49 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -363,38 +363,7 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
struct ns16550_platdata *plat = dev->platdata;
fdt_addr_t addr;
 
-   /* try Processor Local Bus device first */
addr = fdtdec_get_addr(gd->fdt_blob, dev->of_offset, "reg");
-#ifdef CONFIG_PCI
-   if (addr == FDT_ADDR_T_NONE) {
-   /* then try pci device */
-   struct fdt_pci_addr pci_addr;
-   u32 bar;
-   int ret;
-
-   /* we prefer to use a memory-mapped register */
-   ret = fdtdec_get_pci_addr(gd->fdt_blob, dev->of_offset,
- FDT_PCI_SPACE_MEM32, "reg",
- &pci_addr);
-   if (ret) {
-   /* try if there is any i/o-mapped register */
-   ret = fdtdec_get_pci_addr(gd->fdt_blob,
- dev->of_offset,
- FDT_PCI_SPACE_IO,
- "reg", &pci_addr);
-   if (ret)
-   return ret;
-   }
-
-   ret = fdtdec_get_pci_bar32(gd->fdt_blob, dev->of_offset,
-  &pci_addr, &bar);
-   if (ret)
-   return ret;
-
-   addr = bar;
-   }
-#endif
-
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
 
-- 
1.8.2.1

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

[U-Boot] [PATCH 7/8] x86: crownbay: Support Topcliff integrated pci uart devices

[Bin Meng]

Use new PCI_SERIAL driver to support Topcliff integrated pci uart
devices on Intel Crown Bay board.

Signed-off-by: Bin Meng 

---

 arch/x86/dts/crownbay.dts  | 8 
 configs/crownbay_defconfig | 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts
index 3af9cc3..841f47e 100644
--- a/arch/x86/dts/crownbay.dts
+++ b/arch/x86/dts/crownbay.dts
@@ -114,7 +114,7 @@
"pci8086,8811",
"pciclass,070002",
"pciclass,0700",
-   "x86-uart";
+   "pci-uart";
reg = <0x00025100 0x0 0x0 0x0 0x0
   0x01025110 0x0 0x0 0x0 0x0>;
reg-shift = <0>;
@@ -127,7 +127,7 @@
"pci8086,8812",
"pciclass,070002",
"pciclass,0700",
-   "x86-uart";
+   "pci-uart";
reg = <0x00025200 0x0 0x0 0x0 0x0
   0x01025210 0x0 0x0 0x0 0x0>;
reg-shift = <0>;
@@ -140,7 +140,7 @@
"pci8086,8813",
"pciclass,070002",
"pciclass,0700",
-   "x86-uart";
+   "pci-uart";
reg = <0x00025300 0x0 0x0 0x0 0x0
   0x01025310 0x0 0x0 0x0 0x0>;
reg-shift = <0>;
@@ -153,7 +153,7 @@
"pci8086,8814",
"pciclass,070002",
"pciclass,0700",
-   "x86-uart";
+   "pci-uart";
reg = <0x00025400 0x0 0x0 0x0 0x0
   0x01025410 0x0 0x0 0x0 0x0>;
reg-shift = <0>;
diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
index aa1232d..9113eb7 100644
--- a/configs/crownbay_defconfig
+++ b/configs/crownbay_defconfig
@@ -19,6 +19,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_CPU=y
 CONFIG_DM_PCI=y
 CONFIG_SPI_FLASH=y
+CONFIG_PCI_SERIAL=y
 CONFIG_VIDEO_VESA=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
 CONFIG_DM_RTC=y
-- 
1.8.2.1

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

[U-Boot] [PATCH 8/8] x86: queensbay: Call fsp_init_phase_pci() again

[Bin Meng]

With driver model pci conversion, the call to FspNotify was dropped.
Now add this call back as this is required by the FSP spec.

Signed-off-by: Bin Meng 
---

 arch/x86/cpu/queensbay/tnc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
index c465642..11f65ad 100644
--- a/arch/x86/cpu/queensbay/tnc.c
+++ b/arch/x86/cpu/queensbay/tnc.c
@@ -80,5 +80,11 @@ void cpu_irq_init(void)
 
 int arch_misc_init(void)
 {
-   return pirq_init();
+   int ret;
+
+   ret =  pirq_init();
+   if (ret)
+   return ret;
+
+   return fsp_init_phase_pci();
 }
-- 
1.8.2.1

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

[U-Boot] [PATCH 03/15] sunxi_nand_spl: We only need to reset the nand chip once

[Hans de Goede]

There is no need to reset the nand chip for every ecc-block read.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 46654e4..56c0be0 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -162,6 +162,16 @@ void nand_init(void)
 NFC_CTL_RESET, MAX_RETRIES)) {
printf("Couldn't initialize nand\n");
}
+
+   /* reset NAND */
+   writel(NFC_SEND_CMD1 | NFC_WAIT_FLAG | NAND_CMD_RESET,
+  SUNXI_NFC_BASE + NFC_CMD);
+
+   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_CMD_INT_FLAG,
+MAX_RETRIES)) {
+   printf("Error timeout waiting for nand reset\n");
+   return;
+   }
 }
 
 static void nand_read_page(unsigned int real_addr, dma_addr_t dst,
@@ -223,16 +233,6 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
return;
}
 
-   /* set CMD  */
-   writel(NFC_SEND_CMD1 | NFC_WAIT_FLAG | NAND_CMD_RESET,
-  SUNXI_NFC_BASE + NFC_CMD);
-
-   if (!check_value(SUNXI_NFC_BASE + NFC_ST, NFC_CMD_INT_FLAG,
-MAX_RETRIES)) {
-   printf("Error while initilizing command interrupt\n");
-   return;
-   }
-
page = real_addr / CONFIG_NAND_SUNXI_SPL_PAGE_SIZE;
column = real_addr % CONFIG_NAND_SUNXI_SPL_PAGE_SIZE;
 
-- 
2.4.3

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

[U-Boot] [PATCH 07/15] sunxi_nand_spl: Turn off clocks when we're done with the nand

[Hans de Goede]

Turn off the nand and dma clocks when we're done with the nand, this
puts the nand and dma controllers back into a clean state for when the
kernel boots.

Without this the kernel will not boot properly when it is build with
dma-controller support.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 9efe904..147d476 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -5,9 +5,10 @@
  * SPDX-License-Identifier: GPL-2.0+
  */
 
+#include 
+#include 
 #include 
 #include 
-#include 
 #include 
 
 /* registers */
@@ -330,4 +331,16 @@ int nand_spl_load_image(uint32_t offs, unsigned int size, 
void *dest)
return ecc_errors ? -1 : 0;
 }
 
-void nand_deselect(void) {}
+void nand_deselect(void)
+{
+   struct sunxi_ccm_reg *const ccm =
+   (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+   clrbits_le32(&ccm->ahb_gate0, (CLK_GATE_OPEN << AHB_GATE_OFFSET_NAND0));
+#ifdef CONFIG_MACH_SUN9I
+   clrbits_le32(&ccm->ahb_gate1, (1 << AHB_GATE_OFFSET_DMA));
+#else
+   clrbits_le32(&ccm->ahb_gate0, (1 << AHB_GATE_OFFSET_DMA));
+#endif
+   clrbits_le32(&ccm->nand0_clk_cfg, CCM_NAND_CTRL_ENABLE | AHB_DIV_1);
+}
-- 
2.4.3

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

[U-Boot] [PATCH 02/15] sunxi_nand_spl: Drop unnecessary temp buf

[Hans de Goede]

nand_spl_load_image() always gets called with either CONFIG_SYS_TEXT_BASE
or spl_image.load_addr as destination, both of which are properly aligened,
and have plenty of space for "overshooting" up to
CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE bytes, as we read in
CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE bytes chunks.

This saves CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE (typically 1k) in
SPL size, which is a lot on the total 24k we have.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 35 ---
 1 file changed, 8 insertions(+), 27 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index ac5f56d..46654e4 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -85,6 +85,7 @@
 
 #define SUNXI_DMA_DDMA_CFG_REG_LOADING  (1 << 31)
 #define SUNXI_DMA_DDMA_CFG_REG_DMA_DEST_DATA_WIDTH_32 (2 << 25)
+#define SUNXI_DMA_DDMA_CFG_REG_DDMA_DST_DRQ_TYPE_DRAM (1 << 16)
 #define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_DATA_WIDTH_32 (2 << 9)
 #define SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_ADDR_MODE_IO (1 << 5)
 #define SUNXI_DMA_DDMA_CFG_REG_DDMA_SRC_DRQ_TYPE_NFC (3 << 0)
@@ -94,10 +95,6 @@
 
 /* minimal "boot0" style NAND support for Allwinner A20 */
 
-/* temporary buffer in internal ram */
-unsigned char temp_buf[CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE]
-   __aligned(0x10) __section(".text#");
-
 /* random seed used by linux */
 const uint16_t random_seed[128] = {
0x2b75, 0x0bd0, 0x5ca3, 0x62d1, 0x1c93, 0x07e9, 0x2162, 0x3a72,
@@ -167,8 +164,8 @@ void nand_init(void)
}
 }
 
-static void nand_read_page(unsigned int real_addr, int syndrome,
-  uint32_t *ecc_errors)
+static void nand_read_page(unsigned int real_addr, dma_addr_t dst,
+  int syndrome, uint32_t *ecc_errors)
 {
uint32_t val;
int ecc_off = 0;
@@ -226,9 +223,6 @@ static void nand_read_page(unsigned int real_addr, int 
syndrome,
return;
}
 
-   /* clear temp_buf */
-   memset(temp_buf, 0, CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE);
-
/* set CMD  */
writel(NFC_SEND_CMD1 | NFC_WAIT_FLAG | NAND_CMD_RESET,
   SUNXI_NFC_BASE + NFC_CMD);
@@ -278,8 +272,7 @@ static void nand_read_page(unsigned int real_addr, int 
syndrome,
writel(SUNXI_NFC_BASE + NFC_IO_DATA,
   SUNXI_DMA_BASE + SUNXI_DMA_SRC_START_ADDR_REG0);
/* read to RAM */
-   writel((uint32_t)temp_buf,
-  SUNXI_DMA_BASE + SUNXI_DMA_DEST_START_ADDRR_REG0);
+   writel(dst, SUNXI_DMA_BASE + SUNXI_DMA_DEST_START_ADDRR_REG0);
writel(SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC
| SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE,
SUNXI_DMA_BASE + SUNXI_DMA_DDMA_PARA_REG0);
@@ -287,6 +280,7 @@ static void nand_read_page(unsigned int real_addr, int 
syndrome,
   SUNXI_DMA_BASE + SUNXI_DMA_DDMA_BC_REG0); /* 1kB */
writel(SUNXI_DMA_DDMA_CFG_REG_LOADING
| SUNXI_DMA_DDMA_CFG_REG_DMA_DEST_DATA_WIDTH_32
+   | SUNXI_DMA_DDMA_CFG_REG_DDMA_DST_DRQ_TYPE_DRAM
| SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_DATA_WIDTH_32
| SUNXI_DMA_DDMA_CFG_REG_DMA_SRC_ADDR_MODE_IO
| SUNXI_DMA_DDMA_CFG_REG_DDMA_SRC_DRQ_TYPE_NFC,
@@ -324,27 +318,14 @@ static void nand_read_page(unsigned int real_addr, int 
syndrome,
 int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
 {
void *current_dest;
-   uint32_t count;
-   uint32_t current_count;
uint32_t ecc_errors = 0;
 
-   memset(dest, 0x0, size); /* clean destination memory */
for (current_dest = dest;
current_dest < (dest + size);
current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
-   nand_read_page(offs, offs
-   < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
-  &ecc_errors);
-   count = current_dest - dest;
-
-   if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
-   current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
-   else
-   current_count = size - count;
-
-   memcpy(current_dest,
-  temp_buf,
-  current_count);
+   nand_read_page(offs, (dma_addr_t)current_dest,
+   offs < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+   &ecc_errors);
offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
}
return ecc_errors ? -1 : 0;
-- 
2.4.3

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

[U-Boot] [PATCH 05/15] sunxi_nand_spl: Use SYS_NAND_SELF_INIT and only do nand init when necessary

[Hans de Goede]

Use SYS_NAND_SELF_INIT and only setup the pinmux and clocks when we are
actually using the nand.

Signed-off-by: Hans de Goede 
---
 board/sunxi/board.c   | 12 +++-
 drivers/mtd/nand/Kconfig  |  1 +
 drivers/mtd/nand/sunxi_nand_spl.c |  2 ++
 3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 680523a..b76bb83 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #if defined CONFIG_VIDEO_LCD_PANEL_I2C && !(defined CONFIG_SPL_BUILD)
@@ -127,6 +128,12 @@ static void nand_clock_setup(void)
setbits_le32(&ccm->ahb_gate0, (CLK_GATE_OPEN << AHB_GATE_OFFSET_NAND0));
setbits_le32(&ccm->nand0_clk_cfg, CCM_NAND_CTRL_ENABLE | AHB_DIV_1);
 }
+
+void board_nand_init(void)
+{
+   nand_pinmux_setup();
+   nand_clock_setup();
+}
 #endif
 
 #ifdef CONFIG_GENERIC_MMC
@@ -453,11 +460,6 @@ void sunxi_board_init(void)
power_failed |= axp221_set_eldo(3, CONFIG_AXP221_ELDO3_VOLT);
 #endif
 
-#ifdef CONFIG_SPL_NAND_SUNXI
-   nand_pinmux_setup();
-   nand_clock_setup();
-#endif
-
printf("DRAM:");
ramsize = sunxi_dram_init();
printf(" %lu MiB\n", ramsize >> 20);
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 41ebfea..18039f7 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -88,6 +88,7 @@ config SPL_NAND_DENALI
 config SPL_NAND_SUNXI
bool "Support for NAND on Allwinner A20 in SPL"
depends on MACH_SUN7I
+   select SYS_NAND_SELF_INIT
---help---
Enable support for NAND. This option allows SPL to read from
sunxi NAND using DMA transfers.
diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index f6f4928..9efe904 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -153,6 +153,8 @@ void nand_init(void)
 {
uint32_t val;
 
+   board_nand_init();
+
val = readl(SUNXI_NFC_BASE + NFC_CTL);
/* enable and reset CTL */
writel(val | NFC_CTL_EN | NFC_CTL_RESET,
-- 
2.4.3

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

[U-Boot] [PATCH 04/15] sunxi_nand_spl: Do not bother writing the spare-area reg in syndrome mode

[Hans de Goede]

In syndrome mode we set the NFC_SEQ bit in the command register, so the
spare-area register is not used. Also the value currently being written is
actual wrong, the ecc sits at "column + CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE"
not just CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE.

So the current code only serves to confuse the user -> remove it.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 56c0be0..f6f4928 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -256,10 +256,7 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
val = readl(SUNXI_NFC_BASE + NFC_CTL);
writel(val | NFC_CTL_RAM_METHOD, SUNXI_NFC_BASE + NFC_CTL);
 
-   if (syndrome) {
-   writel(CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE,
-  SUNXI_NFC_BASE + NFC_SPARE_AREA);
-   } else {
+   if (!syndrome) {
oob_offset = CONFIG_NAND_SUNXI_SPL_PAGE_SIZE
+ (column / CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
* ecc_off;
-- 
2.4.3

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

[U-Boot] [PATCH 08/15] sunxi_nand_spl: Add proper cache flusing

[Hans de Goede]

We are using dma, so we should flush the cache before starting the dma,
and invalidate it once the dma is done.

Things are working without this by mostly luck, but lets not rely on that.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 147d476..663c03e 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -266,6 +266,10 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
writel(oob_offset, SUNXI_NFC_BASE + NFC_SPARE_AREA);
}
 
+   flush_dcache_range(dst,
+  ALIGN(dst + CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE,
+ARCH_DMA_MINALIGN));
+
/* SUNXI_DMA */
writel(0x0, SUNXI_DMA_BASE + SUNXI_DMA_CFG_REG0); /* clr dma cmd */
/* read from REG_IO_DATA */
@@ -311,6 +315,10 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
return;
}
 
+   invalidate_dcache_range(dst,
+   ALIGN(dst + CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE,
+ ARCH_DMA_MINALIGN));
+
if (readl(SUNXI_NFC_BASE + NFC_ECC_ST))
(*ecc_errors)++;
 }
-- 
2.4.3

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

[U-Boot] [PATCH 15/15] sunxi_nand_spl: Add support for backup boot partitions

[Hans de Goede]

The BROM does not care / use bad page markings, instead it deals with
any bad pages in the first erase-block by simply trying to load "boot0"
from the first next erase-block.

This commit implements the same strategy for the sunxi spl nand code,
allowing it to boot from the backup boot partition when the main boot
partition is bad (tested by erasing the main boot partition).

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 5687cd8..a75e674 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -348,6 +348,23 @@ static int nand_read_buffer(uint32_t offs, unsigned int 
size, void *dest,
 
 int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
 {
+   const uint32_t boot_offsets[] = {
+   0 * 1024 * 1024 + CONFIG_SYS_NAND_U_BOOT_OFFS,
+   1 * 1024 * 1024 + CONFIG_SYS_NAND_U_BOOT_OFFS,
+   2 * 1024 * 1024 + CONFIG_SYS_NAND_U_BOOT_OFFS,
+   4 * 1024 * 1024 + CONFIG_SYS_NAND_U_BOOT_OFFS,
+   };
+   int i;
+
+   if (offs == CONFIG_SYS_NAND_U_BOOT_OFFS) {
+   for (i = 0; i < ARRAY_SIZE(boot_offsets); i++) {
+   if (nand_read_buffer(boot_offsets[i], size,
+dest, 1) == 0)
+   return 0;
+   }
+   return -1;
+   }
+
return nand_read_buffer(offs, size, dest, 1);
 }
 
-- 
2.4.3

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

[U-Boot] [PATCH 12/15] sunxi_nand_spl: Properly config page-size in the nand ctl register

[Hans de Goede]

Properly config page-size in the nand ctl register, it seems that things
work fine without doing this, but still lets play it safe and properly
set the page-size.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 9c304f4..34bb1a3 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -42,6 +42,8 @@
 #define NFC_CTL_EN (1 << 0)
 #define NFC_CTL_RESET  (1 << 1)
 #define NFC_CTL_RAM_METHOD (1 << 14)
+#define NFC_CTL_PAGE_SIZE_MASK (0xf << 8)
+#define NFC_CTL_PAGE_SIZE(a)   ((fls(a) - 11) << 8)
 
 
 #define NFC_ECC_EN (1 << 0)
@@ -294,6 +296,9 @@ int nand_spl_load_image(uint32_t offs, unsigned int size, 
void *dest)
void *current_dest;
uint32_t ecc_errors = 0;
 
+   clrsetbits_le32(SUNXI_NFC_BASE + NFC_CTL, NFC_CTL_PAGE_SIZE_MASK,
+   NFC_CTL_PAGE_SIZE(CONFIG_NAND_SUNXI_SPL_PAGE_SIZE));
+
for (current_dest = dest;
current_dest < (dest + size);
current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
-- 
2.4.3

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

[U-Boot] [PATCH 13/15] sunxi_nand_spl: Parametrize lowlevel read functions

[Hans de Goede]

Parametrize the lowlevel nand_read_page function, instead of directly
using the CONFIG_foo settings for page-size, etc. there and add a few
wrappers / helper functions for calling it.

This is a preparation patch for adding auto-detecting of the nand
parameters like the BROM does.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 82 +--
 1 file changed, 45 insertions(+), 37 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 34bb1a3..4cfcdb3 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -179,8 +179,8 @@ void nand_init(void)
}
 }
 
-static void nand_read_page(unsigned int real_addr, dma_addr_t dst,
-  int syndrome, uint32_t *ecc_errors)
+static int nand_read_page(int page_size, int ecc_strength, int ecc_page_size,
+   int addr_cycles, uint32_t real_addr, dma_addr_t dst, int syndrome)
 {
uint32_t val;
int i, ecc_off = 0;
@@ -188,28 +188,26 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
uint16_t rand_seed;
uint32_t page;
uint16_t column;
-   uint32_t oob_offset;
static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
 
for (i = 0; i < ARRAY_SIZE(strengths); i++) {
-   if (CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH == strengths[i]) {
+   if (ecc_strength == strengths[i]) {
ecc_mode = i;
break;
}
}
 
/* HW ECC always request ECC bytes for 1024 bytes blocks */
-   ecc_off = DIV_ROUND_UP(CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH * fls(8 * 
1024), 8);
+   ecc_off = DIV_ROUND_UP(ecc_strength * fls(8 * 1024), 8);
/* HW ECC always work with even numbers of ECC bytes */
ecc_off += (ecc_off & 1);
ecc_off += 4; /* prepad */
 
-   page = real_addr / CONFIG_NAND_SUNXI_SPL_PAGE_SIZE;
-   column = real_addr % CONFIG_NAND_SUNXI_SPL_PAGE_SIZE;
+   page = real_addr / page_size;
+   column = real_addr % page_size;
 
if (syndrome)
-   column += (column / CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
-   * ecc_off;
+   column += (column / ecc_page_size) * ecc_off;
 
/* clear ecc status */
writel(0, SUNXI_NFC_BASE + NFC_ECC_ST);
@@ -227,16 +225,11 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
val = readl(SUNXI_NFC_BASE + NFC_CTL);
writel(val | NFC_CTL_RAM_METHOD, SUNXI_NFC_BASE + NFC_CTL);
 
-   if (!syndrome) {
-   oob_offset = CONFIG_NAND_SUNXI_SPL_PAGE_SIZE
-   + (column / CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
-   * ecc_off;
-   writel(oob_offset, SUNXI_NFC_BASE + NFC_SPARE_AREA);
-   }
+   if (!syndrome)
+   writel(page_size + (column / ecc_page_size) * ecc_off,
+  SUNXI_NFC_BASE + NFC_SPARE_AREA);
 
-   flush_dcache_range(dst,
-  ALIGN(dst + CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE,
-ARCH_DMA_MINALIGN));
+   flush_dcache_range(dst, ALIGN(dst + ecc_page_size, ARCH_DMA_MINALIGN));
 
/* SUNXI_DMA */
writel(0x0, SUNXI_DMA_BASE + SUNXI_DMA_CFG_REG0); /* clr dma cmd */
@@ -248,7 +241,7 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
writel(SUNXI_DMA_DDMA_PARA_REG_SRC_WAIT_CYC
| SUNXI_DMA_DDMA_PARA_REG_SRC_BLK_SIZE,
SUNXI_DMA_BASE + SUNXI_DMA_DDMA_PARA_REG0);
-   writel(CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE,
+   writel(ecc_page_size,
   SUNXI_DMA_BASE + SUNXI_DMA_DDMA_BC_REG0); /* 1kB */
writel(SUNXI_DMA_DDMA_CFG_REG_LOADING
| SUNXI_DMA_DDMA_CFG_REG_DMA_DEST_DATA_WIDTH_32
@@ -267,46 +260,61 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
   SUNXI_NFC_BASE + NFC_ADDR_LOW);
writel((page >> 16) & 0xFF, SUNXI_NFC_BASE + NFC_ADDR_HIGH);
writel(NFC_SEND_CMD1 | NFC_SEND_CMD2 | NFC_DATA_TRANS |
-   NFC_PAGE_CMD | NFC_WAIT_FLAG | (4 << NFC_ADDR_NUM_OFFSET) |
+   NFC_PAGE_CMD | NFC_WAIT_FLAG |
+   ((addr_cycles - 1) << NFC_ADDR_NUM_OFFSET) |
NFC_SEND_ADR | NFC_DATA_SWAP_METHOD | (syndrome ? NFC_SEQ : 0),
SUNXI_NFC_BASE + NFC_CMD);
 
if (!check_value(SUNXI_NFC_BASE + NFC_ST, (1 << 2),
 MAX_RETRIES)) {
printf("Error while initializing dma interrupt\n");
-   return;
+   return -1;
}
 
if (!check_value_negated(SUNXI_DMA_BASE + SUNXI_DMA_CFG_REG0,
 SUNXI_DMA_DDMA_CFG_REG_LOADING, MAX_RETRIES)) {
printf("Error while waiting for dma transfer to finish\n");
-   return;
+  

[U-Boot] [PATCH 14/15] sunxi_nand_spl: Auto detect nand configuration parameters

[Hans de Goede]

Auto detect the nand configuration parameters, like the BROM does.

This allows us to get rid of various Kconfig settings, and is
necessary to support generic boards like the mk802 which have seen
many production runs with different nands.

The full blown u-boot/kernel nand driver uses the nand id to determine
this info, for the SPL we do as the BROM does and simply try a few
standard configs.

Note the table only contains configs which are known to actually be used,
rather then all the configs the BROM tries. This means that it may need
to be updated in the future as we add support for nand on more boards.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/Kconfig  | 23 -
 drivers/mtd/nand/sunxi_nand_spl.c | 42 +++
 2 files changed, 38 insertions(+), 27 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index e3cbc31..a07cbeb 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -95,29 +95,6 @@ config SPL_NAND_SUNXI
Depending on the NAND chip, values like ECC strength and page sizes
have to be configured.
 
-config NAND_SUNXI_SPL_ECC_STRENGTH
-   int "ECC Strength for sunxi NAND"
-   default 40
-   depends on SPL_NAND_SUNXI
-   ---help---
-   ECC strength used by the sunxi NAND SPL driver. This is specific to the
-   chosen NAND chip and has to match the value used by the sunxi BROM.
-
-config NAND_SUNXI_SPL_ECC_PAGE_SIZE
-   hex "ECC page size for sunxi NAND"
-   default 0x400
-   depends on SPL_NAND_SUNXI
-   ---help---
-   ECC page size used by the sunxi NAND SPL driver for syndrome partitions.
-   This setting has to match the value used by the sunxi BROM.
-
-config NAND_SUNXI_SPL_PAGE_SIZE
-   hex "Page size for sunxi NAND"
-   default 0x2000
-   depends on SPL_NAND_SUNXI
-   ---help---
-   Page size of the NAND flash used by the sunxi NAND SPL driver. This is
-   specific to the chosen NAND chip.
 endif
 
 endmenu
diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 4cfcdb3..5687cd8 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -306,10 +306,44 @@ static int nand_read_ecc(int page_size, int ecc_strength, 
int ecc_page_size,
 static int nand_read_buffer(uint32_t offs, unsigned int size, void *dest,
int syndrome)
 {
-   return nand_read_ecc(CONFIG_NAND_SUNXI_SPL_PAGE_SIZE,
-CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH,
-CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE,
-5, offs, size, dest, syndrome);
+   const struct {
+   int page_size;
+   int ecc_strength;
+   int ecc_page_size;
+   int addr_cycles;
+   } nand_configs[] = {
+   { 8192, 40, 1024, 5 },
+   { 8192, 24, 1024, 5 },
+   };
+   static int nand_config = -1;
+   int i;
+
+   if (nand_config == -1) {
+   for (i = 0; i < ARRAY_SIZE(nand_configs); i++) {
+   debug("nand: trying page %d ecc %d / %d addr %d: ",
+ nand_configs[i].page_size,
+ nand_configs[i].ecc_strength,
+ nand_configs[i].ecc_page_size,
+ nand_configs[i].addr_cycles);
+   if (nand_read_ecc(nand_configs[i].page_size,
+ nand_configs[i].ecc_strength,
+ nand_configs[i].ecc_page_size,
+ nand_configs[i].addr_cycles,
+ offs, size, dest, syndrome) == 0) {
+   debug("success\n");
+   nand_config = i;
+   return 0;
+   }
+   debug("failed\n");
+   }
+   return -1;
+   }
+
+   return nand_read_ecc(nand_configs[nand_config].page_size,
+nand_configs[nand_config].ecc_strength,
+nand_configs[nand_config].ecc_page_size,
+nand_configs[nand_config].addr_cycles,
+offs, size, dest, syndrome);
 }
 
 int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
-- 
2.4.3

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

[U-Boot] [PATCH 11/15] sunxi_nand_spl: Add support for sun4i and sun5i SoCs

[Hans de Goede]

Other then having a few less chip-select lines the nand controller
on sun4i, sun5i and sun7i is identical.

Signed-off-by: Hans de Goede 
---
 board/sunxi/board.c  | 12 +---
 drivers/mtd/nand/Kconfig |  4 ++--
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 1ebd0a4..d411e96 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -112,13 +112,19 @@ int dram_init(void)
 static void nand_pinmux_setup(void)
 {
unsigned int pin;
-   for (pin = SUNXI_GPC(0); pin <= SUNXI_GPC(6); pin++)
-   sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_NAND);
 
-   for (pin = SUNXI_GPC(8); pin <= SUNXI_GPC(22); pin++)
+   for (pin = SUNXI_GPC(0); pin <= SUNXI_GPC(19); pin++)
sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_NAND);
 
+#if defined CONFIG_MACH_SUN4I || defined CONFIG_MACH_SUN7I
+   for (pin = SUNXI_GPC(20); pin <= SUNXI_GPC(22); pin++)
+   sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_NAND);
+#endif
+   /* sun4i / sun7i do have a PC23, but it is not used for nand,
+* only sun7i has a PC24 */
+#ifdef CONFIG_MACH_SUN7I
sunxi_gpio_set_cfgpin(SUNXI_GPC(24), SUNXI_GPC_NAND);
+#endif
 }
 
 static void nand_clock_setup(void)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 8a3fae5..e3cbc31 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -86,8 +86,8 @@ config SPL_NAND_DENALI
  for use on SPL.
 
 config SPL_NAND_SUNXI
-   bool "Support for NAND on Allwinner A20 in SPL"
-   depends on MACH_SUN7I
+   bool "Support for NAND on Allwinner SoCs in SPL"
+   depends on MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
select SYS_NAND_SELF_INIT
---help---
Enable support for NAND. This option allows SPL to read from
-- 
2.4.3

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

[U-Boot] [PATCH 10/15] sunxi_nand_spl: Remove NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END

[Hans de Goede]

We currently only use the spl nand code to get u-boot itself, which
_always_ is located on a syndrome partition. Once we figure out how
we are going to store the u-boot env on nand, we may need non syndrome
support, but even then there will likely be better ways to determine
whether to use syndrome or not (e.g. look at the loadaddr passed in).

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/Kconfig  | 8 
 drivers/mtd/nand/sunxi_nand_spl.c | 3 +--
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 18039f7..8a3fae5 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -95,14 +95,6 @@ config SPL_NAND_SUNXI
Depending on the NAND chip, values like ECC strength and page sizes
have to be configured.
 
-config NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END
-   hex "Size of syndrome partitions in sunxi NAND"
-   default 0x40
-   depends on SPL_NAND_SUNXI
-   ---help---
-   End address for boot partitions on NAND. Those partitions have a
-   different random seed that has to match the sunxi BROM setting.
-
 config NAND_SUNXI_SPL_ECC_STRENGTH
int "ECC Strength for sunxi NAND"
default 40
diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 61eb393..9c304f4 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -297,8 +297,7 @@ int nand_spl_load_image(uint32_t offs, unsigned int size, 
void *dest)
for (current_dest = dest;
current_dest < (dest + size);
current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
-   nand_read_page(offs, (dma_addr_t)current_dest,
-   offs < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
+   nand_read_page(offs, (dma_addr_t)current_dest, 1,
&ecc_errors);
offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
}
-- 
2.4.3

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

[U-Boot] [PATCH 09/15] sunxi_nand_spl: Use kernel driver algorithm for determining ecc_mode / _off

[Hans de Goede]

Sync the code for figuring out the ecc_mode and ecc_offset with the kernel
code. Keeping this in sync seems like a good idea in general, and it
fixes / adds support for ecc strengths of 56, 60 and 64 bits.

Signed-off-by: Hans de Goede 
---
 drivers/mtd/nand/sunxi_nand_spl.c | 58 ---
 1 file changed, 12 insertions(+), 46 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand_spl.c 
b/drivers/mtd/nand/sunxi_nand_spl.c
index 663c03e..61eb393 100644
--- a/drivers/mtd/nand/sunxi_nand_spl.c
+++ b/drivers/mtd/nand/sunxi_nand_spl.c
@@ -181,60 +181,26 @@ static void nand_read_page(unsigned int real_addr, 
dma_addr_t dst,
   int syndrome, uint32_t *ecc_errors)
 {
uint32_t val;
-   int ecc_off = 0;
+   int i, ecc_off = 0;
uint16_t ecc_mode = 0;
uint16_t rand_seed;
uint32_t page;
uint16_t column;
uint32_t oob_offset;
+   static const u8 strengths[] = { 16, 24, 28, 32, 40, 48, 56, 60, 64 };
 
-   switch (CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH) {
-   case 16:
-   ecc_mode = 0;
-   ecc_off = 0x20;
-   break;
-   case 24:
-   ecc_mode = 1;
-   ecc_off = 0x2e;
-   break;
-   case 28:
-   ecc_mode = 2;
-   ecc_off = 0x32;
-   break;
-   case 32:
-   ecc_mode = 3;
-   ecc_off = 0x3c;
-   break;
-   case 40:
-   ecc_mode = 4;
-   ecc_off = 0x4a;
-   break;
-   case 48:
-   ecc_mode = 4;
-   ecc_off = 0x52;
-   break;
-   case 56:
-   ecc_mode = 4;
-   ecc_off = 0x60;
-   break;
-   case 60:
-   ecc_mode = 4;
-   ecc_off = 0x0;
-   break;
-   case 64:
-   ecc_mode = 4;
-   ecc_off = 0x0;
-   break;
-   default:
-   ecc_mode = 0;
-   ecc_off = 0;
+   for (i = 0; i < ARRAY_SIZE(strengths); i++) {
+   if (CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH == strengths[i]) {
+   ecc_mode = i;
+   break;
+   }
}
 
-   if (ecc_off == 0) {
-   printf("Unsupported ECC strength (%d)!\n",
-  CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH);
-   return;
-   }
+   /* HW ECC always request ECC bytes for 1024 bytes blocks */
+   ecc_off = DIV_ROUND_UP(CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH * fls(8 * 
1024), 8);
+   /* HW ECC always work with even numbers of ECC bytes */
+   ecc_off += (ecc_off & 1);
+   ecc_off += 4; /* prepad */
 
page = real_addr / CONFIG_NAND_SUNXI_SPL_PAGE_SIZE;
column = real_addr % CONFIG_NAND_SUNXI_SPL_PAGE_SIZE;
-- 
2.4.3

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

[U-Boot] [PATCH v2 3/7] x86: baytrail: Support multiple microcode copies

[Simon Glass]

From: Bin Meng 

Intel FSP has the capability to walk through the microcode blocks
which are passed as the TempRamInit() parameter from U-Boot and
finds the most appropriate microcode which is suitable for the cpu
on which it is running. Now we've seen several steppings for Intel
BayTrail series processors, adding those microcodes to the Intel
BayleyBay and MinnowMax board device tree files.

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

Changes in v2:
- Adjust to use separate nodes for each microcode block

 arch/x86/dts/bayleybay.dts | 6 ++
 arch/x86/dts/minnowmax.dts | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index 8f0e192..d646987 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -230,6 +230,12 @@
update@0 {
 #include "microcode/m0230671117.dtsi"
};
+   update@1 {
+#include "microcode/m0130673322.dtsi"
+   };
+   update@2 {
+#include "microcode/m0130679901.dtsi"
+   };
};
 
 };
diff --git a/arch/x86/dts/minnowmax.dts b/arch/x86/dts/minnowmax.dts
index daac24e..f4e0a35 100644
--- a/arch/x86/dts/minnowmax.dts
+++ b/arch/x86/dts/minnowmax.dts
@@ -256,6 +256,9 @@
update@0 {
 #include "microcode/m0130673322.dtsi"
};
+   update@1 {
+#include "microcode/m0130679901.dtsi"
+   };
};
 
 };
-- 
2.5.0.276.gf5e568e

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

[U-Boot] [PATCH v2 4/7] x86: ifdtool: Check that U-Boot does not overlap other regions

[Simon Glass]

Since U-Boot and its device tree can grow we should check that it does not
overlap the regions above it. Track the ROM offset that U-Boot reaches and
check that other regions (written after U-Boot) do not interfere.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/ifdtool.c | 33 ++---
 1 file changed, 22 insertions(+), 11 deletions(-)

diff --git a/tools/ifdtool.c b/tools/ifdtool.c
index df16616..510a99c 100644
--- a/tools/ifdtool.c
+++ b/tools/ifdtool.c
@@ -706,10 +706,11 @@ int inject_region(char *image, int size, int region_type, 
char *region_fname)
  * 0x so use an address relative to that. For an
  * 8MB ROM the start address is 0xfff8.
  * @write_fname:   Filename to add to the image
+ * @offset_uboot_top:  Offset of the top of U-Boot
  * @return number of bytes written if OK, -ve on error
  */
 static int write_data(char *image, int size, unsigned int addr,
- const char *write_fname)
+ const char *write_fname, int offset_uboot_top)
 {
int write_fd, write_size;
int offset;
@@ -719,6 +720,14 @@ static int write_data(char *image, int size, unsigned int 
addr,
return write_fd;
 
offset = (uint32_t)(addr + size);
+   if (offset_uboot_top && offset_uboot_top >= offset) {
+   fprintf(stderr, "U-Boot image overlaps with region '%s'\n",
+   write_fname);
+   fprintf(stderr,
+   "U-Boot finishes at offset %x, file starts at %x\n",
+   offset_uboot_top, offset);
+   return -EXDEV;
+   }
debug("Writing %s to offset %#x\n", write_fname, offset);
 
if (offset < 0 || offset + write_size > size) {
@@ -756,24 +765,23 @@ static int write_uboot(char *image, int size, struct 
input_file *uboot,
 {
const void *blob;
const char *data;
-   int uboot_size;
+   int uboot_size, fdt_size;
uint32_t *ptr;
int data_size;
int offset;
int node;
-   int ret;
 
-   uboot_size = write_data(image, size, uboot->addr, uboot->fname);
+   uboot_size = write_data(image, size, uboot->addr, uboot->fname, 0);
if (uboot_size < 0)
return uboot_size;
fdt->addr = uboot->addr + uboot_size;
debug("U-Boot size %#x, FDT at %#x\n", uboot_size, fdt->addr);
-   ret = write_data(image, size, fdt->addr, fdt->fname);
-   if (ret < 0)
-   return ret;
+   fdt_size = write_data(image, size, fdt->addr, fdt->fname, 0);
+   if (fdt_size < 0)
+   return fdt_size;
+   blob = (void *)image + (uint32_t)(fdt->addr + size);
 
if (ucode_ptr) {
-   blob = (void *)image + (uint32_t)(fdt->addr + size);
debug("DTB at %lx\n", (char *)blob - image);
node = fdt_node_offset_by_compatible(blob, 0,
 "intel,microcode");
@@ -796,7 +804,7 @@ static int write_uboot(char *image, int size, struct 
input_file *uboot,
  ucode_ptr, ptr[0], ptr[1]);
}
 
-   return 0;
+   return ((char *)blob + fdt_size) - image;
 }
 
 static void print_version(void)
@@ -1113,12 +1121,14 @@ int main(int argc, char *argv[])
}
 
if (mode_write_descriptor)
-   ret = write_data(image, size, -size, desc_fname);
+   ret = write_data(image, size, -size, desc_fname, 0);
 
if (mode_inject)
ret = inject_region(image, size, region_type, inject_fname);
 
if (mode_write) {
+   int offset_uboot_top = 0;
+
for (wr_idx = 0; wr_idx < wr_num; wr_idx++) {
ifile = &input_file[wr_idx];
if (ifile->type == IF_fdt) {
@@ -1126,9 +1136,10 @@ int main(int argc, char *argv[])
} else if (ifile->type == IF_uboot) {
ret = write_uboot(image, size, ifile, fdt,
  ucode_ptr);
+   offset_uboot_top = ret;
} else {
ret = write_data(image, size, ifile->addr,
-ifile->fname);
+ifile->fname, offset_uboot_top);
}
if (ret < 0)
break;
-- 
2.5.0.276.gf5e568e

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

[U-Boot] [PATCH v2 1/7] x86: Correct microcode documentation

[Simon Glass]

This is incorrect since we require the -m parameter to the microcode tool.
Update the two examples to show this.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 doc/README.x86 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86
index e7dc090..8c3e176 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -654,13 +654,13 @@ 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 
+  ./tools/microcode-tool -d microcode.dat -m  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
+   -m all create
 
 These are written to arch/x86/dts/microcode/ by default.
 
-- 
2.5.0.276.gf5e568e

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

[U-Boot] [PATCH] Drop include/configs/odroid_xu3.h.rej

[Simon Glass]

This file made it into mainline by mistake. Drop it.

Signed-off-by: Simon Glass 
---

 include/configs/odroid_xu3.h.rej | 10 --
 1 file changed, 10 deletions(-)
 delete mode 100644 include/configs/odroid_xu3.h.rej

diff --git a/include/configs/odroid_xu3.h.rej b/include/configs/odroid_xu3.h.rej
deleted file mode 100644
index a1c2964..000
--- a/include/configs/odroid_xu3.h.rej
+++ /dev/null
@@ -1,10 +0,0 @@
 include/configs/odroid_xu3.h
-+++ include/configs/odroid_xu3.h
-@@ -10,7 +10,6 @@
- 
- #include "exynos5420-common.h"
- 
--#define CONFIG_SYS_PROMPT "ODROID-XU3 # "
- #define CONFIG_IDENT_STRING   " for ODROID-XU3"
- 
- #define CONFIG_BOARD_COMMON
-- 
2.5.0.276.gf5e568e

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

[U-Boot] [PATCH v2 0/7] x86: Support multiple microcode blobs for FSP

[Simon Glass]

The Intel Firmware Support Package (FSP) requires that microcode be provided
very early before the device tree can be scanned. We already support adding
a pointer to the microcode data in a place where early init code can access.

However this just points into the device tree and can only point to a single
lot of microcode. For boards which may have different CPU types we must
support multiple microcodes and pass all of them to the FSP in one place.

This series implements this by enhancing ifdtool to remove the microcode
from the device tree and place it in a single block that the FSP can use.
It works without making changes to the existing microcode tool or device
tree format.

Collating the microcode is selected automatically when there is more than
one microcode blob in the device tree. This should make it compatible with
existing boards. Future boards (that don't use FSP) may want to change
this but this can be dealt with at the time.

This series include two of Bin's microcode patches, adjusted to fit this
scheme.

Changes in v2:
- Regenerate with microcode tool
- Adjust to use separate nodes for each microcode block
- Enhance ifdtool rather that changing the microcode format

Bin Meng (2):
  x86: baytrail: Add microcode for BayTrail-I D0 stepping
  x86: baytrail: Support multiple microcode copies

Simon Glass (5):
  x86: Correct microcode documentation
  x86: ifdtool: Check that U-Boot does not overlap other regions
  x86: ifdtool: Split microcode linking into its own function
  x86: ifdtool: Support collating microcode into one place
  x86: ifdtool: Drop microcode from the device tree when collating

 Makefile|1 +
 arch/x86/dts/bayleybay.dts  |6 +
 arch/x86/dts/microcode/m0130679901.dtsi | 3284 +++
 arch/x86/dts/minnowmax.dts  |3 +
 doc/README.x86  |4 +-
 tools/ifdtool.c |  238 ++-
 6 files changed, 3494 insertions(+), 42 deletions(-)
 create mode 100644 arch/x86/dts/microcode/m0130679901.dtsi

-- 
2.5.0.276.gf5e568e

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

Re: [U-Boot] [PATCH] Drop include/configs/odroid_xu3.h.rej

[Tom Rini]

On Sat, Aug 15, 2015 at 02:26:20PM -0600, Simon Glass wrote:

> This file made it into mainline by mistake. Drop it.
> 
> Signed-off-by: Simon Glass 

Already fixed locally, thanks tho.

-- 
Tom


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

[U-Boot] [PATCH v2 6/7] x86: ifdtool: Support collating microcode into one place

[Simon Glass]

The Intel Firmware Support Package (FSP) requires that microcode be provided
very early before the device tree can be scanned. We already support adding
a pointer to the microcode data in a place where early init code can access.

However this just points into the device tree and can only point to a single
lot of microcode. For boards which may have different CPU types we must
support multiple microcodes and pass all of them to the FSP in one place.

Enhance ifdtool to scan all the microcode, place it together in the ROM and
update the microcode pointer to point there. This allows us to pass multiple
microcode blocks to the FSP using its existing API.

Enable the flag in the Makefile so that this feature is used by default for
all boards.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 Makefile|  1 +
 tools/ifdtool.c | 65 -
 2 files changed, 56 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index ad51e60..489315c 100644
--- a/Makefile
+++ b/Makefile
@@ -1040,6 +1040,7 @@ IFDTOOL_FLAGS  = -f 0:$(objtree)/u-boot.dtb
 IFDTOOL_FLAGS += -m 0x$(shell $(NM) u-boot |grep _dt_ucode_base_size |cut -d' 
' -f1)
 IFDTOOL_FLAGS += -U $(CONFIG_SYS_TEXT_BASE):$(objtree)/u-boot.bin
 IFDTOOL_FLAGS += -w $(CONFIG_SYS_X86_START16):$(objtree)/u-boot-x86-16bit.bin
+IFDTOOL_FLAGS += -C
 
 ifneq ($(CONFIG_HAVE_INTEL_ME),)
 IFDTOOL_ME_FLAGS  = -D $(srctree)/board/$(BOARDDIR)/descriptor.bin
diff --git a/tools/ifdtool.c b/tools/ifdtool.c
index b794516..d966c56 100644
--- a/tools/ifdtool.c
+++ b/tools/ifdtool.c
@@ -768,6 +768,8 @@ static int scan_ucode(const void *blob, char *ucode_base, 
int *countp,
return -ENOENT;
}
 
+   if (ucode_base)
+   memcpy(ucode, data, data_size);
ucode += data_size;
}
 
@@ -782,15 +784,19 @@ static int scan_ucode(const void *blob, char *ucode_base, 
int *countp,
 }
 
 static int write_ucode(char *image, int size, struct input_file *fdt,
-  int fdt_size, unsigned int ucode_ptr)
+  int fdt_size, unsigned int ucode_ptr,
+  int collate_ucode)
 {
const char *data = NULL;
+   char *ucode_buf;
const void *blob;
+   char *ucode_base;
uint32_t *ptr;
int ucode_size;
int data_size;
int offset;
int count;
+   int ret;
 
blob = (void *)image + (uint32_t)(fdt->addr + size);
 
@@ -805,12 +811,43 @@ static int write_ucode(char *image, int size, struct 
input_file *fdt,
return -ENOENT;
}
 
-   if (count > 1) {
+   if (count > 1 && !collate_ucode) {
fprintf(stderr,
-   "Cannot handle multiple microcode blocks\n");
+   "Cannot handle multiple microcode blocks - please use 
-C flag to collate them\n");
return -EMLINK;
}
 
+   /*
+* Collect the microcode into a buffer and place it immediately above
+* the device tree.
+*/
+   if (collate_ucode && count > 1) {
+   ucode_buf = malloc(ucode_size);
+   if (!ucode_buf) {
+   fprintf(stderr,
+   "Out of memory for microcode (%d bytes)\n",
+   ucode_size);
+   return -ENOMEM;
+   }
+   ret = scan_ucode(blob, ucode_buf, NULL, NULL, NULL);
+   if (ret < 0)
+   return ret;
+
+   debug("Collated %d microcode block(s)\n", count);
+
+   /*
+* Place microcode area immediately above the FDT, aligned
+* to a 16-byte boundary.
+*/
+   ucode_base = (char *)(((unsigned long)blob + fdt_size + 15) &
+   ~15);
+
+   data = ucode_base;
+   data_size = ucode_size;
+   memcpy(ucode_base, ucode_buf, ucode_size);
+   free(ucode_buf);
+   }
+
offset = (uint32_t)(ucode_ptr + size);
ptr = (void *)image + offset;
 
@@ -819,7 +856,8 @@ static int write_ucode(char *image, int size, struct 
input_file *fdt,
debug("Wrote microcode pointer at %x: addr=%x, size=%x\n", ucode_ptr,
  ptr[0], ptr[1]);
 
-   return 0;
+   return (collate_ucode ? data + data_size : (char *)blob + fdt_size) -
+   image;
 }
 
 /**
@@ -837,7 +875,8 @@ static int write_ucode(char *image, int size, struct 
input_file *fdt,
  * @return 0 if OK, -ve on error
  */
 static int write_uboot(char *image, int size, struct input_file *uboot,
-  struct input_file *fdt, unsigned int ucode_ptr)
+  struct input_file *fdt, unsigned int ucode_ptr,
+  int collate_ucode)
 {
const void *blob;
int uboot_size, fdt_size;
@@ -852,8 

[U-Boot] [PATCH v2 5/7] x86: ifdtool: Split microcode linking into its own function

[Simon Glass]

The code to set up the microcode pointer in the ROM shares almost nothing
with the write_uboot() function.

Move it into its own function so it will be easier to extend.

Signed-off-by: Simon Glass 
---

Changes in v2: None

 tools/ifdtool.c | 105 +---
 1 file changed, 78 insertions(+), 27 deletions(-)

diff --git a/tools/ifdtool.c b/tools/ifdtool.c
index 510a99c..b794516 100644
--- a/tools/ifdtool.c
+++ b/tools/ifdtool.c
@@ -746,6 +746,82 @@ static int write_data(char *image, int size, unsigned int 
addr,
return write_size;
 }
 
+static int scan_ucode(const void *blob, char *ucode_base, int *countp,
+ const char **datap, int *data_sizep)
+{
+   const char *data = NULL;
+   int node, count;
+   int data_size;
+   char *ucode;
+
+   for (node = 0, count = 0, ucode = ucode_base; node >= 0; count++) {
+   node = fdt_node_offset_by_compatible(blob, node,
+"intel,microcode");
+   if (node < 0)
+   break;
+
+   data = fdt_getprop(blob, node, "data", &data_size);
+   if (!data) {
+   debug("Missing microcode data in FDT '%s': %s\n",
+ fdt_get_name(blob, node, NULL),
+ fdt_strerror(data_size));
+   return -ENOENT;
+   }
+
+   ucode += data_size;
+   }
+
+   if (countp)
+   *countp = count;
+   if (datap)
+   *datap = data;
+   if (data_sizep)
+   *data_sizep = data_size;
+
+   return ucode - ucode_base;
+}
+
+static int write_ucode(char *image, int size, struct input_file *fdt,
+  int fdt_size, unsigned int ucode_ptr)
+{
+   const char *data = NULL;
+   const void *blob;
+   uint32_t *ptr;
+   int ucode_size;
+   int data_size;
+   int offset;
+   int count;
+
+   blob = (void *)image + (uint32_t)(fdt->addr + size);
+
+   debug("DTB at %lx\n", (char *)blob - image);
+
+   /* Find out about the micrcode we have */
+   ucode_size = scan_ucode(blob, NULL, &count, &data, &data_size);
+   if (ucode_size < 0)
+   return ucode_size;
+   if (!count) {
+   debug("No microcode found in FDT\n");
+   return -ENOENT;
+   }
+
+   if (count > 1) {
+   fprintf(stderr,
+   "Cannot handle multiple microcode blocks\n");
+   return -EMLINK;
+   }
+
+   offset = (uint32_t)(ucode_ptr + size);
+   ptr = (void *)image + offset;
+
+   ptr[0] = (data - image) - size;
+   ptr[1] = data_size;
+   debug("Wrote microcode pointer at %x: addr=%x, size=%x\n", ucode_ptr,
+ ptr[0], ptr[1]);
+
+   return 0;
+}
+
 /**
  * write_uboot() - Write U-Boot, device tree and microcode pointer
  *
@@ -764,12 +840,7 @@ static int write_uboot(char *image, int size, struct 
input_file *uboot,
   struct input_file *fdt, unsigned int ucode_ptr)
 {
const void *blob;
-   const char *data;
int uboot_size, fdt_size;
-   uint32_t *ptr;
-   int data_size;
-   int offset;
-   int node;
 
uboot_size = write_data(image, size, uboot->addr, uboot->fname, 0);
if (uboot_size < 0)
@@ -781,28 +852,8 @@ static int write_uboot(char *image, int size, struct 
input_file *uboot,
return fdt_size;
blob = (void *)image + (uint32_t)(fdt->addr + size);
 
-   if (ucode_ptr) {
-   debug("DTB at %lx\n", (char *)blob - image);
-   node = fdt_node_offset_by_compatible(blob, 0,
-"intel,microcode");
-   if (node < 0) {
-   debug("No microcode found in FDT: %s\n",
- fdt_strerror(node));
-   return -ENOENT;
-   }
-   data = fdt_getprop(blob, node, "data", &data_size);
-   if (!data) {
-   debug("No microcode data found in FDT: %s\n",
- fdt_strerror(data_size));
-   return -ENOENT;
-   }
-   offset = (uint32_t)(ucode_ptr + size);
-   ptr = (void *)image + offset;
-   ptr[0] = (data - image) - size;
-   ptr[1] = data_size;
-   debug("Wrote microcode pointer at %x: addr=%x, size=%x\n",
- ucode_ptr, ptr[0], ptr[1]);
-   }
+   if (ucode_ptr)
+   return write_ucode(image, size, fdt, fdt_size, ucode_ptr);
 
return ((char *)blob + fdt_size) - image;
 }
-- 
2.5.0.276.gf5e568e

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

Re: [U-Boot] [PATCH] arm: mxs: fix mac address of second interface

[Marek Vasut]

On Sunday, August 16, 2015 at 12:16:21 AM, Michael Heimpold wrote:
> In the rare case that an overflow occurs, propagate it.

Hi!

> Signed-off-by: Michael Heimpold 
> Cc: Stefano Babic 
> Cc: Marek Vasut 
> CC: Fabio Estevam 
> ---
>  arch/arm/cpu/arm926ejs/mxs/mxs.c |   12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs.c
> b/arch/arm/cpu/arm926ejs/mxs/mxs.c index b1d8721..42057ad 100644
> --- a/arch/arm/cpu/arm926ejs/mxs/mxs.c
> +++ b/arch/arm/cpu/arm926ejs/mxs/mxs.c
> @@ -238,11 +238,19 @@ int cpu_eth_init(bd_t *bis)
> 
>  __weak void mx28_adjust_mac(int dev_id, unsigned char *mac)
>  {
> + uint32_t data;
> +
>   mac[0] = 0x00;
>   mac[1] = 0x04; /* Use FSL vendor MAC address by default */
> 
> - if (dev_id == 1) /* Let MAC1 be MAC0 + 1 by default */
> - mac[5] += 1;
> + if (dev_id == 1) { /* Let MAC1 be MAC0 + 1 by default */
> + data = (mac[3] << 16) | (mac[4] << 8) | mac[5];
> + data++;
> +
> + mac[3] = (data >> 16) & 0xff;
> + mac[4] = (data >> 8) & 0xff;
> + mac[5] = data & 0xff;
> + }

I'm not very fond of the added complexity. If an overflow happens,
the last nibble just becomes 0x00, which should be okayish. In case
you need some sort of special handling of the ethernet address, I'd
suggest to implement your own thing in board file.

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

[U-Boot] [PATCH] arm: mxs: fix mac address of second interface

[Michael Heimpold]

In the rare case that an overflow occurs, propagate it.

Signed-off-by: Michael Heimpold 
Cc: Stefano Babic 
Cc: Marek Vasut 
CC: Fabio Estevam 
---
 arch/arm/cpu/arm926ejs/mxs/mxs.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/mxs.c b/arch/arm/cpu/arm926ejs/mxs/mxs.c
index b1d8721..42057ad 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxs.c
+++ b/arch/arm/cpu/arm926ejs/mxs/mxs.c
@@ -238,11 +238,19 @@ int cpu_eth_init(bd_t *bis)
 
 __weak void mx28_adjust_mac(int dev_id, unsigned char *mac)
 {
+   uint32_t data;
+
mac[0] = 0x00;
mac[1] = 0x04; /* Use FSL vendor MAC address by default */
 
-   if (dev_id == 1) /* Let MAC1 be MAC0 + 1 by default */
-   mac[5] += 1;
+   if (dev_id == 1) { /* Let MAC1 be MAC0 + 1 by default */
+   data = (mac[3] << 16) | (mac[4] << 8) | mac[5];
+   data++;
+
+   mac[3] = (data >> 16) & 0xff;
+   mac[4] = (data >> 8) & 0xff;
+   mac[5] = data & 0xff;
+   }
 }
 
 #ifdef CONFIG_MX28_FEC_MAC_IN_OCOTP
-- 
1.7.10.4

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

[U-Boot] [PATCH v2 7/7] x86: ifdtool: Drop microcode from the device tree when collating

[Simon Glass]

When ifdtool collates the microcode into one place it effectively creates
a copy of the 'data' properties in the device tree microcode nodes. This
is wasteful since we now have two copies of the microcode in the ROM.

To avoid this, remove the microcode data from the device tree and shrink it
down. This means that there is only one copy and the overall ROM space used
by the microcode does not increase.

Signed-off-by: Simon Glass 
---

Changes in v2:
- Enhance ifdtool rather that changing the microcode format

 tools/ifdtool.c | 55 +--
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/tools/ifdtool.c b/tools/ifdtool.c
index d966c56..1f95203 100644
--- a/tools/ifdtool.c
+++ b/tools/ifdtool.c
@@ -783,6 +783,47 @@ static int scan_ucode(const void *blob, char *ucode_base, 
int *countp,
return ucode - ucode_base;
 }
 
+static int remove_ucode(char *blob)
+{
+   int node, count;
+   int ret;
+
+   /* Keep going until we find no more microcode to remove */
+   do {
+   for (node = 0, count = 0; node >= 0;) {
+   int ret;
+
+   node = fdt_node_offset_by_compatible(blob, node,
+"intel,microcode");
+   if (node < 0)
+   break;
+
+   ret = fdt_delprop(blob, node, "data");
+
+   /*
+* -FDT_ERR_NOTFOUND means we already removed the
+* data for this one, so we just continue.
+* 0 means we did remove it, so offsets may have
+* changed and we need to restart our scan.
+* Anything else indicates an error we should report.
+*/
+   if (ret == -FDT_ERR_NOTFOUND)
+   continue;
+   else if (!ret)
+   node = 0;
+   else
+   return ret;
+   }
+   } while (count);
+
+   /* Pack down to remove excees space */
+   ret = fdt_pack(blob);
+   if (ret)
+   return ret;
+
+   return fdt_totalsize(blob);
+}
+
 static int write_ucode(char *image, int size, struct input_file *fdt,
   int fdt_size, unsigned int ucode_ptr,
   int collate_ucode)
@@ -818,8 +859,8 @@ static int write_ucode(char *image, int size, struct 
input_file *fdt,
}
 
/*
-* Collect the microcode into a buffer and place it immediately above
-* the device tree.
+* Collect the microcode into a buffer, remove it from the device
+* tree and place it immediately above the (now smaller) device tree.
 */
if (collate_ucode && count > 1) {
ucode_buf = malloc(ucode_size);
@@ -833,7 +874,17 @@ static int write_ucode(char *image, int size, struct 
input_file *fdt,
if (ret < 0)
return ret;
 
+   /* Remove the microcode from the device tree */
+   ret = remove_ucode((char *)blob);
+   if (ret < 0) {
+   debug("Could not remove FDT microcode: %s\n",
+ fdt_strerror(ret));
+   return -EINVAL;
+   }
debug("Collated %d microcode block(s)\n", count);
+   debug("Device tree reduced from %x to %x bytes\n",
+ fdt_size, ret);
+   fdt_size = ret;
 
/*
 * Place microcode area immediately above the FDT, aligned
-- 
2.5.0.276.gf5e568e

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

Re: [U-Boot] [PATCH] i2c: adding driver for pxa27x, pxa3xx, pxa25x

[Marcel Ziswiler]

On Wed, 2015-08-12 at 13:43 -0500, Andrew Ruder wrote:
> Cc: Marek Vasut 
> Cc: Heiko Schocher 
> Signed-off-by: Andrew Ruder 
> ---
> 
> This driver was written before the driver model stuff was really
> around (or at
> least based on a U-Boot version that only had very preliminary
> support) so
> there might be some older conventions in use here.  I have tested on
> a PXA270
> board running upstream master with this driver, however - so to some
> extent
> this all still works fine.  Let me know if things need to change to
> be
> accepted, and I'll try to find some time to update!

Apart from the missing commit message.

Signed-off-by: Marcel Ziswiler 

Tested-by: Marcel Ziswiler 
Tested-on: Colibri PXA270 V1.2C, V1.2D, V2.2B, V2.4A on Colibri
Evaluation Board V3.1A
Note: While power I2C works on the older V1.2C version it does not seem
to work on any of the newer ones but this might just be a pin muxing
resp. missing pull up issue.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i2c: adding driver for pxa27x, pxa3xx, pxa25x

[Marcel Ziswiler]

On Sun, 2015-08-16 at 02:57 +0200, Marek Vasut wrote:

> > Apart from the missing commit message.
> > 
> > Signed-off-by: Marcel Ziswiler 
> 
> I think you're misunderstanding the meaning of a SoB line here, the
> SoB
> line is a certificate of origin. You didn't write the driver and/or
> you
> didn't make changes to it, so you don't place your certificate on it
> :)

Yeah, it's kind of late. Should have been an Acked-by of course, sorry.

> > Tested-by: Marcel Ziswiler 
> 
> This one is of course good.
> 
> > Tested-on: Colibri PXA270 V1.2C, V1.2D, V2.2B, V2.4A on Colibri
> 
> Is this some kind of a newly invented tag ? :-)

Well, others have been using that one on and off for a while. So at
least I am not the inventor (;-p).

> > Evaluation Board V3.1A
> > Note: While power I2C works on the older V1.2C version it does not
> seem
> > to work on any of the newer ones but this might just be a pin
> muxing
> > resp. missing pull up issue.
> 
> Very nice. Btw. how do you bootstrap those modules, do you use that
> OpenPXA
> OBM or OBM2 or something else entirely ?

No, I never used any of that crap. Just purely U-Boot even on the
PXA3xx but the PXA270 being just a regular NOR beast is really nothing
special. Just using ye olde BDI2000 if things go awry. Unfortunately my
PXA3xx U-Boot NAND SPL stuff never made it mainline and you since
dropped PXA3xx support entirely. If I ever get some precious time I
might actually re-add those again especially now with Marvell having
committed to keep selling us PXA320 chips to 2020.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i2c: adding driver for pxa27x, pxa3xx, pxa25x

[Marek Vasut]

On Sunday, August 16, 2015 at 02:34:20 AM, Marcel Ziswiler wrote:
> On Wed, 2015-08-12 at 13:43 -0500, Andrew Ruder wrote:
> > Cc: Marek Vasut 
> > Cc: Heiko Schocher 
> > Signed-off-by: Andrew Ruder 
> > ---
> > 
> > This driver was written before the driver model stuff was really
> > around (or at
> > least based on a U-Boot version that only had very preliminary
> > support) so
> > there might be some older conventions in use here.  I have tested on
> > a PXA270
> > board running upstream master with this driver, however - so to some
> > extent
> > this all still works fine.  Let me know if things need to change to
> > be
> > accepted, and I'll try to find some time to update!
> 
> Apart from the missing commit message.
> 
> Signed-off-by: Marcel Ziswiler 

I think you're misunderstanding the meaning of a SoB line here, the SoB
line is a certificate of origin. You didn't write the driver and/or you
didn't make changes to it, so you don't place your certificate on it :)

> Tested-by: Marcel Ziswiler 

This one is of course good.

> Tested-on: Colibri PXA270 V1.2C, V1.2D, V2.2B, V2.4A on Colibri

Is this some kind of a newly invented tag ? :-)

> Evaluation Board V3.1A
> Note: While power I2C works on the older V1.2C version it does not seem
> to work on any of the newer ones but this might just be a pin muxing
> resp. missing pull up issue.

Very nice. Btw. how do you bootstrap those modules, do you use that OpenPXA
OBM or OBM2 or something else entirely ?

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

Re: [U-Boot] [PATCH V2 4/5] dm9000: dm9000_initialize stub

[Marcel Ziswiler]

On Wed, 2015-08-12 at 12:24 -0500, Andrew Ruder wrote:

Just one nitty-gritty detail:

> diff --git a/include/configs/colibri_pxa270.h
> b/include/configs/colibri_pxa270.h
> index e3f0ab0..e7db8cf 100644
> --- a/include/configs/colibri_pxa270.h
> +++ b/include/configs/colibri_pxa270.h
> @@ -67,6 +67,7 @@
>  #define CONFIG_DM9000_BASE   0x0800
>  #define DM9000_IO(CONFIG_DM9000_BASE)
>  #define DM9000_DATA  (CONFIG_DM9000_BASE + 4)
> +#define DM9000_HAS_SROM  1

Colibri PXA270 do not actually have any SROM so this should be defined
to 0 instead.

>  #define  CONFIG_NET_RETRY_COUNT  10

Otherwise for the whole series.

Signed-off-by: Marcel Ziswiler 

Tested-by: Marcel Ziswiler 
Tested-on: Colibri PXA270 V1.2C, V1.2D, V2.2B, V2.4A on Colibri
Evaluation Board V3.1A
Note: I only tested the one default on-module Ethernet instance and
while it all still works OK it feels like the transfer speed is
slightly lower (e.g. from the previous 1.3 MiB/s I now get 1.2 MiB/s).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 4/5] dm9000: dm9000_initialize stub

[Marcel Ziswiler]

On Sun, 2015-08-16 at 02:51 +0200, Marcel Ziswiler wrote:
> On Wed, 2015-08-12 at 12:24 -0500, Andrew Ruder wrote:
> 
> Just one nitty-gritty detail:
> 
> > diff --git a/include/configs/colibri_pxa270.h
> > b/include/configs/colibri_pxa270.h
> > index e3f0ab0..e7db8cf 100644
> > --- a/include/configs/colibri_pxa270.h
> > +++ b/include/configs/colibri_pxa270.h
> > @@ -67,6 +67,7 @@
> >  #define CONFIG_DM9000_BASE 0x0800
> >  #define DM9000_IO  (CONFIG_DM9000_BASE)
> >  #define DM9000_DATA(CONFIG_DM9000_BASE +
> > 4)
> > +#define DM9000_HAS_SROM1
> 
> Colibri PXA270 do not actually have any SROM so this should be
> defined
> to 0 instead.
> 
> >  #defineCONFIG_NET_RETRY_COUNT  10
> 
> Otherwise for the whole series.
> 
> Signed-off-by: Marcel Ziswiler 

This should of course have been an Acked-by, sorry. Will by you some
Guinness in Dublin (;-p).

> Tested-by: Marcel Ziswiler 
> Tested-on: Colibri PXA270 V1.2C, V1.2D, V2.2B, V2.4A on Colibri
> Evaluation Board V3.1A
> Note: I only tested the one default on-module Ethernet instance and
> while it all still works OK it feels like the transfer speed is
> slightly lower (e.g. from the previous 1.3 MiB/s I now get 1.2 
> MiB/s).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] i2c: adding driver for pxa27x, pxa3xx, pxa25x

[Marek Vasut]

On Sunday, August 16, 2015 at 03:13:15 AM, Marcel Ziswiler wrote:
> On Sun, 2015-08-16 at 02:57 +0200, Marek Vasut wrote:
> > > Apart from the missing commit message.
> > > 
> > > Signed-off-by: Marcel Ziswiler 
> > 
> > I think you're misunderstanding the meaning of a SoB line here, the
> > SoB
> > line is a certificate of origin. You didn't write the driver and/or
> > you
> > didn't make changes to it, so you don't place your certificate on it
> > 
> > :)
> 
> Yeah, it's kind of late. Should have been an Acked-by of course, sorry.

I can understand that :)

> > > Tested-by: Marcel Ziswiler 
> > 
> > This one is of course good.
> > 
> > > Tested-on: Colibri PXA270 V1.2C, V1.2D, V2.2B, V2.4A on Colibri
> > 
> > Is this some kind of a newly invented tag ? :-)
> 
> Well, others have been using that one on and off for a while. So at
> least I am not the inventor (;-p).

Heh :)

> > > Evaluation Board V3.1A
> > > Note: While power I2C works on the older V1.2C version it does not
> > 
> > seem
> > 
> > > to work on any of the newer ones but this might just be a pin
> > 
> > muxing
> > 
> > > resp. missing pull up issue.
> > 
> > Very nice. Btw. how do you bootstrap those modules, do you use that
> > OpenPXA
> > OBM or OBM2 or something else entirely ?
> 
> No, I never used any of that crap.

Well sorry it wasn't to your liking ... ;-)

> Just purely U-Boot even on the
> PXA3xx but the PXA270 being just a regular NOR beast is really nothing
> special. Just using ye olde BDI2000 if things go awry. Unfortunately my
> PXA3xx U-Boot NAND SPL stuff never made it mainline and you since
> dropped PXA3xx support entirely. If I ever get some precious time I
> might actually re-add those again especially now with Marvell having
> committed to keep selling us PXA320 chips to 2020.

There is some very rudimentary SPL support in the u-boot-pxa, but it's
really old.

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

[U-Boot] [PATCH 01/11] arm: pxa: clean-up include file order

[Marcel Ziswiler]

Cleaning up order of include files by sorting them alphabetically
keeping in mind to leave common.h on top.

Signed-off-by: Marcel Ziswiler 
---

 arch/arm/cpu/pxa/pxa2xx.c | 4 ++--
 arch/arm/cpu/pxa/timer.c  | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/pxa/pxa2xx.c b/arch/arm/cpu/pxa/pxa2xx.c
index 7e861e2..2f12fb9 100644
--- a/arch/arm/cpu/pxa/pxa2xx.c
+++ b/arch/arm/cpu/pxa/pxa2xx.c
@@ -10,11 +10,11 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 
 /* Flush I/D-cache */
 static void cache_flush(void)
diff --git a/arch/arm/cpu/pxa/timer.c b/arch/arm/cpu/pxa/timer.c
index 11fefd5..7c25e67 100644
--- a/arch/arm/cpu/pxa/timer.c
+++ b/arch/arm/cpu/pxa/timer.c
@@ -6,8 +6,8 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
2.4.3

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

[U-Boot] [PATCH 02/11] arm: pxa: mmc: clean-up include file order

[Marcel Ziswiler]

Cleaning up order of include files by sorting them alphabetically
keeping in mind to leave common.h on top.

Signed-off-by: Marcel Ziswiler 
---

 drivers/mmc/pxa_mmc_gen.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/pxa_mmc_gen.c b/drivers/mmc/pxa_mmc_gen.c
index 25ab0b1..19ae81d 100644
--- a/drivers/mmc/pxa_mmc_gen.c
+++ b/drivers/mmc/pxa_mmc_gen.c
@@ -6,15 +6,13 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
 #include 
-#include 
-
-#include 
-#include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 
 /* PXAMMC Generic default config for various CPUs */
 #if defined(CONFIG_CPU_PXA25X)
-- 
2.4.3

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

[U-Boot] [PATCH 06/11] lcd: pxa: clean-up include file order

[Marcel Ziswiler]

Cleaning up order of include files by sorting them alphabetically
keeping in mind to leave common.h on top.

Signed-off-by: Marcel Ziswiler 
---

 drivers/video/pxa_lcd.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/video/pxa_lcd.c b/drivers/video/pxa_lcd.c
index 64cef37..2799425 100644
--- a/drivers/video/pxa_lcd.c
+++ b/drivers/video/pxa_lcd.c
@@ -11,14 +11,13 @@
 /* ** HEADER FILES */
 //
 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 /* #define DEBUG */
 
-- 
2.4.3

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

[U-Boot] [PATCH 05/11] usb: pxa27x_udc: clean-up include file order

[Marcel Ziswiler]

Cleaning up order of include files by sorting them alphabetically
keeping in mind to leave common.h on top.

Signed-off-by: Marcel Ziswiler 
---

 drivers/usb/gadget/pxa27x_udc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/gadget/pxa27x_udc.c b/drivers/usb/gadget/pxa27x_udc.c
index 9423555..c7b21ae 100644
--- a/drivers/usb/gadget/pxa27x_udc.c
+++ b/drivers/usb/gadget/pxa27x_udc.c
@@ -10,11 +10,10 @@
 
 
 #include 
-#include 
-#include 
-#include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
-- 
2.4.3

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

[U-Boot] [PATCH 03/11] arm: tegra: mmc: clean-up include file order

[Marcel Ziswiler]

Cleaning up order of include files by sorting them alphabetically
keeping in mind to leave common.h on top.

Signed-off-by: Marcel Ziswiler 
---

 drivers/mmc/tegra_mmc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
index 6f8b4d0..078df39 100644
--- a/drivers/mmc/tegra_mmc.c
+++ b/drivers/mmc/tegra_mmc.c
@@ -7,14 +7,14 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
-- 
2.4.3

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

[U-Boot] [PATCH 10/11] arm: pxa: colibri_pxa270: add optional lcd support

[Marcel Ziswiler]

Add optional LCD support. Note that depending on the toolchain used
one might have to drop some other features to stay within the 0x4
size limit.

Signed-off-by: Marcel Ziswiler 
---

 include/configs/colibri_pxa270.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h
index 08ebd76..a8cdde5 100644
--- a/include/configs/colibri_pxa270.h
+++ b/include/configs/colibri_pxa270.h
@@ -19,6 +19,9 @@
 /* Avoid overwriting factory configuration block */
 #define CONFIG_BOARD_SIZE_LIMIT0x4
 
+/* We will never enable dcache because we have to setup MMU first */
+#define CONFIG_SYS_DCACHE_OFF
+
 /*
  * Environment settings
  */
@@ -56,6 +59,16 @@
 #defineCONFIG_CMD_MMC
 #defineCONFIG_CMD_USB
 
+/* LCD support */
+#ifdef CONFIG_LCD
+#define CONFIG_PXA_LCD
+#define CONFIG_PXA_VGA
+#define CONFIG_SYS_WHITE_ON_BLACK
+#define CONFIG_CONSOLE_SCROLL_LINES10
+#define CONFIG_CMD_BMP
+#define CONFIG_LCD_LOGO
+#endif
+
 /*
  * Networking Configuration
  */
-- 
2.4.3

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

[U-Boot] [PATCH 04/11] serial: pxa: clean-up include file order

[Marcel Ziswiler]

Cleaning up order of include files by sorting them alphabetically
keeping in mind to leave common.h on top.

Signed-off-by: Marcel Ziswiler 
---

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

diff --git a/drivers/serial/serial_pxa.c b/drivers/serial/serial_pxa.c
index d514004..8fbcc10 100644
--- a/drivers/serial/serial_pxa.c
+++ b/drivers/serial/serial_pxa.c
@@ -18,12 +18,12 @@
  */
 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
2.4.3

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

[U-Boot] [PATCH 11/11] arm: pxa: colibri_pxa270: add optional i2c support

[Marcel Ziswiler]

This is useful once Andrew's PXA I2C driver gets merged.

Signed-off-by: Marcel Ziswiler 

---

 include/configs/colibri_pxa270.h | 9 +
 1 file changed, 9 insertions(+)

diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h
index a8cdde5..a250541 100644
--- a/include/configs/colibri_pxa270.h
+++ b/include/configs/colibri_pxa270.h
@@ -59,6 +59,15 @@
 #defineCONFIG_CMD_MMC
 #defineCONFIG_CMD_USB
 
+/* I2C support */
+#ifdef CONFIG_SYS_I2C
+#define CONFIG_CMD_I2C
+#define CONFIG_SYS_I2C_PXA
+#define CONFIG_PXA_STD_I2C
+#define CONFIG_PXA_PWR_I2C
+#define CONFIG_SYS_I2C_SPEED   10
+#endif
+
 /* LCD support */
 #ifdef CONFIG_LCD
 #define CONFIG_PXA_LCD
-- 
2.4.3

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

[U-Boot] [PATCH 09/11] arm: pxa: colibri_pxa270: add some more nor flash details

[Marcel Ziswiler]

Add some more NOR flash details like size, bus width and lock/unlock
time outs.

Signed-off-by: Marcel Ziswiler 
---

 include/configs/colibri_pxa270.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h
index e3f0ab0..08ebd76 100644
--- a/include/configs/colibri_pxa270.h
+++ b/include/configs/colibri_pxa270.h
@@ -121,16 +121,20 @@
  */
 #ifdef CONFIG_CMD_FLASH
 #definePHYS_FLASH_10x  /* Flash Bank 
#1 */
+#definePHYS_FLASH_SIZE 0x0200  /* 32 MB */
 #defineCONFIG_SYS_FLASH_BASE   PHYS_FLASH_1
 
 #defineCONFIG_SYS_FLASH_CFI
 #defineCONFIG_FLASH_CFI_DRIVER 1
+#defineCONFIG_SYS_FLASH_CFI_WIDTH  FLASH_CFI_32BIT
 
 #defineCONFIG_SYS_MAX_FLASH_SECT   (4 + 255)
 #defineCONFIG_SYS_MAX_FLASH_BANKS  1
 
 #defineCONFIG_SYS_FLASH_ERASE_TOUT (25 * CONFIG_SYS_HZ)
 #defineCONFIG_SYS_FLASH_WRITE_TOUT (25 * CONFIG_SYS_HZ)
+#defineCONFIG_SYS_FLASH_LOCK_TOUT  (25 * CONFIG_SYS_HZ)
+#defineCONFIG_SYS_FLASH_UNLOCK_TOUT(25 * CONFIG_SYS_HZ)
 
 #defineCONFIG_SYS_FLASH_USE_BUFFER_WRITE   1
 #defineCONFIG_SYS_FLASH_PROTECTION 1
-- 
2.4.3

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

Re: [U-Boot] [PATCH 07/11] arm: pxa: colibri_pxa270: fix boot hang

[Marek Vasut]

On Sunday, August 16, 2015 at 04:16:32 AM, Marcel Ziswiler wrote:
> Fix boot hang caused by incompatible libgcc which has been observed
> when using later Linaro toolchains like
> gcc-linaro-arm-linux-gnueabihf-2012.09-20120921_linux or
> gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.

That's no surprise, since U-Boot links libgcc into itself. And since PXA2xx
is armv5-compatible, you'd need armv5 toolchain. The hang you're observing
is most likely happening in some aeabi_* function pulled in from libgcc,
which contains some armv7 instruction(s), which in turn upsets the xscale.

I would suggest that we drop this patch, but I would also suggest that we do
the same thing kernel does and just enable CONFIG_USE_PRIVATE_LIBGCC globally 
for everyone to break this constant nonsensical influx of toolchain-related 
problems. This nonsense has been dragging on for too long. Tom? Albert?

> Signed-off-by: Marcel Ziswiler 
> ---
> 
>  configs/colibri_pxa270_defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configs/colibri_pxa270_defconfig
> b/configs/colibri_pxa270_defconfig index 3963a50..2ef9ccb 100644
> --- a/configs/colibri_pxa270_defconfig
> +++ b/configs/colibri_pxa270_defconfig
> @@ -4,3 +4,4 @@ CONFIG_TARGET_COLIBRI_PXA270=y
>  # CONFIG_CMD_LOADB is not set
>  # CONFIG_CMD_LOADS is not set
>  # CONFIG_CMD_SETEXPR is not set
> +CONFIG_USE_PRIVATE_LIBGCC=y

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

[U-Boot] [PATCH 07/11] arm: pxa: colibri_pxa270: fix boot hang

[Marcel Ziswiler]

Fix boot hang caused by incompatible libgcc which has been observed
when using later Linaro toolchains like
gcc-linaro-arm-linux-gnueabihf-2012.09-20120921_linux or
gcc-linaro-4.9-2014.11-x86_64_arm-linux-gnueabihf.

Signed-off-by: Marcel Ziswiler 
---

 configs/colibri_pxa270_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/colibri_pxa270_defconfig b/configs/colibri_pxa270_defconfig
index 3963a50..2ef9ccb 100644
--- a/configs/colibri_pxa270_defconfig
+++ b/configs/colibri_pxa270_defconfig
@@ -4,3 +4,4 @@ CONFIG_TARGET_COLIBRI_PXA270=y
 # CONFIG_CMD_LOADB is not set
 # CONFIG_CMD_LOADS is not set
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_USE_PRIVATE_LIBGCC=y
-- 
2.4.3

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

[U-Boot] [PATCH 08/11] arm: pxa: palmtreo680: get rid of obsolete CONFIG_SYS_LCD_PXA_NO_L_BIAS

[Marcel Ziswiler]

Looks like the define CONFIG_SYS_LCD_PXA_NO_L_BIAS is not used anywhere
else throughout the U-Boot sources any more. Drop it.

Signed-off-by: Marcel Ziswiler 
---

 include/configs/palmtreo680.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/palmtreo680.h b/include/configs/palmtreo680.h
index 3946607..9842eb0 100644
--- a/include/configs/palmtreo680.h
+++ b/include/configs/palmtreo680.h
@@ -67,7 +67,6 @@
 #define CONFIG_PXA_LCD
 #define CONFIG_ACX544AKN
 #define CONFIG_LCD_LOGO
-#define CONFIG_SYS_LCD_PXA_NO_L_BIAS /* don't configure GPIO77 as L_BIAS */
 #define LCD_BPP LCD_COLOR16
 #define CONFIG_FB_ADDR 0x5c00/* internal SRAM */
 #define CONFIG_CMD_BMP
-- 
2.4.3

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

[U-Boot] [PATCH 4/6] sf: Optimize BAR write code

[Jagan Teki]

Optimized spi-flash bar writing code and also removed
unnecessary bank_sel in read_ops.

Signed-off-by: Jagan Teki 
Cc: Simon Glass 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
---
 drivers/mtd/spi/sf_ops.c | 43 +--
 1 file changed, 13 insertions(+), 30 deletions(-)

diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index 5cb4ef6..f1be815 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -94,15 +94,14 @@ int spi_flash_cmd_write_config(struct spi_flash *flash, u8 
wc)
 #endif
 
 #ifdef CONFIG_SPI_FLASH_BAR
-static int spi_flash_cmd_bankaddr_write(struct spi_flash *flash, u8 bank_sel)
+static int spi_flash_write_bank(struct spi_flash *flash, u32 offset)
 {
-   u8 cmd;
+   u8 cmd, bank_sel;
int ret;
 
-   if (flash->bank_curr == bank_sel) {
-   debug("SF: not require to enable bank%d\n", bank_sel);
-   return bank_sel;
-   }
+   bank_sel = offset / (SPI_FLASH_16MB_BOUN << flash->shift);
+   if (bank_sel == flash->bank_curr)
+   goto bar_end;
 
cmd = flash->bank_write_cmd;
ret = spi_flash_write_common(flash, &cmd, 1, &bank_sel, 1);
@@ -110,25 +109,10 @@ static int spi_flash_cmd_bankaddr_write(struct spi_flash 
*flash, u8 bank_sel)
debug("SF: fail to write bank register\n");
return ret;
}
-   flash->bank_curr = bank_sel;
-
-   return 0;
-}
-
-static int spi_flash_bank(struct spi_flash *flash, u32 offset)
-{
-   u8 bank_sel;
-   int ret;
-
-   bank_sel = offset / (SPI_FLASH_16MB_BOUN << flash->shift);
-
-   ret = spi_flash_cmd_bankaddr_write(flash, bank_sel);
-   if (ret) {
-   debug("SF: fail to set bank%d\n", bank_sel);
-   return ret;
-   }
 
-   return bank_sel;
+bar_end:
+   flash->bank_curr = bank_sel;
+   return flash->bank_curr;
 }
 #endif
 
@@ -284,7 +268,7 @@ int spi_flash_cmd_erase_ops(struct spi_flash *flash, u32 
offset, size_t len)
spi_flash_dual_flash(flash, &erase_addr);
 #endif
 #ifdef CONFIG_SPI_FLASH_BAR
-   ret = spi_flash_bank(flash, erase_addr);
+   ret = spi_flash_write_bank(flash, erase_addr);
if (ret < 0)
return ret;
 #endif
@@ -326,7 +310,7 @@ int spi_flash_cmd_write_ops(struct spi_flash *flash, u32 
offset,
spi_flash_dual_flash(flash, &write_addr);
 #endif
 #ifdef CONFIG_SPI_FLASH_BAR
-   ret = spi_flash_bank(flash, write_addr);
+   ret = spi_flash_write_bank(flash, write_addr);
if (ret < 0)
return ret;
 #endif
@@ -383,7 +367,6 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
 {
u8 *cmd, cmdsz;
u32 remain_len, read_len, read_addr;
-   int bank_sel = 0;
int ret = -1;
 
/* Handle memory-mapped SPI */
@@ -416,12 +399,12 @@ int spi_flash_cmd_read_ops(struct spi_flash *flash, u32 
offset,
spi_flash_dual_flash(flash, &read_addr);
 #endif
 #ifdef CONFIG_SPI_FLASH_BAR
-   bank_sel = spi_flash_bank(flash, read_addr);
-   if (bank_sel < 0)
+   ret = spi_flash_write_bank(flash, read_addr);
+   if (ret < 0)
return ret;
 #endif
remain_len = ((SPI_FLASH_16MB_BOUN << flash->shift) *
-   (bank_sel + 1)) - offset;
+   (flash->bank_curr + 1)) - offset;
if (len < remain_len)
read_len = len;
else
-- 
1.9.1

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

[U-Boot] [PATCH 3/6] sf: Make BAR discovery, as spi_flash_read_bar

[Jagan Teki]

Add spi_flash_read_bar function for reading bar and discovering
bar commands at probe time.

Signed-off-by: Jagan Teki 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
---
 drivers/mtd/spi/sf_probe.c | 54 ++
 1 file changed, 35 insertions(+), 19 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index e0283dc..0483bed 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -99,6 +99,37 @@ static int spi_flash_set_qeb(struct spi_flash *flash, u8 
idcode0)
}
 }
 
+#ifdef CONFIG_SPI_FLASH_BAR
+static int spi_flash_read_bank(struct spi_flash *flash, u8 idcode0)
+{
+   u8 curr_bank = 0;
+   int ret;
+
+   if (flash->size <= SPI_FLASH_16MB_BOUN)
+   goto bank_end;
+
+   switch (idcode0) {
+   case SPI_FLASH_CFI_MFR_SPANSION:
+   flash->bank_read_cmd = CMD_BANKADDR_BRRD;
+   flash->bank_write_cmd = CMD_BANKADDR_BRWR;
+   default:
+   flash->bank_read_cmd = CMD_EXTNADDR_RDEAR;
+   flash->bank_write_cmd = CMD_EXTNADDR_WREAR;
+   }
+
+   ret = spi_flash_read_common(flash, &flash->bank_read_cmd, 1,
+   &curr_bank, 1);
+   if (ret) {
+   debug("SF: fail to read bank addr register\n");
+   return ret;
+   }
+
+bank_end:
+   flash->bank_curr = curr_bank;
+   return 0;
+}
+#endif
+
 static int spi_flash_validate_params(struct spi_slave *spi, u8 *idcode,
 struct spi_flash *flash)
 {
@@ -106,6 +137,7 @@ static int spi_flash_validate_params(struct spi_slave *spi, 
u8 *idcode,
u8 cmd;
u16 jedec = idcode[1] << 8 | idcode[2];
u16 ext_jedec = idcode[3] << 8 | idcode[4];
+   int ret;
 
/* Validate params from spi_flash_params table */
params = spi_flash_params_table;
@@ -235,25 +267,9 @@ static int spi_flash_validate_params(struct spi_slave 
*spi, u8 *idcode,
 
/* Configure the BAR - discover bank cmds and read current bank */
 #ifdef CONFIG_SPI_FLASH_BAR
-   u8 curr_bank = 0;
-   if (flash->size > SPI_FLASH_16MB_BOUN) {
-   int ret;
-
-   flash->bank_read_cmd = (idcode[0] == 0x01) ?
-   CMD_BANKADDR_BRRD : CMD_EXTNADDR_RDEAR;
-   flash->bank_write_cmd = (idcode[0] == 0x01) ?
-   CMD_BANKADDR_BRWR : CMD_EXTNADDR_WREAR;
-
-   ret = spi_flash_read_common(flash, &flash->bank_read_cmd, 1,
-   &curr_bank, 1);
-   if (ret) {
-   debug("SF: fail to read bank addr register\n");
-   return ret;
-   }
-   flash->bank_curr = curr_bank;
-   } else {
-   flash->bank_curr = curr_bank;
-   }
+   ret = spi_flash_read_bank(flash, idcode[0]);
+   if (ret < 0)
+   return ret;
 #endif
 
/* Flash powers up read-only, so clear BP# bits */
-- 
1.9.1

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

[U-Boot] [PATCH 6/6] sf: Update spi_flash_cmd_wait_ready

[Jagan Teki]

Current flash wait_ready logic is not modular to add new
register status check, hence few of the logic is used from
Linux spi-nor framework.

Below are the sf speed runs with 'sf update' on whole flash, 16MiB.

=> sf update 0x100 0x0 0x100
device 0 whole chip
16777216 bytes written, 0 bytes skipped in 61.784s, speed 279620 B/s

=> sf update 0x100 0x0 0x100
device 0 whole chip
16777216 bytes written, 0 bytes skipped in 61.276s, speed 284359 B/s

Signed-off-by: Jagan Teki 
Cc: Simon Glass 
Cc: Marek Vasut 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Cc: Stefan Roese 
Cc: Tom Warren 
Cc: Bin Meng 
Cc: Tom Rini 
Tested-by: Jagan Teki 
---
 drivers/mtd/spi/sf_internal.h |   1 +
 drivers/mtd/spi/sf_ops.c  | 110 --
 drivers/mtd/spi/sf_probe.c|   4 +-
 include/spi_flash.h   |   2 -
 4 files changed, 64 insertions(+), 53 deletions(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index e97c716..4ecfd0c 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -49,6 +49,7 @@ enum {
 
 enum spi_nor_option_flags {
SNOR_F_SST_WR   = (1 << 0),
+   SNOR_F_USE_FSR  = (1 << 1),
 };
 
 #define SPI_FLASH_3B_ADDR_LEN  3
diff --git a/drivers/mtd/spi/sf_ops.c b/drivers/mtd/spi/sf_ops.c
index f1be815..388fdd0 100644
--- a/drivers/mtd/spi/sf_ops.c
+++ b/drivers/mtd/spi/sf_ops.c
@@ -40,6 +40,21 @@ int spi_flash_cmd_read_status(struct spi_flash *flash, u8 
*rs)
return 0;
 }
 
+static int read_fsr(struct spi_flash *flash, u8 *fsr)
+{
+   int ret;
+   u8 cmd;
+
+   cmd = CMD_FLAG_STATUS;
+   ret = spi_flash_read_common(flash, &cmd, 1, fsr, 1);
+   if (ret < 0) {
+   debug("SF: fail to read flag status register\n");
+   return ret;
+   }
+
+   return 0;
+}
+
 int spi_flash_cmd_write_status(struct spi_flash *flash, u8 ws)
 {
u8 cmd;
@@ -138,72 +153,71 @@ static void spi_flash_dual_flash(struct spi_flash *flash, 
u32 *addr)
 }
 #endif
 
-static int spi_flash_poll_status(struct spi_slave *spi, unsigned long timeout,
-u8 cmd, u8 poll_bit)
+static inline int spi_flash_sr_ready(struct spi_flash *flash)
 {
-   unsigned long timebase;
-   unsigned long flags = SPI_XFER_BEGIN;
+   u8 sr;
int ret;
-   u8 status;
-   u8 check_status = 0x0;
-
-   if (cmd == CMD_FLAG_STATUS)
-   check_status = poll_bit;
 
-#ifdef CONFIG_SF_DUAL_FLASH
-   if (spi->flags & SPI_XFER_U_PAGE)
-   flags |= SPI_XFER_U_PAGE;
-#endif
-   ret = spi_xfer(spi, 8, &cmd, NULL, flags);
-   if (ret) {
-   debug("SF: fail to read %s status register\n",
- cmd == CMD_READ_STATUS ? "read" : "flag");
+   ret = spi_flash_cmd_read_status(flash, &sr);
+   if (ret < 0)
return ret;
-   }
-
-   timebase = get_timer(0);
-   do {
-   WATCHDOG_RESET();
-
-   ret = spi_xfer(spi, 8, NULL, &status, 0);
-   if (ret)
-   return -1;
 
-   if ((status & poll_bit) == check_status)
-   break;
+   if (sr < 0)
+   return sr;
+   else
+   return !(sr & STATUS_WIP);
+}
 
-   } while (get_timer(timebase) < timeout);
+static inline int spi_flash_fsr_ready(struct spi_flash *flash)
+{
+   u8 fsr;
+   int ret;
 
-   spi_xfer(spi, 0, NULL, NULL, SPI_XFER_END);
+   ret = read_fsr(flash, &fsr);
+   if (ret < 0)
+   return ret;
 
-   if ((status & poll_bit) == check_status)
-   return 0;
+   if (fsr < 0)
+   return fsr;
+   else
+   return fsr & STATUS_PEC;
+}
 
-   /* Timed out */
-   debug("SF: time out!\n");
-   return -1;
+static int spi_flash_ready(struct spi_flash *flash)
+{
+   int sr, fsr;
+   sr = spi_flash_sr_ready(flash);
+   if (sr < 0)
+   return sr;
+   fsr = flash->flags & SNOR_F_USE_FSR ? spi_flash_fsr_ready(flash) : 1;
+   if (fsr < 0)
+   return fsr;
+   return sr && fsr;
 }
 
-int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long timeout)
+/*
+ * Service routine to read status register until ready, or timeout occurs.
+ * Returns non-zero if error.
+ */
+int spi_flash_cmd_wait_ready(struct spi_flash *flash, unsigned long deadline)
 {
-   struct spi_slave *spi = flash->spi;
-   int ret;
-   u8 poll_bit = STATUS_WIP;
-   u8 cmd = CMD_READ_STATUS;
+   int timeout, ret;
 
-   ret = spi_flash_poll_status(spi, timeout, cmd, poll_bit);
-   if (ret < 0)
-   return ret;
+   timeout = get_timer(0);
 
-   if (flash->poll_cmd == CMD_FLAG_STATUS) {
-   poll_bit = STATUS_PEC;
-   cmd = CMD_FLAG_STATUS;
-   ret = spi_flash_poll_status(spi, timeout, cmd, poll_bit);
+

[U-Boot] [PATCH 5/6] sf: Make flash->flags use for generic usage

[Jagan Teki]

Use the flash->flags for generic usage, not only for dm-spi-flash,
this will be used for future flag additions.

Signed-off-by: Jagan Teki 
Cc: Bin Meng 
---
 drivers/mtd/spi/sf_internal.h | 4 
 drivers/mtd/spi/sf_probe.c| 6 ++
 include/spi_flash.h   | 4 ++--
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 9fb5557..e97c716 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -47,6 +47,10 @@ enum {
 
 #define SST_WR (SST_BP | SST_WP)
 
+enum spi_nor_option_flags {
+   SNOR_F_SST_WR   = (1 << 0),
+};
+
 #define SPI_FLASH_3B_ADDR_LEN  3
 #define SPI_FLASH_CMD_LEN  (1 + SPI_FLASH_3B_ADDR_LEN)
 #define SPI_FLASH_16MB_BOUN0x100
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 0483bed..1de2bbb 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -164,15 +164,13 @@ static int spi_flash_validate_params(struct spi_slave 
*spi, u8 *idcode,
flash->name = params->name;
flash->memory_map = spi->memory_map;
flash->dual_flash = flash->spi->option;
-#ifdef CONFIG_DM_SPI_FLASH
-   flash->flags = params->flags;
-#endif
 
/* Assign spi_flash ops */
 #ifndef CONFIG_DM_SPI_FLASH
flash->write = spi_flash_cmd_write_ops;
 #if defined(CONFIG_SPI_FLASH_SST)
if (params->flags & SST_WR) {
+   flash->flags |= SNOR_F_SST_WR;
if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
flash->write = sst_write_bp;
else
@@ -467,7 +465,7 @@ int spi_flash_std_write(struct udevice *dev, u32 offset, 
size_t len,
struct spi_flash *flash = dev_get_uclass_priv(dev);
 
 #if defined(CONFIG_SPI_FLASH_SST)
-   if (flash->flags & SST_WR) {
+   if (flash->flags & SNOR_F_SST_WR) {
if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
return sst_write_bp(flash, offset, len, buf);
else
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 3b2d555..8d85468 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -38,10 +38,10 @@ struct spi_slave;
  *
  * @spi:   SPI slave
  * @dev:   SPI flash device
- * @flags: Indication of spi flash flags
  * @name:  Name of SPI flash
  * @dual_flash:Indicates dual flash memories - dual stacked, 
parallel
  * @shift: Flash shift useful in dual parallel
+ * @flags: Indication of spi flash flags
  * @size:  Total flash size
  * @page_size: Write (page) size
  * @sector_size:   Sector size
@@ -67,11 +67,11 @@ struct spi_flash {
struct spi_slave *spi;
 #ifdef CONFIG_DM_SPI_FLASH
struct udevice *dev;
-   u16 flags;
 #endif
const char *name;
u8 dual_flash;
u8 shift;
+   u16 flags;
 
u32 size;
u32 page_size;
-- 
1.9.1

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

Re: [U-Boot] [PATCH 0/6] sf: BAR/wait_ready logic updates

[Jagan Teki]

Hi Michal/Siva,

On 16 August 2015 at 14:13, Jagan Teki  wrote:
> BAR and spi_flash_cmd_wait_ready are updated to make more
> module to add new status checks.
>
> Jagan Teki (6):
>   spi: zynq_spi: Remove unneeded headers
>   sf: Return proper bank_sel, if flash->bank_curr == bank_sel
>   sf: Make BAR discovery, as spi_flash_read_bar
>   sf: Optimize BAR write code
>   sf: Make flash->flags use for generic usage
>   sf: Update spi_flash_cmd_wait_ready

Pls- test BAR/wait_ready for all supported spi-nor flash.

>
>  drivers/mtd/spi/sf_internal.h |   5 ++
>  drivers/mtd/spi/sf_ops.c  | 153 
> +-
>  drivers/mtd/spi/sf_probe.c|  64 +++---
>  drivers/spi/zynq_spi.c|   6 +-
>  include/spi_flash.h   |   6 +-
>  5 files changed, 121 insertions(+), 113 deletions(-)
>
> --
> 1.9.1
>

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

Re: [U-Boot] [PATCH 0/6] sf: BAR/wait_ready logic updates

[Jagan Teki]

Hi Zhiqiang,

On 16 August 2015 at 14:16, Jagan Teki  wrote:
> Hi Michal/Siva,
>
> On 16 August 2015 at 14:13, Jagan Teki  wrote:
>> BAR and spi_flash_cmd_wait_ready are updated to make more
>> module to add new status checks.
>>
>> Jagan Teki (6):
>>   spi: zynq_spi: Remove unneeded headers
>>   sf: Return proper bank_sel, if flash->bank_curr == bank_sel
>>   sf: Make BAR discovery, as spi_flash_read_bar
>>   sf: Optimize BAR write code
>>   sf: Make flash->flags use for generic usage
>>   sf: Update spi_flash_cmd_wait_ready

Add your clear status register support on-top this, and let me know
for any inputs.

>
> Pls- test BAR/wait_ready for all supported spi-nor flash.
>
>>
>>  drivers/mtd/spi/sf_internal.h |   5 ++
>>  drivers/mtd/spi/sf_ops.c  | 153 
>> +-
>>  drivers/mtd/spi/sf_probe.c|  64 +++---
>>  drivers/spi/zynq_spi.c|   6 +-
>>  include/spi_flash.h   |   6 +-
>>  5 files changed, 121 insertions(+), 113 deletions(-)
>>
>> --
>> 1.9.1

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

[U-Boot] [PATCH 7/8] rockchip: Drop first 32kb of zeros from the rksd image type

[Sjoerd Simons]

Instead of creating a rockchip SPL sd card image with 32Kb of zeros
which can be written to the start of an SD card, create the images with
only the useful data that should be written to an offset of 32Kb on the
SD card.

The first 32 kilobytes aren't needed for bootup and only serve as
convenient way of accidentally obliterating your partition table.

Signed-off-by: Sjoerd Simons 
---

 doc/README.rockchip | 2 +-
 tools/rksd.c| 9 ++---
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index ce8ce77..347fc05 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -90,7 +90,7 @@ Booting from an SD card
 To write an image that boots from an SD card (assumed to be /dev/sdc):
 
./firefly-rk3288/tools/mkimage -T rksd -d 
firefly-rk3288/spl/u-boot-spl-dtb.bin out
-   sudo dd if=out of=/dev/sdc
+   sudo dd if=out of=/dev/sdc seek=64
sudo dd if=firefly-rk3288/u-boot-dtb.img of=/dev/sdc seek=256
 
 This puts the Rockchip header and SPL image first and then places the U-Boot
diff --git a/tools/rksd.c b/tools/rksd.c
index 2efcd68..a8dbe98 100644
--- a/tools/rksd.c
+++ b/tools/rksd.c
@@ -14,9 +14,7 @@
 #include "rkcommon.h"
 
 enum {
-   RKSD_HEADER0_START  = 64 * RK_BLK_SIZE,
-   RKSD_SPL_HDR_START  = RKSD_HEADER0_START +
-   RK_CODE1_OFFSET * RK_BLK_SIZE,
+   RKSD_SPL_HDR_START  = RK_CODE1_OFFSET * RK_BLK_SIZE,
RKSD_SPL_START  = RKSD_SPL_HDR_START + 4,
RKSD_HEADER_LEN = RKSD_SPL_START,
 };
@@ -44,11 +42,8 @@ static void rksd_set_header(void *buf,  struct stat *sbuf,  
int ifd,
unsigned int size;
int ret;
 
-   /* Zero the whole header. The first 32KB is empty */
-   memset(buf,  '\0',  RKSD_HEADER0_START);
-
size = params->file_size - RKSD_SPL_HDR_START;
-   ret = rkcommon_set_header(buf + RKSD_HEADER0_START, size);
+   ret = rkcommon_set_header(buf, size);
if (ret) {
/* TODO(s...@chromium.org): This method should return an error 
*/
printf("Warning: SPL image is too large (size %#x) and will not 
boot\n",
-- 
2.5.0

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

[U-Boot] [PATCH 1/3] sunxi: musb: Drop no longer accurate comment in Kconfig help text

[Hans de Goede]

Drop the no longer accurate part of the USB_MUSB_SUNXI Kconfig help text,
since the musb-host code now supports the device-model, ehci and musb in
host mode can both be enabled at the same time without issues.

Signed-off-by: Hans de Goede 
---
 drivers/usb/musb-new/Kconfig | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/usb/musb-new/Kconfig b/drivers/usb/musb-new/Kconfig
index 0082ff8..6a6cb93 100644
--- a/drivers/usb/musb-new/Kconfig
+++ b/drivers/usb/musb-new/Kconfig
@@ -21,8 +21,6 @@ config USB_MUSB_SUNXI
default y
---help---
Say y here to enable support for the sunxi OTG / DRC USB controller
-   used on almost all sunxi boards. Note currently u-boot can only have
-   one usb host controller enabled at a time, so enabling this on boards
-   which also use the ehci host controller will result in build errors.
+   used on almost all sunxi boards.
 
 endif
-- 
2.4.3

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

[U-Boot] [PATCH 2/8] mmc: Probe DM based mmc devices in u-boot

[Sjoerd Simons]

During mmc initialize probe all devices with the MMC Uclass if build
with CONFIG_DM_MMC

Signed-off-by: Sjoerd Simons 
---

 drivers/mmc/mmc.c | 32 
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index da47037..a366933 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -1759,16 +1761,38 @@ static void do_preinit(void)
}
 }
 
+#if defined(CONFIG_DM_MMC) && defined(CONFIG_SPL_BUILD)
+static void mmc_probe(bd_t *bis)
+{
+}
+#elif defined(CONFIG_DM_MMC)
+static void mmc_probe(bd_t *bis)
+{
+   int ret;
+   struct uclass *uc;
+   struct udevice *m;
+
+   uclass_get(UCLASS_MMC, &uc);
+   uclass_foreach_dev(m, uc) {
+   ret = device_probe(m);
+   if (ret)
+   printf("%s - probe failed: %d\n", m->name, ret);
+   }
+}
+#else
+static void mmc_probe(bd_t *bis)
+{
+   if (board_mmc_init(bis) < 0)
+   cpu_mmc_init(bis);
+}
+#endif
 
 int mmc_initialize(bd_t *bis)
 {
INIT_LIST_HEAD (&mmc_devices);
cur_dev_num = 0;
 
-#ifndef CONFIG_DM_MMC
-   if (board_mmc_init(bis) < 0)
-   cpu_mmc_init(bis);
-#endif
+   mmc_probe(bis);
 
 #ifndef CONFIG_SPL_BUILD
print_mmc_devices(',');
-- 
2.5.0

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

[U-Boot] [PATCH 0/8] dm: rockchip: Enable booting from MMC

[Sjoerd Simons]

This patchset allows u-boot on RK3288 device to load and boot kernels
from MMC using the standard distro boot commands. Patchset is on top of
the rockchip-working branch of u-boot dm

There are some small oddities with the support:
- Linux crashes when try to use the FDT if it's re-allocated to memory
  locations above 512MB. So fdt_high is set to ensure it stays below
  that.
- This SoC seems sensitive to the order in which the caches are
  disabled, when disabling the i-cache before the d-cache starting linux
  fails (unsure if it fails before or after jumping to linux though)

To fix the latter ``arm: Turn of d-cache before i-cache'' changes the
ordering in the general v7 code. However i have not tested this yet on
other device, so it may well need to be handled in rockchip specific
code.

Tested on a Radxa Rock 2 with square baseboard, booting from SD card. I
haven't tested eMMC yet however i suspect the SPL will need
modifications there to load u-boot from eMMC rather then SD (which has
index 0) ideally by detecting where the SPL itself got loaded from.


Sjoerd Simons (8):
  doc: Fix reference to Rock pro when Rock 2 is meant
  mmc: Probe DM based mmc devices in u-boot
  rockchip: Disable sdio mmc slot on rk3288-firefly
  rockchip: Turn off CONFIG_SPL_LED_SUPPORT for firefly
  rockchip: Add config_distro_bootcmd support
  arm: Turn of d-cache before i-cache
  rockchip: Drop first 32kb of zeros from the rksd image type
  rockchip: Update todo in README.rockchip

 arch/arm/cpu/armv7/cpu.c | 15 +--
 arch/arm/dts/rk3288-firefly.dtsi |  2 +-
 doc/README.rockchip  |  9 -
 drivers/mmc/mmc.c| 32 
 include/configs/firefly-rk3288.h |  1 -
 include/configs/rk3288_common.h  | 21 +
 tools/rksd.c |  9 ++---
 7 files changed, 65 insertions(+), 24 deletions(-)

-- 
2.5.0

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

[U-Boot] [PATCH 3/3] sunxi: Add CONFIG_MMC0_CD_PIN to various boards

[Hans de Goede]

Add CONFIG_MMC0_CD_PIN to various boards, this stoos the SPL from still
trying to access the sdcard when there is none (e.g. when booting from
nand).

Signed-off-by: Hans de Goede 
---
 configs/A10-OLinuXino-Lime_defconfig | 1 +
 configs/A13-OLinuXinoM_defconfig | 1 +
 configs/A13-OLinuXino_defconfig  | 1 +
 configs/A20-OLinuXino-Lime_defconfig | 1 +
 configs/Cubieboard_defconfig | 1 +
 configs/Cubietruck_defconfig | 1 +
 6 files changed, 6 insertions(+)

diff --git a/configs/A10-OLinuXino-Lime_defconfig 
b/configs/A10-OLinuXino-Lime_defconfig
index 0245bfc..ee219f8 100644
--- a/configs/A10-OLinuXino-Lime_defconfig
+++ b/configs/A10-OLinuXino-Lime_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN4I=y
 CONFIG_DRAM_CLK=480
 CONFIG_DRAM_EMR1=4
+CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_SYS_CLK_FREQ=91200
 CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-olinuxino-lime"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/configs/A13-OLinuXinoM_defconfig b/configs/A13-OLinuXinoM_defconfig
index 5852be6..ccf35c7 100644
--- a/configs/A13-OLinuXinoM_defconfig
+++ b/configs/A13-OLinuXinoM_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN5I=y
 CONFIG_DRAM_CLK=408
 CONFIG_DRAM_EMR1=0
+CONFIG_MMC0_CD_PIN="PG0"
 CONFIG_USB1_VBUS_PIN="PG11"
 # CONFIG_VIDEO_HDMI is not set
 CONFIG_VIDEO_VGA_VIA_LCD=y
diff --git a/configs/A13-OLinuXino_defconfig b/configs/A13-OLinuXino_defconfig
index a2e7c38..ef239a98 100644
--- a/configs/A13-OLinuXino_defconfig
+++ b/configs/A13-OLinuXino_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN5I=y
 CONFIG_DRAM_CLK=408
 CONFIG_DRAM_EMR1=0
+CONFIG_MMC0_CD_PIN="PG0"
 CONFIG_USB1_VBUS_PIN="PG11"
 CONFIG_AXP_GPIO=y
 # CONFIG_VIDEO_HDMI is not set
diff --git a/configs/A20-OLinuXino-Lime_defconfig 
b/configs/A20-OLinuXino-Lime_defconfig
index fb1f240..4a257b3 100644
--- a/configs/A20-OLinuXino-Lime_defconfig
+++ b/configs/A20-OLinuXino-Lime_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN7I=y
 CONFIG_DRAM_CLK=480
+CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL=y
diff --git a/configs/Cubieboard_defconfig b/configs/Cubieboard_defconfig
index b2f5d09..819fffd 100644
--- a/configs/Cubieboard_defconfig
+++ b/configs/Cubieboard_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN4I=y
 CONFIG_DRAM_CLK=480
+CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-cubieboard"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL=y
diff --git a/configs/Cubietruck_defconfig b/configs/Cubietruck_defconfig
index ebd45b3..7a188d3 100644
--- a/configs/Cubietruck_defconfig
+++ b/configs/Cubietruck_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN7I=y
 CONFIG_DRAM_CLK=432
+CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_VIDEO_VGA=y
 CONFIG_GMAC_TX_DELAY=1
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-cubietruck"
-- 
2.4.3

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

[U-Boot] [PATCH 2/3] sunxi: Drop LCD_MODE from A13-OLinuxIno defconfigs

[Hans de Goede]

With the unified / cleaned up default display output selection changes,
which were done as part of adding composite video out support, our
example LCD_MODE line in the A13-OLinuxIno defconfigs causes the display
code to setup a LCD console by default, rather then a VGA console.

Given that the LCD console is only useful for people who have hooked up
the exact lcd-panel from the config, while most people will not have any
lcd panel connected to these boards, this is not a good default.

Dropping the LCD_MODE line which was intended as an example fixes this,
instead add a link to the LCD_MODE help text pointing to
http://linux-sunxi.org/LCD which contains the removed and other example
modes.

Signed-off-by: Hans de Goede 
---
 board/sunxi/Kconfig  | 1 +
 configs/A13-OLinuXinoM_defconfig | 1 -
 configs/A13-OLinuXino_defconfig  | 1 -
 3 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index fd6668f..55906b5 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -425,6 +425,7 @@ config VIDEO_LCD_MODE
LCD panel timing details string, leave empty if there is no LCD panel.
This is in drivers/video/videomodes.c: video_get_params() format, e.g.

x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:0,vmode:0
+   Also see: http://linux-sunxi.org/LCD
 
 config VIDEO_LCD_DCLK_PHASE
int "LCD panel display clock phase"
diff --git a/configs/A13-OLinuXinoM_defconfig b/configs/A13-OLinuXinoM_defconfig
index dcaaff9..5852be6 100644
--- a/configs/A13-OLinuXinoM_defconfig
+++ b/configs/A13-OLinuXinoM_defconfig
@@ -7,7 +7,6 @@ CONFIG_USB1_VBUS_PIN="PG11"
 # CONFIG_VIDEO_HDMI is not set
 CONFIG_VIDEO_VGA_VIA_LCD=y
 CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
-CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
 CONFIG_VIDEO_LCD_POWER="PB10"
 CONFIG_VIDEO_LCD_BL_PWM="PB2"
 CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino-micro"
diff --git a/configs/A13-OLinuXino_defconfig b/configs/A13-OLinuXino_defconfig
index eed53d5..a2e7c38 100644
--- a/configs/A13-OLinuXino_defconfig
+++ b/configs/A13-OLinuXino_defconfig
@@ -8,7 +8,6 @@ CONFIG_AXP_GPIO=y
 # CONFIG_VIDEO_HDMI is not set
 CONFIG_VIDEO_VGA_VIA_LCD=y
 CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
-CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
 CONFIG_VIDEO_LCD_POWER="AXP0-0"
 CONFIG_VIDEO_LCD_BL_PWM="PB2"
 CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"
-- 
2.4.3

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

[U-Boot] [PATCH 4/8] rockchip: Turn off CONFIG_SPL_LED_SUPPORT for firefly

[Sjoerd Simons]

With LED support enabled the SPL easily goes over the size limit (e.g.
with both Debians gcc 4.9 and 5.2 cross-compilers). Turn off LED support
in the SPL to reduce the size just enough for those compilers.

Signed-off-by: Sjoerd Simons 
---

 include/configs/firefly-rk3288.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/firefly-rk3288.h b/include/configs/firefly-rk3288.h
index 82e7c9c..a82adc8 100644
--- a/include/configs/firefly-rk3288.h
+++ b/include/configs/firefly-rk3288.h
@@ -10,6 +10,5 @@
 #include 
 
 #define CONFIG_SPL_MMC_SUPPORT
-#define CONFIG_SPL_LED_SUPPORT
 
 #endif
-- 
2.5.0

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

[U-Boot] [PATCH 6/8] arm: Turn of d-cache before i-cache

[Sjoerd Simons]

Booting the kernel fails on RK3288 (and probably other rockchip SoCs)
when the i-cache is disabled/flushed before d-cache.

I have not investigated whether this is due to u-boot hanging or whether
it's very early in the linux boot, but following the approach of the
varoius rockchip u-boot forks (first disable d-cache then i-cache) makes
things work.

Signed-off-by: Sjoerd Simons 
---

 arch/arm/cpu/armv7/cpu.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c
index 0b0e500..6eac5ef 100644
--- a/arch/arm/cpu/armv7/cpu.c
+++ b/arch/arm/cpu/armv7/cpu.c
@@ -36,12 +36,6 @@ int cleanup_before_linux_select(int flags)
disable_interrupts();
 #endif
 
-   /*
-* Turn off I-cache and invalidate it
-*/
-   icache_disable();
-   invalidate_icache_all();
-
if (flags & CBL_DISABLE_CACHES) {
/*
* turn off D-cache
@@ -61,7 +55,16 @@ int cleanup_before_linux_select(int flags)
* to avoid coherency problems for kernel
*/
invalidate_dcache_all();
+
+   icache_disable();
+   invalidate_icache_all();
} else {
+   /*
+* Turn off I-cache and invalidate it
+*/
+   icache_disable();
+   invalidate_icache_all();
+
flush_dcache_all();
invalidate_icache_all();
icache_enable();
-- 
2.5.0

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

[U-Boot] [PATCH 8/8] rockchip: Update todo in README.rockchip

[Sjoerd Simons]

MMC support works now, so it can be dropped from the todo

Signed-off-by: Sjoerd Simons 

---

 doc/README.rockchip | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index 347fc05..feb11ff 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -161,7 +161,6 @@ Future work
 
 Immediate priorities are:
 
-- MMC support (in U-Boot itself)
 - GPIO (driver exists but is lightly tested)
 - I2C (driver exists but is non-functional)
 - USB host
-- 
2.5.0

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

[U-Boot] [PATCH 5/8] rockchip: Add config_distro_bootcmd support

[Sjoerd Simons]

Now that MMC works in u-boot add config distro command support to start
Linux in a standard fashion. One oddity here is that linux fails to load
the fdt is relocated to above 512MB, so set fdt_high to make sure it's
loaded below that.

Signed-off-by: Sjoerd Simons 
---

 include/configs/rk3288_common.h | 21 +
 1 file changed, 21 insertions(+)

diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index 081c62d..7781dc3 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -96,6 +96,27 @@
 
 #ifndef CONFIG_SPL_BUILD
 #include 
+
+#define ENV_MEM_LAYOUT_SETTINGS \
+   "scriptaddr=0x\0" \
+   "pxefile_addr_r=0x0010\0" \
+   "fdt_addr_r=0x01f0\0" \
+   "kernel_addr_r=0x0200\0" \
+   "ramdisk_addr_r=0x0400\0"
+
+/* First try to boot from SD (index 0), then eMMC (index 1 */
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1)
+
+#include 
+
+/* Linux fails to load the fdt if it's loaded above 512M on a Rock 2 board, so
+ * limit the fdt reallocation to that */
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   "fdt_high=0x1fff\0" \
+   ENV_MEM_LAYOUT_SETTINGS \
+   BOOTENV
 #endif
 
 #endif
-- 
2.5.0

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

Re: [U-Boot] [PATCH v2] usb: xhci: Fix a potential NULL pointer dereference

[Marek Vasut]

On Saturday, August 15, 2015 at 12:28:10 AM, Sergei Temerkhanov wrote:
> On Fri, Aug 14, 2015 at 11:46 PM, Marek Vasut  wrote:
> > On Friday, August 14, 2015 at 05:14:09 PM, Sergey Temerkhanov wrote:
> >> This patch fixes a potential NULL pointer dereference arising on
> >> non-present/non-initialized xHCI controllers and adds some error
> >> handling to xHCI code
> >> 
> >> Signed-off-by: Sergey Temerkhanov 
> >> Signed-off-by: Radha Mohan Chintakuntla 
> >> 
> >> ---
> >> 
> >> Changes in v2:
> >> - Add return value check with setting hccr and hcor to NULL
> >> 
> >>  drivers/usb/host/xhci.c | 15 +++
> >>  1 file changed, 11 insertions(+), 4 deletions(-)
> >> 
> >> diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> >> index 0b09643..f8e2d70 100644
> >> --- a/drivers/usb/host/xhci.c
> >> +++ b/drivers/usb/host/xhci.c
> >> @@ -199,7 +199,7 @@ int xhci_reset(struct xhci_hcor *hcor)
> >> 
> >>   int ret;
> >>   
> >>   /* Halting the Host first */
> >> 
> >> - debug("// Halt the HC\n");
> >> + debug("// Halt the HC: %p\n", hcor);
> >> 
> >>   state = xhci_readl(&hcor->or_usbsts) & STS_HALT;
> >>   if (!state) {
> >>   
> >>   cmd = xhci_readl(&hcor->or_usbcmd);
> >> 
> >> @@ -1079,6 +1079,11 @@ int usb_lowlevel_init(int index, enum
> >> usb_init_type init, void **controller)
> >> 
> >>   *controller = &xhcic[index];
> >> 
> >> + if (ret) {
> >> + ctrl->hccr = NULL;
> >> + ctrl->hcor = NULL;
> > 
> > Controller should be set to NULL too, for the sake of being completely
> > precise, don't you think so ?
> 
> Maybe. Though the only place it's actually used at the moment (there
> is also some USB gadget stuff
> which seems to rely on EHCI) passes a pointer to a local variable and
> checks the return value.

I think it might be even better to shuffle the code around a little, so
that controller is only set if ret == 0. Can you please do this last
bit and send a V3 ? I'd like to pick the patch then. Thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 07/11] arm: pxa: colibri_pxa270: fix boot hang

[Marek Vasut]

On Sunday, August 16, 2015 at 10:03:51 AM, Marcel Ziswiler wrote:
> On 16 August 2015 05:31:58 CEST, Marek Vasut  wrote:
> >On Sunday, August 16, 2015 at 04:16:32 AM, Marcel Ziswiler wrote:
> >
> >I would suggest that we drop this patch, but I would also suggest that
> >we do
> >the same thing kernel does and just enable CONFIG_USE_PRIVATE_LIBGCC
> >globally
> >for everyone to break this constant nonsensical influx of
> >toolchain-related
> >problems. This nonsense has been dragging on for too long. Tom? Albert?
> 
> I don't really care how this gets fixed I just don't ever want to have to
> debug through that one ever again!

I've been there, multiple times. I can feel your pain, this is a terrible
nastiness with the libgcc.

> Thanks, Marek.

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

Re: [U-Boot] [PATCH 01/11] arm: pxa: clean-up include file order

[Marek Vasut]

On Sunday, August 16, 2015 at 04:16:26 AM, Marcel Ziswiler wrote:
> Cleaning up order of include files by sorting them alphabetically
> keeping in mind to leave common.h on top.
> 
> Signed-off-by: Marcel Ziswiler 

I cannot find 03/11 , why ?

I applied all but 03/11 and 07/11 to u-boot-pxa/master though :)

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

Re: [U-Boot] [PATCH 01/11] arm: pxa: clean-up include file order

[Marcel Ziswiler]

On 16 August 2015 18:53:40 CEST, Marek Vasut  wrote:

>I cannot find 03/11 , why ?

Ah, I believe that one is actually meant for Tegra rather than PXA and will 
hopefully be picked up by Tom.

>I applied all but 03/11 and 07/11 to u-boot-pxa/master though :)

Thanks, Marek. I hope we can sort out 07/11 soon as well.

BTW: I just got it booting Linux -next with a preliminary device tree I put 
together including NFSv4 mounted rootfs. Just wondering why there aren't any 
PXA device trees mainline yet.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] sf: Update spi_flash_cmd_wait_ready

[Marek Vasut]

On Sunday, August 16, 2015 at 10:43:49 AM, Jagan Teki wrote:
> Current flash wait_ready logic is not modular to add new
> register status check, hence few of the logic is used from
> Linux spi-nor framework.
> 
> Below are the sf speed runs with 'sf update' on whole flash, 16MiB.
> 
> => sf update 0x100 0x0 0x100
> device 0 whole chip
> 16777216 bytes written, 0 bytes skipped in 61.784s, speed 279620 B/s
> 
> => sf update 0x100 0x0 0x100
> device 0 whole chip
> 16777216 bytes written, 0 bytes skipped in 61.276s, speed 284359 B/s
> 
> Signed-off-by: Jagan Teki 
> Cc: Simon Glass 
> Cc: Marek Vasut 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Cc: Stefan Roese 
> Cc: Tom Warren 
> Cc: Bin Meng 
> Cc: Tom Rini 
> Tested-by: Jagan Teki 
> ---

Please split this into two patches, one which makes the code modular
and next one which adds new features (the FSR reading or whatever).

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

Re: [U-Boot] [PATCH 01/11] arm: pxa: clean-up include file order

[Marek Vasut]

On Sunday, August 16, 2015 at 07:16:09 PM, Marcel Ziswiler wrote:
> On 16 August 2015 18:53:40 CEST, Marek Vasut  wrote:
> >I cannot find 03/11 , why ?
> 
> Ah, I believe that one is actually meant for Tegra rather than PXA and will
> hopefully be picked up by Tom.

Errr, right. What weird sort of battle tactics is this, are you trying to
confuse the enemy with random unrelated patches right in the middle of a
coherent series? :)

> >I applied all but 03/11 and 07/11 to u-boot-pxa/master though :)
> 
> Thanks, Marek. I hope we can sort out 07/11 soon as well.

Well, I'm not so sure. But I'd definitelly be in favor of dropping our odd
dependency on libgcc. It is just a hindrance and I fail to see the benefit.

> BTW: I just got it booting Linux -next with a preliminary device tree I put
> together including NFSv4 mounted rootfs. Just wondering why there aren't
> any PXA device trees mainline yet.

I think Daniel Mack was the last one who worked on PXA DT support.

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

Re: [U-Boot] [PATCH 07/12] sniper: Serial number support, obtained from die ID

[Paul Kocialkowski]

Le jeudi 13 août 2015 à 08:13 -0400, Tom Rini a écrit :
> On Fri, Aug 07, 2015 at 11:44:46AM +0200, Paul Kocialkowski wrote:
> > Le mardi 04 août 2015 à 14:27 -0400, Tom Rini a écrit :
> > > On Tue, Aug 04, 2015 at 08:22:39PM +0200, Paul Kocialkowski 
> > > wrote:
> > > > Le mardi 04 août 2015 à 14:16 -0400, Tom Rini a écrit :
> > > > > On Tue, Aug 04, 2015 at 08:02:40PM +0200, Paul Kocialkowski 
> > > > > wrote:
> > > > > > Le lundi 03 août 2015 à 22:08 -0400, Tom Rini a écrit :
> > > > > > > On Mon, Jul 20, 2015 at 03:17:13PM +0200, Paul 
> > > > > > > Kocialkowski wrote:
> > > > > > > 
> > > > > > > > The OMAP3 has some die-specific ID bits that we can use 
> > > > > > > > to give the device a
> > > > > > > > (more or less) unique serial number. This is 
> > > > > > > > particularly useful for e.g. USB.
> > > > > > > > 
> > > > > > > > Signed-off-by: Paul Kocialkowski 
> > > > > > > > ---
> > > > > > > >  board/lge/sniper/sniper.c | 13 +
> > > > > > > >  1 file changed, 13 insertions(+)
> > > > > > > > 
> > > > > > > > diff --git a/board/lge/sniper/sniper.c 
> > > > > > > > b/board/lge/sniper/sniper.c
> > > > > > > > index 44d422d..f26855d 100644
> > > > > > > > --- a/board/lge/sniper/sniper.c
> > > > > > > > +++ b/board/lge/sniper/sniper.c
> > > > > > > > @@ -70,7 +70,9 @@ int board_init(void)
> > > > > > > >  
> > > > > > > >  int misc_init_r(void)
> > > > > > > >  {
> > > > > > > > +   char serial_string[17] = { 0 };
> > > > > > > > char reboot_mode[2] = { 0 };
> > > > > > > > +   u32 dieid[4] = { 0 };
> > > > > > > >  
> > > > > > > > /* Reboot mode */
> > > > > > > >  
> > > > > > > > @@ -82,6 +84,17 @@ int misc_init_r(void)
> > > > > > > > omap_reboot_mode_clear();
> > > > > > > > }
> > > > > > > >  
> > > > > > > > +   /* Serial number */
> > > > > > > > +
> > > > > > > > +   get_dieid((u32 *)&dieid);
> > > > > > > > +
> > > > > > > > +   if (!getenv("serial#")) {
> > > > > > > > +   snprintf(serial_string, 
> > > > > > > > sizeof(serial_string),
> > > > > > > > +   "%08x%08x", dieid[0], 
> > > > > > > > dieid[3]);
> > > > > > > > +
> > > > > > > > +   setenv("serial#", serial_string);
> > > > > > > > +   }
> > > > > > > > +
> > > > > > > > return 0;
> > > > > > > >  }
> > > > > > > 
> > > > > > > Shouldn't this be in more generic code so everyone gets 
> > > > > > > this set now?
> > > > > > > Thanks!
> > > > > > 
> > > > > > Well, we had a similar discussion for sunxi, and the 
> > > > > > outcome was that
> > > > > > serial number could be obtained from other places on other 
> > > > > > devices (e.g.
> > > > > > EEPROM) or be calculated from the dieid bits in a different 
> > > > > > way, so I
> > > > > > prefer to keep this board-specific instead of omap3-generic 
> > > > > > for now.
> > > > > > 
> > > > > > This merely matches what is done on Android OMAP devices, 
> > > > > > but one could
> > > > > > do it another way, too.
> > > > > > 
> > > > > > What do you think?
> > > > > 
> > > > > I think, ug,
> > > > > arch/arm/cpu/armv7/omap
> > > > > -common/utils.c::usb_set_serial_num_from_die_id()
> > > > > should be called set_serial_num_from_die_id() and we can use 
> > > > > that for
> > > > > this board too even if it's not ideal.
> > > > 
> > > > Oh okay then, I don't have any problem with making this code 
> > > > common,
> > > > especially if it's not called by every omap3 board then.
> > > > 
> > > > I agree with your proposal. Should I submit a v2 with a patch 
> > > > in that
> > > > direction?
> > > 
> > > Sounds good, thanks!
> > 
> > Taking a closer look at things, it appears that various (non-omap3)
> > boards are grabbing the Die ID bits on their own and then calling 
> > those
> > functions (usb_fake_mac_from_die_id, 
> > usb_set_serial_num_from_die_id).
> > 
> > IMHO, we should have a common naming scheme for the function to get 
> > the
> > dieid (omap_dieid), define that for each omap platform and have it
> > called in omap-common code (with one function for the serial number 
> > and
> > one for the fake mac), just like what I did with 
> > omap_sys_boot_device.
> > 
> > Then, each board would simply call those functions directly, 
> > without
> > having to care about how to obtain the die id bits.
> > 
> > This seems like a series that would deserve to live on its own, so 
> > I
> > suggest that you merge Optimus Black support as-is for now and I'll
> > submit another series to implement that behaviour on top.
> > 
> > What do you think?
> 
> Yes, OK, follow-up series to clean-up that for everyone.

Good, thanks for merging this, I'll get around producing that series
sometime next week, I'm at CCCamp for now!

-- 
Paul Kocialkowski 

* Site web : http://www.paulk.fr/
* Blog : http://blog.paulk.fr/
* Dev blog : http://code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___

Re: [U-Boot] [RFC] Merge all ns16550 dm serial drivers into one

[Simon Glass]

Hi Stephen,

On 14 August 2015 at 20:57, Stephen Warren  wrote:
> On 08/14/2015 05:18 PM, Simon Glass wrote:
>> Hi,
>>
>> On 14 August 2015 at 16:51, Stephen Warren  wrote:
>>> On 08/14/2015 04:40 PM, Bin Meng wrote:

 On Sat, Aug 15, 2015 at 12:59 AM, Simon Glass  wrote:
>
> Hi Stephen,
>
> On 14 August 2015 at 10:58, Stephen Warren  wrote:
>>
>> On 08/14/2015 10:50 AM, Simon Glass wrote:
>>>
>>>
>>> Hi Bin,
>>>
>>> On 14 August 2015 at 03:18, Bin Meng  wrote:


 Hi,

 Currently there are 5 dm serial drivers, all of which are ns16550
 compatible drivers. They are:

 serial_omap.c
 serial_dw.c
 serial_tegra.c
 serial_x86.c
 serial_ppc.c

 All these drivers are pretty much similar. I think we can justmerge
 these into one ns16550 driver.

 If you think this is necessary, I will send a patch series to do this.
>>>
>>>
>>>
>>> The tegra one is there because it needs an input clock and Stephen
>>> didn't want to add this to the device tree binding (the kernel has a
>>> clock framework which gets around this problem).
>>>
>>> After that I followed the same pattern. I would support updating the
>>> binding to support an input clock. Even with the new clock framework
>>> in U-Boot it might be painful to fit it into SPL in some cases.
>>
>>
>>
>> The clock is already in the DT, in both Linux and U-Boot's copy, at
>> least
>> for Tegra DTs:
>>
>>  uarta: serial@0,70006000 {
>>  compatible = "nvidia,tegra124-uart", ...
>> ...
>>  clocks = <&tegra_car TEGRA124_CLK_UARTA>;
>>
>
> I mean the clock-frequency property. However if there is a plan to
> implement the clock framework in U-Boot that would be good too.
>

 The clock-frequency is a fixed value on x86 super i/o chipset, and
 fixed on the PCI bus too. But for ARM and PPC, it might get
 dynamically calculated due to different PLL settings. We can implement
 a _weak function like the one in serial_ppc.c get_serial_clock() to
 initialize plat->clock with its return value. The _weak function gets
 clock-frequency from device tree. If there is not, platform codes
 which uses the ns16550 driver should provide the implementation of
 get_serial_clock(). Thoughts?
>>>
>>>
>>> There is no clock-frequency property in DT, at least for the Tegra DT
>>> binding. It looks like some other bindings have it. To obtain the clock
>>> frequency from DT for Tegra, you'd need to parse the clocks property, find
>>> the clock driver associated with the phandle in DT, and go and ask that
>>> clock driver what the clock frequency is.
>>>
>>> I'd prefer not to have a weak function that parses clock-frequency, since
>>> it's too easy to accidentally use it on systems where parsing that property
>>> is incorrect.
>>>
>>> Certainly, a generic UART driver can call out to a platform-supplied
>>> function to retrieve the clock, and we can provide driver-specific
>>> implementations for x86 super IO and PCI, and generic implementations that
>>> appropriate drivers can call to parse the clocks or clock-frequency property
>>> from DT, and finally for Tegra if we can't parse the clocks property right
>>> now, call the Tegra clock driver directly to look up the value.
>>
>> I'm not a big fan of weak functions either. In fact I think with
>> driver model we should avoid them. If we can't call a uclass to get
>> the info then perhaps we should wait until we can.
>>
>> Pragmatically I wonder if a UART clock frequency would not be a useful
>> compromise? Some bindings have it, some do not. Maybe we should just
>> add it?
>
> There's no need for it; the binding already has a clocks property, from
> which the data can be derived. Adding a clock-frequency property would
> just result in two sources of the same data. In all likelihood, all
> that'd happen is that the two would get out-of-sync, and code wouldn't
> know which to trust.

There clearly is a need for it, since I wrote a driver which hard-codes it.

Even if/when someone puts generic clock support into Tegra it is
unlikely to be worth spinning up all that clock tree stuff just to
find out this value in SPL. It would be MUCH simpler if we just added
an optional clock-frequency property to the binding. As Bin points
out, it is commonly used in other bindings.

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

Re: [U-Boot] [PATCH 03/11] arm: tegra: mmc: clean-up include file order

[Simon Glass]

Hi Marcel,

On 15 August 2015 at 20:16, Marcel Ziswiler  wrote:
> Cleaning up order of include files by sorting them alphabetically
> keeping in mind to leave common.h on top.
>
> Signed-off-by: Marcel Ziswiler 
> ---
>
>  drivers/mmc/tegra_mmc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
> index 6f8b4d0..078df39 100644
> --- a/drivers/mmc/tegra_mmc.c
> +++ b/drivers/mmc/tegra_mmc.c
> @@ -7,14 +7,14 @@
>   * SPDX-License-Identifier:GPL-2.0+
>   */
>
> -#include 
>  #include 
> -#include 
> -#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>
>  DECLARE_GLOBAL_DATA_PTR;
> --
> 2.4.3
>

Thanks for tidying this up. But the ordering should be:






"local.h"

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

Re: [U-Boot] [UBOOT PATCH v4 1/3] x86: Generate a valid ACPI table

[Simon Glass]

Hi Saket,

On 15 August 2015 at 23:10, Saket Sinha  wrote:
> Implement write_acpi_table() to create a minimal working ACPI table.
> This includes writing FACS, XSDT, RSDP, FADT, MCFG, MADT, DSDT & SSDT
> ACPI table entries.
>
> Use a Kconfig option GENERATE_ACPI_TABLE to tell U-Boot whether we need
> actually write the APCI table just like we did for PIRQ routing, MP table
> and SFI tables. With ACPI table existence, linux kernel gets control of
> power management, thermal management, configuration management and
> monitoring in hardware.
>
> Signed-off-by: Saket Sinha 

Reviewed-by: Simon Glass 

But please see nits below.

> ---
>
>  arch/x86/Kconfig  |   9 +
>  arch/x86/include/asm/acpi_table.h | 398 ++
>  arch/x86/lib/Makefile |   1 +
>  arch/x86/lib/acpi_table.c | 438 
> ++
>  arch/x86/lib/tables.c |   5 +
>  scripts/Makefile.lib  |  11 +
>  6 files changed, 862 insertions(+)
>  create mode 100644 arch/x86/include/asm/acpi_table.h
>  create mode 100644 arch/x86/lib/acpi_table.c
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 01ed760..ae881a1 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -344,6 +344,15 @@ config GENERATE_MP_TABLE
>   multiprocessing as well as symmetric I/O interrupt handling with
>   the local APIC and I/O APIC.
>
> +config GENERATE_ACPI_TABLE
> +   bool "Generate an ACPI (Advanced Configuration and Power Interface) 
> table"
> +   default n
> +   help
> + The Advanced Configuration and Power Interface (ACPI) specification
> + provides an open standard for device configuration and management
> + by the operating system. It defines platform-independent interfaces
> + for configuration and power management monitoring.
> +
>  endmenu
>
>  config MAX_PIRQ_LINKS
> diff --git a/arch/x86/include/asm/acpi_table.h 
> b/arch/x86/include/asm/acpi_table.h
> new file mode 100644
> index 000..971adde
> --- /dev/null
> +++ b/arch/x86/include/asm/acpi_table.h
> @@ -0,0 +1,398 @@
> +/*
> + * From coreboot

Has it been modified? If so you could say 'based on the same filename
in coreboot' and add your own copyright at the bottom. But if you have
not changed it then this is fine.

Please check that for each file.

> + *
> + * Copyright (C) 2004 SUSE LINUX AG
> + * Copyright (C) 2004 Nick Barker
> + * Copyright (C) 2008-2009 coresystems GmbH
> + * (Written by Stefan Reinauer )
> + *
> + * SPDX-License-Identifier:   GPL-2.0
> + */
> +

#include  here
> +#include 
> +#include 
> +#include 
> +#include 

Ordering should be:






"local.h"

> +
> +#define RSDP_SIG "RSD PTR "  /* RSDT pointer signature */
> +#define ACPI_TABLE_CREATOR "UBOOT   "  /* Must be exactly 8 bytes long! */
> +#define OEM_ID "UBOOT "/* Must be exactly 6 bytes long! */
> +#define ASLC "INTL"  /* Must be exactly 4 bytes long! */
> +
> +#define OEM_REVISION 42
> +#define ASL_COMPILER_REVISION 42
> +
> +#define APM_CNT 0xb2
> +#define APM_CNT_CST_CONTROL 0x85
> +#define APM_CNT_PST_CONTROL 0x80
> +#define APM_CNT_ACPI_DISABLE 0x1e
> +#define APM_CNT_ACPI_ENABLE 0xe1
> +#define APM_CNT_MBI_UPDATE 0xeb
> +#define APM_CNT_GNVS_UPDATE 0xea
> +#define APM_CNT_FINALIZE 0xcb
> +#define APM_CNT_LEGACY 0xcc
> +#define APM_ST 0xb3
> +
> +#define MP_IRQ_POLARITY_DEFAULT 0x0
> +#define MP_IRQ_POLARITY_HIGH 0x1
> +#define MP_IRQ_POLARITY_LOW 0x3
> +#define MP_IRQ_POLARITY_MASK 0x3
> +#define MP_IRQ_TRIGGER_DEFAULT 0x0
> +#define MP_IRQ_TRIGGER_EDGE 0x4
> +#define MP_IRQ_TRIGGER_LEVEL 0xc
> +#define MP_IRQ_TRIGGER_MASK 0xc
> +
> +#define ACTL 0x00
> +#define SCIS_MASK 0x07
> +#define SCIS_IRQ9 0x00
> +#define SCIS_IRQ10 0x01
> +#define SCIS_IRQ11 0x02
> +#define SCIS_IRQ20 0x04
> +#define SCIS_IRQ21 0x05
> +#define SCIS_IRQ22 0x06
> +#define SCIS_IRQ23 0x07
> +
> +enum acpi_bus_type {
> +   PIC = 0,
> +   APIC = 2,
> +   ETHIGH = 5
> +};
> +
> +#define ACPI_REV_ACPI_1_0 1
> +#define ACPI_REV_ACPI_2_0 1
> +#define ACPI_REV_ACPI_3_0 2
> +#define ACPI_REV_ACPI_4_0 3
> +#define ACPI_REV_ACPI_5_0 5
> +
> +#define ACPI_RSDP_REV_ACPI_1_0 0
> +#define ACPI_RSDP_REV_ACPI_2_0 2
> +
> +typedef struct acpi_gen_regaddr {
> +   u8  space_id;/* Address space ID */
> +   u8  bit_width;   /* Register size in bits */
> +   u8  bit_offset;  /* Register bit offset */
> +   union {
> +   /* Reserved in ACPI 2.0 - 2.0b */
> +   u8  resv;
> +   /* Access size in ACPI 2.0c/3.0/4.0/5.0 */
> +   u8  access_size;
> +   };
> +   u32 addrl; /* Register address, low 32 bits */
> +   u32 addrh; /* Register address, high 32 bits */
> +} acpi_addr_t;
> +
> +
> +/* RSDP (Root System Description Pointer)
> +Note: ACPI 1.0 didn't have length, xsdt_address, and ext_checksum. */
> +struct acpi_rsdp {
> +   char  signature[8]; /* RSDP signature */
> +   u8che

Re: [U-Boot] [UBOOT PATCH v4 3/3] x86: Add DSDT table for supporting ACPI on QEMU

[Simon Glass]

Hi Saket,

On 15 August 2015 at 23:10, Saket Sinha  wrote:
> The DSDT table contains a bytecode that is executed by a driver in the kernel.
>
> Signed-off-by: Saket Sinha 
> ---
>
>  arch/x86/cpu/qemu/Makefile |   2 +-
>  arch/x86/cpu/qemu/acpi/cpu-hotplug.asl |  78 +++
>  arch/x86/cpu/qemu/acpi/dbug.asl|  26 +++
>  arch/x86/cpu/qemu/acpi/hpet.asl|  33 +++
>  arch/x86/cpu/qemu/acpi/isa.asl | 102 
>  arch/x86/cpu/qemu/acpi/pci-crs.asl |  61 +
>  arch/x86/cpu/qemu/dsdt.asl | 414 
> +
>  7 files changed, 715 insertions(+), 1 deletion(-)
>  create mode 100644 arch/x86/cpu/qemu/acpi/cpu-hotplug.asl
>  create mode 100644 arch/x86/cpu/qemu/acpi/dbug.asl
>  create mode 100644 arch/x86/cpu/qemu/acpi/hpet.asl
>  create mode 100644 arch/x86/cpu/qemu/acpi/isa.asl
>  create mode 100644 arch/x86/cpu/qemu/acpi/pci-crs.asl
>  create mode 100644 arch/x86/cpu/qemu/dsdt.asl

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