[U-Boot-Users] Question about CONFIG_MPC83XX

[U-Boot-Users] Question about CONFIG_MPC83XX

[Bruce_Leonard at selinc.com]

I'm working on porting u-boot to my custom HW (using MPC8347E) and I'm 
curious about the CONFIG_MPC83XX flag.  I started with a copy of the 
MPC8349ITX.h file for my config and it defines CONFIG_MPC834X and 
CONFIG_MPC8349.  But there's a field called bi_immrbar in the bd_info 
struct (.../include/asm-ppc/u-boot.h) surrounded by a check for 
CONFIG_MPC83XX.  Now it seems to me that this field should be applicable 
to the 834x processors as well.  So my questions is two fold: 1) why 
doesn't the MPC8349ITX board define CONFIG_MPC83XX to pick it up, and 2) 
should I be doing so for an MPC8347E processor?

Thanks.

Bruce

[U-Boot-Users] Question about CONFIG_MPC83XX

[Kim Phillips]

On Wed, 8 Aug 2007 17:06:32 -0500
Kim Phillips <kim.phillips@freescale.com> wrote:

> On Tue, 7 Aug 2007 15:06:38 -0700
> Bruce_Leonard at selinc.com wrote:
> 
> > I'm working on porting u-boot to my custom HW (using MPC8347E) and I'm 
> > curious about the CONFIG_MPC83XX flag.  I started with a copy of the 
> > MPC8349ITX.h file for my config and it defines CONFIG_MPC834X and 
> > CONFIG_MPC8349.  But there's a field called bi_immrbar in the bd_info 
> > struct (.../include/asm-ppc/u-boot.h) surrounded by a check for 
> > CONFIG_MPC83XX.  Now it seems to me that this field should be applicable 
> > to the 834x processors as well.  So my questions is two fold: 1) why 
> > doesn't the MPC8349ITX board define CONFIG_MPC83XX to pick it up, and 2) 

it should, but Linux works without it because the ITX only went into
ARCH=powerpc kernels which get the immr from device tree.

> > should I be doing so for an MPC8347E processor?

in general, yes.

Kim

[U-Boot-Users] Question about CONFIG_MPC83XX

[Bruce_Leonard at selinc.com]

> > > to the 834x processors as well.  So my questions is two fold: 1) why 

> > > doesn't the MPC8349ITX board define CONFIG_MPC83XX to pick it up, 
and 2) 
> 
> it should, but Linux works without it because the ITX only went into
> ARCH=powerpc kernels which get the immr from device tree.

That makes sense then.  Thanks.  I have discovered that somehow (still 
working on the how :)  ), there's a -DCONFIG_MPC83XX on the command line 
to gcc.  So in reality it was being defined, just not in my board config 
file.

> 
> > > should I be doing so for an MPC8347E processor?
> 

I thought so, thanks again for the feedback.

Bruce

[U-Boot-Users] Question about CONFIG_MPC83XX

[Wolfgang Denk]

In message <OFB773F931.B8C2422F-ON88257333.005DEAC6-88257333.005E6157@selinc.com> you wrote:
>
> That makes sense then.  Thanks.  I have discovered that somehow (still 
> working on the how :)  ), there's a -DCONFIG_MPC83XX on the command line 
> to gcc.  So in reality it was being defined, just not in my board config 
> file.

Hint - try:

	$ cat cpu/mpc83xx/config.mk


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: wd at denx.de
In an organization, each person rises to the level of his own  incom-
petency                                         - The Peter Principle

[U-Boot-Users] [OT] 10/100/1000 TSEC LED meanings

[David Hawkins]

Hi all,

Sorry for the off-topic post, but since everyone
here has probably had to deal with this question at
some point, and complain if the hardware guy didn't
even think about it, I figured someone would have
some insightful comments.

I'm building an MPC8349EA PowerQUICC II Pro board,
and I'm using the Marvell 88E1111 gigabit PHY, and
I'm now looking into the ethernet connector with
integrated magnetics and LEDs.

I can get parts with bicolor GREEN/YELLOW on the
left and right hand sides, and any combination of
single colors.

Which leads me to ask - what should I choose!?

Lets see, it would be useful to know whether the
link speed is 10/100/1000, so a bicolor LED for
off/green/yellow would cover that. Then how about
the other one, perhaps blinking for gree RX,
yellow for TX?

Is there even a standard for this?

What do people find is the most useful combination
of LED colors and blinking?

NOTE:
The Freescale MPC8349E/EA-MDS-PB boards use a single
green and single yellow to indicate the link speed.
I think thats kind of boring :(

Cheers,
Dave

[U-Boot-Users] [OT] 10/100/1000 TSEC LED meanings

[Rune Torgersen]

>-----Original Message-----
>From: David Hawkins
>Sent: Sat 8/11/2007 8:02 PM
>Which leads me to ask - what should I choose!?
>
>Lets see, it would be useful to know whether the
>link speed is 10/100/1000, so a bicolor LED for
>off/green/yellow would cover that. Then how about
>the other one, perhaps blinking for gree RX,
>yellow for TX?
>
>Is there even a standard for this?
>
>What do people find is the most useful combination
>of LED colors and blinking?

We use green for 1000, yellow for 100 and off for 10, and only green for combined rx/tx/activity, as it is kinda hard to do yellow/green at the same time with a two-pin bipolar LED.
(This driven from a 88E1145 quad phy)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070811/1abe5d67/attachment.htm 

[U-Boot-Users] [OT] 10/100/1000 TSEC LED meanings

[David Hawkins]

Hi Rune,

>  >What do people find is the most useful combination
>  >of LED colors and blinking?
> 
> We use green for 1000, yellow for 100 and off for 10, and only green for 
> combined rx/tx/activity, as it is kinda hard to do yellow/green at the 
> same time with a two-pin bipolar LED.
> (This driven from a 88E1145 quad phy)
> 

Ok, I'll go this route too.

  * bi-color for 10/100/1000 (off/yellow/green)
  * green driven by the logical 'and' of LED_TX and LED_RX
    to indicate activity

Thanks!
Dave

[U-Boot-Users] USART on at91rm9200

[Leonid]

Hi all: 

Does somebody have working u-boot code for USART on any at91 Atmel board
(best of all at91rm9200-ek/dk)? The code in serial.c of standard u-boot
tree doesn't work for me...

Thanks,

Leonid.

[U-Boot-Users] USART on at91rm9200

[Matt Gessner]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-
> bounces at lists.sourceforge.net] On Behalf Of Leonid
> Sent: Sunday, August 12, 2007 12:41 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] USART on at91rm9200
> 
> Hi all:
> 
> Does somebody have working u-boot code for USART on any at91 Atmel
board
> (best of all at91rm9200-ek/dk)? The code in serial.c of standard
u-boot
> tree doesn't work for me...

You don't mention what build you're using.

With respect to the standard tree, I'm using 1.2.0 patched from Ulf at
Atmel, and it all works wonderfully (although I don't use USARTs in
u-boot for this project).  Check the archives of this mailing list for
Ulf's announcements.  

Regards,

Matt Gessner

[U-Boot-Users] USART on at91rm9200

[Leonid]

Hi, Matt:

I am using the same source code I guess and everything BUT USARTs works
for me just fine (thanks Ulf). I have searched desperately through mail
archives for any known USART problems but with no avail. It would help
me tremendously if you could test USART on your board (if you have
physical connector it must be simple) just as usual RS232 and tell me
whether it works. It can be useful for yourself if you ever consider
using USARTs. And could you please send me your
u-boot/cpu/arm920t/at91rm9200/serial.c file just in case?

BTW, what USARTs (if any) are available on your board? At91rm9200-ek
evaluation kit has USART1 connected to DB9 port.

Thanks a lot,

Leonid. 

-----Original Message-----
From: Matt Gessner [mailto:mgessner at Avidyne.com] 
Sent: Monday, August 13, 2007 7:26 AM
To: Leonid; u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] USART on at91rm9200

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-

> bounces at lists.sourceforge.net] On Behalf Of Leonid
> Sent: Sunday, August 12, 2007 12:41 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] USART on at91rm9200
> 
> Hi all:
> 
> Does somebody have working u-boot code for USART on any at91 Atmel
board
> (best of all at91rm9200-ek/dk)? The code in serial.c of standard
u-boot
> tree doesn't work for me...

You don't mention what build you're using.

With respect to the standard tree, I'm using 1.2.0 patched from Ulf at
Atmel, and it all works wonderfully (although I don't use USARTs in
u-boot for this project).  Check the archives of this mailing list for
Ulf's announcements.  

Regards,

Matt Gessner

[U-Boot-Users] USART on at91rm9200

[Matt Gessner]

> -----Original Message-----

> From: Leonid [mailto:Leonid at a-k-a.net]

> Sent: Monday, August 13, 2007 11:39 AM

> To: Matt Gessner; u-boot-users at lists.sourceforge.net

> Subject: RE: [U-Boot-Users] USART on at91rm9200

> 

> Hi, Matt:

> 

> I am using the same source code I guess and everything BUT USARTs
works

> for me just fine (thanks Ulf). I have searched desperately through
mail

> archives for any known USART problems but with no avail. It would help

> me tremendously if you could test USART on your board (if you have

> physical connector it must be simple) just as usual RS232 and tell me

> whether it works. It can be useful for yourself if you ever consider

> using USARTs. And could you please send me your

> u-boot/cpu/arm920t/at91rm9200/serial.c file just in case?

 

Yes, I suppose I could send that file to you.  Give me a little time.

 

Are you certain you configured it properly?  Did you just tell u-boot to
use the USART for your output port?  Did you miss some configuration in
your boot setup (the code loaded into SRAM before you start) that might
be causing a problem?

 

> 

> BTW, what USARTs (if any) are available on your board? At91rm9200-ek

> evaluation kit has USART1 connected to DB9 port.

 

I have all 4 USARTs and the DBGU port wired in.  They all work fine
under linux, but again, not under u-boot; the only port used is the DBGU
port under u-boot.

 

I'm a little curious why you aren't using the DBGU port?

 

Regards,

Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070813/17224fad/attachment.htm 

[U-Boot-Users] USART on at91rm9200

[Leonid]

On Monday, August 13, 2007 8:47 AM Matt Gessner wrote:
To: Leonid; u-boot-users at lists.sourceforge.net
Subject: RE: [U-Boot-Users] USART on at91rm9200

> Are you certain you configured it properly?  Did you just tell u-boot
to use the USART for your output port?  Did you miss some 
> configuration in your boot setup (the code loaded into SRAM before you
start) that might be causing a problem?

This is always a possiblity, but I'm working with u-boot in general and
with this particular CPU for so long, I cannot think of something I have
really missed. All defines are in place, I even can get serial data on
USART output, but TX ready/ RX ready bits of CSR are not working
somehow. 

> > 
> > BTW, what USARTs (if any) are available on your board? At91rm9200-ek
> > evaluation kit has USART1 connected to DB9 port.

> I have all 4 USARTs and the DBGU port wired in.  They all work fine
under linux, but again, not under u-boot; the only port used is 
> the DBGU port under u-boot.

> I'm a little curious why you aren't using the DBGU port?

For my project I need some USART functionality DBGU doesn't have. For
the time being I just wanted to verify USARTs are working at all and
using them as serial ports on u-boot looked for me as a simplest test...
Probably I was wrong... 

Regards,

Leonid.

[U-Boot-Users] USART on at91rm9200

[Matt Gessner]

> -----Original Message-----
> From: Leonid [mailto:Leonid at a-k-a.net]
> Sent: Monday, August 13, 2007 12:26 PM
> To: Matt Gessner; u-boot-users at lists.sourceforge.net
> Subject: RE: [U-Boot-Users] USART on at91rm9200
> 
> On Monday, August 13, 2007 8:47 AM Matt Gessner wrote:
> To: Leonid; u-boot-users at lists.sourceforge.net
> Subject: RE: [U-Boot-Users] USART on at91rm9200
> 
> > Are you certain you configured it properly?  Did you just tell
u-boot
> to use the USART for your output port?  Did you miss some
> > configuration in your boot setup (the code loaded into SRAM before
you
> start) that might be causing a problem?
> 
> This is always a possibility, but I'm working with u-boot in general
and
> with this particular CPU for so long, I cannot think of something I
have
> really missed. All defines are in place, I even can get serial data on
> USART output, but TX ready/ RX ready bits of CSR are not working
> somehow.
> 

Have a look at the way that linux 2.6.20 (patched from Maxim) does
things.  It's possible there's a configuration or two missing.

I had an issue with USART0 once because I didn't read something
carefully.

[U-Boot-Users] USART on at91rm9200

[Ulf Samuelsson]

> Hi, Matt:
> 
> I am using the same source code I guess and everything BUT USARTs works
> for me just fine (thanks Ulf). I have searched desperately through mail
> archives for any known USART problems but with no avail. It would help
> me tremendously if you could test USART on your board (if you have
> physical connector it must be simple) just as usual RS232 and tell me
> whether it works. It can be useful for yourself if you ever consider
> using USARTs. And could you please send me your
> u-boot/cpu/arm920t/at91rm9200/serial.c file just in case?
> 
> BTW, what USARTs (if any) are available on your board? At91rm9200-ek
> evaluation kit has USART1 connected to DB9 port.
> 

Why not use the DBGU?
I have never ever tested U-Boot with one of the std USARTs so
I am not surprised if people have problems...

> Thanks a lot,
> 
> Leonid. 
> 


Best Regards
Ulf Samuelsson

[U-Boot-Users] USART on at91rm9200

[Leonid]

As I already wrote, for my project I need some USART functionality DBGU
doesn't have. For the time being I just wanted to verify USARTs are
working at all and using them as serial ports on u-boot looked for me as
a simplest test...
Probably I was wrong...  

Leonid.

-----Original Message-----
From: Ulf Samuelsson [mailto:ulf at atmel.com] 
Sent: Monday, August 13, 2007 10:08 AM
To: Leonid; Matt Gessner; u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] USART on at91rm9200

> Hi, Matt:
> 
> I am using the same source code I guess and everything BUT USARTs 
> works for me just fine (thanks Ulf). I have searched desperately 
> through mail archives for any known USART problems but with no avail. 
> It would help me tremendously if you could test USART on your board 
> (if you have physical connector it must be simple) just as usual RS232

> and tell me whether it works. It can be useful for yourself if you 
> ever consider using USARTs. And could you please send me your 
> u-boot/cpu/arm920t/at91rm9200/serial.c file just in case?
> 
> BTW, what USARTs (if any) are available on your board? At91rm9200-ek 
> evaluation kit has USART1 connected to DB9 port.
> 

Why not use the DBGU?
I have never ever tested U-Boot with one of the std USARTs so I am not
surprised if people have problems...

> Thanks a lot,
> 
> Leonid. 
> 


Best Regards
Ulf Samuelsson

[U-Boot-Users] USART on at91rm9200

[larytet.54154763 at bloglines.com]

hello,



it looks  that function serial_putc() is called before serial_init()
(file cpu/arm920t/at91rm9200/serial.c. Function serial_putc() enters loop
forever.



Suggested quick patch 



static int initialized = 0;



/* bring
flag initialized up in the end of the function serial_init() */

int serial_init
(void)

{

	/* make any port initializations specific to this port */

#ifdef
CONFIG_DBGU

	*AT91C_PIOA_PDR = AT91C_PA31_DTXD | AT91C_PA30_DRXD;	/* PA 31
& 30 */

	*AT91C_PMC_PCER = 1 << AT91C_ID_SYS;	/* enable clock */

#endif

#ifdef CONFIG_USART0

	*AT91C_PIOA_PDR = AT91C_PA17_TXD0 | AT91C_PA18_RXD0;

	*AT91C_PMC_PCER |= 1 << AT91C_ID_USART0;	/* enable clock */

#endif

#ifdef
CONFIG_USART1

	*AT91C_PIOB_PDR = AT91C_PB21_TXD1 | AT91C_PB20_RXD1;

	/*
arkady - this is not enough to write PDR

		i want to make sure, that alternative
function A is set */

	*AT91C_PIOB_ASR = AT91C_PB21_TXD1 | AT91C_PB20_RXD1;

	*AT91C_PMC_PCER |= 1 << AT91C_ID_USART1;	/* enable clock */

	/* arkady
- i am not sure, that port B is enabled in the PCER */

	*AT91C_PMC_PCER |=
1 << AT91C_ID_PIOB;	/* enable PIOB */

#endif

	serial_setbrg ();



	us->US_CR
= AT91C_US_RSTRX | AT91C_US_RSTTX;

	us->US_CR = AT91C_US_RXEN | AT91C_US_TXEN;

	us->US_MR =

		(AT91C_US_CLKS_CLOCK | AT91C_US_CHRL_8_BITS |

		 AT91C_US_PAR_NONE
| AT91C_US_NBSTOP_1_BIT);

	us->US_IMR = ~0ul;

	initialized = 1;

	return
(0);

}





void serial_putc (const char c)

{

	if (!initialized) return;



	if (c == '\n')

		serial_putc ('\r');

	while ((us->US_CSR & AT91C_US_TXRDY)
== 0);

	us->US_THR = c;

}

[U-Boot-Users] USART on at91rm9200

[Wolfgang Denk]

In message <1187155270.2123295638.20273.sendItem@bloglines.com> you wrote:
> 
> it looks  that function serial_putc() is called before serial_init()
> (file cpu/arm920t/at91rm9200/serial.c. Function serial_putc() enters loop
> forever.
> 
> 
> 
> Suggested quick patch 

Sorry, this is no patch, this is unusable.

Please see http://www.denx.de/wiki/UBoot/Patches , then resubmit.
Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The C-shell doesn't parse. It adhoculates.
    - Casper.Dik at Holland.Sun.COM in <3ol96k$b2j@engnews2.Eng.Sun.COM>