* 答复: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-29 2:13 UTC (permalink / raw)
To: John W. Linville; +Cc: linuxppc-embedded
Dear Linville:
I use the zImage to download to RAM from the vmlinux TFTP. The =
strange thins happened :=20
The serial console print the following message and halted :
"Starting at 0x380000... "
I want to ask:
I. I saw the System.map is starting at the address 0x00000, but why =
the zImage is starting at 0x380000 ?=20
2. "Thankfully, I recall that later kernel versions did not have that =
problem."
I use the ELDK3.1.1, kernel 2.4.25.tar.bz2, Which version had you =
revised the kernel ? 2.6.x ?
If I need the 2.4.25 (for its config file fits the PPC860 ADS), =
What can I do ?=20
3. In the vxworks BSP Makefile :
ROM_TEXT_ADRS =3D 02800100 # ROM entry address
ROM_SIZE =3D 00200000 # number of bytes of ROM space
RAM_LOW_ADRS =3D 00010000 # RAM text/data address
RAM_HIGH_ADRS =3D 00200000 # RAM text/data address
=20
How can I relocate to the right address if I download the linux =
kernel and excute it in RAM?=20
=20
Thanks a lot !
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: John W. Linville [mailto:linville@tuxdriver.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C229=C8=D5 0:58
=CA=D5=BC=FE=C8=CB: FCG WANG Baohua
=D6=F7=CC=E2: Re: How to load a linux kernel under vxworks bootloader =
(PPC860
board)
On Thu, Jul 28, 2005 at 01:02:04PM +0800, FCG WANG Baohua wrote:
> Dear linville:
> I want to boot a linux 2.4.25 kernel under vxworks
> bootloader. When I using flat mode(0x200000 --> 0x10000)
> kernel uncompressed ELF format ( vmlinux ),
> and download it using TFTP of vxworks, it print the "starting
> at 0x1000 ...." and freeze. No input or output on serial port.
> The version of vxworks is 5.3.1.=20
> can you give me some detail advice or give me a tool to slove
> it? thanks !
It looks like Guy Streeter gave you as good advice as I could give.
Be sure to read his post on linuxppc-embedded.
In the past there was an issue in that the VxWorks boot loader only
loaded .text and .data sections from ELF images. At that time,
zImage files packed the "real" kernel image into an extra section
in the ELF file, and the VxWorks loader would not load it. The fix
then was to hack the ELF header to make the extra section appear to
be part of the .data section.
Thankfully, I recall that later kernel versions did not have that
problem. I think using a zImage (or zImage.initrd) file that has
been properly modified to support your board should be all that
is necessary. Using a zImage is necessary because it includes a
"shim" that knows how to communicate critical information to the
actual Linux kernel. The VxWorks boot loader does not provide this
information to Linux.
As someone else suggested, your best bet would be to use U-Boot or some
other loader that understands Linux. U-Boot ports are fairly simple.
If you don't want to do one, you probably could convince me to do
a U-Boot port if you wanted to send me a board (and possibly some
reasonably compensation)... :-)
Good luck!
John
--=20
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Unauthorized transactions on your account
From: security @ 2005-07-29 1:26 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 14005 bytes --]
^ permalink raw reply
* 答复: How to load a linux kernel under vxworks bootloader (PPC860 board)
From: FCG WANG Baohua @ 2005-07-29 8:27 UTC (permalink / raw)
To: John W. Linville; +Cc: linuxppc-embedded
Dear linville:
I found that the vxWorks bootrom is load to RAM 0x2800100 address, but =
different address with the different kernel file downloading to the RAM.
For example: the ppcboot ELF file is downloaded to the 0x2800000 and =
only 150256 bytes is downloaded (total file size is 989064 bytes)
the zImage kernel file is downloaded to the =
0x380000 and only 533004 bytes is downloaded (total file size is 591899 =
bytes)
What's the reason for explain it? Does the vxWorks bootloader =
uncompressed the file with its own algorithm?=20
How to download the U-Boot ELF file correctly? Thanks!=20
The right way is to find the right entry points of U-Boot, but =
whatever I change the configure of U-Boot, it doesn't work at all. That =
is, the entry point is=20
forever 0x2800000 for U-Boot and 0x380000 for zImage.=20
=20
-----=D4=AD=CA=BC=D3=CA=BC=FE-----
=B7=A2=BC=FE=C8=CB: John W. Linville [mailto:linville@tuxdriver.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2005=C4=EA7=D4=C229=C8=D5 0:58
=CA=D5=BC=FE=C8=CB: FCG WANG Baohua
=D6=F7=CC=E2: Re: How to load a linux kernel under vxworks bootloader =
(PPC860
board)
On Thu, Jul 28, 2005 at 01:02:04PM +0800, FCG WANG Baohua wrote:
> Dear linville:
> I want to boot a linux 2.4.25 kernel under vxworks
> bootloader. When I using flat mode(0x200000 --> 0x10000)
> kernel uncompressed ELF format ( vmlinux ),
> and download it using TFTP of vxworks, it print the "starting
> at 0x1000 ...." and freeze. No input or output on serial port.
> The version of vxworks is 5.3.1.=20
> can you give me some detail advice or give me a tool to slove
> it? thanks !
It looks like Guy Streeter gave you as good advice as I could give.
Be sure to read his post on linuxppc-embedded.
In the past there was an issue in that the VxWorks boot loader only
loaded .text and .data sections from ELF images. At that time,
zImage files packed the "real" kernel image into an extra section
in the ELF file, and the VxWorks loader would not load it. The fix
then was to hack the ELF header to make the extra section appear to
be part of the .data section.
Thankfully, I recall that later kernel versions did not have that
problem. I think using a zImage (or zImage.initrd) file that has
been properly modified to support your board should be all that
is necessary. Using a zImage is necessary because it includes a
"shim" that knows how to communicate critical information to the
actual Linux kernel. The VxWorks boot loader does not provide this
information to Linux.
As someone else suggested, your best bet would be to use U-Boot or some
other loader that understands Linux. U-Boot ports are fairly simple.
If you don't want to do one, you probably could convince me to do
a U-Boot port if you wanted to send me a board (and possibly some
reasonably compensation)... :-)
Good luck!
John
--=20
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* ATI Radeon with PPC 440 GX and kernel 2.6.12
From: David Grab @ 2005-07-29 8:32 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
i´m using on my custom board a ATI M6 Mobility Radeon with kernel 2.6.12.
Now i have to initialize the ati and configure the kernel to support it. Did
someone use this combination (ppc + ati radeon)? It would be appreciating to
get some help or tipps in configuring to get the ati functioning. Especially
the BIOS of the ATI chip, because i have actually found only x86 binaries.
Is it also possible to set up the bios settings for the ati chip without an
bios eeprom attached via the radeon driver?
Thanks for any help,
David
^ permalink raw reply
* mpc8245-300M MIPS
From: Debora Liu @ 2005-07-29 10:27 UTC (permalink / raw)
To: linuxppc-embedde
linuxppc-embeddeHi ALL,
I am porting MPC8245 kernel-2.4.25 from ELDK version 3.1.1.
This CPU(MPC8245) is 300MHz, kernel calibrate MIPS is 200.
Do anyone know this MIPS is right?
U-Boot 1.1.2 (Jan 25 2005 - 14:55:00) [svm]
CPU: MPC8245 Revision 1.1 at 299.999 MHz: 16 kB I-Cache 16 kB D-Cache
Board: SVM_SC8245 Local Bus at 99.999 MHz
I2C: ready
DRAM: Scan SDRAM memory........................
64 MB
Top of RAM usable for U-Boot at: 04000000
Reserving 460k for U-Boot at: 03f8c000
Reserving 128k for malloc() at: 03f6c000
Reserving 56 Bytes for Board Info at: 03f6bfc8
Reserving 48 Bytes for Global Data at: 03f6bf98
Stack Pointer at: 03f6bf78
New Stack Pointer is: 03f6bf78
Now running in RAM - U-Boot at: 03f8c000
FLASH: 512 kB
PCI Scan: Found Bus 0, Device 22, Function 0
PCI Config: I/O=0x80000000, Memory=0x80000000, Command=0x7
00 16 10ec 8139 0200 0b
PCI Scan: Found Bus 0, Device 23, Function 0
PCI Config: I/O=0x81000000, Memory=0x81000000, Command=0x7
00 17 8086 1209 0200 0c
PCI Scan: Found Bus 0, Device 24, Function 0
00 18 8086 1209 0200 0e
In: serial
Out: serial
Err: serial
U-Boot relocated to 03f8c000
DOC: No DiskOnChip found
Net: rtl8139: REALTEK RTL8139 @0x80000000(80000000)
i82559#0
Warning: i82559#0 MAC addresses don't match:
Address in SROM is 00:AA:00:91:6D:94
Address in environment is EE:CC:7C:7E:65:97
, i82559#1, RTL8139#0
### main_loop entered: bootdelay=2
### main_loop: bootcmd="tftpboot 0x210000 kernel-sc82xx-2.4.25-eldk;bootm 0x2100
00"
Hit any key to stop autoboot: 0
Trying i82559#0
Using i82559#0 device
TFTP from server 192.168.0.82; our IP address is 192.168.0.215
Filename 'kernel-sc82xx-2.4.25-eldk'.
Load address: 0x210000
Loading: #################################################################
#################################################################
###########
done
Bytes transferred = 718901 (af835 hex)
## Booting image at 00210000 ...
Image Name: Linux-2.4.25
Created: 2005-07-29 5:42:02 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 718837 Bytes = 702 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Current stack ends at 0x03F6BBE8 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF7E
bd address = 0x03F6BFC8
memstart = 0x00000000
memsize = 0x04000000
flashstart = 0xFFF00000
flashsize = 0x00080000
flashoffset = 0x00068000
sramstart = 0x00000000
sramsize = 0x00000000
bootflags = 0x00000001
intfreq = 299.999 MHz
busfreq = 99.999 MHz
ethaddr = EE:CC:7C:7E:65:97
IP addr = 192.168.0.215
baudrate = 115200 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.25 (liu@bighead) (gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9))
#2 ? 7? 29 13:41:52 CST 2005
sc82xx_setup_arch:Reserved 0x10000 memory at 0xc01b4000
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=192.168.0.82:/prj/sc8245/root cons
ole=ttyS0,115200 ip=192.168.0.215:192.168.0.82:::itogether:eth0:off
OpenPIC Version 1.2 (1 CPUs and 7 IRQ sources) at fdfd0000
bi_intfreq:299999997 bi_busfreq:99999999
Calibrating delay loop... 199.88 BogoMIPS
Debora Liu
deboralh@fel.com.cn
2005-07-29
^ permalink raw reply
* Re: request_8xxirq
From: Tiago Dall'Agnol @ 2005-07-29 13:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050729013303.33814.qmail@web40712.mail.yahoo.com>
Hi,
I had some problems with irq in my embedded system. I'm interested in
this function source code, but I didn't find it in my linux distribuction?
Does anyone know where I can find it?
Thanks a lot
Tiago
Manish Joshi wrote:
> Hi,
>
> I am working on an old code which uses request_8xxirq() call which I
> can't find in latest kernel.
> Has this been replaced by something else ?
>
> I see the references on net about replacing request_8xxirq() with
> request_irq(). Can I do it ?
>
> TIA,
> Manish
>
>
> ------------------------------------------------------------------------
> Start your day with Yahoo! - make it your home page
> <http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Tiago Dall'Agnol
Pesquisa e Desenvolvimento
Tel.: +55.51.470.05.64
Fax.: +55.51.470.05.70
e-mail: tdallagnol@parks.com.br
Parks S.A. Comunicações Digitais
www.parks.com.br
^ permalink raw reply
* Re: request_8xxirq
From: Alex Zeffertt @ 2005-07-29 13:40 UTC (permalink / raw)
To: Tiago Dall'Agnol; +Cc: linuxppc-embedded
In-Reply-To: <42EA2A2E.5040708@parks.com.br>
In linux-2.4 it's in
include/asm-ppc/mpc8xx.h
-- snip --
#define request_8xxirq request_irq
--/snip --
And request_irq is in arch/ppc/kernel/irq.c
Alex
On Fri, 29 Jul 2005 10:07:58 -0300
"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> Hi,
>
> I had some problems with irq in my embedded system. I'm interested in
> this function source code, but I didn't find it in my linux distribuction?
>
> Does anyone know where I can find it?
>
> Thanks a lot
> Tiago
>
> Manish Joshi wrote:
>
> > Hi,
> >
> > I am working on an old code which uses request_8xxirq() call which I
> > can't find in latest kernel.
> > Has this been replaced by something else ?
> >
> > I see the references on net about replacing request_8xxirq() with
> > request_irq(). Can I do it ?
> >
> > TIA,
> > Manish
> >
> >
> > ------------------------------------------------------------------------
> > Start your day with Yahoo! - make it your home page
> > <http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> --
> Tiago Dall'Agnol
> Pesquisa e Desenvolvimento
> Tel.: +55.51.470.05.64
> Fax.: +55.51.470.05.70
> e-mail: tdallagnol@parks.com.br
> www.parks.com.br
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: request_8xxirq
From: Tiago Dall'Agnol @ 2005-07-29 13:52 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050729144015.09fec9fe.ajz@cambridgebroadband.com>
Thank you Alex.
But in my linux, this is different.
What I have in that file is just
extern int request_8xxirq(unsigned int irq,
void (*handler)(int, void *, struct pt_regs *),
unsigned long flags,
const char *device,
void *dev_id);
And the request_8xxirq is declared as a
EXPORT_SYMBOL(request_8xxirq);
in arch/ppc/kernel/ppc_ksyms.c.
I already tried to find out where the code that implements the function
is located, but it seems that it doesn't exist in my distribuction.
Maybe is it a "binary version"?
Any other information will be apreciated ;-)
Best Regards,
Tiago
Alex Zeffertt wrote:
>In linux-2.4 it's in
>
> include/asm-ppc/mpc8xx.h
>
>-- snip --
>#define request_8xxirq request_irq
>--/snip --
>
>And request_irq is in arch/ppc/kernel/irq.c
>
>Alex
>
>On Fri, 29 Jul 2005 10:07:58 -0300
>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>
>
>
>>Hi,
>>
>>I had some problems with irq in my embedded system. I'm interested in
>>this function source code, but I didn't find it in my linux distribuction?
>>
>>Does anyone know where I can find it?
>>
>>Thanks a lot
>>Tiago
>>
>>Manish Joshi wrote:
>>
>>
>>
>>>Hi,
>>>
>>>I am working on an old code which uses request_8xxirq() call which I
>>>can't find in latest kernel.
>>>Has this been replaced by something else ?
>>>
>>>I see the references on net about replacing request_8xxirq() with
>>>request_irq(). Can I do it ?
>>>
>>>TIA,
>>>Manish
>>>
>>>
>>>------------------------------------------------------------------------
>>>Start your day with Yahoo! - make it your home page
>>><http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>>
>>--
>>Tiago Dall'Agnol
>>Pesquisa e Desenvolvimento
>>Tel.: +55.51.470.05.64
>>Fax.: +55.51.470.05.70
>>e-mail: tdallagnol@parks.com.br
>>www.parks.com.br
>>
>>_______________________________________________
>>Linuxppc-embedded mailing list
>>Linuxppc-embedded@ozlabs.org
>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
>
>
--
^ permalink raw reply
* Re: ATI Radeon with PPC 440 GX and kernel 2.6.12
From: Matt Porter @ 2005-07-29 14:29 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <001f01c59417$fe81b840$f201a8c0@SN7606>
On Fri, Jul 29, 2005 at 10:32:01AM +0200, David Grab wrote:
> Hello,
>
> i´m using on my custom board a ATI M6 Mobility Radeon with kernel 2.6.12.
> Now i have to initialize the ati and configure the kernel to support it. Did
> someone use this combination (ppc + ati radeon)? It would be appreciating to
> get some help or tipps in configuring to get the ati functioning. Especially
> the BIOS of the ATI chip, because i have actually found only x86 binaries.
> Is it also possible to set up the bios settings for the ati chip without an
> bios eeprom attached via the radeon driver?
There is a x86 emulator that can execute x86 VGA BIOS code to initialize
your VGA core in U-Boot. It's part of the MAI port so you can look at
that code and port it to your board. It is actually some scitechsoft
code that's been ported to build within U-Boot.
Gabriel Paubert's preploader code also has an x86 real mode emulator
written in PPC assembly that does the same thing, but it may be more
convenient to work with the stuff in U-Boot. It doesn't help that I
can seem to find a current link to the preploader code. Maybe Gabriel
can appear and provide it.
-Matt
^ permalink raw reply
* Re: request_8xxirq
From: Alex Zeffertt @ 2005-07-29 14:43 UTC (permalink / raw)
To: Tiago Dall'Agnol; +Cc: linuxppc-embedded
In-Reply-To: <42EA34A1.7060600@parks.com.br>
Maybe you're using a really old kernel. In linux-2.4.4 it's in
arch/ppc/kernel/irq.c:
-- snip --
#if (defined(CONFIG_8xx) || defined(CONFIG_8260))
/* Name change so we can catch standard drivers that potentially mess up
* the internal interrupt controller on 8xx and 8260. Just bear with me,
* I don't like this either and I am searching a better solution. For
* now, this is what I need. -- Dan
*/
#define request_irq request_8xxirq
...
...
...
int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *),
unsigned long irqflags, const char * devname, void *dev_id)
{
--/snip --
I don't know why it was done like this....
Alex
On Fri, 29 Jul 2005 10:52:33 -0300
"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> Thank you Alex.
>
> But in my linux, this is different.
> What I have in that file is just
>
> extern int request_8xxirq(unsigned int irq,
> void (*handler)(int, void *, struct pt_regs *),
> unsigned long flags,
> const char *device,
> void *dev_id);
>
> And the request_8xxirq is declared as a
>
> EXPORT_SYMBOL(request_8xxirq);
>
> in arch/ppc/kernel/ppc_ksyms.c.
>
> I already tried to find out where the code that implements the function
> is located, but it seems that it doesn't exist in my distribuction.
> Maybe is it a "binary version"?
>
> Any other information will be apreciated ;-)
>
> Best Regards,
> Tiago
>
> Alex Zeffertt wrote:
>
> >In linux-2.4 it's in
> >
> > include/asm-ppc/mpc8xx.h
> >
> >-- snip --
> >#define request_8xxirq request_irq
> >--/snip --
> >
> >And request_irq is in arch/ppc/kernel/irq.c
> >
> >Alex
> >
> >On Fri, 29 Jul 2005 10:07:58 -0300
> >"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
> >
> >
> >
> >>Hi,
> >>
> >>I had some problems with irq in my embedded system. I'm interested in
> >>this function source code, but I didn't find it in my linux distribuction?
> >>
> >>Does anyone know where I can find it?
> >>
> >>Thanks a lot
> >>Tiago
> >>
> >>Manish Joshi wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>I am working on an old code which uses request_8xxirq() call which I
> >>>can't find in latest kernel.
> >>>Has this been replaced by something else ?
> >>>
> >>>I see the references on net about replacing request_8xxirq() with
> >>>request_irq(). Can I do it ?
> >>>
> >>>TIA,
> >>>Manish
> >>>
> >>>
> >>>------------------------------------------------------------------------
> >>>Start your day with Yahoo! - make it your home page
> >>><http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
> >>>
> >>>------------------------------------------------------------------------
> >>>
> >>>_______________________________________________
> >>>Linuxppc-embedded mailing list
> >>>Linuxppc-embedded@ozlabs.org
> >>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>>
> >>>
> >>>
> >>--
> >>Tiago Dall'Agnol
> >>Pesquisa e Desenvolvimento
> >>Tel.: +55.51.470.05.64
> >>Fax.: +55.51.470.05.70
> >>e-mail: tdallagnol@parks.com.br
> >>www.parks.com.br
> >>
> >>_______________________________________________
> >>Linuxppc-embedded mailing list
> >>Linuxppc-embedded@ozlabs.org
> >>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >>
> >>
> >
> >
> >
>
> --
^ permalink raw reply
* Re: ATI Radeon with PPC 440 GX and kernel 2.6.12
From: Wolfgang Denk @ 2005-07-29 15:10 UTC (permalink / raw)
To: David Grab; +Cc: linuxppc-embedded
In-Reply-To: <001f01c59417$fe81b840$f201a8c0@SN7606>
In message <001f01c59417$fe81b840$f201a8c0@SN7606> you wrote:
>
> i´m using on my custom board a ATI M6 Mobility Radeon with kernel 2.6.12.
> Now i have to initialize the ati and configure the kernel to support it. Did
> someone use this combination (ppc + ati radeon)? It would be appreciating to
> get some help or tipps in configuring to get the ati functioning. Especially
> the BIOS of the ATI chip, because i have actually found only x86 binaries.
> Is it also possible to set up the bios settings for the ati chip without an
> bios eeprom attached via the radeon driver?
If you use U-Boot as boot loader you can enable and use the x86
emulator taht comes included with it. But don't expect to much help
with that - except for the Amiga One (where I was told this is
working) I don't know of any other board using this feature.
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
Two wrongs don't make a right, but three rights make a left.
^ permalink raw reply
* mpc8248 SEC -- interrupt handler not invoked
From: Vikas Aggarwal @ 2005-07-29 15:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
Will appreciate if someone can guide me how to debug this inside SEC
(security co-processor) core.
The linux driver is writing descriptor into the FETCH-Register(0x2048)
for Random Number generation execution unit(RNG-EU). The request came
through a test program from user space. The RNG generation request never
seems to complete as my ISR is not invoked.
I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010) and
it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
always there even before I write the RNG descriptor to Fetch-register.
1. I can read the ID register and verified it is 0x09000000.
2. I can see my ISR is registered(0x47) under /proc/interrupts.
I don't see anything wrong with the descriptor which is very simple Random
Number Generation request.
regards
-vikas aggarwal
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Michael Richardson @ 2005-07-29 16:33 UTC (permalink / raw)
To: Kumar Gala
Cc: Andrew Morton, linux-kernel, kyle, Gala Kumar K.-galak,
linuxppc-embedded
In-Reply-To: <3965D4DD-1628-4463-890F-106DB5BC6931@freescale.com>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Kumar" == Kumar Gala <kumar.gala@freescale.com> writes:
>> When we recover our history from the linuxppc-2.4/2.5 trees we
>> can show exactly how long it's been since anybody touched ep405.
>>
>> Quick googling shows that it's been almost 2 years since the last
>> mention of ep405 (exluding removal discussions) on
>> linuxppc-embedded. Last ep405-related commits are more than 2
>> years ago.
So, I'll bet I can find other parts of the kernel tree that haven't
been touched in 2 years. Maybe there isn't anything to fix?
Happens that in our case,
a) the board is the basis to our own board.
b) we only moved to 2.6 in May.
So, I just don't get removing board support files.
- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] I'm a dad: http://www.sandelman.ca/lrmr/ [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQupaXIqHRg3pndX9AQFnGQP+JXX0ZTKW35LljC/ighUPpmcdClRlmWP2
fsnofXYNi2v9QEkYpoS8pHMc3ClKHT8MFzK/nsDe1CFWPxxavK+365usf77DSGWB
bjZ8CZWjkvDt7IMjBxEnSlzCTVt39Gtjq1zM/DMY0SOi1ccB7TIZE+1Ol3zkYnW5
2X6+0SKgS6Q=
=kcQj
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: request_8xxirq
From: Tiago Dall'Agnol @ 2005-07-29 17:01 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050729154359.1ac8f488.ajz@cambridgebroadband.com>
I'm using kernel 2.4.18, and I can see the code you posted.
But this code doesn't help to find request_8xxirq. It just do the
opposite. This code defines request_irq to be request_8xxirq when
CONFIG_8xx is defined. But where is located the implementation of
request_8xxirq?
Am I wrong? I didn't understand when that function request_irq is used.
Thanks
Tiago
Alex Zeffertt wrote:
>Maybe you're using a really old kernel. In linux-2.4.4 it's in
>arch/ppc/kernel/irq.c:
>
>-- snip --
>#if (defined(CONFIG_8xx) || defined(CONFIG_8260))
>/* Name change so we can catch standard drivers that potentially mess up
> * the internal interrupt controller on 8xx and 8260. Just bear with me,
> * I don't like this either and I am searching a better solution. For
> * now, this is what I need. -- Dan
> */
>#define request_irq request_8xxirq
>
>...
>...
>...
>
>int request_irq(unsigned int irq, void (*handler)(int, void *, struct pt_regs *),
> unsigned long irqflags, const char * devname, void *dev_id)
>{
>--/snip --
>
>
>I don't know why it was done like this....
>
>Alex
>
>
>On Fri, 29 Jul 2005 10:52:33 -0300
>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>
>
>
>>Thank you Alex.
>>
>>But in my linux, this is different.
>>What I have in that file is just
>>
>>extern int request_8xxirq(unsigned int irq,
>> void (*handler)(int, void *, struct pt_regs *),
>> unsigned long flags,
>> const char *device,
>> void *dev_id);
>>
>>And the request_8xxirq is declared as a
>>
>>EXPORT_SYMBOL(request_8xxirq);
>>
>>in arch/ppc/kernel/ppc_ksyms.c.
>>
>>I already tried to find out where the code that implements the function
>>is located, but it seems that it doesn't exist in my distribuction.
>>Maybe is it a "binary version"?
>>
>>Any other information will be apreciated ;-)
>>
>>Best Regards,
>>Tiago
>>
>>Alex Zeffertt wrote:
>>
>>
>>
>>>In linux-2.4 it's in
>>>
>>> include/asm-ppc/mpc8xx.h
>>>
>>>-- snip --
>>>#define request_8xxirq request_irq
>>>--/snip --
>>>
>>>And request_irq is in arch/ppc/kernel/irq.c
>>>
>>>Alex
>>>
>>>On Fri, 29 Jul 2005 10:07:58 -0300
>>>"Tiago Dall'Agnol" <tdallagnol@parks.com.br> wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I had some problems with irq in my embedded system. I'm interested in
>>>>this function source code, but I didn't find it in my linux distribuction?
>>>>
>>>>Does anyone know where I can find it?
>>>>
>>>>Thanks a lot
>>>>Tiago
>>>>
>>>>Manish Joshi wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>I am working on an old code which uses request_8xxirq() call which I
>>>>>can't find in latest kernel.
>>>>>Has this been replaced by something else ?
>>>>>
>>>>>I see the references on net about replacing request_8xxirq() with
>>>>>request_irq(). Can I do it ?
>>>>>
>>>>>TIA,
>>>>>Manish
>>>>>
>>>>>
>>>>>------------------------------------------------------------------------
>>>>>Start your day with Yahoo! - make it your home page
>>>>><http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
>>>>>
>>>>>------------------------------------------------------------------------
>>>>>
>>>>>_______________________________________________
>>>>>Linuxppc-embedded mailing list
>>>>>Linuxppc-embedded@ozlabs.org
>>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>--
>>>>Tiago Dall'Agnol
>>>>Pesquisa e Desenvolvimento
>>>>Tel.: +55.51.470.05.64
>>>>Fax.: +55.51.470.05.70
>>>>e-mail: tdallagnol@parks.com.br
>>>>www.parks.com.br
>>>>
>>>>_______________________________________________
>>>>Linuxppc-embedded mailing list
>>>>Linuxppc-embedded@ozlabs.org
>>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>--
>>
>>
>
>
>
--
Tiago Dall'Agnol
Pesquisa e Desenvolvimento
Tel.: +55.51.470.05.64
Fax.: +55.51.470.05.70
e-mail: tdallagnol@parks.com.br
Parks S.A. Comunicações Digitais
www.parks.com.br
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Esben Nielsen @ 2005-07-29 17:03 UTC (permalink / raw)
To: Matt Porter; +Cc: Andrew Morton, linux-kernel, Kumar Gala, linuxppc-embedded
In-Reply-To: <20050727101502.B1114@cox.net>
On Wed, 27 Jul 2005, Matt Porter wrote:
> On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote:
> > On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote:
> > > Kumar, I thought that we had some volunteers to take care of some of
> > > those. I know that I still care about ep405, and I'm willing to maintain
> > > the code.
> >
> > Well, it has been almost two months since Kumar asked about maintenance
> > for this board. Nothing happened since then.
> >
> > Why is it not fixed yet? Please, send a patch which fixes it. This is
> > the _best_ way to keep this board in the tree, not some empty
> > maintenance _promises_.
>
> When we recover our history from the linuxppc-2.4/2.5 trees we can
> show exactly how long it's been since anybody touched ep405.
>
> Quick googling shows that it's been almost 2 years since the last
> mention of ep405 (exluding removal discussions) on linuxppc-embedded.
> Last ep405-related commits are more than 2 years ago.
>
I don't follow that reasoning. Even broken drivers(board support files,
whateever) are better than non.
Take ArcNet support forinstance. Clearly it hadn't been used in any 2.6
kernel up until around 2.6.10. It was highly broken (call to
uninitialized function pointer). But I needed it. I fixed it and send the
patch so it works from 2.6.11 and up. If the driver had been dropped in
the 2.6 series because nobody actively maintained it, I wouldn't have got
around to fix it at all and was probably forced to use another OS for my
perpose.
But because the driver was still in there and somebody had made sure it
was updated along the changes to the API in the 2.6 kernel, it was easy
for me to fix it although I didn't know so much about the kernel internals
at that time.
Esben
^ permalink raw reply
* Re: request_8xxirq
From: Dan Malek @ 2005-07-29 17:43 UTC (permalink / raw)
To: Tiago Dall'Agnol; +Cc: linuxppc-embedded
In-Reply-To: <42EA60E1.7040804@parks.com.br>
On Jul 29, 2005, at 1:01 PM, Tiago Dall'Agnol wrote:
> Am I wrong? I didn't understand when that function request_irq is used.
At some point I don't remember and against all of my wishes, the code
was changed from using request_8xxirq to using request_irq using
an ugly hack to add some offset to the 8xx interrupt vector number.
I didn't see any bug that needed fixing, but people with the power to
ignore my maintainer status decided to change it anyway. So, now you
have to modify your drivers to call request_irq() with some nonsensical
interrupt number. No value added, just confusion.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 00/14] ppc32: Remove board ports that are no longer maintained
From: Kumar Gala @ 2005-07-29 18:10 UTC (permalink / raw)
To: Esben Nielsen
Cc: Andrew Morton, linux-kernel, Gala Kumar K.-galak,
linuxppc-embedded
In-Reply-To: <Pine.OSF.4.05.10507291900320.26224-100000@da410.phys.au.dk>
On Jul 29, 2005, at 12:03 PM, Esben Nielsen wrote:
>
>
> On Wed, 27 Jul 2005, Matt Porter wrote:
>
>
>> On Wed, Jul 27, 2005 at 09:27:41AM -0700, Eugene Surovegin wrote:
>>
>>> On Wed, Jul 27, 2005 at 12:13:23PM -0400, Michael Richardson wrote:
>>>
>>>> Kumar, I thought that we had some volunteers to take care of some
>>>>
> of
>
>>>> those. I know that I still care about ep405, and I'm willing to
>>>>
> maintain
>
>>>> the code.
>>>>
>>>
>>> Well, it has been almost two months since Kumar asked about
>>>
> maintenance
>
>>> for this board. Nothing happened since then.
>>>
>>> Why is it not fixed yet? Please, send a patch which fixes it. This
>>>
> is
>
>>> the _best_ way to keep this board in the tree, not some empty
>>> maintenance _promises_.
>>>
>>
>> When we recover our history from the linuxppc-2.4/2.5 trees we can
>> show exactly how long it's been since anybody touched ep405.
>>
>> Quick googling shows that it's been almost 2 years since the last
>> mention of ep405 (exluding removal discussions) on linuxppc-embedded.
>> Last ep405-related commits are more than 2 years ago.
>>
>>
> I don't follow that reasoning. Even broken drivers(board support
> files,
> whateever) are better than non.
>
> Take ArcNet support forinstance. Clearly it hadn't been used in any
> 2.6
> kernel up until around 2.6.10. It was highly broken (call to
> uninitialized function pointer). But I needed it. I fixed it and send
> the
> patch so it works from 2.6.11 and up. If the driver had been
> dropped in
> the 2.6 series because nobody actively maintained it, I wouldn't have
> got
> around to fix it at all and was probably forced to use another OS
> for my
> perpose.
>
> But because the driver was still in there and somebody had made
> sure it
> was updated along the changes to the API in the 2.6 kernel, it was
> easy
> for me to fix it although I didn't know so much about the kernel
> internals
> at that time.
The code will still exist in older kernel releases so if someone
needs to bring it up to date they can. We are more than willing to
take patches to fix any issues.
Let's be clear. I posted a request several weeks ago in which anyone
was free to comment on the various board ports that existed and their
maintainership.
- kumar
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler not invoked
From: Kim Phillips @ 2005-07-29 20:33 UTC (permalink / raw)
To: Vikas Aggarwal; +Cc: linuxppc-embedded
In-Reply-To: <32704.198.22.236.230.1122651627.squirrel@198.22.236.230>
On Fri, 29 Jul 2005 11:40:27 -0400 (EDT)
"Vikas Aggarwal" <va824363@albany.edu> wrote:
> Hi All,
> Will appreciate if someone can guide me how to debug this inside SEC
> (security co-processor) core.
>
> The linux driver is writing descriptor into the FETCH-Register(0x2048)
> for Random Number generation execution unit(RNG-EU). The request came
> through a test program from user space. The RNG generation request never
> seems to complete as my ISR is not invoked.
> I checked the CCPSR(Crypto Channel Pointer Status register = 0x2010) and
> it has value=0:7(0-31 : 32-63 bits). 7 means "channel_error". But its
> always there even before I write the RNG descriptor to Fetch-register.
a value of 7 in bits 56-63 (PAIR_PTR) can suggest processing has not begun.
can you verify you are writing the upper bits of the FR (i.e. 0x204c)?
Kim
^ permalink raw reply
* Re: [PATCH RFC]: PHY Abstraction Layer III
From: Jeff Garzik @ 2005-07-29 21:46 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, Embedded PPC Linux list
In-Reply-To: <23F9076F-9FBB-43C8-83CD-F630E694203D@freescale.com>
Andy Fleming wrote:
> Here's the latest version of the patch, done against a cogito linux-2.6
> branch. It has a handful of small changes, which I hope will speed
> acceptance:
>
> * Interrupts are no longer requested at interrupt time
> * There is a function to print out PHY status
> * The PHY drivers' probe function now serves only to initialize driver
> state
> * A new config_init functor has been created to configure PHY state
> just after reset (so that the PHYs will be returned to a sane state if
> they don't start up that way)
> * Stephen Hemminger's patch to allow better module support in the
> drivers has been included
OK, DaveM and I are OK with merging this.
Send me a single One Big Patch which adds all the new files and such,
I'll give it a final review, and queue it for 2.6.14.
Jeff
^ permalink raw reply
* PPC440EP (405GPr) (2.4, 2.6) scatter/gather DMA - now works
From: Roger Larsson @ 2005-07-29 21:47 UTC (permalink / raw)
To: Matt Porter; +Cc: linux-ppc-embedded
We are actually still using the 2.4 tree with our own patches
to make SGDMA work.
Using a different approach...
1. We need more than one page of descriptors, so we allocate one
at a time. [Doing DMA transfers of hires images directly to user space]
2. Interrupt is handled in a simpler way:
If interrupts are enabled:
* always enable error
* always enable end of transfer interrupts
* only enable terminal count interrupt on last descriptor
Anyway we have ported our patch from using 405 GPr to 440 EP,
during that we run into one major roadblock, now solved.
[ppc4xx_dma.h]
504 #ifdef PPC4xx_DMA_64BIT
505 typedef struct {
506 uint32_t control;
507 uint32_t control_count;
508 phys_addr_t src_addr;
509 phys_addr_t dst_addr;
510 phys_addr_t next;
511 } ppc_sgl_t;
512 #else
513 typedef struct {
514 uint32_t control;
515 phys_addr_t src_addr;
516 phys_addr_t dst_addr;
517 uint32_t control_count;
518 uint32_t next;
519 } ppc_sgl_t;
520 #endif
440EP is a strange...
It has 36 bit address, four 64 bit DMA and four 32 bit DMA...
Since we do not, yet, use any 64 bit DMA we turned that off...
[mmu.h]
/*
* Define physical address type. Machines using split size
* virtual/physical addressing like 32-bit virtual / 36-bit
* physical need a larger than native word size type. -Matt
*/
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long phys_addr_t;
extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t);
#else
typedef unsigned long phys_addr_t;
#endif
Since phys_addr_t is 64 bits... the discriptor layout gets wrong...
In this case I think it is better to use uint32_t for those addresses.
What is worse is how to support BOTH 32 and 64 bits DMA at
the same time. Possibly ppc_sgl_t could be private for ppc4xx_sgdma?
Is there other processors in the ppc family that have both 64
and 32 bits DMA?
I have forgot to send our patch for several days now, but this
is the most important part. This message is also to make me
remember to prepare those patches!!!
/RogerL
^ permalink raw reply
* [PATCH] ppc32: fix 44x early serial debug for configurations with more than 512M of RAM
From: Eugene Surovegin @ 2005-07-29 23:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
Fix 44x early serial debugging for big RAM configurations (more than
512M). We cannot use default OpenBIOS virtual mapping, because it
interferes with pinned TLB entry.
While we are at it, move early UART mapping to TLB slot 0, so it can
survive longer during boot process (slot 1 is used by the first
ioremap call, effectively killing UART mapping if it occupies this
slot). Also, change UART TLB entry size to 4K (256M is too much for a
bunch of registers :). Squash some warnings on the way.
Tested on Ebony and Ocotea with 1G of RAM.
Thanks to Scott Coulter <scott.coulter@cyclone.com> for diagnosing
this problem.
Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
diff --git a/arch/ppc/kernel/head_44x.S b/arch/ppc/kernel/head_44x.S
--- a/arch/ppc/kernel/head_44x.S
+++ b/arch/ppc/kernel/head_44x.S
@@ -179,14 +179,14 @@ skpinv: addi r4,r4,1 /* Increment */
4:
#ifdef CONFIG_SERIAL_TEXT_DEBUG
/*
- * Add temporary UART mapping for early debug. This
- * mapping must be identical to that used by the early
- * bootloader code since the same asm/serial.h parameters
- * are used for polled operation.
+ * Add temporary UART mapping for early debug.
+ * We can map UART registers wherever we want as long as they don't
+ * interfere with other system mappings (e.g. with pinned entries).
+ * For an example of how we handle this - see ocotea.h. --ebs
*/
/* pageid fields */
lis r3,UART0_IO_BASE@h
- ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_256M
+ ori r3,r3,PPC44x_TLB_VALID | PPC44x_TLB_4K
/* xlat fields */
lis r4,UART0_PHYS_IO_BASE@h /* RPN depends on SoC */
@@ -196,7 +196,7 @@ skpinv: addi r4,r4,1 /* Increment */
li r5,0
ori r5,r5,(PPC44x_TLB_SW | PPC44x_TLB_SR | PPC44x_TLB_I | PPC44x_TLB_G)
- li r0,1 /* TLB slot 1 */
+ li r0,0 /* TLB slot 0 */
tlbwe r3,r0,PPC44x_TLB_PAGEID /* Load the pageid fields */
tlbwe r4,r0,PPC44x_TLB_XLAT /* Load the translation fields */
diff --git a/arch/ppc/platforms/4xx/ebony.c b/arch/ppc/platforms/4xx/ebony.c
--- a/arch/ppc/platforms/4xx/ebony.c
+++ b/arch/ppc/platforms/4xx/ebony.c
@@ -7,7 +7,7 @@
* Copyright 2002-2005 MontaVista Software Inc.
*
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
- * Copyright (c) 2003, 2004 Zultys Technologies
+ * Copyright (c) 2003-2005 Zultys Technologies
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -50,6 +50,7 @@
#include <asm/bootinfo.h>
#include <asm/ppc4xx_pic.h>
#include <asm/ppcboot.h>
+#include <asm/tlbflush.h>
#include <syslib/gen550.h>
#include <syslib/ibm440gp_common.h>
@@ -248,6 +249,9 @@ ebony_early_serial_map(void)
#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
/* Configure debug serial access */
gen550_init(0, &port);
+
+ /* Purge TLB entry added in head_44x.S for early serial access */
+ _tlbie(UART0_IO_BASE);
#endif
port.membase = ioremap64(PPC440GP_UART1_ADDR, 8);
diff --git a/arch/ppc/platforms/4xx/ebony.h b/arch/ppc/platforms/4xx/ebony.h
--- a/arch/ppc/platforms/4xx/ebony.h
+++ b/arch/ppc/platforms/4xx/ebony.h
@@ -56,9 +56,18 @@
* Serial port defines
*/
-/* OpenBIOS defined UART mappings, used before early_serial_setup */
+#if defined(__BOOTER__)
+/* OpenBIOS defined UART mappings, used by bootloader shim */
#define UART0_IO_BASE 0xE0000200
#define UART1_IO_BASE 0xE0000300
+#else
+/* head_44x.S created UART mapping, used before early_serial_setup.
+ * We cannot use default OpenBIOS UART mappings because they
+ * don't work for configurations with more than 512M RAM. --ebs
+ */
+#define UART0_IO_BASE 0xF0000200
+#define UART1_IO_BASE 0xF0000300
+#endif
/* external Epson SG-615P */
#define BASE_BAUD 691200
@@ -66,7 +75,7 @@
#define STD_UART_OP(num) \
{ 0, BASE_BAUD, 0, UART##num##_INT, \
(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
- iomem_base: UART##num##_IO_BASE, \
+ iomem_base: (void*)UART##num##_IO_BASE, \
io_type: SERIAL_IO_MEM},
#define SERIAL_PORT_DFNS \
diff --git a/arch/ppc/platforms/4xx/ocotea.c b/arch/ppc/platforms/4xx/ocotea.c
--- a/arch/ppc/platforms/4xx/ocotea.c
+++ b/arch/ppc/platforms/4xx/ocotea.c
@@ -48,6 +48,7 @@
#include <asm/bootinfo.h>
#include <asm/ppc4xx_pic.h>
#include <asm/ppcboot.h>
+#include <asm/tlbflush.h>
#include <syslib/gen550.h>
#include <syslib/ibm440gx_common.h>
@@ -266,6 +267,9 @@ ocotea_early_serial_map(void)
#if defined(CONFIG_SERIAL_TEXT_DEBUG) || defined(CONFIG_KGDB)
/* Configure debug serial access */
gen550_init(0, &port);
+
+ /* Purge TLB entry added in head_44x.S for early serial access */
+ _tlbie(UART0_IO_BASE);
#endif
port.membase = ioremap64(PPC440GX_UART1_ADDR, 8);
diff --git a/arch/ppc/platforms/4xx/ocotea.h b/arch/ppc/platforms/4xx/ocotea.h
--- a/arch/ppc/platforms/4xx/ocotea.h
+++ b/arch/ppc/platforms/4xx/ocotea.h
@@ -55,15 +55,24 @@
*/
#define RS_TABLE_SIZE 2
-/* OpenBIOS defined UART mappings, used before early_serial_setup */
+#if defined(__BOOTER__)
+/* OpenBIOS defined UART mappings, used by bootloader shim */
#define UART0_IO_BASE 0xE0000200
#define UART1_IO_BASE 0xE0000300
+#else
+/* head_44x.S created UART mapping, used before early_serial_setup.
+ * We cannot use default OpenBIOS UART mappings because they
+ * don't work for configurations with more than 512M RAM. --ebs
+ */
+#define UART0_IO_BASE 0xF0000200
+#define UART1_IO_BASE 0xF0000300
+#endif
#define BASE_BAUD 11059200/16
#define STD_UART_OP(num) \
{ 0, BASE_BAUD, 0, UART##num##_INT, \
(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST), \
- iomem_base: UART##num##_IO_BASE, \
+ iomem_base: (void*)UART##num##_IO_BASE, \
io_type: SERIAL_IO_MEM},
#define SERIAL_PORT_DFNS \
^ permalink raw reply
* Serial console
From: Daniel Ann @ 2005-07-30 1:06 UTC (permalink / raw)
To: linuxppc-embedded
Hi folks,
Just wondering if anyone could lend a hand with this problem I have
with serial console. I'm trying to boot up my board (very similar to
sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
working but console will display up to,
[snip]
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 112k init =
=20
I've done series of printk in sys_execve() to see if /sbin/init is
working, and found out it went thru the whole rcS file okay. Mind you,
printk is successfully displaying the output on the console while I'm
still not getting anything from the user processes.
Having all the kernel boot up log on console means that I've done some
part right. But why am I not getting anything from the user processes
on the console screen ?
Is there anything I need to do on the kernel config ?
--=20
Daniel
^ permalink raw reply
* Re: Serial console
From: Josh Boyer @ 2005-07-30 1:19 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca65705072918062249e41f@mail.gmail.com>
On Sat, 2005-07-30 at 10:06 +0900, Daniel Ann wrote:
> Hi folks,
>
> Just wondering if anyone could lend a hand with this problem I have
> with serial console. I'm trying to boot up my board (very similar to
> sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> working but console will display up to,
> [snip]
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 112k init
>
> I've done series of printk in sys_execve() to see if /sbin/init is
> working, and found out it went thru the whole rcS file okay. Mind you,
> printk is successfully displaying the output on the console while I'm
> still not getting anything from the user processes.
>
> Having all the kernel boot up log on console means that I've done some
> part right. But why am I not getting anything from the user processes
> on the console screen ?
>
> Is there anything I need to do on the kernel config ?
Do you have a /dev/console device node in your initrd? If not, that is
one of the reasons you could be seeing that problem. Make
sure /dev/null is there too.
josh
^ permalink raw reply
* Re: Serial console
From: Ricardo Scop @ 2005-07-30 1:27 UTC (permalink / raw)
To: Daniel Ann, linuxppc-embedded
In-Reply-To: <9b7ca65705072918062249e41f@mail.gmail.com>
Hi Daniel,
On Friday 29 July 2005 22:06, Daniel Ann wrote:
> Hi folks,
>
> Just wondering if anyone could lend a hand with this problem I have
> with serial console. I'm trying to boot up my board (very similar to
> sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> working but console will display up to,
> [snip]
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 112k init
>
> I've done series of printk in sys_execve() to see if /sbin/init is
> working, and found out it went thru the whole rcS file okay. Mind you,
> printk is successfully displaying the output on the console while I'm
> still not getting anything from the user processes.
>
> Having all the kernel boot up log on console means that I've done some
> part right. But why am I not getting anything from the user processes
> on the console screen ?
>
Please verify that you have a /dev/console in your rootfs, and that it's =
being=20
correctly acessed by the init process.
HTH,
--=20
Ricardo Scop.
\|/
___ -*-
(@ @)/|\
/ V \| R SCOP Consult.
/( )\ Linux-based communications
--^^---^^+------------------------------
rscop@matrix.com.br
+55 51 999-36-777
Porto Alegre, RS - BRazil
^ permalink raw reply
* Re: Serial console
From: Daniel Ann @ 2005-07-30 1:34 UTC (permalink / raw)
To: Ricardo Scop; +Cc: linuxppc-embedded
In-Reply-To: <200507292227.45626.scop@digitel.com.br>
Looks like I have /dev/console
0 crw------- 1 root root 5, 1 Sep 26 2002 console
0 crw-rw-rw- 1 root root 4, 64 Jun 17 2004 ttyS0
I havent yet figured out how I should go about seeing if init is
correctly accessing it tho. Let me take a look at busybox init part.
BTW, any more reasons why this problem might exist ?
On 7/30/05, Ricardo Scop <scop@digitel.com.br> wrote:
> Hi Daniel,
>=20
> On Friday 29 July 2005 22:06, Daniel Ann wrote:
> > Hi folks,
> >
> > Just wondering if anyone could lend a hand with this problem I have
> > with serial console. I'm trying to boot up my board (very similar to
> > sandpoint using MPC8245) with kernel 2.6.12.3, and most of it is
> > working but console will display up to,
> > [snip]
> > RAMDISK: Compressed image found at block 0
> > VFS: Mounted root (ext2 filesystem) readonly.
> > Freeing unused kernel memory: 112k init
> >
> > I've done series of printk in sys_execve() to see if /sbin/init is
> > working, and found out it went thru the whole rcS file okay. Mind you,
> > printk is successfully displaying the output on the console while I'm
> > still not getting anything from the user processes.
> >
> > Having all the kernel boot up log on console means that I've done some
> > part right. But why am I not getting anything from the user processes
> > on the console screen ?
> >
> Please verify that you have a /dev/console in your rootfs, and that it's =
being
> correctly acessed by the init process.
>=20
> HTH,
>=20
> --
> Ricardo Scop.
>=20
> \|/
> ___ -*-
> (@ @)/|\
> / V \| R SCOP Consult.
> /( )\ Linux-based communications
> --^^---^^+------------------------------
> rscop@matrix.com.br
> +55 51 999-36-777
> Porto Alegre, RS - BRazil
>=20
>=20
--=20
Daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox