Re: [U-Boot] Bare x86 support is merged to u-boot-x86

2014-11-26 Thread Joakim Tjernlund
> 
> Hi Andy,
> 
> On 25 November 2014 at 15:08, Andy Pont  
wrote:
> > Hi Simon (and Bin),
> >
> >> I've applied the remaining x86 patches to u-boot-x86. It runs on
> >> chromebook_link (Pixel) with support for most hardware relevant to a
> >> boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal
> >> 32GB SSD), SD card, LCD, UART, keyboard, EC.
> >>
> >> Bin this should be a good base for you to send patches for your Atom
> >> platform and I have no major work pending now so should not get in
> >> your way.
> >
> > Thanks for all of your efforts on getting some x86 support into 
U-Boot.
> > Hopefully in the new year when project work is back under control I 
will
> > have some time to get involved with this - I have almost 20 years 
experience
> > porting commercial BIOS and UEFI solutions for x86 hardware and 
possibly a
> > bunch of Atom C2750 hardware arriving in January.
> 
> Sounds great! I do wonder whether U-Boot could support some UEFI 
protocols.
> 
> >
> > Other than the list of missing features, what are your long term
> > goals/ambitions/desires with x86 support in U-Boot?  From what I can 
see on
> > the Coreboot mailing list it isn't the friendliest of people and 
doesn't
> > seem to know how to deal with the binary blobs that both Intel and AMD 
seem
> > to mandate for their chipsets now.
> 
> It would be nice to make x86 a first-class U-Boot citizen, meaning
> that it has a reasonable set of features as required by a reasonable
> set of modern boards. That means supporting a few more classes of
> chipsets. Then we get all the features that U-Boot has, hopefully
> without to much of the BIOS-era baggage that x86 often brings along
> (U-Boot is pretty simple to understand). I'm pretty happy that the
> current port fits well into the U-Boot philosophy.

I would love to see Intel embedded Guthrie CRB design(No graphics and 4 
GBE eth ports):
  Processor: i7-4702EC 
  PCH: Cave Creek (DH8900CC) 

This will be our next board in not too distant future, we do not
have any x86 experience inhouse though :)

Any chance this could be done?

 Jocke

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


[U-Boot] Pull request: nand flash

2014-11-26 Thread Scott Wood
The following changes since commit 85bafb6da4dddfffa78479aa49a72ae48578a4ce:

  Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq (2014-11-26 
11:23:26 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-nand-flash.git 

for you to fetch changes up to b19157bf3f2345586f2db8a0f8f92cc54f527952:

  mtd: nand: s3c: Unify the register definition and naming (2014-11-26 23:21:43 
-0600)


Marek Vasut (1):
  mtd: nand: s3c: Unify the register definition and naming

Masahiro Yamada (2):
  mtd: denali: use CONFIG_SYS_NAND_SELF_INIT
  mtd: denali: set some registers after nand_scan_ident()

Rostislav Lisovy (1):
  nand: reinstate lazy bad block scanning

Sanchayan Maity (1):
  mtd/nand/vf610_nfc: Disable subpage writes

 arch/arm/include/asm/arch-s3c24x0/s3c2410.h |   4 +-
 arch/arm/include/asm/arch-s3c24x0/s3c2440.h |   4 +-
 arch/arm/include/asm/arch-s3c24x0/s3c24x0.h |  31 ---
 drivers/mtd/nand/Kconfig|   7 ++
 drivers/mtd/nand/denali.c   | 132 
 drivers/mtd/nand/denali.h   |   5 +-
 drivers/mtd/nand/nand_base.c|  10 ++-
 drivers/mtd/nand/s3c2410_nand.c |  38 
 drivers/mtd/nand/vf610_nfc.c|   3 +
 9 files changed, 152 insertions(+), 82 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] sata: fix reset_sata for dwc_ahsata

2014-11-26 Thread Soeren Moch
Hi Fabio,

On 27.11.2014 02:12, Fabio Estevam wrote:
> Hi Soeren,
> 
> On Wed, Nov 26, 2014 at 9:32 PM, Soeren Moch  wrote:
> 
>> off the sata controller clock. I'm even not sure that my patch would
>> work for i.MX6SX, if I further think about it. It is already not easy to
> 
> No need to worry about it: there is no sata on solox ;-)
> 

Of course, but does the code compile for it?
OK, probably yes, because nobody would define CMD_SATA for such board.

Even better if you think the patch will work for all mx6 variants. Maybe
I should send a second version of the patch with fixed typecast.

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


Re: [U-Boot] Export redesign

2014-11-26 Thread Martin Dorwig
Hello, 

for CONFIG_AVR32 the macro looks like this:
#define EXPORT_FUNC(x)  \
asm volatile(   \
"   .globl\t" #x "\n"   \
#x ":\n"\
"   ld.wr8, r6[%0]\n"   \
"   ld.wpc, r8[%1]\n"   \
:   \
: "i"(offsetof(gd_t, jt)), "i"(XF_ ##x) \
: "r8");
if there is an implicit shift in the ld.w instructuions, then the 
ld.w r8,r6[%0] is wrong, because offsetof(gd_t, jt) is the offset in bytes.
if there is no shift, then the 
ld.w pc,r8[%1] is wrong, because the XF_ ## is not multiplied by sizeof(void*)

the syntax from the avr32 manual shows

Operation:
III. Rd ← *(Rp + (ZE(disp5) << 2));
IV. Rd ← *(Rp + (SE(disp16)));

Syntax:
III.  ld.w Rd, Rp[disp]
IV.  ld.w Rd, Rp[disp]

my interpretation is :
the assembler checks if (disp % 4 == 0) && disp <= 124 then
is uses variant III and places disp >> 2 as disp5 into the instruction.
else it uses variant IV and places disp as disp16 into the 
extension word of the instruction.


Regards
Martin

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


Re: [U-Boot] Bare x86 support is merged to u-boot-x86

2014-11-26 Thread Simon Glass
Hi Bin,

On 26 November 2014 at 18:44, Bin Meng  wrote:
> Hi Simon,
>
> On Wed, Nov 26, 2014 at 5:51 AM, Simon Glass  wrote:
>> Hi Bin (and others interested in U-Boot on x86),
>>
>> I've applied the remaining x86 patches to u-boot-x86. It runs on
>> chromebook_link (Pixel) with support for most hardware relevant to a
>> boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal
>> 32GB SSD), SD card, LCD, UART, keyboard, EC.
>>
>> Bin this should be a good base for you to send patches for your Atom
>> platform and I have no major work pending now so should not get in
>> your way.
>>
>
> This is great! Thanks for applying your patch series into the mainline
> so quickly. I will start working on my patches soon.
>
>> Instructions on how to build and run are here:
>>
>> http://www.denx.de/wiki/U-Boot/X86
>>
>> For this platform 4 binary blobs are needed. This is an unavoidable
>> feature of the platform at present. The blobs cover flash descriptor,
>> SDRAM init, video init and Management Engine. Instructions on how to
>> get these are on the same page.
>>
>> Here is a list of some missing features:
>>
>> - README.x86 in the source (mostly the content from the Wiki page
>> would be a good start)
>> - MTRR support (for performance)
>> - Audio
>> - Chrome OS verified boot (only a rough rebase has been done, I'm not
>> sure how to track mainline anyway)
>> - SMI and ACPI support, to provide platform info and facilities to Linux
>>
>
> One question related to ACPI, do we need support pre-ACPI protocols
> for handling over resource allocations and interrupt vector assignment
> information to the OS? I mean the PIRQ table and MP table. These specs
> are really old nowadays, and even commercial BIOS does not always get
> those tables correct, but as far as I can see, ACPI tables are more
> reliable. I think this is largely because they validate ACPI support
> with Windows and Linux which always use ACPI.

I vote no. ACPI should be enough.

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


Re: [U-Boot] [U-Boot,05/10] mtd: nand: s3c: Add S3C2440 specifics

2014-11-26 Thread Scott Wood
On Sat, Oct 11, 2014 at 06:42:53PM +0200, Marek Vasut wrote:
> +#ifdef CONFIG_S3C2410
>  #define S3C2410_NFCONF_TACLS(x)((x)<<8)
>  #define S3C2410_NFCONF_TWRPH0(x)   ((x)<<4)
>  #define S3C2410_NFCONF_TWRPH1(x)   ((x)<<0)
> +#else/* S3C2412, S3C2440 */
> +#define S3C2410_NFCONF_TACLS(x)((x)<<12)
> +#define S3C2410_NFCONF_TWRPH0(x)   ((x)<<8)
> +#define S3C2410_NFCONF_TWRPH1(x)   ((x)<<4)
> +#endif

Is there any chance there will be a third variant?  Perhaps the S3C2440
variant should be explicitly requested with an #error if no variant is
selected.

>  #define S3C2410_ADDR_NALE 4
>  #define S3C2410_ADDR_NCLE 8
> @@ -42,25 +51,30 @@ static void s3c24x0_hwcontrol(struct mtd_info *mtd, int 
> cmd, unsigned int ctrl)
>  {
>   struct nand_chip *chip = mtd->priv;
>   struct s3c24x0_nand *nand = s3c24x0_get_base_nand();
> + uint32_t sel_reg, sel_bit;
>  
>   debug("hwcontrol(): 0x%02x 0x%08x\n", cmd & 0xff, ctrl);
>  
>   if (ctrl & NAND_CTRL_CHANGE) {
> - ulong IO_ADDR_W = (ulong)nand;
> + chip->IO_ADDR_W = &nand->nfconf;
>  
>   if (!(ctrl & NAND_CLE))
> - IO_ADDR_W |= S3C2410_ADDR_NCLE;
> + chip->IO_ADDR_W = &nand->nfaddr;
>   if (!(ctrl & NAND_ALE))
> - IO_ADDR_W |= S3C2410_ADDR_NALE;
> + chip->IO_ADDR_W = &nand->nfcmd;
>  
> - chip->IO_ADDR_W = (void *)IO_ADDR_W;
> +#ifdef CONFIG_S3C2410
> + sel_reg = (uint32_t)&nand->nfconf;
> + sel_bit = S3C2410_NFCONF_nFCE;
> +#else
> + sel_reg = (uint32_t)&nand->nfcont;
> + sel_bit = S3C2440_NFCONT_nFCE;
> +#endif

Why are you casting &nand->nfcon[ft] to an integer...

>   if (ctrl & NAND_NCE)
> - writel(readl(&nand->nfconf) & ~S3C2410_NFCONF_nFCE,
> -&nand->nfconf);
> + clrbits_le32(sel_reg, sel_bit);
>   else
> - writel(readl(&nand->nfconf) | S3C2410_NFCONF_nFCE,
> -&nand->nfconf);
> + setbits_le32(sel_reg, sel_bit);

...only to pass that integer to something that normally accepts a
pointer, which doesn't cause a warning only because of ARM's crappy I/O
accessors that don't do type checking?

At least the code that was there before used ulong for inappropriate
pointer-to-integer casts rather than uint32_t. :-P

> - writel(readl(&clk_power->clkcon) | (1 << 4), &clk_power->clkcon);
> + setbits_le32(&clk_power->clkcon, 1 << 4);

This change seems unrelated to adding s3c2440 support.  It'd be clearer
if the {clr,set,clrset}bits_le32() conversion were done separately,
before the s3c2440 stuff.  I'm not insisting that you redo this one, but
next time try to keep cleanup separate.

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


Re: [U-Boot] [U-Boot, 03/10] mtd: nand: s3c: Fix data type width in debug()

2014-11-26 Thread Scott Wood
On Sat, Oct 11, 2014 at 06:42:51PM +0200, Marek Vasut wrote:
> Printing u32 with %02x is just a bad idea, fix it.
> 
> Signed-off-by: Marek Vasut 
> Cc: Kyungmin Park 
> Cc: Lukasz Majewski 
> Cc: Minkyu Kang 
> Cc: Scott Wood 
> Cc: Vladimir Zapolskiy 
> ---
>  drivers/mtd/nand/s3c2410_nand.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/s3c2410_nand.c b/drivers/mtd/nand/s3c2410_nand.c
> index db87d07..399f2bc 100644
> --- a/drivers/mtd/nand/s3c2410_nand.c
> +++ b/drivers/mtd/nand/s3c2410_nand.c
> @@ -43,7 +43,7 @@ static void s3c2410_hwcontrol(struct mtd_info *mtd, int 
> cmd, unsigned int ctrl)
>   struct nand_chip *chip = mtd->priv;
>   struct s3c2410_nand *nand = s3c2410_get_base_nand();
>  
> - debug("hwcontrol(): 0x%02x 0x%02x\n", cmd, ctrl);
> + debug("hwcontrol(): 0x%02x 0x%08x\n", cmd & 0xff, ctrl);

What is the purpose of forcing extra zeroes in ctrl all the time?  Why is
the lack of such ugliness "just a bad idea"?

Also, the masking of cmd is an unexplained change.

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


Re: [U-Boot] [U-Boot, 02/10] arm: s3c24xx: Fix incorrect CONFIG_SYS_S3C2410_NAND_HWECC name

2014-11-26 Thread Scott Wood
On Sat, Oct 11, 2014 at 06:42:50PM +0200, Marek Vasut wrote:
> The correct name of this symbol is CONFIG_S3C2410_NAND_HWECC , the
> _SYS is redundant.

What makes that the correct name?  The symbol is not documented anywhere,
and while nothing currently tests for the SYS version, nothing currently
sets the non-SYS version.

What is SYS redundant with?

Is this meant to be a user config knob or something that is fixed for a
given board?

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


Re: [U-Boot] Bare x86 support is merged to u-boot-x86

2014-11-26 Thread Bin Meng
Hi Simon,

On Wed, Nov 26, 2014 at 5:51 AM, Simon Glass  wrote:
> Hi Bin (and others interested in U-Boot on x86),
>
> I've applied the remaining x86 patches to u-boot-x86. It runs on
> chromebook_link (Pixel) with support for most hardware relevant to a
> boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal
> 32GB SSD), SD card, LCD, UART, keyboard, EC.
>
> Bin this should be a good base for you to send patches for your Atom
> platform and I have no major work pending now so should not get in
> your way.
>

This is great! Thanks for applying your patch series into the mainline
so quickly. I will start working on my patches soon.

> Instructions on how to build and run are here:
>
> http://www.denx.de/wiki/U-Boot/X86
>
> For this platform 4 binary blobs are needed. This is an unavoidable
> feature of the platform at present. The blobs cover flash descriptor,
> SDRAM init, video init and Management Engine. Instructions on how to
> get these are on the same page.
>
> Here is a list of some missing features:
>
> - README.x86 in the source (mostly the content from the Wiki page
> would be a good start)
> - MTRR support (for performance)
> - Audio
> - Chrome OS verified boot (only a rough rebase has been done, I'm not
> sure how to track mainline anyway)
> - SMI and ACPI support, to provide platform info and facilities to Linux
>

One question related to ACPI, do we need support pre-ACPI protocols
for handling over resource allocations and interrupt vector assignment
information to the OS? I mean the PIRQ table and MP table. These specs
are really old nowadays, and even commercial BIOS does not always get
those tables correct, but as far as I can see, ACPI tables are more
reliable. I think this is largely because they validate ACPI support
with Windows and Linux which always use ACPI.

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


Re: [U-Boot] [PATCH] sata: fix reset_sata for dwc_ahsata

2014-11-26 Thread Fabio Estevam
Hi Soeren,

On Wed, Nov 26, 2014 at 9:32 PM, Soeren Moch  wrote:

> off the sata controller clock. I'm even not sure that my patch would
> work for i.MX6SX, if I further think about it. It is already not easy to

No need to worry about it: there is no sata on solox ;-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Bare x86 support is merged to u-boot-x86

2014-11-26 Thread Simon Glass
Hi Andy,

On 25 November 2014 at 15:08, Andy Pont  wrote:
> Hi Simon (and Bin),
>
>> I've applied the remaining x86 patches to u-boot-x86. It runs on
>> chromebook_link (Pixel) with support for most hardware relevant to a
>> boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal
>> 32GB SSD), SD card, LCD, UART, keyboard, EC.
>>
>> Bin this should be a good base for you to send patches for your Atom
>> platform and I have no major work pending now so should not get in
>> your way.
>
> Thanks for all of your efforts on getting some x86 support into U-Boot.
> Hopefully in the new year when project work is back under control I will
> have some time to get involved with this - I have almost 20 years experience
> porting commercial BIOS and UEFI solutions for x86 hardware and possibly a
> bunch of Atom C2750 hardware arriving in January.

Sounds great! I do wonder whether U-Boot could support some UEFI protocols.

>
> Other than the list of missing features, what are your long term
> goals/ambitions/desires with x86 support in U-Boot?  From what I can see on
> the Coreboot mailing list it isn't the friendliest of people and doesn't
> seem to know how to deal with the binary blobs that both Intel and AMD seem
> to mandate for their chipsets now.

It would be nice to make x86 a first-class U-Boot citizen, meaning
that it has a reasonable set of features as required by a reasonable
set of modern boards. That means supporting a few more classes of
chipsets. Then we get all the features that U-Boot has, hopefully
without to much of the BIOS-era baggage that x86 often brings along
(U-Boot is pretty simple to understand). I'm pretty happy that the
current port fits well into the U-Boot philosophy.

The binary blobs are certainly a problem, but we deal with them in
other cases also - e.g. some ARM SoCs require a signed pre-boot image.
Something to discuss I suppose.

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


Re: [U-Boot] [PATCH] sata: fix reset_sata for dwc_ahsata

2014-11-26 Thread Soeren Moch
On 26.11.2014 18:38, Nikita Kiryanov wrote:
> Hi Soeren,
> 
> On 11/26/2014 01:40 PM, Soeren Moch wrote:
>> - fix crash when sata device is not initialized
>> - remove disable_sata_clock() since it is not clear which clock for which
>>device should be disabled here
>> - call disable_sata_clock() for mx6 in preboot_os instead
>>
>> Signed-off-by: Soeren Moch 
>> ---
>> Cc: Tom Rini 
>> Cc: Nikita Kiryanov 
>> Cc: Simon Glass 
>> Cc: guillaume.gar...@free.fr
>> Cc: Stefano Babic 
>> ---
>>   arch/arm/imx-common/cpu.c  |  3 +++
>>   drivers/block/dwc_ahsata.c | 14 --
>>   2 files changed, 11 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
>> index b58df7d..28ccd29 100644
>> --- a/arch/arm/imx-common/cpu.c
>> +++ b/arch/arm/imx-common/cpu.c
>> @@ -206,6 +206,9 @@ void arch_preboot_os(void)
>>   {
>>   #if defined(CONFIG_CMD_SATA)
>>   sata_stop();
>> +#if defined(CONFIG_MX6)
>> +disable_sata_clock();
>> +#endif
> 
> I think a more proper way to do this might be to mirror the
> init sequence completely. The simplest init sequence calls
> setup_sata() somewhere before sata_initialize() is invoked,
> and the distribution of labor is:
> - arch/arm/imx-common/sata.c:setup_sata() Turns on clocks
> - common/cmd_sata.c: sata_initialize() Calls driver init
> 
> The inverse would be:
> - common/cmd_sata.c: sata_stop() Calls driver reset
> - arch/arm/imx-common/sata.c:disable_sata() Turns off clocks
> 
> Thus disable_sata() would need to be defined in
> arch/arm/imx-common/sata.c; it will call disable_sata_clock(),
> and be used in cm_fx6's version of stop_sata().
> 
> It's a little convoluted, but consistent with the existing code
> flow, and it also fixes the MX53 problems because
> arch/arm/imx-common/sata.c is not compiled for this platform.

Nikita,

if I remember correctly, the whole purpose of this patch series was to
get a SSD running, which was not recognized by linux if sata is enabled
on boot. So for me disabling the sata link in u-boot makes perfectly
sense to overcome this issue.
But I cannot imagine that disabling the clock of the sata controller
makes any difference here. But I did not test this (I have no access to
such problematic SSD).
I would prefer to keep the code simple and easy to maintain, I don't see
any advantage in mirroring the init sequence on exit. I would not switch
off the sata controller clock. I'm even not sure that my patch would
work for i.MX6SX, if I further think about it. It is already not easy to
understand all implications.
But this is only my personal opinion, I'm not the maintainer of this
code. My only goal with this patch was to get sata running again, for
boards which enable sata (call setup_sata() in board_init() ), but do
not run 'sata init' in the bootcmd by default - and for other
architectures than mx6.

So how to proceed is a question for the maintainers now, I think.
I see following opportunities:
- implement the clock disabling framework as Nikita has described above
- try to get my patch working with minimal changes of the merged code
  (as we are in -rc2 phase of development),
  and possibly apply additional patches from Nikita on this later
- revert the whole patch series

> 
>>   #endif
>>   #if defined(CONFIG_VIDEO_IPUV3)
>>   /* disable video before launching O/S */
>> diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
>> index 9a2b547..9e925d1 100644
>> --- a/drivers/block/dwc_ahsata.c
>> +++ b/drivers/block/dwc_ahsata.c
>> @@ -594,22 +594,24 @@ int init_sata(int dev)
>>
>>   int reset_sata(int dev)
>>   {
>> -struct ahci_probe_ent *probe_ent =
>> -(struct ahci_probe_ent *)sata_dev_desc[dev].priv;
>> -struct sata_host_regs *host_mmio =
>> -(struct sata_host_regs *)probe_ent->mmio_base;
>> +struct ahci_probe_ent *probe_ent;
>> +struct sata_host_regs *host_mmio;
>>
>>   if (dev < 0 || dev > (CONFIG_SYS_SATA_MAX_DEVICE - 1)) {
>>   printf("The sata index %d is out of ranges\n\r", dev);
>>   return -1;
>>   }
>>
>> +probe_ent = (struct ahci_probe_ent *)sata_dev_desc[dev].priv;
>> +if (NULL == probe_ent)
>> +/* not initialized, so nothing to reset */
>> +return 0;
>> +
>> +host_mmio = probe_ent->mmio_base;
> 
> The lack of casting generates a warning during compilation:
> drivers/block/dwc_ahsata.c:610:12: warning: assignment makes pointer
> from integer without a cast [enabled by default]
>   host_mmio = probe_ent->mmio_base;
> ^
> 

Of course you are right here, I accidentally removed the type cast. If
we decide to go on with this patch, I will fix this in a new patch version.

  Soeren

>>   setbits_le32(&host_mmio->ghc, SATA_HOST_GHC_HR);
>>   while (readl(&host_mmio->ghc) & SATA_HOST_GHC_HR)
>>   udelay(100);
>>
>> -disable_sata_clock();
>> -
>>   return 0;
>>   }
>>
>>
> 
___
U-Boot mailing l

Re: [U-Boot] [PATCH v3] fs/ext4/ext4fs.c, fs/fs.c fs/fat/fat_write.c: Adjust 64bit math methods

2014-11-26 Thread Simon Glass
On 26 November 2014 at 15:03, Tom Rini  wrote:
> The changes to introduce loff_t into filesize means that we need to do
> 64bit math on 32bit platforms.  Make sure we use the right wrappers for
> these operations.
>
> Cc: Daniel Schwierzeck 
> Cc: Suriyan Ramasami 
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 

Reviewed-by: Simon Glass 

>
> ---
> Changes in v3:
> - Fix bug Simon pointed out in fs/fs.c
>
> Changes in v2:
> - Correct fs/fat/fat_write.c
> ---
>  fs/ext4/ext4fs.c   |   11 ++-
>  fs/fat/fat_write.c |   10 ++
>  fs/fs.c|6 --
>  3 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
> index 943b5bc..258b9379 100644
> --- a/fs/ext4/ext4fs.c
> +++ b/fs/ext4/ext4fs.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include "ext4_common.h"
> +#include 
>
>  int ext4fs_symlinknest;
>  struct ext_filesystem ext_fs;
> @@ -67,11 +68,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
> if (len > filesize)
> len = filesize;
>
> -   blockcnt = ((len + pos) + blocksize - 1) / blocksize;
> +   blockcnt = lldiv(((len + pos) + blocksize - 1), blocksize);
>
> -   for (i = pos / blocksize; i < blockcnt; i++) {
> +   for (i = lldiv(pos, blocksize); i < blockcnt; i++) {
> lbaint_t blknr;
> -   int blockoff = pos % blocksize;
> +   int blockoff = pos - (blocksize * i);
> int blockend = blocksize;
> int skipfirst = 0;
> blknr = read_allocated_block(&(node->inode), i);
> @@ -82,7 +83,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
>
> /* Last block.  */
> if (i == blockcnt - 1) {
> -   blockend = (len + pos) % blocksize;
> +   blockend = (len + pos) - (blocksize * i);
>
> /* The last portion is exactly blocksize. */
> if (!blockend)
> @@ -90,7 +91,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
> }
>
> /* First block. */
> -   if (i == pos / blocksize) {
> +   if (i == lldiv(pos, blocksize)) {
> skipfirst = blockoff;
> blockend -= skipfirst;
> }
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index 88dd495..473723b 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include "fat.c"
>
>  static void uppercase(char *str, int len)
> @@ -770,7 +772,7 @@ static void fill_dentry(fsdata *mydata, dir_entry 
> *dentptr,
>   */
>  static int check_overflow(fsdata *mydata, __u32 clustnum, loff_t size)
>  {
> -   __u32 startsect, sect_num;
> +   __u32 startsect, sect_num, offset;
>
> if (clustnum > 0) {
> startsect = mydata->data_begin +
> @@ -779,13 +781,13 @@ static int check_overflow(fsdata *mydata, __u32 
> clustnum, loff_t size)
> startsect = mydata->rootdir_sect;
> }
>
> -   sect_num = size / mydata->sect_size;
> -   if (size % mydata->sect_size)
> +   sect_num = div_u64_rem(size, mydata->sect_size, &offset);
> +
> +   if (offset != 0)
> sect_num++;
>
> if (startsect + sect_num > cur_part_info.start + total_sector)
> return -1;
> -
> return 0;
>  }
>
> diff --git a/fs/fs.c b/fs/fs.c
> index 3da7860..ddd751c 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -399,7 +401,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> const argv[],
> printf("%llu bytes read in %lu ms", len_read, time);
> if (time > 0) {
> puts(" (");
> -   print_size(len_read / time * 1000, "/s");
> +   print_size(div_u64(len_read, time) * 1000, "/s");
> puts(")");
> }
> puts("\n");
> @@ -469,7 +471,7 @@ int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> const argv[],
> printf("%llu bytes written in %lu ms", len, time);
> if (time > 0) {
> puts(" (");
> -   print_size(len / time * 1000, "/s");
> +   print_size(div_u64(len, time) * 1000, "/s");
> puts(")");
> }
> puts("\n");
> --
> 1.7.9.5
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3] fs/ext4/ext4fs.c, fs/fs.c fs/fat/fat_write.c: Adjust 64bit math methods

2014-11-26 Thread Tom Rini
The changes to introduce loff_t into filesize means that we need to do
64bit math on 32bit platforms.  Make sure we use the right wrappers for
these operations.

Cc: Daniel Schwierzeck 
Cc: Suriyan Ramasami 
Cc: Simon Glass 
Signed-off-by: Tom Rini 

---
Changes in v3:
- Fix bug Simon pointed out in fs/fs.c

Changes in v2:
- Correct fs/fat/fat_write.c
---
 fs/ext4/ext4fs.c   |   11 ++-
 fs/fat/fat_write.c |   10 ++
 fs/fs.c|6 --
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 943b5bc..258b9379 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include "ext4_common.h"
+#include 
 
 int ext4fs_symlinknest;
 struct ext_filesystem ext_fs;
@@ -67,11 +68,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
if (len > filesize)
len = filesize;
 
-   blockcnt = ((len + pos) + blocksize - 1) / blocksize;
+   blockcnt = lldiv(((len + pos) + blocksize - 1), blocksize);
 
-   for (i = pos / blocksize; i < blockcnt; i++) {
+   for (i = lldiv(pos, blocksize); i < blockcnt; i++) {
lbaint_t blknr;
-   int blockoff = pos % blocksize;
+   int blockoff = pos - (blocksize * i);
int blockend = blocksize;
int skipfirst = 0;
blknr = read_allocated_block(&(node->inode), i);
@@ -82,7 +83,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
 
/* Last block.  */
if (i == blockcnt - 1) {
-   blockend = (len + pos) % blocksize;
+   blockend = (len + pos) - (blocksize * i);
 
/* The last portion is exactly blocksize. */
if (!blockend)
@@ -90,7 +91,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
}
 
/* First block. */
-   if (i == pos / blocksize) {
+   if (i == lldiv(pos, blocksize)) {
skipfirst = blockoff;
blockend -= skipfirst;
}
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 88dd495..473723b 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "fat.c"
 
 static void uppercase(char *str, int len)
@@ -770,7 +772,7 @@ static void fill_dentry(fsdata *mydata, dir_entry *dentptr,
  */
 static int check_overflow(fsdata *mydata, __u32 clustnum, loff_t size)
 {
-   __u32 startsect, sect_num;
+   __u32 startsect, sect_num, offset;
 
if (clustnum > 0) {
startsect = mydata->data_begin +
@@ -779,13 +781,13 @@ static int check_overflow(fsdata *mydata, __u32 clustnum, 
loff_t size)
startsect = mydata->rootdir_sect;
}
 
-   sect_num = size / mydata->sect_size;
-   if (size % mydata->sect_size)
+   sect_num = div_u64_rem(size, mydata->sect_size, &offset);
+   
+   if (offset != 0)
sect_num++;
 
if (startsect + sect_num > cur_part_info.start + total_sector)
return -1;
-
return 0;
 }
 
diff --git a/fs/fs.c b/fs/fs.c
index 3da7860..ddd751c 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -399,7 +401,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[],
printf("%llu bytes read in %lu ms", len_read, time);
if (time > 0) {
puts(" (");
-   print_size(len_read / time * 1000, "/s");
+   print_size(div_u64(len_read, time) * 1000, "/s");
puts(")");
}
puts("\n");
@@ -469,7 +471,7 @@ int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[],
printf("%llu bytes written in %lu ms", len, time);
if (time > 0) {
puts(" (");
-   print_size(len / time * 1000, "/s");
+   print_size(div_u64(len, time) * 1000, "/s");
puts(")");
}
puts("\n");
-- 
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 8/8] dm: core: abolish u-boot, dm-pre-reloc property

2014-11-26 Thread Simon Glass
Hi Masahiro,

On 24 November 2014 at 20:18, Masahiro Yamada  wrote:
> Hi Simon,
>
>
>
> On Mon, 24 Nov 2014 15:29:23 -0700
> Simon Glass  wrote:
>
>> HI Masahiro,
>>
>> On 21 November 2014 at 02:59, Masahiro Yamada  
>> wrote:
>> > Hi Simon,
>> >
>> >
>> >
>> > On Thu, 20 Nov 2014 16:44:22 +
>> > Simon Glass  wrote:
>> >
>> >> Hi Masahiro,
>> >>
>> >> On 19 November 2014 09:21, Masahiro Yamada  
>> >> wrote:
>> >> > Hi Simon,
>> >> >
>> >> >
>> >> >
>> >> > On Tue, 18 Nov 2014 14:37:33 +
>> >> > Simon Glass  wrote:
>> >> >
>> >> >> Hi Masahiro,
>> >> >>
>> >> >> On 18 November 2014 12:51, Masahiro Yamada  
>> >> >> wrote:
>> >> >> > Hi Simon,
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Mon, 17 Nov 2014 18:17:43 +
>> >> >> > Simon Glass  wrote:
>> >> >> >
>> >> >> >> Hi Masahiro,
>> >> >> >>
>> >> >> >> On 17 November 2014 08:19, Masahiro Yamada 
>> >> >> >>  wrote:
>> >> >> >> > The driver model provides two ways to pass the device information,
>> >> >> >> > platform data and device tree.  Either way works to bind devices 
>> >> >> >> > and
>> >> >> >> > drivers, but there is inconsistency in terms of how to pass the
>> >> >> >> > pre-reloc flag.
>> >> >> >> >
>> >> >> >> > In the platform data way, the pre-reloc DM scan checks if each 
>> >> >> >> > driver
>> >> >> >> > has DM_FLAG_PRE_RELOC flag (this was changed to use 
>> >> >> >> > U_BOOT_DRIVER_F
>> >> >> >> > just before).  That is, each **driver** has the pre-reloc 
>> >> >> >> > attribute.
>> >> >> >> >
>> >> >> >> > In the device tree control, the existence of 
>> >> >> >> > "u-boot,dm-pre-reloc" is
>> >> >> >> > checked for each device node.  The driver flag 
>> >> >> >> > "DM_FLAG_PRE_RELOC" is
>> >> >> >> > never checked.  That is, each **device** owns the pre-reloc 
>> >> >> >> > attribute.
>> >> >> >> >
>> >> >> >> > Drivers should generally work both with platform data and device 
>> >> >> >> > tree,
>> >> >> >> > but this inconsistency has made our life difficult.
>> >> >> >>
>> >> >> >> I feel we should use device tree where available, and only fall back
>> >> >> >> to platform data when necessary (no device tree available for
>> >> >> >> platform, for example).
>> >> >> >
>> >> >> > No, it is true that device tree is a useful tool, but it should be 
>> >> >> > optional.
>> >> >> >
>> >> >> > All the infrastructures of drivers must work perfectly without 
>> >> >> > device tree.
>> >> >> >
>> >> >> > The device tree is just one choice of how to give device information.
>> >> >> >
>> >> >>
>> >> >> Which platform(s) are we talking about here?
>> >> >
>> >> >
>> >> > I am talking about the general design policy of drivers
>> >> > in U-Boot and Linux.
>> >>
>> >> Well Linux has moved away from platform data, right?
>> >>
>> >> >
>> >> >
>> >> >
>> >> >> >
>> >> >> >
>> >> >> >> >
>> >> >> >> > This commit abolishes "u-boot,dm-pre-reloc" property because:
>> >> >> >> >
>> >> >> >> >  - Having a U-Boot specific property makes it difficult to share 
>> >> >> >> > the
>> >> >> >> >device tree sources between Linux and U-Boot.
>> >> >> >> >
>> >> >> >> >  - The number of devices is generally larger than that of drivers.
>> >> >> >> >Each driver often has multiple devices with different base
>> >> >> >> >addresses.  It seems more reasonable to add the pre-reloc 
>> >> >> >> > attribute
>> >> >> >> >to drivers than devices.
>> >> >> >>
>> >> >> >> The inability for platform data to specify which devices need to be
>> >> >> >> pre-relocation is certainly a limitation. But I'm not sure that the
>> >> >> >> solution is to remove that feature from the device tree. Prior to
>> >> >> >> relocation memory may be severely limited. Things like GPIO and 
>> >> >> >> serial
>> >> >> >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for
>> >> >> >> serial), but only a subset may be needed before relocation (on Tegra
>> >> >> >> only 2!).
>> >> >> >>
>> >> >> >> I'm actually pretty comfortable with platform data having a limited
>> >> >> >> subset of functionality, since I believe most platforms will use
>> >> >> >> device tree for one reason or another.
>> >> >> >>
>> >> >> >> Thoughts?
>> >> >> >>
>> >> >> >
>> >> >> > No, it is not justified to compel to use device tree
>> >> >> > unless Linux is the target OS.
>> >> >> >
>> >> >> > Even in Linux, limited numbers of architrectures use device trees.
>> >> >>
>> >> >> Fair enough, but let's look at this when the case comes up. So far the
>> >> >> platforms that use I2C and SPI with DM do use device tree in Linux and
>> >> >> probably should do in U-Boot.
>> >> >
>> >> > OK, so let's think about it when a problem happens.
>> >> >
>> >> >
>> >> > Let's get back talking about this patch.
>> >> > If 8/8 is not acceptable, I do not have motivation for 6/8 and 7/8, 
>> >> > either.
>> >> >
>> >> >
>> >> > I still believe that the top priority of the design policy is
>> >> > to share the same device tree source between U-Boot and Linux.
>> >>
>> >> Agreed, and we reall

[U-Boot] [PATCH v4 2/3] tegra: dts: Sync tegra124.dtsi with linux kernel

2014-11-26 Thread Simon Glass
Sync this up with Linux v3.18-rc5. Exclude features that are unlikely to
supported in U-Boot soon (regulators, pinmux). Also the addresses are
updated to 32-bit. Otherwise it is the same. Also bring in the dt-bindings
for pinctrl.

Signed-off-by: Simon Glass 
Acked-by: Stephen Warren 
---

Changes in v4: None
Changes in v3:
- Add patch to update tegra124.dtsi from Linux v3.18-rc5

Changes in v2: None

 arch/arm/dts/tegra124.dtsi  | 114 
 include/dt-bindings/pinctrl/pinctrl-tegra.h |  45 +++
 2 files changed, 159 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra.h

diff --git a/arch/arm/dts/tegra124.dtsi b/arch/arm/dts/tegra124.dtsi
index 3288f28..6b5c2be 100644
--- a/arch/arm/dts/tegra124.dtsi
+++ b/arch/arm/dts/tegra124.dtsi
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 
 #include "skeleton.dtsi"
@@ -192,6 +193,16 @@
status = "disabled";
};
 
+   pwm: pwm@7000a000 {
+   compatible = "nvidia,tegra124-pwm", "nvidia,tegra20-pwm";
+   reg = <0x7000a000 0x100>;
+   #pwm-cells = <2>;
+   clocks = <&tegra_car TEGRA124_CLK_PWM>;
+   resets = <&tegra_car 17>;
+   reset-names = "pwm";
+   status = "disabled";
+   };
+
spi@7000d400 {
compatible = "nvidia,tegra124-spi", "nvidia,tegra114-spi";
reg = <0x7000d400 0x200>;
@@ -290,6 +301,109 @@
status = "disabled";
};
 
+   ahub@7030 {
+   compatible = "nvidia,tegra124-ahub";
+   reg = <0x7030 0x200>,
+ <0x70300800 0x800>,
+ <0x70300200 0x600>;
+   interrupts = ;
+   clocks = <&tegra_car TEGRA124_CLK_D_AUDIO>,
+<&tegra_car TEGRA124_CLK_APBIF>;
+   clock-names = "d_audio", "apbif";
+   resets = <&tegra_car 106>, /* d_audio */
+<&tegra_car 107>, /* apbif */
+<&tegra_car 30>,  /* i2s0 */
+<&tegra_car 11>,  /* i2s1 */
+<&tegra_car 18>,  /* i2s2 */
+<&tegra_car 101>, /* i2s3 */
+<&tegra_car 102>, /* i2s4 */
+<&tegra_car 108>, /* dam0 */
+<&tegra_car 109>, /* dam1 */
+<&tegra_car 110>, /* dam2 */
+<&tegra_car 10>,  /* spdif */
+<&tegra_car 153>, /* amx */
+<&tegra_car 185>, /* amx1 */
+<&tegra_car 154>, /* adx */
+<&tegra_car 180>, /* adx1 */
+<&tegra_car 186>, /* afc0 */
+<&tegra_car 187>, /* afc1 */
+<&tegra_car 188>, /* afc2 */
+<&tegra_car 189>, /* afc3 */
+<&tegra_car 190>, /* afc4 */
+<&tegra_car 191>; /* afc5 */
+   reset-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2",
+ "i2s3", "i2s4", "dam0", "dam1", "dam2",
+ "spdif", "amx", "amx1", "adx", "adx1",
+ "afc0", "afc1", "afc2", "afc3", "afc4", "afc5";
+   dmas = <&apbdma 1>, <&apbdma 1>,
+  <&apbdma 2>, <&apbdma 2>,
+  <&apbdma 3>, <&apbdma 3>,
+  <&apbdma 4>, <&apbdma 4>,
+  <&apbdma 6>, <&apbdma 6>,
+  <&apbdma 7>, <&apbdma 7>,
+  <&apbdma 12>, <&apbdma 12>,
+  <&apbdma 13>, <&apbdma 13>,
+  <&apbdma 14>, <&apbdma 14>,
+  <&apbdma 29>, <&apbdma 29>;
+   dma-names = "rx0", "tx0", "rx1", "tx1", "rx2", "tx2",
+   "rx3", "tx3", "rx4", "tx4", "rx5", "tx5",
+   "rx6", "tx6", "rx7", "tx7", "rx8", "tx8",
+   "rx9", "tx9";
+   ranges;
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   tegra_i2s0: i2s@70301000 {
+   compatible = "nvidia,tegra124-i2s";
+   reg = <0x70301000 0x100>;
+   nvidia,ahub-cif-ids = <4 4>;
+   clocks = <&tegra_car TEGRA124_CLK_I2S0>;
+   resets = <&tegra_car 30>;
+   reset-names = "i2s";
+   status = "disabled";
+   };
+
+   tegra_i2s1: i2s@70301100 {
+   compatible = "nvidia,tegra124-i2s";
+   reg = <0x70301100 0x100>;
+   nvidia,ahub-cif-ids = <5 5>;
+   clocks = <&tegra_car TEGRA124_CLK_I2S1>;
+   resets = <&tegra_car 11>;
+  

[U-Boot] [PATCH v4 1/3] dts: Bring in Chrome OS keyboard device tree definition

2014-11-26 Thread Simon Glass
This will be used by nyan-big, but bring it in in a separate patch since it
will be common to other boards.

Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3:
- Add patch to bring in cros-ec-keyboard.dtsi

Changes in v2: None

 arch/arm/dts/cros-ec-keyboard.dtsi | 105 +
 1 file changed, 105 insertions(+)
 create mode 100644 arch/arm/dts/cros-ec-keyboard.dtsi

diff --git a/arch/arm/dts/cros-ec-keyboard.dtsi 
b/arch/arm/dts/cros-ec-keyboard.dtsi
new file mode 100644
index 000..9c7fb0a
--- /dev/null
+++ b/arch/arm/dts/cros-ec-keyboard.dtsi
@@ -0,0 +1,105 @@
+/*
+ * Keyboard dts fragment for devices that use cros-ec-keyboard
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include 
+
+&cros_ec {
+   keyboard-controller {
+   compatible = "google,cros-ec-keyb";
+   keypad,num-rows = <8>;
+   keypad,num-columns = <13>;
+   google,needs-ghost-filter;
+
+   linux,keymap = <
+   MATRIX_KEY(0x00, 0x01, KEY_LEFTMETA)
+   MATRIX_KEY(0x00, 0x02, KEY_F1)
+   MATRIX_KEY(0x00, 0x03, KEY_B)
+   MATRIX_KEY(0x00, 0x04, KEY_F10)
+   MATRIX_KEY(0x00, 0x06, KEY_N)
+   MATRIX_KEY(0x00, 0x08, KEY_EQUAL)
+   MATRIX_KEY(0x00, 0x0a, KEY_RIGHTALT)
+
+   MATRIX_KEY(0x01, 0x01, KEY_ESC)
+   MATRIX_KEY(0x01, 0x02, KEY_F4)
+   MATRIX_KEY(0x01, 0x03, KEY_G)
+   MATRIX_KEY(0x01, 0x04, KEY_F7)
+   MATRIX_KEY(0x01, 0x06, KEY_H)
+   MATRIX_KEY(0x01, 0x08, KEY_APOSTROPHE)
+   MATRIX_KEY(0x01, 0x09, KEY_F9)
+   MATRIX_KEY(0x01, 0x0b, KEY_BACKSPACE)
+
+   MATRIX_KEY(0x02, 0x00, KEY_LEFTCTRL)
+   MATRIX_KEY(0x02, 0x01, KEY_TAB)
+   MATRIX_KEY(0x02, 0x02, KEY_F3)
+   MATRIX_KEY(0x02, 0x03, KEY_T)
+   MATRIX_KEY(0x02, 0x04, KEY_F6)
+   MATRIX_KEY(0x02, 0x05, KEY_RIGHTBRACE)
+   MATRIX_KEY(0x02, 0x06, KEY_Y)
+   MATRIX_KEY(0x02, 0x07, KEY_102ND)
+   MATRIX_KEY(0x02, 0x08, KEY_LEFTBRACE)
+   MATRIX_KEY(0x02, 0x09, KEY_F8)
+
+   MATRIX_KEY(0x03, 0x01, KEY_GRAVE)
+   MATRIX_KEY(0x03, 0x02, KEY_F2)
+   MATRIX_KEY(0x03, 0x03, KEY_5)
+   MATRIX_KEY(0x03, 0x04, KEY_F5)
+   MATRIX_KEY(0x03, 0x06, KEY_6)
+   MATRIX_KEY(0x03, 0x08, KEY_MINUS)
+   MATRIX_KEY(0x03, 0x0b, KEY_BACKSLASH)
+
+   MATRIX_KEY(0x04, 0x00, KEY_RIGHTCTRL)
+   MATRIX_KEY(0x04, 0x01, KEY_A)
+   MATRIX_KEY(0x04, 0x02, KEY_D)
+   MATRIX_KEY(0x04, 0x03, KEY_F)
+   MATRIX_KEY(0x04, 0x04, KEY_S)
+   MATRIX_KEY(0x04, 0x05, KEY_K)
+   MATRIX_KEY(0x04, 0x06, KEY_J)
+   MATRIX_KEY(0x04, 0x08, KEY_SEMICOLON)
+   MATRIX_KEY(0x04, 0x09, KEY_L)
+   MATRIX_KEY(0x04, 0x0a, KEY_BACKSLASH)
+   MATRIX_KEY(0x04, 0x0b, KEY_ENTER)
+
+   MATRIX_KEY(0x05, 0x01, KEY_Z)
+   MATRIX_KEY(0x05, 0x02, KEY_C)
+   MATRIX_KEY(0x05, 0x03, KEY_V)
+   MATRIX_KEY(0x05, 0x04, KEY_X)
+   MATRIX_KEY(0x05, 0x05, KEY_COMMA)
+   MATRIX_KEY(0x05, 0x06, KEY_M)
+   MATRIX_KEY(0x05, 0x07, KEY_LEFTSHIFT)
+   MATRIX_KEY(0x05, 0x08, KEY_SLASH)
+   MATRIX_KEY(0x05, 0x09, KEY_DOT)
+   MATRIX_KEY(0x05, 0x0b, KEY_SPACE)
+
+   MATRIX_KEY(0x06, 0x01, KEY_1)
+   MATRIX_KEY(0x06, 0x02, KEY_3)
+   MATRIX_KEY(0x06, 0x03, KEY_4)
+   MATRIX_KEY(0x06, 0x04, KEY_2)
+   MATRIX_KEY(0x06, 0x05, KEY_8)
+   MATRIX_KEY(0x06, 0x06, KEY_7)
+   MATRIX_KEY(0x06, 0x08, KEY_0)
+   MATRIX_KEY(0x06, 0x09, KEY_9)
+   MATRIX_KEY(0x06, 0x0a, KEY_LEFTALT)
+   MATRIX_KEY(0x06, 0x0b, KEY_DOWN)
+   MATRIX_KEY(0x06, 0x0c, KEY_RIGHT)
+
+   MATRIX_KEY(0x07, 0x01, KEY_Q)
+   MATRIX_KEY(0x07, 0x02, KEY_E)
+   MATRIX_KEY(0x07, 0x03, KEY_R)
+

[U-Boot] [PATCH v4 3/3] ARM: tegra: Add support for nyan-big board

2014-11-26 Thread Simon Glass
From: Allen Martin 

Nyan-big is a Tegra124 clamshell board that is very similar to venice2, but
it has a different panel, the sdcard cd and wp sense are flipped, and it has
a different revision of the AS3722 PMIC.

This is the Acer Chromebook 13 CB5-311-T7NN (13.3-inch HD, NVIDIA
Tegra K1, 2GB). The display is not currently supported, so it should
boot on other nyan-based Chromebooks also, but only the device tree for
nyan-big is provided here.

The device tree file is from Linux but with features removed which are
unlikely to be supported in U-Boot soon (regulators, pinmux). Also the
addresses are updated to 32-bit.

Signed-off-by: Allen Martin 
Signed-off-by: Simon Glass 
(rebase, change to 'nyan-big', fix pinmux that resets nyan-big)

---

Changes in v4:
- Move FIT support to nyan-big only
- Rename nyan to nyan-big everywhere

Changes in v3:
- Rename to nyan from norrin
- Bring in device tree file from Linux v3.18-rc5
- Generate pinmux file from tegra-pinmux-scripts

Changes in v2:
- Rebase and adjust for Kconfig
- Fix up pinmux that reset norrin
- Add note as to the Chromebook's retail name, since it is now released

 arch/arm/cpu/armv7/tegra124/Kconfig|  10 +
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/tegra124-nyan-big.dts | 365 +
 board/nvidia/nyan-big/Kconfig  |  24 ++
 board/nvidia/nyan-big/MAINTAINERS  |   6 +
 board/nvidia/nyan-big/Makefile |   9 +
 board/nvidia/nyan-big/nyan-big.c   |  29 ++
 board/nvidia/nyan-big/pinmux-config-nyan-big.h | 287 +++
 board/nvidia/venice2/as3722_init.h |   2 +-
 configs/nyan-big_defconfig |   5 +
 include/configs/nyan-big.h |  79 ++
 11 files changed, 816 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/tegra124-nyan-big.dts
 create mode 100644 board/nvidia/nyan-big/Kconfig
 create mode 100644 board/nvidia/nyan-big/MAINTAINERS
 create mode 100644 board/nvidia/nyan-big/Makefile
 create mode 100644 board/nvidia/nyan-big/nyan-big.c
 create mode 100644 board/nvidia/nyan-big/pinmux-config-nyan-big.h
 create mode 100644 configs/nyan-big_defconfig
 create mode 100644 include/configs/nyan-big.h

diff --git a/arch/arm/cpu/armv7/tegra124/Kconfig 
b/arch/arm/cpu/armv7/tegra124/Kconfig
index 6a1c83a..88f627c 100644
--- a/arch/arm/cpu/armv7/tegra124/Kconfig
+++ b/arch/arm/cpu/armv7/tegra124/Kconfig
@@ -6,6 +6,15 @@ choice
 config TARGET_JETSON_TK1
bool "NVIDIA Tegra124 Jetson TK1 board"
 
+config TARGET_NYAN_BIG
+   bool "Google/NVIDIA Nyan-big Chrombook"
+   help
+ Nyan Big is a Tegra124 clamshell board that is very similar
+ to venice2, but it has a different panel, the sdcard CD and WP
+ sense are flipped, and it has a different revision of the AS3722
+ PMIC. The retail name is the Acer Chromebook 13 CB5-311-T7NN
+ (13.3-inch HD, NVIDIA Tegra K1, 2GB).
+
 config TARGET_VENICE2
bool "NVIDIA Tegra124 Venice2"
 
@@ -15,6 +24,7 @@ config SYS_SOC
default "tegra124"
 
 source "board/nvidia/jetson-tk1/Kconfig"
+source "board/nvidia/nyan-big/Kconfig"
 source "board/nvidia/venice2/Kconfig"
 
 endif
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e5846ea..f8c0e48 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -31,6 +31,7 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra30-tec-ng.dtb \
tegra114-dalmore.dtb \
tegra124-jetson-tk1.dtb \
+   tegra124-nyan-big.dtb \
tegra124-venice2.dtb
 dtb-$(CONFIG_ZYNQ) += zynq-zc702.dtb \
zynq-zc706.dtb \
diff --git a/arch/arm/dts/tegra124-nyan-big.dts 
b/arch/arm/dts/tegra124-nyan-big.dts
new file mode 100644
index 000..c1f35a0
--- /dev/null
+++ b/arch/arm/dts/tegra124-nyan-big.dts
@@ -0,0 +1,365 @@
+/dts-v1/;
+
+#include 
+#include "tegra124.dtsi"
+
+/ {
+   model = "Acer Chromebook 13 CB5-311";
+   compatible = "google,nyan-big", "nvidia,tegra124";
+
+   aliases {
+   console = &uarta;
+   i2c0 = "/i2c@7000d000";
+   i2c1 = "/i2c@7000c000";
+   i2c2 = "/i2c@7000c400";
+   i2c3 = "/i2c@7000c500";
+   i2c4 = "/i2c@7000c700";
+   i2c5 = "/i2c@7000d100";
+   rtc0 = "/i2c@0,7000d000/pmic@40";
+   rtc1 = "/rtc@0,7000e000";
+   sdhci0 = "/sdhci@700b0600";
+   sdhci1 = "/sdhci@700b0400";
+   spi0 = "/spi@7000d400";
+   spi1 = "/spi@7000da00";
+   usb0 = "/usb@7d00";
+   usb1 = "/usb@7d008000";
+   };
+
+   memory {
+   reg = <0x8000 0x8000>;
+   };
+
+   serial@70006000 {
+   /* Debug connector on the bottom of the board near SD card. */
+   status = "okay";
+   };
+
+   pwm@7000a000 {
+   status = "okay";
+   };

Re: [U-Boot] [PATCH 7/8] ARM: UniPhier: display model name if it is available in device tree

2014-11-26 Thread Simon Glass
Hi Masahiro,

On 26 November 2014 at 02:34, Masahiro Yamada  wrote:
> If CONFIG_OF_CONTROL is defined and the root node of the device tree
> has "model" property, display the model name instead of the hard-coded
> board name.
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Simon Glass 

This works, but also see if CONFIG_DISPLAY_BOARDINFO_LATE works for
you. Or perhaps we can do this prior to relocation if
CONFIG_DISPLAY_BOARDINFO is not defined?

Anyway your code is not really board-specific.

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


Re: [U-Boot] [PATCH 2/8] ARM: UniPhier: add dummy gpio.h to enable CONFIG_OF_CONTROL

2014-11-26 Thread Simon Glass
Hi Masahiro,

On 26 November 2014 at 02:33, Masahiro Yamada  wrote:
> If CONFIG_OF_CONTROL is enabled, lib/fdtdec.c is compiled.
> It includes  and then  includes
> .  Consequently, all the SoCs that enable
> CONFIG_OF_CONTROL must have  even if they do not
> support GPIO.
>
> In the first place, GPIO has nothing to do with OF_CONTROL.
> It is wrong that lib/fdtdec.c includes GPIO functions; it should
> be split into two files, FDT-common things and GPIO things.
> It is, however, a pretty big work to fix that correctly.
>
> This is a compromised commit to add a dummy 
> to support OF_CONTROL for UniPhier platform.  This dummy header
> will be removed after FDT-GPIO stuff is fixed correctly.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
> I am working on the task to split lib/fdtdec.c and
> move GPIO functions to drivers/gpio/.

That code is only temporary and we can probably remove it soon. It
should move to the GPIO uclass.

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


Re: [U-Boot] [PATCH v2] fs/ext4/ext4fs.c, fs/fs.c fs/fat/fat_write.c: Adjust 64bit math methods

2014-11-26 Thread Tom Rini
On Wed, Nov 26, 2014 at 12:36:27PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On 26 November 2014 at 12:29, Tom Rini  wrote:
> > The changes to introduce loff_t into filesize means that we need to do
> > 64bit math on 32bit platforms.  Make sure we use the right wrappers for
> > these operations.
> >
> > Cc: Daniel Schwierzeck 
> > Cc: Suriyan Ramasami 
> > Cc: Simon Glass 
> > Signed-off-by: Tom Rini 
> 
> This fixes things for me, thanks! But please see below.
> 
> > ---
> >  fs/ext4/ext4fs.c   |   11 ++-
> >  fs/fat/fat_write.c |   10 ++
> >  fs/fs.c|6 --
> >  3 files changed, 16 insertions(+), 11 deletions(-)
> >
> > diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
> > index 943b5bc..258b9379 100644
> > --- a/fs/ext4/ext4fs.c
> > +++ b/fs/ext4/ext4fs.c
> > @@ -25,6 +25,7 @@
> >  #include 
> >  #include 
> >  #include "ext4_common.h"
> > +#include 
> >
> >  int ext4fs_symlinknest;
> >  struct ext_filesystem ext_fs;
> > @@ -67,11 +68,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t 
> > pos,
> > if (len > filesize)
> > len = filesize;
> >
> > -   blockcnt = ((len + pos) + blocksize - 1) / blocksize;
> > +   blockcnt = lldiv(((len + pos) + blocksize - 1), blocksize);
> >
> > -   for (i = pos / blocksize; i < blockcnt; i++) {
> > +   for (i = lldiv(pos, blocksize); i < blockcnt; i++) {
> > lbaint_t blknr;
> > -   int blockoff = pos % blocksize;
> > +   int blockoff = pos - (blocksize * i);
> > int blockend = blocksize;
> > int skipfirst = 0;
> > blknr = read_allocated_block(&(node->inode), i);
> > @@ -82,7 +83,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
> >
> > /* Last block.  */
> > if (i == blockcnt - 1) {
> > -   blockend = (len + pos) % blocksize;
> > +   blockend = (len + pos) - (blocksize * i);
> 
> Actually do you think it would be clearer to use div_u64_rem() here?

I don't think so only since we don't care about the quotient only the
remainder.  In the FAT case we needed both (and that's what got me
seeing the  functions.

> 
> >
> > /* The last portion is exactly blocksize. */
> > if (!blockend)
> > @@ -90,7 +91,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
> > }
> >
> > /* First block. */
> > -   if (i == pos / blocksize) {
> > +   if (i == lldiv(pos, blocksize)) {
> > skipfirst = blockoff;
> > blockend -= skipfirst;
> > }
> > diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> > index 88dd495..473723b 100644
> > --- a/fs/fat/fat_write.c
> > +++ b/fs/fat/fat_write.c
> > @@ -13,6 +13,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include "fat.c"
> >
> >  static void uppercase(char *str, int len)
> > @@ -770,7 +772,7 @@ static void fill_dentry(fsdata *mydata, dir_entry 
> > *dentptr,
> >   */
> >  static int check_overflow(fsdata *mydata, __u32 clustnum, loff_t size)
> >  {
> > -   __u32 startsect, sect_num;
> > +   __u32 startsect, sect_num, offset;
> >
> > if (clustnum > 0) {
> > startsect = mydata->data_begin +
> > @@ -779,13 +781,13 @@ static int check_overflow(fsdata *mydata, __u32 
> > clustnum, loff_t size)
> > startsect = mydata->rootdir_sect;
> > }
> >
> > -   sect_num = size / mydata->sect_size;
> > -   if (size % mydata->sect_size)
> > +   sect_num = div_u64_rem(size, mydata->sect_size, &offset);
> > +
> > +   if (offset != 0)
> > sect_num++;
> >
> > if (startsect + sect_num > cur_part_info.start + total_sector)
> > return -1;
> > -
> > return 0;
> >  }
> >
> > diff --git a/fs/fs.c b/fs/fs.c
> > index 3da7860..52078139 100644
> > --- a/fs/fs.c
> > +++ b/fs/fs.c
> > @@ -23,6 +23,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -399,7 +401,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char 
> > * const argv[],
> > printf("%llu bytes read in %lu ms", len_read, time);
> > if (time > 0) {
> > puts(" (");
> > -   print_size(len_read / time * 1000, "/s");
> > +   print_size(div_u64(len_read, time * 1000), "/s");
> 
> The old code multiplies by 1000 but the new code divides. I think it should 
> be:
> 
>print_size(div_u64(len_read, time) * 1000, "/s");
> 
> > puts(")");
> > }
> > puts("\n");
> > @@ -469,7 +471,7 @@ int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char 
> > * const argv[],
> > printf("%llu bytes written in %lu ms", len, time);
> > if (time > 0) {
> > puts(" ("

Re: [U-Boot] [PATCH 2/8] ARM: UniPhier: add dummy gpio.h to enable CONFIG_OF_CONTROL

2014-11-26 Thread Simon Glass
On 26 November 2014 at 13:18, Simon Glass  wrote:
> Hi Masahiro,
>
> On 26 November 2014 at 02:33, Masahiro Yamada  
> wrote:
>> If CONFIG_OF_CONTROL is enabled, lib/fdtdec.c is compiled.
>> It includes  and then  includes
>> .  Consequently, all the SoCs that enable
>> CONFIG_OF_CONTROL must have  even if they do not
>> support GPIO.
>>
>> In the first place, GPIO has nothing to do with OF_CONTROL.
>> It is wrong that lib/fdtdec.c includes GPIO functions; it should
>> be split into two files, FDT-common things and GPIO things.
>> It is, however, a pretty big work to fix that correctly.
>>
>> This is a compromised commit to add a dummy 
>> to support OF_CONTROL for UniPhier platform.  This dummy header
>> will be removed after FDT-GPIO stuff is fixed correctly.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>> I am working on the task to split lib/fdtdec.c and
>> move GPIO functions to drivers/gpio/.
>
> That code is only temporary and we can probably remove it soon. It
> should move to the GPIO uclass.
>
> Regards,
> Simon

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


Re: [U-Boot] [PATCH V2] cmd_i2c: Provide option for bulk 'i2c write' in one transaction

2014-11-26 Thread Simon Glass
+Heiko

Hi,

On 26 November 2014 at 12:37, Lubomir Popov  wrote:
> Hi Simon,
>
> [snip]
>
>>> +   while (length-- > 0) {
>>> +   if (i2c_write(chip, devaddr++, alen, memaddr++, 1) 
>>> != 0)
>>> +   return i2c_report_err(-1, I2C_ERR_WRITE);
>>>  /*
>>>   * No write delay with FRAM devices.
>>>   */
>
>>Should this be indented?
>
>>>  #if !defined(CONFIG_SYS_I2C_FRAM)
>>> -   udelay(11000);
>>> +   udelay(11000);
>>>  #endif
>>> +   }
>
> [snip]
>
> Which indent do you mean? The udelay() is within the while loop, so it 
> should. The
> comment above your note - I kept it as is, aligned with the #if/#endif.

It was hard to tell in my emailed, but yes i see, you have kept it
where it was, which is fine.

I added Heiko (I2C maintainer) to cc. As mentioned, but in more
detail, with driver model 'i2c flags 2' will select this behaviour for
any i2c access, not just for this command. See u-boot-dm/i2c-working2
file i2c-uclass.c.

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


Re: [U-Boot] [PATCH V2] cmd_i2c: Provide option for bulk 'i2c write' in one transaction

2014-11-26 Thread Lubomir Popov
Hi Simon,

[snip]

>> +   while (length-- > 0) {
>> +   if (i2c_write(chip, devaddr++, alen, memaddr++, 1) 
>> != 0)
>> +   return i2c_report_err(-1, I2C_ERR_WRITE);
>>  /*
>>   * No write delay with FRAM devices.
>>   */

>Should this be indented?

>>  #if !defined(CONFIG_SYS_I2C_FRAM)
>> -   udelay(11000);
>> +   udelay(11000);
>>  #endif
>> +   }

[snip]

Which indent do you mean? The udelay() is within the while loop, so it should. 
The
comment above your note - I kept it as is, aligned with the #if/#endif.

Regards,
Lubo


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


Re: [U-Boot] [PATCH v2] fs/ext4/ext4fs.c, fs/fs.c fs/fat/fat_write.c: Adjust 64bit math methods

2014-11-26 Thread Simon Glass
Hi Tom,

On 26 November 2014 at 12:29, Tom Rini  wrote:
> The changes to introduce loff_t into filesize means that we need to do
> 64bit math on 32bit platforms.  Make sure we use the right wrappers for
> these operations.
>
> Cc: Daniel Schwierzeck 
> Cc: Suriyan Ramasami 
> Cc: Simon Glass 
> Signed-off-by: Tom Rini 

This fixes things for me, thanks! But please see below.

> ---
>  fs/ext4/ext4fs.c   |   11 ++-
>  fs/fat/fat_write.c |   10 ++
>  fs/fs.c|6 --
>  3 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
> index 943b5bc..258b9379 100644
> --- a/fs/ext4/ext4fs.c
> +++ b/fs/ext4/ext4fs.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include "ext4_common.h"
> +#include 
>
>  int ext4fs_symlinknest;
>  struct ext_filesystem ext_fs;
> @@ -67,11 +68,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
> if (len > filesize)
> len = filesize;
>
> -   blockcnt = ((len + pos) + blocksize - 1) / blocksize;
> +   blockcnt = lldiv(((len + pos) + blocksize - 1), blocksize);
>
> -   for (i = pos / blocksize; i < blockcnt; i++) {
> +   for (i = lldiv(pos, blocksize); i < blockcnt; i++) {
> lbaint_t blknr;
> -   int blockoff = pos % blocksize;
> +   int blockoff = pos - (blocksize * i);
> int blockend = blocksize;
> int skipfirst = 0;
> blknr = read_allocated_block(&(node->inode), i);
> @@ -82,7 +83,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
>
> /* Last block.  */
> if (i == blockcnt - 1) {
> -   blockend = (len + pos) % blocksize;
> +   blockend = (len + pos) - (blocksize * i);

Actually do you think it would be clearer to use div_u64_rem() here?

>
> /* The last portion is exactly blocksize. */
> if (!blockend)
> @@ -90,7 +91,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
> }
>
> /* First block. */
> -   if (i == pos / blocksize) {
> +   if (i == lldiv(pos, blocksize)) {
> skipfirst = blockoff;
> blockend -= skipfirst;
> }
> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
> index 88dd495..473723b 100644
> --- a/fs/fat/fat_write.c
> +++ b/fs/fat/fat_write.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include "fat.c"
>
>  static void uppercase(char *str, int len)
> @@ -770,7 +772,7 @@ static void fill_dentry(fsdata *mydata, dir_entry 
> *dentptr,
>   */
>  static int check_overflow(fsdata *mydata, __u32 clustnum, loff_t size)
>  {
> -   __u32 startsect, sect_num;
> +   __u32 startsect, sect_num, offset;
>
> if (clustnum > 0) {
> startsect = mydata->data_begin +
> @@ -779,13 +781,13 @@ static int check_overflow(fsdata *mydata, __u32 
> clustnum, loff_t size)
> startsect = mydata->rootdir_sect;
> }
>
> -   sect_num = size / mydata->sect_size;
> -   if (size % mydata->sect_size)
> +   sect_num = div_u64_rem(size, mydata->sect_size, &offset);
> +
> +   if (offset != 0)
> sect_num++;
>
> if (startsect + sect_num > cur_part_info.start + total_sector)
> return -1;
> -
> return 0;
>  }
>
> diff --git a/fs/fs.c b/fs/fs.c
> index 3da7860..52078139 100644
> --- a/fs/fs.c
> +++ b/fs/fs.c
> @@ -23,6 +23,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> @@ -399,7 +401,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> const argv[],
> printf("%llu bytes read in %lu ms", len_read, time);
> if (time > 0) {
> puts(" (");
> -   print_size(len_read / time * 1000, "/s");
> +   print_size(div_u64(len_read, time * 1000), "/s");

The old code multiplies by 1000 but the new code divides. I think it should be:

   print_size(div_u64(len_read, time) * 1000, "/s");

> puts(")");
> }
> puts("\n");
> @@ -469,7 +471,7 @@ int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> const argv[],
> printf("%llu bytes written in %lu ms", len, time);
> if (time > 0) {
> puts(" (");
> -   print_size(len / time * 1000, "/s");
> +   print_size(div_u64(len, time * 1000), "/s");

and here.

> puts(")");
> }
> puts("\n");
> --
> 1.7.9.5
>

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


[U-Boot] [PATCH] spi: Fix flag collision for SST_WP

2014-11-26 Thread Simon Glass
At present SECT_4K is the same as SST_WP so we cannot tell these apart. Fix
this so that the table in sf_params.c can be used correctly.

Reported-by: Jens Rottmann 
Signed-off-by: Simon Glass 
---

 drivers/mtd/spi/sf_internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 5b7670c..1d6a138 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -38,6 +38,7 @@ enum {
SECT_32K= 1 << 1,
E_FSR   = 1 << 2,
WR_QPP  = 1 << 3,
+   SST_WP  = 1 << 4,   /* Supports AAI word program */
 };
 
 #define SPI_FLASH_3B_ADDR_LEN  3
@@ -101,7 +102,6 @@ enum {
 
 /* SST specific */
 #ifdef CONFIG_SPI_FLASH_SST
-# define SST_WP0x01/* Supports AAI word program */
 # define CMD_SST_BP0x02/* Byte Program */
 # define CMD_SST_AAI_WP0xAD/* Auto Address Incr Word Program */
 
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH] arm: at91: snapper9260: Drop invalid CONFIG_SKIP_RELOCATE_UBOOT

2014-11-26 Thread Simon Glass
This config is not valid, so drop it.

Signed-off-by: Simon Glass 
---

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

diff --git a/include/configs/snapper9260.h b/include/configs/snapper9260.h
index 942af2e..9fa644f 100644
--- a/include/configs/snapper9260.h
+++ b/include/configs/snapper9260.h
@@ -34,7 +34,6 @@
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
 #define CONFIG_SKIP_LOWLEVEL_INIT
-#define CONFIG_SKIP_RELOCATE_UBOOT
 #define CONFIG_DISPLAY_CPUINFO
 #define CONFIG_FIT
 
-- 
2.2.0.rc0.207.ga3a616c

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


[U-Boot] [PATCH v2] fs/ext4/ext4fs.c, fs/fs.c fs/fat/fat_write.c: Adjust 64bit math methods

2014-11-26 Thread Tom Rini
The changes to introduce loff_t into filesize means that we need to do
64bit math on 32bit platforms.  Make sure we use the right wrappers for
these operations.

Cc: Daniel Schwierzeck 
Cc: Suriyan Ramasami 
Cc: Simon Glass 
Signed-off-by: Tom Rini 
---
 fs/ext4/ext4fs.c   |   11 ++-
 fs/fat/fat_write.c |   10 ++
 fs/fs.c|6 --
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 943b5bc..258b9379 100644
--- a/fs/ext4/ext4fs.c
+++ b/fs/ext4/ext4fs.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include "ext4_common.h"
+#include 
 
 int ext4fs_symlinknest;
 struct ext_filesystem ext_fs;
@@ -67,11 +68,11 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
if (len > filesize)
len = filesize;
 
-   blockcnt = ((len + pos) + blocksize - 1) / blocksize;
+   blockcnt = lldiv(((len + pos) + blocksize - 1), blocksize);
 
-   for (i = pos / blocksize; i < blockcnt; i++) {
+   for (i = lldiv(pos, blocksize); i < blockcnt; i++) {
lbaint_t blknr;
-   int blockoff = pos % blocksize;
+   int blockoff = pos - (blocksize * i);
int blockend = blocksize;
int skipfirst = 0;
blknr = read_allocated_block(&(node->inode), i);
@@ -82,7 +83,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
 
/* Last block.  */
if (i == blockcnt - 1) {
-   blockend = (len + pos) % blocksize;
+   blockend = (len + pos) - (blocksize * i);
 
/* The last portion is exactly blocksize. */
if (!blockend)
@@ -90,7 +91,7 @@ int ext4fs_read_file(struct ext2fs_node *node, loff_t pos,
}
 
/* First block. */
-   if (i == pos / blocksize) {
+   if (i == lldiv(pos, blocksize)) {
skipfirst = blockoff;
blockend -= skipfirst;
}
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 88dd495..473723b 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "fat.c"
 
 static void uppercase(char *str, int len)
@@ -770,7 +772,7 @@ static void fill_dentry(fsdata *mydata, dir_entry *dentptr,
  */
 static int check_overflow(fsdata *mydata, __u32 clustnum, loff_t size)
 {
-   __u32 startsect, sect_num;
+   __u32 startsect, sect_num, offset;
 
if (clustnum > 0) {
startsect = mydata->data_begin +
@@ -779,13 +781,13 @@ static int check_overflow(fsdata *mydata, __u32 clustnum, 
loff_t size)
startsect = mydata->rootdir_sect;
}
 
-   sect_num = size / mydata->sect_size;
-   if (size % mydata->sect_size)
+   sect_num = div_u64_rem(size, mydata->sect_size, &offset);
+   
+   if (offset != 0)
sect_num++;
 
if (startsect + sect_num > cur_part_info.start + total_sector)
return -1;
-
return 0;
 }
 
diff --git a/fs/fs.c b/fs/fs.c
index 3da7860..52078139 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -399,7 +401,7 @@ int do_load(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[],
printf("%llu bytes read in %lu ms", len_read, time);
if (time > 0) {
puts(" (");
-   print_size(len_read / time * 1000, "/s");
+   print_size(div_u64(len_read, time * 1000), "/s");
puts(")");
}
puts("\n");
@@ -469,7 +471,7 @@ int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[],
printf("%llu bytes written in %lu ms", len, time);
if (time > 0) {
puts(" (");
-   print_size(len / time * 1000, "/s");
+   print_size(div_u64(len, time * 1000), "/s");
puts(")");
}
puts("\n");
-- 
1.7.9.5

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


[U-Boot] [PATCH 2/2] socfpga: correctly increment freeze_controller_base address

2014-11-26 Thread dinguyen
From: Dinh Nguyen 

Correctly increment the base address of the freeze controller. And since
SYSMGR_FRZCTRL_VIOCTRL_SHIFT is not needed, remove it from the include file.

Signed-off-by: Dinh Nguyen 
Cc: Vince Bridgers 
Cc: Chin Liang See 
Cc: Marek Vasut 
Cc: Pavel Machek 
Cc: Wolfgang Denk 
---
 arch/arm/cpu/armv7/socfpga/freeze_controller.c| 6 ++
 arch/arm/include/asm/arch-socfpga/freeze_controller.h | 1 -
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/socfpga/freeze_controller.c 
b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
index b8c9bce..0be643c 100644
--- a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
+++ b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
@@ -38,8 +38,7 @@ void sys_mgr_frzctrl_freeze_req(void)
/* Freeze channel 0 to 2 */
for (channel_id = 0; channel_id <= 2; channel_id++) {
ioctrl_reg_offset = (u32)(
-   &freeze_controller_base->vioctrl +
-   (channel_id << SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+   &freeze_controller_base->vioctrl + channel_id);
 
/*
 * Assert active low enrnsl, plniotri
@@ -120,8 +119,7 @@ void sys_mgr_frzctrl_thaw_req(void)
/* Thaw channel 0 to 2 */
for (channel_id = 0; channel_id <= 2; channel_id++) {
ioctrl_reg_offset
-   = (u32)(&freeze_controller_base->vioctrl
-   + (channel_id << SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+   = (u32)(&freeze_controller_base->vioctrl + channel_id);
 
/*
 * Assert active low bhniotri signal and
diff --git a/arch/arm/include/asm/arch-socfpga/freeze_controller.h 
b/arch/arm/include/asm/arch-socfpga/freeze_controller.h
index 120f20e..f19ad87 100644
--- a/arch/arm/include/asm/arch-socfpga/freeze_controller.h
+++ b/arch/arm/include/asm/arch-socfpga/freeze_controller.h
@@ -42,7 +42,6 @@ typedef enum {
 #define SYSMGR_FRZCTRL_HWCTRL_VIO1REQ_MASK 0x0001
 #define SYSMGR_FRZCTRL_HWCTRL_VIO1STATE_ENUM_FROZEN 0x2
 #define SYSMGR_FRZCTRL_HWCTRL_VIO1STATE_ENUM_THAWED 0x1
-#define SYSMGR_FRZCTRL_VIOCTRL_SHIFT 0x2
 
 void sys_mgr_frzctrl_freeze_req(void);
 void sys_mgr_frzctrl_thaw_req(void);
-- 
2.0.3

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


[U-Boot] [PATCH 1/2] socfpga: add missing struct member fifo_triple_byte

2014-11-26 Thread dinguyen
From: Dinh Nguyen 

socfpga_scan_manager structure was missing a data member.

Signed-off-by: Dinh Nguyen 
Cc: Vince Bridgers 
Cc: Chin Liang See 
Cc: Marek Vasut 
Cc: Pavel Machek 
Cc: Wolfgang Denk 
---
 arch/arm/include/asm/arch-socfpga/scan_manager.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/arch-socfpga/scan_manager.h 
b/arch/arm/include/asm/arch-socfpga/scan_manager.h
index b2686d3..1155fd3 100644
--- a/arch/arm/include/asm/arch-socfpga/scan_manager.h
+++ b/arch/arm/include/asm/arch-socfpga/scan_manager.h
@@ -13,6 +13,7 @@ struct socfpga_scan_manager {
u32 padding[2];
u32 fifo_single_byte;
u32 fifo_double_byte;
+   u32 fifo_triple_byte;
u32 fifo_quad_byte;
 };
 
-- 
2.0.3

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


[U-Boot] [PATCH 2/2] socfpga: correctly increment freeze_controller_base address

2014-11-26 Thread dinguyen
From: Dinh Nguyen 

Correctly increment the base address of the freeze controller. And since
SYSMGR_FRZCTRL_VIOCTRL_SHIFT is not needed, remove it from the include file.

Signed-off-by: Dinh Nguyen 
Cc: Vince Bridgers 
Cc: Chin Liang See 
Cc: Marek Vasut 
Cc: Pavel Machek 
Cc: Wolfgang Denk 
---
 arch/arm/cpu/armv7/socfpga/freeze_controller.c| 6 ++
 arch/arm/include/asm/arch-socfpga/freeze_controller.h | 1 -
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/socfpga/freeze_controller.c 
b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
index b8c9bce..0be643c 100644
--- a/arch/arm/cpu/armv7/socfpga/freeze_controller.c
+++ b/arch/arm/cpu/armv7/socfpga/freeze_controller.c
@@ -38,8 +38,7 @@ void sys_mgr_frzctrl_freeze_req(void)
/* Freeze channel 0 to 2 */
for (channel_id = 0; channel_id <= 2; channel_id++) {
ioctrl_reg_offset = (u32)(
-   &freeze_controller_base->vioctrl +
-   (channel_id << SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+   &freeze_controller_base->vioctrl + channel_id);
 
/*
 * Assert active low enrnsl, plniotri
@@ -120,8 +119,7 @@ void sys_mgr_frzctrl_thaw_req(void)
/* Thaw channel 0 to 2 */
for (channel_id = 0; channel_id <= 2; channel_id++) {
ioctrl_reg_offset
-   = (u32)(&freeze_controller_base->vioctrl
-   + (channel_id << SYSMGR_FRZCTRL_VIOCTRL_SHIFT));
+   = (u32)(&freeze_controller_base->vioctrl + channel_id);
 
/*
 * Assert active low bhniotri signal and
diff --git a/arch/arm/include/asm/arch-socfpga/freeze_controller.h 
b/arch/arm/include/asm/arch-socfpga/freeze_controller.h
index 120f20e..f19ad87 100644
--- a/arch/arm/include/asm/arch-socfpga/freeze_controller.h
+++ b/arch/arm/include/asm/arch-socfpga/freeze_controller.h
@@ -42,7 +42,6 @@ typedef enum {
 #define SYSMGR_FRZCTRL_HWCTRL_VIO1REQ_MASK 0x0001
 #define SYSMGR_FRZCTRL_HWCTRL_VIO1STATE_ENUM_FROZEN 0x2
 #define SYSMGR_FRZCTRL_HWCTRL_VIO1STATE_ENUM_THAWED 0x1
-#define SYSMGR_FRZCTRL_VIOCTRL_SHIFT 0x2
 
 void sys_mgr_frzctrl_freeze_req(void);
 void sys_mgr_frzctrl_thaw_req(void);
-- 
2.0.3

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


[U-Boot] [PATCH 1/2] socfpga: add missing struct member fifo_triple_byte

2014-11-26 Thread dinguyen
From: Dinh Nguyen 

socfpga_scan_manager structure was missing a data member.

Signed-off-by: Dinh Nguyen 
Cc: Vince Bridgers 
Cc: Chin Liang See 
Cc: Marek Vasut 
Cc: Pavel Machek 
Cc: Wolfgang Denk 
---
 arch/arm/include/asm/arch-socfpga/scan_manager.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/arch-socfpga/scan_manager.h 
b/arch/arm/include/asm/arch-socfpga/scan_manager.h
index b2686d3..1155fd3 100644
--- a/arch/arm/include/asm/arch-socfpga/scan_manager.h
+++ b/arch/arm/include/asm/arch-socfpga/scan_manager.h
@@ -13,6 +13,7 @@ struct socfpga_scan_manager {
u32 padding[2];
u32 fifo_single_byte;
u32 fifo_double_byte;
+   u32 fifo_triple_byte;
u32 fifo_quad_byte;
 };
 
-- 
2.0.3

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


Re: [U-Boot] [PATCH V2] cmd_i2c: Provide option for bulk 'i2c write' in one transaction

2014-11-26 Thread Simon Glass
Hi Lubomir,

On 26 November 2014 at 05:47, Lubomir Popov  wrote:
> I2C chips do exist that require a write of some multi-byte data to occur in
> a single bus transaction (aka atomic transfer), otherwise either the write
> does not come into effect at all, or normal operation of internal circuitry
> cannot be guaranteed. The current implementation of the 'i2c write' command
> (transfer of multiple bytes from a memory buffer) in fact performs a separate
> transaction for each byte to be written and thus cannot support such types of
> I2C slave devices.
>
> This patch provides an alternative by allowing 'i2c write' to execute the
> write transfer of the given number of bytes in a single bus transaction if
> the '-s' option is specified as a final command argument. Else the current
> re-addressing method is used.
>
> Signed-off-by: Lubomir Popov 

Reviewed-by: Simon Glass

(see possible nit below)

> ---
> Changes in V2:
> The option to use bulk transfer vs re-addressing is implemented as a run-time
> command argument and shall better fit into the new I2C DM (thanks to Simon for
> the hint). V1 used conditional compilation through a board header definition.
>
>  common/cmd_i2c.c |   35 +--
>  1 file changed, 25 insertions(+), 10 deletions(-)
>
> diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
> index c266b88..5cb7dca 100644
> --- a/common/cmd_i2c.c
> +++ b/common/cmd_i2c.c
> @@ -270,7 +270,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[
> uintdevaddr, alen, length;
> u_char  *memaddr;
>
> -   if (argc != 5)
> +   if ((argc < 5) || (argc > 6))
> return cmd_usage(cmdtp);
>
> /*
> @@ -293,20 +293,34 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int 
> argc, char * const argv[
> return cmd_usage(cmdtp);
>
> /*
> -* Length is the number of objects, not number of bytes.
> +* Length is the number of bytes.
>  */
> length = simple_strtoul(argv[4], NULL, 16);
> -
> -   while (length-- > 0) {
> -   if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0) {
> +
> +   if (argc == 6 && !strcmp(argv[5], "-s")) {
> +   /*
> +* Write all bytes in a single I2C transaction. If the target
> +* device is an EEPROM, it is your responsibility to not cross
> +* a page boundary. No write delay upon completion, take this
> +* into account if linking commands.
> +*/
> +   if (i2c_write(chip, devaddr, alen, memaddr, length) != 0)
> return i2c_report_err(-1, I2C_ERR_WRITE);
> -   }
> +   } else {
> +   /*
> +* Repeated addressing - perform  separate
> +* write transactions of one byte each
> +*/
> +   while (length-- > 0) {
> +   if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 
> 0)
> +   return i2c_report_err(-1, I2C_ERR_WRITE);
>  /*
>   * No write delay with FRAM devices.
>   */

Should this be indented?

>  #if !defined(CONFIG_SYS_I2C_FRAM)
> -   udelay(11000);
> +   udelay(11000);
>  #endif
> +   }
> }
> return 0;
>  }
> @@ -1559,7 +1573,7 @@ static cmd_tbl_t cmd_i2c_sub[] = {
> U_BOOT_CMD_MKENT(nm, 2, 1, do_i2c_nm, "", ""),
> U_BOOT_CMD_MKENT(probe, 0, 1, do_i2c_probe, "", ""),
> U_BOOT_CMD_MKENT(read, 5, 1, do_i2c_read, "", ""),
> -   U_BOOT_CMD_MKENT(write, 5, 0, do_i2c_write, "", ""),
> +   U_BOOT_CMD_MKENT(write, 6, 0, do_i2c_write, "", ""),
> U_BOOT_CMD_MKENT(reset, 0, 1, do_i2c_reset, "", ""),
>  #if defined(CONFIG_CMD_SDRAM)
> U_BOOT_CMD_MKENT(sdram, 1, 1, do_sdram, "", ""),
> @@ -1623,7 +1637,8 @@ static char i2c_help_text[] =
> "i2c nm chip address[.0, .1, .2] - write to I2C device (constant 
> address)\n"
> "i2c probe [address] - test for and show device(s) on the I2C bus\n"
> "i2c read chip address[.0, .1, .2] length memaddress - read to memory 
> \n"
> -   "i2c write memaddress chip address[.0, .1, .2] length - write memory 
> to i2c\n"
> +   "i2c write memaddress chip address[.0, .1, .2] length [-s] - write 
> memory\n"
> +   "  to I2C; the -s option selects bulk write in a single 
> transaction\n"
> "i2c reset - re-init the I2C Controller\n"
>  #if defined(CONFIG_CMD_SDRAM)
> "i2c sdram chip - print SDRAM configuration information\n"
> @@ -1632,7 +1647,7 @@ static char i2c_help_text[] =
>  #endif
>
>  U_BOOT_CMD(
> -   i2c, 6, 1, do_i2c,
> +   i2c, 7, 1, do_i2c,
> "I2C sub-system",
> i2c_help_text
>  );
> --
> 1.7.9.5
>

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

Re: [U-Boot] [PATCH] sata: fix reset_sata for dwc_ahsata

2014-11-26 Thread Nikita Kiryanov

Hi Soeren,

On 11/26/2014 01:40 PM, Soeren Moch wrote:

- fix crash when sata device is not initialized
- remove disable_sata_clock() since it is not clear which clock for which
   device should be disabled here
- call disable_sata_clock() for mx6 in preboot_os instead

Signed-off-by: Soeren Moch 
---
Cc: Tom Rini 
Cc: Nikita Kiryanov 
Cc: Simon Glass 
Cc: guillaume.gar...@free.fr
Cc: Stefano Babic 
---
  arch/arm/imx-common/cpu.c  |  3 +++
  drivers/block/dwc_ahsata.c | 14 --
  2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index b58df7d..28ccd29 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -206,6 +206,9 @@ void arch_preboot_os(void)
  {
  #if defined(CONFIG_CMD_SATA)
sata_stop();
+#if defined(CONFIG_MX6)
+   disable_sata_clock();
+#endif


I think a more proper way to do this might be to mirror the
init sequence completely. The simplest init sequence calls
setup_sata() somewhere before sata_initialize() is invoked,
and the distribution of labor is:
- arch/arm/imx-common/sata.c:setup_sata() Turns on clocks
- common/cmd_sata.c: sata_initialize() Calls driver init

The inverse would be:
- common/cmd_sata.c: sata_stop() Calls driver reset
- arch/arm/imx-common/sata.c:disable_sata() Turns off clocks

Thus disable_sata() would need to be defined in
arch/arm/imx-common/sata.c; it will call disable_sata_clock(),
and be used in cm_fx6's version of stop_sata().

It's a little convoluted, but consistent with the existing code
flow, and it also fixes the MX53 problems because
arch/arm/imx-common/sata.c is not compiled for this platform.


  #endif
  #if defined(CONFIG_VIDEO_IPUV3)
/* disable video before launching O/S */
diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
index 9a2b547..9e925d1 100644
--- a/drivers/block/dwc_ahsata.c
+++ b/drivers/block/dwc_ahsata.c
@@ -594,22 +594,24 @@ int init_sata(int dev)

  int reset_sata(int dev)
  {
-   struct ahci_probe_ent *probe_ent =
-   (struct ahci_probe_ent *)sata_dev_desc[dev].priv;
-   struct sata_host_regs *host_mmio =
-   (struct sata_host_regs *)probe_ent->mmio_base;
+   struct ahci_probe_ent *probe_ent;
+   struct sata_host_regs *host_mmio;

if (dev < 0 || dev > (CONFIG_SYS_SATA_MAX_DEVICE - 1)) {
printf("The sata index %d is out of ranges\n\r", dev);
return -1;
}

+   probe_ent = (struct ahci_probe_ent *)sata_dev_desc[dev].priv;
+   if (NULL == probe_ent)
+   /* not initialized, so nothing to reset */
+   return 0;
+
+   host_mmio = probe_ent->mmio_base;


The lack of casting generates a warning during compilation:
drivers/block/dwc_ahsata.c:610:12: warning: assignment makes pointer 
from integer without a cast [enabled by default]

  host_mmio = probe_ent->mmio_base;
^


setbits_le32(&host_mmio->ghc, SATA_HOST_GHC_HR);
while (readl(&host_mmio->ghc) & SATA_HOST_GHC_HR)
udelay(100);

-   disable_sata_clock();
-
return 0;
  }




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


Re: [U-Boot] [PATCH v2 01/12] spi/ich.c: Fix a bug of reading from a non-64 bytes aligned address

2014-11-26 Thread Simon Glass
Hi Jagan,

On 26 November 2014 at 09:43, Jagan Teki  wrote:
> On 26 November 2014 at 21:33, Simon Glass  wrote:
>> Hi Jagan,
>>
>> On 24 November 2014 at 20:13, Bin Meng  wrote:
>>> Hi Simon
>>>
>>> On Tue, Nov 25, 2014 at 11:10 AM, Simon Glass  wrote:
 Hi,

 On 1 November 2014 at 02:53, Bin Meng  wrote:
> The ich spi controller driver spi_xfer() tries to align reading
> address to 64 bytes when doing spi data in, which causes a bug of
> either infinite loop or a huge size memcpy().
>
> Actually the ich spi controller does not have such requirement of
> 64 bytes alignment when reading data from spi slave devices.
>
> Signed-off-by: Bin Meng 
> Acked-by: Simon Glass 
> Tested-by: Simon Glass 
> ---
>  drivers/spi/ich.c | 17 ++---
>  1 file changed, 2 insertions(+), 15 deletions(-)

 Any update on this series?

 If the series is acceptable I could bring it in through the x86 tree
 since it relates to that SPI controller.

>>>
>>> Thanks for tracking this series. I was asking the same question to
>>> Jagan yesterday.
>>
>> Let me know if you want to pull this through the SPI tree, otherwise
>> I'll go ahead (iwc I'll need to test once more first).
>
> This series change the sf generic code stuff, I will send my review comments.
> Please hold on this, once everything goes fine I will pick.

Sounds good, thanks. Let me know if you want me to test again as a lot
has changed since this series was sent.

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


Re: [U-Boot] Export redesign

2014-11-26 Thread Simon Glass
+avr32 maintainer

Hi,

On 26 November 2014 at 01:07, Martin Dorwig  wrote:
> Hello,
> while trying to eliminate the XF_xxx enums, i came to a point in
> examples/standalone/stubs.c
> In the definition of EXPORT_FUNC for CONFIG_AVR32
> the XF_ ##x is not multiplied with sizeof(void*) .
> Is this a bug or a avr feature ?
>

I know nothing about this arch, but I found this link which suggests
that the shift is implicit for the ld.w instruction:

http://www.avrfreaks.net/forum/ldw-instruction-syntax

So probably it is correct as is.

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


Re: [U-Boot] [PATCH] fs/ext4/ext4fs.c, fs/fs.c: Use lldiv and multiplication / subtraction on 64bit ops

2014-11-26 Thread Tom Rini
On Tue, Nov 25, 2014 at 02:45:33PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On 24 November 2014 at 12:55, Simon Glass  wrote:
> > On 24 November 2014 at 09:55, Tom Rini  wrote:
> >> In some cases we need to do math on 64bit quantities.  We need to be
> >> using lldiv in these cases rather than letting the compiler do it.  In
> >> addition we need to avoid doing % operations on these same quantities.
> >> These changes fix compilation on MIPS/MIPSEL.
> >>
> >> Cc: Daniel Schwierzeck 
> >> Cc: Suriyan Ramasami 
> >> Cc: Simon Glass 
> >> Signed-off-by: Tom Rini 
> >
> > Reviewed-by: Simon Glass 
> 
> I'm not sure this goes far enough. I am still seeing problems even
> with this patch, e.g. for pm9g45:

Indeed it's not.  I'll post a V2 soon, I've figured out the places I
missed but need to step out now.

-- 
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 01/12] spi/ich.c: Fix a bug of reading from a non-64 bytes aligned address

2014-11-26 Thread Jagan Teki
On 26 November 2014 at 21:33, Simon Glass  wrote:
> Hi Jagan,
>
> On 24 November 2014 at 20:13, Bin Meng  wrote:
>> Hi Simon
>>
>> On Tue, Nov 25, 2014 at 11:10 AM, Simon Glass  wrote:
>>> Hi,
>>>
>>> On 1 November 2014 at 02:53, Bin Meng  wrote:
 The ich spi controller driver spi_xfer() tries to align reading
 address to 64 bytes when doing spi data in, which causes a bug of
 either infinite loop or a huge size memcpy().

 Actually the ich spi controller does not have such requirement of
 64 bytes alignment when reading data from spi slave devices.

 Signed-off-by: Bin Meng 
 Acked-by: Simon Glass 
 Tested-by: Simon Glass 
 ---
  drivers/spi/ich.c | 17 ++---
  1 file changed, 2 insertions(+), 15 deletions(-)
>>>
>>> Any update on this series?
>>>
>>> If the series is acceptable I could bring it in through the x86 tree
>>> since it relates to that SPI controller.
>>>
>>
>> Thanks for tracking this series. I was asking the same question to
>> Jagan yesterday.
>
> Let me know if you want to pull this through the SPI tree, otherwise
> I'll go ahead (iwc I'll need to test once more first).

This series change the sf generic code stuff, I will send my review comments.
Please hold on this, once everything goes fine I will pick.

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


[U-Boot] Please pull u-boot-x86.git

2014-11-26 Thread Simon Glass
Hi Tom,

This is the last of the bare x86 support for this release. I also
brought in some interrupt fixes from Bin.



The following changes since commit 2a82ec77d27ef5f860a107c4b764643a655dceeb:

  Prepare v2015.01-rc2 (2014-11-24 17:08:47 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-x86.git

for you to fetch changes up to 908ec6e4d1d12f746cb9b7cc73430a268ceb2c92:

  tools: Add ifdtool to .gitignore (2014-11-25 07:11:17 -0700)


Bin Meng (5):
  x86: Call cpu_init_interrupts() from interrupt_init()
  x86: Remove cpu_init_r() for x86
  x86: Refactor interrupt_init()
  x86: Remove unnecessary call to initr_enable_interrupts()
  tools: Add ifdtool to .gitignore

Simon Glass (51):
  x86: Add ivybridge directory to Makefile
  Fix SIZE_MAX compiler warning when using stdint.h
  Align embedded device tree correctly
  pci: Update pci_ids.h to include some missing IDs
  x86: Remove board_early_init_r()
  x86: Panic if there is no relocation data
  x86: Ensure that all relocation data is included in the image
  x86: Factor out common values in the link script
  rtc: mc146818: Set up RTC at start of day
  x86: Add ioapic.h header
  x86: pci: Add handlers before and after a PCI hose scan
  x86: config: Enable plug-and-play for link PCI
  pci: Add functions to read and write a BAR address
  x86: Set up edge triggering on interrupt 9
  x86: ivybridge: Add support for BD82x6x PCH
  x86: Add a simple header file for ACPI
  x86: ivybridge: Add PCH init
  x86: ivybridge: Add additional LPC init
  x86: dts: Move PCI peripherals into a pci node
  x86: dts: Add LPC settings for link
  x86: ivybridge: Add SATA init
  x86: dts: Add SATA settings for link
  x86: ivybridge: Set up EHCI USB
  x86: config: Enable USB on link
  x86: ivybridge: Set up XHCI USB
  x86: Add Intel speedstep and turbo mode code
  x86: Drop old CONFIG_INTEL_CORE_ARCH code
  x86: Add LAPIC setup code
  x86: Add init for model 206AX CPU
  x86: Drop some msr functions that we don't support
  x86: ivybridge: Add northbridge init functions
  x86: config: Enable SPI for chromebook_link
  x86: Add a definition of asmlinkage
  Introduce a header file for the BIOS emulator
  x86: Add GDT descriptors for option ROMs
  x86: Add vesa mode configuration options
  Add support for Vesa BIOS extensions
  x86: Add support for running option ROMs natively
  pci: Add general support for execution of video ROMs
  x86: video: Add video driver for bare x86 boards
  x86: Allow an option ROM to be built into U-Boot
  x86: Add initial video device init for Intel GMA
  x86: dts: Add video information to the device tree
  x86: config: Enable video support for chromebook_link
  bios_emulator: Allow x86 to use the emulator
  bios_emulator: Add vesa support and allow ROMs to be passed in as data
  bios_emulator: Allow a custom interrupt handler to be installed
  bios_emulator: Add an option to enable debugging
  bios_emulator: Always print errors when opcode decode fails
  x86: chromebook_link: Enable the x86 emulator
  x86: chromebook_link: Enable the Chrome OS EC

 Makefile  |   3 +
 arch/x86/Kconfig  | 149 +++
 arch/x86/cpu/Makefile |   4 +
 arch/x86/cpu/config.mk|   5 +-
 arch/x86/cpu/coreboot/coreboot.c  |  11 --
 arch/x86/cpu/cpu.c|  17 +-
 arch/x86/cpu/interrupts.c |  54 ++
 arch/x86/cpu/ivybridge/Makefile   |   8 +
 arch/x86/cpu/ivybridge/bd82x6x.c  | 146 +++
 arch/x86/cpu/ivybridge/gma.c  | 756
++
 arch/x86/cpu/ivybridge/gma.h  | 156 
 arch/x86/cpu/ivybridge/lpc.c  | 523
++-
 arch/x86/cpu/ivybridge/model_206ax.c  | 514
++
 arch/x86/cpu/ivybridge/northbridge.c  | 188 +++
 arch/x86/cpu/ivybridge/pch.c  | 123 
 arch/x86/cpu/ivybridge/pci.c  |  40 
 arch/x86/cpu/ivybridge/sata.c | 225 ++
 arch/x86/cpu/ivybridge/usb_ehci.c |  29 +++
 arch/x86/cpu/ivybridge/usb_xhci.c |  32 
 arch/x86/cpu/lapic.c  |  57 ++
 arch/x86/cpu/pci.c|  12 ++
 arch/x86/cpu/turbo.c  |  98 ++
 arch/x86/cpu/u-boot.lds

Re: [U-Boot] Please pull u-boot-mpc85xx

2014-11-26 Thread Tom Rini
On Tue, Nov 25, 2014 at 09:36:34AM -0800, York Sun wrote:

> Tom,
> 
> The following changes since commit f196044dfd64745a163773c6c746f9e149ace127:
> 
>   ARM: atmel: add sama5d4 xplained ultra board support (2014-11-17 08:47:18 
> -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mpc85xx.git master
> 
> for you to fetch changes up to 3b4b9a3377d6e7cba6060497b02644f9ff2ac67a:
> 
>   mmc: fsl_esdhc: fix f_max retrieval during init (2014-11-19 18:17:12 -0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] please pull u-boot-fsl-qoriq

2014-11-26 Thread Tom Rini
On Tue, Nov 25, 2014 at 09:37:19AM -0800, York Sun wrote:

> Tom,
> 
> The following changes since commit f196044dfd64745a163773c6c746f9e149ace127:
> 
>   ARM: atmel: add sama5d4 xplained ultra board support (2014-11-17 08:47:18 
> -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fsl-qoriq.git master
> 
> for you to fetch changes up to 0ab172353e14dbdb7278755de6feae3fc4b54c2f:
> 
>   arm: ls102xa: Select ge2_clk125 for eTSEC clock muxing (2014-11-24 09:27:24 
> -0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Please pull u-boot-sunxi master

2014-11-26 Thread Tom Rini
On Wed, Nov 26, 2014 at 10:20:44AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 11/25/2014 10:52 PM, Tom Rini wrote:
> >On Tue, Nov 25, 2014 at 10:52:21AM -0700, Simon Glass wrote:
> >>Hi Tom,
> >>
> >>On 25 November 2014 at 05:45, Hans de Goede  wrote:
> >>>Hi Tom,
> >>>
> >>>Please pull u-boot-sunxi/master into master, highlights:
> >>>
> >>>1) hdmi console (with usb keyboard) support with simplefb support so the
> >>>kernel
> >>>can use the framebuffer too
> >>>2) GMAC support for sun6i
> >>>3) A couple of small bugfixes
> >>>
> >>>Note I've done a rebase + forced-push, as things were becoming a bit messy
> >>>while merging.
> >>>
> >>>The following changes since commit 
> >>>2a82ec77d27ef5f860a107c4b764643a655dceeb:
> >>>
> >>>   Prepare v2015.01-rc2 (2014-11-24 17:08:47 -0500)
> >>>
> >>>are available in the git repository at:
> >>>
> >>>   http://git.denx.de/u-boot-sunxi.git master
> >>>
> >>>for you to fetch changes up to b366fb92c3d118f97bb0f01fa9c40d253e70e12c:
> >>>
> >>>   sun7i: Set ARMV7_BOOT_SEC_DEFAULT when OLD_SUNXI_KERNEL_COMPAT is set
> >>>(2014-11-25 13:38:46 +0100)
> >>>
> >>>
> >>>Hans de Goede (12):
> >>>   sun4i: Rename dram_clk_cfg to dram_clk_gate
> >>>   sunxi: Add video pll clock functions
> >>>   sunxi: video: Add sun6i support
> >>>   fdt_support: Add a fdt_setup_simplefb_node helper function
> >>>   common/lcd: Make lcd_dt_simplefb_configure_node use
> >>>fdt_setup_simplefb_node
> >>>   sunxi: Add usb keyboard Kconfig option
> >>>   sunxi: ahci: Add a delay after enabling target power
> >>>   sun6i: Correct Mele M9 Vbus gpio settings
> >>>   sun6i: Add gmac support for sun6i boards
> >>>   sun6i: Drop some "unknown magic" from dram init
> >>>   sun7i: Drop CONFIG_ARMV7_PSCI_NR_CPUS
> >>>   sun7i: Set ARMV7_BOOT_SEC_DEFAULT when OLD_SUNXI_KERNEL_COMPAT is 
> >>> set
> >>
> >>The u-boot-fdt pull request is pending. I think it might have a slight
> >>conflict with this one, so I'll wait until this goes in and then
> >>resend the fdt pull request.
> >
> >I _think_ I resolved the conflict right.
> 
> Hmm, I'm not seeing any changes if I do a "git remote update" did you perhaps
> forget to push things ?

Ah sorry.  To be clear, I was testing things at the time :)

-- 
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] spl: Fix SPL EXT support

2014-11-26 Thread Tom Rini
On Tue, Nov 25, 2014 at 03:34:16PM +0100, Guillaume GARDET wrote:

> Commit 9f12cd0e062614e19734b2ab37842d387457c5e5 has broken SPL EXT support.
> This patch update error code check to get SPL EXT support working again.
> 
> Tested on a Pandaboard (rev. A3).
> 
> Signed-off-by: Guillaume GARDET 
> Cc: Tom Rini 
> Cc: Suriyan Ramasami 
> 

Applied to u-boot/master (and added Reviewed-by tags), thanks!

-- 
Tom


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


Re: [U-Boot] [ANN] U-Boot v2015.01-rc2 released

2014-11-26 Thread Tom Rini
On Tue, Nov 25, 2014 at 09:51:17AM +0100, Hans de Goede wrote:

> Hi Tom,
> 
> On 11/24/2014 11:13 PM, Tom Rini wrote:
> >Hey all,
> >
> >I've pushed v2015.01-rc2 out to the repository and tarballs should exist
> >soon.
> >
> >I'm tagging later in the day than I wanted to, but that's OK.
> >
> >There's a fair number of things that've gone in since -rc1, but I think
> >that's OK.  And there's a few things that still need to go in.
> >
> >For example, I just pushed the changes to allow bigger files to be read
> >but that's broken MIPS+private libgcc and ARM+hf toolchain and others
> >too.  I posted a patch for this and tested it locally with a 32MB file
> >but I'd like others to review too (Thanks Simon!) before pushing it in.
> >
> >As always, if anything else is broken please speak up.
> 
> First of all thanks for your hard work in this!
> 
> Unfortunately you've missed this pull-req (from Nov 20th) :
> 
> http://patchwork.ozlabs.org/patch/412865/
> 
> I also have some fixed queued up on top in the mean time, some of
> which may just as well be squashed in now. So I'll do a rebase, add
> the fixes and then do a new pull-req.

Sorry about that.  I was going to pull that and then ran into the
fallout from the loff_t patches and forgot about it when I went off to
pick up PRs.

-- 
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] please pull u-boot-samsung master

2014-11-26 Thread Tom Rini
On Tue, Nov 25, 2014 at 09:28:56PM +0900, Minkyu Kang wrote:

> Dear Tom,
> 
> The following changes since commit 2086e388d56cbb0e3737a6276f04f00f74bf6723:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-11-14 
> 16:39:32 -0500)
> 
> are available in the git repository at:
> 
> 
>   http://git.denx.de/u-boot-samsung 
> 
> for you to fetch changes up to 7741c8b8c9215c6def36f24ac0b2d71543dd47ab:
> 
>   ORIGEN: Enhance origen config to be more flexible on boot. (2014-11-25 
> 10:30:25 +0900)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Please pull u-boot-sunxi master

2014-11-26 Thread Tom Rini
On Tue, Nov 25, 2014 at 01:45:10PM +0100, Hans de Goede wrote:

> Hi Tom,
> 
> Please pull u-boot-sunxi/master into master, highlights:
> 
> 1) hdmi console (with usb keyboard) support with simplefb support so the 
> kernel
>can use the framebuffer too
> 2) GMAC support for sun6i
> 3) A couple of small bugfixes
> 
> Note I've done a rebase + forced-push, as things were becoming a bit messy
> while merging.
> 
> The following changes since commit 2a82ec77d27ef5f860a107c4b764643a655dceeb:
> 
>   Prepare v2015.01-rc2 (2014-11-24 17:08:47 -0500)
> 
> are available in the git repository at:
> 
>   http://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to b366fb92c3d118f97bb0f01fa9c40d253e70e12c:
> 
>   sun7i: Set ARMV7_BOOT_SEC_DEFAULT when OLD_SUNXI_KERNEL_COMPAT is set 
> (2014-11-25 13:38:46 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] Please pull u-boot-fdt.git

2014-11-26 Thread Tom Rini
On Fri, Nov 21, 2014 at 05:47:17AM +0100, Simon Glass wrote:

> Hi Tom,
> 
> I should probably get this in while we sort out the final patch. It
> affects a lot of boards. There may be a conflict when this patch is
> respun (ft_board_setup() will need to return an error code):
> 
> http://patchwork.ozlabs.org/patch/412392/
> 
> but I'll try to get in first.
> 
> 
> The following changes since commit 4d70b34d7f721d8b1d4d628e68c3a44ab7a10dff:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-ubi (2014-11-19
> 23:18:29 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fdt.git
> 
> for you to fetch changes up to 933cdbb479aa87dcb6e3e333c3d1e04b0e7de1ec:
> 
>   fdt: Try to use fdt_address_cells()/fdt_size_cells() (2014-11-21
> 04:43:18 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v1] exynos: Fix file system defines

2014-11-26 Thread Suriyan Ramasami
Hello Ian.

On Wed, Nov 26, 2014 at 1:38 AM, Ian Campbell  wrote:
> On Tue, 2014-11-25 at 09:41 -0800, Suriyan Ramasami wrote:
>> On the odroid, files in an ext4 file system were not being accessed.
>> Correct the #defines to take care of this.
>
> In u-boot-samsung.git#master since a bunch of this stuff has changed, in
> particular include/configs/exynos-common.h uses config_distro_defaults.h
> which I think provides most of what you've added here.
>

Thank you for your note.
You are right. I checked again and it works (u-boot-samsung master).
Somehow, I recall it to be not working. Nonetheless, it works now.

This patch can be RIP in software heaven.

Thanks
- Suriyan

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


Re: [U-Boot] [PATCH v2 01/12] spi/ich.c: Fix a bug of reading from a non-64 bytes aligned address

2014-11-26 Thread Simon Glass
Hi Jagan,

On 24 November 2014 at 20:13, Bin Meng  wrote:
> Hi Simon
>
> On Tue, Nov 25, 2014 at 11:10 AM, Simon Glass  wrote:
>> Hi,
>>
>> On 1 November 2014 at 02:53, Bin Meng  wrote:
>>> The ich spi controller driver spi_xfer() tries to align reading
>>> address to 64 bytes when doing spi data in, which causes a bug of
>>> either infinite loop or a huge size memcpy().
>>>
>>> Actually the ich spi controller does not have such requirement of
>>> 64 bytes alignment when reading data from spi slave devices.
>>>
>>> Signed-off-by: Bin Meng 
>>> Acked-by: Simon Glass 
>>> Tested-by: Simon Glass 
>>> ---
>>>  drivers/spi/ich.c | 17 ++---
>>>  1 file changed, 2 insertions(+), 15 deletions(-)
>>
>> Any update on this series?
>>
>> If the series is acceptable I could bring it in through the x86 tree
>> since it relates to that SPI controller.
>>
>
> Thanks for tracking this series. I was asking the same question to
> Jagan yesterday.

Let me know if you want to pull this through the SPI tree, otherwise
I'll go ahead (iwc I'll need to test once more first).

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


Re: [U-Boot] [PATCH] spl: Fix SPL EXT support

2014-11-26 Thread Simon Glass
Hi,

On 25 November 2014 at 12:55, Suriyan Ramasami  wrote:
> Hello Guillaume GARDET,
>
>
> On Tue, Nov 25, 2014 at 6:34 AM, Guillaume GARDET
>  wrote:
>> Commit 9f12cd0e062614e19734b2ab37842d387457c5e5 has broken SPL EXT support.
>> This patch update error code check to get SPL EXT support working again.
>>
>> Tested on a Pandaboard (rev. A3).
>>
>> Signed-off-by: Guillaume GARDET 
>> Cc: Tom Rini 
>> Cc: Suriyan Ramasami 
>>
>> ---
>>  common/spl/spl_ext.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/common/spl/spl_ext.c b/common/spl/spl_ext.c
>> index 5ff9bc5..9d37fd3 100644
>> --- a/common/spl/spl_ext.c
>> +++ b/common/spl/spl_ext.c
>> @@ -43,7 +43,7 @@ int spl_load_image_ext(block_dev_desc_t *block_dev,
>> goto end;
>> }
>> err = ext4fs_read((char *)header, sizeof(struct image_header), 
>> &actlen);
>> -   if (err <= 0) {
>> +   if (err < 0) {
>> puts("spl: ext4fs_read failed\n");
>> goto end;
>> }
>> @@ -54,12 +54,12 @@ int spl_load_image_ext(block_dev_desc_t *block_dev,
>>
>>  end:
>>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>> -   if (err <= 0)
>> +   if (err < 0)
>> printf("%s: error reading image %s, err - %d\n",
>>__func__, filename, err);
>>  #endif
>>
>> -   return err <= 0;
>> +   return err < 0;
>>  }
>>
>>  #ifdef CONFIG_SPL_OS_BOOT
>> @@ -95,7 +95,7 @@ int spl_load_image_ext_os(block_dev_desc_t *block_dev, int 
>> partition)
>> goto defaults;
>> }
>> err = ext4fs_read((void *)CONFIG_SYS_SPL_ARGS_ADDR, filelen, 
>> &actlen);
>> -   if (err <= 0) {
>> +   if (err < 0) {
>> printf("spl: error reading image %s, err - %d, 
>> falling back to default\n",
>>file, err);
>> goto defaults;
>> @@ -124,7 +124,7 @@ defaults:
>> puts("spl: ext4fs_open failed\n");
>>
>> err = ext4fs_read((void *)CONFIG_SYS_SPL_ARGS_ADDR, filelen, 
>> &actlen);
>> -   if (err <= 0) {
>> +   if (err < 0) {
>>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>> printf("%s: error reading image %s, err - %d\n",
>>__func__, CONFIG_SPL_FS_LOAD_ARGS_NAME, err);
>> --
>> 1.8.4.5
>>
>
> I am not sure, if I can put a "Reviewed-by" here, but it does look good to me.
> Thanks
> - Suriyan

Yes you can - but it needs to be in the right format. You can reply on
the thread with 'Reviewed-by:  '

Reviewed-by: Simon Glass 

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


Re: [U-Boot] [PATCH v3 8/8] Fix SIZE_MAX compiler warning when using stdint.h

2014-11-26 Thread Simon Glass
Hi Masahiro,

On 26 November 2014 at 00:49, Masahiro Yamada  wrote:
> Simon,
>
> I am not happy about this because my intention was
> to sync  with that of Linux as much as possible.
>
> I have posted a new thread for open discussion
> because I doubt if USE_STDINT is a good idea.
>

OK, let's discuss on the other thread.

- Simon

>
>
> On Tue, 25 Nov 2014 14:47:22 -0700
> Simon Glass  wrote:
>
>> +Masahiro
>>
>> On 24 November 2014 at 21:18, Simon Glass  wrote:
>> > This new symbol may be defined by the compiler. If it is, avoid a compiler
>> > warning when USE_STDINT is defined.
>> >
>> > Signed-off-by: Simon Glass 
>> > ---
>> >
>> > Changes in v3:
>> > - Add new patch to fix SIZE_MAX compiler warning when using stdint.h
>> >
>> > Changes in v2: None
>> >
>> >  include/linux/kernel.h | 2 ++
>> >  1 file changed, 2 insertions(+)
>>
>> Applied to u-boot-x86.
>
> Best Regards
> Masahiro Yamada
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Tegra board problems

2014-11-26 Thread Simon Glass
Hi Stephen,

On 25 November 2014 at 09:25, Stephen Warren  wrote:
>
> On 11/25/2014 09:16 AM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 25 November 2014 at 09:11, Stephen Warren  wrote:
>>>
>>> On 11/24/2014 09:03 PM, Simon Glass wrote:


 Hi,

 I'm a bit messed up with my testing now.
>>>
>>>
>>> ...


 2. beaver: I cannot get mainline U-Boot to boot a kernel. In fact
 'part list mmc 0' just prints an error:

 ## Unknown partition table

 It is getting a partition ID of 0. Is there something wrong with
 Beaver's mmc support in mainline?
>>>
>>>
>>>
>>> I just built commit 2a82ec77d27e "Prepare v2015.01-rc2" and both eMMC and SD
>>> appear to work.
>>>
>>> Do you have a valid partition table on the eMMC? If you installed L4T there
>>> rather than partitioning it yourself, note that L4T uses a non-standard
>>> "tegra PT" partition table format. Some newer versions of L4T also include a
>>> backup GPT that makes some of the partitions available in a more standard
>>> way, but IIUC there's never a primary GPT. I don't recall if the version of
>>> L4T for Beaver was new enough to do even that though. Your best bet is to
>>> use standard tools to install a complete GPT and then install a Linux distro
>>> on top of that.
>>>
>>> Tegra30 (Beaver) # part list mmc 0
>>>
>>> Partition Map for MMC device 0  --   Partition Type: EFI
>>>
>>> PartStart LBA   End LBA Name
>>>  Attributes
>>>  Type GUID
>>>  Partition GUID
>>>1 0x0800  0x01da97ff  ""
>>>  attrs:  0x
>>>  type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>>>  guid:   ac3c736e-a29b-43d4-9819-4cf4fd84c3b0
>>>
>>> Tegra30 (Beaver) # part list mmc 1
>>>
>>> Partition Map for MMC device 1  --   Partition Type: EFI
>>>
>>> PartStart LBA   End LBA Name
>>>  Attributes
>>>  Type GUID
>>>  Partition GUID
>>>1 0x0022  0x003b9132  ""
>>>  attrs:  0x
>>>  type:   ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
>>>  guid:   b2f82cda-2535-4779-b467-094a210fbae7
>>>
>>
>> OK thank you, that could be my problem. I'll try installing a new GPT.
>>
>> Will try out the Jetson and see if I can get it running again. So does
>> that mean as shipped it runs an Android boot loader and then jumps to
>> U-Boot?
>
>
> It probably depends on which L4T release you have.
>
> I think the following is accurate:
>
> The first L4T releases for Jetson may have only supported the Android boot 
> loader.
>
> A later release certainly supported either the Android boot loader or U-Boot. 
> You had to choose which to install at flashing time. The Android boot loader 
> is/was the default, and is/was what is installed at the factory. In either 
> case, there's no chain-loading of boot loaders, simply a choice of which to 
> put into flash.
>
> I believe the latest release only contains U-Boot, or perhaps supports both 
> with U-Boot as the default, but I haven't validated that, nor whether it's 
> actually shipped yet.

Thanks for the info, very helpful.

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


Re: [U-Boot] sunxi: CPU disabling

2014-11-26 Thread Marc Zyngier
On 26/11/14 08:44, Jan Kiszka wrote:
> On 2014-11-17 07:47, Jan Kiszka wrote:
>> On 2014-11-10 14:10, Marc Zyngier wrote:
>>> On 10/11/14 12:57, Jan Kiszka wrote:
 Hi all,

 I'm trying to get Marc's CPU hotplug-anabling patch [1] for sunxi
 working on a B-Pi. After the first discussion it became clear that we
 need something like flush_dcache_all in the PSCI monitor (I don't think
 we need an icache flush, do we?). Does anyone have a clever suggestion
>>>
>>> No, I-cache can be left alone.
>>>
 how to reuse the existing code for that? Or do we really need to
 re-implement everything, in the worst case in assembly?
>>>
>>> Why don't you turn the u-boot code into a set of macros, included by
>>> both the core u-boot code and the PSCI code?
>>
>> I've now ported over v7_flush_dcache_all from the Linux kernel.
>>
>> However, that didn't magically solve the remaining issues with your
>> patch: I'm getting crashes on CPU 0 after handling the shoot-down FIQ.
>> That is even then the case if I only acknowledge the FIQ on the receiver
>> side, don't do any fiddling with CPU1's power states. Only if I
>> disabling sending the FIQ from CPU 1, the system remains stable in a CPU
>> off/on loop.
>>
>> Below the patch I'm using. Any ideas if something is wrong with the FIQ
>> handler or the setup of this mechanism or whatever?
>>
>> Jan
>>
>> ---
>>
>> diff --git a/arch/arm/cpu/armv7/sunxi/psci.S 
>> b/arch/arm/cpu/armv7/sunxi/psci.S
>> index b9ea78b..0e4bca4 100644
>> --- a/arch/arm/cpu/armv7/sunxi/psci.S
>> +++ b/arch/arm/cpu/armv7/sunxi/psci.S
>> @@ -18,6 +18,7 @@
>>   */
>>  
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -38,6 +39,8 @@
>>  
>>  #define ONE_MS  (CONFIG_SYS_CLK_FREQ / 1000)
>>  #define TEN_MS  (10 * ONE_MS)
>> +#define GICD_BASE   0x1c81000
>> +#define GICC_BASE   0x1c82000
>>  
>>  .macro  timer_wait  reg, ticks
>>  @ Program CNTP_TVAL
>> @@ -61,7 +64,27 @@
>>  
>>  .globl  psci_arch_init
>>  psci_arch_init:
>> +movwr4, #(GICD_BASE & 0x)
>> +movtr4, #(GICD_BASE >> 16)
>> +
>> +ldr r5, [r4, #GICD_IGROUPRn]
>> +bic r5, r5, #(1 << 15)  @ SGI15 as Group-0
>> +str r5, [r4, #GICD_IGROUPRn]
>> +
>> +mov r5, #0  @ Set SGI15 priority to 0
>> +strbr5, [r4, #(GICD_IPRIORITYRn + 15)]
>> +
>> +add r4, r4, #0x1000 @ GICC address
>> +
>> +mov r5, #0xff
>> +str r5, [r4, #GICC_PMR] @ Be cool with non-secure
>> +
>> +ldr r5, [r4, #GICC_CTLR]
>> +orr r5, r5, #(1 << 3)   @ Switch FIQEn on
>> +str r5, [r4, #GICC_CTLR]
>> +
>>  mrc p15, 0, r5, c1, c1, 0   @ Read SCR
>> +orr r5, r5, #4  @ Enable FIQ in monitor mode
>>  bic r5, r5, #1  @ Secure mode
>>  mcr p15, 0, r5, c1, c1, 0   @ Write SCR
>>  isb
>> @@ -79,6 +102,77 @@ psci_arch_init:
>>  
>>  bx  lr
>>  
>> +.globl  psci_fiq_enter
>> +psci_fiq_enter:
>> +push{r0-r12}
>> +
>> +@ Switch to secure
>> +mrc p15, 0, r7, c1, c1, 0
>> +bic r8, r7, #1
>> +mcr p15, 0, r8, c1, c1, 0
>> +isb
>> +
>> +movwr8, #(GICC_BASE & 0x)
>> +movtr8, #(GICC_BASE >> 16)
>> +ldr r9, [r8, #GICC_IAR]
>> +movwr10, #0x3ff
>> +movtr10, #0
>> +cmp r9, r10
>> +beq out
>> +movwr10, #0x3fe
>> +cmp r9, r10
>> +beq out
>> +str r9, [r8, #GICC_EOIR]
>> +dsb
>> +
>> +@ Compute CPU number
>> +lsr r9, r9, #10
>> +and r9, r9, #0xf
>> +
>> +movwr8, #(SUN7I_CPUCFG_BASE & 0x)
>> +movtr8, #(SUN7I_CPUCFG_BASE >> 16)
>> +
>> +@ Wait for the core to enter WFI
>> +lsl r11, r9, #6 @ x64
>> +add r11, r11, r8
>> +
>> +1:  ldr r10, [r11, #0x48]
>> +tst r10, #(1 << 2)
>> +bne 2f
>> +timer_wait r10, ONE_MS
>> +b   1b
>> +
>> +@ Reset CPU
>> +2:  mov r10, #0
>> +str r10, [r11, #0x40]
>> +
>> +@ Lock CPU
>> +mov r10, #1
>> +lsl r9, r10, r9 @ r9 is now CPU mask
>> +ldr r10, [r8, #0x1e4]
>> +bic r10, r10, r9
>> +str r10, [r8, #0x1e4]
>> +
>> +@ Set power gating
>> +ldr r10, [r8, #0x1b4]
>> +orr r10, r10, #1
>> +str r10, [r8, #0x1b4]
>> +timer_wait r10, ONE_MS
>> +
>> +@ Activate power clamp
>> +mov r10, #1
>> +1:  str r10, [r8, #0x1b0]
>> +lsl r10, r10, #1
>> +orr r10, r10, #1
>> +tst r10, #0x100
>> +beq 1b
>> +
>> +@ Restore security level
>> +out:mcr p15, 0, r7, c1, c1, 0
>> +
>> +pop {r0-r12}
>> +movspc, lr
> 
> We have to use "subs pc, lr, #4" to return from FIQ. I guess you can
> explain better than I why, I only stumbled over this in a stackoverflow
> posting

Re: [U-Boot] [PATCH 0/8] PSCI v0.2 framework for ARMv8

2014-11-26 Thread Jan Kiszka
On 2014-08-27 22:29, Arnab Basu wrote:
> This series of patches creates a generic PSCI v0.2 framework for ARMv8.
> 
> The first 3 patches refactor existing code so that ARMv7 PSCI,
> ARMv8 spin-table and ARMv8 PSCI can coexist.
> 
> The next 5 patches create a generic framework for PSCI v0.2 in ARMv8.
> 
> The implementation is modelled on the pre-existing PSCI v0.1 support
> in ARMv7.
> 
> PSCI support patches for the ARMv8 Foundation model will follow shortly.
> 

What's the status of this effort? I'll look into v0.2 support for v7
soon, so I was wondering if there is something recent to possibly build
upon / derive from.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH V2] cmd_i2c: Provide option for bulk 'i2c write' in one transaction

2014-11-26 Thread Lubomir Popov
I2C chips do exist that require a write of some multi-byte data to occur in
a single bus transaction (aka atomic transfer), otherwise either the write
does not come into effect at all, or normal operation of internal circuitry
cannot be guaranteed. The current implementation of the 'i2c write' command
(transfer of multiple bytes from a memory buffer) in fact performs a separate
transaction for each byte to be written and thus cannot support such types of
I2C slave devices.

This patch provides an alternative by allowing 'i2c write' to execute the
write transfer of the given number of bytes in a single bus transaction if
the '-s' option is specified as a final command argument. Else the current
re-addressing method is used.

Signed-off-by: Lubomir Popov 
---
Changes in V2:
The option to use bulk transfer vs re-addressing is implemented as a run-time
command argument and shall better fit into the new I2C DM (thanks to Simon for
the hint). V1 used conditional compilation through a board header definition.

 common/cmd_i2c.c |   35 +--
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
index c266b88..5cb7dca 100644
--- a/common/cmd_i2c.c
+++ b/common/cmd_i2c.c
@@ -270,7 +270,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[
uintdevaddr, alen, length;
u_char  *memaddr;

-   if (argc != 5)
+   if ((argc < 5) || (argc > 6))
return cmd_usage(cmdtp);

/*
@@ -293,20 +293,34 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv[
return cmd_usage(cmdtp);

/*
-* Length is the number of objects, not number of bytes.
+* Length is the number of bytes.
 */
length = simple_strtoul(argv[4], NULL, 16);
-
-   while (length-- > 0) {
-   if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0) {
+
+   if (argc == 6 && !strcmp(argv[5], "-s")) {
+   /*
+* Write all bytes in a single I2C transaction. If the target
+* device is an EEPROM, it is your responsibility to not cross
+* a page boundary. No write delay upon completion, take this
+* into account if linking commands.
+*/
+   if (i2c_write(chip, devaddr, alen, memaddr, length) != 0)
return i2c_report_err(-1, I2C_ERR_WRITE);
-   }
+   } else {
+   /*
+* Repeated addressing - perform  separate
+* write transactions of one byte each
+*/
+   while (length-- > 0) {
+   if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0)
+   return i2c_report_err(-1, I2C_ERR_WRITE);
 /*
  * No write delay with FRAM devices.
  */
 #if !defined(CONFIG_SYS_I2C_FRAM)
-   udelay(11000);
+   udelay(11000);
 #endif
+   }
}
return 0;
 }
@@ -1559,7 +1573,7 @@ static cmd_tbl_t cmd_i2c_sub[] = {
U_BOOT_CMD_MKENT(nm, 2, 1, do_i2c_nm, "", ""),
U_BOOT_CMD_MKENT(probe, 0, 1, do_i2c_probe, "", ""),
U_BOOT_CMD_MKENT(read, 5, 1, do_i2c_read, "", ""),
-   U_BOOT_CMD_MKENT(write, 5, 0, do_i2c_write, "", ""),
+   U_BOOT_CMD_MKENT(write, 6, 0, do_i2c_write, "", ""),
U_BOOT_CMD_MKENT(reset, 0, 1, do_i2c_reset, "", ""),
 #if defined(CONFIG_CMD_SDRAM)
U_BOOT_CMD_MKENT(sdram, 1, 1, do_sdram, "", ""),
@@ -1623,7 +1637,8 @@ static char i2c_help_text[] =
"i2c nm chip address[.0, .1, .2] - write to I2C device (constant 
address)\n"
"i2c probe [address] - test for and show device(s) on the I2C bus\n"
"i2c read chip address[.0, .1, .2] length memaddress - read to memory 
\n"
-   "i2c write memaddress chip address[.0, .1, .2] length - write memory to 
i2c\n"
+   "i2c write memaddress chip address[.0, .1, .2] length [-s] - write 
memory\n"
+   "  to I2C; the -s option selects bulk write in a single 
transaction\n"
"i2c reset - re-init the I2C Controller\n"
 #if defined(CONFIG_CMD_SDRAM)
"i2c sdram chip - print SDRAM configuration information\n"
@@ -1632,7 +1647,7 @@ static char i2c_help_text[] =
 #endif

 U_BOOT_CMD(
-   i2c, 6, 1, do_i2c,
+   i2c, 7, 1, do_i2c,
"I2C sub-system",
i2c_help_text
 );
-- 
1.7.9.5

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


[U-Boot] Make "usb start" only start / scan usb once ?

2014-11-26 Thread Hans de Goede

Hi,

Currently we've this magic in include/config_distro_bootcmd.h to avoid
scanning the usb bus multiple times.

And it does not work when also using an usb keyboard because then the
preboot command has already scanned the bus, so we're still scanning it
twice.

While discussing my latest attempt at fixing this:

http://patchwork.ozlabs.org/patch/413394/
http://patchwork.ozlabs.org/patch/413395/

With Ian, Ian said why not simply make "usb start" keep track of if it
already has started things, and then we can remove all the magic for it
from include/config_distro_bootcmd.h and just call it unconditionally.

This would also cause "usb start" and "usb reset" to actually do something
different, where as currently they are 100% the same.

I must say I like this idea, the only downside is, that it could be seen
as a break of the u-boot cmdline API, one could easily argue it is not,
because usb will be started by "usb start" if necessary, and people can
still force a rescan with "usb reset".

So any input on this, specifically would a patch-set to make "usb start"
start usb only once (per boot) be acceptable ?

Regards,

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


[U-Boot] [PATCH 1/2] sun6i: axp221: Add axp221_get_sid function

2014-11-26 Thread Hans de Goede
For sun6i the SID is stored in the pmic, rather then in the SoC itself,
add a function to retreive the sid.

Signed-off-by: Hans de Goede 
---
 drivers/power/axp221.c | 27 +++
 include/axp221.h   |  6 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/power/axp221.c b/drivers/power/axp221.c
index 941193a..826567a 100644
--- a/drivers/power/axp221.c
+++ b/drivers/power/axp221.c
@@ -184,3 +184,30 @@ int axp221_init(void)
 
return 0;
 }
+
+int axp221_get_sid(unsigned int *sid)
+{
+   u8 *dest = (u8 *)sid;
+   int i, ret;
+
+   ret = axp221_init();
+   if (ret)
+   return ret;
+
+   ret = p2wi_write(AXP221_PAGE, 1);
+   if (ret)
+   return ret;
+
+   for (i = 0; i < 16; i++) {
+   ret = p2wi_read(AXP221_SID + i, &dest[i]);
+   if (ret)
+   return ret;
+   }
+
+   p2wi_write(AXP221_PAGE, 0);
+
+   for (i = 0; i < 4; i++)
+   sid[i] = be32_to_cpu(sid[i]);
+
+   return 0;
+}
diff --git a/include/axp221.h b/include/axp221.h
index e3b4409..db219c6 100644
--- a/include/axp221.h
+++ b/include/axp221.h
@@ -10,6 +10,7 @@
 #define AXP221_CTRL_ADDR 0x3e
 #define AXP221_INIT_DATA 0x3e
 
+/* Page 0 addresses */
 #define AXP221_CHIP_ID 0x03
 #define AXP221_OUTPUT_CTRL10x10
 #define AXP221_OUTPUT_CTRL1_ALDO1_EN   (1 << 6)
@@ -34,6 +35,10 @@
 #define AXP221_ALDO1_CTRL  0x28
 #define AXP221_ALDO2_CTRL  0x28
 #define AXP221_ALDO3_CTRL  0x2a
+#define AXP221_PAGE0xff
+
+/* Page 1 addresses */
+#define AXP221_SID 0x20
 
 int axp221_set_dcdc1(unsigned int mvolt);
 int axp221_set_dcdc2(unsigned int mvolt);
@@ -48,3 +53,4 @@ int axp221_set_aldo1(unsigned int mvolt);
 int axp221_set_aldo2(unsigned int mvolt);
 int axp221_set_aldo3(unsigned int mvolt);
 int axp221_init(void);
+int axp221_get_sid(unsigned int *sid);
-- 
2.1.0

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


[U-Boot] [PATCH 2/2] sunxi: Add sunxi_get_sid helper function

2014-11-26 Thread Hans de Goede
On sun6i the SID is stored in the pmic, rather then in the SoC itself,
add a helper function to abstract this away.

This makes our MAC address generation code also work on sun6i.

Signed-off-by: Hans de Goede 
---
 arch/arm/cpu/armv7/sunxi/cpu_info.c   | 19 +++
 arch/arm/include/asm/arch-sunxi/cpu.h |  1 +
 board/sunxi/board.c   | 24 +++-
 3 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/cpu_info.c 
b/arch/arm/cpu/armv7/sunxi/cpu_info.c
index 5146dc4..7a3a4ca 100644
--- a/arch/arm/cpu/armv7/sunxi/cpu_info.c
+++ b/arch/arm/cpu/armv7/sunxi/cpu_info.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_MACH_SUN6I
 int sunxi_get_ss_bonding_id(void)
@@ -72,3 +73,21 @@ int print_cpuinfo(void)
return 0;
 }
 #endif
+
+int sunxi_get_sid(unsigned int *sid)
+{
+#ifdef CONFIG_MACH_SUN6I
+#ifdef CONFIG_AXP221_POWER
+   return axp221_get_sid(sid);
+#else
+   return -ENODEV;
+#endif
+#else
+   int i;
+
+   for (i = 0; i< 4; i++)
+   sid[i] = readl(SUNXI_SID_BASE + 4 * i);
+
+   return 0;
+#endif
+}
diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h 
b/arch/arm/include/asm/arch-sunxi/cpu.h
index 8aeed2f..9500262 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -147,6 +147,7 @@
 void sunxi_board_init(void);
 void sunxi_reset(void);
 int sunxi_get_ss_bonding_id(void);
+int sunxi_get_sid(unsigned int *sid);
 #endif /* __ASSEMBLY__ */
 
 #endif /* _CPU_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 4c1c69a..b5dfe95 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -217,22 +217,20 @@ void sunxi_board_init(void)
 #ifdef CONFIG_MISC_INIT_R
 int misc_init_r(void)
 {
-   if (!getenv("ethaddr")) {
-   uint32_t reg_val = readl(SUNXI_SID_BASE);
+   unsigned int sid[4];
 
-   if (reg_val) {
-   uint8_t mac_addr[6];
+   if (!getenv("ethaddr") && sunxi_get_sid(sid) == 0 &&
+   sid[0] != 0 && sid[3] != 0) {
+   uint8_t mac_addr[6];
 
-   mac_addr[0] = 0x02; /* Non OUI / registered MAC address 
*/
-   mac_addr[1] = (reg_val >>  0) & 0xff;
-   reg_val = readl(SUNXI_SID_BASE + 0x0c);
-   mac_addr[2] = (reg_val >> 24) & 0xff;
-   mac_addr[3] = (reg_val >> 16) & 0xff;
-   mac_addr[4] = (reg_val >>  8) & 0xff;
-   mac_addr[5] = (reg_val >>  0) & 0xff;
+   mac_addr[0] = 0x02; /* Non OUI / registered MAC address */
+   mac_addr[1] = (sid[0] >>  0) & 0xff;
+   mac_addr[2] = (sid[3] >> 24) & 0xff;
+   mac_addr[3] = (sid[3] >> 16) & 0xff;
+   mac_addr[4] = (sid[3] >>  8) & 0xff;
+   mac_addr[5] = (sid[3] >>  0) & 0xff;
 
-   eth_setenv_enetaddr("ethaddr", mac_addr);
-   }
+   eth_setenv_enetaddr("ethaddr", mac_addr);
}
 
return 0;
-- 
2.1.0

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


Re: [U-Boot] WARNING Could not get liodn of node /pcie@ffe240000: FDT_ERR_NOTFOUND

2014-11-26 Thread Laurentiu Tudor
On 11/26/2014 10:55 AM, Joakim Tjernlund wrote:
> Laurentiu Tudor  wrote on 2014/11/25 09:49:22:
>>
>> On 11/24/2014 06:57 PM, York Sun wrote:
>>> On 11/23/2014 11:30 PM, Joakim Tjernlund wrote:
 York Sun  wrote on 2014/10/24 18:02:03:
>
> On 10/24/2014 08:39 AM, Joakim Tjernlund wrote:
>> Booting my t1042 I get:
>> Loading Ramdisk to 2e639000, end 2cc4 ... OK
>> Loading Device Tree to 03fe4000, end 03fffd45 ... OK
>> WARNING Could not get liodn of node /pcie@ffe24: 
> FDT_ERR_NOTFOUND
>> WARNING Could not get liodn of node /pcie@ffe25: 
> FDT_ERR_NOTFOUND
>> WARNING Could not get liodn of node /pcie@ffe24: 
> FDT_ERR_NOTFOUND
>> WARNING Could not get liodn of node /pcie@ffe25: 
> FDT_ERR_NOTFOUND
>> 
>>
>> This apperas to come from 
>> base_liodn = fdt_getprop(fdt, off, "fsl,liodn", 
> &rc);
>> if (!base_liodn) {
>> char path[64];
>>
>> if (fdt_get_path(fdt, off, path, 
> sizeof(path)) 
 < 
>> 0)
>> strcpy(path, "(unknown)");
>> printf("WARNING Could not get liodn of node 
> 
 %s: 
>> %s\n",
>>path, fdt_strerror(rc));
>> continue;
>> }
>>
>> but I cannot find out  what what this property should be. Anyone?
>>
>
> Laurentiu,
>
> Can you take a look?
>
> York

 I might have missed it, but did this go anywhere?

>>>
>>> No. It didn't go anywhere. Laurentiu, can you follow up?
>>>
>>
>> Hi Jocke, York,
>>
>> Sorry for the late reply. I didn't noticed the thread in time.
>>
>> You need this patch:
>>
>> https://patchwork.ozlabs.org/patch/411910/
> 
> Great, I guess this will hit upstream any day now?
> 

I'm thinking York will pick it up in one of the following pull requests.

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


[U-Boot] [PATCH] sata: fix reset_sata for dwc_ahsata

2014-11-26 Thread Soeren Moch
- fix crash when sata device is not initialized
- remove disable_sata_clock() since it is not clear which clock for which
  device should be disabled here
- call disable_sata_clock() for mx6 in preboot_os instead

Signed-off-by: Soeren Moch 
---
Cc: Tom Rini 
Cc: Nikita Kiryanov 
Cc: Simon Glass 
Cc: guillaume.gar...@free.fr
Cc: Stefano Babic 
---
 arch/arm/imx-common/cpu.c  |  3 +++
 drivers/block/dwc_ahsata.c | 14 --
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
index b58df7d..28ccd29 100644
--- a/arch/arm/imx-common/cpu.c
+++ b/arch/arm/imx-common/cpu.c
@@ -206,6 +206,9 @@ void arch_preboot_os(void)
 {
 #if defined(CONFIG_CMD_SATA)
sata_stop();
+#if defined(CONFIG_MX6)
+   disable_sata_clock();
+#endif
 #endif
 #if defined(CONFIG_VIDEO_IPUV3)
/* disable video before launching O/S */
diff --git a/drivers/block/dwc_ahsata.c b/drivers/block/dwc_ahsata.c
index 9a2b547..9e925d1 100644
--- a/drivers/block/dwc_ahsata.c
+++ b/drivers/block/dwc_ahsata.c
@@ -594,22 +594,24 @@ int init_sata(int dev)
 
 int reset_sata(int dev)
 {
-   struct ahci_probe_ent *probe_ent =
-   (struct ahci_probe_ent *)sata_dev_desc[dev].priv;
-   struct sata_host_regs *host_mmio =
-   (struct sata_host_regs *)probe_ent->mmio_base;
+   struct ahci_probe_ent *probe_ent;
+   struct sata_host_regs *host_mmio;
 
if (dev < 0 || dev > (CONFIG_SYS_SATA_MAX_DEVICE - 1)) {
printf("The sata index %d is out of ranges\n\r", dev);
return -1;
}
 
+   probe_ent = (struct ahci_probe_ent *)sata_dev_desc[dev].priv;
+   if (NULL == probe_ent)
+   /* not initialized, so nothing to reset */
+   return 0;
+
+   host_mmio = probe_ent->mmio_base;
setbits_le32(&host_mmio->ghc, SATA_HOST_GHC_HR);
while (readl(&host_mmio->ghc) & SATA_HOST_GHC_HR)
udelay(100);
 
-   disable_sata_clock();
-
return 0;
 }
 
-- 
1.9.1

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


[U-Boot] [PATCH] tbs2910: fix Kconfig

2014-11-26 Thread Soeren Moch
fix Kconfig for tbs2910 board to prevent crash on relocation

Signed-off-by: Soeren Moch 
---
Cc: Stefano Babic 
---
 arch/arm/Kconfig  | 1 +
 board/tbs/tbs2910/Kconfig | 8 
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b9ac59e..be703af 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -650,6 +650,7 @@ config TARGET_KOSAGI_NOVENA
 
 config TARGET_TBS2910
bool "Support tbs2910"
+   select CPU_V7
 
 config TARGET_TQMA6
bool "TQ Systems TQMa6 board"
diff --git a/board/tbs/tbs2910/Kconfig b/board/tbs/tbs2910/Kconfig
index c514e24..84b243e 100644
--- a/board/tbs/tbs2910/Kconfig
+++ b/board/tbs/tbs2910/Kconfig
@@ -1,23 +1,15 @@
 if TARGET_TBS2910
 
-config SYS_CPU
-   string
-   default "armv7"
-
 config SYS_BOARD
-   string
default "tbs2910"
 
 config SYS_VENDOR
-   string
default "tbs"
 
 config SYS_SOC
-   string
default "mx6"
 
 config SYS_CONFIG_NAME
-   string
default "tbs2910"
 
 endif
-- 
1.9.1

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


Re: [U-Boot] mx53loco: compilation broken with 2015.01-rc2

2014-11-26 Thread Stefano Babic
Hi Guillaume,

On 26/11/2014 10:50, Guillaume Gardet wrote:
> Hi,
> 
> mx53loco_defconfig is broken in 2015.01-rc2 (was ok with -rc1).
> 
> I have the following warning:
> drivers/block/dwc_ahsata.c: In function 'reset_sata':
> drivers/block/dwc_ahsata.c:611:2: warning: implicit declaration of
> function 'disable_sata_clock' [-Wimplicit-function-declaration]
> 
> And finally this error:
> drivers/built-in.o: In function `reset_sata':
> /home/abuild/rpmbuild/BUILD/u-boot-2015.01-rc2/drivers/block/dwc_ahsata.c:611:
> undefined reference to `disable_sata_clock'
> ld.bfd: BFD (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1 assertion
> fail ../../bfd/elf32-arm.c:7696
> ld.bfd: error: required section '.rel.plt' not found in the linker script
> ld.bfd: final link failed: Invalid operation
> Makefile:1066: recipe for target 'u-boot' failed
> 
> 
> Commit 10ee8ecafbb4405ac77f6df081325630617aa7cd : "sata: implement
> reset_sata for dwc_ahsata" is probably the problem.
> mx6 is fixed by commit 8d29cef5887887157f54f98493440ce5c824d5cb : "arm:
> mx6: introduce disable_sata_clock", but nothing for mx5.

You're right. This is also connected to the thread:

https://www.mail-archive.com/u-boot@lists.denx.de/msg155590.html

As Soeren reports crash if sata_init() is not called, patch fixes an
issue but opens a new one on i.MX6. That means, even with i.MX6 is still
open. Soeren promised to send a patch for i.MX6, and after that we can
decide the best way to take for MX5.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] mx53loco: compilation broken with 2015.01-rc2

2014-11-26 Thread Guillaume Gardet

Hi,

mx53loco_defconfig is broken in 2015.01-rc2 (was ok with -rc1).

I have the following warning:
drivers/block/dwc_ahsata.c: In function 'reset_sata':
drivers/block/dwc_ahsata.c:611:2: warning: implicit declaration of function 
'disable_sata_clock' [-Wimplicit-function-declaration]

And finally this error:
drivers/built-in.o: In function `reset_sata':
/home/abuild/rpmbuild/BUILD/u-boot-2015.01-rc2/drivers/block/dwc_ahsata.c:611: 
undefined reference to `disable_sata_clock'
ld.bfd: BFD (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1 assertion fail 
../../bfd/elf32-arm.c:7696
ld.bfd: error: required section '.rel.plt' not found in the linker script
ld.bfd: final link failed: Invalid operation
Makefile:1066: recipe for target 'u-boot' failed


Commit 10ee8ecafbb4405ac77f6df081325630617aa7cd : "sata: implement reset_sata for 
dwc_ahsata" is probably the problem.
mx6 is fixed by commit 8d29cef5887887157f54f98493440ce5c824d5cb : "arm: mx6: 
introduce disable_sata_clock", but nothing for mx5.


Guillaume


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


Re: [U-Boot] [PATCH v1] exynos: Fix file system defines

2014-11-26 Thread Ian Campbell
On Tue, 2014-11-25 at 09:41 -0800, Suriyan Ramasami wrote:
> On the odroid, files in an ext4 file system were not being accessed.
> Correct the #defines to take care of this.

In u-boot-samsung.git#master since a bunch of this stuff has changed, in
particular include/configs/exynos-common.h uses config_distro_defaults.h
which I think provides most of what you've added here.

Ian.

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


[U-Boot] [PATCH] Kconfig: move EXPERT option under "General setup" menu

2014-11-26 Thread Masahiro Yamada
Make it a sub-menu of "General setup" like Linux Kernel.

Signed-off-by: Masahiro Yamada 
Cc: Tom Rini 
---

 Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Kconfig b/Kconfig
index 153ee2b..60cf1dd 100644
--- a/Kconfig
+++ b/Kconfig
@@ -56,8 +56,6 @@ config CC_OPTIMIZE_FOR_SIZE
 
  This option is enabled by default for U-Boot.
 
-endmenu# General setup
-
 menuconfig EXPERT
 bool "Configure standard U-Boot features (expert users)"
 help
@@ -66,6 +64,8 @@ menuconfig EXPERT
   environments which can tolerate a "non-standard" U-Boot.
   Only use this if you really know what you are doing.
 
+endmenu# General setup
+
 menu "Boot images"
 
 config SPL_BUILD
-- 
1.9.1

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


[U-Boot] [PATCH 5/8] usb: UniPhier: support OF configuration

2014-11-26 Thread Masahiro Yamada
If CONFIG_OF_CONTROL is defined, search device tree nodes that are
compatible with "panasonic,uniphier-ehci" and take the base address
from their "reg" property.

Signed-off-by: Masahiro Yamada 
Cc: Marek Vasut 
---

 arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c  |  1 -
 arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c |  1 -
 arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c |  1 -
 arch/arm/dts/uniphier-ph1-ld4-ref.dts |  8 +
 arch/arm/dts/uniphier-ph1-ld4.dtsi| 18 +++
 arch/arm/dts/uniphier-ph1-pro4-ref.dts|  8 +
 arch/arm/dts/uniphier-ph1-pro4.dtsi   | 12 +++
 arch/arm/dts/uniphier-ph1-sld8-ref.dts|  8 +
 arch/arm/dts/uniphier-ph1-sld8.dtsi   | 18 +++
 drivers/usb/host/ehci-uniphier.c  | 38 ++-
 10 files changed, 109 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c 
b/arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c
index 62f5b01..9d51299 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-ld4/platdevice.c
@@ -14,7 +14,6 @@ SERIAL_DEVICE(1, 0x54006900, UART_MASTER_CLK)
 SERIAL_DEVICE(2, 0x54006a00, UART_MASTER_CLK)
 SERIAL_DEVICE(3, 0x54006b00, UART_MASTER_CLK)
 
-/* USB : TODO for Masahiro Yamada: move base address to Device Tree */
 struct uniphier_ehci_platform_data uniphier_ehci_platdata[] = {
{
.base = 0x5a800100,
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c 
b/arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c
index 1843d04..31ee2a2 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/platdevice.c
@@ -14,7 +14,6 @@ SERIAL_DEVICE(1, 0x54006900, UART_MASTER_CLK)
 SERIAL_DEVICE(2, 0x54006a00, UART_MASTER_CLK)
 SERIAL_DEVICE(3, 0x54006b00, UART_MASTER_CLK)
 
-/* USB : TODO for Masahiro Yamada: move base address to Device Tree */
 struct uniphier_ehci_platform_data uniphier_ehci_platdata[] = {
{
.base = 0x5a800100,
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c 
b/arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c
index 72ec599..ea0691d 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-sld8/platdevice.c
@@ -14,7 +14,6 @@ SERIAL_DEVICE(1, 0x54006900, UART_MASTER_CLK)
 SERIAL_DEVICE(2, 0x54006a00, UART_MASTER_CLK)
 SERIAL_DEVICE(3, 0x54006b00, UART_MASTER_CLK)
 
-/* USB : TODO for Masahiro Yamada: move base address to Device Tree */
 struct uniphier_ehci_platform_data uniphier_ehci_platdata[] = {
{
.base = 0x5a800100,
diff --git a/arch/arm/dts/uniphier-ph1-ld4-ref.dts 
b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
index 49642e1..14b6091 100644
--- a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
@@ -32,3 +32,11 @@
 &uart1 {
status = "okay";
 };
+
+&usb0 {
+  status = "okay";
+};
+
+&usb1 {
+  status = "okay";
+};
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index c1c2c62..80074c5 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -56,5 +56,23 @@
reg = <0x54006b00 0x20>;
clock-frequency = <36864000>;
};
+
+   usb0: usb@5a800100 {
+   compatible = "panasonic,uniphier-ehci", "usb-ehci";
+   status = "disabled";
+   reg = <0x5a800100 0x100>;
+   };
+
+   usb1: usb@5a810100 {
+   compatible = "panasonic,uniphier-ehci", "usb-ehci";
+   status = "disabled";
+   reg = <0x5a810100 0x100>;
+   };
+
+   usb2: usb@5a820100 {
+   compatible = "panasonic,uniphier-ehci", "usb-ehci";
+   status = "disabled";
+   reg = <0x5a820100 0x100>;
+   };
};
 };
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts 
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index cfed70b..e724d4e 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -32,3 +32,11 @@
 &uart1 {
status = "okay";
 };
+
+&usb0 {
+  status = "okay";
+};
+
+&usb1 {
+  status = "okay";
+};
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index b53fbc5..dd84269 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -62,5 +62,17 @@
reg = <0x54006b00 0x20>;
clock-frequency = <73728000>;
};
+
+   usb0: usb@5a800100 {
+   compatible = "panasonic,uniphier-ehci", "usb-ehci";
+   status = "disabled";
+   reg = <0x5a800100 0x100>;

[U-Boot] [PATCH 6/8] ARM: UniPhier: enable Device Tree control

2014-11-26 Thread Masahiro Yamada
Signed-off-by: Masahiro Yamada 
---

 arch/arm/Kconfig   | 1 +
 configs/ph1_ld4_defconfig  | 1 +
 configs/ph1_pro4_defconfig | 1 +
 configs/ph1_sld8_defconfig | 1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b9ac59e..0982117 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -793,6 +793,7 @@ config ARCH_UNIPHIER
bool "Panasonic UniPhier platform"
select CPU_V7
select SUPPORT_SPL
+   select OF_CONTROL if !SPL_BUILD
 
 endchoice
 
diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig
index f54b15f..b50503f 100644
--- a/configs/ph1_ld4_defconfig
+++ b/configs/ph1_ld4_defconfig
@@ -2,6 +2,7 @@ CONFIG_SPL=y
 +S:CONFIG_ARM=y
 +S:CONFIG_ARCH_UNIPHIER=y
 +S:CONFIG_MACH_PH1_LD4=y
+CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-ld4-ref"
 CONFIG_DM=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig
index e795752..acb8dc7 100644
--- a/configs/ph1_pro4_defconfig
+++ b/configs/ph1_pro4_defconfig
@@ -2,6 +2,7 @@ CONFIG_SPL=y
 +S:CONFIG_ARM=y
 +S:CONFIG_ARCH_UNIPHIER=y
 +S:CONFIG_MACH_PH1_PRO4=y
+CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref"
 CONFIG_DM=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig
index 6510937..3f1f0c1 100644
--- a/configs/ph1_sld8_defconfig
+++ b/configs/ph1_sld8_defconfig
@@ -2,6 +2,7 @@ CONFIG_SPL=y
 +S:CONFIG_ARM=y
 +S:CONFIG_ARCH_UNIPHIER=y
 +S:CONFIG_MACH_PH1_SLD8=y
+CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-sld8-ref"
 CONFIG_DM=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
-- 
1.9.1

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


[U-Boot] [PATCH 2/8] ARM: UniPhier: add dummy gpio.h to enable CONFIG_OF_CONTROL

2014-11-26 Thread Masahiro Yamada
If CONFIG_OF_CONTROL is enabled, lib/fdtdec.c is compiled.
It includes  and then  includes
.  Consequently, all the SoCs that enable
CONFIG_OF_CONTROL must have  even if they do not
support GPIO.

In the first place, GPIO has nothing to do with OF_CONTROL.
It is wrong that lib/fdtdec.c includes GPIO functions; it should
be split into two files, FDT-common things and GPIO things.
It is, however, a pretty big work to fix that correctly.

This is a compromised commit to add a dummy 
to support OF_CONTROL for UniPhier platform.  This dummy header
will be removed after FDT-GPIO stuff is fixed correctly.

Signed-off-by: Masahiro Yamada 
---

I am working on the task to split lib/fdtdec.c and
move GPIO functions to drivers/gpio/.


 arch/arm/include/asm/arch-uniphier/gpio.h | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-uniphier/gpio.h

diff --git a/arch/arm/include/asm/arch-uniphier/gpio.h 
b/arch/arm/include/asm/arch-uniphier/gpio.h
new file mode 100644
index 000..1fc4e19
--- /dev/null
+++ b/arch/arm/include/asm/arch-uniphier/gpio.h
@@ -0,0 +1,6 @@
+/*
+ * Dummy header file to enable CONFIG_OF_CONTROL.
+ * If CONFIG_OF_CONTROL is enabled, lib/fdtdec.c is compiled.
+ * It includes  via , so those SoCs that enable
+ * OF_CONTROL must have arch/gpio.h even if GPIO is not supported.
+ */
-- 
1.9.1

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


[U-Boot] [PATCH 7/8] ARM: UniPhier: display model name if it is available in device tree

2014-11-26 Thread Masahiro Yamada
If CONFIG_OF_CONTROL is defined and the root node of the device tree
has "model" property, display the model name instead of the hard-coded
board name.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/cpu/armv7/uniphier/Makefile  |  1 +
 arch/arm/cpu/armv7/uniphier/board_info.c  | 25 +++
 arch/arm/cpu/armv7/uniphier/ph1-ld4/board_info.c  |  8 +---
 arch/arm/cpu/armv7/uniphier/ph1-pro4/board_info.c |  9 ++--
 arch/arm/cpu/armv7/uniphier/ph1-sld8/board_info.c |  9 ++--
 arch/arm/include/asm/arch-uniphier/board.h|  2 ++
 6 files changed, 33 insertions(+), 21 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/uniphier/board_info.c

diff --git a/arch/arm/cpu/armv7/uniphier/Makefile 
b/arch/arm/cpu/armv7/uniphier/Makefile
index 0f64d25..77650bd 100644
--- a/arch/arm/cpu/armv7/uniphier/Makefile
+++ b/arch/arm/cpu/armv7/uniphier/Makefile
@@ -11,6 +11,7 @@ obj-y += cache_uniphier.o
 obj-$(CONFIG_BOARD_POSTCLK_INIT) += board_postclk_init.o
 obj-y += dram_init.o
 obj-$(CONFIG_DISPLAY_CPUINFO) += cpu_info.o
+obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o
 obj-$(CONFIG_BOARD_LATE_INIT) += board_late_init.o
 obj-$(CONFIG_UNIPHIER_SMP) += smp.o
 obj-$(CONFIG_CMD_PINMON) += cmd_pinmon.o
diff --git a/arch/arm/cpu/armv7/uniphier/board_info.c 
b/arch/arm/cpu/armv7/uniphier/board_info.c
new file mode 100644
index 000..bd56c11
--- /dev/null
+++ b/arch/arm/cpu/armv7/uniphier/board_info.c
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2014 Panasonic Corporation
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+
+int checkboard(void)
+{
+   const char *model = NULL;
+#ifdef CONFIG_OF_CONTROL
+   DECLARE_GLOBAL_DATA_PTR;
+
+   model = (const char *)fdt_getprop(gd->fdt_blob, 0, "model", NULL);
+#endif
+   if (!model)
+   model = uniphier_board_name;
+
+   printf("Board: %s\n", model);
+
+   return check_support_card();
+}
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-ld4/board_info.c 
b/arch/arm/cpu/armv7/uniphier/ph1-ld4/board_info.c
index 27d772e..a84b77f 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-ld4/board_info.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-ld4/board_info.c
@@ -5,12 +5,6 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
 #include 
 
-int checkboard(void)
-{
-   puts("Board: PH1-LD4 Board\n");
-
-   return check_support_card();
-}
+const char *uniphier_board_name = "PH1-LD4 Board";
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/board_info.c 
b/arch/arm/cpu/armv7/uniphier/ph1-pro4/board_info.c
index 325a4f6..94897d5 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-pro4/board_info.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/board_info.c
@@ -5,12 +5,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
-#include 
 
-int checkboard(void)
-{
-   puts("Board: PH1-Pro4 Board\n");
+#include 
 
-   return check_support_card();
-}
+const char *uniphier_board_name = "PH1-Pro4 Board";
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-sld8/board_info.c 
b/arch/arm/cpu/armv7/uniphier/ph1-sld8/board_info.c
index 15dc289..3a293be 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-sld8/board_info.c
+++ b/arch/arm/cpu/armv7/uniphier/ph1-sld8/board_info.c
@@ -5,12 +5,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
-#include 
-#include 
 
-int checkboard(void)
-{
-   puts("Board: PH1-sLD8 Board\n");
+#include 
 
-   return check_support_card();
-}
+const char *uniphier_board_name = "PH1-sLD8 Board";
diff --git a/arch/arm/include/asm/arch-uniphier/board.h 
b/arch/arm/include/asm/arch-uniphier/board.h
index e6ba4e4..1b50dd2 100644
--- a/arch/arm/include/asm/arch-uniphier/board.h
+++ b/arch/arm/include/asm/arch-uniphier/board.h
@@ -22,6 +22,8 @@ static inline int check_support_card(void)
 }
 #endif
 
+extern const char *uniphier_board_name;
+
 static inline void uniphier_board_reset(void)
 {
support_card_reset();
-- 
1.9.1

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


[U-Boot] [PATCH 3/8] ARM: UniPhier: add device tree sources

2014-11-26 Thread Masahiro Yamada
This commit adds basic device tree sources for UniPhier SoCs/boards.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/Makefile  |  4 
 arch/arm/dts/uniphier-ph1-ld4-ref.dts  | 25 ++
 arch/arm/dts/uniphier-ph1-ld4.dtsi | 32 
 arch/arm/dts/uniphier-ph1-pro4-ref.dts | 25 ++
 arch/arm/dts/uniphier-ph1-pro4.dtsi| 38 ++
 arch/arm/dts/uniphier-ph1-sld8-ref.dts | 25 ++
 arch/arm/dts/uniphier-ph1-sld8.dtsi| 32 
 7 files changed, 181 insertions(+)
 create mode 100644 arch/arm/dts/uniphier-ph1-ld4-ref.dts
 create mode 100644 arch/arm/dts/uniphier-ph1-ld4.dtsi
 create mode 100644 arch/arm/dts/uniphier-ph1-pro4-ref.dts
 create mode 100644 arch/arm/dts/uniphier-ph1-pro4.dtsi
 create mode 100644 arch/arm/dts/uniphier-ph1-sld8-ref.dts
 create mode 100644 arch/arm/dts/uniphier-ph1-sld8.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ba6dec9..b6e4d18 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -31,6 +31,10 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra114-dalmore.dtb \
tegra124-jetson-tk1.dtb \
tegra124-venice2.dtb
+dtb-$(CONFIG_ARCH_UNIPHIER) += \
+   uniphier-ph1-pro4-ref.dtb \
+   uniphier-ph1-ld4-ref.dtb \
+   uniphier-ph1-sld8-ref.dtb
 dtb-$(CONFIG_ZYNQ) += zynq-zc702.dtb \
zynq-zc706.dtb \
zynq-zed.dtb \
diff --git a/arch/arm/dts/uniphier-ph1-ld4-ref.dts 
b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
new file mode 100644
index 000..9f690dd
--- /dev/null
+++ b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
@@ -0,0 +1,25 @@
+/*
+ * Device Tree Source for UniPhier PH1-LD4 Reference Board
+ *
+ * Copyright (C) 2014 Panasonic Corporation
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-ld4.dtsi"
+
+/ {
+   model = "Panasonic UniPhier Ph1-LD4 Reference Board";
+   compatible = "panasonic,ph1-ld4-ref", "panasonic,ph1-ld4";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>;
+   };
+
+   chosen {
+   bootargs = "console=ttyPS0,115200 earlyprintk";
+   };
+};
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
new file mode 100644
index 000..ee53d9c
--- /dev/null
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -0,0 +1,32 @@
+/*
+ * Device Tree Source for UniPhier PH1-LD4 SoC
+ *
+ * Copyright (C) 2014 Panasonic Corporation
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+   compatible = "panasonic,ph1-ld4";
+
+   cpus {
+   #size-cells = <0>;
+   #address-cells = <1>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   reg = <0>;
+   };
+   };
+
+   soc {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   };
+};
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts 
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
new file mode 100644
index 000..9a5823e
--- /dev/null
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -0,0 +1,25 @@
+/*
+ * Device Tree Source for UniPhier PH1-Pro4 Reference Board
+ *
+ * Copyright (C) 2014 Panasonic Corporation
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-pro4.dtsi"
+
+/ {
+   model = "Panasonic UniPhier Ph1-Pro4 Reference Board";
+   compatible = "panasonic,ph1-pro4-ref", "panasonic,ph1-pro4";
+
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x4000>;
+   };
+
+   chosen {
+   bootargs = "console=ttyPS0,115200 earlyprintk";
+   };
+};
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
new file mode 100644
index 000..7619c36
--- /dev/null
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -0,0 +1,38 @@
+/*
+ * Device Tree Source for UniPhier PH1-Pro4 SoC
+ *
+ * Copyright (C) 2014 Panasonic Corporation
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+   compatible = "panasonic,ph1-pro4";
+
+   cpus {
+   #size-cells = <0>;
+   #address-cells = <1>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   reg = <0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   reg = <1>;
+   };
+   };
+
+   soc {
+   compatible = 

[U-Boot] [PATCH 8/8] ARM: UniPhier: move CONFIG_CMD_* and CONFIG_FIT* defines to defconfig

2014-11-26 Thread Masahiro Yamada
Signed-off-by: Masahiro Yamada 
---

 configs/ph1_ld4_defconfig | 25 +
 configs/ph1_pro4_defconfig| 25 +
 configs/ph1_sld8_defconfig| 25 +
 include/configs/uniphier-common.h | 15 ---
 4 files changed, 75 insertions(+), 15 deletions(-)

diff --git a/configs/ph1_ld4_defconfig b/configs/ph1_ld4_defconfig
index b50503f..de068e9 100644
--- a/configs/ph1_ld4_defconfig
+++ b/configs/ph1_ld4_defconfig
@@ -1,7 +1,32 @@
 CONFIG_SPL=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
 +S:CONFIG_ARM=y
 +S:CONFIG_ARCH_UNIPHIER=y
 +S:CONFIG_MACH_PH1_LD4=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BDI=y
+CONFIG_CMD_CONSOLE=y
+CONFIG_CMD_BOOTD=y
+CONFIG_CMD_RUN=y
+CONFIG_CMD_IMI=y
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_EDITENV=y
+CONFIG_CMD_SAVEENV=y
+CONFIG_CMD_MEMORY=y
+CONFIG_CMD_LOADB=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_FLASH=y
+CONFIG_CMD_NAND=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_ECHO=y
+CONFIG_CMD_ITEST=y
+CONFIG_CMD_SOURCE=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_NFS=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_TIME=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-ld4-ref"
 CONFIG_DM=y
 CONFIG_NAND_DENALI=y
diff --git a/configs/ph1_pro4_defconfig b/configs/ph1_pro4_defconfig
index acb8dc7..f4ddf5f 100644
--- a/configs/ph1_pro4_defconfig
+++ b/configs/ph1_pro4_defconfig
@@ -1,7 +1,32 @@
 CONFIG_SPL=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
 +S:CONFIG_ARM=y
 +S:CONFIG_ARCH_UNIPHIER=y
 +S:CONFIG_MACH_PH1_PRO4=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BDI=y
+CONFIG_CMD_CONSOLE=y
+CONFIG_CMD_BOOTD=y
+CONFIG_CMD_RUN=y
+CONFIG_CMD_IMI=y
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_EDITENV=y
+CONFIG_CMD_SAVEENV=y
+CONFIG_CMD_MEMORY=y
+CONFIG_CMD_LOADB=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_FLASH=y
+CONFIG_CMD_NAND=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_ECHO=y
+CONFIG_CMD_ITEST=y
+CONFIG_CMD_SOURCE=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_NFS=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_TIME=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-pro4-ref"
 CONFIG_DM=y
 CONFIG_NAND_DENALI=y
diff --git a/configs/ph1_sld8_defconfig b/configs/ph1_sld8_defconfig
index 3f1f0c1..ee14382 100644
--- a/configs/ph1_sld8_defconfig
+++ b/configs/ph1_sld8_defconfig
@@ -1,7 +1,32 @@
 CONFIG_SPL=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
 +S:CONFIG_ARM=y
 +S:CONFIG_ARCH_UNIPHIER=y
 +S:CONFIG_MACH_PH1_SLD8=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_BDI=y
+CONFIG_CMD_CONSOLE=y
+CONFIG_CMD_BOOTD=y
+CONFIG_CMD_RUN=y
+CONFIG_CMD_IMI=y
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_EDITENV=y
+CONFIG_CMD_SAVEENV=y
+CONFIG_CMD_MEMORY=y
+CONFIG_CMD_LOADB=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_FLASH=y
+CONFIG_CMD_NAND=y
+CONFIG_CMD_USB=y
+CONFIG_CMD_ECHO=y
+CONFIG_CMD_ITEST=y
+CONFIG_CMD_SOURCE=y
+CONFIG_CMD_NET=y
+CONFIG_CMD_TFTPPUT=y
+CONFIG_CMD_NFS=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_TIME=y
 CONFIG_DEFAULT_DEVICE_TREE="uniphier-ph1-sld8-ref"
 CONFIG_DM=y
 CONFIG_NAND_DENALI=y
diff --git a/include/configs/uniphier-common.h 
b/include/configs/uniphier-common.h
index 95f4ee1..31ab470 100644
--- a/include/configs/uniphier-common.h
+++ b/include/configs/uniphier-common.h
@@ -112,7 +112,6 @@ are defined. Select only one of them."
 #define CONFIG_SYS_LONGHELP/* undef to save memory */
 
 #define CONFIG_CMDLINE_EDITING /* add command line history */
-#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser */
 #define CONFIG_SYS_CBSIZE  1024/* Console I/O Buffer Size */
 /* Print Buffer Size */
 #define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + 
sizeof(CONFIG_SYS_PROMPT) + 16)
@@ -143,15 +142,6 @@ are defined. Select only one of them."
  */
 #define CONFIG_ARP_TIMEOUT 500UL  /* 0.5 msec */
 
-/*
- * Command line configuration.
- */
-#include 
-
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_TIME
-#define CONFIG_CMD_NAND/* NAND flash suppport */
-
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_MAX_CHIPS  2
 #define CONFIG_SYS_NAND_ONFI_DETECTION
@@ -167,7 +157,6 @@ are defined. Select only one of them."
 #define CONFIG_SYS_NAND_BAD_BLOCK_POS  0
 
 /* USB */
-#define CONFIG_CMD_USB
 #define CONFIG_USB_MAX_CONTROLLER_COUNT2
 #define CONFIG_CMD_FAT
 #define CONFIG_FAT_WRITE
@@ -224,10 +213,6 @@ are defined. Select only one of them."
"add_default_bootargs=setenv bootargs $bootargs"\
" console=ttyS0,$baudrate\0"\
 
-/* FIT support */
-#define CONFIG_FIT
-#define CONFIG_FIT_VERBOSE 1 /* enable fit_format_{error,warning}() */
-
 /* Open Firmware flat tree */
 #define CONFIG_OF_LIBFDT
 
-- 
1.9.1

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


[U-Boot] [PATCH 4/8] serial: UniPhier: support OF configuration

2014-11-26 Thread Masahiro Yamada
This commit implements the ofdata_to_platdata handler for the UniPhier
serial driver and adds serial device nodes to the device tree sources.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-ph1-ld4-ref.dts  |  9 +
 arch/arm/dts/uniphier-ph1-ld4.dtsi | 28 
 arch/arm/dts/uniphier-ph1-pro4-ref.dts |  9 +
 arch/arm/dts/uniphier-ph1-pro4.dtsi| 28 
 arch/arm/dts/uniphier-ph1-sld8-ref.dts |  9 +
 arch/arm/dts/uniphier-ph1-sld8.dtsi| 28 
 drivers/serial/serial_uniphier.c   | 19 +++
 7 files changed, 122 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/uniphier-ph1-ld4-ref.dts 
b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
index 9f690dd..49642e1 100644
--- a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
@@ -21,5 +21,14 @@
 
chosen {
bootargs = "console=ttyPS0,115200 earlyprintk";
+   stdout-path = &uart0;
};
 };
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   status = "okay";
+};
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index ee53d9c..c1c2c62 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -28,5 +28,33 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+   uart0: serial@54006800 {
+   compatible = "panasonic,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006800 0x20>;
+   clock-frequency = <36864000>;
+   };
+
+   uart1: serial@54006900 {
+   compatible = "panasonic,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006900 0x20>;
+   clock-frequency = <36864000>;
+   };
+
+   uart2: serial@54006a00 {
+   compatible = "panasonic,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006a00 0x20>;
+   clock-frequency = <36864000>;
+   };
+
+   uart3: serial@54006b00 {
+   compatible = "panasonic,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006b00 0x20>;
+   clock-frequency = <36864000>;
+   };
};
 };
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts 
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index 9a5823e..cfed70b 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -21,5 +21,14 @@
 
chosen {
bootargs = "console=ttyPS0,115200 earlyprintk";
+   stdout-path = &uart0;
};
 };
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   status = "okay";
+};
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index 7619c36..b53fbc5 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -34,5 +34,33 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+
+   uart0: serial@54006800 {
+   compatible = "panasonic,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006800 0x20>;
+   clock-frequency = <73728000>;
+   };
+
+   uart1: serial@54006900 {
+   compatible = "panasonic,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006900 0x20>;
+   clock-frequency = <73728000>;
+   };
+
+   uart2: serial@54006a00 {
+   compatible = "panasonic,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006a00 0x20>;
+   clock-frequency = <73728000>;
+   };
+
+   uart3: serial@54006b00 {
+   compatible = "panasonic,uniphier-uart";
+   status = "disabled";
+   reg = <0x54006b00 0x20>;
+   clock-frequency = <73728000>;
+   };
};
 };
diff --git a/arch/arm/dts/uniphier-ph1-sld8-ref.dts 
b/arch/arm/dts/uniphier-ph1-sld8-ref.dts
index 75f35da..d38df3c 100644
--- a/arch/arm/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-sld8-ref.dts
@@ -21,5 +21,14 @@
 
chosen {
bootargs = "console=ttyPS0,115200 earlyprintk";
+   stdout-path = &uart0;
};
 };
+
+&uart0 {
+   status = "okay";
+};
+
+&uart1 {
+   status = "okay";
+};
diff --git a/arch/arm/dts/uniphier-ph1-sld8.dtsi 
b/arch/arm/dts/uniphier-ph1-sld8.dtsi
index 2f895e9..9a8da5e 

[U-Boot] [PATCH 1/8] ARM: UniPhier: do not compile platform data when CONFIG_OF_CONTROL=y

2014-11-26 Thread Masahiro Yamada
Signed-off-by: Masahiro Yamada 
---

 arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile  | 2 +-
 arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile | 2 +-
 arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile 
b/arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile
index fba1cc7..5d682d3 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile
+++ b/arch/arm/cpu/armv7/uniphier/ph1-ld4/Makefile
@@ -3,7 +3,7 @@
 #
 
 obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o
-obj-y += platdevice.o
+obj-$(if $(CONFIG_OF_CONTROL),,y) += platdevice.o
 obj-y += boot-mode.o
 obj-$(CONFIG_SOC_INIT) += bcu_init.o sbc_init.o sg_init.o pll_init.o \
clkrst_init.o
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile 
b/arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile
index 74129bc..fd1c432 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile
+++ b/arch/arm/cpu/armv7/uniphier/ph1-pro4/Makefile
@@ -3,7 +3,7 @@
 #
 
 obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o
-obj-y += platdevice.o
+obj-$(if $(CONFIG_OF_CONTROL),,y) += platdevice.o
 obj-y += boot-mode.o
 obj-$(CONFIG_SOC_INIT) += sbc_init.o sg_init.o pll_init.o clkrst_init.o
 obj-$(CONFIG_BOARD_POSTCLK_INIT) += pinctrl.o
diff --git a/arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile 
b/arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile
index fba1cc7..5d682d3 100644
--- a/arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile
+++ b/arch/arm/cpu/armv7/uniphier/ph1-sld8/Makefile
@@ -3,7 +3,7 @@
 #
 
 obj-$(CONFIG_DISPLAY_BOARDINFO) += board_info.o
-obj-y += platdevice.o
+obj-$(if $(CONFIG_OF_CONTROL),,y) += platdevice.o
 obj-y += boot-mode.o
 obj-$(CONFIG_SOC_INIT) += bcu_init.o sbc_init.o sg_init.o pll_init.o \
clkrst_init.o
-- 
1.9.1

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


Re: [U-Boot] Please pull u-boot-sunxi master

2014-11-26 Thread Hans de Goede

Hi,

On 11/25/2014 10:52 PM, Tom Rini wrote:

On Tue, Nov 25, 2014 at 10:52:21AM -0700, Simon Glass wrote:

Hi Tom,

On 25 November 2014 at 05:45, Hans de Goede  wrote:

Hi Tom,

Please pull u-boot-sunxi/master into master, highlights:

1) hdmi console (with usb keyboard) support with simplefb support so the
kernel
can use the framebuffer too
2) GMAC support for sun6i
3) A couple of small bugfixes

Note I've done a rebase + forced-push, as things were becoming a bit messy
while merging.

The following changes since commit 2a82ec77d27ef5f860a107c4b764643a655dceeb:

   Prepare v2015.01-rc2 (2014-11-24 17:08:47 -0500)

are available in the git repository at:

   http://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to b366fb92c3d118f97bb0f01fa9c40d253e70e12c:

   sun7i: Set ARMV7_BOOT_SEC_DEFAULT when OLD_SUNXI_KERNEL_COMPAT is set
(2014-11-25 13:38:46 +0100)


Hans de Goede (12):
   sun4i: Rename dram_clk_cfg to dram_clk_gate
   sunxi: Add video pll clock functions
   sunxi: video: Add sun6i support
   fdt_support: Add a fdt_setup_simplefb_node helper function
   common/lcd: Make lcd_dt_simplefb_configure_node use
fdt_setup_simplefb_node
   sunxi: Add usb keyboard Kconfig option
   sunxi: ahci: Add a delay after enabling target power
   sun6i: Correct Mele M9 Vbus gpio settings
   sun6i: Add gmac support for sun6i boards
   sun6i: Drop some "unknown magic" from dram init
   sun7i: Drop CONFIG_ARMV7_PSCI_NR_CPUS
   sun7i: Set ARMV7_BOOT_SEC_DEFAULT when OLD_SUNXI_KERNEL_COMPAT is set


The u-boot-fdt pull request is pending. I think it might have a slight
conflict with this one, so I'll wait until this goes in and then
resend the fdt pull request.


I _think_ I resolved the conflict right.


Hmm, I'm not seeing any changes if I do a "git remote update" did you perhaps
forget to push things ?

Thanks & Regards,

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


Re: [U-Boot] qemu-system-arm segfaults on zynq_zed

2014-11-26 Thread James Zhou



Hi Douglas,

It seems to hit in the follow location:


(gdb) f 3
#3  0x557c6a21 in get_page_addr_code (env1=env1@entry=0x562f6100, 
addr=addr@entry=4294967280)
at /xilinx/qemu/cputlb.c:325
325cpu_abort(cpu, "Trying to execute code outside RAM or ROM at 
0x"
(gdb) l 320
315cpu_ldub_code(env1, addr);
316}
317pd = env1->iotlb[mmu_idx][page_index] & ~TARGET_PAGE_MASK;
318mr = iotlb_to_region(cpu->as, pd);
319if (memory_region_is_unassigned(mr)) {
320CPUClass *cc = CPU_GET_CLASS(cpu);
321
322if (cc->do_unassigned_access) {
323cc->do_unassigned_access(cpu, addr, false, true, 0, 4);
324} else {
(gdb) 
325cpu_abort(cpu, "Trying to execute code outside RAM or ROM at 
0x"
326  TARGET_FMT_lx "\n", addr);
327}
328}
329p = (void *)((uintptr_t)addr + 
env1->tlb_table[mmu_idx][page_index].addend);
330return qemu_ram_addr_from_host_nofail(p);
331}
332
333#define MMUSUFFIX _cmmu
334#undef GETPC

(gdb) p/x addr
$2 = 0xfff0


Might be a qemu issue, but not sure how it is triggered by a quick glance.


Regards,

James



Date: Mon, 24 Nov 2014 11:58:05 -0800
From: douglas.b.r...@gmail.com
To: soren.brinkm...@xilinx.com
CC: u-boot@lists.denx.de; crosthwaitepe...@gmail.com
Subject: Re: [U-Boot] qemu-system-arm segfaults on zynq_zed

I tried with a zed_zynq built u-boot.bin and u-boot.dtb built from
u-boot-2014.10 release, and got slightly different results:
 
qemu: fatal: Trying to execute code outside RAM or ROM at 0xfff0.
 
Then a register dump.
 
Oh well, thanks for the pointers in your previous message, will read for
clues.
 
On Mon, Nov 24, 2014 at 10:34 AM, Sören Brinkmann <
soren.brinkm...@xilinx.com> wrote:
 
> I suppose the uboot.bin files you are talking about are binaries that
> had been converted with objcopy or similar from ELF to binary. That
> probably works well. The Zynq boot.bin is a container file that contains
> the Zynq bootloader and (optionally) other things (like U-Boot). I doubt
> QEMU is able to parse this Zynq specific file (though, it's all
> documented, so it could be implemented I guess). So, you probably want to
> pass the u-boot.elf as kernel, but I don't know to what extend that works
> currently. For that we need input from Peter.
> For more information about the Zynq boot.bin format, please have a look
> at section 6.3.2 in the Zynq TRM
> (
> http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf
> )
> and the Zynq SW developer guide
> (
> http://www.xilinx.com/support/documentation/user_guides/ug821-zynq-7000-swdev.pdf
> ).
>
> Sören
>
> On Mon, 2014-11-24 at 10:24AM -0800, Douglas Rupp wrote:
> > For versatilepb arm, there's a blog post that describes a recipe of how
> to
> > build and boot "uboot.bin" in qemu.  It works fine, here's the link if
> > you're interested.
> > https://balau82.wordpress.com/2010/03/10/u-boot-for-arm-on-qemu/
> >
> > I assumed that uboot was standardized enough so that it would work the
> same
> > for other machine/board emulations. I'd like to understand why it's not
> > working.
> >
> > The problem I'm trying to solve is to configure networking in uboot for
> the
> > xilinx-zynq-a9 bsp for vxworks7 running under qemu.  Vxworks7 uses uboot
> > where 6.9 didn't, and the default device tree isn't set correctly for my
> > network, it just has some random defaults that are expected to be
> > customized.  The alternative is to use real hardware, which should work
> > well enough for debugging but in general it's much easier to debug and
> run
> > tests in qemu especially when working remotely.
> >
> > So any ideas you might have on what's special about zynq utboot would be
> > appreciated.
> >
> > On Mon, Nov 24, 2014 at 9:45 AM, Sören Brinkmann <
> soren.brinkm...@xilinx.com
> > > wrote:
> >
> > > I don't think boot.bin is a legal "kernel". IIRC, I had issues running
> > > on QEMU, but it was slightly better than what you describe.
> > >
> > > Sören
> > >
> > > On Mon, 2014-11-24 at 09:40AM -0800, Douglas Rupp wrote:
> > > >The result is:
> > > >
> > > >arm-softmmu/qemu-system-arm -M arm-generic-fdt -nographic -smp 2
> > > -machine
> > > >linux=on -serial mon:stdio -dtb devicetree.dtb -kernel boot.bin
> > > >SPI device 0x7f8161521ee0
> > > >qemu: fatal: Trying to execute code outside RAM or ROM at
> 0xfff0
> > > >
> > > >then a register dump
> > > >
> > > >The "boot.bin" and "devicetree.dtb" is from xilinx binary release
> > > >2014.3-release/zed
> > > >
> > > >I tried removing -smp 2 -machine linux=on, and same error.
> > > >On Mon, Nov 24, 2014 at 9:21 AM, Sören Brinkmann
> > > ><[1]soren.brinkm...@xilinx.com> wrote:
> > > >
> > > >  Could you try whether these instructions work?
> > > >  [2]http://www.wiki.xilinx.com/QEMU
> > > >
> > > >  

Re: [U-Boot] [PATCH] cmd_i2c: Provide option for bulk 'i2c write' in one transaction

2014-11-26 Thread Lubomir Popov
Hi Simon,

> Hi,
>
> On 24 November 2014 at 09:00, Lubomir Popov  wrote:
>> I2C chips do exist that require a write of some multi-byte data to occur in
>> a single bus transaction (aka atomic transfer), otherwise either the write
>> does not come into effect at all, or normal operation of internal circuitry
>> cannot be guaranteed. The current implementation of the 'i2c write' command
>> (transfer of multiple bytes from a memory buffer) in fact performs a separate
>> transaction for each byte to be written and thus cannot support such types of
>> I2C slave devices.
>>
>> This patch provides an alternative by allowing 'i2c write' to execute the
>> write transfer of the given number of bytes in a single bus transaction if
>> CONFIG_SYS_I2C_BULK_WRITE is defined in the board header (otherwise the old
>> method shall compile).
>>
>> Signed-off-by: Lubomir Popov 
>> ---
>>  common/cmd_i2c.c |   15 ++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/common/cmd_i2c.c b/common/cmd_i2c.c
>> index 3a75f94..7116458 100644
>> --- a/common/cmd_i2c.c
>> +++ b/common/cmd_i2c.c
>> @@ -280,10 +280,22 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, 
>> int argc, char * const argv[
>> return cmd_usage(cmdtp);
>>
>> /*
>> -* Length is the number of objects, not number of bytes.
>> +* Length is the number of bytes.
>>  */
>> length = simple_strtoul(argv[4], NULL, 16);
>>
>> +#if defined(CONFIG_SYS_I2C_BULK_WRITE)
>> +   /*
>> +* Write all bytes in a single I2C transaction. If the target
>> +* device is an EEPROM, it is your responsibility to not cross
>> +* a page bounady.
>> +*/
>> +   if (i2c_write(chip, devaddr, alen, memaddr, length) != 0) {
>> +   puts("Error writing to the chip.\n");
>> +   return 1;
>> +   }
>> +#else
>> +   /* Perform  separate write transactions of one byte each */
>> while (length-- > 0) {
>> if (i2c_write(chip, devaddr++, alen, memaddr++, 1) != 0) {
>> puts("Error writing to the chip.\n");
>> @@ -296,6 +308,7 @@ static int do_i2c_write(cmd_tbl_t *cmdtp, int flag, int 
>> argc, char * const argv[
>> udelay(11000);
>>  #endif
>
> This should really be an option/flag on the command. We might want to
> do different things depending on the situation.
Agree. I thought about this initially, even about adding a separate command,
but then decided that the human device using 'i2c write' with or without the
config option would be intelligent enough to know what is being needed and
done. From a chip compatibility perspective this is not an issue, since for
byte-wise transfers the 'i2c mw' and 'i2c mm' commands still do exist. So I
went the easy way :-).
>
> In fact with driver model's I2C implementation, currently in review,
> this logic of splitting things up can be handled in the uclass layer:
>
> http://patchwork.ozlabs.org/patch/414066/
Right, in the DM context a command line option would be the better solution.
I shall see to revising the patch in this respect.
>
> Regards,
> Simon
>
Best regards,
Lubo

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


Re: [U-Boot] WARNING Could not get liodn of node /pcie@ffe240000: FDT_ERR_NOTFOUND

2014-11-26 Thread Joakim Tjernlund
Laurentiu Tudor  wrote on 2014/11/25 09:49:22:
> 
> On 11/24/2014 06:57 PM, York Sun wrote:
> > On 11/23/2014 11:30 PM, Joakim Tjernlund wrote:
> >> York Sun  wrote on 2014/10/24 18:02:03:
> >>>
> >>> On 10/24/2014 08:39 AM, Joakim Tjernlund wrote:
>  Booting my t1042 I get:
>  Loading Ramdisk to 2e639000, end 2cc4 ... OK
>  Loading Device Tree to 03fe4000, end 03fffd45 ... OK
>  WARNING Could not get liodn of node /pcie@ffe24: 
FDT_ERR_NOTFOUND
>  WARNING Could not get liodn of node /pcie@ffe25: 
FDT_ERR_NOTFOUND
>  WARNING Could not get liodn of node /pcie@ffe24: 
FDT_ERR_NOTFOUND
>  WARNING Could not get liodn of node /pcie@ffe25: 
FDT_ERR_NOTFOUND
>  
> 
>  This apperas to come from 
>  base_liodn = fdt_getprop(fdt, off, "fsl,liodn", 
&rc);
>  if (!base_liodn) {
>  char path[64];
> 
>  if (fdt_get_path(fdt, off, path, 
sizeof(path)) 
> >> < 
>  0)
>  strcpy(path, "(unknown)");
>  printf("WARNING Could not get liodn of node 

> >> %s: 
>  %s\n",
> path, fdt_strerror(rc));
>  continue;
>  }
> 
>  but I cannot find out  what what this property should be. Anyone?
> 
> >>>
> >>> Laurentiu,
> >>>
> >>> Can you take a look?
> >>>
> >>> York
> >>
> >> I might have missed it, but did this go anywhere?
> >>
> > 
> > No. It didn't go anywhere. Laurentiu, can you follow up?
> > 
> 
> Hi Jocke, York,
> 
> Sorry for the late reply. I didn't noticed the thread in time.
> 
> You need this patch:
> 
> https://patchwork.ozlabs.org/patch/411910/

Great, I guess this will hit upstream any day now?

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


Re: [U-Boot] sunxi: CPU disabling

2014-11-26 Thread Jan Kiszka
On 2014-11-17 07:47, Jan Kiszka wrote:
> On 2014-11-10 14:10, Marc Zyngier wrote:
>> On 10/11/14 12:57, Jan Kiszka wrote:
>>> Hi all,
>>>
>>> I'm trying to get Marc's CPU hotplug-anabling patch [1] for sunxi
>>> working on a B-Pi. After the first discussion it became clear that we
>>> need something like flush_dcache_all in the PSCI monitor (I don't think
>>> we need an icache flush, do we?). Does anyone have a clever suggestion
>>
>> No, I-cache can be left alone.
>>
>>> how to reuse the existing code for that? Or do we really need to
>>> re-implement everything, in the worst case in assembly?
>>
>> Why don't you turn the u-boot code into a set of macros, included by
>> both the core u-boot code and the PSCI code?
> 
> I've now ported over v7_flush_dcache_all from the Linux kernel.
> 
> However, that didn't magically solve the remaining issues with your
> patch: I'm getting crashes on CPU 0 after handling the shoot-down FIQ.
> That is even then the case if I only acknowledge the FIQ on the receiver
> side, don't do any fiddling with CPU1's power states. Only if I
> disabling sending the FIQ from CPU 1, the system remains stable in a CPU
> off/on loop.
> 
> Below the patch I'm using. Any ideas if something is wrong with the FIQ
> handler or the setup of this mechanism or whatever?
> 
> Jan
> 
> ---
> 
> diff --git a/arch/arm/cpu/armv7/sunxi/psci.S b/arch/arm/cpu/armv7/sunxi/psci.S
> index b9ea78b..0e4bca4 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci.S
> +++ b/arch/arm/cpu/armv7/sunxi/psci.S
> @@ -18,6 +18,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -38,6 +39,8 @@
>  
>  #define  ONE_MS  (CONFIG_SYS_CLK_FREQ / 1000)
>  #define  TEN_MS  (10 * ONE_MS)
> +#define  GICD_BASE   0x1c81000
> +#define  GICC_BASE   0x1c82000
>  
>  .macro   timer_wait  reg, ticks
>   @ Program CNTP_TVAL
> @@ -61,7 +64,27 @@
>  
>  .globl   psci_arch_init
>  psci_arch_init:
> + movwr4, #(GICD_BASE & 0x)
> + movtr4, #(GICD_BASE >> 16)
> +
> + ldr r5, [r4, #GICD_IGROUPRn]
> + bic r5, r5, #(1 << 15)  @ SGI15 as Group-0
> + str r5, [r4, #GICD_IGROUPRn]
> +
> + mov r5, #0  @ Set SGI15 priority to 0
> + strbr5, [r4, #(GICD_IPRIORITYRn + 15)]
> +
> + add r4, r4, #0x1000 @ GICC address
> +
> + mov r5, #0xff
> + str r5, [r4, #GICC_PMR] @ Be cool with non-secure
> +
> + ldr r5, [r4, #GICC_CTLR]
> + orr r5, r5, #(1 << 3)   @ Switch FIQEn on
> + str r5, [r4, #GICC_CTLR]
> +
>   mrc p15, 0, r5, c1, c1, 0   @ Read SCR
> + orr r5, r5, #4  @ Enable FIQ in monitor mode
>   bic r5, r5, #1  @ Secure mode
>   mcr p15, 0, r5, c1, c1, 0   @ Write SCR
>   isb
> @@ -79,6 +102,77 @@ psci_arch_init:
>  
>   bx  lr
>  
> +.globl   psci_fiq_enter
> +psci_fiq_enter:
> + push{r0-r12}
> +
> + @ Switch to secure
> + mrc p15, 0, r7, c1, c1, 0
> + bic r8, r7, #1
> + mcr p15, 0, r8, c1, c1, 0
> + isb
> +
> + movwr8, #(GICC_BASE & 0x)
> + movtr8, #(GICC_BASE >> 16)
> + ldr r9, [r8, #GICC_IAR]
> + movwr10, #0x3ff
> + movtr10, #0
> + cmp r9, r10
> + beq out
> + movwr10, #0x3fe
> + cmp r9, r10
> + beq out
> + str r9, [r8, #GICC_EOIR]
> + dsb
> +
> + @ Compute CPU number
> + lsr r9, r9, #10
> + and r9, r9, #0xf
> +
> + movwr8, #(SUN7I_CPUCFG_BASE & 0x)
> + movtr8, #(SUN7I_CPUCFG_BASE >> 16)
> +
> + @ Wait for the core to enter WFI
> + lsl r11, r9, #6 @ x64
> + add r11, r11, r8
> +
> +1:   ldr r10, [r11, #0x48]
> + tst r10, #(1 << 2)
> + bne 2f
> + timer_wait r10, ONE_MS
> + b   1b
> +
> + @ Reset CPU
> +2:   mov r10, #0
> + str r10, [r11, #0x40]
> +
> + @ Lock CPU
> + mov r10, #1
> + lsl r9, r10, r9 @ r9 is now CPU mask
> + ldr r10, [r8, #0x1e4]
> + bic r10, r10, r9
> + str r10, [r8, #0x1e4]
> +
> + @ Set power gating
> + ldr r10, [r8, #0x1b4]
> + orr r10, r10, #1
> + str r10, [r8, #0x1b4]
> + timer_wait r10, ONE_MS
> +
> + @ Activate power clamp
> + mov r10, #1
> +1:   str r10, [r8, #0x1b0]
> + lsl r10, r10, #1
> + orr r10, r10, #1
> + tst r10, #0x100
> + beq 1b
> +
> + @ Restore security level
> +out: mcr p15, 0, r7, c1, c1, 0
> +
> + pop {r0-r12}
> + movspc, lr

We have to use "subs pc, lr, #4" to return from FIQ. I guess you can
explain better than I why, I only stumbled over this in a stackoverflow
posting - and it works!

Jan




signature.asc
Description: OpenPGP digital signature
___

[U-Boot] Export redesign

2014-11-26 Thread Martin Dorwig
Hello,
while trying to eliminate the XF_xxx enums, i came to a point in 
examples/standalone/stubs.c
In the definition of EXPORT_FUNC for CONFIG_AVR32
the XF_ ##x is not multiplied with sizeof(void*) .
Is this a bug or a avr feature ?

Regards
Martin

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