Re: [U-Boot] Some notes and status on porting U-Boot to the Cavium 64-bit Octeon MIPS Processor

[Wolfgang Denk]

Dear Aaron Williams,

In message <201102081927.36497.aaron.willi...@caviumnetworks.com> you wrote:
>
...
> > > memory size to CONFIG_MAX_MEM_MAPPED. This won't work for us. As I said,
> > > we need to move it out of the lower 4GB when there's more memory
> > > involved. We also don't
> > 
> > Why?
> 
> As I have said, we need all of the lower portion of memory and do not want to 
> introduce holes in the memory space for u-boot for loading 64-bit 

When I ask "why?" then I do so to understand the reasons fdor your
design decisions (and eventually to be able to recomment alternative
solutions).

In such a situation phrases as "we need" or "we [do not] want" are
completely useless und unhelpful, unless they are accompanied with a
"because ..." part that explains _why_ you [think you] "need" or
"want" these things.

> > I understand that you do not _want_ to change this.  My question is:
> > what would you do if you _had_ to change it?
> 
> We might be able to make some changes, but it might be difficult since we 
> have 
> a lot of developers working on this around the world. I would prefer to not 
> have to maintain two separate code bases. I will need to see how much I can 
> strip out.

Well, frankly, this is your problem, not ours. If Cavium had decided
to discuss the design early we might have come up with a solution
that fits without too much problems. Instead, Cavium went on and kept
their stuff closed for years - now they say that it's difficult to
change things. Please understand that our foxus is on the overall
quality and maintainability of the code, so such arguments do not
carry much weight.

> > > since there is some dependency on some of the include files from our GCC
> > > distribution as well, plus our toolchain distribution includes support
> > > for some of the extensions we make use of.
> > 
> > Can this be fixed?  I mean, copying some header files should probably
> > be a solvable problem.  What about of these "extensions" - are they
> > absolutely needed in U-Boot?  Usually such extensions are either
> > performance optimizations which are not really needed in U-Boot, or
> > other well-localized operations that can b ehandlef with small
> > assembler stubs.
> 
> Support for our Octeon2 processor is not in the mainline trunk yet. We also 
> have some changes needed to work with our SDK and the Linux kernel with our 
> newer chips.

You reply, but you do not actually answer my questions.


> > In general we do not want to see board or SoC specific changes to
> > common code.
> 
> The common code is already chock full of them from what I've seen in a number 

Yes, and we've learned that lesson, and now we strive hard not to add
to the mess any more.

> of areas. The number of changes for our SoC is actually quite small. In some 
> cases I've just changed some functions to use __attribute__((__weak__)) so we 
> can define the functionality elsewhere. I count a total of 21 ifdefs in the 
> common code, most of those are in cmd_ide.c, one in cmd_boot.c, one in 
> cmd_elf.c, two in env_flash.c and some in main.c, which can be removed (those 
> are for adding the support for dynamically changing the boot prompt) and one 
> in miiphyutil.c. Right now cmd_ide.c can be cleaned up a bit. The problem is 
> that cmd_ide.c includes the driver functionality in it, requiring us to do 
> this.  I can clean this up by making some of the functions weak. Is this 
> reasonable?

I don't know. I haven't seen any of the code yet, so I really cannot
tell.

> One other change I had to make was for the command table. I have to force the 
> alignment to 8 bytes in the compiler or very bad things happen.

Why?


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
Let the programmers be many and the managers few -- then all will  be
productive.   -- Geoffrey James, "The Tao of Programming"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS: AT91/AVR32]

[Uli Raich]

Dear Reinhard,
Point 1: taken and, as you can see, already improved upon
Point 2: I did not know the new configuration procedure even though I had seen 
the boards.cfg file. The description in the README file is outdated. I tried to 
compile the at91sam9260ek_nandflash version with success but failed on the 
dataflash versions.
Point 3: I have an old (1.3.4) working version for my "armuter-vmax" board, 
which is actually the at91sam9263ek_dataflash_c0 version in which only the main 
clock frequency has been patched. I therefore propose to give the 
at91sam9263ek_dataflash_c0 version a shot and see how far I will come. Hope 
this is ok.
Cheers Uli

-Original Message-
From: Reinhard Meyer [mailto:u-b...@emk-elektronik.de] 
Sent: Tuesday, February 08, 2011 5:43 PM
To: Uli Raich; u-boot
Subject: Re: [STATUS: AT91/AVR32]

Dear Uli Raich,


1. please *always* reply to the list as well

2. Makefile is not relevant for new/fixed boards anymore.
New/fixed boards are added to boards.cfg (and have to be removed from Makefile)!

3. *ONLY* at91sam9260/9xeek are known to work! at91sam9263ek definitely is not 
working yet,
patches are in the pipeline.

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

Re: [U-Boot] [PATCH] Kirkwood: Add support for OpenRD-Client & OpenRD-Ultimate

[Prafulla Wadaskar]

> -Original Message-
> From: Julian Pidancet [mailto:julian.pidan...@citrix.com]
> Sent: Tuesday, February 08, 2011 10:21 AM
> To: u-boot@lists.denx.de
> Cc: tanmay.upadh...@einfochips.com; Prafulla Wadaskar
> Subject: [PATCH] Kirkwood: Add support for OpenRD-Client & OpenRD-
> Ultimate
> 
> This patch modifies existing OpenRD-Base support to deal with all
> the three OpenRD boards (OpenRD-Base, OpenRD-Client & OpenRD-Ultimate).
> 
> This is a rebase onto master from an original patch sent by Tanmay
> Upadhyay a few months ago.
> All credits goes to him.
> It's been tested on my OpenRD-Ultimate and works perfectly fine.
> 
> Signed-off-by: Julian Pidancet 
> 
> ---
>  MAKEALL |2 +
>  board/Marvell/openrd/Makefile   |   56 ++
>  board/Marvell/openrd/config.mk  |   33 ++
>  board/Marvell/openrd/kwbimage.cfg   |  168
> ++
>  board/Marvell/openrd/openrd.c   |  173
> +++
>  board/Marvell/openrd/openrd.h   |   50 +
>  board/Marvell/openrd_base/Makefile  |   56 --
>  board/Marvell/openrd_base/kwbimage.cfg  |  168 
> --
>  board/Marvell/openrd_base/openrd_base.c |  153 
> ---
>  board/Marvell/openrd_base/openrd_base.h |   46 
>  boards.cfg  |4 +-
>  include/configs/openrd.h|  115 
>  include/configs/openrd_base.h   |   92 +++--
>  include/configs/openrd_client.h |   50 +
>  include/configs/openrd_ultimate.h   |   50 +
>  15 files changed, 714 insertions(+), 502 deletions(-)
>  create mode 100644 board/Marvell/openrd/Makefile
>  create mode 100644 board/Marvell/openrd/config.mk
>  create mode 100644 board/Marvell/openrd/kwbimage.cfg
>  create mode 100644 board/Marvell/openrd/openrd.c
>  create mode 100644 board/Marvell/openrd/openrd.h
>  delete mode 100644 board/Marvell/openrd_base/Makefile
>  delete mode 100644 board/Marvell/openrd_base/kwbimage.cfg
>  delete mode 100644 board/Marvell/openrd_base/openrd_base.c
>  delete mode 100644 board/Marvell/openrd_base/openrd_base.h
>  create mode 100644 include/configs/openrd.h
>  create mode 100644 include/configs/openrd_client.h
>  create mode 100644 include/configs/openrd_ultimate.h

Hi Julian

I suggest not to delete old file, on the other hand you can rename or move them 
through git.

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

Re: [U-Boot] PATCH-add "0X" hexadecimal prefix to simple_strtoul

[Albert ARIBAUD]

Le 09/02/2011 07:19, Chris Moore a écrit :
> Hi,
>
> Le 08/02/2011 20:14, Wolfgang Denk a écrit :
>> Dear Rob Alexander,
>>
>> In message<4d51716d.3060...@motorola.com> you wrote:
>>
>>> + if ((tolower(*cp) == 'x')&& isxdigit(cp[1])) {
>> ERROR: spaces required around that '&&' (ctx:VxW)
>>
>
> I suspect that this could be the Thunderbird problem that Albert noticed
> the other day.
> Some versions of TB seem to eat the space before an '&' character and
> IIRC also before at least one of the '<' and '>' characters :(

Not only. From time to time I see spaces missing between simple words in 
the subjects pane of the UI while the actual message does have the 
space, meaning TB wrongly removes spaces at the receiving end, not the 
sending end.

> I also noticed this in some of my (rare) posts.
> I am using TB 3.1.5.
> I am too ashamed to admit my OS ;-)
>
> A nonsense test case written with correct spacing: a = (b > (c >> 1)) &&
> ((d < ((e & 1) << 1)));
> If you receive this correctly then please excuse me for the noise :(

Received correctly. :)

In Rob's case I am not sure that the issue is due to TB eating selected 
spaces upon reception; my own TB (3.1.7), using ^U to display the raw 
message from Rob, shows missing spaces are actually in what was sent, 
and I think Wolfgang does not use TB at all.

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

Re: [U-Boot] PATCH-add "0X" hexadecimal prefix to simple_strtoul

[Chris Moore]

Hi,

Le 08/02/2011 20:14, Wolfgang Denk a écrit :
> Dear Rob Alexander,
>
> In message<4d51716d.3060...@motorola.com>  you wrote:
>
>> +if ((tolower(*cp) == 'x')&&   isxdigit(cp[1])) {
> ERROR: spaces required around that '&&' (ctx:VxW)
>

I suspect that this could be the Thunderbird problem that Albert noticed 
the other day.
Some versions of TB seem to eat the space before an '&' character and 
IIRC also before at least one of the '<' and '>' characters :(

I also noticed this in some of my (rare) posts.
I am using TB 3.1.5.
I am too ashamed to admit my OS ;-)

A nonsense test case written with correct spacing: a = (b > (c >> 1)) && 
((d < ((e & 1) << 1)));
If you receive this correctly then please excuse me for the noise :(

Cheers,
Chris

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

Re: [U-Boot] SATA support?

[Albert ARIBAUD]

Hi Aaron,

Le 08/02/2011 22:58, Aaron Williams a écrit :
> Hi,
>
> I'm trying to compile AHCI support but I'm running into a lot of problems. It
> looks like AHCI is based off of SCSI whereas other SATA drivers appear not to
> be. Is ahci.c being maintained or should I use one of the other drivers?
> Currently for my testing I have a couple Silicon Image 3132 PCIe boards.
>
> -Aaron Williams

I cannot answer on SATA[/PCIe] as such, but depending on your 
requirements and your hardware, you may possibly find it easier to use 
IDE/(P)ATA hardware emulation like I did on the ARM edminiv2 board.

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

[U-Boot] Your E-mail has W O N £850,000 UK Pounds (Your Ticket:00869575733664, Lucky#:12-12-23-35-40-41(12) & CGPN:7-22-71-00-66-12),Contact our verification Unit for full information:

[GOOGLE UK ANNIVERSARY P-R-O-M-O]

VERIFICATION UNIT E-MAIL:
: giveawayteampromo4@ gmail.com
: info.ukgiveawaypromo@ bigmir.net
  Hotline + 44 -703 -18239 68




















--
 Esse e-mail foi enviado pelo WebMail da UFF
NTi - Núcleo de Tecnologia da Informação e Comunicação


-- 
Esta mensagem foi verificada pelo sistema de antivírus e
 acredita-se estar livre de perigo.

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

Re: [U-Boot] Some notes and status on porting U-Boot to the Cavium 64-bit Octeon MIPS Processor

[Aaron Williams]

On Tuesday, February 08, 2011 12:53:27 am Wolfgang Denk wrote:
> Dear Aaron Williams,
> 
> In message <201102071524.17440.aaron.willi...@caviumnetworks.com> you wrote:
> > > these.  I understand that you are using a 64 bit port of U-Boot?
> > 
> > No. We are using a 32-bit port since I think trying to make a 64-bit port
> > of U-Boot would be far more involved. We do have support for loading and
> > executing 64-bit ELF images, however. We use special memcpy/memset
> > functions for 64-bit memory addressing in these cases.
> 
> OK, let's discuss this when we see your code.
> 
> > > Existing U-Boot deals with this by mapping just the lower and the
> > > upper parts of available physical memory. See the CONFIG_VERY_BIG_RAM
> > > config option.
> > 
> > I just looked at this and this. The only place I see this used is in
> > arch/powerpc/lib/board.c and it looks like it just limits the effective
> > memory size to CONFIG_MAX_MEM_MAPPED. This won't work for us. As I said,
> > we need to move it out of the lower 4GB when there's more memory
> > involved. We also don't
> 
> Why?

As I have said, we need all of the lower portion of memory and do not want to 
introduce holes in the memory space for u-boot for loading 64-bit 
applications. Also, some of our customers are loading their own proprietary 
operating systems that need all of the memory. The overhead from our SDK in 
the lower memory region is only a few kilobytes.

One other nice thing about the TLB support is all of the fixups go away.
> 
> > want there being holes in the middle of the memory if we can help it, nor
> > do we want to place u-boot at the lower end of memory. At least on MIPS
> > the TLB
> 
> The question is what is the lesser of two evils: not mapping all of
> the available memory and stick with a total of mapped memory that is
> addressable in 32 bit adress space, or adding the complexity to deal
> with 64 bit address spaces - which will require changes in _lots_ of
> places.
> 
> But again I suggst to defer the discussion until we see your code.
> 
> > Would using virt_to_bus to convert pointers to DMA addresses be
> > appropriate instead of the current assumption that pointers can be used
> > as DMA addresses directly? This seems like a portable solution since on
> > platforms where the pointer and DMA address are the same the macro would
> > just do nothing. Even if we didn't use virtual addresses and were using,
> > say, KSEG1 the pointer and physical address don't match.
> 
> Yes, I think this would indeed be a better approach.

This is what I am doing, though I'm having to make changes on a driver by 
driver basis to add this. I'm using dma_addr_t for the address result of this 
then using the same method used in Linux to fill in both the upper and lower 
32-bit descriptor portions, i.e. foo->lower = dma_addr & 0x; foo-
>upper = ((dma_addr >> 16) >> 16); This is how it's done in the Linux kernel. 
So far the drivers I've modified this way seem to work fine.
> 
> > > Do I understand correctly t hat this SDK (whatever that might be) will
> > > then have to be included with the U-Boot distribution?
> > > 
> > > What would be alternatives to static linking, such as to avoid adding
> > > all this code?
> > 
> > It would have to be included only for the Octeon processors. It is
> > statically
> 
> I don't undertsand what you mean. Either it is part of the U-Boot
> source tree, or it is not.  You cannot add it "only for the Octeon
> processors" - either it's there, or it ain't.
> 
> Given that we are talking about code in the order of 30% of the total
> U-Boot code, probably not conforming to U-Boot coding standards, I am
> anything but happy about such an addition.  Assume ever SoC vendor
> comes up with similar ideas...
> 
It can be included with u-boot, though I think first I should try and see how 
much I can strip it down. We cannot separate u-boot completely from the SDK, 
though. We use it extensively for things like Ethernet and will also likely 
make use of it for USB when I add the Synopsis USB support used in our older 
chips (which is not EHCI/OHCI compatible).

> > linked and we don't want to get away from this. Also, some of our u-boot
> > files are in turn statically linked against some of our utilities, such
> > as our
> 
> I understand that you do not _want_ to change this.  My question is:
> what would you do if you _had_ to change it?

We might be able to make some changes, but it might be difficult since we have 
a lot of developers working on this around the world. I would prefer to not 
have to maintain two separate code bases. I will need to see how much I can 
strip out.

> 
> > Also note that u-boot for Octeon can only be compiled with our toolchain,
> > since there is some dependency on some of the include files from our GCC
> > distribution as well, plus our toolchain distribution includes support
> > for some of the extensions we make use of.
> 
> Can this be fixed?  I mean, copying some header files sh

Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try

[Aaron Williams]

On Tuesday, February 08, 2011 03:11:54 pm Aaron Williams wrote:
> On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> > On Mon, Feb 7, 2011 at 16:58, Scott Wood  wrote:
> > > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> > >> Trying again submitting the patch.
> > >> 
> > >>   /* Do manufacturer-specific fixups */
> > >>   switch (info->manufacturer_id) {
> > >> 
> > >> + case 0x:
> > >>   case 0x0001:
> > >>   flash_fixup_amd(info, &qry);
> > >>   break;
> > > 
> > > This seems unrelated.
> > > 
> > > Otherwise, the patch looks good.  Whose tree should it go through?
> > > It's not really a NAND patch, though NAND is the reason for it.
> > 
> > NAK
> > 
> > This is not only unrelated (which the OP was told to fix on the
> > previous post of this patch), but wrong.  The S29GL series chips don't
> > return 0x for the manufacturer ID.  AMD (later Spansion) have
> > always had mfg. ID 0x0001.
> > 
> > I have various boards with S29GL064, S29GL128N, and S29GL256P, and
> > they all return the correct value (0x0001) for the mfg. ID.  I looked
> > up the latest datasheet and they have not changed that section.
> 
> I always get 0x for the mfg ID and cannot explain it. The full part
> number is S29GL064N90TF103 010FF058. That is why it was added. Without it,
> the proper fixup doesn't happen with this chip.
> 
> -Aaron

Note that in our case the port width is 16-bits and the chip width is 8 bits.

I added some printf statements for all read accesses to help.

Here's the output when I enable debugging:

flash detect cfi
 
fwc addr 1f40 cmd f0 f0f0 16bit x 8 bit 
 
fwc addr 1f40 cmd ff  16bit x 8 bit 
 
fwc addr 1f4000aa cmd 98 9898 16bit x 8 bit 
 
is= cmd 51(Q) addr 1f400020 flash_read16: address 1f400020, value 0x5151
 
is= 5151 5151   
 
flash_read16: address 1f400020, value 0x5151
 
is= cmd 52(R) addr 1f400022 flash_read16: address 1f400022, value 0x5252
 
is= 5252 5252   
 
flash_read16: address 1f400022, value 0x5252
 
is= cmd 59(Y) addr 1f400024 flash_read16: address 1f400024, value 0x5959
 
is= 5959 5959   
 
flash_read16: address 1f400024, value 0x5959
 
flash_read8: address 1f400021, value 0x51   
 
flash_read8: address 1f400023, value 0x52   
 
flash_read8: address 1f400025, value 0x59   
 
flash_read8: address 1f400027, value 0x2
 
flash_read8: address 1f400029, value 0x0
 
flash_read8: address 1f40002b, value 0x40   
 
flash_read8: address 1f40002d, value 0x0
 
flash_read8: address 1f40002f, value 0x0
 
flash_read8: address 1f400031, value 0x0
 
flash_read8: address 1f400033, value 0x0
 
flash_read8: address 1f400035, value 0x0
 
flash_read8: address 1f400037, value 0x27   
 
flash_read8: address 1f400039, value 0x36   
 
flash_read8: address 1f40003b, value 0x0
 
flash_read8: address 1f40003d, value 0x0
 
flash_read8: address 1f40003f, value 0x7
 
flash_read8: address 1f400041, value 0x7
 
flash_read8: address 1f400043, value 0xa
 
flash_read8: address 1f400045, 

Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try

[Aaron Williams]

On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
> On Mon, Feb 7, 2011 at 16:58, Scott Wood  wrote:
> > On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
> >> Trying again submitting the patch.
> >> 
> >>   /* Do manufacturer-specific fixups */
> >>   switch (info->manufacturer_id) {
> >> + case 0x:
> >>   case 0x0001:
> >>   flash_fixup_amd(info, &qry);
> >>   break;
> > 
> > This seems unrelated.
> > 
> > Otherwise, the patch looks good.  Whose tree should it go through?
> > It's not really a NAND patch, though NAND is the reason for it.
> 
> NAK
> 
> This is not only unrelated (which the OP was told to fix on the
> previous post of this patch), but wrong.  The S29GL series chips don't
> return 0x for the manufacturer ID.  AMD (later Spansion) have
> always had mfg. ID 0x0001.
> 
> I have various boards with S29GL064, S29GL128N, and S29GL256P, and
> they all return the correct value (0x0001) for the mfg. ID.  I looked
> up the latest datasheet and they have not changed that section.

I always get 0x for the mfg ID and cannot explain it. The full part number 
is S29GL064N90TF103 010FF058. That is why it was added. Without it, the proper 
fixup doesn't happen with this chip.

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

Re: [U-Boot] [STATUS: AT91/AVR32]

[Andreas Bießmann]

Dear Jens Scharsig,

Am 08.02.2011 um 22:11 schrieb Jens Scharsig:

> Am 08.02.2011 16:35, schrieb Reinhard Meyer:
>> Hello AT91/AVR32 users and maintainers,
>> 
>> since relocation was introduced most ARM boards and therefore all AT91 based 
>> boards are
>> inherently broken.
>> 
>> We also used this "opportunity" to rework most of the AT91 include files 
>> mess.
>> 
>> You can find the current efforts at git.denx.de/u-boot-atmel.git, branch 
>> rework110202.
>> 
> Dear Reinhard Meyer,
> 
> I am maintainer of eb_cpux9k2 board and if you now do the soc rework 2009.
> 
> Currently the arm920t/at91 are not touched by your rework.
> 
> I can try to update the at91rm9200.h to the atmel_ name scheme and update 
> the two board in arm920t/at91 tree including drivers. 
> Maybe I can still send a patch this week.
> 
> But I can't test the at91rm9200ek.

that would be my part ... BTW there was some interest for at91rm9200dk around 
christmas ...

> A second problem is, both boards use the legacy at91rm9200 usart driver. So 
> we could try 
> to use the  atmel_usart in a second step.

The only thing missing is the 'unsigned long get_mck_clk_rate(void)' interface. 
I did test this some time ago but would prefer to have some code as in 
arm926ejs/at91/clock.c for arm920t too. Unfortunately did not have any time to 
do that right. I allege that some code in arm926ejs/at91/clock.c could be 
shared between arm920t/at91 and arm926ejs/at91. Would that allow some at91 
specific code in arm/lib?

regards

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

[U-Boot] SATA support?

[Aaron Williams]

Hi,

I'm trying to compile AHCI support but I'm running into a lot of problems. It 
looks like AHCI is based off of SCSI whereas other SATA drivers appear not to 
be. Is ahci.c being maintained or should I use one of the other drivers? 
Currently for my testing I have a couple Silicon Image 3132 PCIe boards.

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

Re: [U-Boot] [PATCH] atmel nand patch CE don't care NAND

[Michael Trimarchi]

Hi

On 02/08/2011 09:42 PM, Scott Wood wrote:
> On Tue, 8 Feb 2011 14:29:21 -0600
> Scott Wood  wrote:
> 
>> On Wed, Feb 02, 2011 at 04:11:29PM +0100, Michael Trimarchi wrote:
>>> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
>>> index ab8bbb3..bda117a 100644
>>> --- a/drivers/mtd/nand/atmel_nand.c
>>> +++ b/drivers/mtd/nand/atmel_nand.c
>>> @@ -249,8 +249,13 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
>>> if (ctrl & NAND_ALE)
>>> IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE;
>>>  
>>> +   /*
>>> +* Nand CS don't care doesn't need the enable pin
>>> +*/
>>> +#ifdef CONFIG_SYS_NAND_ENABLE_PIN
>>> at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN,
>>> !(ctrl & NAND_NCE));
>>> +#endif
>>
>> New CONFIG symbols need to be documented, and this particular one should
>> probably be less generic.
> 
> Sorry, ignore that -- I see it's not new (it should still be documented,
> but that's not this patch's problem).

too late :(

> 
> The code change itself looks OK, just needs a better commit
> message/comment. Some googling indicates that "CE don't care" refers to the
> ability to deassert the chip enable line once an operation has been
> initiated.  This seems to be different from not having control of CE at all
> (is it just always asserted on these boards?).

It is connected to the CS3.

> 
> -Scott
> 

Regards
Michael
> 

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

Re: [U-Boot] [PATCH] atmel nand patch CE don't care NAND

[Michael Trimarchi]

Hi,

On 02/08/2011 09:29 PM, Scott Wood wrote:
> On Wed, Feb 02, 2011 at 04:11:29PM +0100, Michael Trimarchi wrote:
>> Hi,
>>
>> this patch fix the support for CE don't care nand
>>
>> Michael Trimarchi
>
> Please read http://www.denx.de/wiki/U-Boot/Patches and follow the
> format therein -- don't use attachments.
>
The thunderbird config was wrong. I will use mutt next time
>> commit 0cb23ef858407a7a9de6e353e08394637c518c89
>> Author: Michael Trimarchi 
>> Date:   Wed Feb 2 14:24:21 2011 +0100
>>
>> Fix the CE for the NAND don't care
>> 
>> Signed-off-by: Michael Trimarchi 
>
> The changelog needs to be more descriptive.  What is "NAND don't care"?
> What is broken?
>
>From atmel documentation:

"CE connection depends on the NAND Flash. For standard NAND Flash devices, it 
must be connected to any free PIO line.
For “CE don’t care” NAND Flash devices, it can be connected to either 
NCS3/NANDCS or to any free PIO line."

Hope that is more clear now. Linux use an hook to do it and u-boot a #define

>> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
>> index ab8bbb3..bda117a 100644
>> --- a/drivers/mtd/nand/atmel_nand.c
>> +++ b/drivers/mtd/nand/atmel_nand.c
>> @@ -249,8 +249,13 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
>>  if (ctrl & NAND_ALE)
>>  IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE;
>>  
>> +/*
>> + * Nand CS don't care doesn't need the enable pin
>> + */
>> +#ifdef CONFIG_SYS_NAND_ENABLE_PIN
>>  at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN,
>>  !(ctrl & NAND_NCE));
>> +#endif
> New CONFIG symbols need to be documented, and this particular one should
> probably be less generic.
There is not a new CONFIG symbol, I just skip that code that is not necessary
for this type of NAND
> -Scott
>
I will resend it

Michael

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

[U-Boot] [PATCH] NAND: env: remember the flags used in the previous environment

[Scott Wood]

Previously, uninitialized stack space was being referenced.

Signed-off-by: Scott Wood 
---
 common/env_nand.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/common/env_nand.c b/common/env_nand.c
index a4480cb..980425a 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -181,7 +181,10 @@ int writeenv(size_t offset, u_char *buf)
 
return 0;
 }
+
 #ifdef CONFIG_ENV_OFFSET_REDUND
+static unsigned char env_flags;
+
 int saveenv(void)
 {
env_t   env_new;
@@ -205,7 +208,7 @@ int saveenv(void)
return 1;
}
env_new.crc   = crc32(0, env_new.data, ENV_SIZE);
-   ++env_new.flags; /* increase the serial */
+   env_new.flags = ++env_flags; /* increase the serial */
 
if(gd->env_valid == 1) {
puts("Erasing redundant NAND...\n");
@@ -399,6 +402,7 @@ void env_relocate_spec(void)
else
ep = tmp_env2;
 
+   env_flags = ep->flags;
env_import((char *)ep, 0);
 
free(tmp_env1);
-- 
1.7.1

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

Re: [U-Boot] [PATCH] atmel nand patch CE don't care NAND

[Scott Wood]

On Tue, 8 Feb 2011 21:52:10 +0100
Michael Trimarchi  wrote:

> Hi,
> 
> On 02/08/2011 09:29 PM, Scott Wood wrote:
> > On Wed, Feb 02, 2011 at 04:11:29PM +0100, Michael Trimarchi wrote:
> >> Hi,
> >>
> >> this patch fix the support for CE don't care nand
> >>
> >> Michael Trimarchi
> >
> > Please read http://www.denx.de/wiki/U-Boot/Patches and follow the
> > format therein -- don't use attachments.
> >
> The thunderbird config was wrong. I will use mutt next time
> >> commit 0cb23ef858407a7a9de6e353e08394637c518c89
> >> Author: Michael Trimarchi 
> >> Date:   Wed Feb 2 14:24:21 2011 +0100
> >>
> >> Fix the CE for the NAND don't care
> >> 
> >> Signed-off-by: Michael Trimarchi 
> >
> > The changelog needs to be more descriptive.  What is "NAND don't care"?
> > What is broken?
> >
> From atmel documentation:
> 
> "CE connection depends on the NAND Flash. For standard NAND Flash devices, it 
> must be connected to any free PIO line.
> For “CE don’t care” NAND Flash devices, it can be connected to either 
> NCS3/NANDCS or to any free PIO line."

So the absence of CONFIG_SYS_NAND_ENABLE_PIN means it's connected to
NCS3/NANDCS (which is not quite the same as having a "CE don't care" NAND
chip, since you still have the option of using a PIO line).

I'd just say something like this in the changelog (assuming my assumption
about how this works is correct), and wouldn't bother with an in-code
comment:

atmel_nand: don't require CONFIG_SYS_NAND_ENABLE_PIN

If NCE is hooked up to NCS3, we don't need to (and can't) explicitly set
the state of the NCE pin.  Instead, the controller asserts it
automatically as part of a command/data access.  Only "CE don't
care"-type NAND chips can be used in this manner.

-Scott

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

Re: [U-Boot] [STATUS: AT91/AVR32]

[Jens Scharsig]

Am 08.02.2011 16:35, schrieb Reinhard Meyer:
> Hello AT91/AVR32 users and maintainers,
> 
> since relocation was introduced most ARM boards and therefore all AT91 based 
> boards are
> inherently broken.
> 
> We also used this "opportunity" to rework most of the AT91 include files mess.
> 
> You can find the current efforts at git.denx.de/u-boot-atmel.git, branch 
> rework110202.
> 
Dear Reinhard Meyer,

I am maintainer of eb_cpux9k2 board and if you now do the soc rework 2009.

Currently the arm920t/at91 are not touched by your rework.

I can try to update the at91rm9200.h to the atmel_ name scheme and update 
the two board in arm920t/at91 tree including drivers. 
Maybe I can still send a patch this week.

But I can't test the at91rm9200ek.

A second problem is, both boards use the legacy at91rm9200 usart driver. So we 
could try 
to use the  atmel_usart in a second step.


best regards 


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

Re: [U-Boot] [PATCH] atmel nand patch CE don't care NAND

[Reinhard Meyer]

Dear Scott Wood, Michael Trimarchi,
>>> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
>>> index ab8bbb3..bda117a 100644
>>> --- a/drivers/mtd/nand/atmel_nand.c
>>> +++ b/drivers/mtd/nand/atmel_nand.c
>>> @@ -249,8 +249,13 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
>>> if (ctrl&  NAND_ALE)
>>> IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE;
>>>
>>> +   /*
>>> +* Nand CS don't care doesn't need the enable pin
>>> +*/
>>> +#ifdef CONFIG_SYS_NAND_ENABLE_PIN
>>> at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN,
>>> !(ctrl&  NAND_NCE));
>>> +#endif
>>
>> New CONFIG symbols need to be documented, and this particular one should
>> probably be less generic.
>
> Sorry, ignore that -- I see it's not new (it should still be documented,
> but that's not this patch's problem).
>
> The code change itself looks OK, just needs a better commit
> message/comment. Some googling indicates that "CE don't care" refers to the
> ability to deassert the chip enable line once an operation has been
> initiated.  This seems to be different from not having control of CE at all
> (is it just always asserted on these boards?).

I agree that the code looks OK. Apparently it means that CE must be always 
asserted
(wired to GND) and that access to the chip is solely controlled by RE and WE.
According to (for example) the Samsung K9F2G08X0B data sheet this is possible.

I also agree that the message/comment should point this out for future 
understanding.

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

[U-Boot] [PATCH 4/4 v3] p1021mds: add QE and UEC support

[Haiying Wang]

P1021 has some QE pins which need to be set in pmuxcr register before using QE
functions. In this patch, pin QE0 and QE3 are set for UCC1 and UCC5 in Eth mode.
QE9 and QE12 are set for MII management. QE12 needs to be released after MII
access because QE12 pin is muxed with LBCTL signal.

Signed-off-by: Haiying Wang 
---
v3: change resetting micrel phy via bcsr to board specific.
 arch/powerpc/cpu/mpc85xx/speed.c  |4 ++
 arch/powerpc/include/asm/immap_85xx.h |   13 
 board/freescale/p1021mds/p1021mds.c   |   51 +
 drivers/qe/uec.c  |   41 +-
 include/configs/P1021MDS.h|   44 
 5 files changed, 152 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index f2aa8d0..ae94ee8 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -165,10 +165,14 @@ void get_sys_info (sys_info_t * sysInfo)
 #endif
 
 #ifdef CONFIG_QE
+#ifdef CONFIG_P1021
+   sysInfo->freqQE =  sysInfo->freqSystemBus;
+#else
qe_ratio = ((gur->porpllsr) & MPC85xx_PORPLLSR_QE_RATIO)
>> MPC85xx_PORPLLSR_QE_RATIO_SHIFT;
sysInfo->freqQE = qe_ratio * CONFIG_SYS_CLK_FREQ;
 #endif
+#endif
 
 #if defined(CONFIG_FSL_LBC)
 #if defined(CONFIG_SYS_LBC_LCRR)
diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index 99ecb83..d0fa79b 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1909,6 +1909,19 @@ typedef struct ccsr_gur {
 #define MPC85xx_PMUXCR_SD_DATA 0x8000
 #define MPC85xx_PMUXCR_SDHC_CD 0x4000
 #define MPC85xx_PMUXCR_SDHC_WP 0x2000
+#define MPC85xx_PMUXCR_QE0 0x8000
+#define MPC85xx_PMUXCR_QE1 0x4000
+#define MPC85xx_PMUXCR_QE2 0x2000
+#define MPC85xx_PMUXCR_QE3 0x1000
+#define MPC85xx_PMUXCR_QE4 0x0800
+#define MPC85xx_PMUXCR_QE5 0x0400
+#define MPC85xx_PMUXCR_QE6 0x0200
+#define MPC85xx_PMUXCR_QE7 0x0100
+#define MPC85xx_PMUXCR_QE8 0x0080
+#define MPC85xx_PMUXCR_QE9 0x0040
+#define MPC85xx_PMUXCR_QE100x0020
+#define MPC85xx_PMUXCR_QE110x0010
+#define MPC85xx_PMUXCR_QE120x0008
u32 pmuxcr2;/* Alt. function signal multiplex control 2 */
u8  res6[8];
u32 devdisr;/* Device disable control */
diff --git a/board/freescale/p1021mds/p1021mds.c 
b/board/freescale/p1021mds/p1021mds.c
index 2dfcf13..29972f8 100644
--- a/board/freescale/p1021mds/p1021mds.c
+++ b/board/freescale/p1021mds/p1021mds.c
@@ -37,6 +37,45 @@
 #include 
 #include 
 
+#ifdef CONFIG_QE
+const qe_iop_conf_t qe_iop_conf_tab[] = {
+   /* QE_MUX_MDC */
+   {1,  19, 1, 0, 1}, /* QE_MUX_MDC*/
+   /* QE_MUX_MDIO */
+   {1,  20, 3, 0, 1}, /* QE_MUX_MDIO   */
+
+   /* UCC_1_MII */
+   {0, 23, 2, 0, 2}, /* CLK12 */
+   {0, 24, 2, 0, 1}, /* CLK9 */
+   {0,  7, 1, 0, 2}, /* ENET1_TXD0_SER1_TXD0  */
+   {0,  9, 1, 0, 2}, /* ENET1_TXD1_SER1_TXD1  */
+   {0, 11, 1, 0, 2}, /* ENET1_TXD2_SER1_TXD2  */
+   {0, 12, 1, 0, 2}, /* ENET1_TXD3_SER1_TXD3  */
+   {0,  6, 2, 0, 2}, /* ENET1_RXD0_SER1_RXD0  */
+   {0, 10, 2, 0, 2}, /* ENET1_RXD1_SER1_RXD1  */
+   {0, 14, 2, 0, 2}, /* ENET1_RXD2_SER1_RXD2  */
+   {0, 15, 2, 0, 2}, /* ENET1_RXD3_SER1_RXD3  */
+   {0,  5, 1, 0, 2}, /* ENET1_TX_EN_SER1_RTS_B*/
+   {0, 13, 1, 0, 2}, /* ENET1_TX_ER   */
+   {0,  4, 2, 0, 2}, /* ENET1_RX_DV_SER1_CTS_B*/
+   {0,  8, 2, 0, 2}, /* ENET1_RX_ER_SER1_CD_B*/
+   {0, 17, 2, 0, 2}, /* ENET1_CRS*/
+   {0, 16, 2, 0, 2}, /* ENET1_COL*/
+
+   /* UCC_5_RMII */
+   {1, 11, 2, 0, 1}, /* CLK13 */
+   {1, 7,  1, 0, 2}, /* ENET5_TXD0_SER5_TXD0  */
+   {1, 10, 1, 0, 2}, /* ENET5_TXD1_SER5_TXD1  */
+   {1, 6, 2, 0, 2}, /* ENET5_RXD0_SER5_RXD0  */
+   {1, 9, 2, 0, 2}, /* ENET5_RXD1_SER5_RXD1  */
+   {1, 5, 1, 0, 2}, /* ENET5_TX_EN_SER5_RTS_B*/
+   {1, 4, 2, 0, 2}, /* ENET5_RX_DV_SER5_CTS_B*/
+   {1, 8, 2, 0, 2}, /* ENET5_RX_ER_SER5_CD_B*/
+
+   {0,  0, 0, 0, QE_IOP_TAB_END} /* END of table */
+};
+#endif
+
 int board_early_init_f(void)
 {
 
@@ -100,6 +139,14 @@ int board_eth_init(bd_t *bis)
 
tsec_eth_init(bis, tsec_info, num);
 
+#if defined(CONFIG_UEC_ETH)
+   /*  QE0 and QE3 need to be exposed for UCC1 and UCC5 Eth mode */
+   setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE0);
+   setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_QE3);
+
+   uec_standard_init(bis);
+#endif
+
return pci_eth_init(bis);
 }
 #endif
@@ -119,5 +166,9 @@ void ft_board_setup(void *bl

Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme

[Albert ARIBAUD]

Le 08/02/2011 21:18, stefano babic a écrit :
> Am 08.02.2011 20:26, schrieb Magnus Lilja:
>> Patch reposted as a separate mail a couple of minutes ago.
>>
>> As I mention in the patch I think Fabio's patch has to be applied first.
>
> I think your patch is ok - Fabio fixed the syntax error as you do. We
> need only one of them.
>
>> Another solution would be to change my patch somewhat to apply it first
>> and then update Fabios patch to only touch the i.MX31-PDK specific
>> files.
>
> IMHO this is the preferred way, because the two issues are orthogonal.
> Your patch fixes booting from NAND for ARM11, and  Fabio's patch fix the
> mx31pdk board only.

Agreed.

Note also that there was a recent patch to ARM926's start.S (replacing 
'adr r1, _start' with 'ldr r1, _TEXT_BASE' at line 284). The same should 
be done on arm1136.

> Regards,
> Stefano

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

Re: [U-Boot] [PATCH] atmel nand patch CE don't care NAND

[Scott Wood]

On Tue, 8 Feb 2011 14:29:21 -0600
Scott Wood  wrote:

> On Wed, Feb 02, 2011 at 04:11:29PM +0100, Michael Trimarchi wrote:
> > diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> > index ab8bbb3..bda117a 100644
> > --- a/drivers/mtd/nand/atmel_nand.c
> > +++ b/drivers/mtd/nand/atmel_nand.c
> > @@ -249,8 +249,13 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
> > if (ctrl & NAND_ALE)
> > IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE;
> >  
> > +   /*
> > +* Nand CS don't care doesn't need the enable pin
> > +*/
> > +#ifdef CONFIG_SYS_NAND_ENABLE_PIN
> > at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN,
> > !(ctrl & NAND_NCE));
> > +#endif
> 
> New CONFIG symbols need to be documented, and this particular one should
> probably be less generic.

Sorry, ignore that -- I see it's not new (it should still be documented,
but that's not this patch's problem).

The code change itself looks OK, just needs a better commit
message/comment. Some googling indicates that "CE don't care" refers to the
ability to deassert the chip enable line once an operation has been
initiated.  This seems to be different from not having control of CE at all
(is it just always asserted on these boards?).

-Scott

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

Re: [U-Boot] [PATCH] atmel nand patch CE don't care NAND

[Scott Wood]

On Wed, Feb 02, 2011 at 04:11:29PM +0100, Michael Trimarchi wrote:
> Hi,
> 
> this patch fix the support for CE don't care nand
> 
> Michael Trimarchi

Please read http://www.denx.de/wiki/U-Boot/Patches and follow the
format therein -- don't use attachments.

> commit 0cb23ef858407a7a9de6e353e08394637c518c89
> Author: Michael Trimarchi 
> Date:   Wed Feb 2 14:24:21 2011 +0100
> 
> Fix the CE for the NAND don't care
> 
> Signed-off-by: Michael Trimarchi 

The changelog needs to be more descriptive.  What is "NAND don't care"?
What is broken?

> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> index ab8bbb3..bda117a 100644
> --- a/drivers/mtd/nand/atmel_nand.c
> +++ b/drivers/mtd/nand/atmel_nand.c
> @@ -249,8 +249,13 @@ static void at91_nand_hwcontrol(struct mtd_info *mtd,
>   if (ctrl & NAND_ALE)
>   IO_ADDR_W |= CONFIG_SYS_NAND_MASK_ALE;
>  
> + /*
> +  * Nand CS don't care doesn't need the enable pin
> +  */
> +#ifdef CONFIG_SYS_NAND_ENABLE_PIN
>   at91_set_gpio_value(CONFIG_SYS_NAND_ENABLE_PIN,
>   !(ctrl & NAND_NCE));
> +#endif

New CONFIG symbols need to be documented, and this particular one should
probably be less generic.

-Scott

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

Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme

[stefano babic]

Am 08.02.2011 20:26, schrieb Magnus Lilja:
> Patch reposted as a separate mail a couple of minutes ago.
> 
> As I mention in the patch I think Fabio's patch has to be applied first.

I think your patch is ok - Fabio fixed the syntax error as you do. We
need only one of them.

> Another solution would be to change my patch somewhat to apply it first
> and then update Fabios patch to only touch the i.MX31-PDK specific
> files.

IMHO this is the preferred way, because the two issues are orthogonal.
Your patch fixes booting from NAND for ARM11, and  Fabio's patch fix the
mx31pdk board only.

Regards,
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

Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme

[Magnus Lilja]

Hi


>> Please let me know how you want me to proceed.
>
> I think the correct way is that Magnus adds his Signed-off-by to his
> patch, repushing the patch to the list. Please put Albert in CC, as this
> file is competence of the ARM maintainer (well, we tested only on i.MX,
> I see...). I will take your patch for the mx31pdk and I will merge it on
> u-boot-imx (and including it in the next pull request as well).

Patch reposted as a separate mail a couple of minutes ago.

As I mention in the patch I think Fabio's patch has to be applied first. 
Another solution would be to change my patch somewhat to apply it first 
and then update Fabios patch to only touch the i.MX31-PDK specific 
files. I cannot work on that before Thursday or Friday though.

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

[U-Boot] [PATCH] ARM: Fix startup code to make booting from NAND work again.

[Magnus Lilja]

Signed-off-by: Magnus Lilja 
---

Note: I do think that this patch requires Fabio Estevam's patch
to be applied first since it touches the same lines ~269.

 arch/arm/cpu/arm1136/start.S |   16 
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
index 12545c2..bab2868 100644
--- a/arch/arm/cpu/arm1136/start.S
+++ b/arch/arm/cpu/arm1136/start.S
@@ -163,15 +163,7 @@ call_board_init_f:
bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
ldr r0,=0x
 
-#ifdef CONFIG_NAND_SPL
-   bl  nand_boot
-#else
-#ifdef CONFIG_ONENAND_IPL
-   bl  start_oneboot
-#else
bl  board_init_f
-#endif /* CONFIG_ONENAND_IPL */
-#endif /* CONFIG_NAND_SPL */
 
 
/*--*/
 
@@ -267,10 +259,10 @@ clbss_l:str   r2, [r0]/* clear 
loop...*/
  */
 #ifdef CONFIG_NAND_SPL
ldr r0, _nand_boot_ofs
-   adr r1, _start
-   add pc, r0, r1
-_nand_boot_ofs:
-   .word nand_boot - _start
+   mov pc, r0
+
+_nand_boot_ofs:
+   .word nand_boot
 #else
 jump_2_ram:
ldr r0, _board_init_r_ofs
-- 
1.6.4.2

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

[U-Boot] [PATCH ATMEL REWORK] timer.c compile error io.h not found with arm/at91rm9200

[Jens Scharsig]

* Fix: timer.c compile error io.h not found with arm/at91rm9200


Signed-off-by: Jens Scharsig 
---
 arch/arm/cpu/arm920t/at91/timer.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm920t/at91/timer.c 
b/arch/arm/cpu/arm920t/at91/timer.c
index d9a024f..c4c5eef 100644
--- a/arch/arm/cpu/arm920t/at91/timer.c
+++ b/arch/arm/cpu/arm920t/at91/timer.c
@@ -32,7 +32,7 @@
 
 #include 
 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] PATCH-add "0X" hexadecimal prefix to simple_strtoul

[Wolfgang Denk]

Dear Rob Alexander,

In message <4d51716d.3060...@motorola.com> you wrote:
> Added support to simple_strtoul to support the standard 0X hex notation. This 
> issue
> was causing operational bug in U-boot console commands where "0X" hex numbers 
> were being
> misinterpreted as decimal.

Can you please provide an example where such problems happened?

> Signed-off-by: Rob Alexander
> --- vsprintf.org.c2011-02-08 10:12:35.954644500 -0600
> +++ vsprintf.c2011-02-08 10:26:01.708224300 -0600
> @@ -41,8 +41,9 @@
>   unsigned long result = 0,value;
> 
>   if (*cp == '0') {
> - cp++;
> - if ((*cp == 'x')&&  isxdigit(cp[1])) {
> + cp++;
> + //support both 0X and 0x notation

ERROR: do not use C99 // comments

> + if ((tolower(*cp) == 'x')&&  isxdigit(cp[1])) {

ERROR: spaces required around that '&&' (ctx:VxW)

>   base = 16;
>   cp++;
>   }
> @@ -99,7 +100,8 @@
> 
>   if (*cp == '0') {
>   cp++;
> - if ((*cp == 'x')&&  isxdigit (cp[1])) {
> +//support both 0X and 0x notation
> + if ((tolower(*cp) == 'x')&&  isxdigit(cp[1]))

Ditto.

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
Reader, suppose you were an idiot. And suppose you were a  member  of
Congress. But I repeat myself.   - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4 v2] p1021mds: add QE and UEC support

[Kumar Gala]

On Feb 8, 2011, at 11:11 AM, Haiying Wang wrote:

> On Tue, 2011-02-08 at 12:09 -0500, Haiying Wang wrote:
>> On Tue, 2011-02-08 at 10:52 -0600, Kumar Gala wrote:
>> 
>> 
 +#endif
 
uec = (uec_private_t *)dev->priv;
 
if (uec->the_first_run == 0) {
 +#ifdef CONFIG_P1021
 +  /* reset micrel phy for each UEC */
 +  clrbits_8((u8 *)(CONFIG_SYS_BCSR_BASE + 11), BCSR11_ENET_MICRST);
 +  udelay(200);
 +  setbits_8((u8 *)(CONFIG_SYS_BCSR_BASE + 11), BCSR11_ENET_MICRST);
 +
>>> 
>>> Hmm, this is board specific, can we not do this in board_*_f or _r?
>>> 
>> It did not work to do this in board_*_f/r. The board designer to me to
> :%s/to me/told me/
> 
>> reset the phy before initializing it for each UEC separately. Here is
>> the right place to do so.
> 
> Haiying 

At a minimum this ifdef should be #ifdef CONFIG_P1021MDS

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

Re: [U-Boot] [STATUS: AT91/AVR32]

[Remy Bohmer]

Hi Reinhard,

2011/2/8 Reinhard Meyer :
> Dear Uli Raich,
>> Dear Reinhard,
>> Many thanks for your answer. Only... I do not find a at91sam9260ek in this 
>> Makefile. I find at91sam9261ek or  at91sam92603ek though.
>> Will try the at91sam92603ek config.
>> Uli
> 1. please *always* reply to the list as well
>
> 2. Makefile is not relevant for new/fixed boards anymore.
> New/fixed boards are added to boards.cfg (and have to be removed from 
> Makefile)!
>
> 3. *ONLY* at91sam9260/9xeek are known to work! at91sam9263ek definitely is 
> not working yet,
> patches are in the pipeline.

Well, the at91sam9261ek patches are pending and waiting for you to
pull them in, or at least waiting for your review comments.
AND these patches also work!

Kind regards,

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

[U-Boot] [PATCH 2/2 V2] Add support for ASIX AX88772 USB 2.0 10/100Mbit Ethernet Adaptor

[Simon Glass]

Driver originally written by NVIDIA Corporation, modified to
handle odd-length packets.

Signed-off-by: Simon Glass 
---
 drivers/usb/eth/Makefile|3 +
 drivers/usb/eth/asix.c  |  635 +++
 drivers/usb/eth/usb_ether.c |7 +
 include/usb_ether.h |7 +
 4 files changed, 652 insertions(+), 0 deletions(-)
 create mode 100644 drivers/usb/eth/asix.c

diff --git a/drivers/usb/eth/Makefile b/drivers/usb/eth/Makefile
index a0f5676..6a5f25a 100644
--- a/drivers/usb/eth/Makefile
+++ b/drivers/usb/eth/Makefile
@@ -25,6 +25,9 @@ LIB   := $(obj)libusb_eth.a
 
 # new USB host ethernet layer dependencies
 COBJS-$(CONFIG_USB_HOST_ETHER) += usb_ether.o
+ifdef CONFIG_USB_ETHER_ASIX
+COBJS-y += asix.o
+endif
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
new file mode 100644
index 000..9b012e4
--- /dev/null
+++ b/drivers/usb/eth/asix.c
@@ -0,0 +1,635 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * 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., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include 
+#include 
+#include 
+#include "usb_ether.h"
+
+
+/* ASIX AX8817X based USB 2.0 Ethernet Devices */
+
+#define AX_CMD_SET_SW_MII  0x06
+#define AX_CMD_READ_MII_REG0x07
+#define AX_CMD_WRITE_MII_REG   0x08
+#define AX_CMD_SET_HW_MII  0x0a
+#define AX_CMD_READ_RX_CTL 0x0f
+#define AX_CMD_WRITE_RX_CTL0x10
+#define AX_CMD_WRITE_IPG0  0x12
+#define AX_CMD_READ_NODE_ID0x13
+#define AX_CMD_READ_PHY_ID 0x19
+#define AX_CMD_WRITE_MEDIUM_MODE   0x1b
+#define AX_CMD_WRITE_GPIOS 0x1f
+#define AX_CMD_SW_RESET0x20
+#define AX_CMD_SW_PHY_SELECT   0x22
+
+#define AX_SWRESET_CLEAR   0x00
+#define AX_SWRESET_PRTE0x04
+#define AX_SWRESET_PRL 0x08
+#define AX_SWRESET_IPRL0x20
+#define AX_SWRESET_IPPD0x40
+
+#define AX88772_IPG0_DEFAULT   0x15
+#define AX88772_IPG1_DEFAULT   0x0c
+#define AX88772_IPG2_DEFAULT   0x12
+
+/* AX88772 & AX88178 Medium Mode Register */
+#define AX_MEDIUM_PF   0x0080
+#define AX_MEDIUM_JFE  0x0040
+#define AX_MEDIUM_TFC  0x0020
+#define AX_MEDIUM_RFC  0x0010
+#define AX_MEDIUM_ENCK 0x0008
+#define AX_MEDIUM_AC   0x0004
+#define AX_MEDIUM_FD   0x0002
+#define AX_MEDIUM_GM   0x0001
+#define AX_MEDIUM_SM   0x1000
+#define AX_MEDIUM_SBP  0x0800
+#define AX_MEDIUM_PS   0x0200
+#define AX_MEDIUM_RE   0x0100
+
+#define AX88178_MEDIUM_DEFAULT \
+   (AX_MEDIUM_PS | AX_MEDIUM_FD | AX_MEDIUM_AC | \
+AX_MEDIUM_RFC | AX_MEDIUM_TFC | AX_MEDIUM_JFE | \
+AX_MEDIUM_RE)
+
+#define AX88772_MEDIUM_DEFAULT \
+   (AX_MEDIUM_FD | AX_MEDIUM_RFC | \
+AX_MEDIUM_TFC | AX_MEDIUM_PS | \
+AX_MEDIUM_AC | AX_MEDIUM_RE)
+
+/* AX88772 & AX88178 RX_CTL values */
+#define AX_RX_CTL_SO   0x0080
+#define AX_RX_CTL_AB   0x0008
+
+#define AX_DEFAULT_RX_CTL  \
+   (AX_RX_CTL_SO | AX_RX_CTL_AB)
+
+/* GPIO 2 toggles */
+#define AX_GPIO_GPO2EN 0x10/* GPIO2 Output enable */
+#define AX_GPIO_GPO_2  0x20/* GPIO2 Output value */
+#define AX_GPIO_RSE0x80/* Reload serial EEPROM */
+
+/* local defines */
+#define ASIX_BASE_NAME "asx"
+#define USB_CTRL_SET_TIMEOUT 5000
+#define USB_CTRL_GET_TIMEOUT 5000
+#define USB_BULK_SEND_TIMEOUT 5000
+#define USB_BULK_RECV_TIMEOUT 5000
+
+#define AX_RX_URB_SIZE 2048
+#define PHY_CONNECT_TIMEOUT 5000
+
+/* local vars */
+static int curr_eth_dev; /* index for name of next device detected */
+
+/*
+ * Asix infrastructure commands
+ */
+static int asix_write_cmd(struct ueth_data *dev, u8 cmd, u16 value, u16 index,
+u16 size, void *data)
+{
+   int len;
+
+   debug("asix_write_cmd() cmd=0x%02x value=0x%04x index=0x%04x "
+   "size=%d\n", cmd, value, index, size);
+
+   len = usb_control_msg(
+   dev->pusb_dev,
+   usb_sndctrlpipe(dev->pusb_

[U-Boot] [PATCH 1/2 V2] Add USB host ethernet adapter support

[Simon Glass]

This adds support for using USB Ethernet dongles in host mode. This is just
the framework - drivers will come later. A new config option called
CONFIG_USB_HOST_ETHER can be defined in board config files to switch this
on.

The was originally written by NVIDIA and was cleaned up for release by the
Chromium authors.

Signed-off-by: Simon Glass 
---
 Makefile|1 +
 common/cmd_usb.c|   12 +++-
 common/usb.c|6 ++-
 doc/README.usb  |4 +-
 drivers/usb/eth/Makefile|   45 ++
 drivers/usb/eth/usb_ether.c |  143 +++
 include/usb.h   |9 +++-
 include/usb_ether.h |   61 ++
 net/eth.c   |   47 +++
 9 files changed, 298 insertions(+), 30 deletions(-)
 create mode 100644 drivers/usb/eth/Makefile
 create mode 100644 drivers/usb/eth/usb_ether.c
 create mode 100644 include/usb_ether.h

diff --git a/Makefile b/Makefile
index 60b6494..bbee4f8 100644
--- a/Makefile
+++ b/Makefile
@@ -237,6 +237,7 @@ endif
 LIBS += drivers/rtc/librtc.a
 LIBS += drivers/serial/libserial.a
 LIBS += drivers/twserial/libtws.a
+LIBS += drivers/usb/eth/libusb_eth.a
 LIBS += drivers/usb/gadget/libusb_gadget.a
 LIBS += drivers/usb/host/libusb_host.a
 LIBS += drivers/usb/musb/libusb_musb.a
diff --git a/common/cmd_usb.c b/common/cmd_usb.c
index 6b5c582..b270eb0 100644
--- a/common/cmd_usb.c
+++ b/common/cmd_usb.c
@@ -34,6 +34,9 @@
 #ifdef CONFIG_USB_STORAGE
 static int usb_stor_curr_dev = -1; /* current device */
 #endif
+#ifdef CONFIG_USB_HOST_ETHER
+static int usb_ether_curr_dev = -1; /* current ethernet device */
+#endif
 
 /* some display routines (info command) */
 char *usb_get_class_desc(unsigned char dclass)
@@ -521,11 +524,16 @@ int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
usb_stop();
printf("(Re)start USB...\n");
i = usb_init();
+   if (i >= 0) {
 #ifdef CONFIG_USB_STORAGE
-   /* try to recognize storage devices immediately */
-   if (i >= 0)
+   /* try to recognize storage devices immediately */
usb_stor_curr_dev = usb_stor_scan(1);
 #endif
+#ifdef CONFIG_USB_HOST_ETHER
+   /* try to recognize ethernet devices immediately */
+   usb_ether_curr_dev = usb_host_eth_scan(1);
+#endif
+   }
return 0;
}
if (strncmp(argv[1], "stop", 4) == 0) {
diff --git a/common/usb.c b/common/usb.c
index 10e23de..94f26f4 100644
--- a/common/usb.c
+++ b/common/usb.c
@@ -142,10 +142,14 @@ int usb_stop(void)
 /*
  * disables the asynch behaviour of the control message. This is used for data
  * transfers that uses the exclusiv access to the control and bulk messages.
+ * Returns the old value so it can be restored later.
  */
-void usb_disable_asynch(int disable)
+int usb_disable_asynch(int disable)
 {
+   int old_value = asynch_allowed;
+
asynch_allowed = !disable;
+   return old_value;
 }
 
 
diff --git a/doc/README.usb b/doc/README.usb
index b3bcb91..9aa4f62 100644
--- a/doc/README.usb
+++ b/doc/README.usb
@@ -28,7 +28,8 @@ USB Support for PIP405 and MIP405 (UHCI)
 The USB support is implemented on the base of the UHCI Host
 controller.
 
-Currently supported are USB Hubs, USB Keyboards and USB Floppys.
+Currently supported are USB Hubs, USB Keyboards, USB Floppys, USB
+flash sticks and USB network adaptors.
 Tested with a TEAC Floppy TEAC FD-05PUB and Chicony KU-8933 Keyboard.
 
 How it works:
@@ -78,3 +79,4 @@ CONFIG_USB_UHCI   defines the lowlevel part.A 
lowlevel part must be defined
if using CONFIG_CMD_USB
 CONFIG_USB_KEYBOARD enables the USB Keyboard
 CONFIG_USB_STORAGE  enables the USB storage devices
+CONFIG_USB_HOST_ETHER  enables USB ethernet dongle support
diff --git a/drivers/usb/eth/Makefile b/drivers/usb/eth/Makefile
new file mode 100644
index 000..a0f5676
--- /dev/null
+++ b/drivers/usb/eth/Makefile
@@ -0,0 +1,45 @@
+#
+# Copyright (c) 2011 The Chromium OS Authors.
+# 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., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB:= 

[U-Boot] [PATCH] Kirkwood: Add support for OpenRD-Client & OpenRD-Ultimate

[Julian Pidancet]

This patch modifies existing OpenRD-Base support to deal with all
the three OpenRD boards (OpenRD-Base, OpenRD-Client & OpenRD-Ultimate).

This is a rebase onto master from an original patch sent by Tanmay Upadhyay a 
few months ago.
All credits goes to him.
It's been tested on my OpenRD-Ultimate and works perfectly fine. 

Signed-off-by: Julian Pidancet 
---
 MAKEALL |2 +
 board/Marvell/openrd/Makefile   |   56 ++
 board/Marvell/openrd/config.mk  |   33 ++
 board/Marvell/openrd/kwbimage.cfg   |  168 ++
 board/Marvell/openrd/openrd.c   |  173 +++
 board/Marvell/openrd/openrd.h   |   50 +
 board/Marvell/openrd_base/Makefile  |   56 --
 board/Marvell/openrd_base/kwbimage.cfg  |  168 --
 board/Marvell/openrd_base/openrd_base.c |  153 ---
 board/Marvell/openrd_base/openrd_base.h |   46 
 boards.cfg  |4 +-
 include/configs/openrd.h|  115 
 include/configs/openrd_base.h   |   92 +++--
 include/configs/openrd_client.h |   50 +
 include/configs/openrd_ultimate.h   |   50 +
 15 files changed, 714 insertions(+), 502 deletions(-)
 create mode 100644 board/Marvell/openrd/Makefile
 create mode 100644 board/Marvell/openrd/config.mk
 create mode 100644 board/Marvell/openrd/kwbimage.cfg
 create mode 100644 board/Marvell/openrd/openrd.c
 create mode 100644 board/Marvell/openrd/openrd.h
 delete mode 100644 board/Marvell/openrd_base/Makefile
 delete mode 100644 board/Marvell/openrd_base/kwbimage.cfg
 delete mode 100644 board/Marvell/openrd_base/openrd_base.c
 delete mode 100644 board/Marvell/openrd_base/openrd_base.h
 create mode 100644 include/configs/openrd.h
 create mode 100644 include/configs/openrd_client.h
 create mode 100644 include/configs/openrd_ultimate.h

diff --git a/MAKEALL b/MAKEALL
index a732e6a..4b6da98 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -361,6 +361,8 @@ LIST_ARM9=" \
omap5912osk \
omap730p2   \
openrd_base \
+   openrd_client   \
+   openrd_ultimate \
rd6281a \
sbc2410x\
scb9328 \
diff --git a/board/Marvell/openrd/Makefile b/board/Marvell/openrd/Makefile
new file mode 100644
index 000..19020e4
--- /dev/null
+++ b/board/Marvell/openrd/Makefile
@@ -0,0 +1,56 @@
+#
+# (C) Copyright 2009
+# Net Insight 
+# Written-by: Simon Kagstrom 
+#
+# Based on sheevaplug:
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# 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  := openrd.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/openrd/config.mk b/board/Marvell/openrd/config.mk
new file mode 100644
index 000..8ae355e
--- /dev/null
+++ b/board/Marvell/openrd/config.mk
@@ -0,0 +1,33 @@
+#
+# (C) Copyright 2009
+# Net Insight 
+# Written-by: Simon Kagstrom 
+#
+# Based on sheevaplug:
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# 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 

Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme

[stefano babic]

Am 08.02.2011 18:09, schrieb Fabio Estevam:

> I confirmed that by applying my original patch of this thread plus
> Magnus´ patch above I can get MX31PDK to boot.

Fine.

> 
> Please let me know how you want me to proceed.

I think the correct way is that Magnus adds his Signed-off-by to his
patch, repushing the patch to the list. Please put Albert in CC, as this
file is competence of the ARM maintainer (well, we tested only on i.MX,
I see...). I will take your patch for the mx31pdk and I will merge it on
u-boot-imx (and including it in the next pull request as well).

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-add "0X" hexadecimal prefix to simple_strtoul

[Rob Alexander]

Added support to simple_strtoul to support the standard 0X hex notation. This 
issue
was causing operational bug in U-boot console commands where "0X" hex numbers 
were being
misinterpreted as decimal.

Signed-off-by: Rob Alexander
--- vsprintf.org.c  2011-02-08 10:12:35.954644500 -0600
+++ vsprintf.c  2011-02-08 10:26:01.708224300 -0600
@@ -41,8 +41,9 @@
unsigned long result = 0,value;

if (*cp == '0') {
-   cp++;
-   if ((*cp == 'x')&&  isxdigit(cp[1])) {
+   cp++;
+   //support both 0X and 0x notation
+   if ((tolower(*cp) == 'x')&&  isxdigit(cp[1])) {
base = 16;
cp++;
}
@@ -99,7 +100,8 @@

if (*cp == '0') {
cp++;
-   if ((*cp == 'x')&&  isxdigit (cp[1])) {
+//support both 0X and 0x notation
+   if ((tolower(*cp) == 'x')&&  isxdigit(cp[1]))
base = 16;
cp++;
}


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

Re: [U-Boot] [PATCH 4/4 v2] p1021mds: add QE and UEC support

[Haiying Wang]

On Tue, 2011-02-08 at 12:09 -0500, Haiying Wang wrote:
> On Tue, 2011-02-08 at 10:52 -0600, Kumar Gala wrote:
> 
> 
> > > +#endif
> > > 
> > >   uec = (uec_private_t *)dev->priv;
> > > 
> > >   if (uec->the_first_run == 0) {
> > > +#ifdef CONFIG_P1021
> > > + /* reset micrel phy for each UEC */
> > > + clrbits_8((u8 *)(CONFIG_SYS_BCSR_BASE + 11), BCSR11_ENET_MICRST);
> > > + udelay(200);
> > > + setbits_8((u8 *)(CONFIG_SYS_BCSR_BASE + 11), BCSR11_ENET_MICRST);
> > > +
> > 
> > Hmm, this is board specific, can we not do this in board_*_f or _r?
> > 
> It did not work to do this in board_*_f/r. The board designer to me to
:%s/to me/told me/

> reset the phy before initializing it for each UEC separately. Here is
> the right place to do so.

Haiying 



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

Re: [U-Boot] [RFC] ARM: mx31pdk: Use the new relocation scheme

[Fabio Estevam]

Hi Stefano,

On 2/7/2011 5:48 PM, Magnus Lilja wrote:
...
> 
> Here's a somewhat cleaner version of my patch. Hope the mail looks ok, I'm 
> having internet connectivity issues this evening so I'm using a different 
> installation of Thunderbird than usual.
> 
> Regards, Magnus
> 
> diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S
> index 12545c2..bab2868 100644
> --- a/arch/arm/cpu/arm1136/start.S
> +++ b/arch/arm/cpu/arm1136/start.S
> @@ -163,15 +163,7 @@ call_board_init_f:
> bic sp, sp, #7 /* 8-byte alignment for ABI compliance */
> ldr r0,=0x
> 
> -#ifdef CONFIG_NAND_SPL
> -   bl  nand_boot
> -#else
> -#ifdef CONFIG_ONENAND_IPL
> -   bl  start_oneboot
> -#else
> bl  board_init_f
> -#endif /* CONFIG_ONENAND_IPL */
> -#endif /* CONFIG_NAND_SPL */
> 
> 
> /*--*/
> 
> @@ -267,10 +259,10 @@ clbss_l:str   r2, [r0]/* clear 
> loop...*/
>   */
>  #ifdef CONFIG_NAND_SPL
> ldr r0, _nand_boot_ofs
> -   adr r1, _start
> -   add pc, r0, r1
> -_nand_boot_ofs:
> -   .word nand_boot - _start
> +   mov pc, r0
> +
> +_nand_boot_ofs:
> +   .word nand_boot
>  #else
>  jump_2_ram:
> ldr r0, _board_init_r_ofs

I confirmed that by applying my original patch of this thread plus Magnus´ 
patch above I can get MX31PDK to boot.

Please let me know how you want me to proceed.

Thanks,

Fabio Estevam


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

Re: [U-Boot] [PATCH 4/4 v2] p1021mds: add QE and UEC support

[Haiying Wang]

On Tue, 2011-02-08 at 10:52 -0600, Kumar Gala wrote:


> > +#endif
> > 
> > uec = (uec_private_t *)dev->priv;
> > 
> > if (uec->the_first_run == 0) {
> > +#ifdef CONFIG_P1021
> > +   /* reset micrel phy for each UEC */
> > +   clrbits_8((u8 *)(CONFIG_SYS_BCSR_BASE + 11), BCSR11_ENET_MICRST);
> > +   udelay(200);
> > +   setbits_8((u8 *)(CONFIG_SYS_BCSR_BASE + 11), BCSR11_ENET_MICRST);
> > +
> 
> Hmm, this is board specific, can we not do this in board_*_f or _r?
> 
It did not work to do this in board_*_f/r. The board designer to me to
reset the phy before initializing it for each UEC separately. Here is
the right place to do so.

Haiying


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

Re: [U-Boot] P2020 SPL L2 clearing

[Kumar Gala]

On Feb 7, 2011, at 4:22 AM, Fabian Cenedese wrote:

> At 14:17 03.02.2011 +0100, Fabian Cenedese wrote:
>> Hi
>> 
>> I'm creating a SPL u-boot image for our board. In the file
>> arch/powerpc/cpu/mpc85xx/cpu_init_nand.c is the setup for
>> the L2 cache as SRAM. In the end is a loop that fills the
>> cache with 0 (512KB in this case).
>> 
>>   /* Initialize L2 SRAM to zero */
>>   l2srbar = (char *)CONFIG_SYS_INIT_L2_ADDR;
>>   for (i = 0; i < CONFIG_SYS_L2_SIZE; i++)
>>   l2srbar[i] = 0;
>> 
>> Two questions for this:
>> 
>> 1. Why is the access byte-wise and not dword-wise? This
>> is only for mpc85xx and I think they all can access the cache
>> with 32bits instead of just 8. That would speed up by factor 4
>> (confirmed in my tests with P2020).

No real reason, probably historic and no one noticed.  Patch welcome to change 
this to 32-bit accesses, not really sure why we just dont call memset.

>> 
>> 2. Why does the cache to be cleared at all? L2-SRAM is usually
>> just used to copy in the second part of the u-boot image, so
>> the 0s will be overwritten again anyway.

This needs to be done because we enable ECC.

>> I came to this loop because the board takes an awful long
>> time to boot up. I'm measuring now cpu ticks until board_init_r
>> (in the first part loader before the u-boot image gets loaded).
>> With this loop it takes about 4 seconds, without just 50 ms.
>> How come the L2 access is so slow? I already increased
>> the lb clock but that only helps "outside". Even if this loop
>> didn't need any time I'd still have the questions above.
> 
> I just wanted to ask again if somebody has any insight
> on this. Maybe Kumar?

Patch welcome to clean this up to be more efficient.

- k

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

Re: [U-Boot] [PATCH 4/4 v2] p1021mds: add QE and UEC support

[Kumar Gala]

On Feb 7, 2011, at 3:14 PM,  
 wrote:

> From: Haiying Wang 
> 
> P1021 has some QE pins which need to be set in pmuxcr register before using QE
> functions. In this patch, pin QE0 and QE3 are set for UCC1 and UCC5 in Eth 
> mode.
> QE9 and QE12 are set for MII management. QE12 needs to be released after MII
> access because QE12 pin is muxed with LBCTL signal.
> 
> P1021MDS has to load the microcode from NAND flash, this patchs add support to
> load ucode from NAND before initializing qe.
> 
> Signed-off-by: Haiying Wang 
> ---
> v2: remove misc_init_r, make changes based on laste commits in u-boot-85xx.git
> arch/powerpc/cpu/mpc85xx/speed.c  |4 ++
> arch/powerpc/include/asm/immap_85xx.h |   13 
> board/freescale/p1021mds/p1021mds.c   |   51 +
> drivers/qe/uec.c  |   40 +-
> include/configs/P1021MDS.h|   44 
> 5 files changed, 151 insertions(+), 1 deletions(-)

Can we split this patch up into the QE parts for P1021 and the board parts for 
P1021MDS
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/speed.c 
> b/arch/powerpc/cpu/mpc85xx/speed.c
> index f2aa8d0..ae94ee8 100644
> --- a/arch/powerpc/cpu/mpc85xx/speed.c
> +++ b/arch/powerpc/cpu/mpc85xx/speed.c
> @@ -165,10 +165,14 @@ void get_sys_info (sys_info_t * sysInfo)
> #endif
> 
> #ifdef CONFIG_QE
> +#ifdef CONFIG_P1021
> + sysInfo->freqQE =  sysInfo->freqSystemBus;
> +#else
>   qe_ratio = ((gur->porpllsr) & MPC85xx_PORPLLSR_QE_RATIO)
>   >> MPC85xx_PORPLLSR_QE_RATIO_SHIFT;
>   sysInfo->freqQE = qe_ratio * CONFIG_SYS_CLK_FREQ;
> #endif
> +#endif
> 
> #if defined(CONFIG_FSL_LBC)
> #if defined(CONFIG_SYS_LBC_LCRR)
> diff --git a/arch/powerpc/include/asm/immap_85xx.h 
> b/arch/powerpc/include/asm/immap_85xx.h
> index 99ecb83..d0fa79b 100644
> --- a/arch/powerpc/include/asm/immap_85xx.h
> +++ b/arch/powerpc/include/asm/immap_85xx.h
> @@ -1909,6 +1909,19 @@ typedef struct ccsr_gur {
> #define MPC85xx_PMUXCR_SD_DATA0x8000
> #define MPC85xx_PMUXCR_SDHC_CD0x4000
> #define MPC85xx_PMUXCR_SDHC_WP0x2000
> +#define MPC85xx_PMUXCR_QE0 0x8000
> +#define MPC85xx_PMUXCR_QE1 0x4000
> +#define MPC85xx_PMUXCR_QE2 0x2000
> +#define MPC85xx_PMUXCR_QE3 0x1000
> +#define MPC85xx_PMUXCR_QE4 0x0800
> +#define MPC85xx_PMUXCR_QE5 0x0400
> +#define MPC85xx_PMUXCR_QE6 0x0200
> +#define MPC85xx_PMUXCR_QE7 0x0100
> +#define MPC85xx_PMUXCR_QE8 0x0080
> +#define MPC85xx_PMUXCR_QE9 0x0040
> +#define MPC85xx_PMUXCR_QE100x0020
> +#define MPC85xx_PMUXCR_QE110x0010
> +#define MPC85xx_PMUXCR_QE120x0008
>   u32 pmuxcr2;/* Alt. function signal multiplex control 2 */
>   u8  res6[8];
>   u32 devdisr;/* Device disable control */
> diff --git a/board/freescale/p1021mds/p1021mds.c 
> b/board/freescale/p1021mds/p1021mds.c
> index 2dfcf13..29972f8 100644
> --- a/board/freescale/p1021mds/p1021mds.c
> +++ b/board/freescale/p1021mds/p1021mds.c
> @@ -37,6 +37,45 @@
> #include 
> #include 
> 
> +#ifdef CONFIG_QE
> +const qe_iop_conf_t qe_iop_conf_tab[] = {
> + /* QE_MUX_MDC */
> + {1,  19, 1, 0, 1}, /* QE_MUX_MDC*/
> + /* QE_MUX_MDIO */
> + {1,  20, 3, 0, 1}, /* QE_MUX_MDIO   */
> +
> + /* UCC_1_MII */
> + {0, 23, 2, 0, 2}, /* CLK12 */
> + {0, 24, 2, 0, 1}, /* CLK9 */
> + {0,  7, 1, 0, 2}, /* ENET1_TXD0_SER1_TXD0  */
> + {0,  9, 1, 0, 2}, /* ENET1_TXD1_SER1_TXD1  */
> + {0, 11, 1, 0, 2}, /* ENET1_TXD2_SER1_TXD2  */
> + {0, 12, 1, 0, 2}, /* ENET1_TXD3_SER1_TXD3  */
> + {0,  6, 2, 0, 2}, /* ENET1_RXD0_SER1_RXD0  */
> + {0, 10, 2, 0, 2}, /* ENET1_RXD1_SER1_RXD1  */
> + {0, 14, 2, 0, 2}, /* ENET1_RXD2_SER1_RXD2  */
> + {0, 15, 2, 0, 2}, /* ENET1_RXD3_SER1_RXD3  */
> + {0,  5, 1, 0, 2}, /* ENET1_TX_EN_SER1_RTS_B*/
> + {0, 13, 1, 0, 2}, /* ENET1_TX_ER   */
> + {0,  4, 2, 0, 2}, /* ENET1_RX_DV_SER1_CTS_B*/
> + {0,  8, 2, 0, 2}, /* ENET1_RX_ER_SER1_CD_B*/
> + {0, 17, 2, 0, 2}, /* ENET1_CRS*/
> + {0, 16, 2, 0, 2}, /* ENET1_COL*/
> +
> + /* UCC_5_RMII */
> + {1, 11, 2, 0, 1}, /* CLK13 */
> + {1, 7,  1, 0, 2}, /* ENET5_TXD0_SER5_TXD0  */
> + {1, 10, 1, 0, 2}, /* ENET5_TXD1_SER5_TXD1  */
> + {1, 6, 2, 0, 2}, /* ENET5_RXD0_SER5_RXD0  */
> + {1, 9, 2, 0, 2}, /* ENET5_RXD1_SER5_RXD1  */
> + {1, 5, 1, 0, 2}, /* ENET5_TX_EN_SER5_RTS_B*/
> + {1, 4, 2, 0, 2}, /* ENET5_RX_DV_SER5_CTS_B*/
> + {1, 8, 2, 0, 2}, /* ENET5_RX_ER_SER5_CD_B*/
> +
> + {0,  0, 0, 0, QE_IOP_TAB_END} /* END of table */
> +};
> +#endif
> +
> int board_early_init_f(void)
> {

Re: [U-Boot] [STATUS: AT91/AVR32]

[Reinhard Meyer]

Dear Uli Raich,
> Dear Reinhard,
> Many thanks for your answer. Only... I do not find a at91sam9260ek in this 
> Makefile. I find at91sam9261ek or  at91sam92603ek though.
> Will try the at91sam92603ek config.
> Uli
1. please *always* reply to the list as well

2. Makefile is not relevant for new/fixed boards anymore.
New/fixed boards are added to boards.cfg (and have to be removed from Makefile)!

3. *ONLY* at91sam9260/9xeek are known to work! at91sam9263ek definitely is not 
working yet,
patches are in the pipeline.

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

[U-Boot] [PATCH] itest: fix result of string compares

[Wolfgang Denk]

The implementation of the string compare function of the "itest"
command was weird, as only the length of the shortest argument was
included in the compare, with the result that something like
"itest.s abd == abddef" would return TRUE.  Fix this.

Signed-off-by: Wolfgang Denk 
---
 common/cmd_itest.c |7 ++-
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/common/cmd_itest.c b/common/cmd_itest.c
index fa6a0c3..2a238a4 100644
--- a/common/cmd_itest.c
+++ b/common/cmd_itest.c
@@ -94,16 +94,13 @@ static char * evalstr(char *s)
 
 static int stringcomp(char *s, char *t, int op)
 {
-   int n, p;
+   int p;
char *l, *r;
 
l = evalstr(s);
r = evalstr(t);
 
-   /* we'll do a compare based on the length of the shortest string */
-   n = min(strlen(l), strlen(r));
-
-   p = strncmp(l, r, n);
+   p = strcmp(l, r);
switch (op) {
case EQ: return (p == 0);
case NE: return (p != 0);
-- 
1.7.4

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

Re: [U-Boot] Can't build dbau1x00 anymore

[Loïc Minier]

On Tue, Feb 08, 2011, Thomas Lange wrote:
> See patch from daniel.schwierz...@googlemail.com
> sent 2011-02-03.

 Aha, I'll try with 17a990b55008fd79636e4880d9d10b7172ca87ce from
 u-boot-mips.git which seems to be the V2 of the patch (removing
 board/dbau1x00/flash.c entirely)

   Thanks!
-- 
Loïc Minier
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try

[Andrew Dyer]

On Mon, Feb 7, 2011 at 16:58, Scott Wood  wrote:
> On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
>> Trying again submitting the patch.
>>
>>               /* Do manufacturer-specific fixups */
>>               switch (info->manufacturer_id) {
>> +             case 0x:
>>               case 0x0001:
>>                       flash_fixup_amd(info, &qry);
>>                       break;
>
> This seems unrelated.
>
> Otherwise, the patch looks good.  Whose tree should it go through?
> It's not really a NAND patch, though NAND is the reason for it.

NAK

This is not only unrelated (which the OP was told to fix on the
previous post of this patch), but wrong.  The S29GL series chips don't
return 0x for the manufacturer ID.  AMD (later Spansion) have
always had mfg. ID 0x0001.

I have various boards with S29GL064, S29GL128N, and S29GL256P, and
they all return the correct value (0x0001) for the mfg. ID.  I looked
up the latest datasheet and they have not changed that section.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [STATUS: AT91/AVR32]

[Reinhard Meyer]

Hello AT91/AVR32 users and maintainers,

since relocation was introduced most ARM boards and therefore all AT91 based 
boards are
inherently broken.

We also used this "opportunity" to rework most of the AT91 include files mess.

You can find the current efforts at git.denx.de/u-boot-atmel.git, branch 
rework110202.

If you are going to fix a board, make sure you base on this branch and take the 
at91sam9260ek
port as an example how it can be done.

There is one important "catch" because of relocation relocates u-boot to top of 
available
RAM: U-boot should not be loaded near top of RAM by at91bootstrap anymore, 
otherwise there
is the risk that relocation will fail due to overlaps.
So you need to fix at91bootstrap to load u-boot to begin of RAM, or, at least,
not near the end of RAM. (It works fine to be loaded to begin of RAM.)

The at91sam9260ek port is proven to build and run.

Before submitting patches please check the following:

1. "#define  1" is depreciated if the "1"  is not of numeric significance, 
use "#define "
instead. Check your board config file for such occurrences.

2. SZ_ macros are depreciated, use (n << 10) for KiB, (n << 20) fir MiB, etc. 
Using
(n * 1024) or (n * 1024 * 1024) are also acceptable as well as other numeric 
values.
It is up to you what you prefer to be readable :)

3. Please run the patch through /scripts/checkpatch.pl; that will 
pinpoint coding style
errors. (I assume you do have a kernel tree somewhere.)

4. If you think you need to change generic AT91 files (header files other than 
for
9260/9261/9263 SoCs), please do so in the style of the 9260/9261/9263 header 
files,
but chancges to other AT91 files should not be necessary), please discuss this 
idea
in the list first.

5. *LEGACY defines should not be needed anymore.

6. reset_phy() seems to be an empty function for some boards. Please remove it 
and the
define that causes it to be called.

7. ...?

Unfortunately I am quite busy at work but I will try to comment and accept 
patches as
soon as time permits.

With Best Regards
Reinhard

PS: this list above might not be complete, clarifications and extensions are 
welcome :)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-boot] sf: API for spi_flash_get_sector_size

[Richard Retanubun]

On 02/08/11 10:19, Wolfgang Denk wrote:
> Dear Richard Retanubun,
>
> In message<4d515d06.7020...@ruggedcom.com>  you wrote:
>>
>> If by "how NOR flash in handled" you mean cmd_flash.c::flash_sect_roundb() 
>> then yes, I do want to do this
>> but I need to know what number to round it to, no?
>
> The code needs to know that, you don't ;-)
>
>> In the context of cmd_flash, it has access to flash_info_t
>> which contains the sector_size information. Also cfi_flash.c also provides a 
>> function called flash_sector_size()
>> that is called by other components that needs to know. If I have 
>> misunderstood what you mean, sorry, please clarify.
>
> You are right.

 ;-)

Thus we come to my original question, in the same way that cfi_flash.c provides 
flash_sector_size();

I propose we add spi_flash.c::spi_flash_sector_size() which returns the same 
information so that other code
can validate (or round up if requested) the length of the operation to the 
nearest sector size.

right now (unless I misunderstood), there is no easy way to get the spi flash 
sector_size, no?

would this be acceptable?

>
>> To have SPI flash do this, for example; stmicro.c::stmicro_erase() function 
>> will auto round up to the nearest sector_size.
>> Which is indeed the simpler way. Right now, most drivers/mtd/spi/*.c just 
>> does this check:
>>
>> 
>> sector_size = stm->params->page_size * stm->params->pages_per_sector;
>>
>> if (offset % sector_size || len % sector_size) {
>>  debug("SF: Erase offset/length not multiple of sector size\n");
>>  return -1;
>> }
>> 
>
> This is ok if an explicit size is given - you will see the same
> behaviour on NOR flash when trying something like
>
>   erase 4000 40002345

Understood. So the spi flash driver erase function itself should only validate 
the args and not auto round up.
This means that the decision of [warn or auto-round-up] should be handled by 
other code that parses the user's commands
that is operating on spi flash.

To do this, they need a way to ask the spi flash driver what the sector size to 
round up to is.

>
>> I am worried about unintentionally erasing more than what the caller 
>> requested.
>> Would it be better to round up manually and then calls the erase?
>
> No.  If the caller uses the "+" notation he explictly requests
> to round up.  He is supposed to know what he is doing.
>
> Being able to use "+${filesize}" allows for many powerful solutions
> to standard tasks that without this would result in cumbersome
> manipulation of the size - which would then probably break if you
> issue a new revision of your hardware with different flash chips fit.

This is a cool convention. Should we add this to "sf erase command?" if it is 
not there already.
if so, what command (or better yet, git commit) shows how to add handling of 
"+N"

Thanks!

- Richard

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

Re: [U-Boot] [U-BOOT] [PATCH] mmc: enable switch partition function

[Lei Wen]

Hi Wolfgang,

On Tue, Feb 8, 2011 at 11:13 PM, Wolfgang Denk  wrote:
> Dear Lei Wen,
>
> In message  you 
> wrote:
>>
>> EMMC is sightly different witht the other device with partition.
>
> Maybe.  But does this really require a different iunterface in the
> U-Boot context?   I doubt that.
>
>> For IDE as example, we could copy file between part A and B without problem.
>
> No, we cannot. U-Boot can only read _or_ write form mass storage
> operations, so a copy operation would always require a "read from
> device to RAM buffer", "write to device from RAM buffer" sequence.
> The same can obviously be done with EMMC as well.
>
>> But for EMMC, the boot partition is different with the normal partition.
>> We need to send a special command to do the switch, not with the
>> different offset.
>
> Thisis an internal implementation detail.  As a user, I do not want to
> know about it. I just want to read or write data to some partition.
> The rest is driver internals.
>
>> If we need to copy file between those two partition, we need to send
>> switch command
>> before copy operation.
>
> So where is the problem?  See above. We always have TWO separate
> operations, and each of them will select a device/partition.
>
>> It is a hardware one. IDE or usb masstorage has no such ability...
>
> I see no difference from the user point of view.  The internal
> implementation may be different, but that doesn't matter.
>
>> For mmc may change the hardware partition, but fat command cannot...
>> It is because
>> it need to be compatiable with other devices that have no hardware 
>> partition...
>
> I don;t understand what you want to tell me here.  My complaint is
> that your new code is _not_ compatible with other divices, and I see
> no reason for such an incompatibility.
>

I am thinking now approach for this.
How about adding addtitional member in the mmc structure, like part.
During mmc probe, the driver could know whether the device support partition
switch or not, if it support, we could register three other "faked" mmc device
corresponding to two boot partition, and RPMB partition.

Then we could use the current command to access the different hardware
partition in the emmc. Like if we are accessing one hardware partition, we need
to send switch command first. If the part member in the mmc is a invalid value,
we then don't send that switch partition command.

Could this approach be acceptable?

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

Re: [U-Boot] [U-boot] sf: API for spi_flash_get_sector_size

[Wolfgang Denk]

Dear Richard Retanubun,

In message <4d515d06.7020...@ruggedcom.com> you wrote:
> 
> If by "how NOR flash in handled" you mean cmd_flash.c::flash_sect_roundb() 
> then yes, I do want to do this
> but I need to know what number to round it to, no?

The code needs to know that, you don't ;-)

> In the context of cmd_flash, it has access to flash_info_t
> which contains the sector_size information. Also cfi_flash.c also provides a 
> function called flash_sector_size()
> that is called by other components that needs to know. If I have 
> misunderstood what you mean, sorry, please clarify.

You are right.

> To have SPI flash do this, for example; stmicro.c::stmicro_erase() function 
> will auto round up to the nearest sector_size.
> Which is indeed the simpler way. Right now, most drivers/mtd/spi/*.c just 
> does this check:
> 
> 
> sector_size = stm->params->page_size * stm->params->pages_per_sector;
> 
> if (offset % sector_size || len % sector_size) {
>   debug("SF: Erase offset/length not multiple of sector size\n");
>   return -1;
> }
> 

This is ok if an explicit size is given - you will se ethe same
behaviour on NOR flash when trying something like

erase 4000 40002345

> I am worried about unintentionally erasing more than what the caller 
> requested.
> Would it be better to round up manually and then calls the erase?

No.  If the caller uses the "+" notation he explictly requests
to round up.  He is supposed to know what he is doing.

Being able to use "+${filesize}" allows for many powerful solutions
to standard tasks that without this would result in cumbersome
manipulation of the size - which would then probably break if you
issue a new revision of your hardware with different flash chips fit.

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'll excuse me a minute, I'm going to have a cup of coffee."
- broadcast from Apollo 11's LEM, "Eagle", to Johnson  Space  Center,
Houston July 20, 1969, 7:27 P.M.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-BOOT] [PATCH] mmc: enable switch partition function

[Wolfgang Denk]

Dear Lei Wen,

In message  you 
wrote:
> 
> EMMC is sightly different witht the other device with partition. 

Maybe.  But does this really require a different iunterface in the
U-Boot context?   I doubt that.

> For IDE as example, we could copy file between part A and B without problem.

No, we cannot. U-Boot can only read _or_ write form mass storage
operations, so a copy operation would always require a "read from
device to RAM buffer", "write to device from RAM buffer" sequence.
The same can obviously be done with EMMC as well.

> But for EMMC, the boot partition is different with the normal partition.
> We need to send a special command to do the switch, not with the
> different offset.

Thisis an internal implementation detail.  As a user, I do not want to
know about it. I just want to read or write data to some partition.
The rest is driver internals.

> If we need to copy file between those two partition, we need to send
> switch command
> before copy operation.

So where is the problem?  See above. We always have TWO separate
operations, and each of them will select a device/partition.

> It is a hardware one. IDE or usb masstorage has no such ability...

I see no difference from the user point of view.  The internal
implementation may be different, but that doesn't matter.

> For mmc may change the hardware partition, but fat command cannot...
> It is because
> it need to be compatiable with other devices that have no hardware 
> partition...

I don;t understand what you want to tell me here.  My complaint is
that your new code is _not_ compatible with other divices, and I see
no reason for such an incompatibility.

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
Computers are not intelligent. They only think they are.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-boot] sf: API for spi_flash_get_sector_size

[Richard Retanubun]

On 02/08/11 09:40, Wolfgang Denk wrote:

Thanks for the speedy response Wolfgang,

> Dear Richard Retanubun,
>
> In message<4d514f6e.6040...@ruggedcom.com>  you wrote:
>>
>> When calling spi_flash_erase, which eventually calls stmicro_erase, one must 
>> do so while knowing
>> what the sector_size is of the flash. Is there a recommened API to getting 
>> this from struct stmicro_spi_flash_params?
>
> Why would you need to know the sector size?
>
> To align your erase command accordingly?
Yep.

I think you are taking the wrong approach here.  Look at how NOR flash is 
handled: we don't need
> to know the sector sizes there either.  Instead we support the format
> "+N" (often used as "+${fileszize}") which will _internally_ round up
> N to match the next erase block boundary.
>
> Do the same for SPI flash.

If by "how NOR flash in handled" you mean cmd_flash.c::flash_sect_roundb() then 
yes, I do want to do this
but I need to know what number to round it to, no?

In the context of cmd_flash, it has access to flash_info_t
which contains the sector_size information. Also cfi_flash.c also provides a 
function called flash_sector_size()
that is called by other components that needs to know. If I have misunderstood 
what you mean, sorry, please clarify.


To have SPI flash do this, for example; stmicro.c::stmicro_erase() function 
will auto round up to the nearest sector_size.
Which is indeed the simpler way. Right now, most drivers/mtd/spi/*.c just does 
this check:


sector_size = stm->params->page_size * stm->params->pages_per_sector;

if (offset % sector_size || len % sector_size) {
debug("SF: Erase offset/length not multiple of sector size\n");
return -1;
}


I am worried about unintentionally erasing more than what the caller requested.
Would it be better to round up manually and then calls the erase?

Thanks for your time

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

Re: [U-Boot] [U-BOOT] [PATCH] mmc: enable switch partition function

[Lei Wen]

Hi Wolfgang,

On Tue, Feb 8, 2011 at 10:27 PM, Wolfgang Denk  wrote:
> Dear Lei Wen,
>
> In message <1296463665-26551-1-git-send-email-lei...@marvell.com> you wrote:
>> For emmc, it may has upto 7 partitions: two boot partitions, one
>> user partition, one RPMB partition and four general purpose partitions.
>> (Refer to JESD84-A44.pdf/page 154)
>>
>> As bootloader may need to read out or reflashing images on those
>> different partitions, it is better to enable the partition switch with
>> console command support.
>
> Other devices - say, USB mass storage devices, IDE disks, etc. - have
> partitions, too, and do not need any such special command.

EMMC is sightly different witht the other device with partition.
For IDE as example, we could copy file between part A and B without problem.
It is for the different partition start at different offset in the
physical media.
Just adding the offset with the read address would make this works, so it is
some kind of software implementation.

But for EMMC, the boot partition is different with the normal partition.
We need to send a special command to do the switch, not with the
different offset.
If we need to copy file between those two partition, we need to send
switch command
before copy operation.
It is a hardware one. IDE or usb masstorage has no such ability...

>
>> @@ -247,5 +268,6 @@ U_BOOT_CMD(
>>       "mmc write  addr blk# cnt\n"
>>       "mmc rescan \n"
>>       "mmc part  - lists available partition on mmc\n"
>> +     "mmc sw_part   - switch part support for emmc\n"
>>       "mmc list - lists available devices");
>
> Why would we need a separate command here?
>
>
> Please rework this so it uses the same mechanism we use on all other
> storage devices, without an extra command here.
>

The problem here is that the need to switch this hardware partition
only make sense
to the emmc. If make it generic to the other mmc command, it seems a
bit of weird for the
sd/mmc...

Also add additional command here is the minimual change. If insert
this into already existed
mmc command would make the fat command hard to work.
For mmc may change the hardware partition, but fat command cannot...
It is because
it need to be compatiable with other devices that have no hardware partition...

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

Re: [U-Boot] Can't build dbau1x00 anymore

[Thomas Lange]

Hi,

On 2011-02-07 22:25, Loïc Minier wrote:
> Hi
> 
>  u-boot 2010.09 used to build under Debian mipsel, but failed building
>  starting with 2010.12 with this error:
> /usr/bin/make -C 
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/board/dbau1x00/ 
> u-boot.lds
> make[2]: Entering directory 
> `/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/board/dbau1x00'
> make[2]: Nothing to be done for `u-boot.lds'.
> make[2]: Leaving directory 
> `/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/board/dbau1x00'
> gcc -E -g  -Os   -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xbfc0 
> -I/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/include2
>  
> -I/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/include
>  -I/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/include 
> -fno-builtin -ffreestanding -nostdinc -isystem 
> /usr/lib/gcc/mipsel-linux-gnu/4.4.5/include -pipe  -DCONFIG_MIPS -D__MIPS__ 
> -G 0 -mabicalls -fpic -msoft-float -march=4kc -mtune=4kc -include 
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/include/u-boot/u-boot.lds.h
>   -ansi -D__ASSEMBLY__ -P - 
>   
> >/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/u-boot.lds
> UNDEF_SYM=`objdump -x 
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/board/dbau1x00/libdbau1x00.o
>  
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/api/libapi.o
>  
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/arch/mips/cpu/libmips.o
>  
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/arch/mips/lib/libmips.o
>  
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/common/libcommon.o
>  
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/disk/libdisk.o
>  
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/bios_emulator/libatibiosemu.o
>  
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/block/libblock.o
>  
> /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/dma/libdma.o
>  /build/buildd-u-boot
_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/fpga/libfpga.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/gpio/libgpio.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/hwmon/libhwmon.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/i2c/libi2c.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/input/libinput.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/misc/libmisc.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/mmc/libmmc.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/mtd/libmtd.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/mtd/nand/libnand.o
 /build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/deb
ian/build/dbau1100/drivers/mtd/onenand/libonenand.o 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/mtd/spi/libspi_flash.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/mtd/ubi/libubi.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/net/libnet.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/net/phy/libphy.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/pci/libpci.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/pcmcia/libpcmcia.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/power/libpower.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/rtc/librtc.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/driv
ers/serial/libserial.o 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/spi/libspi.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/twserial/libtws.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/usb/gadget/libusb_gadget.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/usb/host/libusb_host.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8UfBj/u-boot-2010.12/debian/build/dbau1100/drivers/usb/musb/libusb_musb.o
 
/build/buildd-u-boot_2010.12-2-mipsel-Q8U

Re: [U-Boot] [U-boot] sf: API for spi_flash_get_sector_size

[Wolfgang Denk]

Dear Richard Retanubun,

In message <4d514f6e.6040...@ruggedcom.com> you wrote:
> 
> When calling spi_flash_erase, which eventually calls stmicro_erase, one must 
> do so while knowing
> what the sector_size is of the flash. Is there a recommened API to getting 
> this from struct stmicro_spi_flash_params?

Why would you need to know the sector size?

To align your erase command accordingly?  I think you are taking the
wrong approach here.  Look at how NOR flash is handled: we don't need
to know the sector sizes there either.  Instead we support the format
"+N" (often used as "+${fileszize}") which will _internally_ round up
N to match the next erase block boundary.

Do the same for SPI flash.

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 first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-BOOT] [PATCH] mmc: enable switch partition function

[Wolfgang Denk]

Dear Lei Wen,

In message <1296463665-26551-1-git-send-email-lei...@marvell.com> you wrote:
> For emmc, it may has upto 7 partitions: two boot partitions, one
> user partition, one RPMB partition and four general purpose partitions.
> (Refer to JESD84-A44.pdf/page 154)
> 
> As bootloader may need to read out or reflashing images on those
> different partitions, it is better to enable the partition switch with
> console command support.

Other devices - say, USB mass storage devices, IDE disks, etc. - have
partitions, too, and do not need any such special command.

> @@ -247,5 +268,6 @@ U_BOOT_CMD(
>   "mmc write  addr blk# cnt\n"
>   "mmc rescan \n"
>   "mmc part  - lists available partition on mmc\n"
> + "mmc sw_part   - switch part support for emmc\n"
>   "mmc list - lists available devices");

Why would we need a separate command here?


Please rework this so it uses the same mechanism we use on all other
storage devices, without an extra command here.

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
The following statement is not true.  The previous statement is true.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-BOOT] [PATCH] mmc: enable switch partition function

[Wolfgang Denk]

Dear Lei Wen,

In message  you 
wrote:
>
> Does this patch could get the chance to be included in the 2011.03 release?

This is not a bug fix, and it was submitted after the merge window
was closed.

> I just see it haven't gotten any response after eight days...

Will reply ASAP.

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
Why is an average signature file longer than an average Perl script??
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [U-boot] sf: API for spi_flash_get_sector_size

[Richard Retanubun]

Hello,

I am working on hooks to build into my board to allow for SPI flash (STMicro 
M25P40 and M25P16) reflash.
When calling spi_flash_erase, which eventually calls stmicro_erase, one must do 
so while knowing
what the sector_size is of the flash. Is there a recommened API to getting this 
from struct stmicro_spi_flash_params?

There are things like the "to_stmicro_spi_flash" #define in stmicro.c, but that 
is private.

Will adding this API be okay?

int spi_flash_get_sector_size(struct spi_flash *sf) that will simply return the 
sector_size number or an errno.

thanks for everyone's time

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

[U-Boot] [Nios] Pull Request

[Scott McNutt]

Dear Wolfgang,

The following changes since commit 8d4addc3c3fe1a9ea160a5a1a20a1f934ff3fe97:
   Wolfgang Denk (1):
 Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx

are available in the git repository at:

   git://git.denx.de/u-boot-nios.git next

Thomas Chou (4):
   nios2: add gpio_free
   altera_spi: add spi_set_speed
   nios2: use long for ssize_t
   nios2: add gpio_is_valid

  arch/nios2/include/asm/gpio.h|   12 
  arch/nios2/include/asm/posix_types.h |2 +-
  board/altera/nios2-generic/custom_fpga.h |1 +
  board/altera/nios2-generic/gpio.c|   11 +++
  drivers/spi/altera_spi.c |5 +
  5 files changed, 30 insertions(+), 1 deletions(-)

Regards,
--Scott

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

Re: [U-Boot] {Spam?} u-boot-usb DFU working but need some ideas

[Detlev Zundel]

Hi Marcel,

> I finally got things working well with my SAM9G45 USB devcie controller and 
> continued to implement DFU for it. 
> I implemented it using the new gadget layer and should be compatible with the 
> at91_udc driver.

Excellent, congratulations!

> I have managed to get DFU working in such way that it transfers the file to 
> RAM.  There's still a lot to do, but most things are in place and working 
> well. Basically after transfer to RAM,  a u-boot script can handle additional 
> actions, so I'm in doubt about the following :
>
> The DFU implementation I used as a basis came from openmoko. This implements 
> directly flashing the device.
> However, my thought is that it's much better to just write the file to RAM 
> and 
> let a script in u-boot handle what should happen with it (verify, boot, flash)
> The DFU spec seems to handle this with the bitManifestationTolentant bit, but 
> the current dfu-utils don't use this bit (that can be updated of course, 
> which 
> I already did).

I am not too familiar with the DFU spec, but I agree with regards to the
scripting.  I can envision usage scenarios where the downloaded files
are written to other storage media, so I would much rather leave that up
to the U-Boot script interpreter.

> About the way it currently works :
> 1) I start u-boot
> 2) I issue the dfuinit command (new)
> 3) the host can now download a file to RAM.
> Any thoughts on what would be the most preferred way to do this ?

This sequence sounds absolutely feasible.  What exactly is your
question?

> Additionally I think I will implement this as a composite driver so that both 
> (usb)CDC and DFU are available via USB. I have both working, but currently 
> must select it at compile time.
> My current implementation basically is just DFU as it assumes the application 
> (not u-boot) to be the firmware to be updated, so no need to switch on 
> descriptor layer level.
>
> Any reply on this would be nice, even if my above thoughts are in line.
> I hope to be able to post my changes in 1-2 weeks. After that my time is 
> extremely limited due to long time travel.

I'm really looking forward to getting DFU support into U-Boot - having
lobbyied for it quite a while :)

> If anyone is interested in helping me out posting the changes it would
> be very much appreciated.

What help do you need?

Cheers
  Detlev

-- 
Emacs seems a more likely candidate  to contain a mail system than the
mail system to contain an Emacs, so this is the way it was done.
-- Bernard S. Greenberg
--
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] Some notes and status on porting U-Boot to the Cavium 64-bit Octeon MIPS Processor

[Wolfgang Denk]

Dear Aaron Williams,

In message <201102071524.17440.aaron.willi...@caviumnetworks.com> you wrote:
>
> > these.  I understand that you are using a 64 bit port of U-Boot?
> 
> No. We are using a 32-bit port since I think trying to make a 64-bit port of 
> U-Boot would be far more involved. We do have support for loading and 
> executing 64-bit ELF images, however. We use special memcpy/memset functions 
> for 64-bit memory addressing in these cases.

OK, let's discuss this when we see your code.

> > Existing U-Boot deals with this by mapping just the lower and the
> > upper parts of available physical memory. See the CONFIG_VERY_BIG_RAM
> > config option.
> > 
> I just looked at this and this. The only place I see this used is in 
> arch/powerpc/lib/board.c and it looks like it just limits the effective 
> memory 
> size to CONFIG_MAX_MEM_MAPPED. This won't work for us. As I said, we need to 
> move it out of the lower 4GB when there's more memory involved. We also don't 

Why?

> want there being holes in the middle of the memory if we can help it, nor do 
> we want to place u-boot at the lower end of memory. At least on MIPS the TLB 

The question is what is the lesser of two evils: not mapping all of
the available memory and stick with a total of mapped memory that is
addressable in 32 bit adress space, or adding the complexity to deal
with 64 bit address spaces - which will require changes in _lots_ of
places.

But again I suggst to defer the discussion until we see your code.

> Would using virt_to_bus to convert pointers to DMA addresses be appropriate 
> instead of the current assumption that pointers can be used as DMA addresses 
> directly? This seems like a portable solution since on platforms where the 
> pointer and DMA address are the same the macro would just do nothing. Even if 
> we didn't use virtual addresses and were using, say, KSEG1 the pointer and 
> physical address don't match.

Yes, I think this would indeed be a better approach.

> > Do I understand correctly t hat this SDK (whatever that might be) will
> > then have to be included with the U-Boot distribution?
> > 
> > What would be alternatives to static linking, such as to avoid adding
> > all this code?
> > 
> It would have to be included only for the Octeon processors. It is statically 

I don't undertsand what you mean. Either it is part of the U-Boot
source tree, or it is not.  You cannot add it "only for the Octeon
processors" - either it's there, or it ain't.

Given that we are talking about code in the order of 30% of the total
U-Boot code, probably not conforming to U-Boot coding standards, I am
anything but happy about such an addition.  Assume ever SoC vendor
comes up with similar ideas...

> linked and we don't want to get away from this. Also, some of our u-boot 
> files 
> are in turn statically linked against some of our utilities, such as our 

I understand that you do not _want_ to change this.  My question is:
what would you do if you _had_ to change it?

> Also note that u-boot for Octeon can only be compiled with our toolchain, 
> since there is some dependency on some of the include files from our GCC 
> distribution as well, plus our toolchain distribution includes support for 
> some of the extensions we make use of.

Can this be fixed?  I mean, copying some header files should probably
be a solvable problem.  What about of these "extensions" - are they
absolutely needed in U-Boot?  Usually such extensions are either
performance optimizations which are not really needed in U-Boot, or
other well-localized operations that can b ehandlef with small
assembler stubs.


> > Such general changes should then NOT use CONFIG_OCTEON, but some
> > generic variable name.
> > 
> I agree, though some many cases they are not general, such as some of the 
> support for our compact flash in cmd_ide.c and a few other areas.

In general we do not want to see board or SoC specific changes to
common code.

> > Many boards use board specific commands; I see no problem with having
> > SoC specific commands either.
> 
> I am placing these commands under arch/mips/cpu/octeon/commands rather than 
> clutter up the common code, unless you feel it's better to put all the 
> commands under the common code.

This sounds OK with me.

> > > I don't think I can include our SDK as a series of patches on the mailing
> > > list since it is about 26MB with some of the hardware generated files
> > > being hundreds of kilobytes to 12MB for our register database file
> > > (which fortunately isn't needed by u-boot!) It's available under the
> > > LGPL but not easily accessible through our open-source web site without
> > > registration :(
> > 
> > U-Boot is supposed to be self-sufficient, i. e. to contain all parts
> > that are required to build a working U-Boot image.  I see a potential
> > area of conflicts here.
> 
> We don't have any problem including our SDK with U-Boot. I can work on trying 

But  we probably will have problems adding tons 

[U-Boot] at91sam9263ek build is broken

[Uli Raich]

Hi all,
Since some time I am using an arm at91sam9263 board from a young polish company 
named creotech. The board is similar to an Atmel at91sam9263ek from atmel but 
has a series of subtle differences. May goal is to write a new configuration 
for this board. To start off I tried to build u-boot for the existing 
at91sam9263ek configuration, which fails. First it complains that 
CONFIG_AT91FAMILY was missing, which I added to include/configs/ 
at91sam9263ek.h.
Then it asks for CONFIG_SYS_SDRAM_BASE, which I could also guess. I am not sure 
about CONFIG_SYS_INIT_SP_ADDR (no description in the README file) however. I 
gave it a guess looking up u-boot-1.3.4 of which I have a working version for 
my board. Then however it complains about undeclared AT91_BASE_SYS and 
AT91_DBGU when compiling drivers/serial/atmel_usart.c. I see that this includes 
 which uses these definitions when declaring 
USART3_BASE, the console port for the board. memory-map.h  includes hardware.h 
which should include  if CONFIG_AT91SAM9263 is defined, 
which is the case in the basic configuration file  include/configs/ 
at91sam9263ek.h.
For the moment I am puzzled.
I would be grateful also for an explication of CONFIG_SYS_INIT_SP_ADDR.
Thanks Uli

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