Re: [U-Boot] [PATCH V2 0/5] Add support for additional splash screen locations

[Nikita Kiryanov]

Ping^2!

On Sun, Nov 08, 2015 at 10:27:16AM +0200, Nikita Kiryanov wrote:
> Ping!
> 
> On Thu, Oct 29, 2015 at 11:54:39AM +0200, Nikita Kiryanov wrote:
> > This series adds the following functionality to the splash_source library:
> > - load splash image from filesystem formatted usb storage
> > - load splash image from filesystem formatted mmc storage
> > - load splash image from filesystem formatted sata storage
> > 
> > Finally, use the new features on cm-fx6.
> > 
> > Changes in V2:
> > - Rebased over current mainline.
> > - Added "splashfile" env variable to select splash file name 
> > dynamically.
> >   Also available: default value "splash.bmp"
> > - Added documentation for the feature.
> > - Refactored device initialization code so that #ifdefs are outside of
> >   the functions. This affects patches 3 and 4.
> > 
> > Cc: Igor Grinberg 
> > Cc: Tom Rini 
> > 
> > Nikita Kiryanov (5):
> >   splash_source: rename *_read() to *_read_raw()
> >   splash_source: add support for filesystem formatted mmc
> >   splash_source: add support for filesystem formatted usb
> >   splash_source: add support for filesystem formatted sata
> >   arm: mx6: cm-fx6: add splash locations to cm-fx6
> > 
> >  board/compulab/cm_fx6/cm_fx6.c |  19 +++
> >  board/compulab/cm_t35/cm_t35.c |   1 +
> >  common/splash_source.c | 125 
> > +
> >  doc/README.splashprepare   |   5 ++
> >  include/splash.h   |  10 
> >  5 files changed, 150 insertions(+), 10 deletions(-)
> > 
> > -- 
> > 1.9.1
> > 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] dm: Add timeline and guide for porting serial drivers

[Peter Korsgaard]

> "Simon" == Simon Glass  writes:

 > Add a README with a brief guide to porting serial drivers over to use
 > driver model.

 > Add a timeline also. All serial drivers should be converted by the end
 > of January 2015.

2015?

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

Re: [U-Boot] [PATCH v2] dm: Add timeline and guide for porting serial drivers

[Thomas Chou]

Hi Simon,

On 2015年11月14日 23:27, Simon Glass wrote:

Add a README with a brief guide to porting serial drivers over to use
driver model.

Add a timeline also. All serial drivers should be converted by the end
of January 2015.


January 2016



Signed-off-by: Simon Glass 
---
To avoid anyone missing out on this, I have added to Cc the all U-Boot
maintainers using this:

(for f in $(find . -name MAINTAINERS); do grep ^M: $f; done) | \
awk '{$1=""; print "Series-cc:" $0}' |sort | uniq

This is about 229 email address, of which 217 seem to be different people.

Changes in v2:
- Copy the patch to all maintainers
- Move the timeline back to January

  doc/driver-model/serial-howto.txt | 58 +++
  1 file changed, 58 insertions(+)
  create mode 100644 doc/driver-model/serial-howto.txt

diff --git a/doc/driver-model/serial-howto.txt 
b/doc/driver-model/serial-howto.txt
new file mode 100644
index 000..7a72a32
--- /dev/null
+++ b/doc/driver-model/serial-howto.txt
@@ -0,0 +1,58 @@
+How to port a serial driver to driver model
+===
+
+About 16 of 33 serial drivers have been converted as at September 2015. It
+is time for maintainers to start converting over the remaining serial drivers:
+
+   altera_jtag_uart.c
+   altera_uart.c


altera_jtag_uart.c and altera_uart.c are converted to driver model. :)


+   arm_dcc.c
+   lpc32xx_hsuart.c
+   mcfuart.c
+   mxs_auart.c
+   opencores_yanu.c
+   serial_bfin.c
+   serial_imx.c
+   serial_lpuart.c
+   serial_max3100.c
+   serial_pxa.c
+   serial_s3c24x0.c
+   serial_sa1100.c
+   serial_stm32.c
+   serial_xuartlite.c
+   usbtty.c
+
+You should complete this by the end of January 2015.


2016.

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

Re: [U-Boot] [PATCH V2 01/12] Makefile: Include vendor common library in include search path

[Igor Grinberg]

Hi Nishanth,

On 11/13/15 07:43, Nishanth Menon wrote:
> When the vendor common libraries exists, then board should be able to
> reference headers located from a generic base, rather than having to
> do weird logic such as '#include "../common/xyz.h"'.
> 
> There are multiple options of implementation, the current strategy
> expects that:
> a) Vendor boards that need generic files will define build in:
>   board/$(VENDOR)/common
> b) Vendor boards that expose generic functions from (a) for usage
> from other board specific files will provide these headers in:
>   board/$(VENDOR)/common/include/board-common

I would agree with Simon - no need for additional /common/ in the path.

> c) Vendor board files that need these function services will refer
>   #include 
>   Where, xyz.h is an example header exposing generic vendor common
>   functions.
> 
> Cc: Simon Glass 
> Cc: Tom Rini 
> Cc: Masahiro Yamada 
> Cc: Daniel Schwierzeck 
> Cc: Michal Marek 
> Cc: Stefan Roese 
> Cc: Bin Meng 
> 
> Signed-off-by: Nishanth Menon 
> ---
>  Makefile | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index 61050adb13f5..e7a3e2b4de51 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -626,6 +626,9 @@ c_flags := $(KBUILD_CFLAGS) $(cpp_flags)
>  # U-Boot objectsorder is important (i.e. start must be first)
>  
>  HAVE_VENDOR_COMMON_LIB = $(if $(wildcard 
> $(srctree)/board/$(VENDOR)/common/Makefile),y,n)
> +# Include vendor headers - they should be in the following location.
> +# board/$(VENDOR)/common/include/board-common
> +UBOOTINCLUDE += $(if $(HAVE_VENDOR_COMMON_LIB:y=1), 
> -I$(srctree)/board/$(VENDOR)/common/include)
>  
>  libs-y += lib/
>  libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
> 

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

Re: [U-Boot] [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum A008514

[Yao Yuan]

Hi York,

Thanks,
And is there any other comments for this set of patches?
Or could I send v3 for review?

Best Regards,

Yuan Yao

From: York Sun 
Sent: Wednesday, November 11, 2015 0:43
To: Yuan Yao-B46683
Cc: Wang Huan-B18965; u-boot@lists.denx.de
Subject: Re: [PATCH v2 4/5] armv7/fsl-ls102xa: Workaround for DDR erratum 
A008514

On 11/10/2015 05:18 AM, Yuan Yao-B46683 wrote:
> Thanks york,
>
> So it seems I should moving the workaround out of DDR driver in "gen4" to SoC.
> I think the workaround is not just only for ddr4.
> And It should be as a workaround for the SOC.

Please make the patch if you are comfortable. Please gate the code with the
macro CONFIG_SYS_FSL_ERRATUM_A008514.

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

Re: [U-Boot] [PATCH v3] Fix board init code to use a valid C runtime environment

[Albert ARIBAUD]

Hello Simon,

On Sat, 14 Nov 2015 08:41:01 -0700, Simon Glass 
wrote:

> Reading between the lines, there isn't actually a problem with this in
> practice, but it is doing things that C should not really be doing. Is
> that right?

You did not even need to read between the lines :) as the very first
comment to the v1 of this patch was an explicit question whether I had
seen actual failure cause by board_init_f_mem() -- and my explicit
answer was that no, I hadn't, but as an analogy, I hadn't personally
seen any car crash caused by worn tires either, and that did not deter
me from changing worn tires as soon as I noticed them rather than wait
for the tires to fail.

> To me it seems OK provided we can assume that the stack
> needed to call the function is less than 64 bytes. But I'm sure there
> is a spec somewhere that the current function violates. Your idea of
> what constitutes the stack seems slightly different to mine - I think
> of it as the data already written, whereas you think of it as data yet
> to write, There is some associated uncertainty since the compiler is
> free to fiddle with the stack pointer. In practice in a boot loader we
> always make some architectural assumptions based on current operation.
> But I agree we should minimise this.

Ok.

> Anyway, I think your solution only adds one more function and still
> has most of the code in C rather than assembler, so that it is common
> to all archs. That was my main goal with the change.

Just to clarify, keeping as much C as possible is my goal too.
Especially, the patch keeps the size computation in a C function rather
than reverting back to computing it in crt0.S as it was 'in olden
days'; that is because computing the size in a C function is much more
flexible than it would be in assembly language, and accessible to many
more developers.

My general view of assembly vs C language is that assembly language
should only be used to perform things that cannot be done in C language
without violating the C runtime environment, or for which a C runtime
environment is not available, or which may fail depending on the
compiler implementation. This essentially covers:

- the entry point: when it is directly pointed at by the reset vector,
  it obviously does not have a C runtime environment, and it usually
  does not have one either even when it it entered from ROM code. In
  fact, the general goal of the entry point is to set up the C runtime
  environment(s).

- exception vectors: except for rare architectures for which the
  compiler provides a way to directly write interrupt routines in C,
  exception vectors have to be written in assembly language; again,
  their role *is* to set up the C runtime environment for the C
  language exception handler.

- exceptional cases where any implementation of some design in C
  conflicts with the compiler implementation. Of course, these case are
  specific to an architecture and frequently even a compiler version
  (see below for the r9-as-GD issue) and must only resort to assembly
  language for said architecture, and use as little of it as possible.
  Typically, such designs are related to an architecture's system ABI,
  which a compiler does not necessarily handle -- again, r9 as a system
  wide constant register comes to the mind of the ARM custodian -- or
  the need for specific instructions for which the compiler does not
  provide support in C (mcr and mrc are ARM examples).

Also, while the patch does add one C function, it does not change the C
code functionally overall, and adds very little assembly code, thereby
resulting in a negligible global code increase (actually, on ARM, I see
more boards experiencing a slight global code size *decrease* than boards
experiencing an *increase*).

> I prefer to set up gd in the C function if we can, to avoid the
> oddness that gd has to be at the bottom and the associated 16-byte
> alignment issue. But let's see how that goes. If we need to do it in
> assembler, it might be better to require the caller to do it before
> calling board_init_f_reserve().

Right now I only see two architectures which cannot set GD in
arch_setup_gd(): x86 and ARM; my patch takes care not to affect other
arches, nor do I have an intent to do so. They can set GD from C, and
that's fine.

Note about the ARM case:

Regarding ARM, I do change the behaviour for all of ARM, whereas the
issue of arch_setup_gd() failing to set r9 only happens for Thumb-1 code
generation and only with gcc 5.2.1 (and possibly a few other versions).

This is because, as I said elsewhere, I fear that the gcc -ffixed-reg
behaviour change is compliant with a strict interpretation of the
option (all accesses to r9 from user C code will return the same
value) and therefore I expect later gcc versions to not change the
Thumb-1 behaviour; it might even happen that this behaviour change be
'ported over' to Thumb-2 or even ARM code generation.

As the ARM custodian, I do not view tracking gcc 

Re: [U-Boot] [PATCH v2 18/26] dm: usb: Remove inactive children after a bus scan

[Hans de Goede]

Hi,

On 11/13/2015 10:58 PM, Simon Glass wrote:

Hi Hans,





Talking about usb-stop, there is still one (BIG!) problem after
this patch set when building usb-support with DM_DEVICE_REMOVE
not set. This means that the controllers dma engines will not
be stopped when booting the actual OS and they will still be
accessing parts of the main memory while the actual OS is
booting, which is BAD. So I suggest adding something like
this to all host drivers which use dma in this way:

#if defined CONFIG_DM_USB && !defined CONFIG_DM_DEVICE_REMOVE
#error The EHCI driver cannot be used without CONFIG_DM_DEVICE_REMOVE
otherwise DMA stays active while booting the OS
#endif



Sounds good. I am not suggesting that we encourage people to build USB
with out DM_DEVICE_REMOVE. I just want to make sure that we don't
create unnecessary dependencies such that DM_DEVICE_REMOVE becomes
impossible to use.

We have a note in the Kconfig for that, but I agree we need to make it
more explicit. With the #if approach it makes the pitfall much more
obvious.



Ack, so we need to have patches for this for at least ohci, ehci, xhci
and I guess also uhci ? Who is going to write these patches ?


I suppose I could do that. I would like to make sure that any USB fish
hooks are removed, and that is part of the solution.

I'd really like to resolve this and move things forward. If you still
have have strong objections please let me know.


There are no objections from my side to move forward with your current
solution.


We did discuss this at
the time and I was clear that I did not want to keep the solution as
it was - I merged it because it fixed a bug, as you pointed out at the
time.


Ack.

Regards,

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

Re: [U-Boot] [PATCH] usb: kbd: don't use int xfers when polling via ctrl xfers

[Hans de Goede]

Hi,

On 11/13/2015 09:34 PM, Stephen Warren wrote:

From: Stephen Warren 

When CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP is enabled, use a
GET_REPORT control transfer to retrieve the initial state of the
keyboard. This matches the technique used to poll the keyboard state.
This is useful since it eliminates the remaining use of interrupt
transfers from the USB keyboard driver, which allows it to work with
USB HCD that don't support interrupt transfers.

Cc: Hans de Goede 
Signed-off-by: Stephen Warren 
---
Are there any disadvantages to using control transfers over interrupt
transfers? I'm not aware of any, but I assume there must be a reason
that U-Boot typically uses interrupt transfers.


I know of at least 2 issues with using control transfers, and IMHO we
should try to just remove support for control transfers from the usb
kbd drivers.

The 2 known issues are:

1) I've some cheap wireless keyboards where the usb-dongle does not
support the ctrl method of polling and things simply do not work
when using it.

2) My USB+DVI kvm switch will report keys as pressed to all connected
machines, even those without focus when using the ctrl method (this makes
sense since other control methods must work without focus to keep the
os on the machine happy).

Regards,

Hans



---
  common/usb_kbd.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index 95912f99c767..81c4d62c632b 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -475,6 +475,9 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned 
int ifnum)
  USB_KBD_BOOT_REPORT_SIZE, data->new,
  data->intinterval);
if (!data->intq) {
+#elif defined(CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP)
+   if (usb_get_report(dev, iface->desc.bInterfaceNumber,
+  1, 0, data->new, USB_KBD_BOOT_REPORT_SIZE) < 0) {
  #else
if (usb_submit_int_msg(dev, data->intpipe, data->new, data->intpktsize,
   data->intinterval) < 0) {


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

Re: [U-Boot] [PATCH v7 21/21] sf: Add SPI NOR protection mechanism

[Simon Glass]

Hi,

On 13 November 2015 at 03:41, Bin Meng  wrote:
> Hi,
>
> On Wed, Nov 11, 2015 at 10:04 PM, Fabio Estevam  wrote:
>> On Wed, Nov 11, 2015 at 12:56 AM, Simon Glass  wrote:
>>> Hi Fabio,
>>>
>>> On 10 November 2015 at 16:51, Fabio Estevam  wrote:

 Hi Simon,

 On Tue, Nov 10, 2015 at 10:09 PM, Simon Glass  wrote:

 > This patch breaks chromebook_link - I think because it adds a new
 > operation which is not supported by all flash chips. Those that are
 > not supported (i.e that don't have the 'flash_is_locked' method)
 > should still work.

 What is the symptom you are seeing? Which SPI NOR flash does this board 
 have?
>>>
>>> It crashes reading the environment:
>>>
>>> U-Boot 2015.10-00544-gcad0499 (Nov 10 2015 - 17:06:00 -0700)
>>>
>>> CPU:   Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
>>> DRAM:  2.7 GiB
>>> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 8 
>>> MiB
>>> *** Warning - bad CRC, using default environment
>>>
>>> Video: 1280x1024x16
>>> Model: Google Link
>>> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 8 
>>> MiB
>>> Invalid Opcode (Undefined Opcode)
>>
>> I am wondering if this invalid opcode is caused by 6c2f758cee266f7648.
>>
>> Could you please try this?
>>
>
> No, this does not resolve this issue.
>
>> --- a/arch/x86/include/asm/bitops.h
>> +++ b/arch/x86/include/asm/bitops.h
>> @@ -364,7 +364,7 @@ static __inline__ int ffs(int x)
>> __asm__("bsfl %1,%0\n\t"
>> "jnz 1f\n\t"
>> "movl $-1,%0\n"
>> -   "1:" : "=r" (r) : "rm" (x));
>> +   "1:" : "=r" (r) : "g" (x));
>>
>> return r+1;
>>  }
>
> It turns out it is a NULL pointer exception! Fixing this NULL pointer
> makes the crash disappear, but 'saveenv' does not actually work on the
> SST flash. Something is broken again, gosh!

Bin thank you for fixing this.

We still have a big problem with this patch though - it adds features
to the pre-driver-model SPI flash implementation and not the driver
model implementation! If I somehow have the wrong end of the stick
please let me know.

If we accept this sort of patch we will never be done with driver
model conversions, as we make it impossible for boards to move
forward.

Fabio can you please rework this to remove the pre-driver-model
support, and add your new functions to struct dm_spi_flash_ops
instead, then convert the affected boards to driver model?

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

Re: [U-Boot] [PATCH 08/14] dm: pci: Reorder functions in cmd_pci.c

[Simon Glass]

Hi Bin,

On 13 November 2015 at 00:11, Bin Meng  wrote:
> Hi Simon,
>
> On Fri, Nov 13, 2015 at 5:45 AM, Simon Glass  wrote:
>> Before converting this to driver model, reorder the code to avoid forward
>> function declarations.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>>  common/cmd_pci.c | 216 
>> +++
>>  1 file changed, 106 insertions(+), 110 deletions(-)
>>
>> diff --git a/common/cmd_pci.c b/common/cmd_pci.c
>> index debcd1c..53b0f42 100644
>> --- a/common/cmd_pci.c
>> +++ b/common/cmd_pci.c
>> @@ -21,115 +21,6 @@
>>  #include 
>>  #include 
>>
>> -/*
>> - * Follows routines for the output of infos about devices on PCI bus.
>> - */
>> -
>> -void pci_header_show(pci_dev_t dev);
>> -void pci_header_show_brief(pci_dev_t dev);
>> -
>> -/*
>> - * Subroutine:  pciinfo
>> - *
>> - * Description: Show information about devices on PCI bus.
>> - * Depending on the define 
>> CONFIG_SYS_SHORT_PCI_LISTING
>> - * the output will be more or less exhaustive.
>> - *
>> - * Inputs: bus_no  the number of the bus to be scanned.
>> - *
>> - * Return:  None
>> - *
>> - */
>> -void pciinfo(int BusNum, int ShortPCIListing)
>> -{
>> -   struct pci_controller *hose = pci_bus_to_hose(BusNum);
>> -   int Device;
>> -   int Function;
>> -   unsigned char HeaderType;
>> -   unsigned short VendorID;
>> -   pci_dev_t dev;
>> -   int ret;
>> -
>> -   if (!hose)
>> -   return;
>> -
>> -   printf("Scanning PCI devices on bus %d\n", BusNum);
>> -
>> -   if (ShortPCIListing) {
>> -   printf("BusDevFun  VendorId   DeviceId   Device Class   
>> Sub-Class\n");
>> -   
>> printf("_\n");
>> -   }
>> -
>> -   for (Device = 0; Device < PCI_MAX_PCI_DEVICES; Device++) {
>> -   HeaderType = 0;
>> -   VendorID = 0;
>> -   for (Function = 0; Function < PCI_MAX_PCI_FUNCTIONS; 
>> Function++) {
>> -   /*
>> -* If this is not a multi-function device, we skip 
>> the rest.
>> -*/
>> -   if (Function && !(HeaderType & 0x80))
>> -   break;
>> -
>> -   dev = PCI_BDF(BusNum, Device, Function);
>> -
>> -   if (pci_skip_dev(hose, dev))
>> -   continue;
>> -
>> -   ret = pci_read_config_word(dev, PCI_VENDOR_ID,
>> -  );
>> -   if (ret)
>> -   goto error;
>> -   if ((VendorID == 0x) || (VendorID == 0x))
>> -   continue;
>> -
>> -   if (!Function) pci_read_config_byte(dev, 
>> PCI_HEADER_TYPE, );
>> -
>> -   if (ShortPCIListing)
>> -   {
>> -   printf("%02x.%02x.%02x   ", BusNum, Device, 
>> Function);
>> -   pci_header_show_brief(dev);
>> -   }
>> -   else
>> -   {
>> -   printf("\nFound PCI device 
>> %02x.%02x.%02x:\n",
>> -  BusNum, Device, Function);
>> -   pci_header_show(dev);
>> -   }
>> -   }
>> -   }
>> -
>> -   return;
>> -error:
>> -   printf("Cannot read bus configuration: %d\n", ret);
>> -}
>> -
>> -
>> -/*
>> - * Subroutine:  pci_header_show_brief
>> - *
>> - * Description: Reads and prints the header of the
>> - * specified PCI device in short form.
>> - *
>> - * Inputs: dev  Bus+Device+Function number
>> - *
>> - * Return:  None
>> - *
>> - */
>> -void pci_header_show_brief(pci_dev_t dev)
>> -{
>> -   u16 vendor, device;
>> -   u8 class, subclass;
>> -
>> -   pci_read_config_word(dev, PCI_VENDOR_ID, );
>> -   pci_read_config_word(dev, PCI_DEVICE_ID, );
>> -   pci_read_config_byte(dev, PCI_CLASS_CODE, );
>> -   pci_read_config_byte(dev, PCI_CLASS_SUB_CODE, );
>> -
>> -   printf("0x%.4x 0x%.4x %-23s 0x%.2x\n",
>> -  vendor, device,
>> -  pci_class_str(class), subclass);
>> -}
>> -
>>  struct pci_reg_info {
>> const char *name;
>> enum pci_size_t size;
>> @@ -283,10 +174,10 @@ void pci_header_show(pci_dev_t dev)
>>  {
>> u8 _byte, header_type;
>>
>> +   pci_read_config_byte(dev, PCI_CLASS_CODE, &_byte);
>> pci_read_config_byte(dev, PCI_HEADER_TYPE, _type);
>> pci_show_regs(dev, regs_start);
>>
>> -   pci_read_config_byte(dev, PCI_CLASS_CODE, &_byte);
>> printf("  class code =  

Re: [U-Boot] [PATCH V2 07/12] board: LaCie: Move common headers to board-common directory

[Tom Rini]

On Fri, Nov 13, 2015 at 07:05:40PM -0700, Simon Glass wrote:
> Hi Nishanth,
> 
> On 13 November 2015 at 16:57, Nishanth Menon  wrote:
> > On 11/13/2015 09:32 AM, Simon Guinot wrote:
> >> On Fri, Nov 13, 2015 at 09:06:45AM -0500, Tom Rini wrote:
> >>> On Fri, Nov 13, 2015 at 11:30:43AM +0100, Simon Guinot wrote:
>  Hi Nishanth,
> 
>  On Thu, Nov 12, 2015 at 11:43:37PM -0600, Nishanth Menon wrote:
> > Header files can be located in a generic location without
> > needing to reference them with ../common/
> >
> > Generated with the following script
> >
> >  #!/bin/bash
> > vendor=board/LaCie
> > common=$vendor/common
> >
> > cfiles=`git grep "../common" $vendor|grep "#include"|cut -d '"' 
> > -f2|sort -u|grep c$`
> > headers=`git grep "../common" $vendor|grep "#include"|cut -d '"' 
> > -f2|sort -u|grep h$`
> >
> > mkdir -p $common/include/board-common
> > set -x
> > for header in $headers
> > do
> >echo "processing $header in $common"
> >hbase=`basename $header`
> >git mv $common/$hbase $common/include/board-common
> >sed -i -e "s/\"..\/common\/$hbase\"//g" 
> > $vendor/*/*.[chS]
> >sed -i -e "s/\"$hbase\"//g" 
> > $vendor/common/*.[chS]
> > done
> >
> > Cc: Simon Guinot 
> > Cc: Albert ARIBAUD 
> >
> > Signed-off-by: Nishanth Menon 
> > ---
> >  board/LaCie/common/cpld-gpio-bus.c| 2 +-
> >  board/LaCie/common/{ => include/board-common}/common.h| 0
> 
>  Is that really a good idea to move a LaCie-specific file named common.h
>  to a place shared with other boards ?
> 
> >  board/LaCie/common/{ => include/board-common}/cpld-gpio-bus.h | 0
> 
>  IMO, this headers are specific to LaCie boards and it don't make much
>  sense to move them to a shared place. Moreover it is quite convenient to
>  have them close from the board setup files.
> 
>  Please don't move them.
> >>>
> >>> Please read and then suggest changes in the "Makefile: Include vendor
> >>> common library in include search path" thread.  Thanks!
> >>
> >> Hi Tom,
> >>
> >> Do you mean I answered without even really looking at the suggested
> >> change ? Well, it is true :)
> >>
> >> Sorry about that. I have been confused by the "git move file" notation
> >> which I am not familiar with. So, I withdraw my previous objections.
> >>
> >
> > Thanks.
> >
> >> Now, I have to say that I am still not convinced by the change.
> >>
> >> After applying this patch, I can see that:
> >>
> >> #include "../common/cpld-gpio-bus.h"
> >>
> >> have been replaced with:
> >>
> >> #include 
> >>
> >> While this change is fine, I can also see that the header file has been
> >> moved from:
> >>
> >> board/LaCie/common/cpld-gpio-bus.h
> >>
> >> to:
> >>
> >> board/LaCie/common/include/board-common/cpld-gpio-bus.h
> >>
> >> With both the strings "board" and "common" duplicated, I am definitively
> >> not a big fan of this new path. Moreover I think that moving the headers
> >> away from the board setup files will harm a little bit the code reading.
> >>
> >> Maybe it would be better to have a shorter path like:
> >>
> >> board/LaCie/include/board-common/cpld-gpio-bus.h
> >
> > That can easily be done as well. for me, it is just regenerating the
> > scripts..
> >
> > I strongly suggest to comment on the original patch
> > https://patchwork.ozlabs.org/patch/544030/ and suggest this so that
> > other platform folks have the discussion context as well.
> >
> >>
> >> Anyway, IMHO things are fine as they are. But if anyone thinks this
> >> change is needed or valuable, then I am OK with it.
> >
> > IMHO, I started on this story, because we have a need to have a
> > board/ti/common directory and adding more cruft on top of what is
> > already a bunch of crufty includes is just painful.
> >
> > If you are interested in the complete history:
> > https://patchwork.ozlabs.org/patch/540280/
> > https://patchwork.ozlabs.org/patch/541068/
> > https://patchwork.ozlabs.org/patch/542424/
> >
> >
> > Tom, Simon,
> >
> > Are you guys ok with board/$(VENDOR)/include?
> 
> Yes.

Also Yes.

-- 
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 v3 05/11] dm: timer: Support 64-bit counter

[Bin Meng]

Hi Simon,

On Sat, Nov 14, 2015 at 10:04 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 13 November 2015 at 01:11, Bin Meng  wrote:
>> There are timers with a 64-bit counter value but current timer
>> uclass driver assumes a 32-bit one. Modify timer_get_count()
>> to ask timer driver to always return a 64-bit counter value,
>> and provide an inline helper function timer_conv_64() to handle
>> the 32-bit/64-bit conversion automatically.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> Changes in v3:
>> - Update commit message to reflect the v2 changes (ie: there is
>>   no "counter-64bit" property)
>>
>> Changes in v2:
>> - Do not use "counter-64bit" property, instead create an inline
>>   function for 32-bit timer driver to construct a 64-bit timer value.
>>
>>  drivers/timer/altera_timer.c  |  4 ++--
>>  drivers/timer/sandbox_timer.c |  2 +-
>>  drivers/timer/timer-uclass.c  |  8 +++-
>>  include/timer.h   | 23 ---
>>  lib/time.c|  9 ++---
>>  5 files changed, 32 insertions(+), 14 deletions(-)
>
> Is there a binding file for this timer somewhere? If both altera and
> sandbox share this property, should we add a generic binding? It
> doesn't look like Linux has one though.
>
>>
>> diff --git a/drivers/timer/altera_timer.c b/drivers/timer/altera_timer.c
>> index 6fe24f2..a7ed3cc 100644
>> --- a/drivers/timer/altera_timer.c
>> +++ b/drivers/timer/altera_timer.c
>> @@ -34,7 +34,7 @@ struct altera_timer_platdata {
>> struct altera_timer_regs *regs;
>>  };
>>
>> -static int altera_timer_get_count(struct udevice *dev, unsigned long *count)
>> +static int altera_timer_get_count(struct udevice *dev, u64 *count)
>>  {
>> struct altera_timer_platdata *plat = dev->platdata;
>> struct altera_timer_regs *const regs = plat->regs;
>> @@ -46,7 +46,7 @@ static int altera_timer_get_count(struct udevice *dev, 
>> unsigned long *count)
>> /* Read timer value */
>> val = readl(>snapl) & 0x;
>> val |= (readl(>snaph) & 0x) << 16;
>> -   *count = ~val;
>> +   *count = timer_conv_64(~val);
>>
>> return 0;
>>  }
>> diff --git a/drivers/timer/sandbox_timer.c b/drivers/timer/sandbox_timer.c
>> index 4b20af2..00a9944 100644
>> --- a/drivers/timer/sandbox_timer.c
>> +++ b/drivers/timer/sandbox_timer.c
>> @@ -18,7 +18,7 @@ void sandbox_timer_add_offset(unsigned long offset)
>> sandbox_timer_offset += offset;
>>  }
>>
>> -static int sandbox_timer_get_count(struct udevice *dev, unsigned long 
>> *count)
>> +static int sandbox_timer_get_count(struct udevice *dev, u64 *count)
>>  {
>> *count = os_get_nsec() / 1000 + sandbox_timer_offset * 1000;
>>
>> diff --git a/drivers/timer/timer-uclass.c b/drivers/timer/timer-uclass.c
>> index 0218591..1ef0012 100644
>> --- a/drivers/timer/timer-uclass.c
>> +++ b/drivers/timer/timer-uclass.c
>> @@ -9,18 +9,16 @@
>>  #include 
>>  #include 
>>
>> -DECLARE_GLOBAL_DATA_PTR;
>> -
>>  /*
>>   * Implement a timer uclass to work with lib/time.c. The timer is usually
>> - * a 32 bits free-running up counter. The get_rate() method is used to get
>> + * a 32/64 bits free-running up counter. The get_rate() method is used to 
>> get
>>   * the input clock frequency of the timer. The get_count() method is used
>> - * to get the current 32 bits count value. If the hardware is counting down,
>> + * to get the current 64 bits count value. If the hardware is counting down,
>>   * the value should be inversed inside the method. There may be no real
>>   * tick, and no timer interrupt.
>>   */
>>
>> -int timer_get_count(struct udevice *dev, unsigned long *count)
>> +int timer_get_count(struct udevice *dev, u64 *count)
>>  {
>> const struct timer_ops *ops = device_get_ops(dev);
>>
>> diff --git a/include/timer.h b/include/timer.h
>> index ed5c685..4eed504 100644
>> --- a/include/timer.h
>> +++ b/include/timer.h
>> @@ -7,6 +7,23 @@
>>  #ifndef _TIMER_H_
>>  #define _TIMER_H_
>>
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +/*
>> + * timer_conv_64 - convert 32-bit counter value to 64-bit
>> + *
>> + * @count: 32-bit counter value
>> + * @return: 64-bit counter value
>> + */
>> +static inline u64 timer_conv_64(u32 count)
>> +{
>> +   /* increment tbh if tbl has rolled over */
>> +   if (count < gd->timebase_l)
>> +   gd->timebase_h++;
>> +   gd->timebase_l = count;
>> +   return ((u64)gd->timebase_h << 32) | gd->timebase_l;
>> +}
>> +
>>  /*
>>   * Get the current timer count
>>   *
>> @@ -14,7 +31,7 @@
>>   * @count: pointer that returns the current timer count
>>   * @return: 0 if OK, -ve on error
>>   */
>> -int timer_get_count(struct udevice *dev, unsigned long *count);
>> +int timer_get_count(struct udevice *dev, u64 *count);
>>
>>  /*
>>   * Get the timer input clock frequency
>> @@ -35,10 +52,10 @@ struct timer_ops {
>>  * Get the current timer count
>>  *
>>  * @dev: The 

Re: [U-Boot] [PATCH v4 05/21] sf: Make flash->flags use for generic usage

[Bin Meng]

Hi Jagan,

On Mon, Oct 12, 2015 at 11:00 PM, Jagan Teki  wrote:
> 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 
> [Correct the spi flash flags detect logic]
> Signed-off-by: Bin Meng 
> Tested-by: Bin Meng 
> ---
> Changes for v4:
> - Fixed SNOR_F_SST_WR
> Changes for v3, v2:
> - none
>

It turns out this patch breaks the Intel Crown Bay SPI flash. I
compared my original submitted patch with this patch you applied, and
surprisingly found there are differences ...

My version is http://patchwork.ozlabs.org/patch/517704/
You version below seems to modify some places which you thought would
be correct, but that's unfortunately wrong. If you reworked my patch,
I think you should remove at least my "Tested-by:" tag and ask me to
retest.

Can you please help me understand what happened? I expected that you
should just grab my version and include it in your patch series.

>  drivers/mtd/spi/sf_internal.h |  4 
>  drivers/mtd/spi/sf_probe.c| 10 +-
>  include/spi_flash.h   |  4 ++--
>  3 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 9c95d56..53998fc 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -51,6 +51,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 f17ec17..2634e90 100644
> --- a/drivers/mtd/spi/sf_probe.c
> +++ b/drivers/mtd/spi/sf_probe.c
> @@ -163,15 +163,15 @@ 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) {
> +   if (params->flags & SST_WR)
> +   flash->flags |= SNOR_F_SST_WR;
> +
> +   if (params->flags & SNOR_F_SST_WR) {
> if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
> flash->write = sst_write_bp;
> else
> @@ -466,7 +466,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;
> --

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

Re: [U-Boot] [PATCH v5 00/21] Bring up rk3036 uboot

[hl]

Hi Simon,

On 14/11/15 02:14, Simon Glass wrote:

Hi Lin,

On 10 November 2015 at 03:24, Lin Huang  wrote:

This series patch bring up rk3036 uboot, since rk3036 only 4K size
SRAM for SPL, so in SPL stage only support timer, uart, sdram driver,
and back to bootrom when finish ddr initial, and boot up second stage
from bootrom.You can boot to command line(mmc info etc) for now use
this patchset.

Jeffy Chen (2):
   rockchip: Add max init size & chip tag configs
   rockchip: Add support for rk's second level loader

Lin Huang (19):
   rockchip: add timer driver
   rockchip: move SYS_MALLOC_F_LEN to rk3288 own Kconfig
   rockchip: rename board-spl.c to rk3288-board-spl.c
   rockchip: add config decide whether to build common.c
   dm: core: Add SPL Kconfig for REGMAP and SYSCON
   rockchip: serial driver support rk3036
   rockchip: Bring in RK3036 device tree file includes and bindings
   rockchip: rk3036: Add clock driver
   rockchip: rk3036: Add header files for GRF
   rockchip: rk3036: Add Soc reset driver
   rockchip: rk3036: Add a simple syscon driver
   rockchip: rk3036: Add pinctrl driver
   mmc: dw_mmc: support fifo mode in dwc mmc driver
   rockchip: mmc: get the fifo mode and fifo depth property from dts
   rockchip: add early uart driver
   rockchip: add rk3036 sdram driver
   rockchip: rk3036: Add core Soc start-up code
   rockchip: Add basic support for evb-rk3036 board
   rockchip: doc: show packet rk3036 uboot image

  arch/arm/dts/Makefile |   3 +-
  arch/arm/dts/rk3036-sdk.dts   |  46 ++
  arch/arm/dts/rk3036.dtsi  | 428 
  arch/arm/include/asm/arch-rockchip/cru_rk3036.h   | 168 +
  arch/arm/include/asm/arch-rockchip/grf_rk3036.h   | 493 ++
  arch/arm/include/asm/arch-rockchip/sdram_rk3036.h | 341 ++
  arch/arm/include/asm/arch-rockchip/timer.h|  22 +
  arch/arm/include/asm/arch-rockchip/uart.h |  44 ++
  arch/arm/mach-rockchip/Kconfig|  24 +-
  arch/arm/mach-rockchip/Makefile   |  10 +-
  arch/arm/mach-rockchip/board-spl.c| 294 -
  arch/arm/mach-rockchip/board.c|   1 +
  arch/arm/mach-rockchip/rk3036-board-spl.c |  53 ++
  arch/arm/mach-rockchip/rk3036/Kconfig |  23 +
  arch/arm/mach-rockchip/rk3036/Makefile|  13 +
  arch/arm/mach-rockchip/rk3036/reset_rk3036.c  |  45 ++
  arch/arm/mach-rockchip/rk3036/save_boot_param.S   |  34 +
  arch/arm/mach-rockchip/rk3036/sdram_rk3036.c  | 766 ++
  arch/arm/mach-rockchip/rk3036/syscon_rk3036.c |  21 +
  arch/arm/mach-rockchip/rk3288-board-spl.c | 277 
  arch/arm/mach-rockchip/rk3288/Kconfig |   9 +
  arch/arm/mach-rockchip/rk_early_print.c   |  56 ++
  arch/arm/mach-rockchip/rk_timer.c |  48 ++
  board/evb_rk3036/evb_rk3036/Kconfig   |  15 +
  board/evb_rk3036/evb_rk3036/MAINTAINERS   |   0
  board/evb_rk3036/evb_rk3036/Makefile  |   7 +
  board/evb_rk3036/evb_rk3036/evb_rk3036.c  |  48 ++
  configs/chromebook_jerry_defconfig|   2 +
  configs/evb-rk3036_defconfig  |  26 +
  configs/firefly-rk3288_defconfig  |   2 +
  configs/sandbox_defconfig |   2 +
  doc/README.rockchip   |  11 +
  drivers/clk/Makefile  |   1 +
  drivers/clk/clk_rk3036.c  | 414 
  drivers/core/Kconfig  |  19 +
  drivers/core/Makefile |   4 +-
  drivers/mmc/dw_mmc.c  |  81 ++-
  drivers/mmc/rockchip_dw_mmc.c |  28 +-
  drivers/pinctrl/Kconfig   |  18 +
  drivers/pinctrl/rockchip/Makefile |   1 +
  drivers/pinctrl/rockchip/pinctrl_rk3036.c | 276 
  drivers/serial/serial_rockchip.c  |   1 +
  include/configs/evb_rk3036.h  |  12 +
  include/configs/rk3036_common.h   | 100 +++
  include/configs/rk3288_common.h   |   6 +-
  include/dt-bindings/clock/rk3036-cru.h| 186 ++
  include/dwmmc.h   |   5 +
  tools/Makefile|   6 +
  tools/rkcommon.c  |  26 +-
  tools/rkcommon.h  |   4 +-
  tools/rkimage.c   |   2 +-
  tools/rksd.c  |   6 +-
  tools/rkspi.c |   6 +-
  53 files changed, 4185 insertions(+), 349 deletions(-)
  create mode 100644 arch/arm/dts/rk3036-sdk.dts
  create mode 100644 arch/arm/dts/rk3036.dtsi
  create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3036.h
  

Re: [U-Boot] [PATCH] Fix sandbox build on Ubuntu 10.04

[Tom Rini]

On Sat, Nov 14, 2015 at 11:53:49PM -0700, Stephen Warren wrote:

> gcc 4.4.3 (which is the default native compiler on x86-64 Ubuntu 10.04)
> doesn't seem to like initializers for sub-fields of anonymous unions.
> Solve this by replacing the initialization with an assignment. This
> fixes:
> 
> lib/lz4_wrapper.c: In function ‘ulz4fn’:
> lib/lz4_wrapper.c:97: error: unknown field ‘raw’ specified in initializer
> 
> Signed-off-by: Stephen Warren 

So Ubuntu 10.04 hit end of life this past April.  I can be convinced but
as I'm personally staring down upgrading my 12.04 machine I need some
reason.

-- 
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 v5 12/21] rockchip: rk3036: Add pinctrl driver

[hl]

Hi Ariel,

On 14/11/15 07:54, Ariel D'Alessandro wrote:

Hi Lin,

El 10/11/15 a las 07:24, Lin Huang escribió:

Add a driver which support pin multiplexing setup for rk3036

Signed-off-by: Lin Huang 
Acked-by: Simon Glass 
---
Changes in v1:
- clean copyright announcement
Changes in v2: None
Changes in v3:
- fix some coding style error
Changes in v4: None
Changes in v5: None

  drivers/pinctrl/Kconfig   |  18 ++
  drivers/pinctrl/rockchip/Makefile |   1 +
  drivers/pinctrl/rockchip/pinctrl_rk3036.c | 276 ++
  3 files changed, 295 insertions(+)
  create mode 100644 drivers/pinctrl/rockchip/pinctrl_rk3036.c

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 3b6e3b7..6495313 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -114,6 +114,24 @@ config ROCKCHIP_PINCTRL
  definitions and pin control functions for each available multiplex
  function.
  
+config ROCKCHIP_3036_PINCTRL

+   bool "Rockchip rk3036 pin control driver"
+   depends on DM
+   help
+ Support pin multiplexing control on Rockchip rk3036 SoCs. The driver 
is
+ controlled by a device tree node which contains both the GPIO
+ definitions and pin control functions for each available multiplex
+ function.
+
+config ROCKCHIP_PINCTRL

You're duplicating ROCKCHIP_PINCTRL entry here.

Thanks, will fix next version.



+   bool "Rockchip pin control driver"
+   depends on DM
+   help
+ Support pin multiplexing control on Rockchip SoCs. The driver is
+ controlled by a device tree node which contains both the GPIO
+ definitions and pin control functions for each available multiplex
+ function.
+
  config PINCTRL_SANDBOX
bool "Sandbox pinctrl driver"
depends on SANDBOX

[...]



--
Lin Huang


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

Re: [U-Boot] [PATCH v2 09/16] arm: dts: dra7: add qspi register maps for memory map and control module

[Tom Rini]

On Sat, Nov 14, 2015 at 01:01:45PM +0530, Mugunthan V N wrote:
> On Thursday 12 November 2015 06:17 PM, Tom Rini wrote:
> > On Thu, Nov 12, 2015 at 02:33:48PM +0530, Mugunthan V N wrote:
> >> On Sunday 08 November 2015 07:01 PM, Tom Rini wrote:
> >>> On Wed, Nov 04, 2015 at 01:46:17PM +0530, Mugunthan V N wrote:
> >>>
>  Add qspi memory map and control module register maps to device tree.
> 
>  Signed-off-by: Mugunthan V N 
>  Reviewed-by: Simon Glass 
>  ---
>   arch/arm/dts/dra7.dtsi | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
>  diff --git a/arch/arm/dts/dra7.dtsi b/arch/arm/dts/dra7.dtsi
>  index 3060e9a..7045c0f 100644
>  --- a/arch/arm/dts/dra7.dtsi
>  +++ b/arch/arm/dts/dra7.dtsi
>  @@ -1104,8 +1104,8 @@
>   
>   qspi: qspi@4b30 {
>   compatible = "ti,dra7xxx-qspi";
>  -reg = <0x4b30 0x100>;
>  -reg-names = "qspi_base";
>  +reg = <0x4b30 0x100>, <0x5c00 
>  0x400>, <0x4a002558 0x4>;
>  +reg-names = "qspi_base", "qspi_mmap", 
>  "qspi_ctrlmod";
>   #address-cells = <1>;
>   #size-cells = <0>;
>   ti,hwmods = "qspi";
> >>>
> >>> Is this already upstream?
> >>>
> >>
> >> The documentation part is already upstreamed. Driver in kernel doesn't
> >> support mmap mode yet so dt changes are not present. Vignesh has
> >> submitted the mmap patches [1] and is under review.
> >>
> >> [1]: https://lkml.org/lkml/2015/11/10/14
> > 
> > OK, and we can't even get the reg names part in the DT upstream until
> > then?
> > 
> 
> I don't think we can get reg names in the DT upstream separately. But
> there shouldn't be any issues as there is documentation already present
> in kernel and submitted kernel patch DT nodes are similar to what I have
> submitted.

Similar or the same?  We'll be dropping in (and quick diff'ing) a new DT
from the kernel at some point in the future.  So if there's chance of
things changing, we want to wait.

-- 
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] ARM: mxs: fix VDDD brownout setting

[Michael Heimpold]

At the moment, the desired brownout is at 1.0V. However,
this setting cannot be realized by hardware since we have
only 3 bits to represent the voltage difference from the
target value.

Target value is 1500 mV, brownout target is 1000 mV,
voltage steps are 25 mV.

Register content calculation:
  (1500 [mV] - 1000 [mV]) / 25 [mV] = 20 (decimal) = 0x14

  Register takes only 3 bits, that is 0x4.

But 0x4 * 25 [mV] = 100 [mV], that means that actual
brownout level is 1500 [mV] - 100 [mV] = 1.4 V.

Minimum possible BO level is
  1500 [mV] - 0x7 * 25 [mV] = 1315 [mV].

So lets use this value as desired BO value (which is
also the same as FSL bootlets use).

Signed-off-by: Michael Heimpold 
Cc: Marek Vasut 
Cc: Otavio Salvador 
Cc: Fabio Estevam 
---
 arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c 
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index 42f3df2..1972de8 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -1221,8 +1221,8 @@ void mxs_power_init(void)
debug("SPL: Setting VDDIO to 3V3 (brownout @ 3v15)\n");
mxs_power_set_vddx(_vddio_cfg, 3300, 3150);
 
-   debug("SPL: Setting VDDD to 1V5 (brownout @ 1v0)\n");
-   mxs_power_set_vddx(_vddd_cfg, 1500, 1000);
+   debug("SPL: Setting VDDD to 1V5 (brownout @ 1v315)\n");
+   mxs_power_set_vddx(_vddd_cfg, 1500, 1315);
 #ifdef CONFIG_MX23
debug("SPL: Setting mx23 VDDMEM to 2V5 (brownout @ 1v7)\n");
mxs_power_set_vddx(_vddmem_cfg, 2500, 1700);
-- 
2.5.0

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

Re: [U-Boot] [PATCH v7 21/21] sf: Add SPI NOR protection mechanism

[Tom Rini]

On Sun, Nov 15, 2015 at 06:34:51PM -0700, Simon Glass wrote:
> Hi,
> 
> On 13 November 2015 at 03:41, Bin Meng  wrote:
> > Hi,
> >
> > On Wed, Nov 11, 2015 at 10:04 PM, Fabio Estevam  wrote:
> >> On Wed, Nov 11, 2015 at 12:56 AM, Simon Glass  wrote:
> >>> Hi Fabio,
> >>>
> >>> On 10 November 2015 at 16:51, Fabio Estevam  wrote:
> 
>  Hi Simon,
> 
>  On Tue, Nov 10, 2015 at 10:09 PM, Simon Glass  wrote:
> 
>  > This patch breaks chromebook_link - I think because it adds a new
>  > operation which is not supported by all flash chips. Those that are
>  > not supported (i.e that don't have the 'flash_is_locked' method)
>  > should still work.
> 
>  What is the symptom you are seeing? Which SPI NOR flash does this board 
>  have?
> >>>
> >>> It crashes reading the environment:
> >>>
> >>> U-Boot 2015.10-00544-gcad0499 (Nov 10 2015 - 17:06:00 -0700)
> >>>
> >>> CPU:   Intel(R) Core(TM) i5-3427U CPU @ 1.80GHz
> >>> DRAM:  2.7 GiB
> >>> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 8 
> >>> MiB
> >>> *** Warning - bad CRC, using default environment
> >>>
> >>> Video: 1280x1024x16
> >>> Model: Google Link
> >>> SF: Detected W25Q64CV with page size 256 Bytes, erase size 4 KiB, total 8 
> >>> MiB
> >>> Invalid Opcode (Undefined Opcode)
> >>
> >> I am wondering if this invalid opcode is caused by 6c2f758cee266f7648.
> >>
> >> Could you please try this?
> >>
> >
> > No, this does not resolve this issue.
> >
> >> --- a/arch/x86/include/asm/bitops.h
> >> +++ b/arch/x86/include/asm/bitops.h
> >> @@ -364,7 +364,7 @@ static __inline__ int ffs(int x)
> >> __asm__("bsfl %1,%0\n\t"
> >> "jnz 1f\n\t"
> >> "movl $-1,%0\n"
> >> -   "1:" : "=r" (r) : "rm" (x));
> >> +   "1:" : "=r" (r) : "g" (x));
> >>
> >> return r+1;
> >>  }
> >
> > It turns out it is a NULL pointer exception! Fixing this NULL pointer
> > makes the crash disappear, but 'saveenv' does not actually work on the
> > SST flash. Something is broken again, gosh!
> 
> Bin thank you for fixing this.
> 
> We still have a big problem with this patch though - it adds features
> to the pre-driver-model SPI flash implementation and not the driver
> model implementation! If I somehow have the wrong end of the stick
> please let me know.
> 
> If we accept this sort of patch we will never be done with driver
> model conversions, as we make it impossible for boards to move
> forward.
> 
> Fabio can you please rework this to remove the pre-driver-model
> support, and add your new functions to struct dm_spi_flash_ops
> instead, then convert the affected boards to driver model?

Hang on, didn't we have this discussion on one of the earlier threads
about this?  Part of the problem here is that everything else required
to do this on DM isn't quite there and Fabio has agreed to (under pain
of feature removal later) do the conversion when possible but to not
otherwise block getting this feature (and thus some platform(s))
integrated already.

-- 
Tom


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

Re: [U-Boot] [PATCH V2 07/12] board: LaCie: Move common headers to board-common directory

[Masahiro Yamada]

2015-11-15 14:38 GMT+09:00 Nishanth Menon :
> On 11/14/2015 05:56 PM, Masahiro Yamada wrote:
>> 2015-11-13 14:43 GMT+09:00 Nishanth Menon :
>>> Header files can be located in a generic location without
>>> needing to reference them with ../common/
>>>
>>> Generated with the following script
>>>
>>>  #!/bin/bash
>>> vendor=board/LaCie
>>> common=$vendor/common
>>>
>>> cfiles=`git grep "../common" $vendor|grep "#include"|cut -d '"' -f2|sort 
>>> -u|grep c$`
>>> headers=`git grep "../common" $vendor|grep "#include"|cut -d '"' -f2|sort 
>>> -u|grep h$`
>>>
>>> mkdir -p $common/include/board-common
>>> set -x
>>> for header in $headers
>>> do
>>> echo "processing $header in $common"
>>> hbase=`basename $header`
>>> git mv $common/$hbase $common/include/board-common
>>> sed -i -e "s/\"..\/common\/$hbase\"//g" 
>>> $vendor/*/*.[chS]
>>> sed -i -e "s/\"$hbase\"//g" 
>>> $vendor/common/*.[chS]
>>> done
>>>
>>> Cc: Simon Guinot 
>>> Cc: Albert ARIBAUD 
>>>
>>> Signed-off-by: Nishanth Menon 
>>> ---
>>
>>
>> As far as I understood from 02 to 12,
>> the effect of this series is:
>>
>> either
>>   replace "../common/foo.h" with 
> for board/specific board files.
>
>> or
>>   replace "bar.h" with 
> yes - for board/common headers which are exposed.
>
>>
>> Vendor common headers are referenced within their own directory.
>> #include "..." is better than #include <...> in such cases.
>
> Not after this series, which is what is the 3rd change done by this
> series: The headers are moved to a common location away from the
> board/common directory.
>
> This is more inline with what you did with mach.
>
>> I still do not understand what problem this series wants to solve.
>
> standardize board common header inclusion strategy across boards in a
> consistent manner similar to what mach/ changes have been doing.
>
> Overall, you did mention in https://patchwork.ozlabs.org/patch/541068/
>
>
> [step 1] move SoC-specific headers to  arch//mach-/include/mach
>
> [step 2] change  #include  to #include 
>
>
>
> Why did we not let folks user relative includes such as #include
> "../../mach/xyz.h" ? because it constraints us from changing the
> directory architecture in the future.
>
> This is exactly the same problem that board// folders have.
>
>
> Why is it that you dont see that as a problem?
>


You are misunderstanding.

SoC headers (either  in old style, or  in new
style) are exported.


For example,  arch/asm/include/asm/gpio.h includes .
Also, many files under drivers/ include 

I do not think any drivers should depend on SoC specific headers,
but it is the place where we stand now.


OTOH, vendor headers should be only referenced locally.
We should not expand the scope.   No need to standardize the include path.


Relative path is a correct way to include a header file with local scope.

Even Linux does so.

For example

drivers/pinctrl/sunxi/pinctrl-sunxi.c






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

Re: [U-Boot] [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect LS2080A

[Kushwaha Prabhakar]

Hi York,

This patch set in top of my previous patches. I did to make sure it can be 
applied cleanly. 

  armv8: lsch3: Fix lane protocol parsing logic
  driver: net: fsl-mc: Add create, destroy APIs in flibs
  driver: net: fsl-mc: Add APIs for DPMAC objects in FLIB
  armv8: ls2085aqds: Print function name during SerDes error
  driver: ldpaa: Add api to return linked PHY ID of DPMAC
  driver: net: fsl-mc: Increase MC command timeout
  driver: net: fsl-mc: Add DPAA2 commands to manage MC
  driver: net: fsl-mc: Create DPAA2 object at run-time
  driver: net: ldpaa: Use DPMAC as net device
  driver: net: ldpaa: Add debug information
 
 armv8: ls2085a: Add workaround of errata A009635 
 driver: net: ldpaa: Fix Rx buffer alignment


Regards,
Prabhakar

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Wednesday, November 11, 2015 12:40 AM
> To: Kushwaha Prabhakar-B32579 ; u-
> b...@lists.denx.de
> Cc: Srivastava Pratiyush-B46174 
> Subject: Re: [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect
> LS2080A
> 
> 
> 
> On 11/09/2015 03:12 AM, Prabhakar Kushwaha wrote:
> > LS2080A is a prime personality of Freescale’s LS2085A. It is a
> > non-AIOP personality without support of DP-DDR, L2 switch, 1588, PCIe
> endpoint etc.
> > So renaming existing LS2085A code base to reflect LS2080A (Prime
> > personality)
> >
> > Signed-off-by: Pratiyush Mohan Srivastava
> > 
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> > Changes for v2: Rebased on LS1043 patch set
> >
> >  README |  3 +
> >  arch/arm/Kconfig   | 44 +++
> >  arch/arm/cpu/armv8/fsl-layerscape/Makefile |  4 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/README.lsch3 |  4 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  2 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/fdt.c|  2 +-
> >  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 11 +++
> >  .../{ls2085a_serdes.c => ls2080a_serdes.c} |  0
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  2 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/spl.c|  4 +-
> >  arch/arm/dts/Makefile  |  4 +-
> >  .../{fsl-ls2085a-qds.dts => fsl-ls2080a-qds.dts}   |  8 +-
> >  .../{fsl-ls2085a-rdb.dts => fsl-ls2080a-rdb.dts}   |  8 +-
> >  .../arm/dts/{fsl-ls2085a.dtsi => fsl-ls2080a.dtsi} |  4 +-
> > arch/arm/include/asm/arch-fsl-layerscape/config.h  |  4 +-
> >  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |  6 +-
> >  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |  2 +-
> >  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  6 +-
> >  .../{ls2085a_stream_id.h => ls2080a_stream_id.h}   |  4 +-
> >  arch/arm/include/asm/global_data.h |  2 +-
> >  board/freescale/{ls2085a => ls2080a}/Kconfig   | 12 +--
> >  board/freescale/ls2080a/MAINTAINERS|  8 ++
> >  board/freescale/ls2080a/Makefile   |  8 ++
> >  board/freescale/{ls2085a => ls2080a}/README|  2 +-
> >  board/freescale/{ls2085a => ls2080a}/ddr.c |  3 +-
> >  board/freescale/{ls2085a => ls2080a}/ddr.h |  0
> >  .../{ls2085a/ls2085a.c => ls2080a/ls2080a.c}   |  2 +
> >  board/freescale/{ls2085ardb => ls2080aqds}/Kconfig |  6 +-
> >  board/freescale/ls2080aqds/MAINTAINERS |  8 ++
> >  .../freescale/{ls2085aqds => ls2080aqds}/Makefile  |  2 +-
> > board/freescale/{ls2085aqds => ls2080aqds}/README  | 16 ++--
> >  board/freescale/{ls2085ardb => ls2080aqds}/ddr.c   |  5 +-
> >  board/freescale/{ls2085aqds => ls2080aqds}/ddr.h   |  0
> >  board/freescale/{ls2085aqds => ls2080aqds}/eth.c   | 92 +++-
> --
> >  .../ls2085aqds.c => ls2080aqds/ls2080aqds.c}   |  4 +-
> >  .../ls2080aqds_qixis.h}|  0
> >  board/freescale/{ls2085aqds => ls2080ardb}/Kconfig |  6 +-
> >  board/freescale/ls2080ardb/MAINTAINERS |  8 ++
> >  .../freescale/{ls2085ardb => ls2080ardb}/Makefile  |  2 +-
> > board/freescale/{ls2085ardb => ls2080ardb}/README  | 12 +--
> >  board/freescale/{ls2085aqds => ls2080ardb}/ddr.c   |  5 +-
> >  board/freescale/{ls2085ardb => ls2080ardb}/ddr.h   |  0
> >  .../eth_ls2085rdb.c => ls2080ardb/eth_ls2080rdb.c} |  2 +-
> >  .../ls2085ardb.c => ls2080ardb/ls2080ardb.c}   |  4 +-
> >  .../ls2080ardb_qixis.h}|  0
> >  board/freescale/ls2085a/MAINTAINERS|  8 --
> >  board/freescale/ls2085a/Makefile   |  8 --
> >  board/freescale/ls2085aqds/MAINTAINERS |  8 --
> >  board/freescale/ls2085ardb/MAINTAINERS |  8 --
> >  ...ls2085a_emu_defconfig => ls2080a_emu_defconfig} |  2 +-
> > ...2085a_simu_defconfig => ls2080a_simu_defconfig} |  2 +-
> > .../{ls2085ardb_defconfig => ls2080aqds_defconfig} |  4 +-
> > 

Re: [U-Boot] [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect LS2080A

[York Sun]

I realized this set depends on another set. Thanks.

York


Sent on a Sprint Samsung Galaxy Note® II


 Original message 
From: Kushwaha Prabhakar-B32579
Date:11/15/2015 8:35 PM (GMT-08:00)
To: Sun York-R58495 , u-boot@lists.denx.de
Cc: Srivastava Pratiyush-B46174
Subject: RE: [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect LS2080A

Hi York,

This patch set in top of my previous patches. I did to make sure it can be 
applied cleanly.

  armv8: lsch3: Fix lane protocol parsing logic
  driver: net: fsl-mc: Add create, destroy APIs in flibs
  driver: net: fsl-mc: Add APIs for DPMAC objects in FLIB
  armv8: ls2085aqds: Print function name during SerDes error
  driver: ldpaa: Add api to return linked PHY ID of DPMAC
  driver: net: fsl-mc: Increase MC command timeout
  driver: net: fsl-mc: Add DPAA2 commands to manage MC
  driver: net: fsl-mc: Create DPAA2 object at run-time
  driver: net: ldpaa: Use DPMAC as net device
  driver: net: ldpaa: Add debug information

 armv8: ls2085a: Add workaround of errata A009635
 driver: net: ldpaa: Fix Rx buffer alignment


Regards,
Prabhakar

> -Original Message-
> From: York Sun [mailto:york...@freescale.com]
> Sent: Wednesday, November 11, 2015 12:40 AM
> To: Kushwaha Prabhakar-B32579 ; u-
> b...@lists.denx.de
> Cc: Srivastava Pratiyush-B46174 
> Subject: Re: [PATCH 1/2][v2] armv8: LS2080A: Rename LS2085A to reflect
> LS2080A
>
>
>
> On 11/09/2015 03:12 AM, Prabhakar Kushwaha wrote:
> > LS2080A is a prime personality of Freescale’s LS2085A. It is a
> > non-AIOP personality without support of DP-DDR, L2 switch, 1588, PCIe
> endpoint etc.
> > So renaming existing LS2085A code base to reflect LS2080A (Prime
> > personality)
> >
> > Signed-off-by: Pratiyush Mohan Srivastava
> > 
> > Signed-off-by: Prabhakar Kushwaha 
> > ---
> > Changes for v2: Rebased on LS1043 patch set
> >
> >  README |  3 +
> >  arch/arm/Kconfig   | 44 +++
> >  arch/arm/cpu/armv8/fsl-layerscape/Makefile |  4 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/README.lsch3 |  4 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  2 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/fdt.c|  2 +-
> >  .../arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 11 +++
> >  .../{ls2085a_serdes.c => ls2080a_serdes.c} |  0
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  2 +-
> >  arch/arm/cpu/armv8/fsl-layerscape/spl.c|  4 +-
> >  arch/arm/dts/Makefile  |  4 +-
> >  .../{fsl-ls2085a-qds.dts => fsl-ls2080a-qds.dts}   |  8 +-
> >  .../{fsl-ls2085a-rdb.dts => fsl-ls2080a-rdb.dts}   |  8 +-
> >  .../arm/dts/{fsl-ls2085a.dtsi => fsl-ls2080a.dtsi} |  4 +-
> > arch/arm/include/asm/arch-fsl-layerscape/config.h  |  4 +-
> >  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |  6 +-
> >  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |  2 +-
> >  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  6 +-
> >  .../{ls2085a_stream_id.h => ls2080a_stream_id.h}   |  4 +-
> >  arch/arm/include/asm/global_data.h |  2 +-
> >  board/freescale/{ls2085a => ls2080a}/Kconfig   | 12 +--
> >  board/freescale/ls2080a/MAINTAINERS|  8 ++
> >  board/freescale/ls2080a/Makefile   |  8 ++
> >  board/freescale/{ls2085a => ls2080a}/README|  2 +-
> >  board/freescale/{ls2085a => ls2080a}/ddr.c |  3 +-
> >  board/freescale/{ls2085a => ls2080a}/ddr.h |  0
> >  .../{ls2085a/ls2085a.c => ls2080a/ls2080a.c}   |  2 +
> >  board/freescale/{ls2085ardb => ls2080aqds}/Kconfig |  6 +-
> >  board/freescale/ls2080aqds/MAINTAINERS |  8 ++
> >  .../freescale/{ls2085aqds => ls2080aqds}/Makefile  |  2 +-
> > board/freescale/{ls2085aqds => ls2080aqds}/README  | 16 ++--
> >  board/freescale/{ls2085ardb => ls2080aqds}/ddr.c   |  5 +-
> >  board/freescale/{ls2085aqds => ls2080aqds}/ddr.h   |  0
> >  board/freescale/{ls2085aqds => ls2080aqds}/eth.c   | 92 +++-
> --
> >  .../ls2085aqds.c => ls2080aqds/ls2080aqds.c}   |  4 +-
> >  .../ls2080aqds_qixis.h}|  0
> >  board/freescale/{ls2085aqds => ls2080ardb}/Kconfig |  6 +-
> >  board/freescale/ls2080ardb/MAINTAINERS |  8 ++
> >  .../freescale/{ls2085ardb => ls2080ardb}/Makefile  |  2 +-
> > board/freescale/{ls2085ardb => ls2080ardb}/README  | 12 +--
> >  board/freescale/{ls2085aqds => ls2080ardb}/ddr.c   |  5 +-
> >  board/freescale/{ls2085ardb => ls2080ardb}/ddr.h   |  0
> >  .../eth_ls2085rdb.c => ls2080ardb/eth_ls2080rdb.c} |  2 +-
> >  .../ls2085ardb.c => ls2080ardb/ls2080ardb.c}   |  4 +-
> >  .../ls2080ardb_qixis.h}|  0
> >  board/freescale/ls2085a/MAINTAINERS|  8 --
> >  board/freescale/ls2085a/Makefile

[U-Boot] [PATCH] sf: Correct flash->flags for SST flash

[Bin Meng]

flash->flags for SST flash should be updated for both DM and non-DM
flash drivers.

Signed-off-by: Bin Meng 
---

 drivers/mtd/spi/sf_probe.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index bc05d30..fcfac44 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -164,14 +164,15 @@ static int spi_flash_validate_params(struct spi_slave 
*spi, u8 *idcode,
flash->memory_map = spi->memory_map;
flash->dual_flash = flash->spi->option;
 
+   /* Assign spi flash flags */
+   if (params->flags & SST_WR)
+   flash->flags |= SNOR_F_SST_WR;
+
/* 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 (params->flags & SNOR_F_SST_WR) {
+   if (flash->flags & SNOR_F_SST_WR) {
if (flash->spi->op_mode_tx & SPI_OPM_TX_BP)
flash->write = sst_write_bp;
else
-- 
1.8.2.1

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

[U-Boot] U-Boot, avr32: compiler warning with

[Heiko Schocher]

Hello Simon,

I see an compile error for avr32 on travis.org for current mainline
U-Boot, see [1].

git bisecting it, with the information that last working avr32 build
on travis.org is [2], shows:

pollux:u-boot hs [(kein Branch, binäre Suche begonnen bei 20151116)] $ git 
bisect log
git bisect start
# good: [a5325cd5e91f77a2214e80198ae31c1d8b7e7c3c] configs: Remove 
CONFIG_SERIAL_MULTI
git bisect good a5325cd5e91f77a2214e80198ae31c1d8b7e7c3c
# bad: [ae27120c31d58b8bb694d9155bcffdcfae8552a6] Merge 
git://git.denx.de/u-boot-dm
git bisect bad ae27120c31d58b8bb694d9155bcffdcfae8552a6
# bad: [bae34335e8aef46d7103907580c40f18f1876bb0] exynos: Remove unneeded 
device tree control #ifdefs
git bisect bad bae34335e8aef46d7103907580c40f18f1876bb0
# bad: [f615e6a64d23952d3c68b9ac92b4ef5fa5ebdf8a] dm: power: Add support for 
S5M8767 regulators
git bisect bad f615e6a64d23952d3c68b9ac92b4ef5fa5ebdf8a
# bad: [f1ac35b7a6c6bc878d473b5955370b1cc49dba54] exynos: dts: Sync up I2C 
ports with the kernel
git bisect bad f1ac35b7a6c6bc878d473b5955370b1cc49dba54
# good: [7fc65bcf8a0a5463db86efbb273a40448c845efc] dm: i2c: Move definitions to the top of the 
header file

git bisect good 7fc65bcf8a0a5463db86efbb273a40448c845efc
# bad: [b725dc458f9db44957d4f541d05defe178dda7b5] i2c: Add a mux for GPIO-based 
I2C bus arbitration
git bisect bad b725dc458f9db44957d4f541d05defe178dda7b5
# bad: [3d1957f0ea0133ec06f9c6fd85dc1acdf66ad29c] dm: i2c: Add support for 
multiplexed I2C buses
git bisect bad 3d1957f0ea0133ec06f9c6fd85dc1acdf66ad29c
# good: [df358c6beca8f7cc2f2b67c54f0bf255ebd5cc22] dm: i2c: Add a function to 
transfer messages
git bisect good df358c6beca8f7cc2f2b67c54f0bf255ebd5cc22
# first bad commit: [3d1957f0ea0133ec06f9c6fd85dc1acdf66ad29c] dm: i2c: Add support for multiplexed 
I2C buses

pollux:u-boot hs [(kein Branch, binäre Suche begonnen bei 20151116)] $

Hmm... it seems, that introducing the subdir "muxes" leads into
this error for avr32 ... I just tried the following patch:

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 32198bd..811ad9b 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -40,4 +40,4 @@ obj-$(CONFIG_SYS_I2C_UNIPHIER) += i2c-uniphier.o
 obj-$(CONFIG_SYS_I2C_UNIPHIER_F) += i2c-uniphier-f.o
 obj-$(CONFIG_SYS_I2C_ZYNQ) += zynq_i2c.o

-obj-y += muxes/
+obj-$(CONFIG_I2C_MUX) += muxes/
pollux:u-boot hs [20151116] $

and the error "drivers/i2c/built-in.o: warning: input is not relaxable"
is gone ...

Do you have an idea, why this breaks? Is above patch a valid fix?
(I checked, that all boards using CONFIG_I2C_ARB_GPIO_CHALLENGE have
 also set CONFIG_I2C_MUX)

bye,
Heiko
[1] current U-Boot compile error for avr32 on travis.org:
https://travis-ci.org/u-boot/u-boot/jobs/90954387

[2] last working U-Boot compile on travis.org for avr32:
https://travis-ci.org/u-boot/u-boot/builds/74310800
--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/11] dm: timer: Support 64-bit counter

[Bin Meng]

Hi Simon,

On Sat, Nov 14, 2015 at 10:04 AM, Simon Glass  wrote:
> Hi Bin,
>
> On 13 November 2015 at 01:11, Bin Meng  wrote:
>> There are timers with a 64-bit counter value but current timer
>> uclass driver assumes a 32-bit one. Modify timer_get_count()
>> to ask timer driver to always return a 64-bit counter value,
>> and provide an inline helper function timer_conv_64() to handle
>> the 32-bit/64-bit conversion automatically.
>>
>> Signed-off-by: Bin Meng 
>>
>> ---
>>
>> Changes in v3:
>> - Update commit message to reflect the v2 changes (ie: there is
>>   no "counter-64bit" property)
>>
>> Changes in v2:
>> - Do not use "counter-64bit" property, instead create an inline
>>   function for 32-bit timer driver to construct a 64-bit timer value.
>>
>>  drivers/timer/altera_timer.c  |  4 ++--
>>  drivers/timer/sandbox_timer.c |  2 +-
>>  drivers/timer/timer-uclass.c  |  8 +++-
>>  include/timer.h   | 23 ---
>>  lib/time.c|  9 ++---
>>  5 files changed, 32 insertions(+), 14 deletions(-)
>
> Is there a binding file for this timer somewhere? If both altera and
> sandbox share this property, should we add a generic binding? It
> doesn't look like Linux has one though.
>

Missed this comment in my previous post.

I cannot find one too. But this is quite natural as without a
frequency the timer does not count :) I believe 'clock-frequency'
might be dynamically calculated on some platforms like ARM SoCs, which
is similar to the ns16550 serial clock source frequency (we've had
such discussion before).

[snip]

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

Re: [U-Boot] [PATCH v5 1/2] usb: zynqmp: Add XHCI driver support

[Marek Vasut]

On Monday, November 16, 2015 at 06:59:13 AM, Siva Durga Prasad Paladugu wrote:
> From: Siva Durga Prasad Paladugu 
> 
> Added USB XHCI driver support for zynqmp.
> 
> Signed-off-by: Siva Durga Prasad Paladugu 

Hi!

[...]

> +static struct zynqmp_xhci zynqmp_xhci;
> +
> +unsigned long ctr_addr[] = CONFIG_ZYNQMP_XHCI_LIST;

Still no DM/DT support on Xilinx parts, huh ? :)

[...]

> +int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor
> **hcor) +{
> + struct zynqmp_xhci *ctx = _xhci;
> + int ret = 0;
> +
> + if (index < 0 || index >= ARRAY_SIZE(ctr_addr))
> + return -EINVAL;
> +
> + ctx->hcd = (struct xhci_hccr *)ctr_addr[index];
> + ctx->dwc3_reg = (struct dwc3 *)((char *)(ctx->hcd) + DWC3_REG_OFFSET);

Should be void *, not char * I think. Also, the parenthesis around ctx->hcd
are not needed.

> + ret = board_usb_init(index, USB_INIT_HOST);
> + if (ret != 0) {
> + puts("Failed to initialize board for USB\n");
> + return ret;
> + }
> +
> + ret = zynqmp_xhci_core_init(ctx);
> + if (ret < 0) {
> + puts("Failed to initialize xhci\n");
> + return ret;
> + }
> +
> + *hccr = (struct xhci_hccr *)ctx->hcd;
> + *hcor = (struct xhci_hcor *)((uint32_t) *hccr
> + + HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase)));

You want to use uintptr_t for the same of 64bit parts.

> + debug("zynqmp-xhci: init hccr %x and hcor %x hc_length %d\n",
> +   (uint32_t)*hccr, (uint32_t)*hcor,
> +   (uint32_t)HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase)));

We have %p for printing pointers, so drop the casts.

Also, since you're using HC_LENGTH() here twice, you might as well put it's
value into temporary variable and use it in both places, it might make the
code slightly more readable.

> + return ret;
> +}
> +
> +void xhci_hcd_stop(int index)
> +{
> + /*
> +  * Currently zynqmp socs do not support PHY shutdown from
> +  * sw. But this support may be added in future socs.
> +  */
> +
> + return 0;
> +}
> diff --git a/include/configs/xilinx_zynqmp_ep.h
> b/include/configs/xilinx_zynqmp_ep.h index ed6023a..1845622 100644
> --- a/include/configs/xilinx_zynqmp_ep.h
> +++ b/include/configs/xilinx_zynqmp_ep.h
> @@ -23,6 +23,8 @@
>  #define CONFIG_SYS_I2C_ZYNQ
>  #define CONFIG_ZYNQ_EEPROM
>  #define CONFIG_AHCI
> +#define CONFIG_ZYNQMP_XHCI_LIST {ZYNQMP_USB0_XHCI_BASEADDR, \
> +  ZYNQMP_USB1_XHCI_BASEADDR}
> 
>  #include 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Fwd: PSCI for H3

[Chen-Yu Tsai]

Hi everyone,

(Resent with my correct email address...)

I got my Orange Pi PC booting U-boot now, using Hans' sunxi-wip branch that
includes Jens' patches.

For PSCI and SMP, it seems the H3 follows the structure of previous sun8i SoCs.
The CPUCFG registers line up. The manual doesn't have the PRCM, so I'll have to
dig through the SDK.

One other thing is the SMTA, or Secure Memory Touch Arbiter, which we last
encountered issues with on the A31s. This controls non-secure access to a whole
bunch of peripherals, which we'll need to enable for Linux to run non-secure.

Anyway, this is just a preliminary evaluation of the work needed for PSCI.
Nothing has actually been done or tested.


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

Re: [U-Boot] [PATCH V2 0/5] Add support for additional splash screen locations

[Nikita Kiryanov]

Adding Stefano to CC.
On Sun, Nov 15, 2015 at 10:14:37AM +0200, Nikita Kiryanov wrote:
> Ping^2!
> 
> On Sun, Nov 08, 2015 at 10:27:16AM +0200, Nikita Kiryanov wrote:
> > Ping!
> > 
> > On Thu, Oct 29, 2015 at 11:54:39AM +0200, Nikita Kiryanov wrote:
> > > This series adds the following functionality to the splash_source library:
> > > - load splash image from filesystem formatted usb storage
> > > - load splash image from filesystem formatted mmc storage
> > > - load splash image from filesystem formatted sata storage
> > > 
> > > Finally, use the new features on cm-fx6.
> > > 
> > > Changes in V2:
> > >   - Rebased over current mainline.
> > >   - Added "splashfile" env variable to select splash file name 
> > > dynamically.
> > > Also available: default value "splash.bmp"
> > >   - Added documentation for the feature.
> > >   - Refactored device initialization code so that #ifdefs are outside of
> > > the functions. This affects patches 3 and 4.
> > > 
> > > Cc: Igor Grinberg 
> > > Cc: Tom Rini 
> > > 
> > > Nikita Kiryanov (5):
> > >   splash_source: rename *_read() to *_read_raw()
> > >   splash_source: add support for filesystem formatted mmc
> > >   splash_source: add support for filesystem formatted usb
> > >   splash_source: add support for filesystem formatted sata
> > >   arm: mx6: cm-fx6: add splash locations to cm-fx6
> > > 
> > >  board/compulab/cm_fx6/cm_fx6.c |  19 +++
> > >  board/compulab/cm_t35/cm_t35.c |   1 +
> > >  common/splash_source.c | 125 
> > > +
> > >  doc/README.splashprepare   |   5 ++
> > >  include/splash.h   |  10 
> > >  5 files changed, 150 insertions(+), 10 deletions(-)
> > > 
> > > -- 
> > > 1.9.1
> > > 
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> > 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix sandbox build on Ubuntu 10.04

[Stephen Warren]

On 11/15/2015 07:07 PM, Tom Rini wrote:
> On Sat, Nov 14, 2015 at 11:53:49PM -0700, Stephen Warren wrote:
> 
>> gcc 4.4.3 (which is the default native compiler on x86-64 Ubuntu
>> 10.04) doesn't seem to like initializers for sub-fields of
>> anonymous unions. Solve this by replacing the initialization with
>> an assignment. This fixes:
>> 
>> lib/lz4_wrapper.c: In function ‘ulz4fn’: lib/lz4_wrapper.c:97:
>> error: unknown field ‘raw’ specified in initializer
>> 
>> Signed-off-by: Stephen Warren 
> 
> So Ubuntu 10.04 hit end of life this past April.  I can be
> convinced but as I'm personally staring down upgrading my 12.04
> machine I need some reason.

For some reason I though the support life was 5 years desktop and
longer for server, but it looks like 5 years was the server period. Oh
well.

I suspect this patch may still be useful though; RHEL5 is still
supported until March 31, 2017[1], and apparently has an even older
compiler (gcc 4.1.x)[2]

[1] https://access.redhat.com/support/policy/updates/errata
[2] https://access.redhat.com/solutions/19458
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 11/12] board: varisys: Move common headers to board-common directory

[Andy Fleming]

On Thu, Nov 12, 2015 at 11:43 PM, Nishanth Menon  wrote:
> Header files can be located in a generic location without
> needing to reference them with ../common/

> diff --git a/board/varisys/cyrus/cyrus.c b/board/varisys/cyrus/cyrus.c
> index 79c363cf841a..6ce7814cb3b9 100644
> --- a/board/varisys/cyrus/cyrus.c
> +++ b/board/varisys/cyrus/cyrus.c
> @@ -20,7 +20,7 @@
>  #include 
>
>  #include "cyrus.h"
> -#include "../common/eeprom.h"
> +#include 


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

[U-Boot] [PATCH v4] Fix board init code to use a valid C runtime environment

[Albert ARIBAUD]

board_init_f_mem() alters the C runtime environment's
stack it ls actually already using. This is not a valid
C runtime environment.

Split board_init_f_mem into C functions which do not
alter their own stack and therefore run in a valid C
runtime environment.

Signed-off-by: Albert ARIBAUD 
---
Cc:ing custodians for all architectures which this
patch affects.

This patch has been build-tested for all there
architectures, and run-tested on ARM OpenRD Client.

For NIOS2, this patch contains all manual v1 and v2
fixes by Thomas.

For x86, this patch contains all manual v2 fixes by Bin.

Changes in v4:
- Add comments on reserving GD at the lowest location
- Add comments on post-incrementing base for each "chunk"

Changes in v3:
- Rebase after commit 9ac4fc82
- Simplify malloc conditional as per commit 9ac4fc82
- Fix NIOS2 return value register (r2, not r4)
- Fix x86 subl argument inversion
- Group allocations in a single function
- Group initializations in a single function

Changes in v2:
- Fix all checkpatch issues
- Fix board_init_f_malloc prototype mismatch
- Fix board_init_[f_]xxx typo in NIOS2
- Fix aarch64 asm 'sub' syntax error

 arch/arc/lib/start.S|  12 +++--
 arch/arm/lib/crt0.S |   6 ++-
 arch/arm/lib/crt0_64.S  |   6 ++-
 arch/microblaze/cpu/start.S |   4 +-
 arch/nios2/cpu/start.S  |  13 +++--
 arch/powerpc/cpu/ppc4xx/start.S |  10 ++--
 arch/x86/cpu/start.S|   5 +-
 arch/x86/lib/fsp/fsp_common.c   |   4 +-
 common/init/board_init.c| 108 +++-
 include/common.h|  33 +---
 10 files changed, 144 insertions(+), 57 deletions(-)

diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S
index 26a5934..2a99193 100644
--- a/arch/arc/lib/start.S
+++ b/arch/arc/lib/start.S
@@ -54,14 +54,16 @@ ENTRY(_start)
mov %sp, CONFIG_SYS_INIT_SP_ADDR
mov %fp, %sp
 
-   /* Allocate and zero GD, update SP */
-   mov %r0, %sp
-   bl  board_init_f_mem
-
+   /* Get reserved area size, update SP and FP */
+   bl  board_init_f_get_reserve_size
/* Update stack- and frame-pointers */
-   mov %sp, %r0
+   sub %sp, %sp, %r0
mov %fp, %sp
 
+   /* Initialize reserved area */
+   mov %r0, %sp
+   bl  board_init_f_init_reserve
+
/* Zero the one and only argument of "board_init_f" */
mov_s   %r0, 0
j   board_init_f
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 80548eb..4ec89a4 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -82,9 +82,11 @@ ENTRY(_main)
 #else
bic sp, sp, #7  /* 8-byte alignment for ABI compliance */
 #endif
+   bl  board_init_f_get_reserve_size
+   sub sp, sp, r0
+   mov r9, sp
mov r0, sp
-   bl  board_init_f_mem
-   mov sp, r0
+   bl  board_init_f_init_reserve
 
mov r0, #0
bl  board_init_f
diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index cef1c71..2891071 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -75,8 +75,10 @@ ENTRY(_main)
ldr x0, =(CONFIG_SYS_INIT_SP_ADDR)
 #endif
bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
-   bl  board_init_f_mem
-   mov sp, x0
+   bl  board_init_f_get_reserve_size
+   sub sp, sp, x0
+   mov x0, sp
+   bl  board_init_f_init_reserve
 
mov x0, #0
bl  board_init_f
diff --git a/arch/microblaze/cpu/start.S b/arch/microblaze/cpu/start.S
index 14f46a8..206be3e 100644
--- a/arch/microblaze/cpu/start.S
+++ b/arch/microblaze/cpu/start.S
@@ -25,7 +25,7 @@ _start:
 
addir8, r0, __end
mts rslr, r8
-   /* TODO: Redo this code to call board_init_f_mem() */
+   /* TODO: Redo this code to call board_init_f_*() */
 #if defined(CONFIG_SPL_BUILD)
addir1, r0, CONFIG_SPL_STACK_ADDR
mts rshr, r1
@@ -142,7 +142,7 @@ _start:
ori r12, r12, 0x1a0
mts rmsr, r12
 
-   /* TODO: Redo this code to call board_init_f_mem() */
+   /* TODO: Redo this code to call board_init_f_*() */
 clear_bss:
/* clear BSS segments */
addir5, r0, __bss_start
diff --git a/arch/nios2/cpu/start.S b/arch/nios2/cpu/start.S
index 54787c5..45bf0fd 100644
--- a/arch/nios2/cpu/start.S
+++ b/arch/nios2/cpu/start.S
@@ -106,14 +106,17 @@ _reloc:
stw r0, 4(sp)
mov fp, sp
 
-   /* Allocate and zero GD, update SP */
+   /* Allocate and initialize reserved area, update SP */
+   movhi   r2, %hi(board_init_f_get_reserve_size@h)
+   ori r2, r2, %lo(board_init_f_get_reserve_size@h)
+   callr   r2
+   sub sp, sp, r2
mov r4, sp
-   movhi   r2, %hi(board_init_f_mem@h)
-   ori r2, r2, %lo(board_init_f_mem@h)
+   

Re: [U-Boot] [PATCH v4] Fix board init code to use a valid C runtime environment

[Albert ARIBAUD]

Hello Albert,

On Sun, 15 Nov 2015 19:25:25 +0100, Albert ARIBAUD
 wrote:
> board_init_f_mem() alters the C runtime environment's
> stack it ls actually already using. This is not a valid
> C runtime environment.
> 
> Split board_init_f_mem into C functions which do not
> alter their own stack and therefore run in a valid C
> runtime environment.

Of course, I only see the typos above now: that paragraph
should read:

board_init_f_mem() alters the C runtime environment's
stack it is actually already using. This is not a valid
behaviour within a C runtime environment.

Split board_init_f_mem into C functions which do not alter
their own stack and always behave properly with respect to
their C runtime environment.

If no comment calls for a v5, then whoever applies this v4 please fix
the commit message accordingly.

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