MPC82xx -- DPRAM1

MPC82xx -- DPRAM1

[morten.banzon]

Hi,

I am using 2.6.9 for a mpc8280 project, and am having trouble using dpram1 
from offset zero, which I need for a mcc hdlc driver.

 In the file include/asm-ppc/cpm2.h there is a constant CPM_DATAONLY_BASE
In the same file the code comment say that the first 128 bytes are used 
for SMC1 and SMC2. 

When I examine the smc (cpm_uart) driver i do not find any reference to 
this region of the dpram1.
I have replaced the calls to cpm_dpalloc with cpm_dpalloc_fixed and an 
adress way up in the dpram1 region.

My question is; do you know which code is using the dpram1 addresses below 
CPM_DATAONLY_BASE ?

This region must be used by something (smc ?), because when I clear from 
offset 0x00 to 0x80 the serial port stop responding.
I can ssh to the device and things seems to be normal util I try to reboot 
the system, whereupon everything hangs.

I am stuck, so if you have any suggestions, please advice.


Regards,
Morten

Re: MPC82xx -- DPRAM1

[Dan Malek]

On Nov 15, 2004, at 11:10 AM, morten.banzon@axxessit.no wrote:

> I am using 2.6.9 for a mpc8280 project, and am having trouble using 
> dpram1
> from offset zero, which I need for a mcc hdlc driver.

Why does it have to start at zero?

>  In the file include/asm-ppc/cpm2.h there is a constant 
> CPM_DATAONLY_BASE
> In the same file the code comment say that the first 128 bytes are used
> for SMC1 and SMC2.

Yes, it is.

> When I examine the smc (cpm_uart) driver i do not find any reference to
> this region of the dpram1.

It's there somewhere, hardcoded with values 0, then sizeof() something 
is
probably added to it.

> I have replaced the calls to cpm_dpalloc with cpm_dpalloc_fixed and an
> adress way up in the dpram1 region.

Very bad idea.

> My question is; do you know which code is using the dpram1 addresses 
> below
> CPM_DATAONLY_BASE ?

The SMC1 and SMC2 peripherals, just like the comment says.

> This region must be used by something (smc ?), because when I clear 
> from
> offset 0x00 to 0x80 the serial port stop responding.

Yep.


	-- Dan

Re: MPC82xx -- DPRAM1

[Conor McLoughlin]

Dan Malek wrote:
> 
> On Nov 15, 2004, at 11:10 AM, morten.banzon@axxessit.no wrote:
> 
>> I am using 2.6.9 for a mpc8280 project, and am having trouble using 
>> dpram1
>> from offset zero, which I need for a mcc hdlc driver.
> 
> 
> Why does it have to start at zero?

Because the MCC uses a fixed area of dpram.
MCC1 uses dpram starting at 0.
MCC2 uses dpram starting at 0x2000.

---Conor

Re: MPC82xx -- DPRAM1

[morten.banzon]

Dan Malek <dan@embeddededge.com>
16.11.2004 01:18

 
        To:     morten.banzon@axxessit.no
        cc:     linuxppc-embedded@ozlabs.org
        Subject:        Re: MPC82xx -- DPRAM1



On Nov 15, 2004, at 11:10 AM, morten.banzon@axxessit.no wrote:

>> I am using 2.6.9 for a mpc8280 project, and am having trouble using 
>> dpram1
>> from offset zero, which I need for a mcc hdlc driver.

>Why does it have to start at zero?

When using the mccs the use of dpram1 addresses is determined by the
channel number one choose for the mcc channels. The freedom of choosing
channel numbers are somewhat limited by the mcc hardware. In short if
one have a lot of superchannels, i.e. channels with more than one
time time slot, then legal channel numbers are consumed rapidly.

In my case, I have got 48 super channels, 32 consisting of 3 time slots
and 16 consisting of 9 timeslots, spread over four tdm lines and the two
mccs. In case of mcc1 the first super channel is given the number 0,
hence the need to start at dpram1 address zero. There might be room in
my channel map to increase the lowest channel numbers to get above the
128 first bytes of the dpram1, but I think I just run into trouble
elsewhere.

>>  In the file include/asm-ppc/cpm2.h there is a constant 
>> CPM_DATAONLY_BASE
>> In the same file the code comment say that the first 128 bytes are used
>> for SMC1 and SMC2.

>Yes, it is.
Do you know what these bytes are used for ? As far as I understand it is
not buffer descriptors and not the buffers. Besides these two things I
do not know of anything related to smc that could be put in the dpram1.
Obviously there is something I miss here, and thats the reason for
asking the question in the first place.

>> When I examine the smc (cpm_uart) driver i do not find any reference to
>> this region of the dpram1.

>It's there somewhere, hardcoded with values 0, then sizeof() something 
>is
>probably added to it.
Well, I do not find this piece of code. The buffer descriptors are
allocated with cpm_dpalloc in cpm_uart_allocbuf (cpm_uart_cpm2.c), the
buffers are allocated with alloc_bootmem. The first is ofcourse in dpram1
and the latter is allocated from main memory. Other access to the dpram1
could be through im_dprambase, im_dpram1, or DPRAM_BASE (besides 
hard coding). Checking the use of these, I conclude that they are only
used to access memory regions in dpram2 or dpram3.

>> I have replaced the calls to cpm_dpalloc with cpm_dpalloc_fixed and an
>> adress way up in the dpram1 region.

>Very bad idea.
Why is this a bad idea ? Assuming that the region of dpram1 that is 
managed
by the cpm_dpxxxx functions is free, there is as far as I can see 
absolutely
no problem of allocating the buffer descriptors elswhere within dpram1.
As the code is now (running on my hardware), the buffer descriptors for 
smc1
are allocated from 0x80 to 0xC0, this according to cpm_dpdump(). 

nfo @0xc023e6d0 (13 slots empty / 16 max)
  Free:
    0x000000e0-0x00004000 (16160)

  Taken:
    0x00000080-0x000000c0 (64) commproc
    0x000000c0-0x000000e0 (32) commproc

By using cpm_dpalloc_fixed, I have move these up to 0x3300 and so far not
detected any problems.

>> My question is; do you know which code is using the dpram1 addresses 
>> below
>> CPM_DATAONLY_BASE ?

>The SMC1 and SMC2 peripherals, just like the comment says.
I believe the smcs uses this area, but I do not understand what those 128
bytes are used for. Something related to smc is put there, and I would 
like
to understand what that something is, and then move it out of there.

>> This region must be used by something (smc ?), because when I clear 
>> from
>> offset 0x00 to 0x80 the serial port stop responding.

>Yep.

I am still stuck on this issue so any help is very much apreciated.

Regards,
Morten

Re: MPC82xx -- DPRAM1

[morten.banzon]

I am not sure if I understand you. The CPM must have been told somehow 
that there is something for its peripherals in this particular region of 
the dpram1 or no ? I wild guess could be that the bootloader (in this case 
u-boot) has configured this area of dpram1 behind the back of the kernel. 
I assume that is not the case. Would not that be rather ugly ?
 
The mcc driver I am trying to get running on linux-2.6.9 is a driver I 
wrote for pSos a few years ago, and it is running fine on that platform.
Therefore, I am sure that there is nothing i the processor or the cpm that 
prevents me from putting mcc related parameters at offset zero in the 
dpram1.
I am still trying to figure out what piece of code in the kernel that I 
have to manipulate to get this driver working. 

Thanks for any advise,
Morten





"Mark Chambers" <markc@mail.com>
16.11.2004 04:43

 
        To:     <morten.banzon@axxessit.no>
        cc: 
        Subject:        Re: MPC82xx -- DPRAM1


The thing you might be missing is that the CPM coprocessor uses some dpram
that
is not accessed by the PPC processor at all.  So the memory must be set
aside for
the peripherals but the linux code won't reference it.

Mark Chambers

----- Original Message ----- 
From: "Dan Malek" <dan@embeddededge.com>
To: <morten.banzon@axxessit.no>
Cc: <linuxppc-embedded@ozlabs.org>
Sent: Monday, November 15, 2004 7:18 PM
Subject: Re: MPC82xx -- DPRAM1


>
> On Nov 15, 2004, at 11:10 AM, morten.banzon@axxessit.no wrote:
>
> > I am using 2.6.9 for a mpc8280 project, and am having trouble using
> > dpram1
> > from offset zero, which I need for a mcc hdlc driver.
>
> Why does it have to start at zero?
>
> >  In the file include/asm-ppc/cpm2.h there is a constant
> > CPM_DATAONLY_BASE
> > In the same file the code comment say that the first 128 bytes are 
used
> > for SMC1 and SMC2.
>
> Yes, it is.
>
> > When I examine the smc (cpm_uart) driver i do not find any reference 
to
> > this region of the dpram1.
>
> It's there somewhere, hardcoded with values 0, then sizeof() something
> is
> probably added to it.
>
> > I have replaced the calls to cpm_dpalloc with cpm_dpalloc_fixed and an
> > adress way up in the dpram1 region.
>
> Very bad idea.
>
> > My question is; do you know which code is using the dpram1 addresses
> > below
> > CPM_DATAONLY_BASE ?
>
> The SMC1 and SMC2 peripherals, just like the comment says.
>
> > This region must be used by something (smc ?), because when I clear
> > from
> > offset 0x00 to 0x80 the serial port stop responding.
>
> Yep.
>
>
> -- Dan
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

RE: MPC82xx -- DPRAM1

[Rune Torgersen]

Check the drivers/serial/cpm_uart stuff.
In older kernels (before the uart move, ie 2.6.7) the start of dpram was
taken by the initial SCC/SMC driver for initial console output before
the full CPM drivers were initialized. The addresses were hardcoded
because the driver was initialized before the dpalloc functions were
initailized.

There might be some left over from that. Look for anything getting set
to cpm2_immr->im_dprambase[0]


> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> morten.banzon@axxessit.no
> Sent: Tuesday, November 16, 2004 05:17
> To: Mark Chambers
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC82xx -- DPRAM1
>=20
>=20
> I am not sure if I understand you. The CPM must have been=20
> told somehow=20
> that there is something for its peripherals in this=20
> particular region of=20
> the dpram1 or no ? I wild guess could be that the bootloader=20
> (in this case=20
> u-boot) has configured this area of dpram1 behind the back of=20
> the kernel.=20
> I assume that is not the case. Would not that be rather ugly ?
> =20
> The mcc driver I am trying to get running on linux-2.6.9 is a=20
> driver I=20
> wrote for pSos a few years ago, and it is running fine on=20
> that platform. Therefore, I am sure that there is nothing i=20
> the processor or the cpm that=20
> prevents me from putting mcc related parameters at offset zero in the=20
> dpram1.
> I am still trying to figure out what piece of code in the=20
> kernel that I=20
> have to manipulate to get this driver working.=20
>=20
> Thanks for any advise,
> Morten

RE: MPC82xx -- DPRAM1

[morten.banzon]

OK, I get i now.
The first 128 bytes of dpram1 contains  pointers to the smc buffer 
descriptor table, which again points to the buffer descriptor bases.
It is the SMC1_BASE@0x87FC(dpram2)  and the SMC2_BASE@0x88FC(dpram2) which 

points to these addresses.
This is configured in include/asm-ppc/cpm2.h with the two constants 
PROFF_SMC1 and PROFF_SMC2.

I will try to move all smc related data out of the dpram1 regions that I 
need for mcc and see if I can avoid killing the smc.

Does anyone know if there is any trouble movig the smc around within 
drpam1 ?
I guess it must have been done by several users of linux on mpc82xx.

-- Morten






"Rune Torgersen" <runet@innovsys.com>
16.11.2004 15:58

 
        To:     <morten.banzon@axxessit.no>
        cc:     <linuxppc-embedded@ozlabs.org>
        Subject:        RE: MPC82xx -- DPRAM1


Check the drivers/serial/cpm_uart stuff.
In older kernels (before the uart move, ie 2.6.7) the start of dpram was
taken by the initial SCC/SMC driver for initial console output before
the full CPM drivers were initialized. The addresses were hardcoded
because the driver was initialized before the dpalloc functions were
initailized.

There might be some left over from that. Look for anything getting set
to cpm2_immr->im_dprambase[0]


> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org 
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of 
> morten.banzon@axxessit.no
> Sent: Tuesday, November 16, 2004 05:17
> To: Mark Chambers
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC82xx -- DPRAM1
> 
> 
> I am not sure if I understand you. The CPM must have been 
> told somehow 
> that there is something for its peripherals in this 
> particular region of 
> the dpram1 or no ? I wild guess could be that the bootloader 
> (in this case 
> u-boot) has configured this area of dpram1 behind the back of 
> the kernel. 
> I assume that is not the case. Would not that be rather ugly ?
> 
> The mcc driver I am trying to get running on linux-2.6.9 is a 
> driver I 
> wrote for pSos a few years ago, and it is running fine on 
> that platform. Therefore, I am sure that there is nothing i 
> the processor or the cpm that 
> prevents me from putting mcc related parameters at offset zero in the 
> dpram1.
> I am still trying to figure out what piece of code in the 
> kernel that I 
> have to manipulate to get this driver working. 
> 
> Thanks for any advise,
> Morten

RE: MPC82xx -- DPRAM1

[morten.banzon]

No I still do not get this.

The constant PROFF_SMC1_BASE is as far as I can see never used, only 
defined. Hence, the cpm or the smc will never be told by the kernel that 
there are pointers to the buffer descriptor tables located at PROFF_SMC1 
(offset zero) and PROFF_SMC2 (offset 64). Either I am blind or the kernel 
performs magic if this happens.

If this is right whys does the smc driver work? Because the bootloader I 
use, by coincidece (?), use the same configuration as the smc driver in 
the kernel.

Just to verify this connection, I move PROFF_SMC1 to offset 64 and 
PROFF_SMC2 to offset 128 in the kernel code, and increase 
CPM_DATAONLY_SIZE to 192. The way I understand the kernel code, this is 
all it takes to manipulate the location of smc related data which are 
located in the dpram1. Well, booting this kernel on the target platform 
casuse the smc to die, ie. after the
 ## Transfering control to Linux 
message from u-boot, the console is dead.
If I modify the u-boot with the same smc chages it works perfectly again.

Is this intentional; that the kernel is dependent on a specific 
configuration by the bootloader to make the smc driver work ?
If this is the intention, it is fine by me. If not then there is a bug in 
the smc driver (cpm_uart).
Is there anyone readig this list that confirm that this behaviour is right 
or wrong ?

-- Morten





morten.banzon@axxessit.no
Sent by: linuxppc-embedded-bounces@ozlabs.org
16.11.2004 16:07

 
        To:     "Rune Torgersen" <runet@innovsys.com>
        cc:     linuxppc-embedded@ozlabs.org
        Subject:        RE: MPC82xx -- DPRAM1


OK, I get i now.
The first 128 bytes of dpram1 contains  pointers to the smc buffer 
descriptor table, which again points to the buffer descriptor bases.
It is the SMC1_BASE@0x87FC(dpram2)  and the SMC2_BASE@0x88FC(dpram2) which 


points to these addresses.
This is configured in include/asm-ppc/cpm2.h with the two constants 
PROFF_SMC1 and PROFF_SMC2.

I will try to move all smc related data out of the dpram1 regions that I 
need for mcc and see if I can avoid killing the smc.

Does anyone know if there is any trouble movig the smc around within 
drpam1 ?
I guess it must have been done by several users of linux on mpc82xx.

-- Morten






"Rune Torgersen" <runet@innovsys.com>
16.11.2004 15:58

 
        To:     <morten.banzon@axxessit.no>
        cc:     <linuxppc-embedded@ozlabs.org>
        Subject:        RE: MPC82xx -- DPRAM1


Check the drivers/serial/cpm_uart stuff.
In older kernels (before the uart move, ie 2.6.7) the start of dpram was
taken by the initial SCC/SMC driver for initial console output before
the full CPM drivers were initialized. The addresses were hardcoded
because the driver was initialized before the dpalloc functions were
initailized.

There might be some left over from that. Look for anything getting set
to cpm2_immr->im_dprambase[0]


> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org 
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of 
> morten.banzon@axxessit.no
> Sent: Tuesday, November 16, 2004 05:17
> To: Mark Chambers
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MPC82xx -- DPRAM1
> 
> 
> I am not sure if I understand you. The CPM must have been 
> told somehow 
> that there is something for its peripherals in this 
> particular region of 
> the dpram1 or no ? I wild guess could be that the bootloader 
> (in this case 
> u-boot) has configured this area of dpram1 behind the back of 
> the kernel. 
> I assume that is not the case. Would not that be rather ugly ?
> 
> The mcc driver I am trying to get running on linux-2.6.9 is a 
> driver I 
> wrote for pSos a few years ago, and it is running fine on 
> that platform. Therefore, I am sure that there is nothing i 
> the processor or the cpm that 
> prevents me from putting mcc related parameters at offset zero in the 
> dpram1.
> I am still trying to figure out what piece of code in the 
> kernel that I 
> have to manipulate to get this driver working. 
> 
> Thanks for any advise,
> Morten



_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MPC82xx -- DPRAM1

[morten.banzon]

Andy Fleming <afleming@freescale.com>
17.11.2004 16:08

 
        To:     <morten.banzon@axxessit.no>
        cc: 
        Subject:        Re: MPC82xx -- DPRAM1



On Nov 17, 2004, at 06:11, <morten.banzon@axxessit.no> wrote:

>> No I still do not get this.
>>
>> The constant PROFF_SMC1_BASE is as far as I can see never used, only
>> defined. Hence, the cpm or the smc will never be told by the kernel 
>> that
>> there are pointers to the buffer descriptor tables located at 
>> PROFF_SMC1
>> (offset zero) and PROFF_SMC2 (offset 64). Either I am blind or the 
>> kernel
>> performs magic if this happens.

>Look in arch/ppc/boot/simple/m8260_tty.c

>This code, from what I can tell, is called early in boot to set up the 
>boot console.  I haven't read the file very carefully, but I suspect, 
>from what Dan Malek said, that this file sets up the CPM to point the 
>SMCs at that area of dpram.

Thanks for your reply.

I have seen the code you are refering to. After compiling the kernel
the arch/ppc/boot/simple directory contain no object files at all.
Hence, I assumed that none of these files were compiled.
To be asolutely sure I have removed the whole directory, and things
work just fine. Which I take as a proof that nothing in the simple
directory is involved in the configuration of smc1 as a console uart.

I believe that there are only two file involved in configuring the
cpm uart on a mpc82xx platform, namely:
drivers/serial/cpm_uart/cpm_uart_cpm2.c
drivers/serial/cpm_uart/cpm_uart_core.c

None of these files modify the offset addresses 0x87FC (smc1) and
0x88FC(smc2) in the dpram2. Well, at least as far as I can tell.
Hence, I believe the only reason why the cpm_uart driver in the kernel
works, is because the u-boot bootloader does such a fine job.

This might be intentional, I do not know but are seeking
enlightenment.

-- Morten

Re: MPC82xx -- DPRAM1

[morten.banzon]

Thanks again for your reply to my queries.

I did not know that arch/ppc/boot stuff and u-boot were mutually 
exclusive. Thanks for clarifying that.
In fact I have not been considering what is left out when you make a 
uImage as opposed to zImage, obviously I have som styding to do here.

I do not understand all the intricacies of what happens regarding hardware 
configuration during the eraly stages of booting linux, but I conclude 
that when making a uImage one have to modify u-boot and the kernel if one 
want to relocate the usage of dpram1 by the cpm uart driver. This might 
have been obvious to most of you, but I was lost on this issue.

A mystery is why Dan Malek said it was a "very bad idea" to relocate the 
smc buffer descriptors to anohter part of dpram1.
Maybe I will understand that one day too.

Thanks again for your help Mark.

-- Morten






"Mark Chambers" <markc@mail.com>
17.11.2004 17:37

 
        To:     <morten.banzon@axxessit.no>
        cc: 
        Subject:        Re: MPC82xx -- DPRAM1


Well, but the arch/ppc/boot stuff and u-boot are mutually exclusive, 
right?
The arch/ppc/boot takes the kernel binary and wraps it in a very simple
bootloader.  So it depends on your make options whether that code gets
compiled or not.  So I think you've solved the mystery, that indeed the
bootloader sets up the SMCs to use that dpram memory.  I guess the
philosophical question is, should it be left that way or not.

Mark Chambers

>
> >> No I still do not get this.
> >>
> >> The constant PROFF_SMC1_BASE is as far as I can see never used, only
> >> defined. Hence, the cpm or the smc will never be told by the kernel
> >> that
> >> there are pointers to the buffer descriptor tables located at
> >> PROFF_SMC1
> >> (offset zero) and PROFF_SMC2 (offset 64). Either I am blind or the
> >> kernel
> >> performs magic if this happens.
>
> >Look in arch/ppc/boot/simple/m8260_tty.c
>
> >This code, from what I can tell, is called early in boot to set up the
> >boot console.  I haven't read the file very carefully, but I suspect,
> >from what Dan Malek said, that this file sets up the CPM to point the
> >SMCs at that area of dpram.
>
> Thanks for your reply.
>
> I have seen the code you are refering to. After compiling the kernel
> the arch/ppc/boot/simple directory contain no object files at all.
> Hence, I assumed that none of these files were compiled.
> To be asolutely sure I have removed the whole directory, and things
> work just fine. Which I take as a proof that nothing in the simple
> directory is involved in the configuration of smc1 as a console uart.
>
> I believe that there are only two file involved in configuring the
> cpm uart on a mpc82xx platform, namely:
> drivers/serial/cpm_uart/cpm_uart_cpm2.c
> drivers/serial/cpm_uart/cpm_uart_core.c
>
> None of these files modify the offset addresses 0x87FC (smc1) and
> 0x88FC(smc2) in the dpram2. Well, at least as far as I can tell.
> Hence, I believe the only reason why the cpm_uart driver in the kernel
> works, is because the u-boot bootloader does such a fine job.
>
> This might be intentional, I do not know but are seeking
> enlightenment.
>
> -- Morten
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: MPC82xx -- DPRAM1

[Wolfgang Denk]

In message <OFD0B78DE0.9222EE0F-ONC1256F50.003811B2-C1256F50.003B80FF@axxessit.no> you wrote:
> 
> I do not understand all the intricacies of what happens regarding hardware 
> configuration during the eraly stages of booting linux, but I conclude 
> that when making a uImage one have to modify u-boot and the kernel if one 
> want to relocate the usage of dpram1 by the cpm uart driver. This might 
> have been obvious to most of you, but I was lost on this issue.

There is no need to modify U-Boot nor  the  kernel.  Each  driver  is
supposed to perform all required initialization steps itself. It must
not  make  any assumptions about it's previous state except that it's
"harmless", i. e. interrupts are disabled etc.  when  the  driver  is
starting.

> A mystery is why Dan Malek said it was a "very bad idea" to relocate the 
> smc buffer descriptors to anohter part of dpram1.
> Maybe I will understand that one day too.

Read the code.

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
Vulcans believe peace should not depend on force.
	-- Amanda, "Journey to Babel", stardate 3842.3

Re: MPC82xx -- DPRAM1

[morten.banzon]

By modifying the kernel I meant modifying the cpm uart driver. If that was 
not clear I appologise.
I do not how much of this thread you have been reading, but if you know of 
a way to relocate the resources in the dpram1 used by the cpm uart (smc1 
in this case) other than what is suggested in the previous mail I am eager 
to hear from you.

 Since the contents of the arch/ppc/boot are not compiled, and certainly 
not the arch/ppc/boot/simple/m8260_tty.c, then there is absolutely no code 
in cpm_uart_core.c or cpm_uart_cpm2.c that configure the SMC1_BASE 
register, or the SMC2_BASE register for that matter,  found at offset 
0x87FC and 0x88FC respectively. Hence, there is no way for the cpm/smc 
hardware to know were to look for the buffer descriptor tables, hence 
there is no wayt to get a working console on the smc1 unless the 
bootloader configure this identical to what the cpm uart driver within the 
kernel expect. I think I have proven that too by first changing the 
necessary constants in arch/asm-ppc/cpm2.h, which causes the console to 
die as soon as the linux kernel take over control after the bootloader. 
Modifying the u-boot to reflect the modifications done in cpm2.h make the 
whole thing work nicely again.

I agree with you that each driver is supposed to perform all required 
initialization steps itself, but that is not the case for the cpm_uart smc 
driver. This driver consists as far as I can see of two files; 
cpm_uart_cpm2.c and cpm_uart_core.c, and the header files. I might be 
wrong ofcourse claiming that this driver is not able to get off the ground 
without help from a bootloader, and any such explaninations are most 
welcome. I sincerely want to understand this.

Your "Read the code" commet is the best answer to these queries I have 
seen so far. I guess you and Dan Malek understand something that is not 
possible to read from the code. Well, I have relocated both the first 128 
bytes of the dpram1 and the buffer descriptors for the smc1 driver. 
Similar thing is done wiht the i2c driver and so far, just for a few hours 
though, they are working happily.

If you know the reason to why it is "a very bad idea" to relocate these 
resources within dpram1 I am very curious to learn. On the other hand if 
you do not know, then please refrain from giving such a stupid answer.

-- Morten






Wolfgang Denk <wd@denx.de>
Sent by: wd@denx.de
18.11.2004 18:38

 
        To:     morten.banzon@axxessit.no
        cc:     linuxppc-embedded@ozlabs.org
        Subject:        Re: MPC82xx -- DPRAM1


In message 
<OFD0B78DE0.9222EE0F-ONC1256F50.003811B2-C1256F50.003B80FF@axxessit.no> 
you wrote:
> 
> I do not understand all the intricacies of what happens regarding 
hardware 
> configuration during the eraly stages of booting linux, but I conclude 
> that when making a uImage one have to modify u-boot and the kernel if 
one 
> want to relocate the usage of dpram1 by the cpm uart driver. This might 
> have been obvious to most of you, but I was lost on this issue.

There is no need to modify U-Boot nor  the  kernel.  Each  driver  is
supposed to perform all required initialization steps itself. It must
not  make  any assumptions about it's previous state except that it's
"harmless", i. e. interrupts are disabled etc.  when  the  driver  is
starting.

> A mystery is why Dan Malek said it was a "very bad idea" to relocate the 

> smc buffer descriptors to anohter part of dpram1.
> Maybe I will understand that one day too.

Read the code.

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
Vulcans believe peace should not depend on force.
                 -- Amanda, "Journey to Babel", stardate 3842.3

Re: MPC82xx -- DPRAM1

[Dan Malek]

On Nov 18, 2004, at 3:08 PM, morten.banzon@axxessit.no wrote:

> If you know the reason to why it is "a very bad idea" to relocate these
> resources within dpram1 I am very curious to learn. On the other hand 
> if
> you do not know, then please refrain from giving such a stupid answer.

As you have discovered, there are many dependencies on the
configuration of the cpm smc from the boot rom to bootloaders to
the Linux kernel itself.  It's a bad idea to be changing one of these
without changing all of the others to match ....  and then you end
up with a custom piece of software that you have to constantly
maintain.  If you make it configurable, then you end up with even
more confusion when people mismatch the configurations on
a board.

There isn't any reason to change the current SMC buffering configuration
on the CPM2 (and future) devices.  If you like change for the sake
of change, then go ahead and do it.  We answered the questions
you asked and specifically said the changes you were making at
the time weren't a good idea.  Just because you didn't agree
doesn't make it a stupid response, especially since it's pretty easy
to figure out on your own from looking at the code.

Thanks.

	-- Dan

Re: MPC82xx -- DPRAM1

[morten.banzon]

Dan Malek <dan@embeddededge.com>
19.11.2004 00:11

 
        To:     morten.banzon@axxessit.no
        cc:     linuxppc-embedded@ozlabs.org, Wolfgang Denk <wd@denx.de>
        Subject:        Re: MPC82xx -- DPRAM1



On Nov 18, 2004, at 3:08 PM, morten.banzon@axxessit.no wrote:

> > If you know the reason to why it is "a very bad idea" to relocate 
these
> > resources within dpram1 I am very curious to learn. On the other hand 
> > if
> > you do not know, then please refrain from giving such a stupid answer.

> As you have discovered, there are many dependencies on the
> configuration of the cpm smc from the boot rom to bootloaders to
> the Linux kernel itself.  It's a bad idea to be changing one of these
> without changing all of the others to match ....  and then you end
> up with a custom piece of software that you have to constantly
> maintain.  If you make it configurable, then you end up with even
> more confusion when people mismatch the configurations on
> a board.

I aggree with that, I will strive to avoid such changes.

> There isn't any reason to change the current SMC buffering configuration
> on the CPM2 (and future) devices.  If you like change for the sake
> of change, then go ahead and do it.  We answered the questions
> you asked and specifically said the changes you were making at
> the time weren't a good idea.  Just because you didn't agree
> doesn't make it a stupid response, especially since it's pretty easy
> to figure out on your own from looking at the code.

You might be right that there is no reason to change this cofiguration.
I guess you know that no one would change this for the sake of change.
No, you did not answer my questions. Just to recap a few questions and 
answers:

1. I had trouble understanding the use of the CPM_DATAONLY_BASE constant, 
or more precisely what was located at the addresses below 
CPM_DATAONLY_BASE.  It turns out that it is the smc parameter tables that 
are placed there. But the real mystery was how the cpm was told where to 
find these locations.  The end of the story is that the cpm uart driver is 
dependent on this particular configuration (writing these adresses into 
the SMC1_BASE@0x87FC and SMC2_BASE@0x88FC) beeing set-up before being 
loaded. At one point I was asking if this was intentional or not. The 
answer to this I still do not know, but maybe it is not important either.

2. I stated that I relocated the buffer descriptors. This was done by 
replacing cpm_dpalloc with cpm_dpalloc_fixed and an offset adress of my 
choice. Your reply to this was the "very bad idea". Well, on my target I 
can move these buffer descriptors around as I please within the dpram1, 
and the smc1/console just keeps working. I do not say that this is not 
problematic, just that I do not detect any problems neither do I see any 
problems by reading the code. So, why this is a bad idea remains unclear. 
What seems to be a bad idea, or at least a little messy, is  to relocate 
the smc parameter ram located below the first 128 bytes of dpram1.

Now you go on about "just because you didn't agree"? Where did that come 
frome ? Maybe I am expressing myself very unclear, but as far as I know I 
have not disagreed with anything. I am just asking questions and trying to 
understand this peace of the system, and to be frank not many correct 
answers have been provided.

Regarding "stupid response" I am baffled. Wolfgang presents a few very 
clear statement, which are equally clearly wrong regarding this subject, 
the cpm uart driver (smc). Your mail contradicts his mail. I have come to 
the same conclusion as you have summarised in your previous mail. That is 
why I call "read  the code" a stupid answer. I think somebody else should 
take a break and read the code. Besides saying "stupid" about that 
particular answer, I have not called any other answer, suggestion, or 
anything else stupid. I hope we are clear on that.

How you can say it is "pretty easy to figure out on your own from looking 
at the code" I do not get, but that is not important. If you think it is 
easy, that is fine for you. I think I have described the reason why it is 
difficult to understand several times now, just a final point; in terms of 
configuring the smc hardware I think the only thing missing from the 
driver is to setup the now famous SMCx_BASE pointers. This is ofcourse 
possible to do, but there might be good reasons why it is not done. How it 
is supposed to be obvious that some boot code/loader set up these 
particular pointers I disagree with, especially in light of Wolfgang's 
mail.


Have a nice day,
-- Morten

RE: MPC82xx -- DPRAM1

[Rune Torgersen]

> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of=20
> morten.banzon@axxessit.no
> Sent: Thursday, November 18, 2004 20:24
> I think the only thing missing from the=20
> driver is to setup the now famous SMCx_BASE pointers. This is=20
> ofcourse=20
> possible to do, but there might be good reasons why it is not=20
> done.

Send a patch to fix this in the driver. I think most people on this list
would like the seriaql drivers to be totally independent of the
bootloader (no matter what it is).

Re: MPC82xx -- DPRAM1

[Dan Malek]

On Nov 19, 2004, at 9:25 AM, Rune Torgersen wrote:

> Send a patch to fix this in the driver. I think most people on this 
> list
> would like the seriaql drivers to be totally independent of the
> bootloader (no matter what it is).

The serial driver is totally independent of the bootloader.
It configures the SMC from scratch and assumes nothing of
the bootloader.  However, if the bootloader configures itself
as Linux does, then other functions like early kgdb over
serial port work properly.


	-- Dan