Re: [U-Boot] [PATCH 1/5] Tegra2: Add bitfield access macros

[Detlev Zundel]

Hi,

> Dear Simon Glass,
>
> In message  you wrote:
>> 
>> >clrsetbits_le32(&my_device->ctrl, FIELD_MASK, FIELD_VAL(6));
>>
>> We now have a computed mask which is good, thank you.
>>
>> But the FIELD is specified twice in the same statement. Can we
>> therefore please take this a step further and write something like
>> this?
>>
>> clrsetfield_le32(&my_device->ctrl, FIELD, 6);
>
> I think I should provide a little moe explanation why I dislike your
> suggestion.  With "FOO_MASK, FOO_VAL()" it is obvious to the
> reader that we are dealing ith some (bit) mask and some value, and it
> is also trivial to locate the respective definitions of these macros,
> because you know their exact names.
>
> With "FOO, 6" you know nothing.  Searching for "FOO" in the source
> code and header files will probably return a ton of unrelated
> references, and you will have to read (and understand) the definition
> of the bitfield macro and follow it's preprocessor trickery with
> combining some magic name parts until you finally know what to look
> for.
>
> You consider this macro helpful, I consider it obscure, and that's why
> I don't want to have it.

For what its worth, I also consider the magic under the hood to be too
much.  It may look clever, but it actually makes the code harder to read
without knowing the definition of the macrot itself.  Having to know the
_definition_ of a macro to understand how it works violates the usual
paradigm of having a fixed API/contract independent of the
implementation.

Cheers
  Detlev

-- 
It's like manually inflatable airbags -- people will never
think to use it in time to actually get any help from it.
 -- Miles Bader in <20030607122005.ga1...@gnu.org>
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] How to compile tools?

[Veli-Pekka Peltola]

Hi,

We have been using U-Boot 2010.06 and now we are trying to use the 
latest version. Our build system processes the kernel with mkimage so we 
compile U-Boot tools with "make tools" even if bootloader is not 
compiled. This has worked fine in the past. It seems that 2011.03 is the 
last version where this approach worked after removing config.h include 
in tools/imximage.h. Is there currently an easy way to compile only 
tools, not the whole bootloader?

Error with 2011.06-rc2:
peltove@swdtvp:~/u-boot-2011.06-rc2$ make tools
awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' 
boards.cfg > .boards.depend
make -C tools all
make[1]: Entering directory `/home/peltove/u-boot-2011.06-rc2/tools'
/home/peltove/u-boot-2011.06-rc2/config.mk:183: *** could not find 
linker script.  Stop.
make[1]: Leaving directory `/home/peltove/u-boot-2011.06-rc2/tools'
make: *** [tools] Error 2

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

Re: [U-Boot] Supporting SCCB protocol

[Detlev Zundel]

Hi John,

> That's correct! I should elaborate it. It should be (Serial Camera Control
> Bus) protocol developed by omnivision.
> I am using a OV2715 sensor and I need to access the registers of the said
> sensor, I have to modify the I2C read/write in uboot to support the SCCB
> transactions.

So SCCB is really only another name for I2C or are there differences in
the protocol?

If the first holds, then the infrastructure is already thereand you
should be able to use the i2c commands.  If the latter then you really
shoudl come up with your own "sccb" driver.  Probably basing it on
drivers.i2c/soft_i2c.c would be a good idea.

> Here's my question:
> If my sensor has power and a clock, does it response to the I2C probe or I
> have to modify it too?. Right now, If I run iprobe, it did not detect my
> sensor and not sure what it caused.

This should be discoverable by reading the manuals of the sensor.  If
this is at all like I2C, then it should definitely answer when its clock
and data pins are driven by I2C.  Did you check with an oscilloscope
that you really are talking to the chip?

Cheers
  Detlev

-- 
-- Question authority!
-- Yeah, says who?
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] dreamplug: Initial support.

[Prafulla Wadaskar]

> -Original Message-
> From: u-b...@lakedaemon.net [mailto:u-b...@lakedaemon.net]
> Sent: Tuesday, June 07, 2011 11:07 PM
> To: u-boot@lists.denx.de
> Cc: Prafulla Wadaskar; Siddarth Gore; Jason Cooper
> Subject: [PATCH 1/1] dreamplug: Initial support.
> 
> From: Jason Cooper 
> 
> Copied files from boards/Marvell/guruplug/ and did
>   s/GURUPLUG/DREAMPLUG/g
>   s/guruplug/dreamplug/g
> 
> Switched from NAND flash to SPI flash.
>   MPP._SPI_ configuration copied from
>   boards/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c
> 
> Also, MACH_TYPE_DREAMPLUG (board id 3550) has been registered at
> http://www.arm.linux.co.uk/developer/machines/, once support has
> been added to mainline Linux, we'll update the board id here.
> For now, we use MACH_TYPE_GURUPLUG, just as the factory U-Boot does.
> 
> Signed-off-by: Jason Cooper 
> ---
>  MAINTAINERS  |1 +
>  MAKEALL  |1 +
>  board/Marvell/dreamplug/Makefile |   51 +++
>  board/Marvell/dreamplug/dreamplug.c  |  154
> 
>  board/Marvell/dreamplug/dreamplug.h  |   39 
>  board/Marvell/dreamplug/kwbimage.cfg |  160
> ++
>  boards.cfg   |1 +
>  include/configs/dreamplug.h  |  111 +++
>  8 files changed, 518 insertions(+), 0 deletions(-)
>  create mode 100644 board/Marvell/dreamplug/Makefile
>  create mode 100644 board/Marvell/dreamplug/dreamplug.c
>  create mode 100644 board/Marvell/dreamplug/dreamplug.h
>  create mode 100644 board/Marvell/dreamplug/kwbimage.cfg
>  create mode 100644 include/configs/dreamplug.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c462ae2..c3711a8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -202,6 +202,7 @@ Niklaus Giger 
>  Siddarth Gore 
> 
>   guruplugARM926EJS (Kirkwood SoC)
> + dreamplug   ARM926EJS (Kirkwood SoC)

Dreamplug entry should be under your name. maintain alphabetical order too.

> 
>  Paul Gortmaker 
> 
> diff --git a/MAKEALL b/MAKEALL
> index d592374..35fc5b7 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -345,6 +345,7 @@ LIST_ARM9="   \
>   edb9315a\
>   edminiv2\
>   guruplug\
> + dreamplug   \

Not in order.

>   imx27lite   \
>   jadecpu \
>   lpd7a400\
> diff --git a/board/Marvell/dreamplug/Makefile
> b/board/Marvell/dreamplug/Makefile
> new file mode 100644
> index 000..b7e5270
> --- /dev/null
> +++ b/board/Marvell/dreamplug/Makefile
> @@ -0,0 +1,51 @@
> +#
> +# (C) Copyright 2009

2011 ?? and everywhere


> +# Marvell Semiconductor 
> +# Written-by: Siddarth Gore 

You can say, based on or referenced from..
You as an author should reflect for the new files being added.

> +#
> +# See file CREDITS for list of people who contributed to this
> +# project.
> +#
> +# This program is free software; you can redistribute it and/or
> +# modify it under the terms of the GNU General Public License as
> +# published by the Free Software Foundation; either version 2 of
> +# the License, or (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program; if not, write to the Free Software
> +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> +# MA 02110-1301 USA
> +#
> +
> +include $(TOPDIR)/config.mk
> +
> +LIB  = $(obj)lib$(BOARD).o
> +
> +COBJS:= dreamplug.o
> +
> +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS))
> +SOBJS:= $(addprefix $(obj),$(SOBJS))
> +
> +$(LIB):  $(obj).depend $(OBJS) $(SOBJS)
> + $(call cmd_link_o_target, $(OBJS) $(SOBJS))
> +
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean:   clean
> + rm -f $(LIB) core *.bak .depend
> +
> +###
> ##
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +###
> ##
> diff --git a/board/Marvell/dreamplug/dreamplug.c
> b/board/Marvell/dreamplug/dreamplug.c
> new file mode 100644
> index 000..3797af1
> --- /dev/null
> +++ b/board/Marvell/dreamplug/dreamplug.c
> @@ -0,0 +1,154 @@
> +/*
> + * (C) Copyright 2009
> + * Marvell Semiconductor 
> + * Written-by: Siddarth Gore 

Same here..


> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of

Re: [U-Boot] Compilation error - Cygwin - Pandaboard

[Detlev Zundel]

Hi Iordan,

> Hello,
>
> I'm trying to compile u-boot 2011_06_rc2  under Cygwin, but 
> unfortunatelly a header
> file could not be found:

Only people armed with lots of Make foo dare walk that way :)

[...]

> Is it possible that a search path is not specified?
>
> I tried to compile it under Fedora (in a virtual machine) and there is 
> no problem.

There are only very rare occassions of people actually using Cygwin
here.  So my advice would be to use the virtual machine and get on with
the real work.

Cheers
  Detlev

-- 
And like the software patent issue, I also don't necessarily like DRM myself,
but I still ended up feeling the same: I'm an "Oppenheimer", and I refuse to
play politics with Linux, and I think you can use Linux for whatever you want
to - which very much includes things I don't necessarily personally approve
of.-- Linus Torvalds in lmkl
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] arm/km: add support for portl2 board

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: Tuesday, June 07, 2011 4:16 PM
> To: u-boot@lists.denx.de
> Cc: Valentin Longchamp; Holger Brunck; Prafulla Wadaskar; Heiko Schocher
> Subject: [PATCH 2/6] arm/km: add support for portl2 board

Can you add this board support after this patch series or last patch in this 
series?

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

Re: [U-Boot] [STATUS] WARNING: huge ARM board removal pending

[Minkyu Kang]

Dear Albert ARIBAUD,

On 3 June 2011 06:51, Wolfgang Denk  wrote:
>
> Hi,
>
> this is a * W A R N I N G * message to maintainers / users / owners
> of ARM boards.  If your board fails to build in the current release,
> it will be subject to a big cleanup action which is going to remove
> all old, unmaintained and broken boards in the next merge window.
> According to our current schedule, this is in 10 days from now.
>
>
> At present, the following 112 boards are scheduled for removal:
>
> B2                  at91sam9m10g45ek    edb9307a            omap2420h4
> CPU9260             at91sam9rlek        edb9312             omap5912osk
> CPU9G20             cmc_pu2             edb9315             omap730p2
> CPUAT91             cp1026              edb9315a            otc570_dataflash
> SBC35_A9G20         cp1136              ep7312              pm9261
> SMN42               cp920t              evb4510             pm9263
> TNY_A9260           cp922_XA10          gcplus              pm9g45
> TNY_A9G20           cp926ejs            impa7               sbc2410x
> afeb9260            cp946es             imx31_phycore       scb9328
> ap7                 cp966               imx31_phycore_eet   shannon
> ap720t              cpu9260             integratorap        smdk2400
> ap920t              cpu9260_128M        integratorcp        smdk6400
> ap922_XA10          cpu9260_nand        jornada             snapper9260
> ap926ejs            cpu9260_nand_128M   kb9202              snapper9g20
> ap946es             cpu9G20             lart                spear300
> ap966               cpu9G20_128M        lpc2292sodimm       spear310
> apollon             cpu9G20_nand        lpd7a400            spear320
> armadillo           cpu9G20_nand_128M   m501sk              spear600
> assabet             cpuat91             meesc               tnetv107x_evm
> at91cap9adk         cpuat91_ram         meesc_dataflash     top9000eval_xe
> at91rm9200dk        csb226              modnet50            top9000su_xe
> at91rm9200ek        csb637              mx1ads              trab
> at91rm9200ek_ram    dnp1110             mx1fs2              versatile
> at91sam9260ek       eb_cpux9k2          mx31ads             versatileab
> at91sam9261ek       edb9301             netstar             versatilepb
> at91sam9263ek       edb9302             omap1510inn         voiceblue
> at91sam9g10ek       edb9302a            omap1610h2          zipitz2
> at91sam9g20ek       edb9307             omap1610inn         zylonite
>
>
> Please submit fixes to prevent removal.
>
> Note:  countdown is T minus 10 days, and counting.
>

Please apply this patch for SMDK6400.
http://patchwork.ozlabs.org/patch/98525/

Thanks
Minkyu Kang
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] andes_spi: add andes_spi interface

[Macpaul Lin]

Hi Mike and Wolfgang,

Since the patch v3 of andes_spi driver has been sent on 4/25/2011,
and has no further comment for patch v3
will you take this patch? Thanks.

http://patchwork.ozlabs.org/patch/92704/



2011/4/25 Wolfgang Denk 

> Dear Mike Frysinger,
>
> [this goes also to all other custodians[
>
>
> In message  you wrote:
> > On Mon, Apr 25, 2011 at 02:50, Macpaul Lin wrote:
> > > +void spi_init()
> >
> > please use "(void)"
> >
> > > +void andes_spi_spit_en(struct andes_spi_slave *ds)
> >
> > mark static
> ...
>
> If you request changes to a patch like here, could you please be also
> so kind and change the patch status in patchwork to "Changes
> Requested"?  Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
>
>


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

Re: [U-Boot] [PATCH v2] andes_spi: add andes_spi interface

[Macpaul Lin]

Hi all,

2011/6/8 Macpaul Lin 

> Hi Mike and Wolfgang,
>
> Since the patch v3 of andes_spi driver has been sent on 4/25/2011,
> and has no further comment for patch v3
> will you take this patch? Thanks.
>
> http://patchwork.ozlabs.org/patch/92704/
>

I've forget to reply the mail after quoted part at the beginning the mail.
Sorry for top-posting to this thread.

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

Re: [U-Boot] [PATCH 2/6] arm/km: add support for portl2 board

[Holger Brunck]

Hi Prafulla,

On 06/08/2011 10:35 AM, Prafulla Wadaskar wrote:
>> Subject: [PATCH 2/6] arm/km: add support for portl2 board
> 
> Can you add this board support after this patch series or last patch in this 
> series?
> 

hm, 3/6 and 5/6 has dependencies to the portl2 support patch, but I think I can
handle this. So I will prepare an update serie 1/5 and a single patch for the
portl2 support ok? But only for my curiosity, what the reason for this need?

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

Re: [U-Boot] [PATCH 2/6] arm/km: add support for portl2 board

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: Wednesday, June 08, 2011 2:36 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Valentin Longchamp; Heiko Schocher
> Subject: Re: [PATCH 2/6] arm/km: add support for portl2 board
> 
> Hi Prafulla,
> 
> On 06/08/2011 10:35 AM, Prafulla Wadaskar wrote:
> >> Subject: [PATCH 2/6] arm/km: add support for portl2 board
> >
> > Can you add this board support after this patch series or last patch
> in this series?
> >
> 
> hm, 3/6 and 5/6 has dependencies to the portl2 support patch, but I
> think I can
> handle this. So I will prepare an update serie 1/5 and a single patch
> for the
> portl2 support ok? But only for my curiosity, what the reason for this
> need?
> 

:-)
To me a patch series looks like updates/corrections to the existing code.
Whereas new board support is addition, should be on the top of it.
So let's keep them separate for better understanding.

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

Re: [U-Boot] [PATCH] powerpc/85xx: Add basic support for P1023RDS board

[Wolfgang Denk]

Dear Zang Roy-R61911,


[excessive Cc: list trimmed]

In message 
<2239ac579c7d3646a720227a37e02681157...@039-sn1mpn1-004.039d.mgd.msft.net> you 
wrote:
> 
> > Please fix the checkpatch warnings (7 lines over 80 characters)
> 
> I can fix it. In fact, I use checkpatch every time before I send out patch.

Then I do not understand why you submitted the patch at all before
cleaning it up.

> If you check the board header file, most of them has this problem.

Cleanup patches are welcome.

> Do you think 
> + /* physical addr of CCSRBAR */
> +#define CONFIG_SYS_CCSRBAR_PHYSCONFIG_SYS_CCSRBAR
> is better than
> +#define CONFIG_SYS_CCSRBAR_PHYSCONFIG_SYS_CCSRBAR  /* physical
>  addr of CCSRBAR */
> ???
> Please clarify.

At least the first version does not violate coding style requirements.

Regarding the general topic of comments - there are such and such
comments.  Things like

i = i + 1;  /* Increment variable i by one */

are gratuitous and of no use at all.

In your example above, I ask myself why we need
CONFIG_SYS_CCSRBAR_PHYS at all when whe already have
CONFIG_SYS_CCSRBAR (or vice versa).

And why we need a comment that explains this in grat detail - separate
for each single macro.

Please re-read "Chapter 8: Commenting" in the coding-style document
for more details.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The philosophy exam was a piece of cake  -  which  was  a  bit  of  a
surprise, actually, because I was expecting some questions on a sheet
of paper.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] at91sam9260ek and mmc

[Jan Pohanka]

Dear Reinhard,

during last week I have been trying to make sd card in u-boot working on  
at91sam9260ek, unfortunately without success. I have posted some details  
in this post on the mailing list  
http://lists.denx.de/pipermail/u-boot/2011-June/093666.html

I'm almost sure that it is not a hardware issue, because in Linux booted  
 from nand flash sd works like a charm, even mounting rootfs on the sd is  
possible.

You stated, that you have sd card working in your development branch,  
could you share it, please? It seems I'm not able to fix it by myself :(

with best regards
Jan


Dne Mon, 30 May 2011 21:07:37 +0200 Reinhard Meyer  
 napsal(a):

> Dear Jan Pohanka,
>
>> I'm trying to get u-boot 2010.12 working on at91sam9260ek devkit with
>> mmc support. I have read several discussions here and followed the
>> steps described in README.atmel-mci. (my config and board file are
>> below...)
>
> 2010.12 is outdated. Use current top of tree. Besides I have a mmc  
> enabled
> (and working) 9260ek port in my WIP branch that I will post soon.
>
>> There are two issues I'm facing.
>>
>> The first one: When I enable mmc support, the dataflash stops to work.
>> According to info from boot process, dataflash is detected correctly,
>> but no data can be read (environment) or written.
>
> Dataflash and MMC are mutually exclusive on the 9260ek. Only one should  
> be
> enabled and used.
>
>> The second one: fatls command causes u-boot to freeze with following  
>> message
>
> You have to remove the CS jumper to the dataflash chip, otherwise you get
> contention between mmc and dataflash hardware.
>
> Reinhard


-- 
Tato zpráva byla vytvořena převratným poštovním klientem Opery:  
http://www.opera.com/mail/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] arm/km: add support for portl2 board

[Holger Brunck]

Hi Prafulla,

>> On 06/08/2011 10:35 AM, Prafulla Wadaskar wrote:
 Subject: [PATCH 2/6] arm/km: add support for portl2 board
>>>
>>> Can you add this board support after this patch series or last patch
>> in this series?
>>>
>>
>> hm, 3/6 and 5/6 has dependencies to the portl2 support patch, but I
>> think I can
>> handle this. So I will prepare an update serie 1/5 and a single patch
>> for the
>> portl2 support ok? But only for my curiosity, what the reason for this
>> need?
>>
> 
> :-)
> To me a patch series looks like updates/corrections to the existing code.
> Whereas new board support is addition, should be on the top of it.
> So let's keep them separate for better understanding.
> 

yes but in this case the board support patch will not work separated from the
updates. You won't be able to commit the single board support patch before
comitting the updates, so logically they belong together. Therefore I think it
is the best if I follow your first advice and place the board support patch at
the end of the serie.

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

[U-Boot] [PATCH v2][ARM][AT91] Build fix/update of AFEB9260

[Sergey Lapin]

Make AFEB9260 build again.
Based on fix for AT91SAM9260EK.

Signed-off-by: Sergey Lapin 
---
Cleaned-up a bit

 board/afeb9260/afeb9260.c  |  103 ---
 boards.cfg |2 +-
 include/configs/afeb9260.h |   28 +---
 3 files changed, 79 insertions(+), 54 deletions(-)

diff --git a/board/afeb9260/afeb9260.c b/board/afeb9260/afeb9260.c
index 3c37557..0269140 100644
--- a/board/afeb9260/afeb9260.c
+++ b/board/afeb9260/afeb9260.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #if defined(CONFIG_RESET_PHY_R) && defined(CONFIG_MACB)
 #include 
@@ -48,29 +48,29 @@ DECLARE_GLOBAL_DATA_PTR;
 static void afeb9260_nand_hw_init(void)
 {
unsigned long csa;
+   struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
+   struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
 
-   /* Enable CS3 */
-   csa = at91_sys_read(AT91_MATRIX_EBICSA);
-   at91_sys_write(AT91_MATRIX_EBICSA,
-  csa | AT91_MATRIX_CS3A_SMC_SMARTMEDIA);
+   /* Assign CS3 to NAND/SmartMedia Interface */
+   csa = readl(&matrix->ebicsa);
+   csa |= AT91_MATRIX_CS3A_SMC_SMARTMEDIA;
+   writel(csa, &matrix->ebicsa);
 
/* Configure SMC CS3 for NAND/SmartMedia */
-   at91_sys_write(AT91_SMC_SETUP(3),
-  AT91_SMC_NWESETUP_(0) | AT91_SMC_NCS_WRSETUP_(0) |
-  AT91_SMC_NRDSETUP_(0) | AT91_SMC_NCS_RDSETUP_(0));
-   at91_sys_write(AT91_SMC_PULSE(3),
-  AT91_SMC_NWEPULSE_(3) | AT91_SMC_NCS_WRPULSE_(3) |
-  AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3));
-   at91_sys_write(AT91_SMC_CYCLE(3),
-  AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5));
-   at91_sys_write(AT91_SMC_MODE(3),
-  AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
-  AT91_SMC_EXNWMODE_DISABLE |
-  AT91_SMC_DBW_8 |
-  AT91_SMC_TDF_(2));
-
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_PIOC);
-
+   writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
+   AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
+   &smc->cs[3].setup);
+   writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) |
+   AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3),
+   &smc->cs[3].pulse);
+   writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5),
+   &smc->cs[3].cycle);
+   writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
+   AT91_SMC_MODE_EXNW_DISABLE |
+   AT91_SMC_MODE_DBW_8 |
+   AT91_SMC_MODE_TDF_CYCLE(2),
+   &smc->cs[3].mode);
+ 
/* Configure RDY/BSY */
at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
 
@@ -81,10 +81,15 @@ static void afeb9260_nand_hw_init(void)
 #ifdef CONFIG_MACB
 static void afeb9260_macb_hw_init(void)
 {
-   unsigned long rstc;
+   struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+   struct at91_port *pioa = (struct at91_port *)ATMEL_BASE_PIOA;
+   struct at91_rstc *rstc = (struct at91_rstc *)ATMEL_BASE_RSTC;
+   unsigned long erstl;
+
+
+   /* Enable EMAC clock */
+   writel(1 << ATMEL_ID_EMAC0, &pmc->pcer);
 
-   /* Enable clock */
-   at91_sys_write(AT91_PMC_PCER, 1 << AT91SAM9260_ID_EMAC);
 
/*
 * Disable pull-up on:
@@ -103,24 +108,22 @@ static void afeb9260_macb_hw_init(void)
   pin_to_mask(AT91_PIN_PA25) |
   pin_to_mask(AT91_PIN_PA26) |
   pin_to_mask(AT91_PIN_PA28),
-  pin_to_controller(AT91_PIN_PA0) + PIO_PUDR);
+  &pioa->pudr);
 
-   rstc = at91_sys_read(AT91_RSTC_MR) & AT91_RSTC_ERSTL;
+   erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK;
 
/* Need to reset PHY -> 500ms reset */
-   at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-AT91_RSTC_ERSTL | (0x0D << 8) |
-AT91_RSTC_URSTEN);
-
-   at91_sys_write(AT91_RSTC_CR, AT91_RSTC_KEY | AT91_RSTC_EXTRST);
+   writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) |
+   AT91_RSTC_MR_URSTEN, &rstc->mr);
+   writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, &rstc->cr);
 
/* Wait for end hardware reset */
-   while (!(at91_sys_read(AT91_RSTC_SR) & AT91_RSTC_NRSTL));
-
+   while (!(readl(&rstc->sr) & AT91_RSTC_SR_NRSTL))
+   ;
/* Restore NRST value */
-   at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY |
-(rstc) |
-AT91_RSTC_URSTEN);
+   writel(AT91_RSTC_KEY | erstl | AT91_RSTC_MR_URSTEN,
+   &rstc->mr);
+
 
/* Re-enable pull-up */
writel(pin_to_mask(AT91_PIN_PA14) |
@@ -129,23 +132,29 @@ static void afeb9260_macb_hw_init(void)
   pin_to_mask(AT91_PIN_PA2

Re: [U-Boot] [PATCH 2/6] arm/km: add support for portl2 board

[Prafulla Wadaskar]

> -Original Message-
> From: Holger Brunck [mailto:holger.bru...@keymile.com]
> Sent: Wednesday, June 08, 2011 4:06 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Valentin Longchamp; Heiko Schocher
> Subject: Re: [PATCH 2/6] arm/km: add support for portl2 board
> 
> Hi Prafulla,
> 
> >> On 06/08/2011 10:35 AM, Prafulla Wadaskar wrote:
>  Subject: [PATCH 2/6] arm/km: add support for portl2 board
> >>>
> >>> Can you add this board support after this patch series or last patch
> >> in this series?
> >>>
> >>
> >> hm, 3/6 and 5/6 has dependencies to the portl2 support patch, but I
> >> think I can
> >> handle this. So I will prepare an update serie 1/5 and a single patch
> >> for the
> >> portl2 support ok? But only for my curiosity, what the reason for
> this
> >> need?
> >>
> >
> > :-)
> > To me a patch series looks like updates/corrections to the existing
> code.
> > Whereas new board support is addition, should be on the top of it.
> > So let's keep them separate for better understanding.
> >
> 
> yes but in this case the board support patch will not work separated
> from the
> updates. You won't be able to commit the single board support patch
> before
> comitting the updates, so logically they belong together. Therefore I
> think it
> is the best if I follow your first advice and place the board support
> patch at
> the end of the serie.

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

[U-Boot] [GIT PULL] Pull request: u-boot-imx

[Stefano Babic]

Hi Albert,

please pull from u-boot-imx.

The following changes since commit 6f4dd40cddbd69c56fec1285fee02cbd5a3833d8:

  Prepare v2011.06-rc2 (2011-06-02 23:19:27 +0200)

are available in the git repository at:
  git://www.denx.de/git/u-boot-imx.git master

Fabio Estevam (4):
  mx31ads: Use the new relocation scheme
  mx31litekit: Fix boot with the new relocation scheme.
  imx31_litekit: Remove local config.mk
  imx27lite: Remove local config.mk

Felix Radensky (1):
  mx31ads: Fix environment location on flash

 board/freescale/mx31ads/config.mk   |1 -
 board/freescale/mx31ads/mx31ads.c   |   19 +--
 board/freescale/mx31ads/u-boot.lds  |   42
+--
 board/logicpd/imx27lite/config.mk   |5 ---
 board/logicpd/imx31_litekit/config.mk   |1 -
 board/logicpd/imx31_litekit/imx31_litekit.c |   17 +++
 include/configs/imx27lite-common.h  |2 +
 include/configs/imx31_litekit.h |3 ++
 include/configs/mx31ads.h   |   21 +
 9 files changed, 78 insertions(+), 33 deletions(-)
 delete mode 100644 board/freescale/mx31ads/config.mk
 delete mode 100644 board/logicpd/imx27lite/config.mk
 delete mode 100644 board/logicpd/imx31_litekit/config.mk

Thanks,
Stefano

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

[U-Boot] [PATCH v2 2/5] arm/km: use board KM_ENV_BUS for CONFIG_I2C_ENV_EEPROM_BUS

[Holger Brunck]

From: Valentin Longchamp 

This is defined for all km_kirkwood boards and was not used up to now.
This value was the same for all boards but it could be changed for some
boards (and thus needs to be defined for every board).

Signed-off-by: Valentin Longchamp 
Signed-off-by: Holger Brunck 
cc: Prafulla Wadaskar 
cc: Heiko Schocher 
---
Changes for v2:
- the content is the same but patch is now 2/5 instead 5/6

 include/configs/km/km_arm.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index 5b0f1d8..d642ba1 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -215,7 +215,7 @@ int get_scl(void);
 #define CONFIG_SYS_EEPROM_WREN
 #define CONFIG_ENV_OFFSET  0x0 /* no bracets! */
 #define CONFIG_ENV_SIZE(0x2000 - CONFIG_ENV_OFFSET)
-#define CONFIG_I2C_ENV_EEPROM_BUS  "pca9547:70:d\0"
+#define CONFIG_I2C_ENV_EEPROM_BUS  KM_ENV_BUS "\0"
 
 /* offset redund: (CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) */
 #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
-- 
1.7.1

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

[U-Boot] [PATCH v2 0/5] updates for km ARM boards and board support for portl2

[Holger Brunck]

This is the second version of the patch serie with some reorganisation after 
some
comments of Prafulla Wadaskar the patch "arm/km: enable PCIE_INIT for Port-L2" 
was
split up into the "arm/km: replace suenx targets with km_kirkwood" and into the
board support patch for portl2. This board support patch is now patch 5/5.

Initial cover letter message:
Beside the board support some small cleanup was done and the phy_reset funtion
for mgcoge3un was implemented.

Additionaly the suen3 and suen8 target are collected in one
target km_kirkwood. For new targets which differ only in the
usage of the PCI interface on kirkwood a target km_kirkwood_pci
was introduced, but they use all the same header file.

All keymile boards compile cleanly and checkpatch reports no errors or
warnings. 

Holger Brunck (2):
  arm/km: remove unneeded define
  arm/km: replace suenx targets with km_kirkwood

Valentin Longchamp (3):
  arm/km: use board KM_ENV_BUS for CONFIG_I2C_ENV_EEPROM_BUS
  arm/km: ethernet support for mgcoge3un
  arm/km: add support for portl2 board

 MAINTAINERS|7 ++-
 MAKEALL|3 +-
 board/keymile/km_arm/km_arm.c  |   45 ++-
 boards.cfg |5 +-
 include/configs/km/km_arm.h|5 +--
 include/configs/{suen3.h => km_kirkwood.h} |   18 +--
 include/configs/mgcoge3un.h|5 ++
 include/configs/portl2.h   |   81 
 include/configs/suen8.h|   50 -
 9 files changed, 152 insertions(+), 67 deletions(-)
 rename include/configs/{suen3.h => km_kirkwood.h} (77%)
 create mode 100644 include/configs/portl2.h
 delete mode 100644 include/configs/suen8.h

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

[U-Boot] [PATCH v2 1/5] arm/km: remove unneeded define

[Holger Brunck]

CONFIG_ENV_SIZE for NAND was later in this file overwritten
because we have the environment in i2c eeprom, so remove
this define.

Signed-off-by: Holger Brunck 
Signed-off-by: Valentin Longchamp 
cc: Prafulla Wadaskar 
cc: Heiko Schocher 
---
Changes for v2:
- nothing

 include/configs/km/km_arm.h |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index 20ee6ea..5b0f1d8 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -50,7 +50,6 @@
 #include "keymile-common.h"
 
 #define CONFIG_SYS_TEXT_BASE   0x0400  /* code address after reloc */
-#define CONFIG_ENV_SIZE(128 << 10) /* NAND chip block size 
*/
 #define CONFIG_SYS_MEMTEST_START 0x0040/* 4M */
 #define CONFIG_SYS_MEMTEST_END 0x007f  /*(_8M -1) */
 #define CONFIG_SYS_LOAD_ADDR   0x0080  /* default load adr- 8M */
@@ -215,7 +214,6 @@ int get_scl(void);
 #define CONFIG_ENV_EEPROM_IS_ON_I2C
 #define CONFIG_SYS_EEPROM_WREN
 #define CONFIG_ENV_OFFSET  0x0 /* no bracets! */
-#undef CONFIG_ENV_SIZE
 #define CONFIG_ENV_SIZE(0x2000 - CONFIG_ENV_OFFSET)
 #define CONFIG_I2C_ENV_EEPROM_BUS  "pca9547:70:d\0"
 
-- 
1.7.1

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

[U-Boot] [PATCH v2 3/5] arm/km: ethernet support for mgcoge3un

[Holger Brunck]

From: Valentin Longchamp 

The phy is also configured with "RGMII clock transitions when data
stable" and "Class A driver for the direct backplane connection".

Signed-off-by: Valentin Longchamp 
Signed-off-by: Holger Brunck 
cc: Prafulla Wadaskar 
cc: Heiko Schocher 
---
Changes for v2:
- first version has also defines for portl2, they were removed because
  the board support for portl2 has moved to the end of the serie

 board/keymile/km_arm/km_arm.c |   39 ++-
 1 files changed, 38 insertions(+), 1 deletions(-)

diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index d86acc9..ed6ede3 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -335,7 +335,42 @@ void dram_init_banksize(void)
}
 }
 
-/* Configure and enable MV88E1118 PHY */
+#if defined(CONFIG_MGCOGE3UN)
+
+#definePHY_LED_SEL 0x18
+#define PHY_LED0_LINK  (0x5)
+#define PHY_LED1_ACT   (0x8<<4)
+#define PHY_LED2_INT   (0xe<<8)
+#definePHY_SPEC_CTRL   0x1c
+#define PHY_RGMII_CLK_STABLE   (0x1<<10)
+#define PHY_CLSA   (0x1<<1)
+
+/* Configure and enable MV88E3018 PHY */
+void reset_phy(void)
+{
+   char *name = "egiga0";
+   unsigned short reg;
+
+   if (miiphy_set_current_dev(name))
+   return;
+
+   /* RGMII clk transition on data stable */
+   if (miiphy_read(name, CONFIG_PHY_BASE_ADR, PHY_SPEC_CTRL, ®) != 0)
+   printf("Error reading PHY spec ctrl reg\n");
+   if (miiphy_write(name, CONFIG_PHY_BASE_ADR, PHY_SPEC_CTRL,
+   reg | PHY_RGMII_CLK_STABLE | PHY_CLSA) != 0)
+   printf("Error writing PHY spec ctrl reg\n");
+
+   /* leds setup */
+   if (miiphy_write(name, CONFIG_PHY_BASE_ADR, PHY_LED_SEL,
+   PHY_LED0_LINK | PHY_LED1_ACT | PHY_LED2_INT) != 0)
+   printf("Error writing PHY LED reg\n");
+
+   /* reset the phy */
+   miiphy_reset(name, CONFIG_PHY_BASE_ADR);
+}
+#else
+/* Configure and enable MV88E1118 PHY on the piggy*/
 void reset_phy(void)
 {
char *name = "egiga0";
@@ -346,6 +381,8 @@ void reset_phy(void)
/* reset the phy */
miiphy_reset(name, CONFIG_PHY_BASE_ADR);
 }
+#endif
+
 
 #if defined(CONFIG_HUSH_INIT_VAR)
 int hush_init_var(void)
-- 
1.7.1

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

[U-Boot] [PATCH v2 4/5] arm/km: replace suenx targets with km_kirkwood

[Holger Brunck]

suen3 and suen8 were in first HW version quite different, but
now they are from a u-boot point of view similar. So these
two boards can use the same header file. Other keymile boards
differ only in the usage of the PCI interface. Therefore
a target km_kirkwood_pci was introduced. All targets use
the same header file.

Signed-off-by: Holger Brunck 
Signed-off-by: Valentin Longchamp 
cc: Prafulla Wadaskar 
cc: Heiko Schocher 
---
Changes for v2:
- squashed together with 5/6 from previous serie, because
  the pci defines belongs logically to this patch
- change typo in board maintainers name

 MAINTAINERS|6 ++-
 MAKEALL|2 +-
 boards.cfg |4 +-
 include/configs/km/km_arm.h|1 -
 include/configs/{suen3.h => km_kirkwood.h} |   18 +++---
 include/configs/mgcoge3un.h|5 +++
 include/configs/suen8.h|   50 
 7 files changed, 25 insertions(+), 61 deletions(-)
 rename include/configs/{suen3.h => km_kirkwood.h} (77%)
 delete mode 100644 include/configs/suen8.h

diff --git a/MAINTAINERS b/MAINTAINERS
index c462ae2..d1ec392 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -726,6 +726,10 @@ Sergey Lapin 
 
afeb9260ARM926EJS (AT91SAM9260 SoC)
 
+Valentin Longchamp 
+
+   km_kirkwood ARM926EJS (Kirkwood SoC)
+
 Nishanth Menon 
 
omap3_sdp3430   ARM ARMV7 (OMAP3xx SoC)
@@ -814,8 +818,6 @@ Heiko Schocher 
 
magnesium   i.MX27
mgcoge3un   ARM926EJS (Kirkwood SoC)
-   suen3   ARM926EJS (Kirkwood SoC)
-   suen8   ARM926EJS (Kirkwood SoC)
 
 Robert Schwebel 
 
diff --git a/MAKEALL b/MAKEALL
index d592374..1798303 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -347,6 +347,7 @@ LIST_ARM9=" \
guruplug\
imx27lite   \
jadecpu \
+   km_kirkwood \
lpd7a400\
magnesium   \
mv88f6281gtw_ge \
@@ -373,7 +374,6 @@ LIST_ARM9=" \
spear310\
spear320\
spear600\
-   suen3   \
trab\
VCMA9   \
versatile   \
diff --git a/boards.cfg b/boards.cfg
index d2cacc8..6a50236 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -106,8 +106,8 @@ davinci_dvevmarm arm926ejs   dvevm  
 davinci
 davinci_schmoogiearm arm926ejs   schmoogie   
davincidavinci
 davinci_sffsdr   arm arm926ejs   sffsdr  
davincidavinci
 davinci_sonata   arm arm926ejs   sonata  
davincidavinci
-suen3arm arm926ejs   km_arm  
keymilekirkwood
-suen8arm arm926ejs   km_arm  
keymilekirkwood
+km_kirkwood  arm arm926ejs   km_arm  
keymilekirkwood   km_kirkwood:KM_DISABLE_PCI
+km_kirkwood_pci  arm arm926ejs   km_arm  
keymilekirkwood   km_kirkwood
 mgcoge3unarm arm926ejs   km_arm  
keymilekirkwood
 guruplug arm arm926ejs   -   
Marvellkirkwood
 mv88f6281gtw_ge  arm arm926ejs   -   
Marvellkirkwood
diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
index d642ba1..c422d57 100644
--- a/include/configs/km/km_arm.h
+++ b/include/configs/km/km_arm.h
@@ -77,7 +77,6 @@
 #define CONFIG_MD5 /* get_random_hex on krikwood needs MD5 support */
 #define CONFIG_SKIP_LOWLEVEL_INIT  /* disable board lowlevel_init */
 #define CONFIG_KIRKWOOD_EGIGA_INIT /* Enable GbePort0/1 for kernel */
-#undef  CONFIG_KIRKWOOD_PCIE_INIT  /* Disable PCIE Port0 for kernel */
 #define CONFIG_KIRKWOOD_RGMII_PAD_1V8  /* Set RGMII Pad voltage to 1.8V */
 
 #define CONFIG_MISC_INIT_R
diff --git a/include/configs/suen3.h b/include/configs/km_kirkwood.h
similarity index 77%
rename from include/configs/suen3.h
rename to include/configs/km_kirkwood.h
index 0f1b11e..e51b270 100644
--- a/include/configs/suen3.h
+++ b/include/configs/km_kirkwood.h
@@ -6,6 +6,9 @@
  * (C) Copyright 2009
  * Stefan Roese, DENX Software Engineering, s...@denx.de.
  *
+ * (C) Copyright 2011
+ * Holger Brunck, Keymile GmbH Hannover, holger.bru...@keymile.de
+ *
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -30,8 +33,8 @@
  * http://lists.denx.de/pipermail/u-boot/2009-July/057350.html
  */
 
-#ifndef _CONFIG_SUEN3_H
-#define _CONFIG_SUEN3_H
+#ifndef _CONFIG_KM_KIRKWOOD_H
+#define _CONFIG_KM_KIRKWOOD_H
 
 /* inc

[U-Boot] [PATCH v2 5/5] arm/km: add support for portl2 board

[Holger Brunck]

From: Valentin Longchamp 

This adds support for the keymile Kirkwood BEC portl2 board. This board
relies on the km_arm (km_kirkwood) BEC.

The egiga driver is configured for a 100M full-duplex, A/N off connnection
to the backplane. This board has always ethernet present, because it is
connected to the marvell switch similar to mgcoge3un. The reset_phy
functionality is also the same to mgcoge3un.

Signed-off-by: Valentin Longchamp 
Signed-off-by: Holger Brunck 
cc: Prafulla Wadaskar 
cc: Heiko Schocher 
---
Changes for v2:
   - add this board support patch to the end of the serie

 MAINTAINERS   |1 +
 MAKEALL   |1 +
 board/keymile/km_arm/km_arm.c |8 +++--
 boards.cfg|1 +
 include/configs/portl2.h  |   81 +
 5 files changed, 89 insertions(+), 3 deletions(-)
 create mode 100644 include/configs/portl2.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d1ec392..653c928 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -729,6 +729,7 @@ Sergey Lapin 
 Valentin Longchamp 
 
km_kirkwood ARM926EJS (Kirkwood SoC)
+   portl2  ARM926EJS (Kirkwood SoC)
 
 Nishanth Menon 
 
diff --git a/MAKEALL b/MAKEALL
index 1798303..3f92449 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -364,6 +364,7 @@ LIST_ARM9=" \
openrd_base \
openrd_client   \
openrd_ultimate \
+   portl2  \
rd6281a \
sbc2410x\
scb9328 \
diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c
index ed6ede3..5da856f 100644
--- a/board/keymile/km_arm/km_arm.c
+++ b/board/keymile/km_arm/km_arm.c
@@ -130,10 +130,12 @@ int startup_allowed(void)
return 1;
return 0;
 }
+#endif
 
+#if (defined(CONFIG_MGCOGE3UN)|defined(CONFIG_PORTL2))
 /*
- * mgcoge3un has always ethernet present. Its connected to the 6061 switch
- * and provides ICNev and piggy4 connections.
+ * These two boards have always ethernet present. Its connected to the mv
+ * switch.
  */
 int ethernet_present(void)
 {
@@ -335,7 +337,7 @@ void dram_init_banksize(void)
}
 }
 
-#if defined(CONFIG_MGCOGE3UN)
+#if (defined(CONFIG_MGCOGE3UN)|defined(CONFIG_PORTL2))
 
 #definePHY_LED_SEL 0x18
 #define PHY_LED0_LINK  (0x5)
diff --git a/boards.cfg b/boards.cfg
index 6a50236..649f1af 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -109,6 +109,7 @@ davinci_sonata   arm arm926ejs   sonata 
 davinci
 km_kirkwood  arm arm926ejs   km_arm  
keymilekirkwood   km_kirkwood:KM_DISABLE_PCI
 km_kirkwood_pci  arm arm926ejs   km_arm  
keymilekirkwood   km_kirkwood
 mgcoge3unarm arm926ejs   km_arm  
keymilekirkwood
+portl2   arm arm926ejs   km_arm  
keymilekirkwood
 guruplug arm arm926ejs   -   
Marvellkirkwood
 mv88f6281gtw_ge  arm arm926ejs   -   
Marvellkirkwood
 openrd_base  arm arm926ejs   openrd  
Marvellkirkwoodopenrd:BOARD_IS_OPENRD_BASE
diff --git a/include/configs/portl2.h b/include/configs/portl2.h
new file mode 100644
index 000..a8543a5
--- /dev/null
+++ b/include/configs/portl2.h
@@ -0,0 +1,81 @@
+/*
+ * (C) Copyright 2009
+ * Marvell Semiconductor 
+ * Prafulla Wadaskar 
+ *
+ * (C) Copyright 2009
+ * Stefan Roese, DENX Software Engineering, s...@denx.de.
+ *
+ * (C) Copyright 2010-2011
+ * Holger Brunck, Keymile GmbH Hannover, holger.bru...@keymile.com.
+ * Valentin Longchamp, Keymile AG Bern, valentin.longch...@keymile.com
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ */
+
+/* for linking errors see
+ * http://lists.denx.de/pipermail/u-boot/2009-July/057350.html */
+
+#ifndef _CONFIG_PORTL2_H
+#define _CONFIG_PORTL2_H
+
+/* include common defines/options for all arm based Keymile boards */
+#include "km/km_arm.h"
+
+/*
+ * Version number info

[U-Boot] [PATCH] powerpc/8xxx: Update USB mode device tree fixup

[Ramneek Mehresh]

Modify support for USB mode fixup:
- Add common support for USB mode and phy type
  device tree fix-up for all USB controllers
  mentioned in hwconfig string
- Fetch USB mode and phy type via hwconfig; if not
  defined in hwconfig, then fetch them from env

Signed-off-by: Ramneek Mehresh 
---
 arch/powerpc/cpu/mpc8xxx/fdt.c |   77 +--
 1 files changed, 65 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/cpu/mpc8xxx/fdt.c b/arch/powerpc/cpu/mpc8xxx/fdt.c
index 520cb90..d9e3e7e 100644
--- a/arch/powerpc/cpu/mpc8xxx/fdt.c
+++ b/arch/powerpc/cpu/mpc8xxx/fdt.c
@@ -29,6 +29,10 @@
 #include 
 #include 
 #include 
+#include 
+#ifdef CONFIG_HAS_FSL_DR_USB
+#include 
+#endif
 
 #if defined(CONFIG_MP) && (defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx))
 static int ft_del_cpuhandle(void *blob, int cpuhandle)
@@ -84,22 +88,18 @@ void ft_fixup_num_cores(void *blob) {
 #endif /* defined(CONFIG_MPC85xx) || defined(CONFIG_MPC86xx) */
 
 #ifdef CONFIG_HAS_FSL_DR_USB
-void fdt_fixup_dr_usb(void *blob, bd_t *bd)
+static void fdt_fixup_usb_mode_phy_type(void *blob, const char *mode,
+   const char *phy_type)
 {
-   char *mode;
-   char *type;
const char *compat = "fsl-usb2-dr";
const char *prop_mode = "dr_mode";
const char *prop_type = "phy_type";
+   static int start_offset = -1;
int node_offset;
int err;
 
-   mode = getenv("usb_dr_mode");
-   type = getenv("usb_phy_type");
-   if (!mode && !type)
-   return;
-
-   node_offset = fdt_node_offset_by_compatible(blob, 0, compat);
+   node_offset = fdt_node_offset_by_compatible(blob,
+   start_offset, compat);
if (node_offset < 0) {
printf("WARNING: could not find compatible node %s: %s.\n",
compat, fdt_strerror(node_offset));
@@ -114,13 +114,66 @@ void fdt_fixup_dr_usb(void *blob, bd_t *bd)
   prop_mode, compat, fdt_strerror(err));
}
 
-   if (type) {
-   err = fdt_setprop(blob, node_offset, prop_type, type,
- strlen(type) + 1);
+   if (phy_type) {
+   err = fdt_setprop(blob, node_offset, prop_type, phy_type,
+ strlen(phy_type) + 1);
if (err < 0)
printf("WARNING: could not set %s for %s: %s.\n",
   prop_type, compat, fdt_strerror(err));
}
+
+   start_offset = node_offset;
+}
+
+void fdt_fixup_dr_usb(void *blob, bd_t *bd)
+{
+   const char *modes[] = { "host", "peripheral", "otg" };
+   const char *phys[] = { "ulpi", "umti" };
+   const char *mode = NULL;
+   const char *phy_type = NULL;
+   char usb1_defined = 0;
+   char str[5];
+   int i, j;
+
+   for (i = 1; i <= USB_MAX_DEVICE; i++) {
+   int mode_idx = -1, phy_idx = -1;
+   sprintf(str, "%s%d", "usb", i);
+   if (hwconfig(str)) {
+   for (j = 0; j < sizeof(modes); j++) {
+   if (hwconfig_subarg_cmp(str, "dr_mode",
+   modes[j])) {
+   mode_idx = j;
+   break;
+   }
+   }
+   for (j = 0; j < sizeof(phys); j++) {
+   if (hwconfig_subarg_cmp(str, "phy_type",
+   phys[j])) {
+   phy_idx = j;
+   break;
+   }
+   }
+   if (mode_idx >= 0)
+   fdt_fixup_usb_mode_phy_type(blob,
+   modes[mode_idx], NULL);
+   if (phy_idx >= 0)
+   fdt_fixup_usb_mode_phy_type(blob,
+   NULL, phys[phy_idx]);
+   if (!strcmp(str, "usb1"))
+   usb1_defined = 1;
+   if (mode_idx < 0 && phy_idx < 0)
+   printf("WARNING: invalid phy or mode\n");
+   } else {
+   break;
+   }
+   }
+   if (!usb1_defined) {
+   mode = getenv("usb_dr_mode");
+   phy_type = getenv("usb_phy_type");
+   if (!mode && !phy_type)
+   return;
+   fdt_fixup_usb_mode_phy_type(blob, mode, phy_type);
+   }
 }
 #endif /* CONFIG_HAS_FSL_DR_USB */
 
-- 
1.6.1


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

Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros

[Aneesh V]

Dear Wolfgang,

On Tuesday 07 June 2011 09:10 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dee161b.2050...@ti.com>  you wrote:
>>
 So, if I have to write 5 different fields in a register I first write
 them into a variable and finally call writel() instead of making 5
 clrsetbits*() calls.
>>>
>>> It does not make much difference to me if you call one macro or
>>> another 5 times.
>>
>> No it makes a difference. It's 5 writes to a variable typically in an
>> ARM register + 1 IO access vs 5 IO accesses. It's logically not
>> equivalent.
>
> You can use in_le32() to read the register in a variable, a number of
> macros operating on that variable, and then a out_le32() to write it
> back.
>
> It's logically equivalent.
>
>> Further if the 5 values are constants a smart compiler will fold the
>> five writes into one write to the ARM register + 1 IO access, which
>> won't happen if you used 5 clrsetbits*()
>
> See above.
>
> If you ever want to use your macros on device registers, you MUST use
> proper memory barriers.  This will probably ruin your idea to combine
> the access into a single write.  So you can just work on a variable as
> suggested before.
>
>> Problem: We want to read-modify-write an IO register 'reg' affecting 3
>> different fields: a, b, and c. The values to be written to the fields
>> are a_val, b_val, and c_val respectively:
>>
>> Solution 1 - without any macros:
>>
>> unsigned int r = readl(reg);
>> r = (r&  ~a_mask) | ((a_val<<  a_shift)&  a_mask)
>> r = (r&  ~b_mask) | ((b_val<<  b_shift)&  b_mask)
>> r = (r&  ~c_mask) | ((c_val<<  c_shift)&  c_mask)
>> writel(r, reg);
>>
>> Solution2 - with my macros:
>>
>> unsigned int r = readl(reg);
>> set_bit_field(r, a, a_val);
>> set_bit_field(r, b, b_val);
>> set_bit_field(r, c, c_val);
>> writel(r, reg);
>>
>> Solution3 - with clrsetbits*():
>>
>> clrsetbits_le32(reg, a_mask, a_val<<  a_shift);
>> clrsetbits_le32(reg, b_mask, b_val<<  b_shift);
>> clrsetbits_le32(reg, c_mask, c_val<<  c_shift);
>
> Solution 4 - with standard macros, and proper defines:
>
>   unsigned int r = in_le32(reg);  /* or readl() if you like */
>
>   clrsetbits_le32(&r, a_mask, a_val);
>   clrsetbits_le32(&r, b_mask, b_val);
>   clrsetbits_le32(&r, c_mask, c_val);
>
>   out_le32(reg, r);

I still don't think this is the 'right' solution for my problem. I don't
like the fact that clrsetbits_le32() introduces a lot of un-necessary
'volatile's.

Yes, it's about the 'efficiency'. May be it doesn't count in some
cases. But, may be it counts in some other cases. Basically, I don't
like to sacrifice 'efficiency' unless the cost for achieving it is very
high. I don't think having an extra helper function is a big cost.
Neither do I believe that readability suffers in this case.

If you still insist, I can use clrsetbits_le32() in the interest
of getting this to a closure.

>
> Actually solution 3 looks best to me.
>
>> Solution 3 is not acceptable to me because it's clearly not equivalent
>> to what I want to do. Writing the register 3 times instead of once may
>> have undesirable side-effects. Even if it worked, it's clearly not
>> efficient.
>
> In case of side effects you can use solution 4.
>
> We should not bother here about wether this is "efficient" or "not
> efficient".  Probably none opf this code is ever time critical, not to
> the extent of a few additional instructions.
>
>> If you are forcing me to use solution 1, IMHO you are essentially
>> forcing me not to use a sub-routine for a task that is repeated many
>> times in my code, leaving my code to be more error prone and less
>> readable.
>
> I agree that 1 is ugly and error prone, but there is no need to use
> it.
>
> I repeat:  we have a set of powerful macros ready available.  Just use
> them.

We have a set of powerful macros designed for bit-field accesses in IO
egisters.

But, what I am looking for is a set of macros for bit-field operations
on C integer variables without the un-necessary overhead of IO register
accesses. I am looking for missing APIs in bitops.h not anything from
io.h

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

[U-Boot] OpenRD: booting u-boot from NAND

[Alexei Ozhigov]

Hello!

I am trying to launch U-Boot v2011.06-rc2 built with Codesourcery 2011
toolchain on OpenRD Ultimate board with no luck so far.
After resetting the board hangs without any symbols being printed on
console. OpenOCD shows PC value of 0x0BA6 (not 4-byte aligned!)
after halting the core.
The strange thing is that the image boots up successfully if booted
from SDRAM. U-boot-1.1.4 with the patch from open-rd.org does boot
from NAND.


Any suggestions on why booting from NAND is not working?

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

[U-Boot] Download the u-boot from flash back to PC

[Rishi Dhupar]

I have a board which has a version of u-boot on it that I would like
to save before overwriting. I did not flash this version so I do not
have the source code for it.

I am trying to figure out is there away to essentially do a 'tftp get'
of the u-boot.bin that was originally written to flash.  I do not see
any methods to "read" data from U-boot back to the PC.  Is there any
method to do this?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] P4080DS: RDIMM support

[Joyce, Richard]

Re:  http://lists.denx.de/pipermail/u-boot/2011-March/088152.html


Specifically mentionssupport for a Virtium RDIMM: VL33B5163F-K9S
But I don't see this part in the Virtium product support web site.

Would like to contact the person who entered this commit  item, perhaps it is a 
typo.
Would like to get an idea of the general parameters of the 'working'  Virtium 
device,
I am trying to get  RDIMM  VL33B5263A-K9S  to work.

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

Re: [U-Boot] Download the u-boot from flash back to PC

[Detlev Zundel]

Hi Rishi,

> I have a board which has a version of u-boot on it that I would like
> to save before overwriting. I did not flash this version so I do not
> have the source code for it.
>
> I am trying to figure out is there away to essentially do a 'tftp get'
> of the u-boot.bin that was originally written to flash.  I do not see
> any methods to "read" data from U-boot back to the PC.  Is there any
> method to do this?

The only thing that I know of is CONFIG_CMD_SAVES which does a "save S
record over serial line" (check common/cmd_load.c).  It is likely that
your binary U-Boot does noe have this feature though (it is not in
config_cmd_default, so the board maintainer has to define it
explicitely).

When I needed to do this, I could either attach a BDI3000 which can do a
tftp put (remember to create the file on the host first, otherwise it
will fail silently!), or I used a linux kernel that was able to read
U-Boot through the mtd interface.

If you decide to implement a "tftpput" command, I for one would find
this a very nice addition indeed ;)

Cheers
  Detlev

-- 
Question: If you were redesigning UNIX, what would you do differently?
Ken Thompson: I'd spell creat with an e.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] dreamplug: Initial support.

[Jason]

On Wed, Jun 08, 2011 at 12:51:01AM -0700, Prafulla Wadaskar wrote:
> 
> 
> > -Original Message-
> > From: u-b...@lakedaemon.net [mailto:u-b...@lakedaemon.net]
> > Sent: Tuesday, June 07, 2011 11:07 PM
> > To: u-boot@lists.denx.de
> > Cc: Prafulla Wadaskar; Siddarth Gore; Jason Cooper
> > Subject: [PATCH 1/1] dreamplug: Initial support.
> > 
> > From: Jason Cooper 
> > 
> > Copied files from boards/Marvell/guruplug/ and did
> > s/GURUPLUG/DREAMPLUG/g
> > s/guruplug/dreamplug/g
> > 
> > Switched from NAND flash to SPI flash.
> > MPP._SPI_ configuration copied from
> > boards/Marvell/mv88f6281gtw_ge/mv88f6281gtw_ge.c
> >

Prafulla,

Please note: I literally copied the files from boards/Marvell/guruplug,
and then copied the SPI config from the mv88f6281gtw_ge...  There isn't
a single original thought of mine in there. ;-)
 
> > Also, MACH_TYPE_DREAMPLUG (board id 3550) has been registered at
> > http://www.arm.linux.co.uk/developer/machines/, once support has
> > been added to mainline Linux, we'll update the board id here.
> > For now, we use MACH_TYPE_GURUPLUG, just as the factory U-Boot does.
> > 
> > Signed-off-by: Jason Cooper 
> > ---
> >  MAINTAINERS  |1 +
> >  MAKEALL  |1 +
> >  board/Marvell/dreamplug/Makefile |   51 +++
> >  board/Marvell/dreamplug/dreamplug.c  |  154
> > 
> >  board/Marvell/dreamplug/dreamplug.h  |   39 
> >  board/Marvell/dreamplug/kwbimage.cfg |  160
> > ++
> >  boards.cfg   |1 +
> >  include/configs/dreamplug.h  |  111 +++
> >  8 files changed, 518 insertions(+), 0 deletions(-)
> >  create mode 100644 board/Marvell/dreamplug/Makefile
> >  create mode 100644 board/Marvell/dreamplug/dreamplug.c
> >  create mode 100644 board/Marvell/dreamplug/dreamplug.h
> >  create mode 100644 board/Marvell/dreamplug/kwbimage.cfg
> >  create mode 100644 include/configs/dreamplug.h
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index c462ae2..c3711a8 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -202,6 +202,7 @@ Niklaus Giger 
> >  Siddarth Gore 
> > 
> > guruplugARM926EJS (Kirkwood SoC)
> > +   dreamplug   ARM926EJS (Kirkwood SoC)
> 
> Dreamplug entry should be under your name. maintain alphabetical order too.
>

Ok, I assumed I didn't have enough experience yet.  No problem.

> > 
> >  Paul Gortmaker 
> > 
> > diff --git a/MAKEALL b/MAKEALL
> > index d592374..35fc5b7 100755
> > --- a/MAKEALL
> > +++ b/MAKEALL
> > @@ -345,6 +345,7 @@ LIST_ARM9=" \
> > edb9315a\
> > edminiv2\
> > guruplug\
> > +   dreamplug   \
> 
> Not in order.
> 

Ok.

> > imx27lite   \
> > jadecpu \
> > lpd7a400\
> > diff --git a/board/Marvell/dreamplug/Makefile
> > b/board/Marvell/dreamplug/Makefile
> > new file mode 100644
> > index 000..b7e5270
> > --- /dev/null
> > +++ b/board/Marvell/dreamplug/Makefile
> > @@ -0,0 +1,51 @@
> > +#
> > +# (C) Copyright 2009
> 
> 2011 ?? and everywhere
> 

This probably needs to be fixed throughout the boards/Marvell/*
codebase.  Can I do that since I'm not Marvell?  If so, I'll do a
separate patch.

> > +# Marvell Semiconductor 
> > +# Written-by: Siddarth Gore 
> 
> You can say, based on or referenced from..
> You as an author should reflect for the new files being added.
> 

Will do, but see my above comment about no original thoughts. ;-)  

> > +#
> > +# See file CREDITS for list of people who contributed to this
> > +# project.
> > +#
> > +# This program is free software; you can redistribute it and/or
> > +# modify it under the terms of the GNU General Public License as
> > +# published by the Free Software Foundation; either version 2 of
> > +# the License, or (at your option) any later version.
> > +#
> > +# This program is distributed in the hope that it will be useful,
> > +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > +# GNU General Public License for more details.
> > +#
> > +# You should have received a copy of the GNU General Public License
> > +# along with this program; if not, write to the Free Software
> > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> > +# MA 02110-1301 USA
> > +#
> > +
> > +include $(TOPDIR)/config.mk
> > +
> > +LIB= $(obj)lib$(BOARD).o
> > +
> > +COBJS  := dreamplug.o
> > +
> > +SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> > +OBJS   := $(addprefix $(obj),$(COBJS))
> > +SOBJS  := $(addprefix $(obj),$(SOBJS))
> > +
> > +$(LIB):$(obj).depend $(OBJS) $(SOBJS)
> > +   $(call cmd_link_o_target, $(OBJS) $(SOBJS))
> > +
> > +clean:
> > +   rm -f $(SOBJS) $(OBJS)
> > +
> > +distclean: clean
> > +   rm -f $(LIB) core *.bak .depe

Re: [U-Boot] Download the u-boot from flash back to PC

[Jason]

On Wed, Jun 08, 2011 at 09:25:42AM -0400, Rishi Dhupar wrote:
> I have a board which has a version of u-boot on it that I would like
> to save before overwriting. I did not flash this version so I do not
> have the source code for it.

funny how often that happens... :-(
 
> I am trying to figure out is there away to essentially do a 'tftp get'
> of the u-boot.bin that was originally written to flash.  I do not see
> any methods to "read" data from U-boot back to the PC.  Is there any
> method to do this?

Here's what I've done in the past.

WARNING: read everything _before_ you start!

1.) On the device, in U-Boot, zero out some memory (1MB at 0x080)

$ mw.b 0x080 0x00 0x10

2.) Read the bootloader into RAM at 0x080, size 1MB, offset into
nand, 0x300. 

$ nand read 0x080 0x300 0x10

3.) close your minicom/screen/whatever that you are using to talk to the
serial port.  On your desktop, run the following:

$ printf "md.b 0x080 0x10\r\r" | \
socat - /dev/ttyUSB0,raw,echo=0,crnl >u-boot.ascii 2>&1

This will take a while (10 - 20 minutes!), in another terminal, setup a
watch:

$ watch -n3 "ls -l u-boot.ascii"

4.) prep the ascii file for conversion to binary.
a.) remove the first and last lines
b.) start the address numbers (first column) at 0, eg

$ sed -i.bak -r -e 's/^008/000/' -e 's/^009/001/' u-boot.ascii

5.) Convert ascii to binary

$ xxd -r u-boot.ascii u-boot.bin

Notes: Obviously, your addresses and sizes are going to be different,
you may need to use 'sudo socat' for step 3.  This is from memory, I
just did it a week ago though.  You could always replace xxd with some
sort of sed/awk script.

hth,

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

Re: [U-Boot] [PATCH 1/5] Tegra2: Add bitfield access macros

[Simon Glass]

Hi Wolfgang,

On Tue, Jun 7, 2011 at 1:00 PM, Wolfgang Denk  wrote:
> Dear Simon Glass,
>
> In message  you wrote:
>>
>> >        clrsetbits_le32(&my_device->ctrl, FIELD_MASK, FIELD_VAL(6));
>>
>> We now have a computed mask which is good, thank you.
>>
>> But the FIELD is specified twice in the same statement. Can we
>> therefore please take this a step further and write something like
>> this?
>>
>> clrsetfield_le32(&my_device->ctrl, FIELD, 6);
>
> I think I should provide a little moe explanation why I dislike your
> suggestion.  With "FOO_MASK, FOO_VAL()" it is obvious to the
> reader that we are dealing ith some (bit) mask and some value, and it
> is also trivial to locate the respective definitions of these macros,
> because you know their exact names.
>
> With "FOO, 6" you know nothing.  Searching for "FOO" in the source
> code and header files will probably return a ton of unrelated
> references, and you will have to read (and understand) the definition
> of the bitfield macro and follow it's preprocessor trickery with
> combining some magic name parts until you finally know what to look
> for.

I don't agree. Going back to the original patch, the macro allow us to
write this code to read/write bias time for example (showing header
and C file):

#define UTMIP_BIAS_PDTRK_COUNT_RANGE7:3

bf_writel(UTMIP_BIAS_PDTRK_COUNT, params->bias_time,
&usbctlr->utmip_bias_cfg1);

and we also have a lot of things like this (Note: this code line is
made up and isn't actually in the code):
return bf_readl(UTMIP_BIAS_PDTRK_COUNT, &usbctlr->utmip_bias_cfg1);

By the way a grep for UTMIP_BIAS_PDTRK_COUNT pulls up exactly what I
would expect:

$ ack UTMIP_BIAS_PDTRK_COUNT |more
arch/arm/include/asm/arch-tegra2/usb.h:162:#define
UTMIP_BIAS_PDTRK_COUNT_RANGE7:3
board/nvidia/common/usb.c:202:  bf_writel(UTMIP_BIAS_PDTRK_COUNT,
params->bias_time,
$

What you are asking for is I think something like:

#define UTMIP_BIAS_PDTRK_COUNT_SHIFT 4
#define UTMIP_BIAS_PDTRK_COUNT_MASK (0xf << UTMIP_BIAS_PDTRK_COUNT_SHIFT)
#define UTMIP_BIAS_PDTRK_COUNT_VAL(v) \
  ((v << UTMIP_BIAS_PDTRK_COUNT_SHIFT) & UTMIP_BIAS_PDTRK_COUNT_MASK)
#define UTMIP_BIAS_PDTRK_COUNT_EXTRACT(v) \
  ((v & UTMIP_BIAS_PDTRK_COUNT_MASK) >> UTMIP_BIAS_PDTRK_COUNT_SHIFT)

clrsetbits_le32(&usbctlr->utmip_bias_cfg1, UTMIP_BIAS_PDTRK_COUNT_MASK,
UTMIP_BIAS_PDTRK_COUNT_VAL(params->bias_time));
return UTMIP_BIAS_PDTRK_COUNT_EXTRACT(readl(&usbctlr->utmip_bias_cfg1))


Going further back now to use explicit shifts in the C code, we have:

#define UTMIP_BIAS_PDTRK_COUNT_SHIFT 4
#define UTMIP_BIAS_PDTRK_COUNT_MASK (0xf << UTMIP_BIAS_PDTRK_COUNT_SHIFT)

clrsetbits_le32(&usbctlr->utmip_bias_cfg1, UTMIP_BIAS_PDTRK_COUNT_MASK,
params->bias_time << UTMIP_BIAS_PDTRK_COUNT_SHIFT);
return (readl(&usbctlr->utmip_bias_cfg1) & UTMIP_BIAS_PDTRK_COUNT_MASK) >>
UTMIP_BIAS_PDTRK_COUNT_SHIFT;

and the original idea again:

#define UTMIP_BIAS_PDTRK_COUNT_RANGE7:3

bf_writel(UTMIP_BIAS_PDTRK_COUNT, params->bias_time,
&usbctlr->utmip_bias_cfg1);
return bf_readl(UTMIP_BIAS_PDTRK_COUNT, &usbctlr->utmip_bias_cfg1);

>
> You consider this macro helpful, I consider it obscure, and that's why
> I don't want to have it.

So yes you need to learn the macros, but once you have done that
(which takes maybe 10 minutes if you haven't had your coffee yet)
things are easier. Also, the datasheet has things like:

Bit:
13:8UTMIP_BIAS_TCTRL
7:3  UTMIP_BIAS_PDTRK_COUNT
2 UTMIP_VBUS_WAKEUP_TIME

So it is very natural to be able to define fields like this.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> If you want strict real-time behavior, run in the real  time  schedu-
> ling class.  But there are no seatbelts or airbags;  main(){for(;;);}
> can hard hang your system.                          -- Bart Smaalders
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] andes_spi: add andes_spi interface

[Mike Frysinger]

Acked-by: Mike Frysinger 
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] andes_spi: add andes_spi interface

[Mike Frysinger]

On Wednesday, June 08, 2011 04:55:20 Macpaul Lin wrote:
> Since the patch v3 of andes_spi driver has been sent on 4/25/2011,
> and has no further comment for patch v3
> will you take this patch? Thanks.
> 
> http://patchwork.ozlabs.org/patch/92704/

i dont pick up spi bus drivers ... that's left for the relevant arch/soc 
maintainer to do or if there is no appropriate person, then it's up to 
wolfgang
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Download the u-boot from flash back to PC

[Mike Frysinger]

On Wednesday, June 08, 2011 09:43:36 Detlev Zundel wrote:
> If you decide to implement a "tftpput" command, I for one would find
> this a very nice addition indeed ;)

someone has already posted tftp server support for u-boot.  not sure if it's 
been merged yet, but wolfgang seemed happy with it.

not that it'd help with the OP's current issue ...
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Supporting SCCB protocol

[Mike Frysinger]

On Wednesday, June 08, 2011 03:54:01 Detlev Zundel wrote:
> > That's correct! I should elaborate it. It should be (Serial Camera
> > Control Bus) protocol developed by omnivision.
> > I am using a OV2715 sensor and I need to access the registers of the said
> > sensor, I have to modify the I2C read/write in uboot to support the SCCB
> > transactions.
> 
> So SCCB is really only another name for I2C or are there differences in
> the protocol?

there are slight differences.  enough that existing i2c signals arent 
sufficient, but not enough that tweaking existing i2c framework shouldnt be 
too much of a hassle to make work.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How to compile tools?

[Mike Frysinger]

On Wednesday, June 08, 2011 03:41:31 Veli-Pekka Peltola wrote:
> We have been using U-Boot 2010.06 and now we are trying to use the
> latest version. Our build system processes the kernel with mkimage so we
> compile U-Boot tools with "make tools" even if bootloader is not
> compiled. This has worked fine in the past. It seems that 2011.03 is the
> last version where this approach worked after removing config.h include
> in tools/imximage.h. Is there currently an easy way to compile only
> tools, not the whole bootloader?

`make tools` should work.  if it doesnt, post a patch to fix it.  breakage 
here is not on purpose, but rather simply not noticed.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] arm920t/at91: use new clock features from libat91-common

[Jens Scharsig]

Am 08.06.2011 01:27, schrieb Andreas Bießmann:
>
> diff --git a/arch/arm/cpu/arm920t/at91/Makefile 
> b/arch/arm/cpu/arm920t/at91/Makefile
> index 5c71b77..872461a 100644
> --- a/arch/arm/cpu/arm920t/at91/Makefile
> +++ b/arch/arm/cpu/arm920t/at91/Makefile
> @@ -28,6 +28,7 @@ LIB = $(obj)lib$(SOC).o
>   SOBJS   += lowlevel_init.o
>   COBJS   += reset.o
>   COBJS   += timer.o
> +COBJS+= cpu.o
>
>   SRCS:= $(SOBJS:.o=.S) $(COBJS:.o=.c)
>   OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS))
> diff --git a/arch/arm/include/asm/arch-at91/at91rm9200.h 
> b/arch/arm/include/asm/arch-at91/at91rm9200.h
> index ff18014..979241e 100644

Dear Andreas Bießmann,

I am running in the following error:

.
make -C arch/arm/cpu/arm920t/at91/
make[1]: Entering directory 
`/home/scharsig/projects/CPUx9K2/u-boot/arch/arm/cpu/arm920t/at91'
make[1]: *** No rule to make target `cpu.c', needed by `.depend'.  Stop.
make[1]: Leaving directory 
`/home/scharsig/projects/CPUx9K2/u-boot/arch/arm/cpu/arm920t/at91'
make: *** [arch/arm/cpu/arm920t/at91/libat91.o] Error 2


Is it possible that the patch is incomplete
or is an additional patch needed

Best regards

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

[U-Boot] [PATCH] powerpc/p1022ds: set the clock-frequency property only if the clock is enabled

[Timur Tabi]

The clock-frequency property in an audio codec's device tree node is set to
the input clock frequency for that codec.  On the Freescale P1022DS reference
board, the input clock is enabled only if the hwconfig 'audclk' option is set.
Therefore, the property should only be set in the device tree if the clock
is actually enabled.

Signed-off-by: Timur Tabi 
---

This patch fixes a real bug in the P1022DS, so please apply it to 2011.06.

 board/freescale/p1022ds/p1022ds.c |   16 ++--
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/board/freescale/p1022ds/p1022ds.c 
b/board/freescale/p1022ds/p1022ds.c
index 8ef627f..456d9b0 100644
--- a/board/freescale/p1022ds/p1022ds.c
+++ b/board/freescale/p1022ds/p1022ds.c
@@ -308,7 +308,8 @@ int board_eth_init(bd_t *bis)
  * ft_codec_setup - fix up the clock-frequency property of the codec node
  *
  * Update the clock-frequency property based on the value of the 'audclk'
- * hwconfig option.  If audclk is not specified, then default to 12.288MHz.
+ * hwconfig option.  If audclk is not specified, then don't write anything
+ * to the device tree, because it means that the codec clock is disabled.
  */
 static void ft_codec_setup(void *blob, const char *compatible)
 {
@@ -317,12 +318,15 @@ static void ft_codec_setup(void *blob, const char 
*compatible)
u32 freq;
 
audclk = hwconfig_arg("audclk", &arglen);
-   if (audclk && (strncmp(audclk, "11", 2) == 0))
-   freq = 11289600;
-   else
-   freq = 12288000;
+   if (audclk) {
+   if (strncmp(audclk, "11", 2) == 0)
+   freq = 11289600;
+   else
+   freq = 12288000;
 
-   do_fixup_by_compat_u32(blob, compatible, "clock-frequency", freq, 1);
+   do_fixup_by_compat_u32(blob, compatible, "clock-frequency",
+  freq, 1);
+   }
 }
 
 void ft_board_setup(void *blob, bd_t *bd)
-- 
1.7.3.4


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

[U-Boot] [PATCH v3] NAND: Add 16bit NAND support for the NDFC

[Alex Waterman]

Subject: [PATCH v3] NAND: Add 16bit NAND support for the NDFC

This patch adds support for 16 bit NAND devices attached to the
NDFC on ppc4xx processors. Two config entries were added:

  CONFIG_SYS_NDFC_16- Setting this tells the NDFC that a
  16 bit device is attached.
  CONFIG_SYS_NDFC_EBC0_CFG  - This is for the External Bus
  Controller configuration register.

Also, a new ndfc_read_byte() function was added which does not
first convert the data to little endian.

The NAND SPL was also modified to do 16bit bad block testing
when a 16 bit chip is being used.

Signed-off-by: Alex Waterman 
Cc: Scott Wood 
Cc: Stefan Roese 
---
 README  |8 
 drivers/mtd/nand/ndfc.c |   33 +
 nand_spl/nand_boot.c|   11 ---
 3 files changed, 45 insertions(+), 7 deletions(-)

Changes for v2:
   - Changes dynamic checking of chip options field to a compile time
 check.
Changes for v3:
   - Revert back to dynamic checking of chip->options in the nand_spl
 code.

Note:
  For now I just went back to dynamic checking in the nand_spl code since
that is easeir. I think its worth using a preprocessor directive to do this
instead but that would require some more thought. Maybe when the next release
is out I can look into that but for now I don't have as much time as I would
like :(.

diff --git a/README b/README
index 6f3748d..3ede798 100644
--- a/README
+++ b/README
@@ -2912,6 +2912,14 @@ Low Level (hardware related) configuration options:
 - CONFIG_SYS_SRIOn_MEM_SIZE:
Size of SRIO port 'n' memory region
 
+- CONFIG_SYS_NDFC_16
+   Defined to tell the NDFC that the NAND chip is using a
+   16 bit bus.
+
+- CONFIG_SYS_NDFC_EBC0_CFG
+   Sets the EBC0_CFG register for the NDFC. If not defined
+   a default value will be used.
+
 - CONFIG_SPD_EEPROM
Get DDR timing information from an I2C EEPROM. Common
with pluggable memory modules such as SODIMMs
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 0729e0c..6ebbb5e 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -37,6 +37,13 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_NAND_BCR
+#define CONFIG_SYS_NAND_BCR 0x8000
+#endif
+#ifndef CONFIG_SYS_NDFC_EBC0_CFG
+#define CONFIG_SYS_NDFC_EBC0_CFG 0xb840
+#endif
+
 /*
  * We need to store the info, which chip-select (CS) is used for the
  * chip number. For example on Sequoia NAND chip #0 uses
@@ -140,12 +147,25 @@ static int ndfc_verify_buf(struct mtd_info *mtdinfo, 
const uint8_t *buf, int len
 
return 0;
 }
-#endif /* #ifndef CONFIG_NAND_SPL */
 
-#ifndef CONFIG_SYS_NAND_BCR
-#define CONFIG_SYS_NAND_BCR 0x8000
+/*
+ * Read a byte from the NDFC.
+ */
+static uint8_t ndfc_read_byte(struct mtd_info *mtd)
+{
+
+   struct nand_chip *chip = mtd->priv;
+
+#ifdef CONFIG_SYS_NDFC_16BIT
+   return (uint8_t) readw(chip->IO_ADDR_R);
+#else
+   return readb(chip->IO_ADDR_R);
 #endif
 
+}
+
+#endif /* #ifndef CONFIG_NAND_SPL */
+
 void board_nand_select_device(struct nand_chip *nand, int chip)
 {
/*
@@ -198,16 +218,21 @@ int board_nand_init(struct nand_chip *nand)
nand->ecc.bytes = 3;
nand->select_chip = ndfc_select_chip;
 
+#ifdef CONFIG_SYS_NDFC_16BIT
+   nand->options |= NAND_BUSWIDTH_16;
+#endif
+
 #ifndef CONFIG_NAND_SPL
nand->write_buf  = ndfc_write_buf;
nand->verify_buf = ndfc_verify_buf;
+   nand->read_byte = ndfc_read_byte;
 
chip++;
 #else
/*
 * Setup EBC (CS0 only right now)
 */
-   mtebc(EBC0_CFG, 0xb840);
+   mtebc(EBC0_CFG, CONFIG_SYS_NDFC_EBC0_CFG);
 
mtebc(PB0CR, CONFIG_SYS_EBC_PB0CR);
mtebc(PB0AP, CONFIG_SYS_EBC_PB0AP);
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index 9545a9a..1d847ef 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -122,10 +122,15 @@ static int nand_is_bad_block(struct mtd_info *mtd, int 
block)
nand_command(mtd, block, 0, CONFIG_SYS_NAND_BAD_BLOCK_POS, 
NAND_CMD_READOOB);
 
/*
-* Read one byte
+* Read one byte (or two if it's a 16 bit chip).
 */
-   if (readb(this->IO_ADDR_R) != 0xff)
-   return 1;
+   if (this->chip_options & NAND_BUSWIDTH_16){
+   if (readw(this->IO_ADDR_R) != 0x)
+   return 1;
+   } else {
+   if (readb(this->IO_ADDR_R) != 0xff)
+   return 1;
+   }
 
return 0;
 }
-- 
1.7.4.4


-- 
Alex Waterman
Computer Engineer
Phone: 215-896-4920
Email: awater...@dawning.com

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

Re: [U-Boot] [PATCH v3 2/4] build/mkconfig: Add EXTRA_OPTS argument to make to modify build

[McClintock Matthew-B29882]

On Tue, Jun 7, 2011 at 3:04 PM, Wolfgang Denk  wrote:
>> BOARD_NAND
>> BOARD_NAND_IN_BOOTSTRAP
>> BOARD_SPIFLASH
>> BOARD_SPIFLASH_IN_BOOTSTRAP
>> BOARD_SDCARD
>> BOARD_SDCARD_IN_BOOTSTRAP
>
> Are these independent targets?  I think you don't run a
> "./MAKEALL BOARD_SDCARD_IN_BOOTSTRAP" alone, right?

Correct, however I was hoping to use a normal build system to make
this image. With the only difference being that CONFIG_IN_BOOTSTRAP is
defined when parsing the board config file.

> You can set all types of make variable sinternally during different
> stages of the build, like we already do with the nand_spl code.

Right but nand_spl provides more Makefiles for building it's own
image. I want to reuse the normal u-boot build system to create this
shim/bootstrap image.

> I have to admit that I don't even understand why you would need
> separate top-level FOO and FOO_IN_BOOTSTRAP make targets.  Please
> elucidate.

Sorry, let me try to explain some more.

Certain boards require some sort of shim, or spl for booting from
media other than NOR on our parts. We need this shim to perform DDR
initialization. This shim does not need to be anything but a stripped
down version of u-boot since it needs to be <256k and contain the DDR
SPD initialization code. Therefore I just wanted to reuse the u-boot
build system as is and add some configuration changes to create all
the final images for booting this board.

So when I build a target for my board the following happens:

make FOO
-> builds u-boot.bin to run from RAM
-> calls make FOO_IN_BOOTSTRAP to run from L2 and configure DDR
-> NAND will also have a nand_spl shim as well (where as SDCARD and
SPI booting currently do not have support in u-boot for making this
shim)

The FOO_IN_BOOTSTRAP build above creates a u-boot image that runs from
L2 and its BOOTCOMMAND is set such that it will automatically load the
final u-boot image from the boot media to ram and then execute the
full version of u-boot.

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

Re: [U-Boot] [PATCH 3/4] nand_spl/spiboot/sdboot: Add ability to have smaller middle loader

[McClintock Matthew-B29882]

On Tue, Jun 7, 2011 at 3:19 PM, Wolfgang Denk  wrote:
>> Perhaps having a CONFIG_TARGET_IMAGE available and having just one
>> generic TARGET available?
>>
>> ifdef CONFIG_TARGET_IMAGE
>> ALL += $(CONFIG_TARGET_IMAGE)
>> endif
>>
>> TARGET_IMAGE_OBJS-y += various.bin
>> TARGET_IMAGE_OBJS-y += required.bin
>> TARGET_IMAGE_OBJS-y += blobs.bin
>>
>> $(obj)$(CONFIG_TARGET_IMAGE):   $(TARGET_IMAGE_OBJS-y)
>>                 cat $(TARGET_IMAGE_OBJS-y) > $(obj)$(CONFIG_TARGET_IMAGE)
>
> THis will probably not work, as different images may require different
> levels of alignment / padding.  Also, some architectures require more
> fancy image building capabilities (provided for example by the mkimage
> tool).

It works for the images in the Makefile currently, but in the future
more complicated and board specific targets could live in
board/arch/cpu specific files that are included into the top level
makefile.

sinclude $(obj)arch/$(ARCH)/Makefile.targets
sinclude $(obj)arch/$(ARCH)/cpu/$(CPU)/Makefile.targets

In fact we could move all image creation (besides u-boot.bin) out to
the files and clean out the top level makefile.

>
>> > Do we really need all this in the top level Makefile?
>>
>> I'm not sure there is a great way around this. I played around with
>> trying to include them in the config.mk or a board/cpu/arch Makefile
>> (I'll admit my lack of Makefile mastery here) but what seems to work
>> best is something like this to add "other" targets that don't need to
>> reside in the top level Makefile. This is best because targets depend
>> on things in the toplevel Makefile.
>
> I think we should step back a bit.  Assume I forgot everything I've
> read so far, and try to explain me in simple words (completely
> independent from your suggested implementation) what exactly you want
> to do.

I think my other reply to your email on patch 2/4 should provide a
good summary on what I am trying to accomplish.

>
>> >>  cat << EOF >> config.h
>> >> +#define CONFIG_BOARD_NAME $BOARD_NAME
>> >>  #define CONFIG_BOARDDIR board/$BOARDDIR
>> >>  #include 
>> >>  #include 
>> >
>> > NAK. This breaks existing code, also it should not be needed.
>>
>> How does this break existing code? Because a specific board might also
>> defined this? I can drop it and add it to the board config file
>
> Not might, bot actually does.

Still not sure how this is breaking anything. Can you point me at a
build that fails?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] Tegra2: Add bitfield access macros

[Wolfgang Denk]

Dear Simon Glass,

In message  
you wrote:
> 
> I don't agree. Going back to the original patch, the macro allow us to
> write this code to read/write bias time for example (showing header
> and C file):

We don't make any progress if you now go back to the starting point.
Please feel free to do so, but I don't follow.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"All my life I wanted to be someone; I guess I should have been  more
specific."  - Jane Wagner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] Tegra2: Add bitfield access macros

[Simon Glass]

On Wed, Jun 8, 2011 at 12:21 PM, Wolfgang Denk  wrote:
> Dear Simon Glass,
>
> In message 
>  you 
> wrote:
>>
>> I don't agree. Going back to the original patch, the macro allow us to
>> write this code to read/write bias time for example (showing header
>> and C file):
>
> We don't make any progress if you now go back to the starting point.
> Please feel free to do so, but I don't follow.

Hi Wolfgang,

I think I responded to your point about not being able to search in
the source code. I can't really respond to your point about it being
obscure as I think that is a matter of opinion. But please let me know
if I missed something else from your response.

I also presented two options based around clrsetbits_le32. Does
something like the below meet with your approval?

(in a header somewhere:)
#define UTMIP_BIAS_PDTRK_COUNT_SHIFT 4
#define UTMIP_BIAS_PDTRK_COUNT_MASK (0xf << UTMIP_BIAS_PDTRK_COUNT_SHIFT)
#define UTMIP_BIAS_PDTRK_COUNT_VAL(v) \
 ((v << UTMIP_BIAS_PDTRK_COUNT_SHIFT) & UTMIP_BIAS_PDTRK_COUNT_MASK)
#define UTMIP_BIAS_PDTRK_COUNT_EXTRACT(v) \
 ((v & UTMIP_BIAS_PDTRK_COUNT_MASK) >> UTMIP_BIAS_PDTRK_COUNT_SHIFT)

(in the C file:)
clrsetbits_le32(&usbctlr->utmip_bias_cfg1, UTMIP_BIAS_PDTRK_COUNT_MASK,
   UTMIP_BIAS_PDTRK_COUNT_VAL(params->bias_time));
return UTMIP_BIAS_PDTRK_COUNT_EXTRACT(readl(&usbctlr->utmip_bias_cfg1))

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> "All my life I wanted to be someone; I guess I should have been  more
> specific."                                              - Jane Wagner
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] WARNING: huge ARM board removal pending

[Igor Grinberg]

Hi Albert,

On 06/07/11 21:21, Albert ARIBAUD wrote:
> Hi Igor,
>
> Le 07/06/2011 07:42, Igor Grinberg a écrit :
>> On 06/06/11 23:17, Albert ARIBAUD wrote:
>>
>>> Hi,
>>>
>>> Le 03/06/2011 15:10, Igor Grinberg a écrit :
 On 06/03/11 00:51, Wolfgang Denk wrote:

> Hi,

 Hi Wolfgang,

 [...]

> omap1610h2
> omap1610inn

> Please submit fixes to prevent removal.

 I've sent a compile fix [1] for omap1610h2 and omap1610inn about a month 
 ago,
 but still it hasn't been picked up.

 Sandeep said, he is on vacation, may be Albert should pick this up instead?

 [1] http://patchwork.ozlabs.org/patch/93545/
>>>
>>> What exactly do the FIXMEs mean? Are the definitions of 
>>> CONFIG_SYS_INIT_SP_ADDR somehow incorrect in this patch, or just 
>>> non-optimal?
>>
>> This means, that I could not test those, because I don't have the hardware.
>> I've taken those from the same SoC, so they should be fine, but again could 
>> not test,
>> so I've added a comment.
>
> FIXME implies the writer know something was wrong and mention it. Here, it is 
> less of a FIXME and more of a TODO: test ; and I don't want readers 
> to think there is a known error where there is not. Can you resubmit with the 
> FIXMEs turned into TODOs?

I can see Aneesh has posted several fixes of that kind (also for these two 
boards),
so may be his values are better justified and don't need either TODO or FIXME.
If it is so, then my patch can be dropped.


-- 
Regards,
Igor.

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

Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx

[Albert ARIBAUD]

Hi Stefano,

Le 08/06/2011 13:36, Stefano Babic a écrit :
> Hi Albert,
>
> please pull from u-boot-imx.
>
> The following changes since commit 6f4dd40cddbd69c56fec1285fee02cbd5a3833d8:
>
>Prepare v2011.06-rc2 (2011-06-02 23:19:27 +0200)
>
> are available in the git repository at:
>git://www.denx.de/git/u-boot-imx.git master
>
> Fabio Estevam (4):
>mx31ads: Use the new relocation scheme
>mx31litekit: Fix boot with the new relocation scheme.
>imx31_litekit: Remove local config.mk
>imx27lite: Remove local config.mk
>
> Felix Radensky (1):
>mx31ads: Fix environment location on flash
>
>   board/freescale/mx31ads/config.mk   |1 -
>   board/freescale/mx31ads/mx31ads.c   |   19 +--
>   board/freescale/mx31ads/u-boot.lds  |   42
> +--
>   board/logicpd/imx27lite/config.mk   |5 ---
>   board/logicpd/imx31_litekit/config.mk   |1 -
>   board/logicpd/imx31_litekit/imx31_litekit.c |   17 +++
>   include/configs/imx27lite-common.h  |2 +
>   include/configs/imx31_litekit.h |3 ++
>   include/configs/mx31ads.h   |   21 +
>   9 files changed, 78 insertions(+), 33 deletions(-)
>   delete mode 100644 board/freescale/mx31ads/config.mk
>   delete mode 100644 board/logicpd/imx27lite/config.mk
>   delete mode 100644 board/logicpd/imx31_litekit/config.mk
>
> Thanks,
> Stefano

Applied, thanks!

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

[U-Boot] [PATCH v2] arm920t/at91: use new clock features from libat91-common

[Andreas Bießmann]

This patch enables the new clock features from new libat91-common. This
is a required step to get at91rm9200_usart replaced by atmel_usart
driver.

Signed-off-by: Andreas Bießmann 

Cc: Jens Scharsig 
Cc: Eric Bénard 
---
changes since v1:
 - add missing cpu.c

 resent due to wrong list mail ...

 arch/arm/cpu/arm920t/at91/Makefile  |1 +
 arch/arm/cpu/arm920t/at91/cpu.c |   14 ++
 arch/arm/include/asm/arch-at91/at91rm9200.h |1 +
 include/configs/at91rm9200ek.h  |3 +++
 include/configs/cpuat91.h   |5 +++--
 include/configs/eb_cpux9k2.h|4 ++--
 6 files changed, 24 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/cpu/arm920t/at91/cpu.c

diff --git a/arch/arm/cpu/arm920t/at91/Makefile 
b/arch/arm/cpu/arm920t/at91/Makefile
index 5c71b77..872461a 100644
--- a/arch/arm/cpu/arm920t/at91/Makefile
+++ b/arch/arm/cpu/arm920t/at91/Makefile
@@ -28,6 +28,7 @@ LIB   = $(obj)lib$(SOC).o
 SOBJS  += lowlevel_init.o
 COBJS  += reset.o
 COBJS  += timer.o
+COBJS  += cpu.o
 
 SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/arch/arm/cpu/arm920t/at91/cpu.c b/arch/arm/cpu/arm920t/at91/cpu.c
new file mode 100644
index 000..b4c0175
--- /dev/null
+++ b/arch/arm/cpu/arm920t/at91/cpu.c
@@ -0,0 +1,14 @@
+#include 
+#include 
+#include 
+#include 
+
+#ifndef CONFIG_SYS_AT91_MAIN_CLOCK
+#define CONFIG_SYS_AT91_MAIN_CLOCK 0
+#endif
+
+int arch_cpu_init(void)
+{
+   return at91_clock_init(CONFIG_SYS_AT91_MAIN_CLOCK);
+}
+
diff --git a/arch/arm/include/asm/arch-at91/at91rm9200.h 
b/arch/arm/include/asm/arch-at91/at91rm9200.h
index ff18014..979241e 100644
--- a/arch/arm/include/asm/arch-at91/at91rm9200.h
+++ b/arch/arm/include/asm/arch-at91/at91rm9200.h
@@ -22,6 +22,7 @@
 #define __AT91RM9200_H__
 
 #define CONFIG_AT91FAMILY  /* it's a member of AT91 */
+#define CONFIG_ARCH_CPU_INIT   /* we need arch_cpu_init() for hw timers */
 #define CONFIG_ARM920T /* This is an ARM920T Core  */
 
 /* Periperial Identifiers */
diff --git a/include/configs/at91rm9200ek.h b/include/configs/at91rm9200ek.h
index 16cd214..ee199ab 100644
--- a/include/configs/at91rm9200ek.h
+++ b/include/configs/at91rm9200ek.h
@@ -55,6 +55,7 @@
  * CONFIG_SYS_HZ is the tick rate for timer tc0
  */
 #define AT91C_XTAL_CLOCK   18432000
+#define CONFIG_SYS_AT91_SLOW_CLOCK 32768
 #define AT91C_MAIN_CLOCK   ((AT91C_XTAL_CLOCK / 4) * 39)
 #define AT91C_MASTER_CLOCK (AT91C_MAIN_CLOCK / 3 )
 #define CONFIG_SYS_HZ_CLOCK(AT91C_MASTER_CLOCK / 2)
@@ -66,6 +67,8 @@
 #define CONFIG_CPUAT91
 #define USE_920T_MMU
 
+#include   /* needed for port definitions */
+
 #define CONFIG_CMDLINE_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
diff --git a/include/configs/cpuat91.h b/include/configs/cpuat91.h
index cfaef15..2bda72b 100644
--- a/include/configs/cpuat91.h
+++ b/include/configs/cpuat91.h
@@ -37,6 +37,7 @@
 #endif
 
 #define AT91C_XTAL_CLOCK   18432000
+#define CONFIG_SYS_AT91_SLOW_CLOCK 32768
 #define AT91C_MAIN_CLOCK   ((AT91C_XTAL_CLOCK / 4) * 39)
 #define AT91C_MASTER_CLOCK (AT91C_MAIN_CLOCK / 3)
 #define CONFIG_SYS_HZ_CLOCK(AT91C_MASTER_CLOCK / 2)
@@ -45,11 +46,11 @@
 #define CONFIG_ARM920T
 #define CONFIG_AT91RM9200
 #define CONFIG_CPUAT91
-#define CONFIG_AT91FAMILY
-
 #undef CONFIG_USE_IRQ
 #define USE_920T_MMU
 
+#include   /* needed for port definitions */
+
 #define CONFIG_CMDLINE_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
diff --git a/include/configs/eb_cpux9k2.h b/include/configs/eb_cpux9k2.h
index e12770a..25b28f5 100644
--- a/include/configs/eb_cpux9k2.h
+++ b/include/configs/eb_cpux9k2.h
@@ -36,7 +36,7 @@
 #define CONFIG_VERSION_VARIABLE
 #define CONFIG_IDENT_STRING" on EB+CPUx9K2"
 
-#include  /* needed for port definitions */
+#include   /* needed for port definitions */
 
 #define CONFIG_MISC_INIT_R
 
@@ -69,7 +69,7 @@
 #define CONFIG_SYS_HZ  1000
 #define CONFIG_SYS_HZ_CLOCK(AT91C_MASTER_CLOCK / 2)
 
-#define AT91_SLOW_CLOCK32768   /* slow clock */
+#define CONFIG_SYS_AT91_SLOW_CLOCK 32768   /* slow clock */
 
 #define CONFIG_CMDLINE_TAG 1
 #define CONFIG_SETUP_MEMORY_TAGS   1
-- 
1.7.5.4

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

Re: [U-Boot] [PATCH] SMDK6400: fix the compiler error

[Albert ARIBAUD]

Hi Minkyu,

Le 03/06/2011 10:15, Minkyu Kang a écrit :
> Dear  Albert ARIBAUD,
>
> On 3 June 2011 16:27, Minkyu Kang  wrote:
>> This patch adds _end for fix following compiler error
>>
>> arch/arm/cpu/arm1176/start.o: In function `_end_ofs':
>> arch/arm/cpu/arm1176/start.S:61: undefined reference to `_end'
>>
>> Signed-off-by: Minkyu Kang
>> ---
>>   board/samsung/smdk6400/u-boot-nand.lds |2 ++
>>   1 files changed, 2 insertions(+), 0 deletions(-)
>
> This patch is for bugfix.
> Please apply it to arm tree.
>
> Thanks
> Minkyu Kang

Applied, thanks!

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

Re: [U-Boot] [STATUS] WARNING: huge ARM board removal pending

[Albert ARIBAUD]

Hi Minkyu,

Le 08/06/2011 10:47, Minkyu Kang a écrit :

> Please apply this patch for SMDK6400.
> http://patchwork.ozlabs.org/patch/98525/
>
> Thanks
> Minkyu Kang


Done.

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

Re: [U-Boot] [PATCH 0/6] OMAP: fix build breaks on OMAP boards

[Albert ARIBAUD]

Hi Aneesh,

Le 07/06/2011 17:13, Aneesh V a écrit :
> Fix build breaks for OMAP boards.
> All the build breaks were due to couple of missing
> defines in the config file, namely:
>
> CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR
>
> They have been fixed by providing the right SDRAM
> base address and by using SRAM base as the initial
> stack address.
>
> None of these have been tested as I do not have any of
> these boards.
>
> Aneesh V (6):
>omap1610h2: fix build breaks
>omap5912osk: fix build breaks
>omap1510inn: fix build breaks
>omap1610inn: fix build breaks
>omap2420h4: fix build breaks
>omap730p2: fix build breaks
>
>   include/configs/omap1510inn.h |3 +++
>   include/configs/omap1610h2.h  |3 +++
>   include/configs/omap1610inn.h |3 +++
>   include/configs/omap2420h4.h  |3 +++
>   include/configs/omap5912osk.h |3 +++
>   include/configs/omap730p2.h   |3 +++
>   6 files changed, 18 insertions(+), 0 deletions(-)

Could you post a V2 series with a symbolic constant rather than a magic 
number for SP? Something like:

...
#define PHYS_SRAM 0x2000
...
#define CONFIG_SYS_INIT_SP_ADDR PHYS_SRAM

... so that readers of the code know exactly that SP is set to SRAM base.

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

Re: [U-Boot] [STATUS] WARNING: huge ARM board removal pending

[Albert ARIBAUD]

Hi Igor,

Le 08/06/2011 22:00, Igor Grinberg a écrit :
> Hi Albert,

> I can see Aneesh has posted several fixes of that kind (also for these two 
> boards),
> so may be his values are better justified and don't need either TODO or FIXME.
> If it is so, then my patch can be dropped.

Alright -- I'll apply Aneesh's set as soon as magic numbers are fixed.

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

[U-Boot] Pull request: u-boot-arm/master

[Albert ARIBAUD]

Hi Wolfgang,

The following changes since commit 6f4dd40cddbd69c56fec1285fee02cbd5a3833d8:

   Prepare v2011.06-rc2 (2011-06-02 23:19:27 +0200)

are available in the git repository at:
   git://git.denx.de/u-boot-arm.git master

Fabio Estevam (4):
   mx31ads: Use the new relocation scheme
   mx31litekit: Fix boot with the new relocation scheme.
   imx31_litekit: Remove local config.mk
   imx27lite: Remove local config.mk

Felix Radensky (1):
   mx31ads: Fix environment location on flash

Minkyu Kang (1):
   SMDK6400: fix the compiler error

  board/freescale/mx31ads/config.mk   |1 -
  board/freescale/mx31ads/mx31ads.c   |   19 +--
  board/freescale/mx31ads/u-boot.lds  |   42 
+--
  board/logicpd/imx27lite/config.mk   |5 ---
  board/logicpd/imx31_litekit/config.mk   |1 -
  board/logicpd/imx31_litekit/imx31_litekit.c |   17 +++
  board/samsung/smdk6400/u-boot-nand.lds  |2 +
  include/configs/imx27lite-common.h  |2 +
  include/configs/imx31_litekit.h |3 ++
  include/configs/mx31ads.h   |   21 +
  10 files changed, 80 insertions(+), 33 deletions(-)
  delete mode 100644 board/freescale/mx31ads/config.mk
  delete mode 100644 board/logicpd/imx27lite/config.mk
  delete mode 100644 board/logicpd/imx31_litekit/config.mk

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

Re: [U-Boot] [PATCH 1/5] Tegra2: Add bitfield access macros

[Wolfgang Denk]

Dear Simon Glass,

In message  
you wrote:
>
> I think I responded to your point about not being able to search in
> the source code. I can't really respond to your point about it being

Yes, and doing so you ignore all previous discussion about portability
etc. etc. etc.

Let's stop this discussion here.  You don't have any new arguments.
We're just wasting our time.  My mind is set.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
How can you tell when sour cream goes bad?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request u-boot-blackfin.git (v2)

[Wolfgang Denk]

Dear Mike Frysinger,

In message <1307122089-6470-1-git-send-email-vap...@gentoo.org> you wrote:
> The following changes since commit 6f4dd40cddbd69c56fec1285fee02cbd5a3833d8:
> 
>   Prepare v2011.06-rc2 (2011-06-02 23:19:27 +0200)
> 
> are available in the git repository at:
>   git://www.denx.de/git/u-boot-blackfin.git master
> 
> Harald Krapfenbauer (1):
>   Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update embedded env settings
> 
> Mike Frysinger (4):
>   Blackfin: use common LDSCRIPT logic
>   Blackfin: use on-chip reset func with newer parts
>   Blackfin: bf548-ezkit/bf561-ezkit: update env location
>   Blackfin: boards: build zlib dir with -O2
> 
>  arch/blackfin/config.mk|4 -
>  arch/blackfin/cpu/reset.c  |   70 
> ++--
>  arch/blackfin/{lib/u-boot.lds.S => cpu/u-boot.lds} |0
>  board/bct-brettl2/config.mk|1 +
>  board/bf518f-ezbrd/config.mk   |1 +
>  board/bf526-ezbrd/config.mk|1 +
>  board/bf527-ad7160-eval/config.mk  |1 +
>  board/bf527-ezkit/config.mk|1 +
>  board/bf527-sdp/config.mk  |1 +
>  board/bf533-ezkit/config.mk|1 +
>  board/bf533-stamp/config.mk|1 +
>  board/bf537-stamp/config.mk|1 +
>  board/bf538f-ezkit/config.mk   |1 +
>  board/bf548-ezkit/config.mk|1 +
>  board/bf561-acvilon/config.mk  |1 +
>  board/bf561-ezkit/config.mk|1 +
>  board/cm-bf527/config.mk   |1 +
>  board/cm-bf533/config.mk   |1 +
>  board/cm-bf537e/config.mk  |1 +
>  board/cm-bf537u/config.mk  |1 +
>  board/cm-bf548/config.mk   |1 +
>  board/cm-bf561/config.mk   |1 +
>  board/ip04/config.mk   |1 +
>  board/tcm-bf518/config.mk  |1 +
>  board/tcm-bf537/config.mk  |1 +
>  include/configs/bf548-ezkit.h  |   10 ++--
>  include/configs/bf561-ezkit.h  |   23 +--
>  include/configs/cm-bf537e.h|   11 ++--
>  include/configs/cm-bf537u.h|   11 ++--
>  include/configs/tcm-bf537.h|   11 ++--
>  30 files changed, 79 insertions(+), 83 deletions(-)
>  rename arch/blackfin/{lib/u-boot.lds.S => cpu/u-boot.lds} (100%)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"If you want to eat hippopatomus, you've got to pay the  freight."  -
attributed to an IBM guy, about why IBM software uses so much memory
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4defde71.7010...@aribaud.net> you wrote:
> Hi Wolfgang,
> 
> The following changes since commit 6f4dd40cddbd69c56fec1285fee02cbd5a3833d8:
> 
>Prepare v2011.06-rc2 (2011-06-02 23:19:27 +0200)
> 
> are available in the git repository at:
>git://git.denx.de/u-boot-arm.git master
> 
> Fabio Estevam (4):
>mx31ads: Use the new relocation scheme
>mx31litekit: Fix boot with the new relocation scheme.
>imx31_litekit: Remove local config.mk
>imx27lite: Remove local config.mk
> 
> Felix Radensky (1):
>mx31ads: Fix environment location on flash
> 
> Minkyu Kang (1):
>SMDK6400: fix the compiler error
> 
>   board/freescale/mx31ads/config.mk   |1 -
>   board/freescale/mx31ads/mx31ads.c   |   19 +--
>   board/freescale/mx31ads/u-boot.lds  |   42 
> +--
>   board/logicpd/imx27lite/config.mk   |5 ---
>   board/logicpd/imx31_litekit/config.mk   |1 -
>   board/logicpd/imx31_litekit/imx31_litekit.c |   17 +++
>   board/samsung/smdk6400/u-boot-nand.lds  |2 +
>   include/configs/imx27lite-common.h  |2 +
>   include/configs/imx31_litekit.h |3 ++
>   include/configs/mx31ads.h   |   21 +
>   10 files changed, 80 insertions(+), 33 deletions(-)
>   delete mode 100644 board/freescale/mx31ads/config.mk
>   delete mode 100644 board/logicpd/imx27lite/config.mk
>   delete mode 100644 board/logicpd/imx31_litekit/config.mk

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is much easier to suggest solutions when you know nothing
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 02/10] armv7: add miscellaneous utility macros

[Wolfgang Denk]

Dear Aneesh V,

In message <4def62a6.7060...@ti.com> you wrote:
> 
> I still don't think this is the 'right' solution for my problem. I don't
> like the fact that clrsetbits_le32() introduces a lot of un-necessary
> 'volatile's.

Well, with this argument you would also have to refuse using readl()
and writel() and all other I/O accessor macros.  The only place where
volatile is used is in the __arch_get*() and __arch_put*() macros, and
ther eit is supposed to be ok.


> Yes, it's about the 'efficiency'. May be it doesn't count in some
> cases. But, may be it counts in some other cases. Basically, I don't
> like to sacrifice 'efficiency' unless the cost for achieving it is very

Try and show me a single case where you see a measurable difference in
performance.

> If you still insist, I can use clrsetbits_le32() in the interest
> of getting this to a closure.

Please do.  Thanks.

> We have a set of powerful macros designed for bit-field accesses in IO
> egisters.
> 
> But, what I am looking for is a set of macros for bit-field operations
> on C integer variables without the un-necessary overhead of IO register
> accesses. I am looking for missing APIs in bitops.h not anything from
> io.h

All the overhead we have is a few memory barriers.  Can you measure
any difference in performance?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Never underestimate the bandwidth of a station wagon full of tapes.
-- Dr. Warren Jackson, Director, UTCS
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Download the u-boot from flash back to PC

[Detlev Zundel]

Hi Mike,

> On Wednesday, June 08, 2011 09:43:36 Detlev Zundel wrote:
>> If you decide to implement a "tftpput" command, I for one would find
>> this a very nice addition indeed ;)
>
> someone has already posted tftp server support for u-boot.  not sure if it's 
> been merged yet, but wolfgang seemed happy with it.

Yes, I know - but that only implemenmts the "receive" operation,
i.e. U-Boot receives data.

> not that it'd help with the OP's current issue ...

Nope, not at all ;)  That's why I said, either a "tftpput" or a
"receive" for the tftp server would be nice.

Cheers
  Detlev

-- 
Emacs is the way to purify your soul using garbage collection.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V3 0/2] GPIO: Tegra2: add GPIO driver for Tegra2

[Tom Warren]

This patchset adds a GPIO driver for Tegra2 SoC, and enables it for all boards

Changes in V2:
- use 'gpio_pin' enum in gpio.h (Simon Glass review request)
- change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request)
- change 'offset' to 'pin' globally
- enable GPIO for all boards (tegra2-common.h)
Changes in V3:
- use common cmd_gpio; remove redundant cmd processing code
- add gpio_request, gpio_free and gpio_toggle
- alias 'gpio_status' to 'gpio_info' for use in cmd_gpio

Tom Warren (2):
  GPIO: Tegra2: add GPIO driver for Tegra2
  arm: Tegra2: GPIO: enable GPIO for Tegra2 boards

 arch/arm/include/asm/arch-tegra2/gpio.h |  249 ++-
 common/cmd_gpio.c   |4 +
 drivers/gpio/Makefile   |1 +
 drivers/gpio/tegra2_gpio.c  |  225 
 include/configs/tegra2-common.h |2 +
 5 files changed, 474 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpio/tegra2_gpio.c

-- 
1.7.5.1

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

[U-Boot] [PATCH V3 2/2] arm: Tegra2: GPIO: enable GPIO for Tegra2 boards

[Tom Warren]

Signed-off-by: Tom Warren 
---
Changes in V2:
- enable GPIO for all boards (tegra2-common.h)
Changes in V3:
- enable use of common cmd_gpio

 include/configs/tegra2-common.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
index febce35..295ee11 100644
--- a/include/configs/tegra2-common.h
+++ b/include/configs/tegra2-common.h
@@ -160,4 +160,6 @@
CONFIG_SYS_INIT_RAM_SIZE - \
GENERATED_GBL_DATA_SIZE)
 
+#define CONFIG_TEGRA2_GPIO
+#define CONFIG_CMD_GPIO
 #endif /* __TEGRA2_COMMON_H */
-- 
1.7.5.1

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

[U-Boot] [PATCH V3 1/2] GPIO: Tegra2: add GPIO driver for Tegra2

[Tom Warren]

Signed-off-by: Tom Warren 
---
Changes in V2:
- use 'gpio_pin' enum in gpio.h (Simon Glass review request)
- change 'GPIO_PORT8' to 'GPIO_FULLPORT' (Simon Glass request)
- change 'offset' to 'pin' globally
Changes in V3:
- use common cmd_gpio; remove redundant cmd processing code
- add gpio_request, gpio_free and gpio_toggle
- alias 'gpio_status' to 'gpio_info' for use in cmd_gpio

 arch/arm/include/asm/arch-tegra2/gpio.h |  249 ++-
 common/cmd_gpio.c   |4 +
 drivers/gpio/Makefile   |1 +
 drivers/gpio/tegra2_gpio.c  |  225 
 4 files changed, 472 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpio/tegra2_gpio.c

diff --git a/arch/arm/include/asm/arch-tegra2/gpio.h 
b/arch/arm/include/asm/arch-tegra2/gpio.h
index 0fb8f0d..4718474 100644
--- a/arch/arm/include/asm/arch-tegra2/gpio.h
+++ b/arch/arm/include/asm/arch-tegra2/gpio.h
@@ -45,15 +45,250 @@ struct gpio_ctlr {
struct gpio_ctlr_bank gpio_bank[TEGRA_GPIO_BANKS];
 };
 
-#define GPIO_BANK(x)   ((x) >> 5)
-#define GPIO_PORT(x)   (((x) >> 3) & 0x3)
-#define GPIO_BIT(x)((x) & 0x7)
+#define GPIO_BANK(x)   ((x) >> 5)
+#define GPIO_PORT(x)   (((x) >> 3) & 0x3)
+#define GPIO_FULLPORT(x)   ((x) >> 3)
+#define GPIO_BIT(x)((x) & 0x7)
+
+enum gpio_pin {
+   GPIO_PA0 = 0,   /* pin 0 */
+   GPIO_PA1,
+   GPIO_PA2,
+   GPIO_PA3,
+   GPIO_PA4,
+   GPIO_PA5,
+   GPIO_PA6,
+   GPIO_PA7,
+   GPIO_PB0,   /* pin 8 */
+   GPIO_PB1,
+   GPIO_PB2,
+   GPIO_PB3,
+   GPIO_PB4,
+   GPIO_PB5,
+   GPIO_PB6,
+   GPIO_PB7,
+   GPIO_PC0,   /* pin 16 */
+   GPIO_PC1,
+   GPIO_PC2,
+   GPIO_PC3,
+   GPIO_PC4,
+   GPIO_PC5,
+   GPIO_PC6,
+   GPIO_PC7,
+   GPIO_PD0,   /* pin 24 */
+   GPIO_PD1,
+   GPIO_PD2,
+   GPIO_PD3,
+   GPIO_PD4,
+   GPIO_PD5,
+   GPIO_PD6,
+   GPIO_PD7,
+   GPIO_PE0,   /* pin 32 */
+   GPIO_PE1,
+   GPIO_PE2,
+   GPIO_PE3,
+   GPIO_PE4,
+   GPIO_PE5,
+   GPIO_PE6,
+   GPIO_PE7,
+   GPIO_PF0,   /* pin 40 */
+   GPIO_PF1,
+   GPIO_PF2,
+   GPIO_PF3,
+   GPIO_PF4,
+   GPIO_PF5,
+   GPIO_PF6,
+   GPIO_PF7,
+   GPIO_PG0,   /* pin 48 */
+   GPIO_PG1,
+   GPIO_PG2,
+   GPIO_PG3,
+   GPIO_PG4,
+   GPIO_PG5,
+   GPIO_PG6,
+   GPIO_PG7,
+   GPIO_PH0,   /* pin 56 */
+   GPIO_PH1,
+   GPIO_PH2,
+   GPIO_PH3,
+   GPIO_PH4,
+   GPIO_PH5,
+   GPIO_PH6,
+   GPIO_PH7,
+   GPIO_PI0,   /* pin 64 */
+   GPIO_PI1,
+   GPIO_PI2,
+   GPIO_PI3,
+   GPIO_PI4,
+   GPIO_PI5,
+   GPIO_PI6,
+   GPIO_PI7,
+   GPIO_PJ0,   /* pin 72 */
+   GPIO_PJ1,
+   GPIO_PJ2,
+   GPIO_PJ3,
+   GPIO_PJ4,
+   GPIO_PJ5,
+   GPIO_PJ6,
+   GPIO_PJ7,
+   GPIO_PK0,   /* pin 80 */
+   GPIO_PK1,
+   GPIO_PK2,
+   GPIO_PK3,
+   GPIO_PK4,
+   GPIO_PK5,
+   GPIO_PK6,
+   GPIO_PK7,
+   GPIO_PL0,   /* pin 88 */
+   GPIO_PL1,
+   GPIO_PL2,
+   GPIO_PL3,
+   GPIO_PL4,
+   GPIO_PL5,
+   GPIO_PL6,
+   GPIO_PL7,
+   GPIO_PM0,   /* pin 96 */
+   GPIO_PM1,
+   GPIO_PM2,
+   GPIO_PM3,
+   GPIO_PM4,
+   GPIO_PM5,
+   GPIO_PM6,
+   GPIO_PM7,
+   GPIO_PN0,   /* pin 104 */
+   GPIO_PN1,
+   GPIO_PN2,
+   GPIO_PN3,
+   GPIO_PN4,
+   GPIO_PN5,
+   GPIO_PN6,
+   GPIO_PN7,
+   GPIO_PO0,   /* pin 112 */
+   GPIO_PO1,
+   GPIO_PO2,
+   GPIO_PO3,
+   GPIO_PO4,
+   GPIO_PO5,
+   GPIO_PO6,
+   GPIO_PO7,
+   GPIO_PP0,   /* pin 120 */
+   GPIO_PP1,
+   GPIO_PP2,
+   GPIO_PP3,
+   GPIO_PP4,
+   GPIO_PP5,
+   GPIO_PP6,
+   GPIO_PP7,
+   GPIO_PQ0,   /* pin 128 */
+   GPIO_PQ1,
+   GPIO_PQ2,
+   GPIO_PQ3,
+   GPIO_PQ4,
+   GPIO_PQ5,
+   GPIO_PQ6,
+   GPIO_PQ7,
+   GPIO_PR0,   /* pin 136 */
+   GPIO_PR1,
+   GPIO_PR2,
+   GPIO_PR3,
+   GPIO_PR4,
+   GPIO_PR5,
+   GPIO_PR6,
+   GPIO_PR7,
+   GPIO_PS0,   /* pin 144 */
+   GPIO_PS1,
+   GPIO_PS2,
+   GPIO_PS3,
+   GPIO_PS4,
+   GPIO_PS5,
+   GPIO_PS6,
+   GPIO_PS7,
+   GPIO_PT0,   /* pin 152 */
+   GPIO_PT1,
+   GPIO_PT2,
+   GPIO_PT3,
+   GPIO_PT4,
+   GPIO_PT5,
+   GPIO_PT6,
+   GPIO_PT7,
+   GPIO_PU0,   /* pin 160 */
+   GPIO_PU1,
+   GPIO_PU2,
+   GPIO_PU3,
+   GPIO_PU4,
+   GPIO_PU5,
+   GPIO_PU6,
+   GPIO_PU7,
+   GPIO_PV0,   /* pin 168 */
+   GPIO_PV1,
+   GPIO_PV2,
+   GPIO_PV3,
+   GPIO_PV4,
+   GPIO_PV5,
+   GPIO_PV

Re: [U-Boot] [PATCH V3 1/2] GPIO: Tegra2: add GPIO driver for Tegra2

[Mike Frysinger]

On Wednesday, June 08, 2011 18:08:12 Tom Warren wrote:
> --- a/common/cmd_gpio.c
> +++ b/common/cmd_gpio.c
> 
> +#ifdef   CONFIG_TEGRA2_GPIO
> +#include 
> +#else
>  #include 
> +#endif

sorry, but no.  create an asm/gpio.h in the arch/arm/ subtree that includes 
asm/arch/gpio.h.  you could probably even move some of the common stuff (like 
the gpio func prototypes) into that header.

if we get enough people picking this up in u-boot, we can probably eventually 
unify further in asm-generic/gpio.h.  but that day isnt today :P.

> --- /dev/null
> +++ b/drivers/gpio/tegra2_gpio.c
>
> +int gpio_num = 0;
> +char gpio_label[20] = "";

this doesnt make much sense.  the gpio code is not 1-pin at a time, it allows 
for any number of pins to be requested at a time.  i'd suggest you just drop 
these two variables and their users.

> +/* Config pin 'gp' as GPIO or SFPIO, based on 'type' */
> +void __set_config(int gp, int type)

probably want all these internal funcs to be marked static

> +int gpio_request(int gp, const char *label)
> +{
> + /* Configure as a GPIO */
> + __set_config(gp, 1);

you probably want to do error checking on gp.  if someone does 
gpio_request(1), i'm pretty sure your current code is going to crash and 
burn.

> +int gpio_direction_input(int gp)
> +{
> ...
> + /* Configure as a GPIO */
> + __set_config(gp, 1);
> ...
> +int gpio_direction_output(int gp, int value)
> +{
> ...
> + /* Configure as a GPIO */
> + __set_config(gp, 1);

this should be unnecessary.  code that calls any gpio_* funcs on a pin that 
first did not call gpio_request (and succeed) is broken.  dont work around 
that in the core code.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Download the u-boot from flash back to PC

[Mike Frysinger]

On Wednesday, June 08, 2011 17:42:30 Detlev Zundel wrote:
> > On Wednesday, June 08, 2011 09:43:36 Detlev Zundel wrote:
> >> If you decide to implement a "tftpput" command, I for one would find
> >> this a very nice addition indeed ;)
> > 
> > someone has already posted tftp server support for u-boot.  not sure if
> > it's been merged yet, but wolfgang seemed happy with it.
> 
> Yes, I know - but that only implemenmts the "receive" operation,
> i.e. U-Boot receives data.

i thought there was code sitting around for transmitting from u-boot.  *shrug* 
must have remembered wrong.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] powerpc/85xx: Add basic support for P1023RDS board

[Roy Zang]

The P1023RDS board is the reference board for the P1023 SoC.

Add support for booting it from NOR or NAND, with fixed 2G of DDR, PCIe,
UART, I2C, etc.

Signed-off-by: Roy Zang 
Signed-off-by: Haiying Wang 
Signed-off-by: Chunhe Lan 
Signed-off-by: Lei Xu 
Signed-off-by: York Sun 
Signed-off-by: Kumar Gala 
---
based on "Prepare v2011.06-rc2"
v2 vs. v1: some code style clean up

 MAINTAINERS   |1 +
 board/freescale/p1023rds/Makefile |   38 ++
 board/freescale/p1023rds/bcsr.h   |   53 +++
 board/freescale/p1023rds/law.c|   35 ++
 board/freescale/p1023rds/p1023rds.c   |  162 +++
 board/freescale/p1023rds/tlb.c|  118 ++
 boards.cfg|2 +
 doc/README.p1023rds   |  102 +
 include/configs/P1023RDS.h|  562 +
 nand_spl/board/freescale/p1023rds/Makefile|  133 ++
 nand_spl/board/freescale/p1023rds/nand_boot.c |   99 +
 11 files changed, 1305 insertions(+), 0 deletions(-)
 create mode 100644 board/freescale/p1023rds/Makefile
 create mode 100644 board/freescale/p1023rds/bcsr.h
 create mode 100644 board/freescale/p1023rds/law.c
 create mode 100644 board/freescale/p1023rds/p1023rds.c
 create mode 100644 board/freescale/p1023rds/tlb.c
 create mode 100644 doc/README.p1023rds
 create mode 100644 include/configs/P1023RDS.h
 create mode 100644 nand_spl/board/freescale/p1023rds/Makefile
 create mode 100644 nand_spl/board/freescale/p1023rds/nand_boot.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c462ae2..af31552 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -511,6 +511,7 @@ Ilya Yanok 
 Roy Zang 
 
mpc7448hpc2 MPC7448
+   P1023RDSP1023
 
 John Zhan 
 
diff --git a/board/freescale/p1023rds/Makefile 
b/board/freescale/p1023rds/Makefile
new file mode 100644
index 000..bf87580
--- /dev/null
+++ b/board/freescale/p1023rds/Makefile
@@ -0,0 +1,38 @@
+#
+# Copyright 2010-2011 Freescale Semiconductor, Inc.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the Free
+# Software Foundation; either version 2 of the License, or (at your option)
+# any later version.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS-y+= $(BOARD).o
+COBJS-y+= law.o
+COBJS-y+= tlb.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+clean:
+   rm -f $(OBJS) $(SOBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/freescale/p1023rds/bcsr.h b/board/freescale/p1023rds/bcsr.h
new file mode 100644
index 000..0995aa4
--- /dev/null
+++ b/board/freescale/p1023rds/bcsr.h
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2011 Freescale Semiconductor, Inc.
+ *
+ * Authors:  Chunhe Lan 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ */
+
+#ifndef __BCSR_H_
+#define __BCSR_H_
+
+#include 
+
+/*
+ * BCSR Bit definitions
+   * BCSR 15 *
+   0   device insertion oriention
+   1   stack processor present
+   2   power supply shut down/normal operation
+   3   I2C bus0 drive enable
+   4   reserved
+   5:7 I2C bus0 select
+   5 - I2C_BUS_0_SS0
+   6 - I2C_BUS_0_SS1
+   7 - I2C_BUS_0_SS2
+*/
+
+/* BCSR register base address is 0xFX20 */
+#define BCSR_BASE_REG_OFFSET   0x20
+#define BCSR_ACCESS_REG_ADDR   (CONFIG_SYS_BCSR_BASE + BCSR_BASE_REG_OFFSET)
+
+#define BCSR15_DEV_INS_ORI 0x80
+#define BCSR15_STACK_PRO_PRE   0x40
+#define BCSR15_POWER_SUPPLY0x20
+#define BCSR15_I2C_BUS0_EN 0x10
+#define BCSR15_I2C_BUS0_SEG0   0x00
+#define BCSR15_I2C_BUS0_SEG1   0x04
+#define BCSR15_I2C_BUS0_SEG2   0x02
+#define BCSR15_I2C_BUS0_SEG3   0x06
+#define BCSR15_I2C_BUS0_SEG4   0x01
+#define BCSR15_I2C_BUS0_SEG5   0x05
+#define BCSR15_I2C_BUS0_SEG6   0x03
+#define BCSR15_I2C_BUS0_SEG7   0x07
+#define BCSR15_I2C_BUS0_SEG_CLR0x07
+#define BCSR19_SGMII_SEL_L 0x01
+
+/*BCSR Utils functions*/
+void fixup_i2c_bus0_sel_seg0(void);
+#endif  /* __BCSR_H_ */
diff --git a/board/freescale/p1023rds/law.c b/board/freescale/p1023rds/law.c
new file mode 100644
index 000..f140f64
--- /dev/null
+++ b/board

Re: [U-Boot] [PATCH] sh: Fix rsk7203 alignment problem

[Nobuhiro Iwamatsu]

Applied, thanks!

Nobuhiro

2011/5/31 Phil Edworthy :
>
> Signed-off-by: Phil Edworthy 
> ---
>  board/renesas/rsk7203/lowlevel_init.S |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/board/renesas/rsk7203/lowlevel_init.S 
> b/board/renesas/rsk7203/lowlevel_init.S
> index 30ef5ab..ef4e341 100644
> --- a/board/renesas/rsk7203/lowlevel_init.S
> +++ b/board/renesas/rsk7203/lowlevel_init.S
> @@ -186,6 +186,7 @@ PCCRL2_D:   .word 0x
>  .align 2
>  PCCRL1_A:      .long 0xFFFE3916
>  PCCRL1_D:      .word 0x1010
> +.align 2
>  PDCRL4_A:      .long 0xFFFE3990
>  PDCRL4_D:      .word 0x0011
>  .align 2
> --
> 1.7.0.4
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



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

Re: [U-Boot] [PATCH v2] sh: Add support for SH2A freestanding build

[Nobuhiro Iwamatsu]

Hi, Phil.

Applied to next branch.

Thanks!

Nobuhiro

2011/6/3 Phil Edworthy :
> SH2A toolchains often only provide an fdpic version of libgcc. This
> can't be used with bare-metal software like U-Boot, so this patch
> provides the necessary functions extracted from libgcc.
>
> Signed-off-by: Phil Edworthy 
> Cc: Nobuhiro Iwamatsu 
> ---
> Changes for v2:
>   - Removed changes to PLATFORM_CPPFLAGS. These are independent
>     of the patch functionality.
>
>  arch/sh/lib/Makefile   |   22 +
>  arch/sh/lib/ashiftlt.S |  192 ++
>  arch/sh/lib/ashiftrt.S |  149 ++
>  arch/sh/lib/ashldi3.c  |   25 +
>  arch/sh/lib/libgcc.h   |   25 +
>  arch/sh/lib/lshiftrt.S |  192 ++
>  arch/sh/lib/lshrdi3.c  |   25 +
>  arch/sh/lib/movmem.S   |  238 
> 
>  8 files changed, 868 insertions(+), 0 deletions(-)
>  create mode 100644 arch/sh/lib/ashiftlt.S
>  create mode 100644 arch/sh/lib/ashiftrt.S
>  create mode 100644 arch/sh/lib/ashldi3.c
>  create mode 100644 arch/sh/lib/libgcc.h
>  create mode 100644 arch/sh/lib/lshiftrt.S
>  create mode 100644 arch/sh/lib/lshrdi3.c
>  create mode 100644 arch/sh/lib/movmem.S
>
> diff --git a/arch/sh/lib/Makefile b/arch/sh/lib/Makefile
> index c0670cb..6aaf55a 100644
> --- a/arch/sh/lib/Makefile
> +++ b/arch/sh/lib/Makefile
> @@ -21,8 +21,15 @@
>  include $(TOPDIR)/config.mk
>
>  LIB    = $(obj)lib$(ARCH).o
> +LIBGCC = $(obj)libgcc.o
>
>  SOBJS-y        +=
> +GLSOBJS        += ashiftrt.o
> +GLSOBJS        += ashiftlt.o
> +GLSOBJS        += lshiftrt.o
> +GLSOBJS        += ashldi3.o
> +GLSOBJS        += lshrdi3.o
> +GLSOBJS        += movmem.o
>
>  COBJS-y        += board.o
>  COBJS-y        += bootm.o
> @@ -37,10 +44,25 @@ endif
>
>  SRCS   := $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
>  OBJS   := $(addprefix $(obj),$(SOBJS-y) $(COBJS-y))
> +LGOBJS := $(addprefix $(obj),$(GLSOBJS)) \
> +          $(addprefix $(obj),$(GLCOBJS))
> +
> +# Always build libsh.o
> +TARGETS        := $(LIB)
> +
> +# Build private libgcc only when asked for
> +ifdef USE_PRIVATE_LIBGCC
> +TARGETS        += $(LIBGCC)
> +endif
> +
> +all:   $(TARGETS)
>
>  $(LIB):        $(obj).depend $(OBJS)
>        $(call cmd_link_o_target, $(OBJS))
>
> +$(LIBGCC): $(obj).depend $(LGOBJS)
> +       $(call cmd_link_o_target, $(LGOBJS))
> +
>  #
>
>  # defines $(obj).depend target
> diff --git a/arch/sh/lib/ashiftlt.S b/arch/sh/lib/ashiftlt.S
> new file mode 100644
> index 000..4940a87
> --- /dev/null
> +++ b/arch/sh/lib/ashiftlt.S
> @@ -0,0 +1,192 @@
> +/* Copyright (C) 1994, 1995, 1997, 1998, 1999, 2000, 2001, 2002, 2003,
> +   2004, 2005, 2006
> +   Free Software Foundation, Inc.
> +
> +This file is free software; you can redistribute it and/or modify it
> +under the terms of the GNU General Public License as published by the
> +Free Software Foundation; either version 2, or (at your option) any
> +later version.
> +
> +In addition to the permissions in the GNU General Public License, the
> +Free Software Foundation gives you unlimited permission to link the
> +compiled version of this file into combinations with other programs,
> +and to distribute those combinations without any restriction coming
> +from the use of this file.  (The General Public License restrictions
> +do apply in other respects; for example, they cover modification of
> +the file, and distribution when not linked into a combine
> +executable.)
> +
> +This file is distributed in the hope that it will be useful, but
> +WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with this program; see the file COPYING.  If not, write to
> +the Free Software Foundation, 51 Franklin Street, Fifth Floor,
> +Boston, MA 02110-1301, USA.  */
> +
> +!! libgcc routines for the Renesas / SuperH SH CPUs.
> +!! Contributed by Steve Chamberlain.
> +!! s...@cygnus.com
> +
> +!! ashiftrt_r4_x, ___ashrsi3, ___ashlsi3, ___lshrsi3 routines
> +!! recoded in assembly by Toshiyasu Morita
> +!! t...@netcom.com
> +
> +/* SH2 optimizations for ___ashrsi3, ___ashlsi3, ___lshrsi3 and
> +   ELF local label prefixes by J"orn Rennecke
> +   amyl...@cygnus.com  */
> +
> +!
> +! GLOBAL(ashlsi3)
> +!
> +! Entry:
> +!
> +! r4: Value to shift
> +! r5: Shifts
> +!
> +! Exit:
> +!
> +! r0: Result
> +!
> +! Destroys:
> +!
> +! (none)
> +!
> +       .global __ashlsi3
> +       .align  2
> +__ashlsi3:
> +       mov     #31,r0
> +       and     r0,r5
> +       mova    __ashlsi3_table,r0
> +       mov.b   @(r0,r5),r5
> +#ifdef __sh1__
> +       add     r5,r0
> +       jmp     @r0
> +#else
> +       braf    r5
> +#endif
> +       mov     r4,r0
> +
> +       .align  2
> +__ashlsi3_table:

Re: [U-Boot] cache support make DaVinci dm365 quicker reading emmc

[Raffaele Recalcati]

On Wed, Jun 1, 2011 at 3:09 PM, Raffaele Recalcati
 wrote:
> Thanks to:
>
> commit c3330e9d6a11b6ead4a2346001338ce884b5832b
> Author: Heiko Schocher 
> Date:   Fri Sep 17 13:10:30 2010 +0200
>
>    ARM (ARM926ejs): add data cache support, tested on magnesium and tx25 board
>
>
> My 'Basi' board, based on DaVinci dm365, can read the uImage (1.5MB)
> in 0.7 sec (with ext2load) instead of 2 sec.
> If I read using mmc read I can reach 0.3 sec, but I need to know the 
> dimension.
>
> Take in account only that tftpboot doesn't work with dcache/icache enabled.
>

I have discovered that if I leave only icache enabled tftp works (more
more quickly than without icache).
So at the moment I enable by default dcache and icache, but, when
I need to do tftp, I disable dcache.

Hoping it helps,
Raffaele
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sh: sh2a: Add sh2a optimize to config.mk

[Nobuhiro Iwamatsu]

Only the optimization of sh2 had been supported up.
This adds the optimization of sh2a.

Signed-off-by: Nobuhiro Iwamatsu 
---
 arch/sh/cpu/sh2/config.mk |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/arch/sh/cpu/sh2/config.mk b/arch/sh/cpu/sh2/config.mk
index f2d40aa..f46b38f 100644
--- a/arch/sh/cpu/sh2/config.mk
+++ b/arch/sh/cpu/sh2/config.mk
@@ -23,6 +23,11 @@
 #
 ENDIANNESS += -EB
 
+ifdef CONFIG_SH2A
+PLATFORM_CPPFLAGS += -m2a -m2a-nofpu -mb -mno-fdpic -ffreestanding
+else # SH2
 PLATFORM_CPPFLAGS += -m3e -mb
+endif
+
 PLATFORM_RELFLAGS += -ffixed-r13
 PLATFORM_LDFLAGS += $(ENDIANNESS)
-- 
1.7.5.3

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

Re: [U-Boot] [PATCH v2 2/2] arm: a320: enable tagged list support

[Po-Yu Chuang]

Dear Albert,

On Tue, May 17, 2011 at 11:11 AM, Po-Yu Chuang  wrote:
> From: Po-Yu Chuang 
>
>
> Signed-off-by: Po-Yu Chuang 
> ---
>  include/configs/a320evb.h |    6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h
> index f832d52..62913b5 100644
> --- a/include/configs/a320evb.h
> +++ b/include/configs/a320evb.h
> @@ -25,6 +25,12 @@
>  #include 
>
>  /*
> + * Linux kernel tagged list
> + */
> +#define CONFIG_CMDLINE_TAG
> +#define CONFIG_SETUP_MEMORY_TAGS
> +
> +/*
>  * CPU and Board Configuration Options
>  */
>  #undef CONFIG_USE_IRQ          /* we don't need IRQ/FIQ stuff */
> --
> 1.6.3.3
>
>

Is it possible to accept this patch series in v2011.06?

[U-Boot,v2,1/2] arm: a320: fix multiline comment style
http://patchwork.ozlabs.org/patch/95847/

[U-Boot,v2,2/2] arm: a320: enable tagged list support
http://patchwork.ozlabs.org/patch/95848/

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

Re: [U-Boot] [PATCH v2 2/2] arm: a320: enable tagged list support

[Po-Yu Chuang]

Dear Albert,

On Thu, Jun 9, 2011 at 2:35 PM, Po-Yu Chuang  wrote:
> Dear Albert,
>
> On Tue, May 17, 2011 at 11:11 AM, Po-Yu Chuang  
> wrote:
>> From: Po-Yu Chuang 
>>
>>
>> Signed-off-by: Po-Yu Chuang 
>> ---
>>  include/configs/a320evb.h |    6 ++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/configs/a320evb.h b/include/configs/a320evb.h
>> index f832d52..62913b5 100644
>> --- a/include/configs/a320evb.h
>> +++ b/include/configs/a320evb.h
>> @@ -25,6 +25,12 @@
>>  #include 
>>
>>  /*
>> + * Linux kernel tagged list
>> + */
>> +#define CONFIG_CMDLINE_TAG
>> +#define CONFIG_SETUP_MEMORY_TAGS
>> +
>> +/*
>>  * CPU and Board Configuration Options
>>  */
>>  #undef CONFIG_USE_IRQ          /* we don't need IRQ/FIQ stuff */
>> --
>> 1.6.3.3
>>
>>
>
> Is it possible to accept this patch series in v2011.06?
>
> [U-Boot,v2,1/2] arm: a320: fix multiline comment style
> http://patchwork.ozlabs.org/patch/95847/
>
> [U-Boot,v2,2/2] arm: a320: enable tagged list support
> http://patchwork.ozlabs.org/patch/95848/

Just now I noticed that your mail address has changed.
So resend this mail.

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