* RE: Mpc5200 and ISP1106/1107 USB transceivers
From: Zeitler, Nathan @ 2005-08-11 13:27 UTC (permalink / raw)
To: linuxppc-embedded
IA0KID4gVXJsOiBodHRwOi8vb3psYWJzLm9yZy9waXBlcm1haWwvbGludXhwcGMtZW1iZWRkZWQv
YXR0YWNobWVudHMvMjAwNTA4MDUvYTJhYTBkNzgvYXR0YWNobWVudC0wMDAxLmVtbA0KDQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2VlbXMgdGhhdCBQaGlsaXBzIGhhcyBwdXQg
b3V0IGFuIGVycmF0YSBub3QgdG9vIGxvbmcgYWdvIGZvciB0aGlzIA0KY2hpcCB3aGljaCBpc24n
dCBpbiBhbnkgcHVibGljIGVycmF0YSBkb2N1bWVudCB0aGF0IHdlIGNvdWxkIGZpbmQuICANCkhl
cmUncyBob3cgaXQgcmVhZHM6DQoNClByb2JsZW06IA0KV2l0aCB0aGUgSVNQMTEwNS82IHVzZWQg
YXMgYSBVbml2ZXJzYWwgU2VyaWFsIEJ1cyAoVVNCKSANCnRyYW5zY2VpdmVyIGluIGEgSG9zdCBD
b250cm9sbGVyIGFwcGxpY2F0aW9uLCB3aGVuIGEgbG93LXNwZWVkIA0KZGV2aWNlIGlzIGNvbm5l
Y3RlZCwgaXQgZG9lcyBub3QgZ2V0IGVudW1lcmF0ZWQuIEZ1bGwtc3BlZWQgDQpkZXZpY2VzLCBo
b3dldmVyLCBhcmUgcHJvcGVybHkgZW51bWVyYXRlZC4NCg0KV2hlbiBwaW4gT0VfTiBnb2VzIEhJ
R0gsIHRoZSBJU1AxMTA1LzYgbXVzdCBiZSBpbiByZWNlaXZlIA0KbW9kZSBhbmQgdGhlIERNIGxp
bmUgc2hvdWxkIGJlIGRldGVjdGVkIGFzIEhJR0ggYmVjYXVzZSBvZiANCnRoZSBwdWxsLXVwIHJl
c2lzdG9yIG9uIHRoZSBE4oiSIGxpbmUgaW4gdGhlIGNhc2Ugb2YgdGhlIGxvdy1zcGVlZCANCmRl
dmljZS4gQnV0IGluIHRoZSBJU1AxMTA1LzYsIHRoZSBE4oiSIGxpbmUgcmlzZXMgdmVyeSBzbG93
bHksIHRha2luZyANCmFsbW9zdCAzMCBtcy4gVGhpcyBhZmZlY3RzIGVudW1lcmF0aW9uLg0KDQpX
b3JrYXJvdW5kOg0KSW4gdGhlIElTUDExMDUsIHRoZSBwcm9ibGVtIGNhbiBiZSByZXNvbHZlZCBi
eSBPUmluZyBWTyB3aXRoIA0KT0VfTiB0byBwcm9kdWNlIFZPIHRvIHRoZSBJU1AxMTA1LiBUaGlz
IGlzIGFwcGxpY2FibGUgd2hlbiANCnRoZSBNT0RFIHBpbiBpcyBjb25maWd1cmVkIGFzIExPVzsg
c2luZ2xlLWVuZGVkIGlucHV0IGRhdGEgDQppbnRlcmZhY2UuIA0KDQpUaGlzIGNpcmN1aXQgd2ls
bCBlbnN1cmUgdGhhdCBWTyBpcyBoZWxkIEhJR0ggdGlsbCBPRV9OIGlzIEhJR0gsIA0KZW5zdXJp
bmcgdGhhdCB0aGUgY29tcGVuc2F0aW9uIGxvZ2ljIGlzIG5vdCB0dXJuZWQgb24uDQoNCkluIHRo
ZSBJU1AxMTA2LCB0aGlzIG11c3QgYmUgaW1wbGVtZW50ZWQgYnkgQU5EaW5nIE9FIA0KKGludmVy
dGVkIE9FX04pIHdpdGggVk1PIHRvIHByb2R1Y2UgVk1PIHRvIHRoZSBJU1AxMTA2Lg0KDQoNCk5h
dGhhbiBaZWl0bGVyDQpIYXJkd2FyZSBFbmdpbmVlcg0KT3BlbiBTeXN0ZW1zIEludGVybmF0aW9u
YWwsIEluYy4NCjM2MDAgSG9sbHkgTGFuZSBOb3J0aCwgU3VpdGUgNDANCk1pbm5lYXBvbGlzLCBN
TiA1NTQ0Ny0xMjg2DQpQaG9uZTogKDc2MykgNTUxLTA1NTkNCkZheDogICAgICg3NjMpNTUxLTA3
NTANCkVtYWlsOiAgbnplaXRsZXJAb3NpaS5jb20NCg==
^ permalink raw reply
* where to get new BestComm API
From: Nuguru Susheel @ 2005-08-11 17:30 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Why do we need Bestcomm API new version for MPC5200 Rev B processor
Where can I get it from ???
Thanks a lot
^ permalink raw reply
* RE: copy_from_user problem
From: T Michael Turney @ 2005-08-11 14:29 UTC (permalink / raw)
To: murahari, linuxppc-dev
In-Reply-To: <0IL100L2IEO6NG@ms13.samsung.com>
[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]
Samsung Enterprise Portal mySingleMurahari,
I always start simple and work up to the harder things. Try to access a
single
long word in the ioctl, e.g.,
int
chr1_ioctl(struct inode *ino, struct file *filp, unsigned int cmd, unsigned
long arg)
{
int ret = 0;
unsigned int userdata;
switch(cmd)
{
case IOCTL_WIN_DEBUG_READ_CODE:
{
ret = get_user(userdata, (unsigned int *)arg);
......
}
}
}
The two O'Reilly books, Linux Device Drivers and Understanding the Linux
Kernel are also good
references for how to use the get_user and copy_from_user macros.
Hope this helps.
Cheers,
T.mike
-----Original Message-----
From: linuxppc-dev-bounces@ozlabs.org
[mailto:linuxppc-dev-bounces@ozlabs.org]On Behalf Of V MURAHARI
Sent: Wednesday, August 10, 2005 7:53 PM
To: linuxppc-dev@ozlabs.org
Subject: copy_from_user problem
Hello,
I am working on a character driver for reading and writing the registers
to FPGA in our system.
I am using driver ioctl to read/write to these registers of FPGA. As the
function call to the ioctl is being made, the printk trace shows that the
call goes to switch->copy_from_user. As soon as the call is made to
copy_from_user, the kernel crashes
Can someone help me with this problem?
****************************************************************************
***********************
Unhandled kernel unaligned access in
unaligned.c::emulate_load_store_insn, line 483
:
$0 : 00000000 10001f00 8fbf0034 02a01021 801157a0 8fe8e000 10001f00
ffff00ff
$8 : 8fe8ffe0 00001f00 00000000 00000003 74652053 8fe9fed8 0000000a
50434942
$16: 10001f01 00000001 801157a0 0000000f 8fe8fee8 00000104 00000000
0000000f
$24: 00000000 2ac0fdb0 8fe8e000 8fe8fe38 00000001
8012010c
Hi : 00000000
Lo : 00000000
epc : 8011f774 Tainted: GF
Status: 10001f02
Cause : 00800014
Process rsgbm (pid: 317, stackpage=8fe8e000)
Stack: 802d920a 0000000a 10001f01 0000003c 10001f01 0000003c 8012010c
80120104 caa8f356 8fe82008 8fe82000 0000000f 00000000 7fff7d00 7fff7d00
0000c001 00000003 10012808 ffffffff caa8e548 00004000 8fe9e272 00000150
7fff7d00 ffffffea 00000000 00000240 8fe82000 00000000 00000001 00000001
7ebff310 00000000 0000000f 8fef24e0 00000004 7ebff3e8 00000000 0000002e
80159c6c ...
Call Trace: [<8012010c>] [<80120104>] [<caa8f356>] [<caa8e548>]
[<80159c6c>]
[<8010a5c4>] [<80271dc4>]
Code: 8c820004 24110001 ac430000 <ac620004> ac800000 ac800004 ac800000
ac800004
8f820004
Unit Fault Handler !!! (INDEX=10)
****************************************************************************
**********************
int
chr1_ioctl(struct inode *ino, struct file *filp, unsigned int cmd,
unsigned long arg)
{
int ret = 0;
n2_debug_rw_reg *dw;
switch(cmd)
{
case IOCTL_WIN_DEBUG_READ_CODE:
{
n2_debug_rw_reg test;
printk("%s %d\n", current->comm, current->pid);
printk("%lx\n", arg);
copy_from_user(&test, (n2_debug_rw_reg*)arg,
sizeof(n2_debug_rw_reg));
printk("%lx %lx\n", ((n2_debug_rw_reg*)arg)->data,
((n2_debug_rw_reg*)arg)->
addr);
}
}
}
Thanks & Regards,
--Murahari
[-- Attachment #2: Type: text/html, Size: 7237 bytes --]
^ permalink raw reply
* CLOCK_TICK_RATE
From: Rune Torgersen @ 2005-08-11 15:13 UTC (permalink / raw)
To: linuxppc-dev
Hi
I have found that I need to set CLOCK_TICK_RATE (currently defined in
include/asm-ppc/timex.h) to something else.
Right now it is set to the PC timer clock value (1193180Hz). I need to
set it to the frequency of my decrementer instead (busfreq/4)
Right now the value of theis define means the wall-clock time on ALL ppc
(and ppc64) systems that does not use the old I386 timer freqyuencly
(most all?) are using the wrong values.
How can I change this to be platform dependant?=20
The other problem is that it has to be hardcoded on compile time, but
I'm not going to worry to much about that.
^ permalink raw reply
* Re: [PATCH] identify_ppc_sys_by_name_and_id function implementation final
From: Vitaly Bordug @ 2005-08-11 15:25 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded list
In-Reply-To: <20050811053032.GF5665@dmt.cnet>
Marcelo Tosatti wrote:
> On Wed, Aug 10, 2005 at 02:16:57PM -0500, Kumar Gala wrote:
>
>>+static int __init find_chip_by_name_and_id(char *name, u32 id)
>>+{
>>+ int ret = -1;
>>+ unsigned int i = 0;
>>+ unsigned int j = 0;
>>+ unsigned int dups = 0;
>>+
>>+ unsigned int matched[count_sys_specs()];
>>
>>Is is legit in the kernel to use dynamically sized array?
>
>
> kmalloc() is certainly safer - why not use it?
Practically , version with kmalloc works, but setup_arch and thus this
function is called before mem_init, so I just wonder if kmalloc can
handle this case. On the other hand, I don't like to deal with
alloc_bootmem() if mem_init_done!=1 and kmalloc otherwise (like ocp
does) just for the temporary buffer.
But it's the only _right_ way (or I 've missed something) - sure I'll
follow it.
--
Sincerely,
Vitaly
^ permalink raw reply
* [PATCH] cpm_uart: added missed spinlock initialization
From: Vitaly Bordug @ 2005-08-11 15:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
The lack of spin_lock_init causes badness in the preempt configuration.
The fix is trivial.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
--
Sincerely,
Vitaly
[-- Attachment #2: cpm_uart_spinlock.patch --]
[-- Type: text/x-patch, Size: 440 bytes --]
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -1045,6 +1045,7 @@ static int __init cpm_uart_console_setup
port =
(struct uart_port *)&cpm_uart_ports[cpm_uart_port_map[co->index]];
pinfo = (struct uart_cpm_port *)port;
+ spin_lock_init(&port->lock);
pinfo->flags |= FLAG_CONSOLE;
^ permalink raw reply
* GDB backtrace and signal trampolines
From: Hollis Blanchard @ 2005-08-11 15:54 UTC (permalink / raw)
To: PPC64-dev List, Linux PPC Dev
GDB 6.3 contains this code in ppc-linux-tdep.c:
static const struct frame_unwind *
ppc_linux_sigtramp_sniffer (struct frame_info *next_frame)
{
struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch
(next_frame));
if (frame_pc_unwind (next_frame)
> frame_unwind_register_unsigned (next_frame, SP_REGNUM))
/* Assume anything that is vaguely on the stack is a signal
trampoline. */
return &ppc_linux_sigtramp_unwind;
else
return NULL;
}
Essentially it says that any time the program counter is above the
stack pointer, we must be in a signal trampoline, and so GDB proceeds
to grope about for a struct rt_sigframe on the stack.
This is not a good assumption. I'm using a GDB stub to debug Xen, and
as it so happens, the Xen stack is below the Xen text. That means that
the above test always triggers, but of course there is no rt_sigframe
on the stack, and my backtrace runs away.
Would it make sense to limit the test to within a few hundred bytes of
the stack pointer? Or some better way to detect that the PC is in a
signal trampoline?
(Also, how can I test backtraces within a signal trampoline? I've
single-stepped my way into and out of a signal hander, and never saw
the PC inside the stack.)
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: CLOCK_TICK_RATE
From: Andreas Schwab @ 2005-08-11 16:14 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B859421@ismail.innsys.innovsys.com>
"Rune Torgersen" <runet@innovsys.com> writes:
> Hi
>
> I have found that I need to set CLOCK_TICK_RATE (currently defined in
> include/asm-ppc/timex.h) to something else.
I can't find any use of CLOCK_TICK_RATE in the kernel that is relevant for
ppc.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] MPC52xxx I2C: make algo use of I2C_RSTA
From: Bertrand BAUDET @ 2005-08-11 18:03 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
This patch makes use of I2C RESTART sequence when sending severals i2c_msg
instead of the STOP and START sequence.
Some I2C component reset there internal values when a STOP is sent.
(like the Ricoh rs5c372b I2C RTC)
Patch is against DENX linuxppc CVS
Regards,
Bertrand
[-- Attachment #2: mpc52xx_i2c-algo.patch --]
[-- Type: text/x-diff, Size: 1421 bytes --]
--- linuxppc_2_4_devel_new/drivers/i2c/i2c-algo-mpc5xxx.c 2004-05-08 18:49:39.000000000 +0200
+++ linuxppc_2_4_devel-lacie6/drivers/i2c/i2c-algo-mpc5xxx.c 2004-12-13 15:53:37.000000000 +0100
@@ -62,6 +62,14 @@
return;
}
+static void i2c_restart(struct i2c_algo_mpc5xxx_data *algo_data)
+{
+ struct mpc5xxx_i2c *regs = algo_data->regs;
+
+ mpc5xxx_out(®s->mcr, MPC5xxx_I2C_RSTA, MPC5xxx_I2C_RSTA);
+
+ return;
+}
static void i2c_stop(struct i2c_algo_mpc5xxx_data *algo_data)
{
@@ -311,13 +319,14 @@
int status;
int i;
+ if (wait_for_bb(algo_data))
+ return -EREMOTEIO;
+
+ i2c_start(algo_data);
+
for (i = 0; i < num; i++) {
pmsg = &msgs[i];
- if (wait_for_bb(algo_data))
- return -EREMOTEIO;
-
- i2c_start(algo_data);
mpc5xxx_do_address(algo_data, pmsg, adap->retries);
if (wait_for_pin(algo_data, &status)) {
@@ -332,17 +341,21 @@
if (pmsg->flags & I2C_M_RD) {
ret = mpc5xxx_readbytes(adap, pmsg->buf, pmsg->len);
- if (ret != pmsg->len)
+ if (ret != pmsg->len) {
+ i2c_stop(algo_data);
return (ret < 0) ? ret : -EREMOTEIO;
+ }
} else {
ret = mpc5xxx_sendbytes(adap, pmsg->buf, pmsg->len);
- if (ret != pmsg->len)
+ if (ret != pmsg->len) {
+ i2c_stop(algo_data);
return (ret < 0) ? ret : -EREMOTEIO;
+ }
}
-
- i2c_stop(algo_data);
+ if (i+1 < num) i2c_restart(algo_data);
}
-
+
+ i2c_stop(algo_data);
return num;
}
^ permalink raw reply
* FW: CLOCK_TICK_RATE
From: Rune Torgersen @ 2005-08-11 16:19 UTC (permalink / raw)
To: linuxppc-dev
CLOCK_TICK_RATE is the basis for TIME_NSEC which is used to update xtime
on every timer interrupt, so it is very relevant for PPC.
CLOCK_TICK_RATE is used for LATCH which is used for ACTHZ which in turn
is used for TIME_NSEC
=20
> -----Original Message-----
> From: Andreas Schwab [mailto:schwab@suse.de]=20
> Sent: Thursday, August 11, 2005 11:15
> To: Rune Torgersen
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: CLOCK_TICK_RATE
>=20
> "Rune Torgersen" <runet@innovsys.com> writes:
>=20
> > Hi
> >
> > I have found that I need to set CLOCK_TICK_RATE (currently=20
> defined in
> > include/asm-ppc/timex.h) to something else.
>=20
> I can't find any use of CLOCK_TICK_RATE in the kernel that is=20
> relevant for
> ppc.
>From a previous thread in linux-ppc-embedded (Wall clock accuracy)
> -----Original Message-----
> From: George Anzinger [mailto:george@mvista.com]=20
> Sent: Tuesday, August 09, 2005 19:07
>
> The problem here is that the CLOCK_TICK_RATE is not correctly=20
> defined.=20
> This should be the rate at which the decrementer is clocked in hertz.=20
> If this is properly defined the tick_nsec value will be what=20
> works to to=20
> be an integral number of these that gives an nsec value less than or=20
> equal to what LATCH says you should be using for the number of=20
> decrementer counts in a jiffie. It is important that this be=20
> correctly=20
> defined so that a) LATCH is right and b) the jiffies to/from=20
> conversions=20
> are done right. These conversions rely on TICK_NSEC to get the right=20
> answer. (Also, so you don't step into a computing mess, it=20
> is important=20
> that these be defined at compile time so the compiler can do=20
> the heavy=20
> lifting. If defined as variables the conversions will take a=20
> LOT longer=20
> (and use more code to boot).)
>=20
> If you are getting 999848, it would appear that you are using the x86=20
> value which, I assume, is NOT right for a PPC, but then the=20
> PPC is NOT=20
> my strong suit...
>
^ permalink raw reply
* 8xx: i2c-algo-8xx - fixed timeout detection and transmission errors
From: Tjernlund @ 2005-08-11 17:50 UTC (permalink / raw)
To: linuxppc-embedded
Try changing all
i2c->i2c_i2com |= 0x80; /* Begin transmission */
to
i2c->i2c_i2com |= 0x80 | 0x01; /* Begin transmission */
That should remove the need to do force_reinit(cpm) I hope.
See http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019600.html for a litte more info.
Also, I think you should remove the busy wait code. Its not needed IMHO.
Jocke
^ permalink raw reply
* Re: mpc8248 SEC -- interrupt handler 'is' invoked
From: Vikas Aggarwal @ 2005-08-11 18:48 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-embedded
In-Reply-To: <20050810103750.253a2b74.kim.phillips@freescale.com>
Hi Kim,
While browsing the SIU came across TESCR1(0x10040) & TESTCR2(0x10044). I
dumped it during module_init (00000000::00000000) and also in the ISR
after RNG was submitted to SEC core, this time I got
(0x814a0000::00000000).
TESCR1 after RNG descriptor submitted and SEC-ISR invoked=0x814a0000
bit 0 set -- 60x bus monitor timeout
bit 7-9= 101 --- SEC transaction
bit 11-15=01010 -- TT -- Single-beat-read or burst.
Now looking more into SIU -- SIU-BCR(bus Configuration register=0x10024)
has EBM bit , i set that. Did'nt make any difference. :(
I want to ask -- To make SEC 1.0 as master do i have to do several other
modifications to the SIU configurations so that 60x bus mode is enabled
for internal master. Like PPC_ACR(0x10028) has 4-7 bits as PRKM-parking
master and PPC_ACR=0100 stands for SEC engine.
-vikas
> On Tue, 9 Aug 2005 16:52:04 -0400 (EDT)
> "Vikas Aggarwal" <va824363@albany.edu> wrote:
>
>> The address returned by kmalloc=0x009ffc5c is 4 byte aligned.
>> Are u advicing that dma_map_single() should return 8 byte aligned ,
>> becuase thats what gets written into the Data-Paclet_descriptor later.
>>
> I wouldn't worry about alignment as much as the register write trace and
> checking the System Interface Unit and individual eu status registers.
>
> --
> Kim
>
^ permalink raw reply
* Re: [PATCH] Use todc on Mot PReP platforms
From: Tom Rini @ 2005-08-11 19:43 UTC (permalink / raw)
To: Matt Porter, Leigh Brown; +Cc: linuxppc-dev
In-Reply-To: <20050810093735.B22586@cox.net>
On Wed, Aug 10, 2005 at 09:37:35AM -0700, Matt Porter wrote:
> This restores behavior from 2.4 where PReP platforms identified
> as Motorola would calibrate the decrementer using the RTC. On
> real Motorola PReP hardware this isn't needed. However, in order
> to boot a stock 2.6 PReP kernel on qemu (which emulates a Motorola
> PReP system) it is necessary to allow it to calibrate the decrementer
> using an emulated RTC. If the decrementer rate is read from
> residual data then timing is screwed since a qemu PReP system typically
> runs much faster than the original hardware.
>
> If anybody has objections to this as the default, let me know. It
> still works (as did 2.4) on a couple of my Mot PReP boxes and doesn't
> affect the IBM PReP paths. My goal with this is to be able to run
> a stock 2.6 defconfig PReP build on qemu.
So, I like this, and not just because I'm playing with qemu as well.
Leigh, can you run this on any 'interesting' PReP you've got that might
tickle a bug here? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-11 19:59 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <c237b7e878e0c32f421209fa37b7a156@freescale.com>
On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
[snip]
> platforms/
> - platform-specific code laid out in the following
> directories:
> pSeries/
> iSeries/
> pmac/ (both 32 and 64-bit)
> classic32/ (platforms containing
> 6xx/7xx/74xx/8240/8241/8245)
> classic64/ (Maple?)
I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
for all of the ppc64's that have a 9xx in them (Maple), that aren't pmac
(which is a class of its own).
> 83xx/ (may collapse into classic 32 at some point)
> 86xx/ (may collapse into classic 32 at some point)
> pq2/ (may collapse into classic 32 at some point)
PQ2 is the marketing name for 82xx, lets just call it 82xx.
I don't like the idea of sticking subdirs in classic32/ either, but also
can't think of a better name for the catchall of 7xx and 74xx boards.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Kumar Gala @ 2005-08-11 20:13 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <20050811195927.GX3187@smtp.west.cox.net>
On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:
> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
>
> [snip]
>
>> platforms/
>> - platform-specific code laid out in the following
>> directories:
>> pSeries/
>> iSeries/
>> pmac/ (both 32 and 64-bit)
>> classic32/ (platforms containing
>> 6xx/7xx/74xx/8240/8241/8245)
>> classic64/ (Maple?)
>>
>
> I'm a bit ppc64-ignorant, but isn't 'pSeries' just a regular
> OpenFirmware-containing ppc64 box (like Maple) ? How about just 9xx/
> for all of the ppc64's that have a 9xx in them (Maple), that aren't
> pmac
> (which is a class of its own).
>
>
>> 83xx/ (may collapse into classic 32 at some point)
>> 86xx/ (may collapse into classic 32 at some point)
>> pq2/ (may collapse into classic 32 at some point)
>>
>
> PQ2 is the marketing name for 82xx, lets just call it 82xx.
The problem is that PQ2 describes a subset of 82xx (it nots
8240/8241/8245).
> I don't like the idea of sticking subdirs in classic32/ either, but
> also
> can't think of a better name for the catchall of 7xx and 74xx boards.
I dont think we where planning on subdirs in classic32.
- kumar
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Tom Rini @ 2005-08-11 20:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <BF36E655-9534-4FCD-9EB3-A1CD36C7981D@freescale.com>
On Thu, Aug 11, 2005 at 03:13:30PM -0500, Kumar Gala wrote:
>
> On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:
>
> >On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
> >
> >[snip]
[snip]
> >> 83xx/ (may collapse into classic 32 at some point)
> >> 86xx/ (may collapse into classic 32 at some point)
> >> pq2/ (may collapse into classic 32 at some point)
> >>
> >
> >PQ2 is the marketing name for 82xx, lets just call it 82xx.
>
> The problem is that PQ2 describes a subset of 82xx (it nots
> 8240/8241/8245).
All the more reason imho to stick all 82xx stuff under '82xx', rather
than classic32 or 'pq2'.
> >I don't like the idea of sticking subdirs in classic32/ either, but
> >also
> >can't think of a better name for the catchall of 7xx and 74xx boards.
>
> I dont think we where planning on subdirs in classic32.
I took "may collapse into classic 32 at some point" to mean "move into
classic32/ at some point", for some reason. collapsing the content into
classic32/ will bring us back to the bad-old-days of everything in
platforms/ (or kernel/).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Olaf Hering @ 2005-08-11 20:25 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <c237b7e878e0c32f421209fa37b7a156@freescale.com>
On Wed, Aug 10, Becky Bruce wrote:
> boot/
> - Pre-kernel execution shims and pre-passes.
> - Convert firmware reprensentations (bi_recs, OF Dev-Trees,
> bootx,bd_t) to flat-dev-trees.
> - Includes merged files from arch/ppc*/boot/ trees, plus
> prom_init.c from arch/ppc64/kernel.
This should live outside the kernel source, in a $mkzimage project.
^ permalink raw reply
* 8260 fcc_enet driver newbie question
From: Vijay Kumar @ 2005-08-11 5:47 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: dmalek
I was going through the fcc_enet driver
(linux-2.6.12.2/arch/ppc/8260_io/fcc_enet.c).
The driver accesses the CPM memory map using
immap = (cpm2_map_t *)CPM_MAP_ADDR;
There is also a global variable cpm2_immr defined in
arch/ppc/syslib/cpm2_common.c
If I were to write a new driver which one should I use
to access the CPM memory map?
Vijay
^ permalink raw reply
* Re: [PATCH] add field to struct ocp_func_emac_data for platform-specific unsupported PHY features
From: Wade Farnsworth @ 2005-08-11 20:42 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050808164457.C9951@cox.net>
[-- Attachment #1: Type: text/plain, Size: 530 bytes --]
On Mon, 2005-08-08 at 16:44, Matt Porter wrote:
(snip)
>
> Could you update this field (and related usages) to be "phy_ftr_exc"?
> For "Excluded phy features". Eugene and I discussed this on IRC and
> think it's a better name...for one it starts with the phy_ prefix like
> other related phy data. Except for that, it's ready for upstream.
>
> Thanks,
> Matt
Here is the updated patch with the field renamed to "phy_ftr_exc"
instead of "feat_unsupp".
-Wade Farnsworth
Signed-off-by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: ibm-emac-phy-feat-exc-ppc.patch --]
[-- Type: text/x-patch, Size: 3264 bytes --]
diff -upr linux-2.6/arch/ppc/platforms/4xx/bamboo.c linux-2.6-dev/arch/ppc/platforms/4xx/bamboo.c
--- linux-2.6/arch/ppc/platforms/4xx/bamboo.c 2005-08-11 13:29:30.000000000 -0700
+++ linux-2.6-dev/arch/ppc/platforms/4xx/bamboo.c 2005-08-11 13:15:59.000000000 -0700
@@ -123,33 +123,69 @@ bamboo_map_irq(struct pci_dev *dev, unsi
static void __init bamboo_set_emacdata(void)
{
- unsigned char * selection1_base;
+ u8 * base_addr;
struct ocp_def *def;
struct ocp_func_emac_data *emacdata;
- u8 selection1_val;
+ u8 val;
int mode;
+ u32 excluded = 0;
- selection1_base = ioremap64(BAMBOO_FPGA_SELECTION1_REG_ADDR, 16);
- selection1_val = readb(selection1_base);
- iounmap((void *) selection1_base);
- if (BAMBOO_SEL_MII(selection1_val))
+ base_addr = ioremap64(BAMBOO_FPGA_SELECTION1_REG_ADDR, 16);
+ val = readb(base_addr);
+ iounmap((void *) base_addr);
+ if (BAMBOO_SEL_MII(val))
mode = PHY_MODE_MII;
- else if (BAMBOO_SEL_RMII(selection1_val))
+ else if (BAMBOO_SEL_RMII(val))
mode = PHY_MODE_RMII;
else
mode = PHY_MODE_SMII;
- /* Set mac_addr and phy mode for each EMAC */
+ /*
+ * SW2 on the Bamboo is used for ethernet configuration and is accessed
+ * via the CONFIG2 register in the FPGA. If the ANEG pin is set,
+ * overwrite the supported features with the settings in SW2.
+ *
+ * This is used as a workaround for the improperly biased RJ-45 sockets
+ * on the Rev. 0 Bamboo. By default only 10baseT is functional.
+ * Removing inductors L17 and L18 from the board allows 100baseT, but
+ * disables 10baseT. The Rev. 1 has no such limitations.
+ */
+
+ base_addr = ioremap64(BAMBOO_FPGA_CONFIG2_REG_ADDR, 8);
+ val = readb(base_addr);
+ iounmap((void *) base_addr);
+ if (!BAMBOO_AUTONEGOTIATE(val)) {
+ excluded |= SUPPORTED_Autoneg;
+ if (BAMBOO_FORCE_100Mbps(val)) {
+ excluded |= SUPPORTED_10baseT_Full;
+ excluded |= SUPPORTED_10baseT_Half;
+ if (BAMBOO_FULL_DUPLEX_EN(val))
+ excluded |= SUPPORTED_100baseT_Half;
+ else
+ excluded |= SUPPORTED_100baseT_Full;
+ } else {
+ excluded |= SUPPORTED_100baseT_Full;
+ excluded |= SUPPORTED_100baseT_Half;
+ if (BAMBOO_FULL_DUPLEX_EN(val))
+ excluded |= SUPPORTED_10baseT_Half;
+ else
+ excluded |= SUPPORTED_10baseT_Full;
+ }
+ }
+
+ /* Set mac_addr, phy mode and unsupported phy features for each EMAC */
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
emacdata = def->additions;
memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
emacdata->phy_mode = mode;
+ emacdata->phy_feat_exc = excluded;
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
emacdata = def->additions;
memcpy(emacdata->mac_addr, __res.bi_enet1addr, 6);
emacdata->phy_mode = mode;
+ emacdata->phy_feat_exc = excluded;
}
static int
diff -upr linux-2.6/include/asm-ppc/ibm_ocp.h linux-2.6-dev/include/asm-ppc/ibm_ocp.h
--- linux-2.6/include/asm-ppc/ibm_ocp.h 2005-08-11 13:30:02.000000000 -0700
+++ linux-2.6-dev/include/asm-ppc/ibm_ocp.h 2005-08-11 13:12:34.000000000 -0700
@@ -67,6 +67,7 @@ struct ocp_func_emac_data {
int phy_mode; /* PHY type or configurable mode */
u8 mac_addr[6]; /* EMAC mac address */
u32 phy_map; /* EMAC phy map */
+ u32 phy_feat_exc; /* Excluded PHY features */
};
/* Sysfs support */
^ permalink raw reply
* Re: 8260 fcc_enet driver newbie question
From: Dan Malek @ 2005-08-11 21:00 UTC (permalink / raw)
To: vijaykumar; +Cc: dmalek, linuxppc-embedded
In-Reply-To: <1123739278.19079.13.camel@localhost.localdomain>
On Aug 11, 2005, at 1:47 AM, Vijay Kumar wrote:
> I was going through the fcc_enet driver
> (linux-2.6.12.2/arch/ppc/8260_io/fcc_enet.c).
This has been replaced by the new net/fs_enet, right?
> The driver accesses the CPM memory map using
> immap = (cpm2_map_t *)CPM_MAP_ADDR;
Yes, and that's wrong. You should at least use
ioremap(), and we recently had discussions about
whether to create some properly named functions
or macros to return common addresses like the
CPM space.
> There is also a global variable cpm2_immr defined in
> arch/ppc/syslib/cpm2_common.c
I know, but we shouldn't be doing that any longer.
> If I were to write a new driver which one should I use
> to access the CPM memory map?
For now, at least ioremap() the space in your driver
and cache the pointer. I'd like to quickly get a couple of
these other supporting functions done to use, though.
Thanks.
-- Dan
^ permalink raw reply
* What's wrong with the serial port?
From: Shawn Jin @ 2005-08-11 22:41 UTC (permalink / raw)
To: ppcembed
Hi,
I'm porting linux 2.6.11.4 to a custom SoC with ppc440 core. The UART
is 16550 compatible. U-Boot is already running fine.
When the kernel is booting, it gets to the point where console_init()
is called, which calls individual early console initialization
functions. In my case it's serial8250_console_init(). Before
register_console() is called in serial8250_console_init(), everything
seems fine because the debugging logs are printed on the serial port.
But once register_console() is called, the serial port continues
spitting out =E0. See the following message. What's wrong?
Any hints are appreciated!
Boot reached stage 4 =
=20
Boot reached stage 5 =
=20
Boot reached stage 6 =
=20
OK =
=20
Boot reached stage 7 =
=20
Boot reached stage 8 =
=20
## Current stack ends at 0x01FC6B80 =3D> set upper limit to 0x00800000 =
=20
## cmdline at 0x007FFF00 ... 0x007FFF10 =
=20
bd address =3D 0x01FC6F90 =
=20
memstart =3D 0x00000000 =
=20
memsize =3D 0x02000000 =
=20
flashstart =3D 0x00000000 =
=20
flashsize =3D 0x00000000 =
=20
flashoffset =3D 0x00000000 =
=20
sramstart =3D 0x00000000 =
=20
sramsize =3D 0x00000000 =
=20
bootflags =3D 0x00000000 =
=20
intfreq =3D 400 MHz =
=20
busfreq =3D 266 MHz =
=20
ethaddr =3D 00:00:00:00:00:00 =
=20
IP addr =3D 0.0.0.0 =
=20
baudrate =3D 115200 bps =
=20
Boot reached stage 14 =
=20
No initrd =
=20
## Transferring control to Linux (at address 00000000) ... =
=20
Boot reached stage 15 =
=20
id mach(): done =
=20
MMU:enter =
=20
MMU:hw init =
=20
MMU:mapin =
=20
MMU:setio =
=20
MMU:exit =
=20
setup_arch: enter =
=20
setup_arch: bootmem =
=20
arch: exit =
=20
=E0=E0=E0=E0=E0=E0 =20
-Shawn.
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Becky Bruce @ 2005-08-11 22:41 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <20050811201821.GY3187@smtp.west.cox.net>
>
>>> I don't like the idea of sticking subdirs in classic32/ either, but
>>> also
>>> can't think of a better name for the catchall of 7xx and 74xx boards.
>>
>> I dont think we where planning on subdirs in classic32.
>
> I took "may collapse into classic 32 at some point" to mean "move into
> classic32/ at some point", for some reason. collapsing the content
> into
> classic32/ will bring us back to the bad-old-days of everything in
> platforms/ (or kernel/).
My apologies - this wasn't at all clear in the proposal. The plan at
present is to not have subdirs under classic32. By "collapsing into
classic32", I meant a move to a more common code base, not a wholescale
copy of the existing files into classic32.
Cheers,
-B
^ permalink raw reply
* Re: RFC: proposed arch/powerpc directory structure
From: Kumar Gala @ 2005-08-11 23:07 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, Gill Becky-BGILL, linuxppc64-dev
In-Reply-To: <20050811201821.GY3187@smtp.west.cox.net>
On Aug 11, 2005, at 3:18 PM, Tom Rini wrote:
> On Thu, Aug 11, 2005 at 03:13:30PM -0500, Kumar Gala wrote:
>
>>
>> On Aug 11, 2005, at 2:59 PM, Tom Rini wrote:
>>
>>
>>> On Wed, Aug 10, 2005 at 11:45:10AM -0500, Becky Bruce wrote:
>>>
>>> [snip]
>>>
> [snip]
>
>>>> 83xx/ (may collapse into classic 32 at some point)
>>>> 86xx/ (may collapse into classic 32 at some point)
>>>> pq2/ (may collapse into classic 32 at some point)
>>>>
>>>>
>>>
>>> PQ2 is the marketing name for 82xx, lets just call it 82xx.
>>>
>>
>> The problem is that PQ2 describes a subset of 82xx (it nots
>> 8240/8241/8245).
>>
>
> All the more reason imho to stick all 82xx stuff under '82xx', rather
> than classic32 or 'pq2'.
I think this causes confusion. the reason we suggested pq2 and
classic32 was to handle things like sandpoint. Sandpoint would live
in classic32. The confusion partial comes from the fact that we can
run 8240/1/5 on a Sandpoint. The thinking was everything that was
6xx/7xx/74xx + things like 8240/1/5 which can be thought of as 603 +
10x bridge would be classic32.
If it was 82xx w/o a CPM it went into classic32. If it was a 82xx w/
CPM it went into pq2. The idea being that we might be able to build
kernels in either directory that supported a large number of boards
with one image.
Anyways, that was the thought process to try and keep things sane.
(Which it may not ;)
- kumar
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Eugene Surovegin @ 2005-08-11 23:14 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b050811154148164691@mail.gmail.com>
On Thu, Aug 11, 2005 at 03:41:21PM -0700, Shawn Jin wrote:
> Hi,
>
> I'm porting linux 2.6.11.4 to a custom SoC with ppc440 core. The UART
> is 16550 compatible. U-Boot is already running fine.
>
> When the kernel is booting, it gets to the point where console_init()
> is called, which calls individual early console initialization
> functions. In my case it's serial8250_console_init(). Before
> register_console() is called in serial8250_console_init(), everything
> seems fine because the debugging logs are printed on the serial port.
> But once register_console() is called, the serial port continues
> spitting out ?. See the following message. What's wrong?
>
> Any hints are appreciated!
>
> Boot reached stage 4
> Boot reached stage 5
> Boot reached stage 6
> OK
> Boot reached stage 7
> Boot reached stage 8
> ## Current stack ends at 0x01FC6B80 => set upper limit to 0x00800000
> ## cmdline at 0x007FFF00 ... 0x007FFF10
> bd address = 0x01FC6F90
> memstart = 0x00000000
> memsize = 0x02000000
> flashstart = 0x00000000
> flashsize = 0x00000000
> flashoffset = 0x00000000
> sramstart = 0x00000000
> sramsize = 0x00000000
> bootflags = 0x00000000
> intfreq = 400 MHz
> busfreq = 266 MHz
> ethaddr = 00:00:00:00:00:00
> IP addr = 0.0.0.0
> baudrate = 115200 bps
> Boot reached stage 14
> No initrd
> ## Transferring control to Linux (at address 00000000) ...
> Boot reached stage 15
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> arch: exit
> ??????
Try disabling early text debugging (all that "MMU:..." stuff).
--
Eugene
^ permalink raw reply
* Re: What's wrong with the serial port?
From: Eugene Surovegin @ 2005-08-11 23:17 UTC (permalink / raw)
To: Shawn Jin, ppcembed
In-Reply-To: <20050811231454.GA5796@gate.ebshome.net>
On Thu, Aug 11, 2005 at 04:14:54PM -0700, Eugene Surovegin wrote:
> > MMU:exit
> > setup_arch: enter
> > setup_arch: bootmem
> > arch: exit
> > ??????
>
> Try disabling early text debugging (all that "MMU:..." stuff).
>
Also, make sure you pass correct "console=..." line to the kernel
(with correct device name and baud rate).
--
Eugene
^ 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