* BSE-IP
@ 2010-01-26 20:30 Dan.Geer
2010-01-26 21:03 ` BSE-IP Scott Wood
0 siblings, 1 reply; 9+ messages in thread
From: Dan.Geer @ 2010-01-26 20:30 UTC (permalink / raw)
To: linuxppc-dev
My end goal is to run the latest 2.6.32 kernel on an ancient BSE-IP MPC823
board. One step in the process is an attempt to compile the last "working"
kernel for this platform, and it hasn't been pretty.
Back in 2005, Kumar Gala caught an issue with compiling for this platform,
and Dan Malek commented about which options to choose to complete a
successful compile. I'm in the process of trying to get that (2.6.16.62)
series to work. It seems that one of the newer dev boards got the focus of
the port, and the BSE-IP drop out of sight.
Is anyone still working with the BSE-IP? What is the last known working
kernel? Any suggestions/insight into what kernel works would be very much
appreciated.
Dan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BSE-IP
2010-01-26 20:30 BSE-IP Dan.Geer
@ 2010-01-26 21:03 ` Scott Wood
2010-01-26 22:04 ` BSE-IP Dan.Geer
0 siblings, 1 reply; 9+ messages in thread
From: Scott Wood @ 2010-01-26 21:03 UTC (permalink / raw)
To: Dan.Geer; +Cc: linuxppc-dev
Dan.Geer@faa.gov wrote:
> My end goal is to run the latest 2.6.32 kernel on an ancient BSE-IP MPC823
> board. One step in the process is an attempt to compile the last "working"
> kernel for this platform, and it hasn't been pretty.
>
> Back in 2005, Kumar Gala caught an issue with compiling for this platform,
> and Dan Malek commented about which options to choose to complete a
> successful compile. I'm in the process of trying to get that (2.6.16.62)
> series to work. It seems that one of the newer dev boards got the focus of
> the port, and the BSE-IP drop out of sight.
Newer boards have been used for recent development, but it shouldn't be
too hard to get other boards to work. With the device tree, a lot more
of the hardware description is done in a data structure, rather than
scattered throughout code.
I'd start by taking one of the existing supported 8xx boards in the
current tree, and adapting its device tree and platform file to describe
the BSE-IP, using the old code as a reference. You may also need
bootwrapper changes, depending on what firmware you use.
Things have changed enough that I don't recommend trying to directly
merge the old code into the new kernel.
-Scott
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BSE-IP
2010-01-26 21:03 ` BSE-IP Scott Wood
@ 2010-01-26 22:04 ` Dan.Geer
2010-01-26 22:17 ` BSE-IP Scott Wood
0 siblings, 1 reply; 9+ messages in thread
From: Dan.Geer @ 2010-01-26 22:04 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
> > My end goal is to run the latest 2.6.32 kernel on an ancient BSE-IP
MPC823
> > board. One step in the process is an attempt to compile the last
"working"
> > kernel for this platform, and it hasn't been pretty.
> >
> > Back in 2005, Kumar Gala caught an issue with compiling for this
platform,
> > and Dan Malek commented about which options to choose to complete a
> > successful compile. I'm in the process of trying to get that
(2.6.16.62)
> > series to work. It seems that one of the newer dev boards got the
focus of
> > the port, and the BSE-IP drop out of sight.
>
> Newer boards have been used for recent development, but it shouldn't be
> too hard to get other boards to work. With the device tree, a lot more
> of the hardware description is done in a data structure, rather than
> scattered throughout code.
>
> I'd start by taking one of the existing supported 8xx boards in the
> current tree, and adapting its device tree and platform file to describe
> the BSE-IP, using the old code as a reference. You may also need
> bootwrapper changes, depending on what firmware you use.
Any idea of the last kernel version that worked? So I know I can count on
that as a reference? I have the 2.2 pre7 from BSE, but there have been a
few changes since. ;^)
It appears the image (bootwrapper) needs to be completely self-contained,
and needs to understand how to read the flash parameters. That's on my
list.
> Things have changed enough that I don't recommend trying to directly
> merge the old code into the new kernel.
Understood.
> -Scott
=Dan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BSE-IP
2010-01-26 22:04 ` BSE-IP Dan.Geer
@ 2010-01-26 22:17 ` Scott Wood
2010-01-26 23:28 ` BSE-IP Dan.Geer
0 siblings, 1 reply; 9+ messages in thread
From: Scott Wood @ 2010-01-26 22:17 UTC (permalink / raw)
To: Dan.Geer; +Cc: linuxppc-dev
Dan.Geer@faa.gov wrote:
> Any idea of the last kernel version that worked? So I know I can count on
> that as a reference?
I'm not familiar with the board, sorry -- was just pointing out that
there shouldn't be anything too dependent on the particular boards/chips
that are currently supported out-of-the-box, and it should be easier
to add a new board than it used to be.
> I have the 2.2 pre7 from BSE, but there have been a few changes since. ;^)
Hopefully not changes in the board. :-)
That kernel should still work for extracting any knowledge about the
board's hardware that may or may not be clear from its documentation.
> It appears the image (bootwrapper) needs to be completely self-contained,
> and needs to understand how to read the flash parameters. That's on my
> list.
What firmware is on the board?
-Scott
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BSE-IP
2010-01-26 22:17 ` BSE-IP Scott Wood
@ 2010-01-26 23:28 ` Dan.Geer
0 siblings, 0 replies; 9+ messages in thread
From: Dan.Geer @ 2010-01-26 23:28 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
> > I have the 2.2 pre7 from BSE, but there have been a few changes
since. ;^)
>
> Hopefully not changes in the board. :-)
Hardware is standard.
> That kernel should still work for extracting any knowledge about the
> board's hardware that may or may not be clear from its documentation.
Yeah, I have some more homework todo. I've looked at the device tree
documentation (I think you wrote) and will be getting to that.
> > It appears the image (bootwrapper) needs to be completely
self-contained,
> > and needs to understand how to read the flash parameters. That's on my
> > list.
>
> What firmware is on the board?
Great question! I have no idea! BSE has some specific factory bootstrap.
It supports tftp, fsets, fgets, and a go <address>... it's blackbox from
there to the kernel start. BSE supplied a bootlo.bin file in their build
chain, but I haven't figured out the source yet. It unzips the kernel,
ramdisk, and supplies the old bd_info pointer to the kernel as it bounces
into the kernel start. I guess I still have my work cut out for me.
Thanks for the advice!
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BSE-IP
@ 2010-02-01 18:08 Dan.Geer
2010-02-01 18:24 ` BSE-IP Scott Wood
0 siblings, 1 reply; 9+ messages in thread
From: Dan.Geer @ 2010-02-01 18:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
I'm hoping someone can offer some advice on this:
I'm working with an embedded platform that does not pass anything from
firmware. I'm just trying to get some activity out the serial console at
this stage. simpleImage.bseip compiled with the following bseip.dts seems
to freeze before anything is written to the console. I'm assuming the
standard 8xx code will pickup this device tree, and work from there. Is
this correct? Shouldn't I see some output?
/dts-v1/;
/ {
model = "BSEIP";
compatible = "fsl,bseip";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,823@0 {
compatible = "PowerPC,8xx";
device_type = "cpu";
reg = <0x0>;
d-cache-line-size = <8>; // 8 bytes
per line
i-cache-line-size = <8>; // 8 bytes
per line
d-cache-size = <0x0400>; // L1, 1K
i-cache-size = <0x0800>; // L1, 2K
timebase-frequency = <48000000>;
bus-frequency = <48000000>;
clock-frequency = <48000000>;
interrupts = <15 2>;
// decrementer interrupt
interrupt-parent = <&PIC>;
};
};
memory {
device_type = "memory";
reg = <0 0x1000000>;
};
soc@ff000000 {
compatible = "fsl,mpc823", "fsl,pq1-soc";
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
ranges = <0 0xff000000 0x00004000>;
reg = <0xff000000 0x4000>;
bus-frequency = <48000000>;
PIC: interrupt-controller@0 {
interrupt-controller;
#interrupt-cells = <2>;
reg = <0 0x24>;
compatible = "fsl,mpc823-pic",
"fsl,pq1-pic";
};
pcmcia@80 {
#address-cells = <3>;
#interrupt-cells = <1>;
#size-cells = <2>;
compatible = "fsl,pq-pcmcia";
device_type = "pcmcia";
reg = <0x80 0x80>;
interrupt-parent = <&PIC>;
interrupts = <13 1>;
};
cpm@9c0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc823-cpm",
"fsl,cpm1";
command-proc = <0x9c0>;
interrupts = <0>; // cpm error
interrupt
interrupt-parent = <&CPM_PIC>;
reg = <0x9c0 0x40>;
ranges;
muram@2000 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x2000
0x2000>;
data@0 {
compatible =
"fsl,cpm-muram-data";
reg = <0
0x1c00>;
};
};
brg@9f0 {
compatible =
"fsl,mpc823-brg",
"fsl,cpm1-brg",
"fsl,cpm-brg";
reg = <0x9f0 0x10>;
clock-frequency =
<48000000>;
};
CPM_PIC: interrupt-controller@930 {
interrupt-controller;
#interrupt-cells = <1>;
interrupts = <5 2 0 2>;
interrupt-parent = <&PIC>;
reg = <0x930 0x20>;
compatible =
"fsl,mpc823-cpm-pic",
"fsl,cpm1-pic";
};
serial@a80 {
device_type = "serial";
compatible =
"fsl,mpc823-smc-uart",
"fsl,cpm1-smc-uart";
reg = <0xa80 0x10 0x3e80
0x40>;
interrupts = <4>;
interrupt-parent =
<&CPM_PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x90>;
current-speed = <9600>;
};
serial@a90 {
device_type = "serial";
compatible =
"fsl,mpc823-smc-uart",
"fsl,cpm1-smc-uart";
reg = <0xa90 0x10 0x3f80
0x40>;
interrupts = <3>;
interrupt-parent =
<&CPM_PIC>;
fsl,cpm-brg = <2>;
fsl,cpm-command = <0xd0>;
current-speed = <9600>;
};
ethernet@a20 {
device_type = "network";
compatible =
"fsl,mpc823-scc-enet",
"fsl,cpm1-scc-enet";
reg = <0xa20 0x18 0x3c00
0x100>;
local-mac-address = [ 00
00 00 00 00 00 ];
interrupts = <30>;
interrupt-parent =
<&CPM_PIC>;
fsl,cpm-command = <0x80>;
linux,network-index = <1>;
};
};
};
chosen {
linux,stdout-path = "/soc/cpm/serial@a80";
};
};
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: BSE-IP
2010-02-01 18:08 BSE-IP Dan.Geer
@ 2010-02-01 18:24 ` Scott Wood
2010-02-01 18:59 ` BSE-IP Dan.Geer
0 siblings, 1 reply; 9+ messages in thread
From: Scott Wood @ 2010-02-01 18:24 UTC (permalink / raw)
To: Dan.Geer; +Cc: linuxppc-dev
Dan.Geer@faa.gov wrote:
> I'm hoping someone can offer some advice on this:
>
> I'm working with an embedded platform that does not pass anything from
> firmware. I'm just trying to get some activity out the serial console at
> this stage. simpleImage.bseip compiled with the following bseip.dts seems
> to freeze before anything is written to the console. I'm assuming the
> standard 8xx code will pickup this device tree, and work from there. Is
> this correct? Shouldn't I see some output?
Has your firmware already set up the serial port? cpm-serial doesn't make
assumptions about specific addresses, but it does assume that the BRG, pins,
etc. have been set up for the serial port to work.
If this isn't the case, you'll need to do it from a custom bootwrapper platform
file.
> d-cache-line-size = <8>; // 8 bytes
> per line
> i-cache-line-size = <8>; // 8 bytes
> per line
Shouldn't this be 16 bytes?
> soc@ff000000 {
Is this the correct IMMR address for your firmware?
-Scott
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: BSE-IP
2010-02-01 18:24 ` BSE-IP Scott Wood
@ 2010-02-01 18:59 ` Dan.Geer
2010-02-01 19:06 ` BSE-IP Scott Wood
0 siblings, 1 reply; 9+ messages in thread
From: Dan.Geer @ 2010-02-01 18:59 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
> Has your firmware already set up the serial port? cpm-serial doesn't
make
> assumptions about specific addresses, but it does assume that the BRG,
pins,
> etc. have been set up for the serial port to work.
Yes. Or, so I thought. First, I interrupt the bootstrap with <Esc>. Then,
I load the image into RAM with 'load simpleImage.bseip 200000' then 'go
200000'. All of which is echo'd out the serial console by the firmware.
I assumed that the low-level setups were complete. However, in the old
ppc/boot/m8xx_tty.c there is some initialization for SMC1 and the BRG
(serial_init()). Where should I do this in the new model? Is
platform_specific_init() the right place?
> If this isn't the case, you'll need to do it from a custom bootwrapper
platform
> file.
>
> > d-cache-line-size = <8>; //
8 bytes
> > per line
> > i-cache-line-size = <8>; //
8 bytes
> > per line
>
> Shouldn't this be 16 bytes?
Thanks! I read "4 word boundary" in the manual, and assumed 16bit words.
I fixed this, but same results. I think I have a little more init work
todo.
> > soc@ff000000 {
>
> Is this the correct IMMR address for your firmware?
Yes, this is the correct IMMR address.
Thanks for your help!
Dan
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: BSE-IP
2010-02-01 18:59 ` BSE-IP Dan.Geer
@ 2010-02-01 19:06 ` Scott Wood
0 siblings, 0 replies; 9+ messages in thread
From: Scott Wood @ 2010-02-01 19:06 UTC (permalink / raw)
To: Dan.Geer; +Cc: linuxppc-dev
Dan.Geer@faa.gov wrote:
>> Has your firmware already set up the serial port? cpm-serial doesn't
> make
>> assumptions about specific addresses, but it does assume that the BRG,
> pins,
>> etc. have been set up for the serial port to work.
>
> Yes. Or, so I thought. First, I interrupt the bootstrap with <Esc>. Then,
> I load the image into RAM with 'load simpleImage.bseip 200000' then 'go
> 200000'. All of which is echo'd out the serial console by the firmware.
> I assumed that the low-level setups were complete. However, in the old
> ppc/boot/m8xx_tty.c there is some initialization for SMC1 and the BRG
> (serial_init()). Where should I do this in the new model? Is
> platform_specific_init() the right place?
That'd be the place -- though it's also possible that it is already set up and
the old code simply didn't assume it, and the problem is somewhere else.
If you don't have an external debugger, you may want to dump some registers from
the firmware prompt and determine where it set up the tx ring, and use that for
early debugging.
-Scott
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-02-01 19:07 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-26 20:30 BSE-IP Dan.Geer
2010-01-26 21:03 ` BSE-IP Scott Wood
2010-01-26 22:04 ` BSE-IP Dan.Geer
2010-01-26 22:17 ` BSE-IP Scott Wood
2010-01-26 23:28 ` BSE-IP Dan.Geer
-- strict thread matches above, loose matches on Subject: below --
2010-02-01 18:08 BSE-IP Dan.Geer
2010-02-01 18:24 ` BSE-IP Scott Wood
2010-02-01 18:59 ` BSE-IP Dan.Geer
2010-02-01 19:06 ` BSE-IP Scott Wood
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).