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 at denx.de>
Sent by: wd at denx.de
18.11.2004 18:38
To: morten.banzon at axxessit.no
cc: linuxppc-embedded at ozlabs.org
Subject: Re: MPC82xx -- DPRAM1
In message
<OFD0B78DE0.9222EE0F-ONC1256F50.003811B2-C1256F50.003B80FF at 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 at denx.de
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3
