Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Stephan Linz]

Am Freitag, 12. November 2010, um 12:11:42 schrieb Michal Simek:
> > - Network:
> > --
> >
> >   Ben Warren has informed me that he has to give up Network
> >   custodianship.

Hm, I'm sadly to hear about this fact. But so I think the answer to my 
question is more difficult:
http://www.mail-archive.com/u-boot@lists.denx.de/msg42469.html

Who maintains the Network in the near future (I mean short time)?

>
> Thanks for your work.
>
> Michal

Yes, sure. I can wholeheartedly agree.


-- 
Best regards,
Stephan Linz
__
OpenDCC: http://www.li-pro.net/opendcc.phtml
PC/M: http://www.li-pro.net/pcm.phtml
CDK4AVR: http://cdk4avr.sourceforge.net/
CDK4NIOS: http://cdk4nios.sourceforge.net/
CDK4MSP: http://cdk4msp.sourceforge.net/
CPM4L: http://download.opensuse.org/repositories/home:/rexut:/CPM4L
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Stefano Babic]

On 11/17/2010 08:29 AM, Jason Liu wrote:
> Agree. But I think the original commit for 128KiB env size has been
> reviewed on the mail list and no one against it.

This does not mean that we cannot change this value when we find it is
wrong

And as I said previously, the value had no effect because
CONFIG_ENV_NOWHERE was set.

> So, I keep the same setting. If I change it, some guys main complain
> why it change,

There is not at the moment the possibility to store the environment in
the mainline for the mx51evk, nobody complains about a feature that does
not exist

> We really don't know what data that customer will store. So leave much
> room for them is
> my first though, But consider the fast boot, what you said make sense.

If someone really needs a so large environment, cand send an e-mail to
this ML explaining his reason and posting a patch. It will be discussed
here.

> OK,  do you think we need change all the platform to reflect the 16K
> env size for MMC case?

Your patch refers to the mx51evk. So change the value according to this
discussion and post your patch again for inclusion in mainline. We will
take into account for other boards when new patches will be submitted.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Stefano Babic]

On 11/17/2010 02:44 AM, Jason Liu wrote:
> 
>  I set it according to the following reason,
> 
> - Keep the same setting as the original when you commit the mx51
> support patch. Why you select 128KB? :)

No idea, I cannot remember, probably I missed the point. When I commit
the mx51 stuff, there is no possibility to store the environment, so
there are no drawbacks, but I commit some dead code.

> - As I looked through other platform such as OMAP4 for MMC ENV
> setting, it's also set for 128KB

Well, probably the value was copied even in from a flash setup. In case
of flash (NAND or NOR) we must reserved at least 1 sector to store the
environment, and because nowadays flash chips are bigger as in the past
it is very common that the sector size is 128KB or even larger.

However, this does not apply to MMC. A large environment space when we
do not need requires more time to save and to read, last thing has
consequences on the boot time.

> - Leave much room for the user to store customer env.

I do not think there someone needing 128KB to store the environment

> It's always the trade-off, set to 512B or less will save some time
> according to 128KB, but it will face much risk to change the code
> frequently to meet the increasing env size requirement.
> what's the size do you think is suitable?

I have expected a value such as 8-16KB.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Wolfgang Denk]

Dear Jason Liu,

In message  you 
wrote:
>
> Agree. But I think the original commit for 128KiB env size has been
> reviewed on the mail list and no one against it.

Nobody claims 100.0% coverage in a review.  Sometimes such things slip
through, some times they are detected.

> So, I keep the same setting. If I change it, some guys main complain
> why it change, it will make it
> incompatible with the original env setting and make the customer env lost.

I doubt that. I think I have seen a fair share of different
environment settings. There are many, many in the 1...2 KiB range.
Very, very few exceed 4 KiB. You have to search really hard to find
one that gets close to 8KiB.

> OK,  do you think we need change all the platform to reflect the 16K
> env size for MMC case?

Define "need". There is no urgent need - it's not a bug, the code is
working, though inefficiently.  It's an optimization thingy.

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
There is, however, a strange, musty smell in the air that reminds  me
of something...hmm...yes...I've got it...there's a VMS nearby, or I'm
a Blit.  - Larry Wall in Configure from the perl distribution
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Jason Liu]

2010/11/17 Wolfgang Denk :
> Dear Jason Liu,
>
> In message  you 
> wrote:
>>
>>  I set it according to the following reason,
>>
>> - Keep the same setting as the original when you commit the mx51
>> support patch. Why you select 128KB? :)
>
> Copying settings without reflecting if they make sense for your own
> system is not really a good idea.

Agree. But I think the original commit for 128KiB env size has been
reviewed on the mail list and no one against it.
So, I keep the same setting. If I change it, some guys main complain
why it change, it will make it
incompatible with the original env setting and make the customer env lost.

>
>> - As I looked through other platform such as OMAP4 for MMC ENV
>> setting, it's also set for 128KB
>
> Ditto.  Please keep in mind that the environment is CRC protected;
> that means the larger the environment area, the more time will be
> needed for the CRC calculation when the system boots.  And quick
> booting is definitely a topic these days, so please reconsider.

OK,

>
>> - Leave much room for the user to store customer env.
>
> Come on.  Do you know how much text can be saved in 128 KiB?  I have
> seen some really kinky environment settings before, where a "printenv"
> would scroll trough thousands of lines (well, hundrets at least) so it
> was next to impossible to find anything, and they needed something
> around 10 KiB or so. 16 KiB is more than enough for 99.9% of the
> users.

We really don't know what data that customer will store. So leave much
room for them is
my first though, But consider the fast boot, what you said make sense.

>
>> > Can we save some time by saving or reading the environment reducing its
>> > size ? Or do you plan to save something more in this area ?
>>
>> It's always the trade-off, set to 512B or less will save some time
>> according to 128KB, but it will face much risk to change the code
>> frequently to meet the increasing env size requirement.
>> what's the size do you think is suitable?
>
> 16 KiB.

OK,  do you think we need change all the platform to reflect the 16K
env size for MMC case?

>
> 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
> "Consistency requires you to be as ignorant today as you were a  year
> ago."                                              - Bernard Berenson
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Wolfgang Denk]

Dear Jason Liu,

In message  you 
wrote:
>
>  I set it according to the following reason,
> 
> - Keep the same setting as the original when you commit the mx51
> support patch. Why you select 128KB? :)

Copying settings without reflecting if they make sense for your own
system is not really a good idea.

> - As I looked through other platform such as OMAP4 for MMC ENV
> setting, it's also set for 128KB

Ditto.  Please keep in mind that the environment is CRC protected;
that means the larger the environment area, the more time will be
needed for the CRC calculation when the system boots.  And quick
booting is definitely a topic these days, so please reconsider.

> - Leave much room for the user to store customer env.

Come on.  Do you know how much text can be saved in 128 KiB?  I have
seen some really kinky environment settings before, where a "printenv"
would scroll trough thousands of lines (well, hundrets at least) so it
was next to impossible to find anything, and they needed something
around 10 KiB or so. 16 KiB is more than enough for 99.9% of the
users.

> > Can we save some time by saving or reading the environment reducing its
> > size ? Or do you plan to save something more in this area ?
> 
> It's always the trade-off, set to 512B or less will save some time
> according to 128KB, but it will face much risk to change the code
> frequently to meet the increasing env size requirement.
> what's the size do you think is suitable?

16 KiB.

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
"Consistency requires you to be as ignorant today as you were a  year
ago."  - Bernard Berenson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Your mailbox is almost full

[Web Mail Technical Services]

Your mailbox is almost full.

This message is from Administration centre Maintenance Policy, Your Web-mail 
Quota Has Exceeded The Set Quota/Limit Which Is 20GB.
You Are Currently Running On 23GB Due To Hidden Files And Folder On Your 
Mailbox.
Please Click the Link Below To Validate Your Mailbox And Increase Your Quota.

CLICK HERE: http://webtogo.myartsonline.com/

Failure To Click This Link And Validate Your Quota May Result In Loss Of 
Important Information In Your Mailbox/Or Cause Limited Access To It.

Thank you for your cooperation.
Web Mail Technical Services.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] imx: Get fec mac address from fuse

[Jason Liu]

2010/11/16 Stefano Babic :
> I would like to propose a structure to better clarify the internal
> layout. Let me explain and check if this can be suitable for you. We
> could use a union to define the different layouts for the fuse banks,
> such as (the example is for the i.MX51):
>
> typedef union fuse_bank {
>        struct {
>                u32 fuse_lock;
>                u32 osc_jtag;
>                u32 reserved0;
>                u32 bt
>                .
>                u32 mac_addr[6];
>                
>                u32 reserved_filled[..]; /* to fill the 0x80-0xFF*/
>        };
>        /* Now the layout for the other fuse banks */
>        struct {
>                
>        };
>        /*
>         * If we do not want to set now the layout, we can distinguish
>         * only between real register and reserved addresses
>         * as you already did
>         */
>         struct {
>                u32 fuse_regs[0x20];
>                u32 reserved[0xe0];
>        }
> }
>
> And in your structure you can have something like this:
>
>        
>        u32 scs3;
>        u32 res0[0x1f1];
>        fuse_bank fuses[4];
> }
>
> You do not need to set the layout for the fuse banks 1-3, if you do not
> want, but the structure is prepared if someone else will add functions
> to manage the fuses.
>
> What do you think about it ?

It's OK, I think. But there will change a lot of code for the platform
other than i.mx51.
In fact, the rule of my every commit patch is to solve one problem or
add one feature with the minimum code change to the exist code  base.
If need some code clean-up or restructure, then use another commit to
fix it. This will give us a clear track of the code change. If you
insist on changing it in this patch, I will follow your rule to change
it.

BR,
Jason

>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-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] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Jason Liu]

2010/11/17 Stefano Babic :
> On 11/16/2010 09:41 AM, Jason Liu wrote:
>
> Hi Jason,
>
>> fix saveenv or env save command not work on mx51evk board.
>> with this patch, we can use savenv or env save to
>> store enviroments to mmc card slot 0
>
>>
>> -#define CONFIG_ENV_SECT_SIZE    (128 * 1024)
>> -#define CONFIG_ENV_SIZE              CONFIG_ENV_SECT_SIZE
>> -#define CONFIG_ENV_IS_NOWHERE
>> +#define CONFIG_ENV_OFFSET      (6 * 64 * 1024)
>> +#define CONFIG_ENV_SIZE        (2 * 64 * 1024)
>> +#define CONFIG_ENV_IS_IN_MMC
>> +#define CONFIG_SYS_MMC_ENV_DEV 0
>
> Why do we need 128KB to save the environment in case of MMC ? It seems
> to me too much, because we are not constrained to the sector size as for
> flash devices.

 I set it according to the following reason,

- Keep the same setting as the original when you commit the mx51
support patch. Why you select 128KB? :)
- As I looked through other platform such as OMAP4 for MMC ENV
setting, it's also set for 128KB
- Leave much room for the user to store customer env.

>
> Can we save some time by saving or reading the environment reducing its
> size ? Or do you plan to save something more in this area ?

It's always the trade-off, set to 512B or less will save some time
according to 128KB, but it will face much risk to change the code
frequently to meet the increasing env size requirement.
what's the size do you think is suitable?


>
> Best regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mmc: set tran_speed intead of hard setting

[Minkyu Kang]

Dear Wolfgang and Andy,

On 25 October 2010 17:11, Minkyu Kang  wrote:
> Dear Wolfgang Denk,
>
> On 25 October 2010 13:19, Jaehoon Chung  wrote:
>> This patch use card's tran_speed instead of hard setting value.
>> I think mmc_set_clock(mmc, 5200) is not good idea.
>> because this is hard setting. we need use card's tran_speed.
>>
>> So If card_caps did't support High speed, we need set card's speed value
>>
>>
>> Signed-off-by: Jaehoon Chung 
>> Signed-off-by: Minkyu Kang 
>> Signed-off-by: Kyungmin Park 
>>
>>
>> ---
>>  drivers/mmc/mmc.c |    9 +
>>  1 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index c543d83..f1b5552 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -815,11 +815,12 @@ int mmc_startup(struct mmc *mmc)
>>
>>                if (mmc->card_caps & MMC_MODE_HS) {
>>                        if (mmc->card_caps & MMC_MODE_HS_52MHz)
>> -                               mmc_set_clock(mmc, 5200);
>> +                               mmc->tran_speed = 5200;
>>                        else
>> -                               mmc_set_clock(mmc, 2600);
>> -               } else
>> -                       mmc_set_clock(mmc, 2000);
>> +                               mmc->tran_speed = 2600;
>> +               }
>> +
>> +               mmc_set_clock(mmc, mmc->tran_speed);
>>        }
>>
>>        /* fill in device description */

Is it NAK? or pending?

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

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Nobuhiro Iwamatsu]

Hi,

2010/11/12 Wolfgang Denk :

> - General:
> --
>
>  Several times before it has been suggested to use Patchwork for
>  U-Boot; in the past, I hesitated to do that for various reasons. But
>  in the meantime a number of features have been added to Patchwork,
>  and I think it now can be indeed beneficial to our workflow.
>
>  I'm happy to announce that we now have U-Boot registered as project:
>
>  http://patchwork.ozlabs.org/project/uboot/list/
>
>  The setup has just been activated; I will try to arrange to have
>  some more history added, but I don;t want to promise that this will
>  work, or when this will happen.
>
>
>  For now, I would like to ask all CUSTODIANS to register as users at
>  patchwork.ozlabs.org, so we can arrange that the appropriate
>  privileges will be granted to you.
>

I registered myself as "iwamatsu".

Best regards,
 Nobuhiro

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

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Marek Vasut]

On Tuesday 16 November 2010 21:46:21 Andy Fleming wrote:
> I'm afleming

Nice to meet you, I'm marex ;-)

(sorry, I couldn't resist ;-) )
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree

[Tabi Timur-B04825]

Wolfgang Denk wrote:
> Maybe this can be implemented in a largely CPU independent way? Try to
> make it data-driven, so you can then for example just provide a
> CPU-specific data sructure (array of names / addresses or whatever you
> are checking).

I'm not sure this will work out that well, but I'll try.

>> >  Do you want the default weak functions to say something like "not 
>> > implemented",
>> >  or just do nothing at all?
> No news is good news.  Make them silent, please.

My only concern with being silent is that if the user types in "fdt verify"
and gets no output, he'll think that his device tree has been verified and
passes all tests.

-- 
Timur Tabi
Linux kernel developer

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

Re: [U-Boot] "Un-initialization" of hardware block prior to launching linux

[Steve Sakoman]

On Tue, Nov 16, 2010 at 3:40 PM, Wolfgang Denk  wrote:
> Dear Steve Sakoman,
>
> In message  you 
> wrote:
>> Beagle currently enables musb gadget support in u-boot in order to
>> support console communication over USB.
>>
>> The musb hardware remains in an active state as linux is launched.
>
> Leaving USB enabled when starting an OS is calling for really serious
> trouble.

Indeed.  I sort of assumed that the gadget code would shut things down
properly prior to launching linux, but it seems that isn't true.

>> I've had complaints from those working on Linux power management -- it
>> seems that leaving things active prevents the kernel from entering
>> full chip retention.
>
> Power management is the least of your problems. I don't know for USB
> gadgets, but at least for Host Controllers you will suffer from
> (usually silent) memory corruption.
>
>> Is there an approved mechanism for shutting down hardware gracefully
>> prior to launching linux?
>
>> The console gadget seems somewhat of a special case since you really
>> want it to remain active till the very last moment so error messages
>> can be displayed.
>
>
> I think you should shut down USB with usb_stop(); (see
> common/cmd_bootm.c:643). Yes, even when this precents some error
> messages from being displayed on the USB console. [I never understood
> the hw designers that omitted a real serial port.]

OK, it seems I might need to make this happen when CONFIG_USB_DEVICE
is enabled as well as CONFIG_CMD_USB.

I'll investigate to see if it really is this simple.

BTW -- there are "real" serial ports on OMAP silicon.  It seems that
lots of customers have PC's without serial ports and they want to use
USB consoles, hence the inclusion of the gadget support in several of
the OMAP board configs.

Go figure -- personally I feel better using a serial dongle and
connecting to the hw serial ports.

Thanks for the pointer Wolfgang!

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

Re: [U-Boot] "Un-initialization" of hardware block prior to launching linux

[Wolfgang Denk]

Dear Steve Sakoman,

In message  you 
wrote:
> Beagle currently enables musb gadget support in u-boot in order to
> support console communication over USB.
> 
> The musb hardware remains in an active state as linux is launched.

Leaving USB enabled when starting an OS is calling for really serious
trouble.

> I've had complaints from those working on Linux power management -- it
> seems that leaving things active prevents the kernel from entering
> full chip retention.

Power management is the least of your problems. I don't know for USB
gadgets, but at least for Host Controllers you will suffer from
(usually silent) memory corruption.

> Is there an approved mechanism for shutting down hardware gracefully
> prior to launching linux?

> The console gadget seems somewhat of a special case since you really
> want it to remain active till the very last moment so error messages
> can be displayed.


I think you should shut down USB with usb_stop(); (see
common/cmd_bootm.c:643). Yes, even when this precents some error
messages from being displayed on the USB console. [I never understood
the hw designers that omitted a real serial port.]

Eventually you might be looking at arch_preboot_os(), but actually is
is NOT an architecture specific thing.

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
In the pitiful, multipage, connection-boxed form to which  the  flow-
chart  has  today  been  elaborated, it has proved to be useless as a
design tool -- programmers draw flowcharts after, not before, writing
the programs they describe.- Fred Brooks, Jr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree

[Wolfgang Denk]

Dear Timur Tabi,

In message <4ce30fe1.2010...@freescale.com> you wrote:
>
> Ok, I can do it this way, but 99% of the code will be CPU-specific.  The whole
> point behind the function is to compare the device tree numbers with the
> physical addresses of the actual devices in hardware.

Maybe this can be implemented in a largely CPU independent way? Try to
make it data-driven, so you can then for example just provide a
CPU-specific data sructure (array of names / addresses or whatever you
are checking).
 
> Do you want the default weak functions to say something like "not 
> implemented",
> or just do nothing at all?

No news is good news.  Make them silent, please.

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 can you only have two doors on a chicken coop? If it had four  it
would be a chicken sedan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] "Un-initialization" of hardware block prior to launching linux

[Steve Sakoman]

Beagle currently enables musb gadget support in u-boot in order to
support console communication over USB.

The musb hardware remains in an active state as linux is launched.
I've had complaints from those working on Linux power management -- it
seems that leaving things active prevents the kernel from entering
full chip retention.

Is there an approved mechanism for shutting down hardware gracefully
prior to launching linux?

The console gadget seems somewhat of a special case since you really
want it to remain active till the very last moment so error messages
can be displayed.

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

Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree

[Timur Tabi]

Wolfgang Denk wrote:
> No, I don't like this.  The parts that are not specific to 85xx should
> be available to all, and CPU specific (and eventually board specific?)
> parts should be possible by calling into respective functions (which
> might, for example, have weak dummy implementations).

Ok, I can do it this way, but 99% of the code will be CPU-specific.  The whole
point behind the function is to compare the device tree numbers with the
physical addresses of the actual devices in hardware.

Do you want the default weak functions to say something like "not implemented",
or just do nothing at all?

-- 
Timur Tabi
Linux kernel developer at Freescale

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

Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree

[Wolfgang Denk]

Dear Timur Tabi,

In message <4ce302a5.8070...@freescale.com> you wrote:
>
> >> Would "fdt verify" be a good place?
> > 
> > Yes, sounds good to me.
> 
> There is one problem -- a lot of the code is 85xx-specific.  I'm not sure how 
> to
> reasonably make this feature available to all fdt-capable architectures.  
> Would
> you be okay with I enclosed it in an #ifdef CONFIG_MPC85xx, like this:

No, I don't like this.  The parts that are not specific to 85xx should
be available to all, and CPU specific (and eventually board specific?)
parts should be possible by calling into respective functions (which
might, for example, have weak dummy implementations).

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
I am pleased to see that we have differences.  May we together become
greater than the sum of both of us.
-- Surak of Vulcan, "The Savage Curtain", stardate 5906.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Scott Wood]

On Tue, 16 Nov 2010 23:02:48 +0100
Wolfgang Denk  wrote:

> Dear Scott Wood,
> 
> In message <20101116155432.585fa...@udp111988uds.am.freescale.net> you wrote:
> >
> > > Can you not provide a plain and simple AUTOMATIC way to get this
> > > result? some plain stupid command line tool? Something that works as
> > > a simple "make XXX" ?  So it can be scripted / automatized / used?
> > 
> > Yes, a simple C tool to take an existing PBL or RCW dump and "espi-ize"
> > it into a PBL dump would be nice.  The user will still need to acquire
> > the existing RCW manually.  This only needs to be done once on a board;
> > it's not part of building a U-Boot image.
> 
> If this only needs to be done once on a board, then why cannot it be
> included in U-Boot with the configuration for this specific board?

We probably should provide some RCWs as a starting point (we do in the
BSP, outside of the U-Boot component) -- but there are more valid RCWs
than there are U-Bboot configurations.

Besides details about how the board is wired up and where you're
booting from, it depends on what sort of riser cards you have in which
slots, what speed your chip is rated for, etc.

The usual case for NOR flash is a user building U-Boot and flashing
it, while leaving the existing RCW in place -- the RCW is not embedded
in the U-Boot image like it is on 83xx.  This is a fortunate accident
of where the reset vector is located, though.  Other boot sources such
as espi are probably not as lucky.  But even then, you should only need
to create a PBL/RCW once, to be included in all subsequent U-Boot
builds.

-Scott

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

Re: [U-Boot] [PATCH] powerpc/85xx: compare actual device addresses with the device tree

[Timur Tabi]

Wolfgang Denk wrote:
> 
>> > If we agree that this is adebug help, then please provide a separate
>> > command to perform this operation. Make this command optional (feel
>> > free to add it to the default list, but it must be possible to disable
>> > it if wanted). Then users who want this feature can add it to their
>> > boot command sequence, and others, who are interested in fast boot
>> > times can omit it.
>>
>> Would "fdt verify" be a good place?
> 
> Yes, sounds good to me.

There is one problem -- a lot of the code is 85xx-specific.  I'm not sure how to
reasonably make this feature available to all fdt-capable architectures.  Would
you be okay with I enclosed it in an #ifdef CONFIG_MPC85xx, like this:

U_BOOT_CMD(
fdt,255,0,  do_fdt,
"flattened device tree utility commands",
"addr[]- Set the fdt location to \n"
#ifdef CONFIG_OF_BOARD_SETUP
"fdt boardsetup  - Do board-specific set up\n"
#endif
"fdt move  - Copy the fdt to  and make 
it active\n"
...
#ifdef CONFIG_MPC85xx
"fdt verify  - Verify the addresses in the 
device tree\n"
#endif
"NOTE: Dereference aliases by omiting the leading '/', "
"e.g. fdt print ethernet0."
);

-- 
Timur Tabi
Linux kernel developer at Freescale

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

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Wolfgang Denk]

Dear Scott Wood,

In message <20101116155432.585fa...@udp111988uds.am.freescale.net> you wrote:
>
> > Can you not provide a plain and simple AUTOMATIC way to get this
> > result? some plain stupid command line tool? Something that works as
> > a simple "make XXX" ?  So it can be scripted / automatized / used?
> 
> Yes, a simple C tool to take an existing PBL or RCW dump and "espi-ize"
> it into a PBL dump would be nice.  The user will still need to acquire
> the existing RCW manually.  This only needs to be done once on a board;
> it's not part of building a U-Boot image.

If this only needs to be done once on a board, then why cannot it be
included in U-Boot with the configuration for this specific board?

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
"Intelligence without character is a dangerous thing."   - G. Steinem
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Scott Wood]

On Tue, 16 Nov 2010 11:34:43 +0100
Wolfgang Denk  wrote:

> Dear Shaohui Xie,
> 
> In message <1289897403-24602-1-git-send-email-b21...@freescale.com> you wrote:
> >
> > +The P4080 is capable of booting from SPI. The bootup process can be 
> > divided into
> > +two stages: the first stage will load RCW and write configuration 
> > registers to
> > +initialize SPI interface, and configure one CPC as 1M SRAM, and loads 
> > U-boot image
> > +to CPC. The second stage will configure all the hardware and boot up to 
> > U-Boot
> > +command line.
> > +
> > +The PBL image contains three parts, the first is RCW, the second is PBI 
> > commands
> > +performs configuration registers write, the third is the 512KB u-boot 
> > image. The
> > +PBL image is produced by tool pbl_image_tool.html.
> 
> Please explain abbreviations. What's PBI? CPC? 

PBI is pre-boot initialization.

CPC is corenet platform cache -- a.k.a. L3 cache.

> What is "pbl_image_tool.html"?  I doubt that a HTML page can be used
> as tool?

The html file contains a javascript-based tool.

> And where can this tool be found?  And why is it not part of the
> U-Boot distribution?

It *may* be bundled with the BSP -- not sure.

It would be really nice if it were made generally available, though I
don't know if there are any plans for that.  Certainly we shouldn't be
referring users towards it if it's not publicly available.

> > +1. Producing RCW
> > +Copy RCW of u-boot dump and paste it to tab "Tools" of the tool and choose
> > +"Boot" and change PBI_SRC to "0b0101 - SPI 24b Addressing", change 
> > BOOT_LOC to
> 
> You really mean one has to go to some web page and manually copy and
> paste information there?
> 
> To build some image?
> 
> May I ask how you do automatic regression testing?

We usually use xxd to turn a hex dump of an RCW into a binary.  You
only need the tool if you want something interactive to make changes to
the RCW.

The problem with providing such a hexdump here is that it would contain
other settings that may not be appropriate for the board's
configuration.  RCWs on p4080 are a lot more complicated than on older
chips; it's no longer practical to embed a near-universal default
RCW in the U-Boot build.

> > +2. Producing ACS File
> 
> What is ACS?

Don't know, I don't even have a reference to that in my copy of the RCW
tool. :-P

> > +   make P4080DS_PBL_BOOT_INDIRECT_config
> > +   make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
> > +   xxd u-boot.bin > u-boot.xxd
> 
> > +3. Producing PBI commands
> > +Switch to tab "PBI" and paste commands below into text field (please note 
> > these
> > +commands are for CPC1 used as SRAM only, change corresponding register 
> > setting
> > +if CPC2 need to be used as SRAM), then choose "ACS File (XXD Object Dump)",
> > +change Offset to "f8", and click "Browse" to select the u-boot.xxd file
> > +produced in step 2, and click "Add PBI Data", after it finished, paste
> > +"09138000 " and "091380c0 " at the end.
> 
> This must be a bad joke.
> 
> Can you not provide a plain and simple AUTOMATIC way to get this
> result? some plain stupid command line tool? Something that works as
> a simple "make XXX" ?  So it can be scripted / automatized / used?

Yes, a simple C tool to take an existing PBL or RCW dump and "espi-ize"
it into a PBL dump would be nice.  The user will still need to acquire
the existing RCW manually.  This only needs to be done once on a board;
it's not part of building a U-Boot image.

-Scott

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

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Andy Fleming]

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

Re: [U-Boot] [PATCH] Fix jornada memory init

[Kristoffer Ericson]

Hi,

Just bumping this since Ive gotten no feedback and its not
applied yet.

Best wishes
Kristoffer

On Sat, Nov 06, 2010 at 02:24:27PM +0100, Kristoffer Ericson wrote:
> * Fix memory initialization. This fixes the problem
>   with kernel oopses during heavy load.
> 
> * Cleanup pinsetup, which for reference is among
>   other things needed for proper flash erasing.
> 
> Signed-off-by: Kristoffer Ericson 
> ---
>  board/jornada/setup.S |   24 
>  1 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/board/jornada/setup.S b/board/jornada/setup.S
> index 885e02f..cdf5f54 100644
> --- a/board/jornada/setup.S
> +++ b/board/jornada/setup.S
> @@ -112,12 +112,13 @@ gafr_set:   .long   0x0860
>  .globl lowlevel_init
>  lowlevel_init:
>  
> - /* set output and direction of pins */
> - ldr r0, PPC_BASE
> - ldr r1, pin_set_out
> - str r1, [r0, #PPSR]
> - ldr r1, pin_set_dir
> - str r1, [r0, #PPDR]
> +
> + /* this is required for flashing */
> + ldr r0, PPC_BASE
> + ldr r1, pin_set_out
> + str r1, [r0, #PPSR]
> + ldr r1, pin_set_dir
> + str r1, [r0, #PPDR]
>  
>   /* Setting up the memory and stuff */
>   /***/
> @@ -190,6 +191,11 @@ lowlevel_init:
>   ldr r3, [r2]
>  .endr
>  
> + ldr r2, [r0, #MDCNFG]
> + orr r2, r2, #0x0003
> + orr r2, r2, #0x0003
> + str r2, [r0, #MDCNFG]
> +
>   ldr r1, msc0
>   str r1, [r0, #MSC0]
>   ldr r1, msc1
> @@ -198,13 +204,7 @@ lowlevel_init:
>   str r1, [r0, #MSC2]
>   ldr r1, smcnfg
>   str r1, [r0, #SMCNFG]
> - ldr r1, mdcnfg
> - str r1, [r0, #MDCNFG]
>   ldr r1, mecr
>   str r1, [r0, #MECR]
>  
> - /* enable SDRAM */
> - orr r1, r1, #0x0001
> - str r1, [r0, #MDCNFG]
> -
>   mov pc, lr
> -- 
> 1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RAM MEMORY] Hardware Replacement.

[Rodolfo Oliveira]

Hi,
I'm upgrading my hardware RAM, but I found a problem.
After replacing the RAM MT48LC32M4A2 by IS42S16800E the following message
appeared:
Memory (date line) error at , wrote , read
89abcdef89abc def!

Does anyone know what problem is this?
I looked at the two memories and ram it are similar.

Thanks,
Rodolfo Romão.

2010/11/16 Mike Frysinger 

> On Tuesday, November 16, 2010 09:58:48 Detlev Zundel wrote:
> > > On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
> > >> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> > >> > I notice that the patch affects the size of the resulting U-Boot
> > >> > images.
> > >> >
> > >> > For example:
> > >> >
> > >> > Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> > >> >
> > >> >textdata bss dec hex filename
> > >> >
> > >> >  358144   35208  303248  696600   aa118 ./u-boot before
> > >> >  361340   35824  303332  700496   ab050 ./u-boot after
> > >> >
> > >> > ---
> > >> >
> > >> >  Delta:   +3896 Bytes
> > >> >
> > >> > For other boards it's only a few hundred bytes, but why do we see
> > >> > such big increase here?
> > >>
> > >> In this case, these libraries contribute 3260 bytes in unused
> > >> definitions:
> > >>
> > >> In each case, a whole object file contains exactly the unused
> > >> definitions, and could be excluded in the respective Makefile.
> > >
> > > or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and
> > > dont worry about it.  which is what we do for the Blackfin port.
> >
> > If you do worry, you can use the "--gc-sections" together with
> > "--print-gc-sections" to actually find out what is unused[1].
>
> the u-boot.map also mentions which input sections are discarded without
> needing --print-gc-sections ...
> -mike
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>


-- 

[]´s



===
Rodolfo R. de O. Neto, Eng. , MBA
Engenheiro de computação
MBA - Governança em TI
E-mail: rodolforo...@gmail.com
===
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] RFC: missing patch review for LL TEMAC driver to u-boot

[Stephan Linz]

Hi Ben,
Hi Michal,

in terms of your last communication:

http://www.mail-archive.com/u-boot@lists.denx.de/msg36959.html

... I want ask about the state of the review. When will the patch be added in 
the mainstream?

As far as I can see there were more than a try to submit the patch:
http://www.mail-archive.com/u-boot@lists.denx.de/msg35518.html
http://www.mail-archive.com/u-boot@lists.denx.de/msg08025.html
http://www.mail-archive.com/u-boot@lists.denx.de/msg06789.html

@Ben: What's wrong?

@Michal: Where can I find the latest commit for cherry-pick?


-- 
Best regards,
Stephan Linz
__
OpenDCC: http://www.li-pro.net/opendcc.phtml
PC/M: http://www.li-pro.net/pcm.phtml
CDK4AVR: http://cdk4avr.sourceforge.net/
CDK4NIOS: http://cdk4nios.sourceforge.net/
CDK4MSP: http://cdk4msp.sourceforge.net/
CPM4L: http://download.opensuse.org/repositories/home:/rexut:/CPM4L
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Stefano Babic]

On 11/16/2010 09:41 AM, Jason Liu wrote:

Hi Jason,

> fix saveenv or env save command not work on mx51evk board.
> with this patch, we can use savenv or env save to
> store enviroments to mmc card slot 0

>  
> -#define CONFIG_ENV_SECT_SIZE(128 * 1024)
> -#define CONFIG_ENV_SIZE  CONFIG_ENV_SECT_SIZE
> -#define CONFIG_ENV_IS_NOWHERE
> +#define CONFIG_ENV_OFFSET  (6 * 64 * 1024)
> +#define CONFIG_ENV_SIZE(2 * 64 * 1024)
> +#define CONFIG_ENV_IS_IN_MMC
> +#define CONFIG_SYS_MMC_ENV_DEV 0

Why do we need 128KB to save the environment in case of MMC ? It seems
to me too much, because we are not constrained to the sector size as for
flash devices.

Can we save some time by saving or reading the environment reducing its
size ? Or do you plan to save something more in this area ?

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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] [PATCH V4][NEXT] Davinci: add support for the ea20 board

[Stefano Babic]

On 11/16/2010 04:44 PM, Ben Gardiner wrote:
> On Tue, Nov 16, 2010 at 5:06 AM, Stefano Babic  wrote:
>> This board uses the OMAP-L138 SOM stacked on a
>> custom baseboard. It supports SPI Flash, Ethernet
>> with RMII.

Hi Ben,

> If this patch is based on the da850evm RMII support as previous
> version indicated then could this function prototype and the
> implementation below be wrapped in #if defined(CONFIG_DRIVER_TI_EMAC)
> and the corresponding declaration and implementations added to
> board/davinci/da8xxevm/common.{h,c} in the RMII patch be removed to
> minimize duplicate code?

Sorry, In my previous e-mail I misunderstood what you meant. You are
right, we have to drop the function from da8xxevm/common.{h,c}, or we
duplicate the code. I will send a patch for that.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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] [PATCH v4] Switch from archive libraries to partial linking

[Mike Frysinger]

On Tuesday, November 16, 2010 09:58:48 Detlev Zundel wrote:
> > On Monday, November 15, 2010 07:13:03 Sebastien Carlier wrote:
> >> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> >> > I notice that the patch affects the size of the resulting U-Boot
> >> > images.
> >> > 
> >> > For example:
> >> > 
> >> > Configuring for MiniFAP - Board: TQM5200, Options: MINIFAP
> >> > 
> >> >textdata bss dec hex filename
> >> >  
> >> >  358144   35208  303248  696600   aa118 ./u-boot before
> >> >  361340   35824  303332  700496   ab050 ./u-boot after
> >> > 
> >> > ---
> >> > 
> >> >  Delta:   +3896 Bytes
> >> > 
> >> > For other boards it's only a few hundred bytes, but why do we see
> >> > such big increase here?
> >> 
> >> In this case, these libraries contribute 3260 bytes in unused
> >> definitions:
> >> 
> >> In each case, a whole object file contains exactly the unused
> >> definitions, and could be excluded in the respective Makefile.
> > 
> > or just use -ffunction-sections/-fdata-sections/-Wl,--gc-sections and
> > dont worry about it.  which is what we do for the Blackfin port.
> 
> If you do worry, you can use the "--gc-sections" together with
> "--print-gc-sections" to actually find out what is unused[1].

the u-boot.map also mentions which input sections are discarded without 
needing --print-gc-sections ...
-mike


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

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Detlev Zundel]

Hi Shaohui Xie,

[...]

> Can you not provide a plain and simple AUTOMATIC way to get this
> result? some plain stupid command line tool? Something that works as
> a simple "make XXX" ?  So it can be scripted / automatized / used?

Maybe have a look at "tools/kwbimage.c".  This is a tool for kirkwood
chips to build "wrapped images".

I'm not into this tool, but it sounds like it tries to solve a similar
problem, so maybe you can leverage what's already there?

Cheers
  Detlev

-- 
PUBLIC NOTICE AS REQUIRED BY LAW:Any Use of  This Product,  in Any Manner
Whatsoever, Will Increase the Amount of Disorder in the Universe. Although No
Liability Is  Implied Herein,  the Consumer Is Warned  That This Process Will
Ultimately Lead to the Heat Death of the Universe.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4][NEXT] Davinci: add support for the ea20 board

[Stefano Babic]

On 11/16/2010 04:44 PM, Ben Gardiner wrote:
> On Tue, Nov 16, 2010 at 5:06 AM, Stefano Babic  wrote:
>> This board uses the OMAP-L138 SOM stacked on a
>> custom baseboard. It supports SPI Flash, Ethernet
>> with RMII.
>>
>> Signed-off-by: Stefano Babic 
>> ---
>> Changes since V2:
>>  - Make clear that the code is taken from da850evm.c
>>   and not da830evm.c (Ben Gardiner)
>>  - factorize function to enable RMII (Ben Gardiner)
> 
> previous versions were based on Sugosh's and my patches. Is that still true?

Yes, it is not changed.

>> +void davinci_emac_mii_mode_sel(int mode_sel);
> I'm sorry I didn't mention this before -- I was just reviewing my
> pending RMII patch and noticed the following:
> 
> If this patch is based on the da850evm RMII support as previous
> version indicated then could this function prototype and the
> implementation below be wrapped in #if defined(CONFIG_DRIVER_TI_EMAC)
> and the corresponding declaration and implementations added to
> board/davinci/da8xxevm/common.{h,c} in the RMII patch be removed to
> minimize duplicate code?

I will protect prototype and implementation, but I prefer to not move
the code in da8xxevm/common.x. The ea20 board has its own directory, and
the place to share code among all davinci boards is under davinci/common
instead of under da8xxevm. And probably it should be better to protect
the function with CONFIG_SOC_DA8XX, too.

> 
> You said you were going to remove this NAND stuff. It sounds like the
> ea20 will support NAND, so I've no qualms about keeping it around;
> just wondering if you forgot to remove it or forgot to mention that
> you weren't going to remove it?

The main reason is that I cannot test at the moment the NAND. I think
the best way to do is that I will provide another patch only when I will
get a new release of the board and I can test the NAND functionalities.
At the moment, this is dead code.

>> diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
>> index e4ae6f3..00d946e 100644
>> --- a/include/configs/da850evm.h
>> +++ b/include/configs/da850evm.h
> 
> I think some da850evm.h changes creeped in by accident.

Yes, I noted too late, email was already sent ;-)

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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] qemu-arm

[Albert ARIBAUD]

Le 16/11/2010 15:49, Peter Maydell a écrit :
> On 16 November 2010 13:54, Albert ARIBAUD  wrote:
>>> Mostly these things
>>> don't cause a problem in practice, which is why they haven't
>>> been corrected yet.
>>
>> Thanks Peter for the clarification. I imagine that "in practice" can bear
>> different meanings depending on the practice -- for software like u-boot,
>> which is very low-level and can encounter issues such as a RAM controller
>> misconfiguration (or plain bad BAR setting, mind) addressing outside
>> physically available space, including writing to RO memory or fetching bad
>> code, is something we can see in practice, at least in the first times of a
>> board's bring up.
>
> Sure, but I imagine that for debugging that sort of thing it doesn't make
> a great deal of difference whether you discover it by getting a cpu
> abort, by having the core just go off into the weeds somewhere or by
> getting a fatal error message from qemu. So that was partly what I
> meant by "in practice" -- yes, it's a deviation from correct behaviour,
> but it's not really any more of an impediment to debugging than
> correctly modelled behaviour would be, once you know what qemu
> is doing wrong...

Understood. What I meant is that "in practice" with a real piece of HW, 
we expect aborts or undefined so much that we actually handle them and 
do a register dump the board's console, so not seeing this dump when 
simulating an abort on the HW would thus somehow 'depart' from 'the 
practice' as I know it. However:

> (Which is not to defend the current qemu behaviour so much as to
> try to explain why this particular bug isn't at the top of my todo list :-))

I do understand why it isn't, and as I said, I can happily live without 
it as long as I know that the simulator differs from the HW in this 
respect -- after all, if I *really* need it, I guess I can delve deep 
into the qemu-arm source code. :)

> -- PMM

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

Re: [U-Boot] [PATCH V4][NEXT] Davinci: add support for the ea20 board

[Ben Gardiner]

On Tue, Nov 16, 2010 at 5:06 AM, Stefano Babic  wrote:
> This board uses the OMAP-L138 SOM stacked on a
> custom baseboard. It supports SPI Flash, Ethernet
> with RMII.
>
> Signed-off-by: Stefano Babic 
> ---
> Changes since V2:
>  - Make clear that the code is taken from da850evm.c
>   and not da830evm.c (Ben Gardiner)
>  - factorize function to enable RMII (Ben Gardiner)

previous versions were based on Sugosh's and my patches. Is that still true?

>
>  MAINTAINERS                                      |    1 +
>  arch/arm/include/asm/arch-davinci/davinci_misc.h |    2 +-
>  board/davinci/common/misc.c                      |   15 ++
>  board/davinci/ea20/Makefile                      |   53 +
>  board/davinci/ea20/ea20.c                        |  230 
> ++
>  boards.cfg                                       |    1 +
>  include/configs/da850evm.h                       |    2 +-
>  include/configs/ea20.h                           |  192 ++
>  8 files changed, 494 insertions(+), 2 deletions(-)
>  create mode 100644 board/davinci/ea20/Makefile
>  create mode 100644 board/davinci/ea20/ea20.c
>  create mode 100644 include/configs/ea20.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9258cb1..386a7b9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -551,6 +551,7 @@ Rowel Atienza 
>
>  Stefano Babic 
>
> +       ea20            davinci
>        polaris         xscale
>        trizepsiv       xscale
>        mx51evk         i.MX51
> diff --git a/arch/arm/include/asm/arch-davinci/davinci_misc.h 
> b/arch/arm/include/asm/arch-davinci/davinci_misc.h
> index a6ac3b9..80b366c 100644
> --- a/arch/arm/include/asm/arch-davinci/davinci_misc.h
> +++ b/arch/arm/include/asm/arch-davinci/davinci_misc.h
> @@ -50,5 +50,5 @@ void davinci_sync_env_enetaddr(uint8_t *rom_enetaddr);
>  int davinci_configure_pin_mux(const struct pinmux_config *pins, int n_pins);
>  int davinci_configure_pin_mux_items(const struct pinmux_resource *item,
>                                    int n_items);
> -
> +void davinci_emac_mii_mode_sel(int mode_sel);
I'm sorry I didn't mention this before -- I was just reviewing my
pending RMII patch and noticed the following:

If this patch is based on the da850evm RMII support as previous
version indicated then could this function prototype and the
implementation below be wrapped in #if defined(CONFIG_DRIVER_TI_EMAC)
and the corresponding declaration and implementations added to
board/davinci/da8xxevm/common.{h,c} in the RMII patch be removed to
minimize duplicate code?

>  #endif /* __MISC_H */
> diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
> index a30047b..d6698c0 100644
> --- a/board/davinci/common/misc.c
> +++ b/board/davinci/common/misc.c
> @@ -170,3 +170,18 @@ int davinci_configure_pin_mux_items(const struct 
> pinmux_resource *item,
>
>        return 0;
>  }
> +
> +/*
> + * Set the mii mode as MII or RMII
> + */
> +void davinci_emac_mii_mode_sel(int mode_sel)
> +{
> +       int val;
> +
> +       val = readl(&davinci_syscfg_regs->cfgchip3);
> +       if (mode_sel == 0)
> +               val &= ~(1 << 8);
> +       else
> +               val |= (1 << 8);
> +       writel(val, &davinci_syscfg_regs->cfgchip3);
> +}

(this one)

> [...]
> diff --git a/board/davinci/ea20/ea20.c b/board/davinci/ea20/ea20.c
> new file mode 100644
> index 000..c1e1be2
> --- /dev/null
> +++ b/board/davinci/ea20/ea20.c
> [...]
> +#ifdef CONFIG_NAND_DAVINCI
> +       /*
> +        * NAND CS setup - cycle counts based on da850evm NAND timings in the
> +        * Linux kernel @ 25MHz EMIFA
> +        */
> +       writel((DAVINCI_ABCR_WSETUP(0) |
> +               DAVINCI_ABCR_WSTROBE(0) |
> +               DAVINCI_ABCR_WHOLD(0) |
> +               DAVINCI_ABCR_RSETUP(0) |
> +               DAVINCI_ABCR_RSTROBE(1) |
> +               DAVINCI_ABCR_RHOLD(0) |
> +               DAVINCI_ABCR_TA(0) |
> +               DAVINCI_ABCR_ASIZE_8BIT),
> +              &davinci_emif_regs->ab2cr); /* CS3 */
> +#endif

You said you were going to remove this NAND stuff. It sounds like the
ea20 will support NAND, so I've no qualms about keeping it around;
just wondering if you forgot to remove it or forgot to mention that
you weren't going to remove it?

> diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h
> index e4ae6f3..00d946e 100644
> --- a/include/configs/da850evm.h
> +++ b/include/configs/da850evm.h

I think some da850evm.h changes creeped in by accident.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support

[Peter Maydell]

On 15 November 2010 15:09, Loïc Minier  wrote:
> On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
>> One last question:
>> >     qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400
>>
>> Does this mean that qemu does not simulate data or instruction
>> aborts? Not that it is required for u-boot, but it *could* be useful
>> sometimes.
>
>  I think the only thing it can do is halt  :-)

qemu does simulate data/insn aborts caused when the MMU is
enabled and you try an access forbidden by the access permissions
set up in the page table. That particular error message happens when
you try to execute from a physical address which isn't RAM or ROM,
so you'll only see it if you have not enabled the MMU or if you get
your page tables wrong. There's no particular reason this couldn't
be made to take a simulated fault instead, I think -- there's an #ifdef
that means qemu for Sparc and MIPS will simulate a fault instead
of aborting. (In theory I think the behaviour shouldn't necessarily
always be to fault, but if there is a non-RAM non-ROM device at
the address to simulate the effect of trying to fetch instructions
from your serial device registers, for example :-))

This is an example of a general tendency in qemu-arm for the
modelling to be a bit weak for situations which will never be
triggered by a correct program/OS but which nonetheless have
well defined failure behaviour. Other examples include execution
of various opcode values which should UNDEF (may trigger qemu
internal error warnings or decode to some other instruction), and
execution of VFP or Neon when the CPACR is set to disable
access to cp10/11 (should fault but won't). Mostly these things
don't cause a problem in practice, which is why they haven't
been corrected yet.

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

[U-Boot] [PATCH] [MPC837x v2] Make it work again with USB.

[Andre Schwarz]

USB register range IMMR+0x00-0xff is reserved and hangs the CPU.

Signed-off-by: Andre Schwarz 
---
 arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c 
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index 7a1cae7..cfead18 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
@@ -327,7 +327,7 @@ void cpu_init_f (volatile immap_t * im)
im->gpio[1].dir = CONFIG_SYS_GPIO2_DIR;
 #endif
 #ifdef CONFIG_USB_EHCI_FSL
-#ifndef CONFIG_MPC834x
+#if !defined(CONFIG_MPC834x) && !defined(CONFIG_MPC837x)
uint32_t temp;
struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
 
-- 
1.7.0.4

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

[U-Boot] [PATCH] [MPC837x] Make it work again with USB. USB register range IMMR+0x00-0xff is reserved and hangs the CPU.

[Andre Schwarz]

Signed-off-by: Andre Schwarz 
---
 arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c 
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index 7a1cae7..cfead18 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
@@ -327,7 +327,7 @@ void cpu_init_f (volatile immap_t * im)
im->gpio[1].dir = CONFIG_SYS_GPIO2_DIR;
 #endif
 #ifdef CONFIG_USB_EHCI_FSL
-#ifndef CONFIG_MPC834x
+#if !defined(CONFIG_MPC834x) && !defined(CONFIG_MPC837x)
uint32_t temp;
struct usb_ehci *ehci = (struct usb_ehci *)CONFIG_SYS_FSL_USB_ADDR;
 
-- 
1.7.0.4

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

Re: [U-Boot] [PATCH] AT91: Add support for NetusG20

[Reinhard Meyer]

Dear Claudio Mignanti,

> Add support for the NetusG20 board by Acmesystems srl.
> This board is based on AT91SAM9G20 SoC.
> 
> Signed-off-by: Claudio Mignanti 

Please run your patch with linux/scripts/checkpatch.pl, you'll
get alot of errors (whitespace and style)...

> ---
>  MAINTAINERS|5 +
>  board/acmesystems/netusg20/Makefile|   55 ++
>  board/acmesystems/netusg20/netusg20.c  |  130 
>  board/acmesystems/netusg20/partition.c |   39 +++
>  boards.cfg |1 +
>  include/configs/netusg20.h |  174 
> 
>  6 files changed, 404 insertions(+), 0 deletions(-)
>  create mode 100644 board/acmesystems/netusg20/Makefile
>  create mode 100644 board/acmesystems/netusg20/netusg20.c
>  create mode 100644 board/acmesystems/netusg20/partition.c
>  create mode 100644 include/configs/netusg20.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ccece74..7ce96b5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -852,6 +852,11 @@ Alex Z
>   lartSA1100
>   dnp1110 SA1110
>  
> +
> +Claudio Mignanti 
> +
> + netusg20ARM926EJS (AT91SAM9G20 SoC)
> +

Please sort that in alphabetically by Surname.

>  -
>  
>  Unknown / orphaned boards:

> diff --git a/board/acmesystems/netusg20/Makefile 
> b/board/acmesystems/netusg20/Makefile
> new file mode 100644
> index 000..09e6695
> --- /dev/null
> +++ b/board/acmesystems/netusg20/Makefile
> @@ -0,0 +1,55 @@
> +#
> +# (C) Copyright 2003-2008
> +# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> +#
> +# (C) Copyright 2008
> +# Stelian Pop 
> +# Lead Tech Design 
> +#
> +# 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  = $(obj)lib$(BOARD).a
> +
> +COBJS-$(CONFIG_NETUSG20) += netusg20.o
> +COBJS-y  += partition.o
> +
> +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(COBJS-y))
> +SOBJS:= $(addprefix $(obj),$(SOBJS))
> +
> +$(LIB):  $(obj).depend $(OBJS) $(SOBJS)
> + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
> +
> +clean:
> + rm -f $(SOBJS) $(OBJS)
> +
> +distclean:   clean
> + rm -f $(LIB) core *.bak $(obj).depend
> +
> +#
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/board/acmesystems/netusg20/netusg20.c 
> b/board/acmesystems/netusg20/netusg20.c
> new file mode 100644
> index 000..6bcb1f7
> --- /dev/null
> +++ b/board/acmesystems/netusg20/netusg20.c
> @@ -0,0 +1,130 @@
> +/*
> + * (C) Copyright 2007-2008
> + * Stelian Pop 
> + * Lead Tech Design 
> + *
> + * (C) Copyright 2010
> + * Reinhard Meyer, EMK Elektronik, reinhard.me...@emk-elektronik.de
> + * Claudio Mignanti 
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +/* - 
> */
> +/*
> + * Miscellaneous platform

Re: [U-Boot] writing board_nand_init for pollux vr3520F

[Miguel Amez]

Hi Scott,

thanks for your answer.
Indeed, I have the datasheet from the manufacturer of the SoC.
There is a project from Jeff Kent that treats about running U-boot an,
ideed, a linux kernel on these chips.
The specifications for this SoC could be consulted here:
http://kthx.ath.cx/trac/nc600/raw-attachment/wiki/Hardware/NC600/POLLUX%20Databook%20Rev0.91.pdf

I'm new to U-boot, so I would like to know if some instructions are
available to know the basics for developing a custom board for pollux. An
initial approach was made by Jeff Kent. It could also be consulted on his
trac here: http://kthx.ath.cx/trac/uboot/

I think that his project is very atractive. I bought 3 pollux thin clients
and see linux working on them would be great! But I think it would need some
work...

Regards,
Miguel Amez

El 15 de noviembre de 2010 20:42, Scott Wood escribió:

> On Sat, 13 Nov 2010 17:33:02 +
> Miguel José Amez Riendas  wrote:
>
> > Hi list,
> >
> > this is my first post on u-boot list.
> > I'm trying to write function "board_nand_init" for a Pollux VR3520F SoC
> > based board.
> > I'm having some troubles and really don't know very good where to start
> and
> > which parts of nand_chip pointer have to be filled and which not.
> > Could you please help me a little bit on this?
>
> Does its NAND controller resemble any of the drivers under
> drivers/mtd/nand?
>
> If so, look at what other boards using that controller are doing.
>
> If not, you'll need to write a controller driver.  What that driver
> looks like depends on how the hardware works -- do you have a simple
> interface to read/write bytes or words, and raise/lower some signals?
> Maybe with an ECC accelerator?  Or does the hardware isolate you more
> from the hardware details, such that you program it to do high level
> operations such as read page, erase block, etc?
>
> -Scott
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] AT91: Add support for NetusG20

[Claudio Mignanti]

Add support for the NetusG20 board by Acmesystems srl.
This board is based on AT91SAM9G20 SoC.

Signed-off-by: Claudio Mignanti 
---
 MAINTAINERS|5 +
 board/acmesystems/netusg20/Makefile|   55 ++
 board/acmesystems/netusg20/netusg20.c  |  130 
 board/acmesystems/netusg20/partition.c |   39 +++
 boards.cfg |1 +
 include/configs/netusg20.h |  174 
 6 files changed, 404 insertions(+), 0 deletions(-)
 create mode 100644 board/acmesystems/netusg20/Makefile
 create mode 100644 board/acmesystems/netusg20/netusg20.c
 create mode 100644 board/acmesystems/netusg20/partition.c
 create mode 100644 include/configs/netusg20.h

diff --git a/MAINTAINERS b/MAINTAINERS
index ccece74..7ce96b5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -852,6 +852,11 @@ Alex Z
lartSA1100
dnp1110 SA1110
 
+
+Claudio Mignanti 
+
+   netusg20ARM926EJS (AT91SAM9G20 SoC)
+
 -
 
 Unknown / orphaned boards:
diff --git a/board/acmesystems/netusg20/Makefile 
b/board/acmesystems/netusg20/Makefile
new file mode 100644
index 000..09e6695
--- /dev/null
+++ b/board/acmesystems/netusg20/Makefile
@@ -0,0 +1,55 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop 
+# Lead Tech Design 
+#
+# 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= $(obj)lib$(BOARD).a
+
+COBJS-$(CONFIG_NETUSG20)   += netusg20.o
+COBJS-y+= partition.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/acmesystems/netusg20/netusg20.c 
b/board/acmesystems/netusg20/netusg20.c
new file mode 100644
index 000..6bcb1f7
--- /dev/null
+++ b/board/acmesystems/netusg20/netusg20.c
@@ -0,0 +1,130 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop 
+ * Lead Tech Design 
+ *
+ * (C) Copyright 2010
+ * Reinhard Meyer, EMK Elektronik, reinhard.me...@emk-elektronik.de
+ * Claudio Mignanti 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* - */
+/*
+ * Miscellaneous platform dependent initialisations
+ */
+#ifdef CONFIG_MACB
+static void netus_macb_init(void)
+{
+   struct at91_pmc *pmc = (struct at91_pmc *)ATMEL_BASE_PMC;
+
+   /* Enable EMAC clock */
+   writel(1 << ATMEL_ID_EMAC0, &pmc->pcer);
+
+   /* Initialize EMAC=MACB hardware */
+   at91_macb_hw_init();
+}
+
+int board_eth_init(bd_t *bis)
+{
+   int rc = 0;
+   rc = macb_eth_initialize(0, (void *)ATMEL_BASE_EMAC0, 0x00);
+   return rc;
+}
+#el

Re: [U-Boot] "boxbe" bullshit

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4ce25dfc.9070...@emk-elektronik.de> you wrote:
>
> > Is there any way to block this ?
> 
> We could only purge such members that use such annoying "services"
> from the u-boot mailing list.

I hesitate to do that, because it's a pretty serious measure, but in
this case I had no other coice.

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
One essential to success is that you desire be an all-obsessing  one,
your thoughts and aims be co-ordinated, and your energy be concentra-
ted and applied without letup.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] "boxbe" bullshit

[Wolfgang Denk]

Dear Andre Schwarz,

In message <4ce25bea.9080...@matrix-vision.de> you wrote:
> 
> since a couple of days I get lots of mails from other U-Boot List 
> subscribers.

The problem is only with one address, actually (vipulsamar87).
And I get the same crap.

> Is there any way to block this ?

I tried to contact him, but got just another of these messages.

I had no other choice and unsubscribed him last night. The problem
should be gone now (except for some backlog in the mail server
queues).

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
Too many people are ready to carry the stool when the piano needs  to
be moved.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Wolfgang Denk]

Dear Shaohui Xie,

In message <1289897403-24602-1-git-send-email-b21...@freescale.com> you wrote:
>
> +The P4080 is capable of booting from SPI. The bootup process can be divided 
> into
> +two stages: the first stage will load RCW and write configuration registers 
> to
> +initialize SPI interface, and configure one CPC as 1M SRAM, and loads U-boot 
> image
> +to CPC. The second stage will configure all the hardware and boot up to 
> U-Boot
> +command line.
> +
> +The PBL image contains three parts, the first is RCW, the second is PBI 
> commands
> +performs configuration registers write, the third is the 512KB u-boot image. 
> The
> +PBL image is produced by tool pbl_image_tool.html.

Please explain abbreviations. What's PBI? CPC? 

What is "pbl_image_tool.html"?  I doubt that a HTML page can be used
as tool?

And where can this tool be found?  And why is it not part of the
U-Boot distribution?

> +1. Producing RCW
> +Copy RCW of u-boot dump and paste it to tab "Tools" of the tool and choose
> +"Boot" and change PBI_SRC to "0b0101 - SPI 24b Addressing", change BOOT_LOC 
> to

You really mean one has to go to some web page and manually copy and
paste information there?

To build some image?

May I ask how you do automatic regression testing?

> +2. Producing ACS File

What is ACS?

> + make P4080DS_PBL_BOOT_INDIRECT_config
> + make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
> + xxd u-boot.bin > u-boot.xxd

> +3. Producing PBI commands
> +Switch to tab "PBI" and paste commands below into text field (please note 
> these
> +commands are for CPC1 used as SRAM only, change corresponding register 
> setting
> +if CPC2 need to be used as SRAM), then choose "ACS File (XXD Object Dump)",
> +change Offset to "f8", and click "Browse" to select the u-boot.xxd file
> +produced in step 2, and click "Add PBI Data", after it finished, paste
> +"09138000 " and "091380c0 " at the end.

This must be a bad joke.

Can you not provide a plain and simple AUTOMATIC way to get this
result? some plain stupid command line tool? Something that works as
a simple "make XXX" ?  So it can be scripted / automatized / used?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Never call a man a fool.  Borrow from him.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] "boxbe" bullshit

[Reinhard Meyer]

Andre Schwarz schrieb:
> Wolfgang,
> 
> since a couple of days I get lots of mails from other U-Boot List 
> subscribers.
> 
> Is there any way to block this ?

We could only purge such members that use such annoying "services"
from the u-boot mailing list.

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

[U-Boot] "boxbe" bullshit

[Andre Schwarz]

Wolfgang,

since a couple of days I get lots of mails from other U-Boot List 
subscribers.

Is there any way to block this ?


Regards,
André


Am 16.11.2010 10:51, schrieb nore...@boxbe.com:
>
> Hello Andre Schwarz,
>
> Your message about "Re: [U-Boot] MPC8377: USB breaks board (Action 
> Required)" was waitlisted.
>
> Please add yourself to my Guest List so your messages will be 
> delivered to my Inbox. Use the link below.
>
> Click here to deliver your message 
> 
>
> Thank you,
> vipulsama...@gmail.com
>
> *About this Notice*
> Boxbe (www.boxbe.com ) 
> prioritizes and screens your email using a Guest List and your 
> extended social network. It's free, it removes clutter, and it helps 
> you focus on the people who matter to you.
>
> Boxbe 
> End Email Overload
>
>
> Reporting-MTA: dns; boxbe.com
> Remote-MTA: dns; yahoo.com
> Action: failed
> Arrival-Date: Tue, 16 Nov 2010 01:51:51 -0800 (PST)
>
> Final-Recipient: rfc822; vipulsama...@gmail.com
> Diagnostic-Code: X-Boxbe-Notice; Sender not pre-approved.  Follow 
> instructions in above notice
> Status: 4.7.0
>


MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] omap3 i2c issues

[Murali K. Vemuri]

Hi,
Thanks for the info, but is there any way to detect whats probably going wrong?
any help / pointers are highly appreciated.
Thanks & regards
Murali

On Tue, Nov 16, 2010 at 5:53 PM, Heiko Schocher  wrote:
> Hello Murali,
>
> Murali K. Vemuri wrote:
>> I am using a omap3 based board and U-Boot version 03.00.02.07.
>
> There is no such a version in mainline ...
>
>> when I do "i2c probe", this results in : 38  3C  3D  3F.
>>
>> I found that Kernel TWL is dumping messages to 48  49  4A & 4B.
>>
>> I tried the the same on the "reference board and the corresponding
>> u-boot" supplied from Mistral , when I type "iprobe", I get the
>> output: 48 49 4A 4B.
>
> here on my omap3_beagle board:
>
> U-Boot 2010.09-05496-gbafe743-dirty (Oct 14 2010 - 09:26:57)
>
> OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
> OMAP3 Beagle board + LPDDR/NAND
> I2C:   ready
> DRAM:  256 MiB
> NAND:  256 MiB
> In:    serial
> Out:   serial
> Err:   serial
> Beagle Rev C1/C2/C3
> Die ID #00b304013f8a1700900c
> Hit any key to stop autoboot:  0
> OMAP3 beagleboard.org # i2c probe
> Valid chip addresses: 48 49 4A 4B
> OMAP3 beagleboard.org #
>
> So, I think, i2c driver should be ok.
>
>> I further verified that on my board, if I do "i2c mw 0x3C 0 0x34 0x10"
>> I am able to write into I2C and "i2c md 0x3C 0 0x10" I am able to read
>> back . This however, works only on 0x3c. "mw" & "md" are working on
>> 0x3c only. 38, 3d & 3f are returning error.
>>
>> I could not understand what is missing here? How come my board U-boot
>> is getting a chip id different?
>> is there a setting that I can do? my Hardware engineer says the OMAP3
>> connections are same between our board and evm board.
>
> pinsetup, clock setup?
>
> bye,
> Heiko
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2][v2] PBL: add support for boot from SPI flash.

[Wolfgang Denk]

Dear Shaohui Xie,

In message <1289897285-16845-1-git-send-email-b21...@freescale.com> you wrote:
> PBL: SPI flash used as RCW and PBI source, CPC used as 1M SRAM
> where PBL will copy whole U-BOOT image to, U-boot can boot from CPC
> after PBL completes RCW and PBI phases.

Can you please write plain text?  What does all these TLAs mean?

PBL ?
PBI ?
CPC ?


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
Remember thee Ay, thou poor ghost while memory holds a seat  In  this
distracted  globe.  Remember  thee!  Yea, from the table of my memory
I'll wipe away all trivial fond  records,  All  saws  of  books,  all
forms,  all  pressures past, That youth and observation copied there.
Hamlet, I : v : 95 William Shakespeare
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V4][NEXT] Davinci: add support for the ea20 board

[Stefano Babic]

This board uses the OMAP-L138 SOM stacked on a
custom baseboard. It supports SPI Flash, Ethernet
with RMII.

Signed-off-by: Stefano Babic 
---
Changes since V2:
 - Make clear that the code is taken from da850evm.c
   and not da830evm.c (Ben Gardiner)
 - factorize function to enable RMII (Ben Gardiner)

 MAINTAINERS  |1 +
 arch/arm/include/asm/arch-davinci/davinci_misc.h |2 +-
 board/davinci/common/misc.c  |   15 ++
 board/davinci/ea20/Makefile  |   53 +
 board/davinci/ea20/ea20.c|  230 ++
 boards.cfg   |1 +
 include/configs/da850evm.h   |2 +-
 include/configs/ea20.h   |  192 ++
 8 files changed, 494 insertions(+), 2 deletions(-)
 create mode 100644 board/davinci/ea20/Makefile
 create mode 100644 board/davinci/ea20/ea20.c
 create mode 100644 include/configs/ea20.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 9258cb1..386a7b9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -551,6 +551,7 @@ Rowel Atienza 
 
 Stefano Babic 
 
+   ea20davinci
polaris xscale
trizepsiv   xscale
mx51evk i.MX51
diff --git a/arch/arm/include/asm/arch-davinci/davinci_misc.h 
b/arch/arm/include/asm/arch-davinci/davinci_misc.h
index a6ac3b9..80b366c 100644
--- a/arch/arm/include/asm/arch-davinci/davinci_misc.h
+++ b/arch/arm/include/asm/arch-davinci/davinci_misc.h
@@ -50,5 +50,5 @@ void davinci_sync_env_enetaddr(uint8_t *rom_enetaddr);
 int davinci_configure_pin_mux(const struct pinmux_config *pins, int n_pins);
 int davinci_configure_pin_mux_items(const struct pinmux_resource *item,
int n_items);
-
+void davinci_emac_mii_mode_sel(int mode_sel);
 #endif /* __MISC_H */
diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c
index a30047b..d6698c0 100644
--- a/board/davinci/common/misc.c
+++ b/board/davinci/common/misc.c
@@ -170,3 +170,18 @@ int davinci_configure_pin_mux_items(const struct 
pinmux_resource *item,
 
return 0;
 }
+
+/*
+ * Set the mii mode as MII or RMII
+ */
+void davinci_emac_mii_mode_sel(int mode_sel)
+{
+   int val;
+
+   val = readl(&davinci_syscfg_regs->cfgchip3);
+   if (mode_sel == 0)
+   val &= ~(1 << 8);
+   else
+   val |= (1 << 8);
+   writel(val, &davinci_syscfg_regs->cfgchip3);
+}
diff --git a/board/davinci/ea20/Makefile b/board/davinci/ea20/Makefile
new file mode 100644
index 000..ddd2564
--- /dev/null
+++ b/board/davinci/ea20/Makefile
@@ -0,0 +1,53 @@
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# Copyright (C) 2007 Sergey Kubushyn 
+#
+# 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= $(obj)lib$(BOARD).a
+
+COBJS-y+= ea20.o
+
+COBJS   := $(COBJS-y)
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak *~ .depend
+
+#
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/davinci/ea20/ea20.c b/board/davinci/ea20/ea20.c
new file mode 100644
index 000..c1e1be2
--- /dev/null
+++ b/board/davinci/ea20/ea20.c
@@ -0,0 +1,230 @@
+/*
+ * (C) Copyright 2010
+ * Stefano Babic, DENX Software Engineering, sba...@denx.de
+ *
+ * Based on da850evm.c, original Copyrights follow:
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Based on da830evm.c. Original Copyrights follow:
+ *
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc, Ltd. 
+ * Copyright (C) 2007 Sergey Kubushyn 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public Lice

Re: [U-Boot] [PATCH v2 1/1] imx: Get fec mac address from fuse

[Wolfgang Denk]

Dear Jason Liu,

In message  you 
wrote:
>
...
> This is defined according to the IC spec and it should be hw layout.
> We can read such kind of fuse just like read register.  But currently, uboot
> require that all the register array should be included into one
> structure and not
> use the *(offset + base_addr) method, this is also stefano suggestion. But for
> fuse support, there are many fuses but we only use FEC_MAC fuse
> currently, this is why
> I ask how to handle it better in uboot.

I still suggest to have an unstructured entry iim_bank_area0[] in
iim_regs; actually this allows to collapse the 4 areas into an array
of 4 identical ones.

Then provide a separate struct description which declares the usage on
iim_bank_area0.


Um... and can you please stop top-posting / full-quoting? Try and read
http://www.netmeister.org/news/learn2quote.html

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 software required `Windows 95 or better', so I installed Linux.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] imx: Get fec mac address from fuse

[Stefano Babic]

On 11/16/2010 08:16 AM, Jason Liu wrote:
>>> struct iim_regs {
>>> u32 stat;
>>> u32 statm;
>>> u32 err;
>>> u32 emask;
>>> u32 fctl;
>>> u32 ua;
>>> u32 la;
>>> u32 sdat;
>>> u32 prev;
>>> u32 srev;
>>> u32 preg_p;
>>> u32 scs0;
>>> u32 scs1;
>>> u32 scs2;
>>> u32 scs3;
>>> u32 res0[0x1f1];
>>> u32 iim_bank_area0_1[9];
>>> u32 mac_addr[6];
>>> u32 iim_bank_area0_2[0x11];
>>> u32 res1[0xe0];
>>> u32 iim_bank_area1[0x20];
>>> u32 res2[0xe0];
>>> u32 iim_bank_area2[0x20];
>>> u32 res3[0xe0];
>>> u32 iim_bank_area3[0x20];
>>> u32 res4[0xe0];
>>> };
>>
>> This struct is supposed to describe some register layout defined by
>> the hardware - but does the hardware know anything about teh special
>> meaning "MAC address" of this specific field, or is this an
>> interpretation that we just define as we like?

The MAC address is stored at a specific address, that is different in
each i.MX implementation. There are a lot of fields the hardware is
aware of.

> 
> This is defined according to the IC spec and it should be hw layout.
> We can read such kind of fuse just like read register.  But currently, uboot
> require that all the register array should be included into one
> structure and not
> use the *(offset + base_addr) method, this is also stefano suggestion. But for
> fuse support, there are many fuses but we only use FEC_MAC fuse
> currently, this is why
> I ask how to handle it better in uboot.
> 
> Stefano, what's your comments?

I would like to propose a structure to better clarify the internal
layout. Let me explain and check if this can be suitable for you. We
could use a union to define the different layouts for the fuse banks,
such as (the example is for the i.MX51):

typedef union fuse_bank {
struct {
u32 fuse_lock;
u32 osc_jtag;
u32 reserved0;
u32 bt
.
u32 mac_addr[6];

u32 reserved_filled[..]; /* to fill the 0x80-0xFF*/
};
/* Now the layout for the other fuse banks */
struct {

};
/*
 * If we do not want to set now the layout, we can distinguish
 * only between real register and reserved addresses
 * as you already did
 */
 struct {
u32 fuse_regs[0x20];
u32 reserved[0xe0];
}
}

And in your structure you can have something like this:


u32 scs3;
u32 res0[0x1f1];
fuse_bank fuses[4];
}

You do not need to set the layout for the fuse banks 1-3, if you do not
want, but the structure is prepared if someone else will add functions
to manage the fuses.

What do you think about it ?

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Shaohui Xie]

Signed-off-by: Shaohui Xie 
---
 doc/README.espi-boot-p4080ds |   85 ++
 1 files changed, 85 insertions(+), 0 deletions(-)
 create mode 100644 doc/README.espi-boot-p4080ds

diff --git a/doc/README.espi-boot-p4080ds b/doc/README.espi-boot-p4080ds
new file mode 100644
index 000..79ef459
--- /dev/null
+++ b/doc/README.espi-boot-p4080ds
@@ -0,0 +1,85 @@
+Overview:
+=
+The P4080 integrates a pre-boot-loader(PBL) which performs configuration
+registers read and write to initialize external memory devices such as I2c,
+eLBC FCM(NAND flash), eSDHC, or SPI interface, loads RCW and/or pre-boot
+initialization commands from those devices before the local cores are permitted
+to boot.
+
+Boot from SPI:
+==
+
+The P4080 is capable of booting from SPI. The bootup process can be divided 
into
+two stages: the first stage will load RCW and write configuration registers to
+initialize SPI interface, and configure one CPC as 1M SRAM, and loads U-boot 
image
+to CPC. The second stage will configure all the hardware and boot up to U-Boot
+command line.
+
+The PBL image contains three parts, the first is RCW, the second is PBI 
commands
+performs configuration registers write, the third is the 512KB u-boot image. 
The
+PBL image is produced by tool pbl_image_tool.html.
+
+Build and boot steps
+
+
+1. Producing RCW
+Copy RCW of u-boot dump and paste it to tab "Tools" of the tool and choose
+"RCW[0:511] U-Boot CCSR Dump" and then click button "Decode PBL", switch to tab
+"Boot" and change PBI_SRC to "0b0101 - SPI 24b Addressing", change BOOT_LOC to
+"0b1 - Memory Complex 1"(if CPC2 is used as SRAM, this should be set as
+"0b10001 - Memory Complex 2").
+
+2. Producing ACS File
+   make P4080DS_PBL_BOOT_INDIRECT_config
+   make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
+   xxd u-boot.bin > u-boot.xxd
+
+3. Producing PBI commands
+Switch to tab "PBI" and paste commands below into text field (please note these
+commands are for CPC1 used as SRAM only, change corresponding register setting
+if CPC2 need to be used as SRAM), then choose "ACS File (XXD Object Dump)",
+change Offset to "f8", and click "Browse" to select the u-boot.xxd file
+produced in step 2, and click "Add PBI Data", after it finished, paste
+"09138000 " and "091380c0 " at the end.
+
+Below are Commands pasted before click "Add PBI Data".
+
+   PBI DATA  | Description
+   -
+   |  0901 00200400  | CPCFI & |
+   |  09138000   | CPCLFC for CPC1 |
+   |  091380c0 0100  | |
+   -
+   |  09010100   | Configure   |
+   |  09010104 fffb  | CPC1 as |
+   |  09010f00 0800  | 1M SRAM |
+   |  0901 8000  | |
+   -
+   |  09000d00   | Configure   |
+   |  09000d04 fff0  | LAW for CPC1|
+   |  09000d08 8113  | |
+   -
+   |  0910   | Configure   |
+   |  0914 ff00  | Alternate   |
+   |  0918 8100  | for CPC1|
+   -
+   |  0911 8403  | Initialize  |
+   |  09110020 2d170008  | SPI interface   |
+   |  09110024 0018  | |
+   |  09110028 0018  | |
+   |  0911002c 0018  | |
+   -
+   |  09138000   | Flush command   |
+   |  091380c0   | |
+   -
+
+4. Producing PBL image
+   1. Switch to tab "Tools" and click "Encode PBL", after it finished copy
+the encoded content to file and save as x.xxd.
+   2. xxd -r x.xxd > pbl_u-boot.bin
+
+5. Put image to SPI flash
+   Put the pbl_u-boot.bin to SPI flash from offset 0.
+
+6. Change dip-switch
+   Change SW1[2] = off, then power on.
-- 
1.6.4


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

[U-Boot] [PATCH 1/2][v2] PBL: add support for boot from SPI flash.

[Shaohui Xie]

PBL: SPI flash used as RCW and PBI source, CPC used as 1M SRAM
where PBL will copy whole U-BOOT image to, U-boot can boot from CPC
after PBL completes RCW and PBI phases.

Signed-off-by: Chunhe Lan 
Signed-off-by: Mingkai Hu 
Signed-off-by: Shaohui Xie 
---
 arch/powerpc/cpu/mpc85xx/cpu_init.c  |   17 +
 board/freescale/corenet_ds/config.mk |6 ++
 board/freescale/corenet_ds/tlb.c |9 +
 boards.cfg   |1 +
 include/configs/corenet_ds.h |   31 +--
 5 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c 
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 27236a0..cff7ac3 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -139,6 +139,20 @@ static void enable_cpc(void)
for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
u32 cpccfg0 = in_be32(&cpc->cpccfg0);
size += CPC_CFG0_SZ_K(cpccfg0);
+   if (in_be32(&cpc->cpcsrcr0) & CPC_SRCR0_SRAMEN) {
+   /* find and disable LAW of SRAM */
+   struct law_entry law = 
find_law(CONFIG_SYS_INIT_L3_ADDR);
+
+   if (law.index == -1) {
+   printf("\nFatal error happened\n");
+   return;
+   } else
+   disable_law(law.index);
+
+   clrbits_be32(&cpc->cpchdbcr0, CPC_HDBCR0_CDQ_SPEC_DIS);
+   out_be32(&cpc->cpccsr0, 0);
+   out_be32(&cpc->cpcsrcr0, 0);
+   }
 
out_be32(&cpc->cpccsr0, CPC_CSR0_CE | CPC_CSR0_PE);
/* Read back to sync write */
@@ -155,6 +169,9 @@ void invalidate_cpc(void)
cpc_corenet_t *cpc = (cpc_corenet_t *)CONFIG_SYS_FSL_CPC_ADDR;
 
for (i = 0; i < CONFIG_SYS_NUM_CPC; i++, cpc++) {
+   /* skip CPC when it used as all SRAM */
+   if (in_be32(&cpc->cpcsrcr0) & CPC_SRCR0_SRAMEN)
+   continue;
/* Flash invalidate the CPC and clear all the locks */
out_be32(&cpc->cpccsr0, CPC_CSR0_FI | CPC_CSR0_LFC);
while (in_be32(&cpc->cpccsr0) & (CPC_CSR0_FI | CPC_CSR0_LFC))
diff --git a/board/freescale/corenet_ds/config.mk 
b/board/freescale/corenet_ds/config.mk
index 15bbf20..31b3379 100644
--- a/board/freescale/corenet_ds/config.mk
+++ b/board/freescale/corenet_ds/config.mk
@@ -24,4 +24,10 @@
 # P4080DS board
 #
 
+ifeq ($(CONFIG_PBL_BOOT_INDIRECT), y)
+RESET_VECTOR_ADDRESS = 0xfffc
+endif
+
+ifndef RESET_VECTOR_ADDRESS
 RESET_VECTOR_ADDRESS = 0xeffc
+endif
diff --git a/board/freescale/corenet_ds/tlb.c b/board/freescale/corenet_ds/tlb.c
index 1ae0416..08f91a7 100644
--- a/board/freescale/corenet_ds/tlb.c
+++ b/board/freescale/corenet_ds/tlb.c
@@ -51,9 +51,18 @@ struct fsl_e_tlb_entry tlb_table[] = {
 
/* TLB 1 */
/* *I*** - Covers boot page */
+#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L3_ADDR)
+   /* *I*G - L3SRAM. When L3 is used as 1M SRAM, the address of the
+* SRAM is at 0xfff0, it covered the 0xf000.
+* */
+   SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
+   MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+   0, 0, BOOKE_PAGESZ_1M, 1),
+#else
SET_TLB_ENTRY(1, 0xf000, 0xf000,
  MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
  0, 0, BOOKE_PAGESZ_4K, 1),
+#endif
 
/* *I*G* - CCSRBAR */
SET_TLB_ENTRY(1, CONFIG_SYS_CCSRBAR, CONFIG_SYS_CCSRBAR_PHYS,
diff --git a/boards.cfg b/boards.cfg
index 6c2a667..168d6f5 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -195,6 +195,7 @@ P1022DS powerpc mpc85xx p1022ds 
freescale
 P2020DSpowerpc mpc85xx p2020ds freescale
 stxgp3 powerpc mpc85xx stxgp3  stx
 P4080DSpowerpc mpc85xx corenet_ds  freescale
+P4080DS_PBL_BOOT_INDIRECT  powerpc mpc85xx corenet_ds  
freescale   -   P4080DS:PBL_BOOT_INDIRECT,SYS_TEXT_BASE=0xFFF8
 sbc8540powerpc mpc85xx sbc8560 -   
-   SBC8540
 sbc8548powerpc mpc85xx sbc8548 -   
-   sbc8548
 sbc8560powerpc mpc85xx sbc8560 -   
-   sbc8560
diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h
index 2ac59e5..0776c3b 100644
--- a/include/configs/corenet_ds.h
+++ b/include/configs/corenet_ds.h
@@ -28,6 +28,11 @@
 
 #include "../board/freescale/common/ics307_clk.h"
 
+#ifdef CONFIG_PBL_BOOT_INDIRECT
+#define CONFIG_RAMBOOT_PBL 1
+#define CONFIG_RAMBOOT_TEXT_BASE0xfff8
+#endif
+
 /* High Level Configuration Options */
 #def

[U-Boot] AT91: working port for Atmels AT91SAM9XE-EK (should be good for )G20 and 9260, too)

[Reinhard Meyer]

In line with the at91/avr32 rework efforts, I have made the board
AT91SAM9XE-EK build and work again.

Note however that I could not test all functions of the board thoroughly.
MMC with the generic driver is working, note that dataflash and mmc are
mutually exclusive on those evaluation boards.

If you want to try the build, you can find it at top of the rework tree
in u-boot-atmel.git, at91avr32rework-5 branch.

Note also that you need the initial bootstrap loader recompiled to load
the image to 0x2000, OR (not recommended) change the
CONFIG_SYS_TEXTBASE back to 0x23f0 which is 1 Meg. below end of SDRAM
and therefore a bit close to the relocated u-boot image.

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

[U-Boot] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Jason Liu]

fix saveenv or env save command not work on mx51evk board.
with this patch, we can use savenv or env save to
store enviroments to mmc card slot 0

Signed-off-by: Jason Liu 
---
 include/configs/mx51evk.h |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index f98438d..4af492c 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -216,8 +216,9 @@
  */
 #define CONFIG_SYS_NO_FLASH
 
-#define CONFIG_ENV_SECT_SIZE(128 * 1024)
-#define CONFIG_ENV_SIZECONFIG_ENV_SECT_SIZE
-#define CONFIG_ENV_IS_NOWHERE
+#define CONFIG_ENV_OFFSET  (6 * 64 * 1024)
+#define CONFIG_ENV_SIZE(2 * 64 * 1024)
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_SYS_MMC_ENV_DEV 0
 
 #endif
-- 
1.7.0.4


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

Re: [U-Boot] [PATCH V3][NEXT] Davinci: add support for the ea20 board

[Stefano Babic]

On 11/15/2010 04:32 PM, Ben Gardiner wrote:

>> --- /dev/null
>> +++ b/board/davinci/ea20/ea20.c
>> @@ -0,0 +1,237 @@
>> +/*
>> + * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * Based on da830evm.c. Original Copyrights follow:
> 
> It seems to me that this file is based off of da850evm.c;

Correct.

> the
> da850ev.c file contains this comment which is where it likely came
> from. If it is based on da850evm.c then I think the file's comment
> should reflect this.

This is part of the original copyright in the da850evm.c, and this is
the reason why I have not changed it. Probably to be more correct I
should add at the beginning another comment, inidicating where the file
comes from.

> 
>> [...]
>> +
>> +static void da850_emac_mii_mode_sel(int mode_sel)
>> +{
>> +   int val;
>> +
>> +   val = readl(&davinci_syscfg_regs->cfgchip3);
>> +   if (mode_sel == 0)
>> +   val &= ~(1 << 8);
>> +   else
>> +   val |= (1 << 8);
>> +   writel(val, &davinci_syscfg_regs->cfgchip3);
>> +}
> 
> This is a function common to any da850 board using RMII, could it be
> extracted to a shared .c file?

Agree, the function is a good candidate to be moved into misc.c :-).

> 
>> [...]
>> +#ifdef CONFIG_NAND_DAVINCI
>> +   /*
>> +* NAND CS setup - cycle counts based on da850evm NAND timings in the
>> +* Linux kernel @ 25MHz EMIFA
>> +*/
>> +   writel((DAVINCI_ABCR_WSETUP(0) |
>> +   DAVINCI_ABCR_WSTROBE(0) |
>> +   DAVINCI_ABCR_WHOLD(0) |
>> +   DAVINCI_ABCR_RSETUP(0) |
>> +   DAVINCI_ABCR_RSTROBE(1) |
>> +   DAVINCI_ABCR_RHOLD(0) |
>> +   DAVINCI_ABCR_TA(0) |
>> +   DAVINCI_ABCR_ASIZE_8BIT),
>> +  &davinci_emif_regs->ab2cr); /* CS3 */
>> +#endif
> 
> This looks like it was copied from da850evm.c; note that these timings
> are based on the integer multiples of EMA_CLK periods that meet the
> timing specifications of the NAND chip found on the UI board. A
> different part could have different timings...

The ea20 board will support NAND, but not at the moment. There will be a
future release with storage on board, I will drop these NAND definitions
because they do not reflect the actual hardware.

> 
> Also, from your description of the ea20: "It supports SPI Flash,
> Ethernet with RMII." -- there is no NAND support.

No NAND support - defines are useless now ;-)

> Perhaps it would be prudent to _enable_ the MDC line via the GPIO2[6]
> pin instead of a no-op.

It should be not necessary. U-Boot is stored on the SPI flash, and if
the SPI is not enabled at reset by the HW, the board cannot boot. It
seems to me it is already ensured that the buffer output is enabled and
the code does not need to set it.

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-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] omap3 i2c issues

[Heiko Schocher]

Hello Murali,

Murali K. Vemuri wrote:
> I am using a omap3 based board and U-Boot version 03.00.02.07.

There is no such a version in mainline ...

> when I do "i2c probe", this results in : 38  3C  3D  3F.
> 
> I found that Kernel TWL is dumping messages to 48  49  4A & 4B.
> 
> I tried the the same on the "reference board and the corresponding
> u-boot" supplied from Mistral , when I type "iprobe", I get the
> output: 48 49 4A 4B.

here on my omap3_beagle board:

U-Boot 2010.09-05496-gbafe743-dirty (Oct 14 2010 - 09:26:57)

OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
OMAP3 Beagle board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
In:serial
Out:   serial
Err:   serial
Beagle Rev C1/C2/C3
Die ID #00b304013f8a1700900c
Hit any key to stop autoboot:  0
OMAP3 beagleboard.org # i2c probe
Valid chip addresses: 48 49 4A 4B
OMAP3 beagleboard.org #

So, I think, i2c driver should be ok.

> I further verified that on my board, if I do "i2c mw 0x3C 0 0x34 0x10"
> I am able to write into I2C and "i2c md 0x3C 0 0x10" I am able to read
> back . This however, works only on 0x3c. "mw" & "md" are working on
> 0x3c only. 38, 3d & 3f are returning error.
> 
> I could not understand what is missing here? How come my board U-boot
> is getting a chip id different?
> is there a setting that I can do? my Hardware engineer says the OMAP3
> connections are same between our board and evm board.

pinsetup, clock setup?

bye,
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] omap3 i2c issues

[Murali K. Vemuri]

Hi There,

I am using a omap3 based board and U-Boot version 03.00.02.07.
when I do "i2c probe", this results in : 38  3C  3D  3F.

I found that Kernel TWL is dumping messages to 48  49  4A & 4B.

I tried the the same on the "reference board and the corresponding
u-boot" supplied from Mistral , when I type "iprobe", I get the
output: 48 49 4A 4B.

I further verified that on my board, if I do "i2c mw 0x3C 0 0x34 0x10"
I am able to write into I2C and "i2c md 0x3C 0 0x10" I am able to read
back . This however, works only on 0x3c. "mw" & "md" are working on
0x3c only. 38, 3d & 3f are returning error.

I could not understand what is missing here? How come my board U-boot
is getting a chip id different?
is there a setting that I can do? my Hardware engineer says the OMAP3
connections are same between our board and evm board.

ideally my question boils down to: how can I get the device ids
correctly (or is it possible to change them)?

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

[U-Boot] [PATCH] AT91: gen_atmel_mci.c: fix bug when Slot B is used

[Reinhard Meyer]

Signed-off-by: Reinhard Meyer 
---
 drivers/mmc/gen_atmel_mci.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index 5463250..c28c469 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -308,6 +308,7 @@ static int mci_init(struct mmc *mmc)
writel(MMCI_BIT(SWRST), &mci->cr);  /* soft reset */
writel(MMCI_BIT(PWSDIS), &mci->cr); /* disable power save */
writel(MMCI_BIT(MCIEN), &mci->cr);  /* enable mci */
+   writel(MMCI_BF(SCDSEL, MCI_BUS), &mci->sdcr);   /* select port */
 
/* Initial Time-outs */
writel(0x5f, &mci->dtor);
-- 
1.5.6.5

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