U-Boot and kernel 2.6

U-Boot and kernel 2.6

[Ricardo DIz]

Hi,

I'm trying to boot a custom 860T board using the latest kernel from
linuxppc-2.5. The board is currently using a variation of an old version
of U-Boot (0.2.0) along with a hacked 2.4.20 linux kernel version.

My first aim is to boot a simple kernel and make it get to a shell. For
that I compiled the kernel, but did not compiled u-boot with a recent
version.

When booting, the kernel got uncompressed, but then it resets! I presume
the watchdog (which is enabled), is resetting the processor, so I guess
booting just stalls. Was there any changes in the way parameters were
received by the kernel since 2.4.20?

Oh, I forgot to mention the compiler. I'm still using a gcc 2.95
cross-compiler, altough I tried using a gcc 3.2 cross-compiler for the
8260 once, but got the same result.

I followed a recent thread very similar to this, but that turned out to be
just a matter of UART configuration, and I don't thinks this is the case.

Any thoughts?

Thanks in advance,
Ricardo Diz

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: U-Boot and kernel 2.6

[Meriin Michael-BMM063]

Check the bd_t definition, it MUST be the same in u-boot and Linux platform definition.
bd_t in Linux is defined in ppcboot.h

Best Regards,
     Michael Meriin


-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Ricardo DIz
Sent: Wednesday, June 09, 2004 20:48
To: linuxppc-embedded@lists.linuxppc.org
Subject: U-Boot and kernel 2.6



Hi,

I'm trying to boot a custom 860T board using the latest kernel from
linuxppc-2.5. The board is currently using a variation of an old version
of U-Boot (0.2.0) along with a hacked 2.4.20 linux kernel version.

My first aim is to boot a simple kernel and make it get to a shell. For
that I compiled the kernel, but did not compiled u-boot with a recent
version.

When booting, the kernel got uncompressed, but then it resets! I presume
the watchdog (which is enabled), is resetting the processor, so I guess
booting just stalls. Was there any changes in the way parameters were
received by the kernel since 2.4.20?

Oh, I forgot to mention the compiler. I'm still using a gcc 2.95
cross-compiler, altough I tried using a gcc 3.2 cross-compiler for the
8260 once, but got the same result.

I followed a recent thread very similar to this, but that turned out to be
just a matter of UART configuration, and I don't thinks this is the case.

Any thoughts?

Thanks in advance,
Ricardo Diz


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: U-Boot and kernel 2.6

[David Woodhouse]

On Thu, 2004-06-10 at 09:45 +0300, Meriin Michael-BMM063 wrote:
> Check the bd_t definition, it MUST be the same in u-boot and Linux platform definition.
> bd_t in Linux is defined in ppcboot.h

We really need to throw this crap away and start using structured tags
like ARM does.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Pantelis Antoniou]

David Woodhouse wrote:

>On Thu, 2004-06-10 at 09:45 +0300, Meriin Michael-BMM063 wrote:
>
>>Check the bd_t definition, it MUST be the same in u-boot and Linux platform definition.
>>bd_t in Linux is defined in ppcboot.h
>>
>
>We really need to throw this crap away and start using structured tags
>like ARM does.
>
>--
>dwmw2
>
>
>
>
>
>
Or we can parse the u-boot environment which is ascii.
I already do this...

Regards

Pantelis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[David Woodhouse]

On Fri, 2004-06-11 at 14:03 +0300, Pantelis Antoniou wrote:
> Or we can parse the u-boot environment which is ascii.
> I already do this...

Yeah, that works too.

Btw, consoles starting nice and early is nice...

diff -ur --exclude '.*.cmd' --exclude '.config.*' --exclude '*.o' linux-2.6.6-nopci/arch/ppc/syslib/m8260_setup.c linux-2.6.6/arch/ppc/syslib/m8260_setup.c
--- linux-2.6.6-nopci/arch/ppc/syslib/m8260_setup.c	2004-06-11 09:09:03.000000000 +0100
+++ linux-2.6.6/arch/ppc/syslib/m8260_setup.c	2004-06-11 11:39:08.710629736 +0100
@@ -53,6 +53,7 @@
 unsigned char __res[sizeof(bd_t)];

 extern void cpm2_reset(void);
+extern int cpm_uart_console_init(void);

 static void __init
 m8260_setup_arch(void)
@@ -60,6 +61,9 @@
 	/* Reset the Communication Processor Module.
 	*/
 	cpm2_reset();
+#ifdef CONFIG_SERIAL_CPM_CONSOLE
+	cpm_uart_console_init();
+#endif
 }

 /* The decrementer counts at the system (internal) clock frequency
--- linux-2.6.6-nopci/drivers/serial/cpm_uart/cpm_uart_core.c	2004-06-11 09:09:03.000000000 +0100
+++ linux-2.6.6/drivers/serial/cpm_uart/cpm_uart_core.c	2004-06-11 11:38:51.376264960 +0100
@@ -1151,7 +1151,14 @@

 int __init cpm_uart_console_init(void)
 {
-	int ret = cpm_uart_init_portdesc();
+	static int first = 1;
+	int ret;
+
+	if (!first)
+		return 0;
+
+	first = 0;
+	ret = cpm_uart_init_portdesc();

 	if (!ret)
 		register_console(&cpm_scc_uart_console);


--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Wolfgang Denk]

In message <40C99182.8050201@intracom.gr> you wrote:
>
[David Woodhouse:]

> >We really need to throw this crap away and start using structured tags
> >like ARM does.

Right (or bi_rec's or whatever this might end up being called).

> Or we can parse the u-boot environment which is ascii.
> I already do this...

No, this is IMHO not a good idea. Some of the information that  needs
to  be  passed to the kernel is not contained in the envrionment, and
does not belong there.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Sendmail may be safely run set-user-id to root.
                        -- Eric Allman, "Sendmail Installation Guide"

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Pantelis Antoniou]

Wolfgang Denk wrote:

>In message <40C99182.8050201@intracom.gr> you wrote:
>
>[David Woodhouse:]
>
>
>>>We really need to throw this crap away and start using structured tags
>>>like ARM does.
>>>
>
>Right (or bi_rec's or whatever this might end up being called).
>
>
>>Or we can parse the u-boot environment which is ascii.
>>I already do this...
>>
>
>No, this is IMHO not a good idea. Some of the information that  needs
>to  be  passed to the kernel is not contained in the envrionment, and
>does not belong there.
>
I'm just talking about augmenting the information provided by bd_t.

And it's not just things that the kernel needs, it can be used to
pass information to the user-space applications.

Reading the environment from flash is not correct because the
variables might be modified by the boot sequence but not commited.

When I get some breathing time, I'll sent you the patch.

>
>Best regards,
>
>Wolfgang Denk
>
>
Regards

Pantelis


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Wolfgang Denk]

Dear Pantelis,

in message <40C9B249.4070905@intracom.gr> you wrote:
>
> >No, this is IMHO not a good idea. Some of the information that  needs
> >to  be  passed to the kernel is not contained in the envrionment, and
> >does not belong there.
> >
> I'm just talking about augmenting the information provided by bd_t.

Again, no. It makes no sense to implement two  (or  more)  interfaces
for  the  same  purpose.  Let's  do it once, and right. It has become
clear that the bd_t stuff is not flexible enough, so let's get rid of
it and replace it, instead of adding more crap^H^H^H^H stuff  on  top
of it.

> And it's not just things that the kernel needs, it can be used to
> pass information to the user-space applications.

But this is nothing now. You have always been able to read and  write
the  U-Boot  environment  from applications. But this is a completely
unrelated topic.

Similarly it's trivial to parse /proc/cmdline by a script or  program
to  extract any information you might be looking for. But again, this
has nothing to do with  the  way  how  the  boot  loader  passes  the
required information to the kernel.

> Reading the environment from flash is not correct because the
> variables might be modified by the boot sequence but not commited.

This depends  on  what  you  are  doing.  Of  course  it  is  in  the
responsibility  of  the user to define which data to use, and when or
where to place a "setenv" in the boot script (if really needed). "Not
correct" is just your opinion for a very specuific mode  of  usage  -
which  just  indicates the problem: the U-Boot environment is NOT the
right place to look for the information you are after.

> When I get some breathing time, I'll sent you the patch.

Be prepared that I might ignore it.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It all seemed, he thought, to be rather a lot of  trouble  to  go  to
just sharpen a razor blade.  - Terry Pratchett, _The Light Fantastic_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[David Woodhouse]

On Fri, 2004-06-11 at 17:16 +0300, Pantelis Antoniou wrote:
> Yeah, having the bi_recs interface actually working
> would be ideal, but at the present time nothing is
> working and as AFAIK no-one is working on it.

So we should offer some gentle encouragement. Like refusing to accept
any further modifications to include/asm-ppc/ppcboot.h.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Wolfgang Denk]

In message <40C9BED6.3010809@intracom.gr> you wrote:
>
> OK, lets look at the very simple problem of having two
> ethernet interfaces. From where do I get the ethernet
> mac addresses? Modifying bd_t with defines is gross.

This is hardware dependend. For  example,  on  some  boards  the  MAC
addresses are simply sequential - so you just add one :-)

> Putting everything on the kernel command line results in
> an unreadable command line.

Agreed. The command  line  is  another  bad  solution  to  pass  such
information.

> Yeah, having the bi_recs interface actually working
> would be ideal, but at the present time nothing is
> working and as AFAIK no-one is working on it.

Mark A. Greer made a  nice  proposal  more  than  2  years  ago.  See
discussion  that  started  as  "EV-64260-BP & GT64260 bi_recs" around
March 19, 2002.

I'd be happy to see this accepted.

> I have to have something working now and IMO just reading
> the u-boot environment is the fastest solution.

OK - accepted. But it's a quick and dirty  hack,  and  not  something
that should go into a public tree.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Microsoft Multitasking:
                     several applications can crash at the same time.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Wolfgang Denk]

In message <1086964452.15845.1308.camel@hades.cambridge.redhat.com> you wrote:
> On Fri, 2004-06-11 at 17:16 +0300, Pantelis Antoniou wrote:
> > Yeah, having the bi_recs interface actually working
> > would be ideal, but at the present time nothing is
> > working and as AFAIK no-one is working on it.
>
> So we should offer some gentle encouragement. Like refusing to accept
> any further modifications to include/asm-ppc/ppcboot.h.

Then you must also refuse to accept any  further  modifications  that
define  "struct  bd_info"  for  any boards. Or please explain why you
think that one definiton of bd_info which gets used by many boards is
worse then several private definitions of the same structure used  by
one board only in each case?

Let's see:

linuxppc-2.4				linuxppc-2.5
----------------------------------------------------
-> cd arch/ppc/platforms		-> cd arch/ppc/platforms
-> grep bd_info * | wc -l		-> grep bd_info * | wc -l
      6					      8
-> grep ppcboot.h * | wc -l		-> grep ppcboot.h * | wc -l
      9					     12

Before phasing out a working solution, even if it's  a  poor  design,
you should provide a new, better solution.

I promise: I will make sure that U-Boot supports the new interface as
soon as there is any definitive agreement about what  it's  going  to
look like. As mentioned before - I'd be happy to accept what has been
discussed more than two years ago, especially Mark's proposal.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Experience is what causes a person to make new  mistakes  instead  of
old ones.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Mark Chambers]

> > Yeah, having the bi_recs interface actually working
> > would be ideal, but at the present time nothing is
> > working and as AFAIK no-one is working on it.
>
> So we should offer some gentle encouragement. Like refusing to accept
> any further modifications to include/asm-ppc/ppcboot.h.
>

Here's another idea - how about XML?  That would be two steps forward, IMO,
instead of just going from one magic structure to another.

As to just trashing bd_t, does that mean users have to upgrade their
bootloader to use newer kernels, and could not switch back easily if
problems arose?  Perhaps the kernel could identify whether the pointer is to
a bd_t or something else and handle it automatically?

Mark Chambers


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Wolfgang Denk]

In message <002a01c44fc9$201dc820$0301a8c0@chuck2> you wrote:
>
> Here's another idea - how about XML?  That would be two steps forward, IMO,
> instead of just going from one magic structure to another.

Oh no. Don't forget that the the boot loader  has  to  generate  XML.
Grrrhh... [I'd rather generate a troff document, then :-) ]

> As to just trashing bd_t, does that mean users have to upgrade their
> bootloader to use newer kernels, and could not switch back easily if
> problems arose?  Perhaps the kernel could identify whether the pointer is to
> a bd_t or something else and handle it automatically?

I guess you can always add some glue code (aka bootstrap  loader)  to
the Linux kernel which converts one interface into another.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
A conservative is a man with two perfectly good legs  who  has  never
learned to walk.                              - Franklin D. Roosevelt

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Tom Rini]

On Fri, Jun 11, 2004 at 05:16:54PM +0300, Pantelis Antoniou wrote:
>
> Wolfgang Denk wrote:
>
> >Dear Pantelis,
> >
> >in message <40C9B249.4070905@intracom.gr> you wrote:
> >
> >>>No, this is IMHO not a good idea. Some of the information that  needs
> >>>to  be  passed to the kernel is not contained in the envrionment, and
> >>>does not belong there.
> >>>
> >>>
> >>I'm just talking about augmenting the information provided by bd_t.
> >>
> >
> >Again, no. It makes no sense to implement two  (or  more)  interfaces
> >for  the  same  purpose.  Let's  do it once, and right. It has become
> >clear that the bd_t stuff is not flexible enough, so let's get rid of
> >it and replace it, instead of adding more crap^H^H^H^H stuff  on  top
> >of it.
> >
> >
> >>And it's not just things that the kernel needs, it can be used to
> >>pass information to the user-space applications.
> >>
> >
> >But this is nothing now. You have always been able to read and  write
> >the  U-Boot  environment  from applications. But this is a completely
> >unrelated topic.
> >
> >Similarly it's trivial to parse /proc/cmdline by a script or  program
> >to  extract any information you might be looking for. But again, this
> >has nothing to do with  the  way  how  the  boot  loader  passes  the
> >required information to the kernel.
> >
> >
> >>Reading the environment from flash is not correct because the
> >>variables might be modified by the boot sequence but not commited.
> >>
> >
> >This depends  on  what  you  are  doing.  Of  course  it  is  in  the
> >responsibility  of  the user to define which data to use, and when or
> >where to place a "setenv" in the boot script (if really needed). "Not
> >correct" is just your opinion for a very specuific mode  of  usage  -
> >which  just  indicates the problem: the U-Boot environment is NOT the
> >right place to look for the information you are after.
> >
> >
> OK, lets look at the very simple problem of having two
> ethernet interfaces. From where do I get the ethernet
> mac addresses? Modifying bd_t with defines is gross.
> Putting everything on the kernel command line results in
> an unreadable command line.

The 98%-in-2.6 answer today is to pass in BI_BOARD_INFO, a
board-specific blob of information, which is what boards like the
prpmc260 (only 2_4_devel right now since it's a gt64x60 board that needs
cleaner generic code for 2.6, but anyhow..).

... kicking myself for getting into this thread now, no doubt.

--
Tom Rini
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Kenneth Johansson]

On Fri, 2004-06-11 at 17:31, Mark Chambers wrote:
> > > Yeah, having the bi_recs interface actually working
> > > would be ideal, but at the present time nothing is
> > > working and as AFAIK no-one is working on it.
> >
> > So we should offer some gentle encouragement. Like refusing to accept
> > any further modifications to include/asm-ppc/ppcboot.h.
> >
>
> Here's another idea - how about XML?  That would be two steps forward, IMO,
> instead of just going from one magic structure to another.

Well XML of all things must be magic considering that it automatically
solves all problems all the time.

> As to just trashing bd_t, does that mean users have to upgrade their
> bootloader to use newer kernels, and could not switch back easily if
> problems arose?  Perhaps the kernel could identify whether the pointer is to
> a bd_t or something else and handle it automatically?

Don't worry this will never change the problem is not creating a big
enough itch so nobody will do anything (again).


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Greg Goodwin]

As long as the bd_info still allows for my use case I
will be happy.

I have am using the bd_info structure to pass the
differences between several Interphase boards we are
using. Since the MDIO pins and interrupts are
different I am able to use this technique to allow the
same kernel to work with the Interphase 5339F, 4538
and now I am doing the 4532.

If the bd_info structure was fixed this would not be a
problem provided a clear OEM area was defined.

typedef struct bd_info {
    /* commmon */
    void *oem_bd_info_pointer;
} bd_t;

Now filling the oem_bd_info_pointer with anything
other that NULL would allow passing OEM specific
information while still allowing the bd_info fixed
stucture to be defined in a fixed manner.

One example of my use case for the bd_info area is the
fcc_enet driver. In fcc_enet.c I can point to the pin
assigments from the core boot code. Kind of nice since
the fcc_enet driver is this case need not change for
new boards!

For those who care, I did add full MII-TOOL support,
as well as RMON status via procs and I am getting full
line rate on the driver. Still not in great shape for
folding back since it is based on 2.4.20 and not much
care to handle all cases. But it does have some
promise.

>From fcc_enet.c (small example)

  bd_t	 *bd = (bd_t *)__res;

  fip->fc_mdio = bd->bi_fcc_mdio_pin;  /* FCC MDIO pin
*/
  fip->fc_mdck = bd->bi_fcc_mdc_pin;  /* FCC MDC pin
*/


# ttcp -ts -n10000 10.2.0.65
ttcp-t: buflen=8192, nbuf=10000, align=16384/0,
port=5001  tcp  -> 10.2.0.65
ttcp-t: socket
ttcp-t: connect
ttcp-t: 81920000 bytes in 7.52 real seconds = 10642.38
KB/sec +++
ttcp-t: 10000 I/O calls, msec/call = 0.77, calls/sec =
1330.30
ttcp-t: 0.0user 7.4sys 0:07real 100% 0i+0d 0maxrss
0+2pf 0+0csw

# mii-tool eth0
eth0: negotiated 100baseTx-FD, link ok

# cat /proc/driver/fcc_enet/rmon
Total octect counter.................. 0x0060c23a
6341178
Total collision counter............... 0x00000000 0
Total broadcast packet counter........ 0x00000000 0
Total multicast packet count.......... 0x00000000 0
Total packets < 64 bytes.............. 0x00000000 0
Total packets < 64 bytes with errors.. 0x00000000 0
Total packets > 1518.................. 0x00000000 0
Total packets > 1518 with errors...... 0x00000000 0
Total packets == 64 byte,,,,,,,,...... 0x00000000 0
Total packets 64 < bytes <= 127,...... 0x000151d4
86484
Total packets 127 < bytes <= 255...... 0x00000068 104
Total packets 256 < bytes <= 511...... 0x00000000 0
Total packets 512 < bytes <= 1023..... 0x00000001 1
Total packets 1024 < bytes <= 1518.... 0x00000000 0
eth0: MII status: link up, 100 Mbps Full Duplex (FD),
auto-negotiation complete.

# cat /proc/cpuinfo
cpu             : 82xx
sbc             : Interphase 4538 revision 1
monarch         : false
t1/e1 ports     : 2
sdram           : 64MB
local sdram     : none
flash           : 4MB
cam             : none
ima             : not installed
mpc             : MPC8264AZU, 300/200/66MHz, HIP4 rev
B.1
core clock      : 294 MHz
CPM  clock      : 196 MHz
bus  clock      : 65 MHz
revision        : 16.20 (pvr 8081 1014)
bogomips        : 196.19

# cat /proc/cpuinfo
cpu             : 82xx
sbc             : Interphase 5539F revision 1
monarch         : false
t1/e1 ports     : 4
sdram           : 64MB
local sdram     : 8MB
flash           : 4MB
cam             : 16Kx64
ima             : not installed
mpc             : MPC8264AZU, 300/200/66MHz, HIP4 rev
B.1
core clock      : 294 MHz
CPM  clock      : 196 MHz
bus  clock      : 65 MHz
revision        : 16.20 (pvr 8081 1014)
bogomips        : 196.19

That should give you an idea.
>From one user here who uses the bd_info stucture.

Greg

--- Wolfgang Denk <wd@denx.de> wrote:
>
> In message
>
<1086964452.15845.1308.camel@hades.cambridge.redhat.com>
> you wrote:
> > On Fri, 2004-06-11 at 17:16 +0300, Pantelis
> Antoniou wrote:
> > > Yeah, having the bi_recs interface actually
> working
> > > would be ideal, but at the present time nothing
> is
> > > working and as AFAIK no-one is working on it.
> >
> > So we should offer some gentle encouragement. Like
> refusing to accept
> > any further modifications to
> include/asm-ppc/ppcboot.h.
>
> Then you must also refuse to accept any  further
> modifications  that
> define  "struct  bd_info"  for  any boards. Or
> please explain why you
> think that one definiton of bd_info which gets used
> by many boards is
> worse then several private definitions of the same
> structure used  by
> one board only in each case?
>
> Let's see:
>
> linuxppc-2.4				linuxppc-2.5
> ----------------------------------------------------
> -> cd arch/ppc/platforms		-> cd arch/ppc/platforms
> -> grep bd_info * | wc -l		-> grep bd_info * | wc -l
>       6					      8
> -> grep ppcboot.h * | wc -l		-> grep ppcboot.h * |
> wc -l
>       9					     12
>
> Before phasing out a working solution, even if it's
> a  poor  design,
> you should provide a new, better solution.
>
> I promise: I will make sure that U-Boot supports the
> new interface as
> soon as there is any definitive agreement about what
>  it's  going  to
> look like. As mentioned before - I'd be happy to
> accept what has been
> discussed more than two years ago, especially Mark's
> proposal.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime
> Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88
> Email: wd@denx.de
> Experience is what causes a person to make new
> mistakes  instead  of
> old ones.
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: U-Boot and kernel 2.6

[Ricardo DIz]

Thanks, I'll do that first thing Monday morning (currently on a 4-days
mini-vacations :) )

Regards,
Ricardo Diz

>
> Check the bd_t definition, it MUST be the same in u-boot and Linux
> platform definition.
> bd_t in Linux is defined in ppcboot.h
>
> Best Regards,
>      Michael Meriin
>
>
> -----Original Message-----
> From: owner-linuxppc-embedded@lists.linuxppc.org
> [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Ricardo
> DIz
> Sent: Wednesday, June 09, 2004 20:48
> To: linuxppc-embedded@lists.linuxppc.org
> Subject: U-Boot and kernel 2.6
>
>
>
> Hi,
>
> I'm trying to boot a custom 860T board using the latest kernel from
> linuxppc-2.5. The board is currently using a variation of an old version
> of U-Boot (0.2.0) along with a hacked 2.4.20 linux kernel version.
>
> My first aim is to boot a simple kernel and make it get to a shell. For
> that I compiled the kernel, but did not compiled u-boot with a recent
> version.
>
> When booting, the kernel got uncompressed, but then it resets! I presume
> the watchdog (which is enabled), is resetting the processor, so I guess
> booting just stalls. Was there any changes in the way parameters were
> received by the kernel since 2.4.20?
>
> Oh, I forgot to mention the compiler. I'm still using a gcc 2.95
> cross-compiler, altough I tried using a gcc 3.2 cross-compiler for the
> 8260 once, but got the same result.
>
> I followed a recent thread very similar to this, but that turned out to be
> just a matter of UART configuration, and I don't thinks this is the case.
>
> Any thoughts?
>
> Thanks in advance,
> Ricardo Diz
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Mark A. Greer]

Wolfgang Denk wrote:

>In message <40C9BED6.3010809@intracom.gr> you wrote:
>
>
>>OK, lets look at the very simple problem of having two
>>ethernet interfaces. From where do I get the ethernet
>>mac addresses? Modifying bd_t with defines is gross.
>>
>>
>
>This is hardware dependend. For  example,  on  some  boards  the  MAC
>addresses are simply sequential - so you just add one :-)
>
>
>
>>Putting everything on the kernel command line results in
>>an unreadable command line.
>>
>>
>
>Agreed. The command  line  is  another  bad  solution  to  pass  such
>information.
>
>
>
>>Yeah, having the bi_recs interface actually working
>>would be ideal, but at the present time nothing is
>>working and as AFAIK no-one is working on it.
>>
>>
>
>Mark A. Greer made a  nice  proposal  more  than  2  years  ago.  See
>discussion  that  started  as  "EV-64260-BP & GT64260 bi_recs" around
>March 19, 2002.
>
>I'd be happy to see this accepted.
>
Hey, thanks for the plug Wolfgang!  :)

Here are some thoughts that don't directly address the bi_rec (or
whatever) issue but they are related...

Some things have changed since that thread.  In particular, the "On Chip
Peripheral" or OCP support has been added to the kernel.  Matt Porter
has spent a lot of time working on the OCP and has it looking/working
well.  If you're not familiar with it, its worth a look.

We can use the OCP to pass information from the platform-specific kernel
code to drivers.  We still have the issue of getting info into the
kernel in the first place so we still need to resolve that issue.
However, I would rather have drivers look in the OCP for info instead of
directly at bi_recs (or whatever we chose).

So for example, a network driver does not have to worry about where to
get a MAC address, it just looks in the OCP.  The board-specific code
can deal with getting the MAC addr from a bi_rec, the cmd line, an I2C
SROM somewhere, conjuring one up using incrementing MAC addrs, or
whatever.  After all, where to get the MAC addr really is platform (&
firmware) specific.  The OCP provides a single, clean interface to pass
info into drivers.

I think its something worth considering.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Mark Chambers]

I have seen many references to OCP.  How does one find out what it is?

Mark Chambers

----- Original Message -----
From: "Mark A. Greer" <mgreer@mvista.com>
> Here are some thoughts that don't directly address the bi_rec (or
> whatever) issue but they are related...
>
> Some things have changed since that thread.  In particular, the "On Chip
> Peripheral" or OCP support has been added to the kernel.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Mark A. Greer]

Mark Chambers wrote:

>I have seen many references to OCP.  How does one find out what it is?
>
AFAIK, the best way is to just look at the code: arch/ppc/syslib/ocp.c.
Its pretty straightforward.  Its used extensively by the 4xx code:
arch/ppc/platforms/4xx/*.

Mark


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Kumar Gala]

> Some things have changed since that thread.  In particular, the "On
> Chip
> Peripheral" or OCP support has been added to the kernel.  Matt Porter
> has spent a lot of time working on the OCP and has it looking/working
> well.  If you're not familiar with it, its worth a look.
>
> We can use the OCP to pass information from the platform-specific
> kernel
> code to drivers.  We still have the issue of getting info into the
> kernel in the first place so we still need to resolve that issue.
> However, I would rather have drivers look in the OCP for info instead
> of
> directly at bi_recs (or whatever we chose).
>
> So for example, a network driver does not have to worry about where to
> get a MAC address, it just looks in the OCP.  The board-specific code
> can deal with getting the MAC addr from a bi_rec, the cmd line, an I2C
> SROM somewhere, conjuring one up using incrementing MAC addrs, or
> whatever.  After all, where to get the MAC addr really is platform (&
> firmware) specific.  The OCP provides a single, clean interface to pass
> info into drivers.
>
> I think its something worth considering.

I agree with Mark.  We are already doing this for 85xx in 2.4 and 2.6.
The board code handles populating mac addr's in OCP info.

Our intention is that drivers that support Freescale parts should use
OCP.  One of the reasons for this is because of all the various
processors that will exist from Freescale were the driver should be
reusable.

- kumar


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: U-Boot and kernel 2.6

[Dmitry Chichkov]

Hi Ricardo,

I would recommend not to try old versions of U-Boot ("from 2.4") with new 
linux kernels ("2.6").
We had some troubles with invalid memory mappings in this configuration.

-- Regards, Dmitry Chichkov




"Ricardo DIz" <rdiz@alumni.deec.uc.pt> ???????/???????? ? ???????? 
?????????: news:4418.62.48.238.11.1086803257.squirrel@alumni.deec.uc.pt...
>
> Hi,
>
> I'm trying to boot a custom 860T board using the latest kernel from
> linuxppc-2.5. The board is currently using a variation of an old version
> of U-Boot (0.2.0) along with a hacked 2.4.20 linux kernel version.
>
> My first aim is to boot a simple kernel and make it get to a shell. For
> that I compiled the kernel, but did not compiled u-boot with a recent
> version.
>
> When booting, the kernel got uncompressed, but then it resets! I presume
> the watchdog (which is enabled), is resetting the processor, so I guess
> booting just stalls. Was there any changes in the way parameters were
> received by the kernel since 2.4.20?
>
> Oh, I forgot to mention the compiler. I'm still using a gcc 2.95
> cross-compiler, altough I tried using a gcc 3.2 cross-compiler for the
> 8260 once, but got the same result.
>
> I followed a recent thread very similar to this, but that turned out to be
> just a matter of UART configuration, and I don't thinks this is the case.
>
> Any thoughts?
>
> Thanks in advance,
> Ricardo Diz
>
> ** Sent via the linuxppc-embedded mail list. See 
> http://lists.linuxppc.org/
>
> 

Re: U-Boot and kernel 2.6

[Wolfgang Denk]

In message <eamnsh$v4b$1@sea.gmane.org> you wrote:
> 
> I would recommend not to try old versions of U-Boot ("from 2.4") with new 
> linux kernels ("2.6").
> We had some troubles with invalid memory mappings in this configuration.

It is of course always a good idea to use  the  latest  and  greatest
versions  of  the software, but U-Boot is a boot loader, and it has a
clearly defined interface to the kernel  -  and  great  attempts  are
being  made  to  keep  this  interface  unchanged  or, if changes are
necessary, to perform them in a way that stays compatible.

I see no reason why even old versions of U-Boot could cause  problems
with  recent Linux kernels. Actually I have seen very old versions of
U-Boot (like U-Boot-0.3.x) seen in production use with recent  kernel
versions.



In your case it was probably a bug that had been fixed,  but  not  an
incompatibility with current kernels.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
panic: can't find /