* RE: Question for all the folks who are ALSO building custom MPC5200boards
From: Andrew Dennison @ 2005-02-09 22:12 UTC (permalink / raw)
To: 'Caruso, Nick', linuxppc-embedded
In-Reply-To: <712A2DEC228C7448978CBD7A7AD5B090592CB5@fever.wardrobe.irobot.com>
On , linuxppc-embedded-bounces@ozlabs.org wrote:
> I spoze this is slightly off topic, but... since a number of
> people have recently mentioned they're building custom MPC5200 boards:
>=20
> Have any of you had trouble with the 32kHz oscillator, when
> trying to use the crystal-and-passive-network approach
> instead of the big-ugly-reliable-metal-can-oscillator
> technique? Anyone actually get the crystal to oscillate properly?
>=20
> Replies off list would be fine if this is too off-topic...
>=20
> best regards,
> Nick Caruso
No problems here. Thought I would have to tweak some of the values I =
chose
but it just worked.
^ permalink raw reply
* Re: ppc405 core, VIA VT82C686A chipset, linux_2.4.22_pre5, and IDE DMA woes
From: John F Davis @ 2005-02-09 20:53 UTC (permalink / raw)
To: Lawrence E. Bakst; +Cc: linuxppc-embedded
In-Reply-To: <p0611041bbe2f959b9dda@mail.iridescent.org>
"Lawrence E. Bakst" <ml@iridescent.org>
02/09/2005 05:34 AM
To
John F Davis/Raleigh/IBM@ibmus, linuxppc-embedded@ozlabs.org
cc
Subject
Re: ppc405 core, VIA VT82C686A chipset, linux_2.4.22_pre5, and IDE
DMA woes
1. Can you say exactly which 405 core you are using?
D4V6
2. Is it Xilinx?
No
3. Have you read all the eratta for your core?
Yes
4. How is the VIA VT82C686A hooked to the 405? Via a bus mastering EBC?
PCI PLB Macro
Best,
leb
^ permalink raw reply
* RE: MPC5200 JTAG/BDM Flash Burning
From: Caruso, Nick @ 2005-02-09 20:22 UTC (permalink / raw)
To: Jerry Van Baren, Mark Chambers; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
Well, I said this privately, but I guess I'll say it in public as well - we like the BDI 2000.
I don't have a huge amount of experience with it, but I can vouch that it works fine with both the lite5200 and our custom MPC5200 board. We also bought ours from Ultimate Solutions. (Hi Fahd!)
best regards,
Nick Caruso
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org on behalf of Jerry Van Baren
Sent: Wed 2/9/2005 3:09 PM
P.S. The BDI2000 gets my endorsement (disclaimer: my experience is with
the 82xx family, not the 5200). You can pay more, but why settle for less?
[-- Attachment #2: Type: text/html, Size: 1089 bytes --]
^ permalink raw reply
* Question for all the folks who are ALSO building custom MPC5200 boards
From: Caruso, Nick @ 2005-02-09 20:23 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 473 bytes --]
I spoze this is slightly off topic, but... since a number of people have recently mentioned they're building custom MPC5200 boards:
Have any of you had trouble with the 32kHz oscillator, when trying to use the crystal-and-passive-network approach instead of the big-ugly-reliable-metal-can-oscillator technique? Anyone actually get the crystal to oscillate properly?
Replies off list would be fine if this is too off-topic...
best regards,
Nick Caruso
[-- Attachment #2: Type: text/html, Size: 945 bytes --]
^ permalink raw reply
* Re: MPC5200 JTAG/BDM Flash Burning
From: Wolfgang Denk @ 2005-02-09 20:33 UTC (permalink / raw)
To: Eric N. Johnson (ACD); +Cc: linuxppc-embedded
In-Reply-To: <6.2.1.2.1.20050209131409.02b2b718@mail.int.acdstar.com>
In message <6.2.1.2.1.20050209131409.02b2b718@mail.int.acdstar.com> you wrote:
> I'm working on a custom MPC5200 board based heavily on the IceCube design
> from Motorola/Freescale. We plan to use the u-boot bootloader.
>
> I'm looking for a tool to allow us to burn u-boot into the flash memory on
> new board (with all flash devices unprogrammed). Ideally, I'd like
If you consider the fact that besides fash burning you may also want
to have a working hardware debugger, you should go for a BDI2000 -
especially for Linux, when MMU support is needed.
> Both the "MPCBDM" and "bdm4gdb" projects haven't been updated for
> years. The BDM-Tools project is more active, but only seems to support
Tha't mostly because they are just working fine for the class of
devices they have been designed for. The MPC5200 has no BDM
interface, but a JTAG based debug interface for which it is
impossible to get the necessary specifications without an NDA - an
NDA which prevents any implementation under GPL. Complain with
Freescale.
> The 5200lite "IceCube" demo board came with a Metrowerks "Wiretap" BDM
> interface, and a Green Hills "Slingshot" BDM module, but these seems to
> require a large (and expensive) windows based "Development environment"
And they have no idea how do deal with virtual addresses.
> We may have to write our own JTAG based pin-wiggler, but this solution
> tends to be extremely slow.
It may be difficult to get the required documentation from Freescale,
and then you will probably spend more money (in terms of your time)
than you have to pay for a working tool (BDI2000).
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
Clothes make the man. Naked people have little or no influence on
society. - Mark Twain
^ permalink raw reply
* Re: MPC5200 JTAG/BDM Flash Burning
From: Jerry Van Baren @ 2005-02-09 20:09 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
In-Reply-To: <002501c50ee2$852b4390$0301a8c0@chuck2>
Mark Chambers wrote:
>
> You could also look at magraigor.com. I had problems with their 5200 device
> but they've probably got them worked out by now.
>
> Mark Chambers
That is http://macraigor.com/ of course ;-).
gvb
P.S. The BDI2000 gets my endorsement (disclaimer: my experience is with
the 82xx family, not the 5200). You can pay more, but why settle for less?
^ permalink raw reply
* Re: MPC5200 JTAG/BDM Flash Burning
From: Mark Chambers @ 2005-02-09 20:04 UTC (permalink / raw)
To: linuxppc-embedded, Eric N. Johnson (ACD)
In-Reply-To: <6.2.1.2.1.20050209131409.02b2b718@mail.int.acdstar.com>
> I'm working on a custom MPC5200 board based heavily on the IceCube design
> from Motorola/Freescale. We plan to use the u-boot bootloader.
>
I'm doing the same.
> I'm looking for a tool to allow us to burn u-boot into the flash memory on
> new board (with all flash devices unprogrammed). Ideally, I'd like
> something like the Jflash-linux tool used with StrongARM linux, or a
> stand-along linux tool that lets us burn the memory.
>
The BDI2000 from abatron, which in the US you probably want to get
from www.ultsol.com (send my commision to...). The difference between
the BDI product and others that my have similar spec sheets is that it
actually works, including the flash burning portions.
Once you have u-boot and/or the kernel up you can use them to update
flash.
> Both the "MPCBDM" and "bdm4gdb" projects haven't been updated for
> years. The BDM-Tools project is more active, but only seems to support
> 68k/Coldfire processors.
>
As I understand it, Freescale has not publicly released the OCD interface
so that's why it's not supported in the open source community.
> The 5200lite "IceCube" demo board came with a Metrowerks "Wiretap" BDM
> interface, and a Green Hills "Slingshot" BDM module, but these seems to
> require a large (and expensive) windows based "Development environment"
> which is far more than we need. Are there linux based drivers for either
> of these?
>
You could also look at magraigor.com. I had problems with their 5200 device
but they've probably got them worked out by now.
Mark Chambers
P.S. Love the way you play the guitar!
^ permalink raw reply
* MPC5200 JTAG/BDM Flash Burning
From: Eric N. Johnson (ACD) @ 2005-02-09 19:31 UTC (permalink / raw)
To: linuxppc-embedded
I'm working on a custom MPC5200 board based heavily on the IceCube design
from Motorola/Freescale. We plan to use the u-boot bootloader.
I'm looking for a tool to allow us to burn u-boot into the flash memory on
new board (with all flash devices unprogrammed). Ideally, I'd like
something like the Jflash-linux tool used with StrongARM linux, or a
stand-along linux tool that lets us burn the memory.
Both the "MPCBDM" and "bdm4gdb" projects haven't been updated for
years. The BDM-Tools project is more active, but only seems to support
68k/Coldfire processors.
The 5200lite "IceCube" demo board came with a Metrowerks "Wiretap" BDM
interface, and a Green Hills "Slingshot" BDM module, but these seems to
require a large (and expensive) windows based "Development environment"
which is far more than we need. Are there linux based drivers for either
of these?
We may have to write our own JTAG based pin-wiggler, but this solution
tends to be extremely slow.
Thanks
Eric
------------------------------------
Eric Johnson, Electrical Engineer
Advanced Communication Design
7901 12th Avenue South
Bloomington, MN 55425
Ph: 952-854-4000 Fax: 952-854-5774
^ permalink raw reply
* Re: Are the I2C drivers on MPC8540 Kernel 2.6.10 working?
From: Kumar Gala @ 2005-02-09 19:26 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <420A4CF3.5090902@anagramm.de>
One issue with the 2.6.10 driver was it was very slow. I changed some=20=
sleep calls in 2.6.11 to improve its performance. You may want to try=20=
grabbing the driver out of 2.6.11-rc3 and see if that helps also.
- kumar
On Feb 9, 2005, at 11:48 AM, Clemens Koller wrote:
> Hello,
>
> My questions:
> Is I2C and the Real Time Clock stuff working for the MPC8540
> in Kernel 2.6.10?
> Are there any hidden bugs/traps/features I need to tweak?
> Does anybody work successfully with the I2C in
> this configuration?
>
> My problems:
> I try to get a I2C Philips PCF8563 Real Time Clock working which
> is connected to the I2C of my MPC8540 processor.
> The chip should be sw-compatible with the Epson RTC8564 component
> (according to the datasheets), so I tried to enable the MPC85xx
> I2C bus, the EPSON RTC8564 and the Kernel RTC support.
> I tried several configs - compiled i2c into the kernel or as a
> modules to load and unload them with debug=3D1
>
> I cannot access /dev/misc/rtc with the hwclock (latest version=3D2.23):
> -----8<------------------------------------
> hwclock -w
> hwclock: ioctl() (RTC_SET_TIME) to /dev/misc/rtc to set time failed,
> errno =3D Invalid argument (22).
> -----8<------------------------------------
>
> Now I try to work with the modules and try to track down
> the problem:
>
> after a modprobe rtc8564:
> -----8<------------------------------------
> i2c_adapter i2c-0: examining adapter
> i2c-core: driver unregistered: RTC8564
> i2c-core: driver RTC8564 registered.
> i2c_adapter i2c-0: found normal i2c entry for adapter 0, addr 51
> i2c_adapter i2c-0: master_xfer: with 1 msgs.
> Doing write 0 bytes to 0x51 - 1 of 1 messages
> rtc8564_attach: client=3Dc02c1e00
> rtc8564_attach: client.id=3D61440
> i2c_adapter i2c-0: master_xfer: with 1 msgs.
> Doing write 2 bytes to 0x51 - 1 of 1 messages
> I2C: No RXAK
> rtc8564: cant init ctrl1
> i2c-core: unregister_driver - looking for clients.
> i2c_adapter i2c-0: examining adapter
> i2c-core: driver unregistered: RTC8564
> i2c_adapter i2c-0: adapter unregistered
> i2c-core: driver RTC8564 registered.
> -----8<------------------------------------
> Module=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Size=A0 =
Used by
> rtc8564=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 6660=A0 0
> i2c_core=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 25264=A0 1 rtc8564
> -----8<------------------------------------
>
> and after a modprobe i2c-mpc I get:
> -----8<------------------------------------
> i2c_adapter i2c-0: found normal i2c entry for adapter 0, addr 51
> i2c_adapter i2c-0: master_xfer: with 1 msgs.
> Doing write 0 bytes to 0x51 - 1 of 1 messages
> rtc8564_attach: client=3Dc02c1200
> rtc8564_attach: client.id=3D61440
> i2c_adapter i2c-0: master_xfer: with 1 msgs.
> Doing write 2 bytes to 0x51 - 1 of 1 messages
> I2C: No RXAK
> rtc8564: cant init ctrl1
> i2c_adapter i2c-0: registered as adapter #0
> -----8<------------------------------------
> Module=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Size=A0 =
Used by
> i2c_mpc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 5376=A0 0
> rtc8564=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 6660=A0 0
> i2c_core=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 25264=A0 2 =
i2c_mpc,rtc8564
> -----8<------------------------------------
>
> So, the output looks basically fine, except of the
>
> I2C: No RXAK
> rtc8564: cant init ctrl1
>
> Which means that I don't get an ACK from my RTC.
> I connected an oscilloscope to the I2C - there
> is a lot of traffic. So I believe that the problem
> is more on the protocol side?
>
> Does somebody have any suggestions before I dig into
> the code?
> Thank you in advance!
>
> Best greets,
>
> Clemens Koller
> _______________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
>
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Are the I2C drivers on MPC8540 Kernel 2.6.10 working?
From: Eugene Surovegin @ 2005-02-09 18:57 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <420A4CF3.5090902@anagramm.de>
On Wed, Feb 09, 2005 at 06:48:35PM +0100, Clemens Koller wrote:
> My problems:
> I try to get a I2C Philips PCF8563 Real Time Clock working which
> is connected to the I2C of my MPC8540 processor.
> The chip should be sw-compatible with the Epson RTC8564 component
> (according to the datasheets), so I tried to enable the MPC85xx
> I2C bus, the EPSON RTC8564 and the Kernel RTC support.
> I tried several configs - compiled i2c into the kernel or as a
> modules to load and unload them with debug=1
>
> I cannot access /dev/misc/rtc with the hwclock (latest version=2.23):
Make sure I2C address for your RTC clock is correct. They may be
compatible, but usually I2C address depends on board design and you
may have to tweak the driver a little.
--
Eugene.
^ permalink raw reply
* question on CONFIG_I2C_SPI_UCODE_PATCH and CONFIG_I2C_SPI_SMC1_UCODE_P ATCH
From: Alexander Povolotsky @ 2005-02-09 18:22 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
Hi,
I have a question on use of CONFIG_I2C_SPI_UCODE_PATCH and CONFIG_I2C_SPI_SMC1_UCODE_PATCH in Linux 2.6.
Could someone from this list explain for me what problems each of those two patches are addressing ?
I have MPC 880 based board with single 24C02 I2C EEPROM,
connected to the I2C bus and currently (without those two patches configured in .config) I have problem of communicating
over I2C bus with that device - scanning for any address (in the range between 0 and 128) on the I2C bus does not get any response (interrupt)
so code remains in the sleep (on interrupt) mode.
Would applying (any or both) above patches resolve my problem as described ?
Thanks,
Best Regards,
Alex
___________________________________________________________________
Speed up your surfing with Juno SpeedBand.
Now includes pop-up blocker!
Only $14.95/month -visit http://www.juno.com/surf to sign up today!
^ permalink raw reply
* Are the I2C drivers on MPC8540 Kernel 2.6.10 working?
From: Clemens Koller @ 2005-02-09 17:48 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
My questions:
Is I2C and the Real Time Clock stuff working for the MPC8540
in Kernel 2.6.10?
Are there any hidden bugs/traps/features I need to tweak?
Does anybody work successfully with the I2C in
this configuration?
My problems:
I try to get a I2C Philips PCF8563 Real Time Clock working which
is connected to the I2C of my MPC8540 processor.
The chip should be sw-compatible with the Epson RTC8564 component
(according to the datasheets), so I tried to enable the MPC85xx
I2C bus, the EPSON RTC8564 and the Kernel RTC support.
I tried several configs - compiled i2c into the kernel or as a
modules to load and unload them with debug=1
I cannot access /dev/misc/rtc with the hwclock (latest version=2.23):
-----8<------------------------------------
hwclock -w
hwclock: ioctl() (RTC_SET_TIME) to /dev/misc/rtc to set time failed,
errno = Invalid argument (22).
-----8<------------------------------------
Now I try to work with the modules and try to track down
the problem:
after a modprobe rtc8564:
-----8<------------------------------------
i2c_adapter i2c-0: examining adapter
i2c-core: driver unregistered: RTC8564
i2c-core: driver RTC8564 registered.
i2c_adapter i2c-0: found normal i2c entry for adapter 0, addr 51
i2c_adapter i2c-0: master_xfer: with 1 msgs.
Doing write 0 bytes to 0x51 - 1 of 1 messages
rtc8564_attach: client=c02c1e00
rtc8564_attach: client.id=61440
i2c_adapter i2c-0: master_xfer: with 1 msgs.
Doing write 2 bytes to 0x51 - 1 of 1 messages
I2C: No RXAK
rtc8564: cant init ctrl1
i2c-core: unregister_driver - looking for clients.
i2c_adapter i2c-0: examining adapter
i2c-core: driver unregistered: RTC8564
i2c_adapter i2c-0: adapter unregistered
i2c-core: driver RTC8564 registered.
-----8<------------------------------------
Module Size Used by
rtc8564 6660 0
i2c_core 25264 1 rtc8564
-----8<------------------------------------
and after a modprobe i2c-mpc I get:
-----8<------------------------------------
i2c_adapter i2c-0: found normal i2c entry for adapter 0, addr 51
i2c_adapter i2c-0: master_xfer: with 1 msgs.
Doing write 0 bytes to 0x51 - 1 of 1 messages
rtc8564_attach: client=c02c1200
rtc8564_attach: client.id=61440
i2c_adapter i2c-0: master_xfer: with 1 msgs.
Doing write 2 bytes to 0x51 - 1 of 1 messages
I2C: No RXAK
rtc8564: cant init ctrl1
i2c_adapter i2c-0: registered as adapter #0
-----8<------------------------------------
Module Size Used by
i2c_mpc 5376 0
rtc8564 6660 0
i2c_core 25264 2 i2c_mpc,rtc8564
-----8<------------------------------------
So, the output looks basically fine, except of the
I2C: No RXAK
rtc8564: cant init ctrl1
Which means that I don't get an ACK from my RTC.
I connected an oscilloscope to the I2C - there
is a lot of traffic. So I believe that the problem
is more on the protocol side?
Does somebody have any suggestions before I dig into
the code?
Thank you in advance!
Best greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
^ permalink raw reply
* Re: [PATCH][2.6.11-rc3] gcc-4.0 fixes for ppc32
From: Tom Rini @ 2005-02-09 17:34 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: paulus, linux-kerne, linuxppc-dev
In-Reply-To: <16906.12395.517982.168072@alkaid.it.uu.se>
On Wed, Feb 09, 2005 at 04:46:51PM +0100, Mikael Pettersson wrote:
> These patches are needed to allow me to build a working
> 2.6.11-rc3 kernel for ppc32 with gcc-4.0 (20050130 snapshot):
>
> - The static time_offset in arch/ppc/kernel/time.c triggers a
> declaration conflict with the non-static one in include/linux/timex.h.
> Solution: s/time_offset/ppc_time_offset/g in ppc's time.c.
> - OpenPIC is declared extern in open_pic_defs.h but static in
> open_pic.c. Solution: remove the extern decl.
> - prom_display_paths[] and prom_num_displays are declared extern in
> include/asm-ppc/prom.h but static in arch/ppc/syslib/prom_init.c.
> Solution: remove the extern decls.
> - The 'const' on __USE_RTC() in include/asm-ppc/time.h triggers
> compiler warnings. Change it to use compiler.h's __attribute_const__.
> (This mirrors changes that have already been made in e.g. byteorder.h.)
>
> Tested on an eMac. No breakage observed.
>
> Signed-off-by: Mikael Pettersson <mikpe@csd.uu.se>
This all looks fine to me, will send once 2.6.12-rc1 opens.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: true ide
From: Eugene Surovegin @ 2005-02-09 17:11 UTC (permalink / raw)
To: Marco Schramel; +Cc: Linuxppc-embedded
In-Reply-To: <200502091710.25227.Schramel.Linux@go.bartec.de>
On Wed, Feb 09, 2005 at 05:10:25PM +0100, Marco Schramel wrote:
> on my custom board i can access my compact flash card through true ide interface. My UPM's work und the taskfile is ready to use.
> How i tell my kernel (denx 2.4.25) to use my taskfile for ide access?
> How can i register the compact flash as hard drive in linux ??
Here is an example code for CF attached to the external bus on PPC4xx:
---------------------------------------------------------------------
static void cf_ide_insw(unsigned long port, void *addr, u32 count){
_insw((volatile u16*)port, addr, count);
}
static void cf_ide_outsw(unsigned long port, void *addr, u32 count){
_outsw((volatile u16*)port, addr, count);
}
void __init cf_ide_probe(void){
/* Find an empty slot */
while (idx < MAX_HWIFS && ide_hwifs[idx].io_ports[IDE_DATA_OFFSET])
++idx;
if (idx == MAX_HWIFS){
printk(KERN_ERR"Cannot find empty IDE hwif slot\n");
return;
}
hwif = &ide_hwifs[idx];
hw = &hwif->hw;
hw->io_ports[IDE_DATA_OFFSET] = cf_taskfile_main_kva;
hw->io_ports[IDE_ERROR_OFFSET] = cf_taskfile_main_kva + 3;
hw->io_ports[IDE_NSECTOR_OFFSET] = cf_taskfile_main_kva + 5;
hw->io_ports[IDE_SECTOR_OFFSET] = cf_taskfile_main_kva + 7;
hw->io_ports[IDE_LCYL_OFFSET] = cf_taskfile_main_kva + 9;
hw->io_ports[IDE_HCYL_OFFSET] = cf_taskfile_main_kva + 0xb;
hw->io_ports[IDE_SELECT_OFFSET] = cf_taskfile_main_kva + 0xd;
hw->io_ports[IDE_STATUS_OFFSET] = cf_taskfile_main_kva + 0xf;
hw->io_ports[IDE_CONTROL_OFFSET] = cf_taskfile_alt_kva + 0xd;
memcpy(hwif->io_ports, hw->io_ports, sizeof(hwif->io_ports));
hwif->irq = hw->irq = CF_IRQ;
hwif->noprobe = 0;
/* Don't probe second drive */
hwif->drives[1].noprobe = 1;
default_hwif_mmiops(hwif);
/* Override 16-bit string ops to do byte-swapping */
hwif->OUTSW = cf_ide_outsw;
hwif->INSW = cf_ide_insw;
}
-------------------------------------------------------------------
Some comments: cf_task_main_kva - ioremmaped main taskfile (main chip
select), cf_task_file_atl_kva - ioremapped alternative taskfile
(second chip select). In my case board support code sets up those.
CF_IRQ - interrupt request from CF.
Also, note that actual offset for each taskfile register depends on
how you wired CF to the CPU, it may be different in your case, so use
this code as an _example_.
I call cf_ide_probe() from drivers/ide/ide.c::probe_for_hwifs.
--
Eugene
^ permalink raw reply
* true ide
From: Marco Schramel @ 2005-02-09 16:10 UTC (permalink / raw)
To: Linuxppc-embedded
Hi,
on my custom board i can access my compact flash card through true ide interface. My UPM's work und the taskfile is ready to use.
How i tell my kernel (denx 2.4.25) to use my taskfile for ide access?
How can i register the compact flash as hard drive in linux ??
Thanks in advance
Marco
--
---------
Marco Schramel
R&D
Bartec GmbH
Schulstr. 30
94239 Gotteszell, Germany
www.bartec.de
Marco.Schramel@go.bartec.de
Phone: +49 (0)9929/301332
Fax: +49 (0)9929/301112
^ permalink raw reply
* [PATCH][2.6.11-rc3] gcc-4.0 fixes for ppc32
From: Mikael Pettersson @ 2005-02-09 15:46 UTC (permalink / raw)
To: paulus, benh; +Cc: linuxppc-dev, linux-kerne
These patches are needed to allow me to build a working
2.6.11-rc3 kernel for ppc32 with gcc-4.0 (20050130 snapshot):
- The static time_offset in arch/ppc/kernel/time.c triggers a
declaration conflict with the non-static one in include/linux/timex.h.
Solution: s/time_offset/ppc_time_offset/g in ppc's time.c.
- OpenPIC is declared extern in open_pic_defs.h but static in
open_pic.c. Solution: remove the extern decl.
- prom_display_paths[] and prom_num_displays are declared extern in
include/asm-ppc/prom.h but static in arch/ppc/syslib/prom_init.c.
Solution: remove the extern decls.
- The 'const' on __USE_RTC() in include/asm-ppc/time.h triggers
compiler warnings. Change it to use compiler.h's __attribute_const__.
(This mirrors changes that have already been made in e.g. byteorder.h.)
Tested on an eMac. No breakage observed.
Signed-off-by: Mikael Pettersson <mikpe@csd.uu.se>
--- linux-2.6.11-rc3/arch/ppc/kernel/time.c.~1~ 2005-02-08 20:43:01.000000000 +0100
+++ linux-2.6.11-rc3/arch/ppc/kernel/time.c 2005-02-08 21:57:24.000000000 +0100
@@ -89,7 +89,7 @@ unsigned long tb_to_ns_scale;
extern unsigned long wall_jiffies;
-static long time_offset;
+static long ppc_time_offset;
DEFINE_SPINLOCK(rtc_lock);
@@ -172,7 +172,7 @@ void timer_interrupt(struct pt_regs * re
xtime.tv_sec - last_rtc_update >= 659 &&
abs((xtime.tv_nsec / 1000) - (1000000-1000000/HZ)) < 500000/HZ &&
jiffies - wall_jiffies == 1) {
- if (ppc_md.set_rtc_time(xtime.tv_sec+1 + time_offset) == 0)
+ if (ppc_md.set_rtc_time(xtime.tv_sec+1 + ppc_time_offset) == 0)
last_rtc_update = xtime.tv_sec+1;
else
/* Try again one minute later */
@@ -289,7 +289,7 @@ void __init time_init(void)
unsigned old_stamp, stamp, elapsed;
if (ppc_md.time_init != NULL)
- time_offset = ppc_md.time_init();
+ ppc_time_offset = ppc_md.time_init();
if (__USE_RTC()) {
/* 601 processor: dec counts down by 128 every 128ns */
@@ -334,10 +334,10 @@ void __init time_init(void)
set_dec(tb_ticks_per_jiffy);
/* If platform provided a timezone (pmac), we correct the time */
- if (time_offset) {
- sys_tz.tz_minuteswest = -time_offset / 60;
+ if (ppc_time_offset) {
+ sys_tz.tz_minuteswest = -ppc_time_offset / 60;
sys_tz.tz_dsttime = 0;
- xtime.tv_sec -= time_offset;
+ xtime.tv_sec -= ppc_time_offset;
}
set_normalized_timespec(&wall_to_monotonic,
-xtime.tv_sec, -xtime.tv_nsec);
--- linux-2.6.11-rc3/arch/ppc/syslib/open_pic_defs.h.~1~ 2005-02-08 20:43:01.000000000 +0100
+++ linux-2.6.11-rc3/arch/ppc/syslib/open_pic_defs.h 2005-02-08 22:06:36.000000000 +0100
@@ -172,9 +172,6 @@ struct OpenPIC {
OpenPIC_Processor Processor[OPENPIC_MAX_PROCESSORS];
};
-extern volatile struct OpenPIC __iomem *OpenPIC;
-
-
/*
* Current Task Priority Register
*/
--- linux-2.6.11-rc3/include/asm-ppc/prom.h.~1~ 2003-09-28 12:19:57.000000000 +0200
+++ linux-2.6.11-rc3/include/asm-ppc/prom.h 2005-02-08 22:02:49.000000000 +0100
@@ -13,9 +13,6 @@
typedef void *phandle;
typedef void *ihandle;
-extern char *prom_display_paths[];
-extern unsigned int prom_num_displays;
-
struct address_range {
unsigned int space;
unsigned int address;
--- linux-2.6.11-rc3/include/asm-ppc/time.h.~1~ 2004-12-25 12:16:24.000000000 +0100
+++ linux-2.6.11-rc3/include/asm-ppc/time.h 2005-02-08 22:14:22.000000000 +0100
@@ -13,6 +13,7 @@
#include <linux/types.h>
#include <linux/rtc.h>
#include <linux/threads.h>
+#include <linux/compiler.h>
#include <asm/reg.h>
@@ -58,7 +59,7 @@ static __inline__ void set_dec(unsigned
/* Accessor functions for the timebase (RTC on 601) registers. */
/* If one day CONFIG_POWER is added just define __USE_RTC as 1 */
#ifdef CONFIG_6xx
-extern __inline__ int const __USE_RTC(void) {
+extern __inline__ int __attribute_const__ __USE_RTC(void) {
return (mfspr(SPRN_PVR)>>16) == 1;
}
#else
^ permalink raw reply
* Re: Kernel 2.6.10 on the MPC5200
From: Babarovic Ivica @ 2005-02-09 11:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4209E9E2.30208@asist-traffic.com>
> It's called buildroot. You can find it on busybox pages.
> http://www.uclibc.org/cgi-bin/cvsweb/buildroot/
> But it looks like this page is not accessible now.
>
You will find it here:
http://www.uclibc.org/cgi-bin/cvsweb/trunk/buildroot/
Docs:
http://www.uclibc.org/cgi-bin/cvsweb/*checkout*/trunk/buildroot/docs/buildroot-documentation.html?rev=9628
^ permalink raw reply
* Re: ppc405 core, VIA VT82C686A chipset, linux_2.4.22_pre5, and IDE DMA woes
From: Lawrence E. Bakst @ 2005-02-09 10:34 UTC (permalink / raw)
To: John F Davis, linuxppc-embedded
In-Reply-To: <OF307335B1.8C256DF4-ON87256F98.005EDF72-85256F98.00648315@us.ibm.com>
1. Can you say exactly which 405 core you are using?
2. Is it Xilinx?
3. Have you read all the eratta for your core?
4. How is the VIA VT82C686A hooked to the 405? Via a bus mastering EBC?
Best,
leb
At 1:12 PM -0500 1/29/05, John F Davis wrote:
>Hello
>
>I am trying to get DMA working on a ppc405 core on a custom SOC with IDE
>DMA using a VIA VT82C686A southbridge. I apologize for the length of this
>note.
>
>Here is my environment, configuration, attempts at fixing the system, what
>works, and what doesn't.
>
>o Using linux 2.4.22 pre5 kernel from ppc devel bitkeeper tree. Using
>cross compiler gcc version 3.2.3
>
>o On this box non dma IDE works flawlessy with and without 405 data
>caching.
>
>o DMA IDE works when caching is disabled. When caching is enabled and
>DMA ide is enabled, the system works for a while and then it gets a Data
>Storage Exception when it tries to do a write. The exception is usually
>involves writing to a very similar address no matter how and when the
>exception occurs.
>
>o I am using hdparm to enable and disable the IDE DMA at the command
>line. I ususally cause the oops by running consecutive hdparm tests from
>two different TTY logins. If that does not cause it to oops then starting
>X windows, playing a movie from disk and then issuing the hdparm test most
>certainly will.
>
>o Here are some sample oops messages and ksymoops interpetations. (There
>is more info after the oops messages.)
>
># Oops: kernel access of bad area, sig: 11
>NIP: A002EC04 XER: 20000000 LR: A002EB84 SP: ACBC5D60 REGS: acbc5cb0 TRAP:
>0800 Tainted: P
>MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>DEAR: 5459545D, ESR: 00800000
>TASK = acbc4000[156] 'xine' Last syscall: 4
>last math 00000000 last altivec 00000000
>PLB0: bear= 0x00000000 acr= 0x00000000 besr= 0x00000000
>PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
>
>GPR00: 00000000 ACBC5D60 ACBC4000 00000001 00009030 00000001 000009B0
>AB126000
>GPR08: FFFFFFFF AB14F020 54595459 A02E9DDC 24044082 10115790 00000000
>100E10B0
>GPR16: ACBC5EA0 AB0FE000 A007ACA8 ACBC5E08 AEB3F080 AEB3F080 000009B0
>00001000
>GPR24: 00000000 A04D2BA8 00000001 00000000 00001000 000000F0 AB126F60
>A02E9DD4
>Call backtrace:
>00000003 A002E3E4 A003A084 A003A1C0 A003A504 A003AC90 A003B4D8
>A007B000 A002A874 A002AECC A0037564 A000279C 0FECCD18 0EFC53BC
>0FF50A48 0FEC7914 0FC0B408
>
>produces:*************************
>>>NIP; a002ec04 <kmem_find_general_cachep+6ec/2614> <=====
>
>>>GPR1; acbc5d60 <_end+c925038/12618420>
>>>GPR2; acbc4000 <_end+c9232d8/12618420>
>>>GPR7; ab126000 <_end+ae852d8/12618420>
>>>GPR9; ab14f020 <_end+aeae2f8/12618420>
>>>GPR11; a02e9ddc <_end+490b4/12618420>
>>>GPR16; acbc5ea0 <_end+c925178/12618420>
>>>GPR17; ab0fe000 <_end+ae5d2d8/12618420>
>>>GPR18; a007aca8 <journal_blocks_per_page+4340/87fc>
>>>GPR19; acbc5e08 <_end+c9250e0/12618420>
>>>GPR20; aeb3f080 <_end+e89e358/12618420>
>>>GPR21; aeb3f080 <_end+e89e358/12618420>
>>>GPR25; a04d2ba8 <_end+231e80/12618420>
>>>GPR30; ab126f60 <_end+ae86238/12618420>
>>>GPR31; a02e9dd4 <_end+490ac/12618420>
>
>Trace; 00000003 Before first symbol
>Trace; a002e3e4 <kmem_cache_alloc+10/20>
>Trace; a003a084 <get_unused_buffer_head+68/c8>
>Trace; a003a1c0 <set_bh_page+dc/334>
>Trace; a003a504 <create_empty_buffers+24/908>
>Trace; a003ac90 <create_empty_buffers+7b0/908>
>Trace; a003b4d8 <block_prepare_write+34/a8>
>Trace; a007b000 <journal_blocks_per_page+4698/87fc>
>Trace; a002a874 <read_cache_page+5f4/aac>
>Trace; a002aecc <generic_file_write+1a0/2400>
>Trace; a0037564 <default_llseek+490/e10>
>Trace; a000279c <set_context+3b4/5e0>
>Trace; 0feccd18 Before first symbol
>Trace; 0efc53bc Before first symbol
>Trace; 0ff50a48 Before first symbol
>Trace; 0fec7914 Before first symbol
>Trace; 0fc0b408 Before first symbol
>
>
>5 warnings and 2 errors issued. Results may not be reliable.
>
>===========================================================
>
>
>>>NIP; a002ec40 <kmem_find_general_cachep+728/2614> <=====
>
>>>GPR1; ab53dd10 <_end+b29cfe8/125fe420>
>>>GPR2; ab53c000 <_end+b29b2d8/125fe420>
>>>GPR7; ad4f0000 <_end+d24f2d8/125fe420>
>>>GPR8; a0270000 <ide_register_driver+9e3c/be50>
>>>GPR9; a02e9ddc <_end+490b4/125fe420>
>>>GPR11; a02e9de4 <_end+490bc/125fe420>
>>>GPR18; a00284d0 <do_generic_file_read+73c/804>
>>>GPR19; ada5ff60 <_end+d7bf238/125fe420>
>>>GPR20; ab53ded8 <_end+b29d1b0/125fe420>
>>>GPR21; a003ea04 <sb_min_blocksize+60/4c8>
>>>GPR25; a052bd04 <_end+28afdc/125fe420>
>>>GPR30; a02e9ddc <_end+490b4/125fe420>
>>>GPR31; a02e9dd4 <_end+490ac/125fe420>
>
>Trace; 00000000 Before first symbol
>Trace; a002e3e4 <kmem_cache_alloc+10/20>
>Trace; a003a084 <get_unused_buffer_head+68/c8>
>Trace; a003a1c0 <set_bh_page+dc/334>
>Trace; a003a504 <create_empty_buffers+24/908>
>Trace; a003b094 <block_read_full_page+2ac/2d8>
>Trace; a003ead0 <sb_min_blocksize+12c/4c8>
>Trace; a00272b4 <filemap_fdatawait+414/4dc>
>Trace; a0027c40 <grab_cache_page_nowait+22c/380>
>Trace; a0028108 <do_generic_file_read+374/804>
>Trace; a0028640 <generic_file_read+a8/9d4>
>Trace; a0037414 <default_llseek+340/e10>
>Trace; a000279c <set_context+3b8/5e4>
>Trace; 00000000 Before first symbol
>Trace; 10001dcc Before first symbol
>Trace; 10002ba4 Before first symbol
>Trace; 10003f94 Before first symbol
>Trace; 0fee4920 Before first symbol
>Trace; 00000000 Before first symbol
>
>
>
>=======================================================
>
>
>Trace; a00190dc <__tasklet_hi_schedule+204/250>
>Trace; a002e3e4 <kmem_cache_alloc+10/20>
>Trace; a003a084 <get_unused_buffer_head+68/c8>
>Trace; a003a1c0 <set_bh_page+dc/334>
>Trace; a003a504 <create_empty_buffers+24/908>
>Trace; a003b094 <block_read_full_page+2ac/2d8>
>Trace; a003ead0 <sb_min_blocksize+12c/4c8>
>Trace; a00272b4 <filemap_fdatawait+414/4dc>
>Trace; a0027c40 <grab_cache_page_nowait+22c/380>
>Trace; a0027f3c <do_generic_file_read+1a8/804>
>Trace; a0028640 <generic_file_read+a8/9d4>
>Trace; a0037414 <default_llseek+340/e10>
>Trace; a000279c <set_context+3b8/5e4>
>Trace; 00000000 Before first symbol
>Trace; 10001dcc Before first symbol
>Trace; 10002ba4 Before first __ide_dma_write
>symbol
>Trace; 1__ide_dma_write
>0003f94 Before first symbol
>Trace; 0fee4920 Before first symbol
>Trace; 00000000 Before first symbol
>
>
>i========================================
># Oops: kernel access of bad area, sig: 11
>NIP: A002EC40 XER: 20000000 LR: A002EB84 SP: AF40BD10 REGS: af40bc60 TRAP:
>0800 Tainted: P
>MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>DEAR: 54D954DD, ESR: 00800000
>TASK = af40a000[292] 'hdparm' Last syscall: 3
>last math 00000000 last altivec 00000000
>PLB0: bear= 0x60000000 acr= 0x00000000 besr= 0x00000000
>PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
>
>GPR00: 00000000 AF40BD10 AF40A000 00000001 00009030 00000001 0000000A
>AC091000
>GPR08: A0270000 A02E9DDC 54D954D9 A02E9DE4 84002082 101EDDE4 00000000
>00000000
>GPR16: 00000000 00000000 A00284D0 ADC0E760 AF40BED8 A003EA04 00000001
>00000000
>GPR24: 00000C00 A045BBA0 00000001 00000000 00000400 000000F0 A02E9DDC
>A02E9DD4
>Call backtrace:
>A045FED4 A002E3E4 A003A084 A003A1C0 A003A504 A003B094 A003EAD0
>A00272B4 A0027C40 A0028108 A0028640 A0037414 A000279C 00000000
>10001DCC 10002BA4 10003F94 0FEE4920 00000000
># Oops: kernel access of bad area, sig: 11
>NIP: A002EC40 XER: 20000000 LR: A002EB84 SP: AF40BD10 REGS: af40bc60 TRAP:
>0800 Tainted: P
>MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>DEAR: 54D954DD, ESR: 00800000
>TASK = af40a000[292] 'hdparm' Last syscall: 3
>last math 00000000 last altivec 00000000
>PLB0: bear= 0x60000000 acr= 0x00000000 besr= 0x00000000
>PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
>
>GPR00: 00000000 AF40BD10 AF40A000 00000001 00009030 00000001 0000000A
>AC091000
>GPR08: A0270000 A02E9DDC 54D954D9 A02E9DE4 84002082 101EDDE4 00000000
>00000000
>GPR16: 00000000 00000000 A00284D0 ADC0E760 AF40BED8 A003EA04 00000001
>00000000
>GPR24: 00000C00 A045BBA0 00000001 00000000 00000400 000000F0 A02E9DDC
>A02E9DD4
>Call backtrace:
>A045FED4 A002E3E4 A003A084 A003A1C0 A003A504 A003B094 A003EAD0
>A00272B4 A0027C40 A0028108 A0028640 A0037414 A000279C 00000000
>10001DCC 10002BA4 10003F94 0FEE4920 00000000
>
>>>NIP; a002ec40 <kmem_find_general_cachep+728/2614> <=====
>
>>>GPR1; af40bd10 <_end+f16afe8/125fe420>
>>>GPR2; af40a000 <_end+f1692d8/125fe420>
>>>GPR7; ac091000 <_end+bdf02d8/125fe420>
>>>GPR8; a0270000 <ide_register_driver+9e3c/be50>
>>>GPR9; a02e9ddc <_end+490b4/125fe420>
>>>GPR11; a02e9de4 <_end+490bc/125fe420>
>>>GPR18; a00284d0 <do_generic_file_read+73c/804>
>>>GPR19; adc0e760 <_end+d96da38/125fe420>
>>>GPR20; af40bed8 <_end+f16b1b0/125fe420>
>>>GPR21; a003ea04 <sb_min_blocksize+60/4c8>
>>>GPR25; a045bba0 <_end+1bae78/125fe420>
>>>GPR30; a02e9ddc <_end+490b4/125fe420>
>>>GPR31; a02e9dd4 <_end+490ac/125fe420>
>
>Trace; a045fed4 <_end+1bf1ac/125fe420>
>Trace; a002e3e4 <kmem_cache_alloc+10/20>
>Trace; a003a084 <get_unused_buffer_head+68/c8>
>Trace; a003a1c0 <set_bh_page+dc/334>
>Trace; a003a504 <create_empty_buffers+24/908>
>Trace; a003b094 <block_read_full_page+2ac/2d8>
>Trace; a003ead0 <sb_min_blocksize+12c/4c8>
>Trace; a00272b4 <filemap_fdatawait+414/4dc>
>Trace; a0027c40 <grab_cache_page_nowait+22c/380>
>Trace; a0028108 <do_generic_file_read+374/804>
>Trace; a0028640 <generic_file_read+a8/9d4>
>Trace; a0037414 <default_llseek+340/e10>
>Trace; a000279c <set_context+3b8/5e4>
>Trace; 00000000 Before first symbol
>Trace; 10001dcc Before first symbol
>Trace; 10002ba4 Before first symbol
>Trace; 10003f94 Before first symbol
>Trace; 0fee4920 Before first symbol
>Trace; 00000000 Before first symbol
>
>==========================================================
>
>added the debug code to drivers/block/ll_rw_blk.c
>#Oops: kernel access of bad area, sig: 11
>NIP: A002EC04 XER: 20000000 LR: A002EB84 SP: ACF25D60 REGS: acf25cb0 TRAP:
>0800 Tainted: P
>MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>DEAR: 54D954DD, ESR: 00800000
>TASK = acf24000[139] 'xine' Last syscall: 4
>last math 00000000 last altivec 00000000
>PLB0: bear= 0x60000000 acr= 0x00000000 besr= 0x00000000
>PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
>
>GPR00: 00000000 ACF25D60 ACF24000 00000001 00009030 00000001 0000042C
>AB9F1000
>GPR08: FFFFFFFF ABA1A020 54D954D9 A02E9DDC 24044082 10115790 00000000
>100E10B0
>GPR16: ACF25EA0 AB9CE000 A007ACA8 ACF25E08 AC58F680 AC58F680 0000042C
>00001000
>GPR24: 00000000 A04EAF68 00000001 00000000 00001000 000000F0 AB9F1F60
>A02E9DD4
>Call backtrace:
>00000003 A002E3E4 A003A084 A003A1C0 A003A504 A003AC90 A003B4D8
>A007B000 A002A874 A002AECC A0037564 A000279C 0FECCD18 0EFC53BC
>0FF50A48 0FEC7914 0FC0B408
>
>Was so hosed I could not run ksymoops.
>================================
>
> Timing buffered disk reads: Oops: kernel access of bad area, sig: 11
>NIP: A002EC28 XER: 20000000 LR: A002EB84 SP: AE1F7D10 REGS: ae1f7c60 TRAP:
>0800 Tainted: P
>MSR: 00001030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
>DEAR: 54D954D9, ESR: 00000000
>TASK = ae1f6000[131] 'hdparm' Last syscall: 3
>last math 00000000 last altivec 00000000
>PLB0: bear= 0x60000000 acr= 0x00000000 besr= 0x00000000
>PLB0 to OPB: bear= 0xc27e3183 besr0= 0xc0000000 besr1= 0x00000000
>
>GPR00: A02E9DE4 AE1F7D10 AE1F6000 00000001 00009030 00000002 00000003
>54D954D9
>GPR08: A0270000 00000000 A0270000 00000001 84002042 10025468 00000000
>00000000
>GPR16: 00000000 00000000 A00284D0 AC3CE760 AE1F7ED8 A003EA1C 00000000
>00000000
>GPR24: 00000C00 A054755C 00000001 00000000 00000400 000000F0 A02E9DDC
>A02E9DD4
>Call backtrace:
>A00190DC A002E3E4 A003A09C A003A1D8 A003A51C A003B0AC A003EAE8
>A00272B4 A0027C40 A0027F3C A0028640 A0037414 A000279C 00000000
>10001DCC 10002BA4 10003F94 0FEE4920 00000000
>Segmentation fault
>
>Warning (Oops_read): Code line not seen, dumping what data is available
>
>
>>>NIP; a002ec28 <kmem_find_general_cachep+710/2614> <=====
>
>>>GPR0; a02e9de4 <_end+490bc/125fe420>
>>>GPR1; ae1f7d10 <_end+df56fe8/125fe420>
>>>GPR2; ae1f6000 <_end+df552d8/125fe420>
>>>GPR8; a0270000 <ide_register_driver+9e3c/be50>
>>>GPR10; a0270000 <ide_register_driver+9e3c/be50>
>>>GPR18; a00284d0 <do_generic_file_read+73c/804>
>>>GPR19; ac3ce760 <_end+c12da38/125fe420>
>>>GPR20; ae1f7ed8 <_end+df571b0/125fe420>
>>>GPR21; a003ea1c <sb_min_blocksize+60/4c8>
>>>GPR25; a054755c <_end+2a6834/125fe420>
>>>GPR30; a02e9ddc <_end+490b4/125fe420>
>>>GPR31; a02e9dd4 <_end+490ac/125fe420>
>
>Trace; a00190dc <__tasklet_hi_schedule+204/250>
>Trace; a002e3e4 <kmem_cache_alloc+10/20>
>Trace; a003a09c <get_unused_buffer_head+80/e0>
>Trace; a003a1d8 <set_bh_page+dc/334>
>Trace; a003a51c <create_empty_buffers+24/908>
>Trace; a003b0ac <block_read_full_page+2ac/2d8>
>Trace; a003eae8 <sb_min_blocksize+12c/4c8>
>Trace; a00272b4 <filemap_fdatawait+414/4dc>
>Trace; a0027c40 <grab_cache_page_nowait+22c/380>
>Trace; a0027f3c <do_generic_file_read+1a8/804>
>Trace; a0028640 <generic_file_read+a8/9d4>
>Trace; a0037414 <default_llseek+340/e10>
>Trace; a000279c <set_context+3b8/5e4>
>Trace; 00000000 Before first symbol
>Trace; 10001dcc Before first symbol
>Trace; 10002ba4 Before first symbol
>Trace; 10003f94 Before first symbol
>Trace; 0fee4920 Before first symbol
>
>
>
>
>Here is a dump of the configuration space for the isa bridge and ide
>interface on the VIA chipset in both human readable form and raw form.
>
> The ISA bridge:
>0000:00:01.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
>South] (rev 40)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>ParErr- Stepping+ SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
><TAbort- <MAbort- >SERR- <PERR-
> Latency: 0
> Interrupt: pin ? routed to IRQ 46
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
>and in raw form
>0000:00:01.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super
>South] (rev 40)
>00: 06 11 86 06 87 00 10 02 40 00 01 06 00 00 80 00
>10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00
>40: 08 01 00 00 00 00 00 00 05 01 84 00 00 00 00 03
>50: 0e 00 34 00 0f 90 ba 00 00 04 bf 00 00 00 00 00
>60: d8 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>70: 00 00 00 00 00 00 00 88 00 00 00 00 00 00 00 00
>80: 00 00 00 00 00 01 00 00 00 60 00 00 00 00 00 00
>90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
>d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>f0: 00 00 00 00 00 00 42 00 00 00 00 00 00 00 00 00
>
>
>The IDE Interface:
>0000:00:01.1 IDE interface: VIA Technologies, Inc.
>VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if
>8f [Master SecP SecO PriP PriO])
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>ParErr- Stepping- SERR- FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
><TAbort- <MAbort- >SERR- <PERR-
> Latency: 128
> Interrupt: pin ? routed to IRQ 46
> Region 0: I/O ports at fff8 [size=8]
> Region 1: I/O ports at fff4 [size=4]
> Region 2: I/O ports at ffe8 [size=8]
> Region 3: I/O ports at ffe4 [size=4]
> Region 4: I/O ports at ffd0 [size=16]
> Capabilities: [c0] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
>
>
>and in raw form
>0000:00:01.1 IDE interface: VIA Technologies, Inc.
>VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
>00: 06 11 71 05 07 00 90 02 06 8f 01 01 00 80 00 00
>10: f9 ff 00 00 f5 ff 00 00 e9 ff 00 00 e5 ff 00 00
>20: d1 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>30: 00 00 00 00 c0 00 00 00 00 00 00 00 0e 00 00 00
>40: 0b 02 c9 3a 08 00 c0 00 a8 a8 a8 20 3f 00 ff 20
>50: 07 07 07 e4 04 00 00 00 a8 a8 a8 a8 00 00 00 00
>60: 00 02 00 00 00 00 00 00 00 02 00 00 00 00 00 00
>70: 02 01 00 00 00 00 00 00 02 01 00 00 00 00 00 00
>80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>c0: 01 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00
>d0: 06 00 71 05 00 00 00 00 00 00 00 00 00 00 00 00
>e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
>
>Here is a summary of what I have tried in the kernel code.
>
>o I tried the unaligned buffer patch to see if I had alignment problems.
>I dont.
>o I tried to flush the cache instead of invalidating it in the
>consistent_sync PCI_DMA_FROMDEVICE case.
>o I tried to flush the consistent sync the memory in the ide_build_sglist
>routine in a manner similar to Dan Malek in his 4xx OCP IDE driver.
>o I tried to flush the cache based upon the dma table after the
>ide_build_dmatable call as done in the Amiga One port which also uses the
>VIA chipset.
>o I tried converting the kmalloc calls for the sg_table to non cacheable
>as well.
>
>Here is the cleaned up diff with the debug printk's and my comments
>removed.
>
>diff -Naur orig/arch/ppc/mm/cachemap.c mod/arch/ppc/mm/cachemap.c
>--- orig/arch/ppc/mm/cachemap.c 2005-01-29 13:06:41.000000000 -0500
>+++ mod/arch/ppc/mm/cachemap.c 2005-01-29 13:04:10.000000000 -0500
>@@ -146,10 +146,28 @@
> unsigned long start = (unsigned long)vaddr;
> unsigned long end = start + size;
>
> switch (direction) {
> case PCI_DMA_NONE:
> BUG();
> case PCI_DMA_FROMDEVICE: /* invalidate only */
>+// printk("consistent sync: PCI_DMA_FROMDEVICE\n");
>+
>+#ifdef CONFIG_DEBUG_CONSISTENT_SYNC
>+ if (unlikely(start & (L1_CACHE_LINE_SIZE - 1)) ||
>+ unlikely(end & (L1_CACHE_LINE_SIZE - 1)))
>+ {
>+ static unsigned int count = 0;
>+ if (++count < 10)
>+ //printk(KERN_WARNING
>+ printk(
>+ "consistent_sync: 0x%08lx-0x%08lx "
>+ "is not properly aligned, lr 0x%p\n",
>+ start, end, __builtin_return_address(0));
>+ }
>+#endif
>+
> flush_dcache_range(start, end);
>+// invalidate_dcache_range(start, end);
>
> break;
> case PCI_DMA_TODEVICE: /* writeback only */
>+// printk("consistent sync: PCI_DMA_TODEVICE\n");
> clean_dcache_range(start, end);
> break;
> case PCI_DMA_BIDIRECTIONAL: /* writeback and invalidate */
>+// printk("consistent sync: PCI_DMA_BIDIRECTIONAL\n");
> flush_dcache_range(start, end);
> break;
> }
>diff -Naur orig/drivers/ide/ide-dma.c mod/drivers/ide/ide-dma.c
>--- orig/drivers/ide/ide-dma.c 2005-01-29 13:06:53.000000000 -0500
>+++ mod/drivers/ide/ide-dma.c 2005-01-29 12:55:15.000000000 -0500
> static int ide_build_sglist (ide_hwif_t *hwif, struct request *rq, int
>ddir)
> {
> struct buffer_head *bh;
> unsigned long lastdataend = ~0UL;
> int nents = 0;
>
> if (hwif->sg_dma_active)
> BUG();
>
>@@ -270,6 +291,17 @@
> }
>
> if (contig) {
>+ unsigned int size, addr;
>+
>+ addr = virt_to_bus(bh->b_data);
>+ size = bh->b_size;
>+ if (ddir)
>+ consistent_sync(bh->b_data, size,
>PCI_DMA_TODEVICE);
>+ else
>+ consistent_sync(bh->b_data, size,
>PCI_DMA_FROMDEVICE);
>+
>+
>+
> sg[nents - 1].length += bh->b_size;
> lastdataend += bh->b_size;
> continue;
>@@ -281,10 +313,26 @@
> memset(&sg[nents], 0, sizeof(*sg));
>
> if (bh->b_page) {
>+ unsigned int size, addr;
>+
>+
>+ addr = virt_to_bus(bh->b_data);
>+ size = bh->b_size;
>+ if (ddir)
>+ consistent_sync(bh->b_data, size,
>PCI_DMA_TODEVICE);
>+ else
>+ consistent_sync(bh->b_data, size,
>PCI_DMA_FROMDEVICE);
>+
>+
> sg[nents].page = bh->b_page;
> sg[nents].offset = bh_offset(bh);
> lastdataend = bh_phys(bh) + bh->b_size;
>+ //printk("we are using pages\n");
>+
>+
>+
> } else {
>+ printk("we are using datas\n");
> if ((unsigned long) bh->b_data < PAGE_SIZE)
> BUG();
>
>@@ -300,6 +348,8 @@
> BUG();
>
> hwif->sg_dma_direction = ddir;
> return pci_map_sg(hwif->pci_dev, sg, nents, ddir);
> }
>
>@@ -686,9 +751,18 @@
> u8 dma_stat = 0, lba48 = (drive->addressing == 1) ? 1 : 0;
> task_ioreg_t command = WIN_NOP;
>
> if (!(count = ide_build_dmatable(drive, rq, PCI_DMA_FROMDEVICE)))
> /* try PIO instead of DMA */
> return 1;
>+#if 1 /* MAI: make sure RAM's copy of dma table is up to date */
>+ /* flush (start, stop) */
>+// printk("ide_dma_read\n");
>+// printk("\tflush_dcache_range start=%x
>size=%x\n",hwif->dmatable_cpu, hwif->dmatable_cpu +(count << 3));
>+ flush_dcache_range (hwif->dmatable_cpu, hwif->dmatable_cpu +
>(count << 3));
>+#endif
> /* PRD table */
> hwif->OUTL(hwif->dmatable_dma, hwif->dma_prdtable);
> /* specify r/w */
>@@ -732,9 +806,18 @@
> u8 dma_stat = 0, lba48 = (drive->addressing == 1) ? 1 : 0;
> task_ioreg_t command = WIN_NOP;
>
>+// printk("__ide_dma_write\n");
>+
>+
> if (!(count = ide_build_dmatable(drive, rq, PCI_DMA_TODEVICE)))
> /* try PIO instead of DMA */
> return 1;
>+#if 1 /* MAI: make sure RAM's copy of dma table is up to date */
>+ // This is flushing the virt address table.
>+// printk("ide_dma_write\n");
>+// printk("\tflush_dcache_range start=%x
>size=%x\n",hwif->dmatable_cpu, hwif->dmatable_cpu +(count << 3));
>+ flush_dcache_range (hwif->dmatable_cpu, hwif->dmatable_cpu +
>(count << 3));
>+#endif
> /* PRD table */
> hwif->OUTL(hwif->dmatable_dma, hwif->dma_prdtable);
> /* specify r/w */
>@@ -994,12 +1077,14 @@
> hwif->dmatable_cpu = NULL;
> }
> if (hwif->sg_table) {
>- kfree(hwif->sg_table);
>+/* jfd kfree(hwif->sg_table); */
>+ pci_free_consistent(NULL, sizeof(struct scatterlist) *
>PRD_ENTRIES, hwif->sg_table,NULL);
> hwif->sg_table = NULL;
> }
> return 1;
> }
>
>+
> int ide_release_mmio_dma (ide_hwif_t *hwif)
> {
> if ((hwif->dma_extra) && (hwif->channel == 0))
>@@ -1039,11 +1124,26 @@
>
> int ide_allocate_dma_engine (ide_hwif_t *hwif)
> {
>+
>+ printk("ide_allocate_dma_engine\n");
>+
> hwif->dmatable_cpu = pci_alloc_consistent(hwif->pci_dev,
> PRD_ENTRIES * PRD_BYTES,
> &hwif->dmatable_dma);
>+
>+ printk("\t dma table bus addr %x\n",hwif->dmatable_dma);
>+ printk("\t dma table virt addr %x\n",hwif->dmatable_cpu);
>+ printk("\t size
>%x*%x=%x\n",PRD_ENTRIES,PRD_BYTES,PRD_ENTRIES*PRD_BYTES);
>+
>+
>+
>+ hwif->sg_table = pci_alloc_consistent(NULL,sizeof(struct
>scatterlist) * PRD_ENTRIES,
>+ &hwif->sg_table);
>+#if 0
> hwif->sg_table = kmalloc(sizeof(struct scatterlist) * PRD_ENTRIES,
> GFP_KERNEL);
>+jfd
>+#endif
>
>
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Kernel 2.6.10 on the MPC5200
From: Babarovic Ivica @ 2005-02-09 10:45 UTC (permalink / raw)
To: Vlad L, linuxppc-embedded
In-Reply-To: <20050203141050.38170.qmail@web90004.mail.scd.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
Vlad L wrote:
>Hello,
>
>I am new in this list.
>We should run Linux Kernel 2.6.10 on the Light5200
>board (MPC5200).
>
>
Try this kernel: http://246tnt.com/mpc52xx/
It works for me.
>Please, direct me to links were can I download GCC
>(and others) and Kernel, which are good point to start
>from.
>
>
There is a tool out there:
http://kegel.com/crosstool/current/doc/crosstool-howto.html
Read about it. You will basically need to change a couple of files
to generate your cross compiler environment.
I'll attach my files.
I also use another tool for my basic file system layout.
It's called buildroot. You can find it on busybox pages.
http://www.uclibc.org/cgi-bin/cvsweb/buildroot/
But it looks like this page is not accessible now.
>Thanks in advance.
>Vlad.
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Mail - You care about security. So do we.
>http://promotions.yahoo.com/new_mail
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
>
>
[-- Attachment #2: demo-ppc603e.sh --]
[-- Type: text/plain, Size: 664 bytes --]
#!/bin/sh
set -ex
TARBALLS_DIR=$HOME/src/mpc5200_binar/build-tools/downloads
RESULT_TOP=$HOME/src/mpc5200_binar/tools
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES
# Really, you should do the mkdir before running this,
# and chown /opt/crosstool to yourself so you don't need to run as root.
mkdir -p $RESULT_TOP
# Build the toolchain. Takes a couple hours and a couple gigabytes.
#eval `cat powerpc-604.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --builduserland --notest
eval `cat powerpc-603e.dat gcc-3.4.1-glibc-2.3.3.dat` sh all.sh --notest
#eval `cat powerpc-604.dat gcc-3.4.1-glibc-20040827.dat` sh all.sh --notest
echo Done.
[-- Attachment #3: powerpc-603e.dat --]
[-- Type: text/plain, Size: 125 bytes --]
TARGET=powerpc-603e-linux-gnu
TARGET_CFLAGS="-O -mcpu=603e"
GCC_EXTRA_CONFIG="--with-cpu=603e --enable-cxx-flags=-mcpu=603e"
^ permalink raw reply
* [PATCH] emac: fix mdio delay
From: Matt Porter @ 2005-02-09 5:43 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-embedded
Fixes MDIO delay. Please apply.
Signed-off-by: Ralph Siemsen <ralphs@netwinder.org>
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
--- linux-2.6.10-orig/drivers/net/ibm_emac/ibm_emac_core.c 2005-01-20 15:45:28.576226303 -0500
+++ linux-2.6.10/drivers/net/ibm_emac/ibm_emac_core.c 2005-01-20 15:25:10.430674655 -0500
@@ -475,8 +479,9 @@
out_be32(&emacp->em0stacr, stacr);
- while (((stacr = in_be32(&emacp->em0stacr) & EMAC_STACR_OC) == 0)
- && (count++ < 5000))
+ count = 0;
+ while ((((stacr = in_be32(&emacp->em0stacr)) & EMAC_STACR_OC) == 0)
+ && (count++ < MDIO_DELAY))
udelay(1);
MDIO_DEBUG((" (count was %d)\n", count));
^ permalink raw reply
* Re: Problems with Serial Port on IceCube
From: Linas Petras @ 2005-02-09 5:36 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: 'Sylvain Munaut'
I have tried using another serial cable (as suggested by Wolfgang) but =
it
made no difference, but I did not expect it to as I get all the messages
from the bootroms OK.
I have have confirmed that I have (as suggested by Sylvian) set
CONFIG_CMDLINE=3D "console=3DttyS0" and have also tried =
"console=3DttyS0, 115200"
(as my serial port is set to 115200 on the icecube board) without any
messages after arch:exit.=20
Below is what I see when I try and boot Sylvians 2-6-10-rc2 kernel.
=3D> tftp 200000
Using FEC ETHERNET device
TFTP from server 192.168.1.101; our IP address is 192.168.1.201
Filename 'uImage'.
Load address: 0x200000
Loading: =
#################################################################
#################################################################
#################################################################
#############################################################
done
Bytes transferred =3D 1305842 (13ecf2 hex)
=3D> bootm 200000
## Booting image at 00200000 ...
Image Name: Linux-2.6.10-rc2
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1305778 Bytes =3D 1.2 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
ocp: exit
arch: exit
=20
At this point all output to the serial port stops but the board boots =
and I
can telnet to the IP address. It's not that important in the greater =
scheme
of things, just very annoying :-(
Below is a "printenv" from the icecube-uboot.
baudrate=3D115200
ethact=3DFEC ETHERNET
preboot=3Decho;echo AutoStarting. Press any key to abort ...;echo
ethaddr=3D00:04:9F:00:12:60
bootdelay=3D5
hostname=3Dicecube
flashboot=3Droot=3D/dev/mtdblock2 rw
rootfs=3Droot=3D/dev/nfs rw =
nfsroot=3D192.168.1.101:/work/ELDK-3.1/ppc_6xx
bootfile=3DuImage
nfsroot=3Droot=3D/dev/nfs rw =
nfsroot=3D192.168.1.101:/work/ELDK-3.1/ppc_6xx
ip=3Dip=3D192.168.1.201:192.168.1.101:192.168.1.101:255.255.255.0:icecube=
::off
bootargs=3Droot=3D/dev/nfs rw =
nfsroot=3D192.168.1.101:/work/ELDK-3.1/ppc_6xx
ip=3D192.16
8.1.201:192.168.1.101:192.168.1.101:255.255.255.0:icecube::off
filesize=3Db7d6e
fileaddr=3D100000
netmask=3D255.255.255.0
ipaddr=3D192.168.1.201
serverip=3D192.168.1.101
bootcmd=3Dbootm ff100000
stdin=3Dserial
stdout=3Dserial
stderr=3Dserial
Any ideas????
Linas Petras
------------
I know not with which weapons World War III will be faught, but World =
War IV
will be faught with sticks and stones. - Albert Einstein.
^ permalink raw reply
* [PATCH] emac: fix jumbo frame support
From: Matt Porter @ 2005-02-09 5:34 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linuxppc-embedded
Fixes a bug in RX buffer allocation so that jumbo size skbs are
allocated when the MTU size is changed. Also removes the deprecated
restore_flags() call. Please apply.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
===== drivers/net/ibm_emac/ibm_emac_core.c 1.7 vs edited =====
--- 1.7/drivers/net/ibm_emac/ibm_emac_core.c 2004-12-07 10:06:23 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_core.c 2005-02-08 22:25:39 -07:00
@@ -912,7 +912,6 @@
PKT_DEBUG(("emac_start_xmit() stopping queue\n"));
netif_stop_queue(dev);
spin_unlock_irqrestore(&fep->lock, flags);
- restore_flags(flags);
return -EBUSY;
}
@@ -1281,7 +1280,7 @@
/* Format the receive descriptor ring. */
ep->rx_slot = 0;
/* Default is MTU=1500 + Ethernet overhead */
- ep->rx_buffer_size = ENET_DEF_BUF_SIZE;
+ ep->rx_buffer_size = dev->mtu + ENET_HEADER_SIZE + ENET_FCS_SIZE;
emac_rx_fill(dev, 0);
if (ep->rx_slot != 0) {
printk(KERN_ERR
===== drivers/net/ibm_emac/ibm_emac_core.h 1.2 vs edited =====
--- 1.2/drivers/net/ibm_emac/ibm_emac_core.h 2004-08-05 07:26:55 -07:00
+++ edited/drivers/net/ibm_emac/ibm_emac_core.h 2005-02-08 22:24:52 -07:00
@@ -77,8 +77,6 @@
#define ENET_HEADER_SIZE 14
#define ENET_FCS_SIZE 4
-#define ENET_DEF_MTU_SIZE 1500
-#define ENET_DEF_BUF_SIZE (ENET_DEF_MTU_SIZE + ENET_HEADER_SIZE + ENET_FCS_SIZE)
#define EMAC_MIN_FRAME 64
#define EMAC_MAX_FRAME 9018
#define EMAC_MIN_MTU (EMAC_MIN_FRAME - ENET_HEADER_SIZE - ENET_FCS_SIZE)
^ permalink raw reply
* Re: [PATCH] sungem update
From: Benjamin Herrenschmidt @ 2005-02-09 4:32 UTC (permalink / raw)
To: David S. Miller; +Cc: linuxppc-dev list, Jeff Garzik
In-Reply-To: <20050208164042.6dd6fcb0.davem@davemloft.net>
Hi !
> Sorry for taking so long to review this :-/
No worries.
> This looks fine, except for one thing. The WOL_* registers don't exist
> in the Sun variants of the GEM chip, so it's not safe to try and program
> them on all chips blindly like these changes do. Perhaps some bit test
> like:
>
> if (pdev->vendor != PCI_VENDOR_ID_SUN)
> gp->flags |= GEM_HAS_WOL;
>
> Then protect all the WOL_* register programming with this new
> GEM_HAS_WOL flag.
Ok, I'll have a look.
Ben.
^ permalink raw reply
* Re: [PATCH] sungem update
From: David S. Miller @ 2005-02-09 0:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, jgarzik
In-Reply-To: <1106028614.4533.69.camel@gaston>
On Tue, 18 Jan 2005 17:10:14 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This patch updates the sungem driver. I reworked all of the PM stuff, making it
> less prone to races, probably simpler to read as well, and I no longer shut the
> PHY down when the interface is down so that things like laptop-net no longer
> die (the gain in power consumption was minimal, not worth the pain). I also
> implemented basic WOL support.
>
> There is still something I'm not totally happy with in the locking
> (explained in the comment at the beginning), basically too much locking and a
> couple of places with delays in locks. I will try to improve these later on.
>
> If you are happy with this, please forward to Linus/Andrew asap
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Sorry for taking so long to review this :-/
This looks fine, except for one thing. The WOL_* registers don't exist
in the Sun variants of the GEM chip, so it's not safe to try and program
them on all chips blindly like these changes do. Perhaps some bit test
like:
if (pdev->vendor != PCI_VENDOR_ID_SUN)
gp->flags |= GEM_HAS_WOL;
Then protect all the WOL_* register programming with this new
GEM_HAS_WOL flag.
^ permalink raw reply
* Re: [PATCH][PPC32] mktree fix
From: Tom Rini @ 2005-02-08 22:33 UTC (permalink / raw)
To: Andre' Draszik; +Cc: linuxppc-embedded
In-Reply-To: <4206EFDC.3090904@gmx.net>
On Mon, Feb 07, 2005 at 05:34:36AM +0100, Andre' Draszik wrote:
> This one fixes mktree. The image size stored in the header is pretty off
> without
> this patch. (yes, it can make a difference of upto almost 64k)
>
> Signed-off-by: Andre' Draszik <andid@gmx.net>
With this wrong, what breaks? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ 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