* Serial console settings nightmare...
From: Garcia Jérémie @ 2005-05-10 13:45 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
I'm trying to get a montavista hardhat pro 3.1 (kernel 2.4.20) running =
on our hardware. This one uses a ppc 405 EP.
In order to do that, we use a vxWorks bootloader to download via ftp the =
linux image (zImage.treeboot) in memory.=20
We had to modify some parts of linux code to achieve that. Indeed, linux =
bootstrap (which relocate & decompress) waits a board info structure =
from the bootloader;
in our case the vxWorks bootloader was not able to do that so we had =
this in a static way :
/**********************/
/* ppc4xx_setup.c */
/**********************/
void __init
platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
parse_bootinfo(find_bootinfo());
/* We use VxWorks bootrom, so we have to create ourselves the boot info =
structure */
bd_t my_bd_t;
=20
strcpy(my_bd_t.bi_s_version,"v1"); /* Version of =
this structure */
strcpy(my_bd_t.bi_r_version,"bootrom linux 1.0") ; /* Version of the =
IBM ROM */
my_bd_t.bi_memsize =3D 16*1024*1024 ; /* DRAM =
installed, in bytes */
my_bd_t.bi_intfreq =3D 200000000 ; /* Processor speed, in Hz =
*/
my_bd_t.bi_busfreq =3D 100000000 ; /* PLB Bus speed, in Hz =
*/
my_bd_t.bi_pllouta_freq =3D 400000000 ; /* PLL OUTA speed, in Hz =
*/
my_bd_t.bi_opb_busfreq =3D 50000000 ; /* OPB Bus speed, in Hz =
*/
my_bd_t.bi_iic_fast[0] =3D 0 ; /* Use fast i2c mode =
*/ =20
=20
memcpy((void *) __res, (void *) &my_bd_t,sizeof (bd_t));
...
/**********************/
/* embed_config.c */
/**********************/
bd_t * get_board_info(void)
{
my_strcpy(my_bd_t.bi_s_version,"v1"); /* Version of =
this structure */
my_strcpy(my_bd_t.bi_r_version,"bootrom linux 1.0") ; /* Version of =
the IBM ROM */
my_bd_t.bi_memsize =3D 16*1024*1024 ; /* DRAM =
installed, in bytes */
my_bd_t.bi_intfreq =3D 200000000 ; /* Processor speed, in Hz =
*/
my_bd_t.bi_busfreq =3D 100000000 ; /* PLB Bus speed, in Hz =
*/
my_bd_t.bi_pllouta_freq =3D 400000000 ; /* PLL OUTA speed, in Hz =
*/
/*my_bd_t.bi_opb_busfreq =3D 50000000 ; /* OPB Bus speed, in Hz =
*/
/*my_bd_t.bi_iic_fast[0] =3D 0 ; /* Use fast i2c mode =
*/
/* We return the address of our global structure */ =20
return &my_bd_t;
} =20
After that modifications the kernel boot process seemed to begin =
properly. But I can't see it properly on my serial console after
the linux bootstrap give the control to the kernel execution entry point =
(head_4xx.S).=20
Here is what I see on it:
loaded at: 00C7B250 00D374C4
relocated to: 00400000 004BC274
board data at: 004B913C 004B9190
relocated to: 0040547C 004054D0
zimage at: 00405AFF 004B8B22
avail ram: 004BD000 01000000
Linux/PPC load: console=3DttyS0,38400 root=3D/dev/nfs rw ip=3Don
Uncompressing Linux...done.
Now booting the kernel
.?w..tg?..*/)1j..-b?./?...V..?..-..W..E..?..4.)-W.?.-CV....i\Q!n.?v.-....=
;rs5k.5%.?i-.?-.-..V.....?!.-.?.Cn..?-.Fh-..g-.?wH.k... =
.[1;156H.[1;156H.
As you can see, I'd like my linux to have a serial setting of 38400 8n1. =
To achieve that, I modified the following things:
- in "ns16550.c": #define SERIAL_BAUD 38400 //(instead of 9600)
- in "tty_io.c" (console_init() function ): =20
tty_std_termios.c_iflag =3D ICRNL | IXON;
tty_std_termios.c_oflag =3D OPOST | ONLCR;
tty_std_termios.c_cflag =3D B38400 | CS8 | CREAD | HUPCL; =
//(instead of 9600)
tty_std_termios.c_lflag =3D ISIG | ICANON | ECHO | ECHOE | ECHOK =
|ECHOCTL | ECHOKE | IEXTEN;
- in "arch/ppc/platforms/myplatform.h" : #define BASE_BAUD xxxxxx
As you can see I haven't given a value for the BASE_BAUD value. Indeed, =
I can not find the right method to calculate it.
Could someone give me the formula please given the following infos:
- UART_DIV =3D 0x15 (so 21 in decimal)
- all other clocking info are given above in the "get_board_info"
Do you see sometrhing wrong there cause without any "readable" console =
I'm totally blind and I can't debug anything.
Please help me cause I've read so many forums,docs, and others that I'm =
really desperate... HELP!!!
J=E9r=E9mie
^ permalink raw reply
* Re: [PATCH 03/04] Freescale Ethernet combined driver
From: Pantelis Antoniou @ 2005-05-10 13:14 UTC (permalink / raw)
To: Matt Porter; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <20050510062744.A21835@cox.net>
Matt Porter wrote:
> On Tue, May 10, 2005 at 08:13:48AM -0400, Dan Malek wrote:
>
>>On May 10, 2005, at 7:17 AM, Pantelis Antoniou wrote:
>>
>>
>>>This patch replace iopa use with virt_to_phys.
>>
>>Not gonna work .....
>>
>>When you map uncached on 8xx you get a new vmalloc()
>>space. The virt_to_xxx macros don't work on those addresses.
>>You need to use the dma_consistent() function, stash the
>>real physical address it returns and then use it where
>>appropriate.
>
>
> That and the use of virt_to_* and friends is deprecated by
> the DMA API. You'll never get that upstream even if it were
> a case where it did work. That's a good thing to know for
> anybody doing other drivers...
>
> -Matt
>
>
OK then.
What's the recommended function to call to go from a
virtual -> physical address, but without doing a cache
flush/invalidate?
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH 03/04] Freescale Ethernet combined driver
From: Matt Porter @ 2005-05-10 13:27 UTC (permalink / raw)
To: Dan Malek; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <f1e15a8d9ed033e850b56ca965754a43@embeddededge.com>
On Tue, May 10, 2005 at 08:13:48AM -0400, Dan Malek wrote:
>
> On May 10, 2005, at 7:17 AM, Pantelis Antoniou wrote:
>
> > This patch replace iopa use with virt_to_phys.
>
> Not gonna work .....
>
> When you map uncached on 8xx you get a new vmalloc()
> space. The virt_to_xxx macros don't work on those addresses.
> You need to use the dma_consistent() function, stash the
> real physical address it returns and then use it where
> appropriate.
That and the use of virt_to_* and friends is deprecated by
the DMA API. You'll never get that upstream even if it were
a case where it did work. That's a good thing to know for
anybody doing other drivers...
-Matt
^ permalink raw reply
* Re: [PATCH 03/04] Freescale Ethernet combined driver
From: Pantelis Antoniou @ 2005-05-10 12:15 UTC (permalink / raw)
To: Dan Malek; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <f1e15a8d9ed033e850b56ca965754a43@embeddededge.com>
Dan Malek wrote:
>
> On May 10, 2005, at 7:17 AM, Pantelis Antoniou wrote:
>
>> This patch replace iopa use with virt_to_phys.
>
>
> Not gonna work .....
>
> When you map uncached on 8xx you get a new vmalloc()
> space. The virt_to_xxx macros don't work on those addresses.
> You need to use the dma_consistent() function, stash the
> real physical address it returns and then use it where
> appropriate.
>
Hmm. Correct. The dma_consistent() function will
do some cache flushing, but we don't really care about that
anyway.
Oh well. Patch will be forthcoming...
>> + W32(ep, fen_genfcc.fcc_rbase, virt_to_phys(fep->rx_bd_base));
>> + W32(ep, fen_genfcc.fcc_tbase, virt_to_phys(fep->tx_bd_base));
>
>
> I thought you were getting rid of these weirdo macros and
> write normal code for data structure access? Please .....
>
This is going to be difficult since the /net/drivers maintainer
insists on using them. I used to have direct data structure
accesses so it won't be difficult to change.
But we must have a consunsus.
> Thanks.
>
>
> -- Dan
>
>
>
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH 03/04] Freescale Ethernet combined driver
From: Dan Malek @ 2005-05-10 12:13 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <4280985D.80108@intracom.gr>
On May 10, 2005, at 7:17 AM, Pantelis Antoniou wrote:
> This patch replace iopa use with virt_to_phys.
Not gonna work .....
When you map uncached on 8xx you get a new vmalloc()
space. The virt_to_xxx macros don't work on those addresses.
You need to use the dma_consistent() function, stash the
real physical address it returns and then use it where
appropriate.
> + W32(ep, fen_genfcc.fcc_rbase, virt_to_phys(fep->rx_bd_base));
> + W32(ep, fen_genfcc.fcc_tbase, virt_to_phys(fep->tx_bd_base));
I thought you were getting rid of these weirdo macros and
write normal code for data structure access? Please .....
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 03/04] Freescale Ethernet combined driver
From: Pantelis Antoniou @ 2005-05-10 11:17 UTC (permalink / raw)
To: Matt Porter; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <20050509133808.A16776@cox.net>
[-- Attachment #1: Type: text/plain, Size: 517 bytes --]
Matt Porter wrote:
> On Mon, May 09, 2005 at 02:45:03PM +0300, Pantelis Antoniou wrote:
>
>>Hi
>>
>>The following patch is a combined FCC/FEC ethernet driver
>>for the Freescale line of PowerQUICCs.
>>
>>FECs on 8xx and FCCs on 82xx are supported.
>>
>>This part of the patch contains the mac drivers
>>for FEC & FCC.
>
>
> As mentioned on IRC, this needs to be scrubbed of all iopa() usage
> in favor of standard DMA API calls.
>
> -Matt
>
>
This patch replace iopa use with virt_to_phys.
Regards
Pantelis
[-- Attachment #2: fs_enet-iopa-kill.patch --]
[-- Type: text/x-patch, Size: 1311 bytes --]
Index: linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fcc.c
===================================================================
--- linux-2.6.11.7-fs_enet.orig/drivers/net/fs_enet/mac-fcc.c
+++ linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fcc.c
@@ -226,8 +226,8 @@ static void restart(struct net_device *d
__fcc_out8((char *)ep + i, 0);
/* point to bds */
- W32(ep, fen_genfcc.fcc_rbase, iopa((__u32)fep->rx_bd_base));
- W32(ep, fen_genfcc.fcc_tbase, iopa((__u32)fep->tx_bd_base));
+ W32(ep, fen_genfcc.fcc_rbase, virt_to_phys(fep->rx_bd_base));
+ W32(ep, fen_genfcc.fcc_tbase, virt_to_phys(fep->tx_bd_base));
/* Set maximum bytes per receive buffer.
* It must be a multiple of 32.
Index: linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fec.c
===================================================================
--- linux-2.6.11.7-fs_enet.orig/drivers/net/fs_enet/mac-fec.c
+++ linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fec.c
@@ -306,8 +306,8 @@ static void restart(struct net_device *d
/*
* Set receive and transmit descriptor base.
*/
- FW(fecp, r_des_start, iopa((__u32)fep->rx_bd_base));
- FW(fecp, x_des_start, iopa((__u32)fep->tx_bd_base));
+ FW(fecp, r_des_start, virt_to_phys(fep->rx_bd_base));
+ FW(fecp, x_des_start, virt_to_phys(fep->tx_bd_base));
fs_init_bds(dev);
^ permalink raw reply
* Re: [PATCH 2.6.11.7] Remove iopa()
From: Pantelis Antoniou @ 2005-05-10 11:10 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: PPC_LINUX
In-Reply-To: <428094E8.4060900@intracom.gr>
Pantelis Antoniou wrote:
> McMullan, Jason wrote:
>
>> iopa() is stupid. Remove it.
>>
>>
>>
>
> Jason take a look at virt_to_phys...
>
> extern inline unsigned long virt_to_phys(volatile void * address)
> {
> #ifndef CONFIG_APUS
> return (unsigned long) address - KERNELBASE;
> #else
> return iopa ((unsigned long) address);
> #endif
> }
>
> Maybe virt_to_xxx needs to go too?
>
Oops sorry. Maybe APUS needs to go instead :)
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH 2.6.11.7] Remove iopa()
From: Pantelis Antoniou @ 2005-05-10 11:03 UTC (permalink / raw)
To: McMullan, Jason; +Cc: PPC_LINUX
In-Reply-To: <1115672263.9050.52.camel@jmcmullan.timesys>
McMullan, Jason wrote:
> iopa() is stupid. Remove it.
>
>
>
Jason take a look at virt_to_phys...
extern inline unsigned long virt_to_phys(volatile void * address)
{
#ifndef CONFIG_APUS
return (unsigned long) address - KERNELBASE;
#else
return iopa ((unsigned long) address);
#endif
}
Maybe virt_to_xxx needs to go too?
Regards
Pantelis
^ permalink raw reply
* Re: [ANNOUNCE] mini_fo-0.6.0 overlay file system
From: Pantelis Antoniou @ 2005-05-10 10:57 UTC (permalink / raw)
To: Markus Klotzbuecher; +Cc: linuxppc-embedded
In-Reply-To: <20050509182747.GA27743@mary>
Markus Klotzbuecher wrote:
> mini_fo is a virtual kernel filesystem that can make read-only file
> systems writable. This is done by redirecting modifying operations to
> a writeable location called "storage directory", and leaving the
> original data in the "base directory" untouched. When reading, the
> file system merges the modifed and original data so that only the
> newest versions will appear. This occurs transparently to the user,
> who can access the data like on any other read-write file system.
>
> mini_fo was originally developed for use in embedded systems, and
> therefore is lightweight in terms of module size (~50K), memory usage
> and storage usage. Nevertheless it has proved usefull for other
> projects such as live cds or for sandboxing and testing.
>
> For more information and download of the sources visit the project
> page:
>
> http://www.denx.de/twiki/bin/view/Know/MiniFOHome
>
> ChangeLog for mini_fo-0-6-0:
> - support for 2.4 and 2.6 kernels.
> - mini_fo now implements all file system operations.
> - many bugfixes and code cleanup.
>
>
> Markus Klotzbuecher
Hi Markus.
This sounds interesting.
Could you post the patches in the list so that we can discuss
them properly?
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH 02/04] Freescale Ethernet combined driver
From: Pantelis Antoniou @ 2005-05-10 10:56 UTC (permalink / raw)
To: Ricardo Scop; +Cc: linuxppc-embedded
In-Reply-To: <200505091605.08630.scop@digitel.com.br>
Ricardo Scop wrote:
> Hi Pantelis,
>
> On Monday 09 May 2005 08:44, Pantelis Antoniou wrote:
>
>>Hi
>>
>>The following patch is a combined FCC/FEC ethernet driver
>>for the Freescale line of PowerQUICCs.
>>
>>FECs on 8xx and FCCs on 82xx are supported.
>>
>>This part of the patch contains the core driver.
>>
>
> and, inside the patch:
>
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
>
> Does this mean that the code is designed to be backwards compatible to 2.4.x
> kernel code? If so, I could give it a try and, maybe, even make sure that it
> keeps such compatibility.
>
> Best regards,
>
Yes the code support 2.4 also.
You need a diffent way to fill in the platform data though...
Regards
Pantelis
^ permalink raw reply
* Re: [PATCH 01/04] Freescale Ethernet combined driver
From: Pantelis Antoniou @ 2005-05-10 10:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <89f1e01d28e3fd391c2c636707a02be1@freescale.com>
Kumar Gala wrote:
> Any reason we dont allow this driver on 85xx? (should be same as 82xx)
>
> - kumar
>
I don't have a 85xx available, so I can't test.
You could try it if you have a board that can be supported.
Also there's the issue with >32bit physical addresses.
This might be more tricky.
Regards
Pantelis
^ permalink raw reply
* Re: PPC uImage build not reporting correctly
From: cpclark @ 2005-05-10 10:34 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Tom Rini, Linux Kernel list, linuxppc-embedded list
In-Reply-To: <20050510042828.GA8398@mars.ravnborg.org>
On Tue, 10 May 2005, Sam Ravnborg wrote:
> On Mon, May 09, 2005 at 10:19:01AM -0500, Kumar Gala wrote:
> >
> > On May 6, 2005, at 6:22 PM, <cpclark@xmission.com> wrote:
> >
> > >On Fri, 6 May 2005, Kumar Gala wrote:
> > > > I tried the following w/o success:
> > > >
> > > > $(obj)/uImage: $(obj)/vmlinux.gz
> > > > $(Q)rm -f $@
> > > > $(call if_changed,uimage)
> > > > @echo ' Image: $@' $(shell if [ -f $@ ]; then echo 'is ready'; else echo 'not made'; fi)
> > >
> > >Couldn't you eliminate the ($shell ..) construct altogether, like this?:
> > >
> > >$(obj)/uImage: $(obj)/vmlinux.gz
> > > $(Q)rm -f $@
> > > $(call if_changed,uimage)
> > > @echo -n '? Image: $@'
> > > @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
> >
> > Yes, and this seems to actually work.
> >
> > Sam, does this look reasonable to you. If so I will work up a patch.
>
> Looks ok - but I do not see why use of $(shell ...) did not work out.
As I understand it, the $(shell ...) construct doesn't "work" in the case
cited above because make evaluates/expands the $(shell ...) stuff while it
is parsing the makefile and building the command list--i.e. before it has
issued any commands to build anything. What seems to be desired in this
case is a file-existence test which runs "inline" with respect to the
preceding commands. The use of $(shell ...) inside a command
subverts/preempts that natural sequence. I think. :-)
Chris
^ permalink raw reply
* Re: How to increase kernel stack size?
From: Patrick Huesmann @ 2005-05-10 10:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <427FB3A5.5080702@gmail.com>
Just FYI:
The symbol INIT_TASK_SIZE defines the length of a union (task_union)
which holds the kernel stack. But when I define this value to be
larger than 8192, the kernel wouldn't boot.
So this value is probably hard-coded somewhere else.
BTW, I'm using 2.4.26
Does someone know how to increase the kernel stack size for PPC archs?
I really need more stack for my external interrupt b/c sometimes the
peripheral generates fast bursts on the external interrupt line, which
lead to kernel stack overflow.
(SA_INTERRUPT doesn't help because this is a realtime interrupt).
Any ideas?
TIA,
Patrick
^ permalink raw reply
* RE: Network Setup - HOW TO
From: Atit_Shah @ 2005-05-10 10:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3256 bytes --]
I had my router with IP address 172.19.56.218 and linux machine
172.19.60.11 connected with a normal cable. I had the system ping the
router with ethereal running.
Ethereal captured only the ARP packets, there were no ARP reply and on
the console of the system I would get "Destination Host unreachable".
Have enclosed the ethereal capture...
Atit
-----Original Message-----
From: Grant Likely [mailto:glikely@gmail.com]
Sent: Monday, May 09, 2005 12:07 PM
To: Atit_Shah
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Network Setup - HOW TO
On 5/8/05, Atit_Shah <Atit_Shah@satyam.com> wrote:
> My company uses the 172.19.x.x IP addresses, I want a PC with
> 192.168.x.x IP address to access the company network via a router. I
> have a router running Linux and having 2 Ethernet ports. I configured
> the systems in the following 2 ways:
So, two subnets:
Eth0 on subnet 192.168.0.0/255.255.0.0
Eth1 on subnet 172.19.0.0/255.255.0.0
>
> 1. Eth0 (LAN port) - 172.19.56.218
> Eth1 (WAN port) - 172.19.56.219
> Single System - 192.168.100.10 - IP Address
> 172.19.56.218 - Gateway
> 172.19.56.218 - DNS
This is wrong. IP address for Eth0 must be on the 192.168.0.0/16 subnet
>
> 2. Eth0 (LAN port) - 192.168.100.20
> Eth1 (WAN port) - 172.19.56.219
> Single System - 192.168.100.10 - IP Address
> 192.168.100.20 - Gateway
> 192.168.100.20 - DNS
This is correct, but the DNS server does not have to be your router.
>
> But I am not able to ping from the router to my single system in
either
> way.
> How should I configure router to make this possible for the 2 networks
> to communicate?
Is you netmask set right? Does /sbin/route show sane IP routes? What
do you see on the wire? (Use Ethereal on a third computer). If you
cannot ping then you've got a fundamental flaw in your configurations.
Get this working before worrying about DHCP or routing.
>
> The second question is how to run DHCP on my router so it can receive
a
> dynamic IP and assign dynamic IP when I power my router?
You need to run both dhcpd and dhcpcd. dhcpd to assign IP to your
client. dhcpcd to get an IP from the network.
It sounds like you need to brush up on your IP networking knowledge w/
linux. Go look at the howtos on www.tldp.org. Specifically on
networking and DHCP. You should get this stuff working on a regular
PC w/ 2 network cards running linux first before trying to get it
going on your embedded board.
Also, as I asked before, please include relevant output logs with your
posts and I strongly recommend sniffing the Ethernet traffic with a
tool like Ethereal.
g.
DISCLAIMER:
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.
[-- Attachment #2: ethereal --]
[-- Type: application/octet-stream, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] ppc32: small cpufreq update
From: Benjamin Herrenschmidt @ 2005-05-10 5:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list
Hi !
This patch adds a missing attribute to pmac cpufreq so that
"scaling_available_frequencies" works. It also cleans up the duplicate
definitions for low and high speed constants.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: John Clemens <clemej@alum.rpi.edu>
Index: linux-work/arch/ppc/platforms/pmac_cpufreq.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/pmac_cpufreq.c 2005-05-02 10:48:08.000000000 +1000
+++ linux-work/arch/ppc/platforms/pmac_cpufreq.c 2005-05-10 10:10:44.000000000 +1000
@@ -85,14 +85,11 @@
static int has_cpu_l2lve;
-#define PMAC_CPU_LOW_SPEED 1
-#define PMAC_CPU_HIGH_SPEED 0
-
/* There are only two frequency states for each processor. Values
* are in kHz for the time being.
*/
-#define CPUFREQ_HIGH PMAC_CPU_HIGH_SPEED
-#define CPUFREQ_LOW PMAC_CPU_LOW_SPEED
+#define CPUFREQ_HIGH 0
+#define CPUFREQ_LOW 1
static struct cpufreq_frequency_table pmac_cpu_freqs[] = {
{CPUFREQ_HIGH, 0},
@@ -100,6 +97,11 @@
{0, CPUFREQ_TABLE_END},
};
+static struct freq_attr* pmac_cpu_freqs_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
static inline void local_delay(unsigned long ms)
{
if (no_schedule)
@@ -355,7 +357,7 @@
static unsigned long prev_l3cr;
freqs.old = cur_freq;
- freqs.new = (speed_mode == PMAC_CPU_HIGH_SPEED) ? hi_freq : low_freq;
+ freqs.new = (speed_mode == CPUFREQ_HIGH) ? hi_freq : low_freq;
freqs.cpu = smp_processor_id();
if (freqs.old == freqs.new)
@@ -363,7 +365,7 @@
if (notify)
cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
- if (speed_mode == PMAC_CPU_LOW_SPEED &&
+ if (speed_mode == CPUFREQ_LOW &&
cpu_has_feature(CPU_FTR_L3CR)) {
l3cr = _get_L3CR();
if (l3cr & L3CR_L3E) {
@@ -371,8 +373,8 @@
_set_L3CR(0);
}
}
- set_speed_proc(speed_mode == PMAC_CPU_LOW_SPEED);
- if (speed_mode == PMAC_CPU_HIGH_SPEED &&
+ set_speed_proc(speed_mode == CPUFREQ_LOW);
+ if (speed_mode == CPUFREQ_HIGH &&
cpu_has_feature(CPU_FTR_L3CR)) {
l3cr = _get_L3CR();
if ((prev_l3cr & L3CR_L3E) && l3cr != prev_l3cr)
@@ -380,7 +382,7 @@
}
if (notify)
cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
- cur_freq = (speed_mode == PMAC_CPU_HIGH_SPEED) ? hi_freq : low_freq;
+ cur_freq = (speed_mode == CPUFREQ_HIGH) ? hi_freq : low_freq;
return 0;
}
@@ -423,7 +425,8 @@
policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
policy->cur = cur_freq;
- return cpufreq_frequency_table_cpuinfo(policy, &pmac_cpu_freqs[0]);
+ cpufreq_frequency_table_get_attr(pmac_cpu_freqs, policy->cpu);
+ return cpufreq_frequency_table_cpuinfo(policy, pmac_cpu_freqs);
}
static u32 __pmac read_gpio(struct device_node *np)
@@ -457,7 +460,7 @@
no_schedule = 1;
sleep_freq = cur_freq;
if (cur_freq == low_freq)
- do_set_cpu_speed(PMAC_CPU_HIGH_SPEED, 0);
+ do_set_cpu_speed(CPUFREQ_HIGH, 0);
return 0;
}
@@ -473,8 +476,8 @@
* is that we force a switch to whatever it was, which is
* probably high speed due to our suspend() routine
*/
- do_set_cpu_speed(sleep_freq == low_freq ? PMAC_CPU_LOW_SPEED
- : PMAC_CPU_HIGH_SPEED, 0);
+ do_set_cpu_speed(sleep_freq == low_freq ?
+ CPUFREQ_LOW : CPUFREQ_HIGH, 0);
no_schedule = 0;
return 0;
@@ -488,6 +491,7 @@
.suspend = pmac_cpufreq_suspend,
.resume = pmac_cpufreq_resume,
.flags = CPUFREQ_PM_NO_WARN,
+ .attr = pmac_cpu_freqs_attr,
.name = "powermac",
.owner = THIS_MODULE,
};
^ permalink raw reply
* Re: PPC uImage build not reporting correctly
From: Sam Ravnborg @ 2005-05-10 4:28 UTC (permalink / raw)
To: Kumar Gala
Cc: Tom Rini,
<cpclark@xmission.com> <cpclark@xmission.com>,
Linux Kernel list, linuxppc-embedded list
In-Reply-To: <b0aede90eb15562c0dd5a44c10d1b965@freescale.com>
On Mon, May 09, 2005 at 10:19:01AM -0500, Kumar Gala wrote:
>
> On May 6, 2005, at 6:22 PM, <cpclark@xmission.com> wrote:
>
> >On Fri, 6 May 2005, Kumar Gala wrote:
> > > I tried the following w/o success:
> > >
> >> $(obj)/uImage: $(obj)/vmlinux.gz
> >>???????? $(Q)rm -f $@
> > >???????? $(call if_changed,uimage)
> >>???????? @echo '? Image: $@' $(shell if [ -f $@ ]; then echo 'is
> >ready'; else
> > > echo 'not made'; fi)
> >
> >Couldn't you eliminate the ($shell ..) construct altogether, like
> >this?:
> >
> >$(obj)/uImage: $(obj)/vmlinux.gz
> >??????? $(Q)rm -f $@
> > ??????? $(call if_changed,uimage)
> >??????? @echo -n '? Image: $@'
> > ??????? @if [ -f $@ ]; then echo 'is ready' ; else echo 'not made'; fi
>
> Yes, and this seems to actually work.
>
> Sam, does this look reasonable to you. If so I will work up a patch.
Looks ok - but I do not see why use of $(shell ...) did not work out.
Please bring your working version forward.
Sam
^ permalink raw reply
* linux-2.6.10, ppc8280, odd ARP request
From: Richard Danter @ 2005-05-09 12:19 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am seeing an odd ARP request from an 8280 when using any of the FCC's
as eth0. Using SCC1 as eth0 seems fine.
My board boots using U-Boot. It tftp loads the kernel image via FCC2, so
I know the FCC's are working (I have tested the others too). This part
is fine, but once the kernel has loaded it tries to NFS mount the root
filesystem. When it gets to the point of looking up the RPC port it
first sends an ARP request for the server. When eth0 is any of the FCC's
I see a 59 byte packet on the wire (using ethereal). The server either
does not see the packet or just ignores it so there is no reply to the
board.
When I boot using SCC1 as eth0 the ARP request sent is 60 bytes long. It
is replied to and the NFS mount works.
I noticed that U-Boot also sends an ARP request before the tftp download
starts and it is 60 bytes long using both SCC and FCC ports. But as far
as I know, ARP requests can be varying length (the last few bytes seem
to be just padding).
Has anyone else seen anything like this? Any pointers where I should look?
Many thanks,
Rich
^ permalink raw reply
* [PATCH 2.6.11.7] Remove iopa()
From: McMullan, Jason @ 2005-05-09 20:57 UTC (permalink / raw)
To: PPC_LINUX
[-- Attachment #1.1: Type: text/plain, Size: 109 bytes --]
iopa() is stupid. Remove it.
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #1.2: iopa-removal.patch --]
[-- Type: text/x-patch, Size: 6678 bytes --]
--- linux-2.6.11.7/arch/ppc/8xx_io/fec.c 2005-05-09 16:53:52.000000000 -0400
+++ linux-2.6.11.7-noiopa/arch/ppc/8xx_io/fec.c 2005-05-09 16:51:27.000000000 -0400
@@ -1835,8 +1835,8 @@
/* Set receive and transmit descriptor base.
*/
- fecp->fec_r_des_start = iopa((uint)(fep->rx_bd_base));
- fecp->fec_x_des_start = iopa((uint)(fep->tx_bd_base));
+ fecp->fec_r_des_start = virt_to_phys(fep->rx_bd_base);
+ fecp->fec_x_des_start = virt_to_phys(fep->tx_bd_base);
fep->dirty_tx = fep->cur_tx = fep->tx_bd_base;
fep->cur_rx = fep->rx_bd_base;
--- linux-2.6.11.7/arch/ppc/kernel/ppc_ksyms.c 2005-05-09 16:53:52.000000000 -0400
+++ linux-2.6.11.7-noiopa/arch/ppc/kernel/ppc_ksyms.c 2005-05-09 16:43:53.000000000 -0400
@@ -146,8 +146,10 @@
EXPORT_SYMBOL(_outsw_ns);
EXPORT_SYMBOL(_insl_ns);
EXPORT_SYMBOL(_outsl_ns);
-EXPORT_SYMBOL(iopa);
-EXPORT_SYMBOL(mm_ptov);
+#ifdef CONFIG_APUS
+EXPORT_SYMBOL(virt_to_bus);
+EXPORT_SYMBOL(bus_to_virt);
+#endif
EXPORT_SYMBOL(ioremap);
#ifdef CONFIG_44x
EXPORT_SYMBOL(ioremap64);
--- linux-2.6.11.7/arch/ppc/mm/pgtable.c 2005-05-09 16:53:52.000000000 -0400
+++ linux-2.6.11.7-noiopa/arch/ppc/mm/pgtable.c 2005-05-09 16:49:35.000000000 -0400
@@ -403,10 +403,11 @@
return(retval);
}
+#ifdef CONFIG_APUS
/* Find physical address for this virtual address. Normally used by
* I/O functions, but anyone can call it.
*/
-unsigned long iopa(unsigned long addr)
+unsigned long virt_to_bus(void *addr)
{
unsigned long pa;
@@ -441,18 +442,11 @@
return(pa);
}
-/* This is will find the virtual address for a physical one....
- * Swiped from APUS, could be dangerous :-).
- * This is only a placeholder until I really find a way to make this
- * work. -- Dan
- */
-unsigned long
-mm_ptov (unsigned long paddr)
+void *bus_to_virt(unsigned long paddr)
{
- unsigned long ret;
-#if 0
+ void *ret;
if (paddr < 16*1024*1024)
- ret = ZTWO_VADDR(paddr);
+ ret = (void *)ZTWO_VADDR(paddr);
else {
int i;
@@ -466,16 +460,13 @@
goto exit;
}
}
-
- ret = (unsigned long) __va(paddr);
+
+ ret = (void *) __va(paddr);
}
exit:
#ifdef DEBUGPV
printk ("PTOV(%lx)=%lx\n", paddr, ret);
#endif
-#else
- ret = (unsigned long)paddr + KERNELBASE;
-#endif
return ret;
}
-
+#endif /* CONFIG_APUS */
--- linux-2.6.11.7/arch/ppc/platforms/apus_setup.c 2005-05-09 16:53:52.000000000 -0400
+++ linux-2.6.11.7-noiopa/arch/ppc/platforms/apus_setup.c 2005-05-09 16:47:38.000000000 -0400
@@ -385,34 +385,6 @@
}
}
-unsigned long mm_ptov (unsigned long paddr)
-{
- unsigned long ret;
- if (paddr < 16*1024*1024)
- ret = ZTWO_VADDR(paddr);
- else {
- int i;
-
- for (i = 0; i < kmap_chunk_count;){
- unsigned long phys = kmap_chunks[i++];
- unsigned long size = kmap_chunks[i++];
- unsigned long virt = kmap_chunks[i++];
- if (paddr >= phys
- && paddr < (phys + size)){
- ret = virt + paddr - phys;
- goto exit;
- }
- }
-
- ret = (unsigned long) __va(paddr);
- }
-exit:
-#ifdef DEBUGPV
- printk ("PTOV(%lx)=%lx\n", paddr, ret);
-#endif
- return ret;
-}
-
int mm_end_of_chunk (unsigned long addr, int len)
{
if (memory[0].addr + memory[0].size == addr + len)
--- linux-2.6.11.7/arch/ppc/syslib/m8260_pci_erratum9.c 2005-05-09 16:53:52.000000000 -0400
+++ linux-2.6.11.7-noiopa/arch/ppc/syslib/m8260_pci_erratum9.c 2005-05-09 16:44:59.000000000 -0400
@@ -261,7 +261,7 @@
int readb(volatile unsigned char *addr)
{
u8 val;
- unsigned long pa = iopa((unsigned long) addr);
+ unsigned long pa = virt_to_bus(addr);
if (!is_pci_mem(pa))
return in_8(addr);
@@ -273,7 +273,7 @@
int readw(volatile unsigned short *addr)
{
u16 val;
- unsigned long pa = iopa((unsigned long) addr);
+ unsigned long pa = virt_to_bus(addr);
if (!is_pci_mem(pa))
return in_le16(addr);
@@ -285,7 +285,7 @@
unsigned readl(volatile unsigned *addr)
{
u32 val;
- unsigned long pa = iopa((unsigned long) addr);
+ unsigned long pa = virt_to_bus(addr);
if (!is_pci_mem(pa))
return in_le32(addr);
--- linux-2.6.11.7/drivers/net/fec_8xx/fec_main.c 2005-05-09 16:53:52.000000000 -0400
+++ linux-2.6.11.7-noiopa/drivers/net/fec_8xx/fec_main.c 2005-05-09 16:52:52.000000000 -0400
@@ -278,8 +278,8 @@
/*
* Set receive and transmit descriptor base.
*/
- FW(fecp, r_des_start, iopa((__u32) (fep->rx_bd_base)));
- FW(fecp, x_des_start, iopa((__u32) (fep->tx_bd_base)));
+ FW(fecp, r_des_start, virt_to_bus(fep->rx_bd_base));
+ FW(fecp, x_des_start, virt_to_bus(fep->tx_bd_base));
fep->dirty_tx = fep->cur_tx = fep->tx_bd_base;
fep->tx_free = fep->tx_ring;
--- linux-2.6.11.7/include/asm-ppc/io.h 2005-05-09 16:53:52.000000000 -0400
+++ linux-2.6.11.7-noiopa/include/asm-ppc/io.h 2005-05-09 16:40:39.000000000 -0400
@@ -376,8 +376,6 @@
#endif
#define ioremap_nocache(addr, size) ioremap((addr), (size))
extern void iounmap(volatile void __iomem *addr);
-extern unsigned long iopa(unsigned long addr);
-extern unsigned long mm_ptov(unsigned long addr) __attribute_const__;
extern void io_block_mapping(unsigned long virt, phys_addr_t phys,
unsigned int size, int flags);
@@ -388,27 +386,24 @@
* address from the PCI point of view, thus buffer addresses also
* have to be modified [mapped] appropriately.
*/
+#ifdef CONFIG_APUS
+extern unsigned long virt_to_bus(volatile void * address);
+extern void * bus_to_virt(unsigned long address);
+#else
extern inline unsigned long virt_to_bus(volatile void * address)
{
-#ifndef CONFIG_APUS
if (address == (void *)0)
return 0;
return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;
-#else
- return iopa ((unsigned long) address);
-#endif
}
extern inline void * bus_to_virt(unsigned long address)
{
-#ifndef CONFIG_APUS
if (address == 0)
return NULL;
return (void *)(address - PCI_DRAM_OFFSET + KERNELBASE);
-#else
- return (void*) mm_ptov (address);
-#endif
}
+#endif
/*
* Change virtual addresses to physical addresses and vv, for
--- linux-2.6.11.7/include/asm-ppc/pgtable.h 2005-05-09 16:53:52.000000000 -0400
+++ linux-2.6.11.7-noiopa/include/asm-ppc/pgtable.h 2005-05-09 16:38:44.000000000 -0400
@@ -691,7 +691,6 @@
extern void cache_clear(__u32 addr, int length);
extern void cache_push(__u32 addr, int length);
extern int mm_end_of_chunk (unsigned long addr, int len);
-extern unsigned long iopa(unsigned long addr);
extern unsigned long mm_ptov(unsigned long addr) __attribute_const__;
/* Values for nocacheflag and cmode */
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 03/04] Freescale Ethernet combined driver
From: Matt Porter @ 2005-05-09 20:38 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <427F4D3F.1010802@intracom.gr>
On Mon, May 09, 2005 at 02:45:03PM +0300, Pantelis Antoniou wrote:
> Hi
>
> The following patch is a combined FCC/FEC ethernet driver
> for the Freescale line of PowerQUICCs.
>
> FECs on 8xx and FCCs on 82xx are supported.
>
> This part of the patch contains the mac drivers
> for FEC & FCC.
As mentioned on IRC, this needs to be scrubbed of all iopa() usage
in favor of standard DMA API calls.
-Matt
^ permalink raw reply
* Re: Writing a small test program - a bit off topic
From: McMullan, Jason @ 2005-05-09 20:04 UTC (permalink / raw)
To: Peter Asemann; +Cc: PPC_LINUX
In-Reply-To: <427F3441.2010108@web.de>
[-- Attachment #1: Type: text/plain, Size: 670 bytes --]
On Mon, 2005-05-09 at 11:58 +0200, Peter Asemann wrote:
> I *hope* this mail isn't very off topic. In principle it probably is,
> but I don't know a mailing list which is about writing test programs to
> test processors in order to debug a hardware to get linux running. Plus,
> I suppose there are people out there who could help me. So I hope you
> won't stone me for this post.
assuming 'foo.c' is your program, and you want to run it at origin 0.
Step 1) ppc8xx-linux-gcc -Dmain=_start -nostdlib foo.c -o foo
Step 2) ppc8xx-linux-objcopy foo -O binary foo.bin
Done!
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How to fix 8xx dcbst bug?
From: Dan Malek @ 2005-05-09 19:25 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Joakim Tjernlund, linux-ppc-embedded
In-Reply-To: <20050507214739.GF16996@logos.cnet>
On May 7, 2005, at 5:47 PM, Marcelo Tosatti wrote:
> So, for sys_read() v2.6 i-cache translation footprint is about 100%
> more than v2.4.
It could actually be something as "simple" as the organization
of the functions in the image. Would you also send along the
portion of the System.map that covers these kernel address
ranges? There is only one additional user space TLB, which
is probably the C library, all of the rest are kernel ones.
For example, what functions are in the range of 0xc009c00,
0xc009d000, 0xc009e000, and in the 0xc0003000
pages for your 2.4 kernel?
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 02/04] Freescale Ethernet combined driver
From: Ricardo Scop @ 2005-05-09 19:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <427F4D3B.6060403@intracom.gr>
Hi Pantelis,
On Monday 09 May 2005 08:44, Pantelis Antoniou wrote:
> Hi
>
> The following patch is a combined FCC/FEC ethernet driver
> for the Freescale line of PowerQUICCs.
>
> FECs on 8xx and FCCs on 82xx are supported.
>
> This part of the patch contains the core driver.
>
and, inside the patch:
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
Does this mean that the code is designed to be backwards compatible to 2.=
4.x=20
kernel code? If so, I could give it a try and, maybe, even make sure that=
it=20
keeps such compatibility.
Best regards,
--=20
Ricardo Scop.
\|/
___ -*-
(@ @)/|\
/ V \| R SCOP Consult.
/( )\ Linux-based communications
--^^---^^+------------------------------
rscop@matrix.com.br
+55 51 999-36-777
Porto Alegre, RS - BRazil
--
P. S.: "If you don't have time to do it right, when will you have time
to do it over?" -- Penny Hines =20
^ permalink raw reply
* How to increase kernel stack size?
From: Patrick Huesmann @ 2005-05-09 19:01 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
is there a way to set the kernel stack size (for interrupts) at compile
time?
I need to have more stack space for the external interrupt on a PPC-405.
BTW, I'm using a RTAI patch but it shouldn't matter as the realtime
interrupts use the same stack as Linux interrupts.
TIA,
Patrick
^ permalink raw reply
* USB on PQ3?
From: Kylo Ginsberg @ 2005-05-09 18:53 UTC (permalink / raw)
To: linuxppc-embedded
Hi folks,
What is the state of support for USB under PQ3 processors? We will be
using the 8555E. I've seen USB support mentioned here on a PQ2 and
8xx, but don't see that source in 2.6.12-rc4. Thanks for any
pointers.
Kylo
^ permalink raw reply
* Re: How to fix 8xx dcbst bug?
From: Marcelo Tosatti @ 2005-05-07 21:47 UTC (permalink / raw)
To: Dan Malek; +Cc: Joakim Tjernlund, linux-ppc-embedded
In-Reply-To: <52dc3ae70f883699b1e48b7d742afcaf@embeddededge.com>
On Sat, May 07, 2005 at 09:10:17PM -0400, Dan Malek wrote:
>
> On May 6, 2005, at 11:45 AM, Marcelo Tosatti wrote:
>
> >
> >Hi Dan,
> >
> >So, restarting this conversation...
>
> One of the things I don't want to lose sight of during
> all of this is the real performance problem in 2.6.
> Your test results show there is something that needs
> attention, regardless of using pinned entries. We
> need to continue some of this investigation, it
> affects all processors.
True.
Follows some useful data:
"itlb-content-before" and "itlb-content-after" are dumps of TLB cache
content before and after "sys_read()", for both v2.4 and v2.6.
The "diff" output shows which TLB's have been faulted in:
[marcelo@logos itlb]$ diff -u 24-itlb-content-before.txt 24-itlb-content-after.txt
| grep SPR | grep 816 | grep "+"
+SPR 816 : 0x0ffe800f 268337167
+SPR 816 : 0x0ffeb00f 268349455
+SPR 816 : 0xc009e01f -1073094625
+SPR 816 : 0xc009d01f -1073098721
+SPR 816 : 0xc000301f -1073729505
+SPR 816 : 0xc009c01f -1073102817
[marcelo@logos itlb]$ diff -u 24-itlb-content-before.txt 24-itlb-content-after.txt
| grep SPR | grep 818 | grep "+" | wc -l
6
Now v2.6:
[marcelo@logos itlb]$ diff -u 26-itlb-before.txt 26-itlb-after.txt
| grep 816 | grep SPR | grep "+"
+SPR 816 : 0x0feda16f 267231599
+SPR 816 : 0xc004b17f -1073434241
+SPR 816 : 0xc004a17f -1073438337
+SPR 816 : 0x0ff7e16f 267903343
+SPR 816 : 0x1001016f 268501359
+SPR 816 : 0xc000217f -1073733249
+SPR 816 : 0xc001617f -1073651329
+SPR 816 : 0xc002e17f -1073553025
+SPR 816 : 0xc010e17f -1072635521
+SPR 816 : 0xc002d17f -1073557121
+SPR 816 : 0xc010d17f -1072639617
+SPR 816 : 0xc000c17f -1073692289
+SPR 816 : 0xc000317f -1073729153
[marcelo@logos itlb]$ diff -u 26-itlb-before.txt 26-itlb-after.txt
| grep 816 | grep SPR | grep "+" | wc -l
13
So, for sys_read() v2.6 i-cache translation footprint is about 100%
more than v2.4.
I suspect that actual cache footprint is higher, too.
^ 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