* random code execution - kernel oops
From: Johannes Berg @ 2007-06-18 13:04 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 4969 bytes --]
unsigned long hx = 0x4bfcc50c;
int main()
{
asm("bl hx");
}
yields:
[101274.818295] Unable to handle kernel paging request for data at address 0x0ffdc000
[101274.818313] Faulting instruction address: 0xc00122a8
[101274.818330] Oops: Kernel access of bad area, sig: 11 [#11]
[101274.818335] PREEMPT PowerMac
[101274.818341] Modules linked in: nls_iso8859_15 isofs zlib_inflate udf af_packet binfmt_misc radeon drm hci_usb rfcomm l2cap bluetooth snd_powermac configfs nls_utf8 hfsplus nls_base fuse dm_snapshot dm_mirror sha256 joydev snd_aoa_codec_tas snd_aoa_fabric_layout appletouch snd_aoa usbhid firewire_ohci firewire_core crc_itu_t bcm43xx ieee80211softmac ieee80211 ieee80211_crypt arc4 snd_aoa_i2sbus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc rc80211_simple snd soundcore ohci1394 ieee1394 snd_aoa_soundbus bcm43xx_mac80211 ssb ehci_hcd pcmcia firmware_class mac80211 ohci_hcd cfg80211 yenta_socket rsrc_nonstatic usbcore uninorth_agp pcmcia_core agpgart evdev unix
[101274.818448] NIP: c00122a8 LR: c0015950 CTR: 00000080
[101274.818456] REGS: cb157cd0 TRAP: 0300 Not tainted (2.6.22-rc4-g7d59453a-dirty)
[101274.818463] MSR: 00009032 <EE,ME,IR,DR> CR: 33003353 XER: 80000000
[101274.818478] DAR: 0ffdc000, DSISR: 40000000
[101274.818485] TASK = cfc56670[19956] '0x4bfcc50c' THREAD: cb156000
[101274.818490] GPR00: cfc0dc40 cb157d80 cfc56670 0ffdc000 00000080 22723101 0ffdc000 40000000
[101274.818508] GPR08: c084e000 cfc0dc40 00000000 c084e000 0000015b 100189a0 c0610000 0ffdc000
[101274.818525] GPR16: c05f8a10 100d0000 fe3fffff 00000000 ca437200 00000000 d2b170fc c0610000
[101274.818542] GPR24: cfc0dc40 00000f70 0ffdceac ec849a58 ec849a58 0ffdceac 22723101 c0c9c460
[101274.818560] NIP [c00122a8] __flush_dcache_icache+0x14/0x40
[101274.818580] LR [c0015950] update_mmu_cache+0xec/0xf0
[101274.818591] Call Trace:
[101274.818596] [cb157d80] [00000f70] 0xf70 (unreliable)
[101274.818610] [cb157da0] [c0079cec] __handle_mm_fault+0x2d8/0xbe4
[101274.818623] [cb157e10] [c0301aa8] do_page_fault+0x41c/0x554
[101274.818640] [cb157f40] [c00119f4] handle_page_fault+0xc/0x80
[101274.818650] --- Exception: 401 at 0xffdceac
[101274.818660] LR = 0x1000043c
[101274.818664] Instruction dump:
[101274.818670] 4d820020 7c8903a6 7c001bac 38630020 4200fff8 7c0004ac 4e800020 60000000
[101274.818687] 54630026 38800080 7c8903a6 7c661b78 <7c00186c> 38630020 4200fff8 7c0004ac
[101274.818707] note: 0x4bfcc50c[19956] exited with preempt_count 2
[101274.818716] BUG: sleeping function called from invalid context at kernel/rwsem.c:20
[101274.818723] in_atomic():1, irqs_disabled():0
[101274.818727] Call Trace:
[101274.818732] [cb157bc0] [c0008e10] show_stack+0x3c/0x194 (unreliable)
[101274.818748] [cb157bf0] [c0027648] __might_sleep+0xd0/0xec
[101274.818764] [cb157c00] [c00494d4] down_read+0x24/0x5c
[101274.818778] [cb157c20] [c005cda4] acct_collect+0x44/0x1a4
[101274.818793] [cb157c40] [c0030470] do_exit+0x10c/0x8c4
[101274.818805] [cb157c80] [c000ff34] die+0x210/0x218
[101274.818815] [cb157cb0] [c0015600] bad_page_fault+0x90/0xd8
[101274.818825] [cb157cc0] [c0011a64] handle_page_fault+0x7c/0x80
[101274.818835] --- Exception: 300 at __flush_dcache_icache+0x14/0x40
[101274.818846] LR = update_mmu_cache+0xec/0xf0
[101274.818852] [cb157d80] [00000f70] 0xf70 (unreliable)
[101274.818901] [cb157da0] [c0079cec] __handle_mm_fault+0x2d8/0xbe4
[101274.818911] [cb157e10] [c0301aa8] do_page_fault+0x41c/0x554
[101274.818923] [cb157f40] [c00119f4] handle_page_fault+0xc/0x80
[101274.818933] --- Exception: 401 at 0xffdceac
[101274.818942] LR = 0x1000043c
[101274.818961] BUG: scheduling while atomic: 0x4bfcc50c/0x10000002/19956
[101274.818967] Call Trace:
[101274.818971] [cb157ac0] [c0008e10] show_stack+0x3c/0x194 (unreliable)
[101274.818984] [cb157af0] [c02fe44c] schedule+0x584/0x6b4
[101274.818994] [cb157b40] [c00276f4] __cond_resched+0x34/0x60
[101274.819006] [cb157b50] [c02fe8f4] cond_resched+0x50/0x58
[101274.819016] [cb157b60] [c0077964] unmap_vmas+0x698/0x6b4
[101274.819026] [cb157be0] [c007c558] exit_mmap+0x74/0x120
[101274.819036] [cb157c10] [c002a1f0] mmput+0x68/0xf8
[101274.819048] [cb157c20] [c002e7fc] exit_mm+0xac/0x110
[101274.819058] [cb157c40] [c0030484] do_exit+0x120/0x8c4
[101274.819067] [cb157c80] [c000ff34] die+0x210/0x218
[101274.819077] [cb157cb0] [c0015600] bad_page_fault+0x90/0xd8
[101274.819087] [cb157cc0] [c0011a64] handle_page_fault+0x7c/0x80
[101274.819097] --- Exception: 300 at __flush_dcache_icache+0x14/0x40
[101274.819109] LR = update_mmu_cache+0xec/0xf0
[101274.819115] [cb157d80] [00000f70] 0xf70 (unreliable)
[101274.819125] [cb157da0] [c0079cec] __handle_mm_fault+0x2d8/0xbe4
[101274.819135] [cb157e10] [c0301aa8] do_page_fault+0x41c/0x554
[101274.819147] [cb157f40] [c00119f4] handle_page_fault+0xc/0x80
[101274.819157] --- Exception: 401 at 0xffdceac
[101274.819166] LR = 0x1000043c
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [patch 1/6] ps3: Preallocate bootmem memory for the PS3 FLASH
From: Geert Uytterhoeven @ 2007-06-19 11:36 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <bc61eb97d01812aeccaff374fd1d775b@bga.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1946 bytes --]
On Mon, 18 Jun 2007, Milton Miller wrote:
> On Fri Jun 15 23:32:41 EST 2007, Geert Uytterhoeven wrote:
> > On Fri, 15 Jun 2007, Benjamin Herrenschmidt wrote:
> > > On Fri, 2007-06-15 at 13:39 +0200, Geert Uytterhoeven wrote:
> > > > Preallocate 256 KiB of bootmem memory for the PS3 FLASH ROM storage
> > > > driver.
> > >
> > > I still very much dislike the #ifdef xxx_MODULE in main kernel code.
> >
> > Me too, but there's no other reliable way to allocate it after boot up...
> >
> > > At the end of the day, is it realistic to ever use a PS3 without the
> > > storage driver ? I would suggest just allocating those unconditionally.
> >
> > If you don't plan to (a) boot into GameOS or (b) update the kboot kernel,
> > then the answer is: yes, you can live without the FLASH ROM driver, and save
> > one promille of RAM.
>
> In that case, why not make it an early_param, and only change the default
> based on the config varables? It sounds like I might want to reclaim this
> memory even if I compiled in the driver.
Like `ps3flash=off' on the kernel command line to disable it? Can be done.
> Statement (a) is because one has to write the flag to say don't' boot OtherOS
> to go back to GameOS (or reset all defaults) I presume.
Indeed, there's a flag in the FLASH ROM to choose between booting GameOS and
OtherOS (e.g. Linux).
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [patch 6/6] ps3: FLASH ROM Storage Driver
From: Geert Uytterhoeven @ 2007-06-19 12:02 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <89ca7c200ed0f7c47387af99643df6a1@bga.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2207 bytes --]
Hi Milton,
Thanks for your comments!
On Mon, 18 Jun 2007, Milton Miller wrote:
> You indicated that the primary reasons to use this driver were to boot back
> into GameOS, or reinstall the boot loader, yet your Kconfig entry says "In
> general, all users will say Y or M". This could give a bit more guidance.
Normal users boot back into GameOS from time to time (I don't consider myself a
normal user ;-)
> ps3flash_read_write_sectors chooses a string every call that is only used on
> the error path.
Fixed.
> ps3flash_read gives priority to returning an encountered error. If it made
> partial progress (eg partially mapped user buffer) it should return the count
> of bytes sent to the user.
Apparently all character drivers in drivers/char/mem.c immediately return
-EFAULT if copy_to_user() fails. The behavior of ps3flash is consistent with
this.
> ps3_write will call the hypervisor to write an aligned chunk of memory every
> call. I'm guessing the hypervisor does no buffering of the flash. If the
> file is written with a small block size, this will
> cause unnecessary flash wear. Have you considered requiring the application
> to write the full 256MiB, or alternatively delaying the actual write call
> until either close, the write reaches the boundary, or a read or write
> accesses another chunk? Yes, the later would mean short writes would receive
> the error on close.
I do not know how the hypervisor handles this internally.
But as the only time you write to the FLASH ROM is to change some boot flags or
upgrade the boot loader, I don't think this is a big problem.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Regarding SCC in DTS File
From: b.vigneshkumar @ 2007-06-19 12:19 UTC (permalink / raw)
To: Zhang Wei-r63237, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 395 bytes --]
Hi,
What does these two lines in DTS File.
Can u let me know what this suppose to mean
scc@a00 {
........
rx-clock = <1>;
tx-clock = <1>;
........
interrupts = <1e 3>;
interrupt-parent = <&Cpm_pic>;
}
Actually where can we get a better documentation for the DTS File? If
you have any reference please let me know. Thanks A Lot.
Regards,
Vignesh
[-- Attachment #2: b.vigneshkumar.vcf --]
[-- Type: text/x-vcard, Size: 178 bytes --]
begin:vcard
fn:Vignesh Kumar Bagavathsingh
n:Bagavathsingh;Vignesh Kumar
email;internet:b.vigneshkumar@gdatech.com
tel;work:6513
tel;home:044-23773210
version:2.1
end:vcard
^ permalink raw reply
* Re: [PATCH] Add the support of ST M48T59 RTC chip in rtc-class driver subsystem
From: Alessandro Zummo @ 2007-06-19 12:29 UTC (permalink / raw)
To: Mark Zhan; +Cc: linuxppc-dev@ozlabs.org, rtc-linux
In-Reply-To: <1181657546.3975.25.camel@mark>
On Tue, 12 Jun 2007 22:12:25 +0800
Mark Zhan <rongkai.zhan@windriver.com> wrote:
> Hi All,
>
> For the platform data of RTC chip driver, you know, currently we use
> different header files to define different driver-specific platform data
> structure. For example: linux/m48t86.h, linux/rtc-v3020.h....
>
> Could we consider to add a new header file linux/rtc_pd.h to gather them
> together, and remove those rtc platform data header files in
> include/linux directory?
files in linux/ are the ones that are required by other modules
of the kernel and it wouldn't be fair to combine all of them.
I'd rather add a linux/rtc directory.
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
^ permalink raw reply
* Re: [patch 5/6] ps3: ROM Storage Driver
From: Geert Uytterhoeven @ 2007-06-19 12:29 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <d46c75da8a86ab5cd83b63f9dbfee33f@bga.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2902 bytes --]
On Mon, 18 Jun 2007, Milton Miller wrote:
> > +config PS3_ROM
> > + tristate "PS3 ROM Storage Driver"
> > + depends on PPC_PS3 && BLK_DEV_SR
> > + select PS3_STORAGE
> > + help
> > + Include support for the PS3 ROM Storage.
> > +
> > + This support is required to access the PS3 BD/DVD/CD-ROM drive.
> > + In general, all users will say Y or M.
> > +
>
>
> When I think ROM I usually dont' start with optical media.
>
> Have you condered calling this the optical driver?
The name comes from the SCSI device type (0x05 == TYPE_ROM). But if people
prefer ps3atapi, I can change it.
> Or at least putting BD?DVD?CD-ROM on the prompt.
>
>
> Why does it depend on BLK_DEV_SR?
Because it needs SCSI CD-ROM support.
> > +static int __devinit ps3rom_probe(struct ps3_system_bus_device *_dev)
> > +{
> > + struct ps3_storage_device *dev = to_ps3_storage_device(&_dev->core);
> > + int error;
> > + struct Scsi_Host *host;
> > + struct ps3rom_private *priv;
> > +
> > + if (dev->blk_size != CD_FRAMESIZE) {
> > + dev_err(&dev->sbd.core,
> > + "%s:%u: cannot handle block size %lu\n", __func__,
> > + __LINE__, dev->blk_size);
> > + return -EINVAL;
> > + }
> > +
> > + dev->bounce_size = BOUNCE_SIZE;
> > + dev->bounce_buf = kmalloc(BOUNCE_SIZE, GFP_DMA);
> > + if (!dev->bounce_buf) {
> > + return -ENOMEM;
> > + }
> > +
> > + error = ps3stor_setup(dev);
> > + if (error)
> > + goto fail_free_bounce;
> > +
> > + /* override the interrupt handler */
> > + free_irq(dev->irq, dev);
> > + error = request_irq(dev->irq, ps3rom_interrupt, IRQF_DISABLED,
> > + dev->sbd.core.driver->name, dev);
> > + if (error) {
> > + dev_err(&dev->sbd.core, "%s:%u: request_irq failed %d\n",
> > + __func__, __LINE__, error);
> > + goto fail_teardown;
> > + }
> > +
>
> Somebody's help isn't helpful? Layering problem?
ps3stor_setup() tries to read from the device to check its accessibility,
and uses a simple interrupt routine for synchronous operations (using the
completion). This interrupt routine is also used for ps3flash.
Ps3rom and ps3disk do asynchronous device accesses, hence they use different
interrupt routines.
I guess I can add synchronous support to the ps3rom interrupt handler (ps3disk
already has this, for sync cache), so ps3stor_setup() can use them for probing,
too.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Gerhard Pircher @ 2007-06-19 12:37 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, david
In-Reply-To: <81b5cc3c799c9ec65df04468d4d9051e@kernel.crashing.org>
-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 12:08:06 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, david@gibson.dropbear.id.au
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc
> > I guess I can define both of them or do they conflict (IIRC
> > the two hardware revision should be compatible)?
>
> Use one or the other, not both. Perhaps you'll need
> to add the pnpPNP,500 and pnpPNP,501 entries to the
> generic OF serial code, should be trivial to do.
I guess I stick with compatible = "serial" for now, as it should
also work with the generic serial console support code.
> The 16550A supports something the 16550 doesn't (don't
> ask me what, I forgot :-) ), so don't say it is an A
> when it isn't; the other way around is fine though.
>
> And it doesn't matter much for Linux anyway currently,
> the "generic" kernel driver will do its own wacky probing.
Yes, that's why the current AmigaOne kernels (2.6.16) detect 3 serial
ports, whereas there should be only 2 (the first two are detected by
probing for the VIA southbridge and the last one IIRC is registered by
request_region()). I hope the device tree fixes this.
> > Where are all this "pnpPNP,xxx" identifiers specified (except
> > for serial parallel, fdc, keyboard, mouse)?
>
> They are defined by the vendor of the devices; for
> vendor "PNP", i.e. legacy non-PNP PC devices, that
> is MicroSoft.
Downloaded the file you pointed to and the OF generic names document. I
thought the OF core specification defines them, but it's not available
freely.
Thanks a lot!
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: Geert Uytterhoeven @ 2007-06-19 12:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, James E.J. Bottomley, linux-scsi, linux-kernel,
linuxppc-dev, Paul Mackerras
In-Reply-To: <20070619054324.GA18542@lst.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1266 bytes --]
On Tue, 19 Jun 2007, Christoph Hellwig wrote:
> On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote:
> > From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> >
> > Add a Disk Storage Driver for the PS3:
> > - Implemented as a block device driver with a dynamic major
> > - Disk names (and partitions) are of the format ps3d%c(%u)
> > - Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
> > doesn't support scatter-gather
>
> Looks good to me. Only nitpicks are:
>
> - ps3disk_priv should probably be an inline function instead of a macro
I used a macro because you can do
ps3disk_pri(dev) = ...;
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Segher Boessenkool @ 2007-06-19 13:15 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev, david
In-Reply-To: <20070619123721.202110@gmx.net>
>>> I guess I can define both of them or do they conflict (IIRC
>>> the two hardware revision should be compatible)?
>>
>> Use one or the other, not both. Perhaps you'll need
>> to add the pnpPNP,500 and pnpPNP,501 entries to the
>> generic OF serial code, should be trivial to do.
> I guess I stick with compatible = "serial" for now, as it should
> also work with the generic serial console support code.
"compatible" = "serial" is completely wrong -- it is
a generic name and should never be matched on.
>> The 16550A supports something the 16550 doesn't (don't
>> ask me what, I forgot :-) ), so don't say it is an A
>> when it isn't; the other way around is fine though.
>>
>> And it doesn't matter much for Linux anyway currently,
>> the "generic" kernel driver will do its own wacky probing.
> Yes, that's why the current AmigaOne kernels (2.6.16) detect 3 serial
> ports, whereas there should be only 2 (the first two are detected by
> probing for the VIA southbridge and the last one IIRC is registered by
> request_region()). I hope the device tree fixes this.
It should, yes.
>>> Where are all this "pnpPNP,xxx" identifiers specified (except
>>> for serial parallel, fdc, keyboard, mouse)?
>>
>> They are defined by the vendor of the devices; for
>> vendor "PNP", i.e. legacy non-PNP PC devices, that
>> is MicroSoft.
> Downloaded the file you pointed to and the OF generic names document. I
> thought the OF core specification defines them, but it's not available
> freely.
That's a common misconception :-)
<ftp://playground.sun.com/pub/p1275/coredoc/1275-1994/1275.ps.gz>
Segher
^ permalink raw reply
* Re: [RFC] Device tree for new desktop platform in arch/powerpc
From: Gerhard Pircher @ 2007-06-19 13:29 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, david
In-Reply-To: <bec0a23b1a544fe66810f43a73b142a2@kernel.crashing.org>
-------- Original-Nachricht --------
Datum: Tue, 19 Jun 2007 15:15:33 +0200
Von: Segher Boessenkool <segher@kernel.crashing.org>
An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
CC: linuxppc-dev@ozlabs.org, david@gibson.dropbear.id.au
Betreff: Re: [RFC] Device tree for new desktop platform in arch/powerpc
> "compatible" = "serial" is completely wrong -- it is
> a generic name and should never be matched on.
Doh again! Looks like I'm absent-minded today.
> > Downloaded the file you pointed to and the OF generic names document. I
> > thought the OF core specification defines them, but it's not available
> > freely.
>
> That's a common misconception :-)
>
> <ftp://playground.sun.com/pub/p1275/coredoc/1275-1994/1275.ps.gz>
So much for "available commercially". :-) Thanks!
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: base system for avnet virtex 4 fx mini module
From: Glenn.G.Hart @ 2007-06-19 14:25 UTC (permalink / raw)
To: linuxppc-embedded
I am also using the Avenet MM. The best luck I have had was using EDK8.2
and the updated board support from Avent. Once I has these I was able to
add the TEMAC and PLB memory controller. These seemed to be the key. I
have not tried the flash device. I am also having trouble with the
network.
Glenn
>Dear all,
>
>After brining up linux on ML403 I'm now going toward using AVNET mini
module as the next step
>
>I studied available examples from AVNET and I can not find any suitable
base system with both of TEMAC and Flash memory interfaces available in it.
>
>Does any body here can share his EDK project on AVNET mini module with me?
Mainly I need a base system with both of Hard TEMAC, PLB TEMAC and EMC
flash interface >available in it.
>
>thanks for kindness and help,
>mohammad sadegh sadri
>
>_________________________________________________________________
>Explore the seven wonders of the world
>http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH/RFC] Modify sched_clock() to make CONFIG_PRINTK_TIME more sane.
From: Olof Johansson @ 2007-06-19 14:53 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev
In-Reply-To: <20070619063557.GK9768@bakeyournoodle.com>
Hi,
On Tue, Jun 19, 2007 at 04:35:57PM +1000, Tony Breeds wrote:
> When booting a current kernel with CONFIG_PRINTK_TIME enabled you'll
> see messages like:
>
> [ 0.000000] time_init: decrementer frequency = 188.044000 MHz
> [ 0.000000] time_init: processor frequency = 1504.352000 MHz
> [3712914.436297] Console: colour dummy device 80x25
>
> This patch modifies sched_clock() to report the offset since the machine booted
> so the same printk's now look like:
>
> [ 0.000000] time_init: decrementer frequency = 188.044000 MHz
> [ 0.000000] time_init: processor frequency = 1504.352000 MHz
> [ 0.000135] Console: colour dummy device 80x25
>
> Effectivly including the uptime in printk()s.
Nice!
> Index: working/arch/powerpc/kernel/time.c
> ===================================================================
> --- working.orig/arch/powerpc/kernel/time.c
> +++ working/arch/powerpc/kernel/time.c
> @@ -115,6 +115,7 @@ EXPORT_SYMBOL_GPL(rtc_lock);
>
> u64 tb_to_ns_scale;
> unsigned tb_to_ns_shift;
> +unsigned long boot_tb;
It only seems to be used in this file, so it can be static, right?
-Olof
^ permalink raw reply
* Virtex 4 Avnet Mini-Module Networking.
From: Glenn.G.Hart @ 2007-06-19 15:21 UTC (permalink / raw)
To: linuxppc-embedded
I am having trouble using the network on the Avent Mini-Module. I had the
network working on the ML403 board with Linux 2.6.19.
The kernel comes up fine with the Mini-Module and the network seems to work
until I try to use it. I can configured the ethernet with ifconfig and can
even ping another machine on the network.
The problem is with the TCP layer. It seems almost everytime the
Mini-Module sends TCP information the checksum is reported an wrong (via
ethereal). The only thing that comes to mind is the ML403 uses a Marvell
PHY and the Mini-Module has a Broadcom PHY. I do not know enough about
low-level networking to know where the problem is. Is the checksum
generated in the PHY? Could something be wrong in Linux programming the
Broadcom PHY and not the Marvell PHY? Why is it only the TCP information
(the IP information has the correct checksum)?
Thanks for any information you can offer.
Glenn
^ permalink raw reply
* [PATCH] PowerPC: Prevent data exception in kernel space (32-bit)
From: Segher Boessenkool @ 2007-06-19 15:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Johannes Berg, Paul Mackerras
In-Reply-To: <1182171859.21013.3.camel@johannes.berg>
The "is_exec" branch of the protection check in do_page_fault()
didn't do anything on 32-bit PowerPC. So if a userland program
jumps to a page with Linux protection flags "---p", all the tests
happily fall through, and handle_mm_fault() is called, which in
turn calls handle_pte_fault(), which calls update_mmu_cache(),
which goes flush the dcache to a page with no access rights.
Boom.
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Paul Mackerras <paulus@samba.org>
---
Johannes, please test. Paul, I think you'll want this for .22 still?
If the patch is correct, anyway ;-)
arch/powerpc/mm/fault.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index bfe9013..115b25f 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -279,14 +279,13 @@ good_area:
#endif /* CONFIG_8xx */
if (is_exec) {
-#ifdef CONFIG_PPC64
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
/* protection fault */
if (error_code & DSISR_PROTFAULT)
goto bad_area;
if (!(vma->vm_flags & VM_EXEC))
goto bad_area;
-#endif
-#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
+#else
pte_t *ptep;
pmd_t *pmdp;
--
1.5.2.1.144.gabc40-dirty
^ permalink raw reply related
* Re: Virtex 4 Avnet Mini-Module Networking.
From: Yoshio Kashiwagi @ 2007-06-19 15:51 UTC (permalink / raw)
To: Glenn.G.Hart, linuxppc-embedded
In-Reply-To: <OF3C9BCACE.144FD16A-ON852572FF.004F2888-852572FF.005457E7@ct.wec.com>
Glenn-san,
The PLB TEMAC driver is supporting checksum off loading (checksum
calculation by hardware).
If the same kernel source is used, isn't the hardware checksum
of PLB TEMAC disabled by the MHS file of Mini-Module?
BEGIN plb_temac
PARAMETER INSTANCE = plb_temac_0
PARAMETER HW_VER = 3.00.a
PARAMETER C_PLB_CLK_PERIOD_PS = 10000
PARAMETER C_TXFIFO_DEPTH = 131072
PARAMETER C_RXFIFO_DEPTH = 131072
PARAMETER C_MAC_FIFO_DEPTH = 64
PARAMETER C_BASEADDR = 0x80000000
PARAMETER C_HIGHADDR = 0x8000ffff
PARAMETER C_INCLUDE_RX_CSUM = 1 <--- H/W checksum enable
PARAMETER C_INCLUDE_TX_CSUM = 1 <--- H/W checksum enable
PARAMETER C_RX_DRE_TYPE = 2
PARAMETER C_TX_DRE_TYPE = 2
Yoshio Kashiwagi - Nissin Systems
> I am having trouble using the network on the Avent Mini-Module. I had
the
> network working on the ML403 board with Linux 2.6.19.
>
> The kernel comes up fine with the Mini-Module and the network seems to
work
> until I try to use it. I can configured the ethernet with ifconfig
and can
> even ping another machine on the network.
>
> The problem is with the TCP layer. It seems almost everytime the
> Mini-Module sends TCP information the checksum is reported an wrong
(via
> ethereal). The only thing that comes to mind is the ML403 uses a
Marvell
> PHY and the Mini-Module has a Broadcom PHY. I do not know enough
about
> low-level networking to know where the problem is. Is the checksum
> generated in the PHY? Could something be wrong in Linux programming
the
> Broadcom PHY and not the Marvell PHY? Why is it only the TCP
information
> (the IP information has the correct checksum)?
>
> Thanks for any information you can offer.
>
> Glenn
^ permalink raw reply
* Re: [PATCH] rheap: eliminates internal fragments caused by alignment
From: Joakim Tjernlund @ 2007-06-19 16:17 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev Development, Paul, Vitaly Bordug
In-Reply-To: <1182167304.2969.8.camel@gentoo-jocke.transmode.se>
On Mon, 2007-06-18 at 13:48 +0200, Joakim Tjernlund wrote:
> On Mon, 2007-06-18 at 19:29 +0800, Li Yang wrote:
> > The patch adds fragments caused by rh_alloc_align() back to free list, instead
> > of allocating the whole chunk of memory. This will greatly improve memory
> > utilization managed by rheap.
> >
> > It solves MURAM not enough problem with 3 UCCs enabled on MPC8323.
> >
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
>
> For what it is worth:
> I have tested this patch and it solves the problem with 3 UCCs
> as ethernet for me. This fixes a regression introduced after 2.6.20
> Please consider for 2.6.22
> Acked-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
I noticed Paulus pull request to Linus and this patch wasn't
included. I really want to see it included.
Jocke
^ permalink raw reply
* Re: for-2.6.23 branch in powerpc.git created
From: Scott Wood @ 2007-06-19 16:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Guennadi Liakhovetski
In-Reply-To: <18039.30713.948665.48880@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
>>I assume you mean "Call of_register_i2c_devices() for fsl-i2c"
>>(http://ozlabs.org/pipermail/linuxppc-dev/2007-May/036333.html)?
>
>
> Isn't that the one where you replied to yourself saying you'd posted
> the wrong patch? Did you ever post the right patch?
I did, but discussion ensued, and the consensus was that the original
patch is the way to do it.
-Scott
^ permalink raw reply
* Re: [patch 4/6] ps3: Disk Storage Driver
From: Christoph Hellwig @ 2007-06-19 17:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Jens Axboe, James E.J. Bottomley, linux-scsi, linux-kernel,
linuxppc-dev, Paul Mackerras, Christoph Hellwig
In-Reply-To: <Pine.LNX.4.62.0706191450120.4069@pademelon.sonytel.be>
On Tue, Jun 19, 2007 at 02:51:25PM +0200, Geert Uytterhoeven wrote:
> On Tue, 19 Jun 2007, Christoph Hellwig wrote:
> > On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote:
> > > From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> > >
> > > Add a Disk Storage Driver for the PS3:
> > > - Implemented as a block device driver with a dynamic major
> > > - Disk names (and partitions) are of the format ps3d%c(%u)
> > > - Uses software scatter-gather with a 64 KiB bounce buffer as the hypervisor
> > > doesn't support scatter-gather
> >
> > Looks good to me. Only nitpicks are:
> >
> > - ps3disk_priv should probably be an inline function instead of a macro
>
> I used a macro because you can do
>
> ps3disk_pri(dev) = ...;
I'm not exactly a fan of macros used as lvalues, but if you really
want this it can go in.
^ permalink raw reply
* Re: Regarding SCC in DTS File
From: Scott Wood @ 2007-06-19 17:57 UTC (permalink / raw)
To: b.vigneshkumar; +Cc: linuxppc-embedded, Zhang Wei-r63237
In-Reply-To: <4677C9C2.6080802@gdatech.co.in>
b.vigneshkumar wrote:
> Hi,
>
> What does these two lines in DTS File.
> Can u let me know what this suppose to mean
>
> scc@a00 {
> ........
> rx-clock = <1>;
> tx-clock = <1>;
These indicate which baud rate generator the serial port is attached to.
> ........
> interrupts = <1e 3>;
> interrupt-parent = <&Cpm_pic>;
These indicate that the serial port uses interrupt 0x1e on the CPM PIC.
> Actually where can we get a better documentation for the DTS File?
Documentation/powerpc/booting-without-of.txt
-Scott
^ permalink raw reply
* Re: Virtex 4 Avnet Mini-Module Networking.
From: Glenn.G.Hart @ 2007-06-19 18:06 UTC (permalink / raw)
To: kashiwagi, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]
Yoshio Kashiwagi,
Yes the checksum off loading is turned off. Should it be turned on? My
documentation says I need to use DMA mode to use checksum offloading.
Glenn
(Embedded Yoshio Kashiwagi <kashiwagi@co-nss.co.jp>@ozlabs.org
image moved 06/19/2007 11:51 AM
to file:
pic31426.pcx)
Sent by:
linuxppc-embedded-bounces+glenn.g.hart=us.westinghouse.com@ozlabs.org
To: Glenn.G.Hart@us.westinghouse.com, linuxppc-embedded@ozlabs.org
cc:
Subject: Re: Virtex 4 Avnet Mini-Module Networking.
Security Level:? Internal
Glenn-san,
The PLB TEMAC driver is supporting checksum off loading (checksum
calculation by hardware).
If the same kernel source is used, isn't the hardware checksum
of PLB TEMAC disabled by the MHS file of Mini-Module?
BEGIN plb_temac
PARAMETER INSTANCE = plb_temac_0
PARAMETER HW_VER = 3.00.a
PARAMETER C_PLB_CLK_PERIOD_PS = 10000
PARAMETER C_TXFIFO_DEPTH = 131072
PARAMETER C_RXFIFO_DEPTH = 131072
PARAMETER C_MAC_FIFO_DEPTH = 64
PARAMETER C_BASEADDR = 0x80000000
PARAMETER C_HIGHADDR = 0x8000ffff
PARAMETER C_INCLUDE_RX_CSUM = 1 <--- H/W checksum enable
PARAMETER C_INCLUDE_TX_CSUM = 1 <--- H/W checksum enable
PARAMETER C_RX_DRE_TYPE = 2
PARAMETER C_TX_DRE_TYPE = 2
Yoshio Kashiwagi - Nissin Systems
> I am having trouble using the network on the Avent Mini-Module. I had
the
> network working on the ML403 board with Linux 2.6.19.
>
> The kernel comes up fine with the Mini-Module and the network seems to
work
> until I try to use it. I can configured the ethernet with ifconfig
and can
> even ping another machine on the network.
>
> The problem is with the TCP layer. It seems almost everytime the
> Mini-Module sends TCP information the checksum is reported an wrong
(via
> ethereal). The only thing that comes to mind is the ML403 uses a
Marvell
> PHY and the Mini-Module has a Broadcom PHY. I do not know enough
about
> low-level networking to know where the problem is. Is the checksum
> generated in the PHY? Could something be wrong in Linux programming
the
> Broadcom PHY and not the Marvell PHY? Why is it only the TCP
information
> (the IP information has the correct checksum)?
>
> Thanks for any information you can offer.
>
> Glenn
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
[-- Attachment #2: pic31426.pcx --]
[-- Type: application/octet-stream, Size: 128 bytes --]
^ permalink raw reply
* Freescale MPC5121e support anybody?
From: David Jander @ 2007-06-19 18:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
Now that there are official details about this very promising looking chip, is
there anyone preparing linux support for it (maybe from Freescale)?
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC512X
I can imagine this being the perfect killer-SOC for many embedded-linux
applications...
Just curious,
--
David Jander
^ permalink raw reply
* 2.6.22: ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
From: Olaf Hering @ 2007-06-19 19:02 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
What happend to __ucmpdi2 from David Woodhouse?
google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:
ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
using the drivers/net/s2io* files from 2.6.21 with 2.6.22-rc5 fixes the
compile.
25805dcf9d83098cf5492117ad2669cd14cc9b24 adds two u64 >>= 48 followed by
a switch statement (line 2889 and 6816).
^ permalink raw reply
* Re: 2.6.22: ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
From: Stephen Hemminger @ 2007-06-19 20:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, linux-kernel
In-Reply-To: <20070619190253.GA19419@aepfle.de>
On Tue, 19 Jun 2007 21:02:53 +0200
Olaf Hering <olaf@aepfle.de> wrote:
>
> What happend to __ucmpdi2 from David Woodhouse?
> google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:
>
> ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
>
> using the drivers/net/s2io* files from 2.6.21 with 2.6.22-rc5 fixes the
> compile.
>
> 25805dcf9d83098cf5492117ad2669cd14cc9b24 adds two u64 >>= 48 followed by
> a switch statement (line 2889 and 6816).
Probably the "switch(err) {" needs a cast to a smaller type (like u8).
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: Virtex 4 Avnet Mini-Module Networking.
From: Mohammad Sadegh Sadri @ 2007-06-19 21:04 UTC (permalink / raw)
To: linuxppc-embedded, kashiwagi, glenn.g.hart
Dear Glenn,
Dear Yoshio
I'm wondering where are the original developers of TEMAC driver these days,=
I have not seen any posts from any of andrei nor grant in the recent weeks=
. may be they are involved in other projects.
checksum off loading can be used only with SGDMA, it can also remain disabl=
ed in this mode and the CPU will compute the CSUM itself.=20
Grant's kernel source tree is 2.6.21 and the latest release of EDK is 9.1SP=
2. these two make a good set of dev tools for building the needed systems.=
=20
as far as I know there are some bugs in the SP1 version of edk 9.1 which ma=
kes the ethernet link unstable. In our tests the systems implemented with E=
DK 9.1SP1 were not able to bring up the linux root file system on NFS corre=
ctly and we always encoutered "segmentation fault" messages even when we li=
mited the packet sizes with rsize and wsize kernel parameters.
Using EDK 9.1SP2 however ( and also the latest virtex-dev tree from grant's=
git tree ) we were able to bring up the root file system via NFS with exac=
tly no problem over both of 100mbits and 1000mbits links.
However unfortunately our band width tests for the gigabit ethernet link of=
ML403 has not resulted any good values till now ( all of the obtained valu=
es are smaller than 40mbits/s for both of 100 and 1000 links ) we have not =
understood the reason for this behavior yet.
any how, the main disscussion is about avnet mini module and availability o=
f good examples and good base systems for it.=20
Basically the main question can be stated as follows:
- Is there any reference design, or example available for avnet mini-module=
.?=20
---------------------------------------------------------------------------=
-----
>Message: 9
>Date: Tue, 19 Jun 2007 14:06:18 -0400
>From: Glenn.G.Hart@us.westinghouse.com
>Subject: Re: Virtex 4 Avnet Mini-Module Networking.
>To: kashiwagi@co-nss.co.jp, linuxppc-embedded@ozlabs.org
>Message-ID:
>=09
>Content-Type: text/plain; charset=3D"us-ascii"
>=20
>=20
>Yoshio Kashiwagi,
>=20
>Yes the checksum off loading is turned off. Should it be turned on? My
>documentation says I need to use DMA mode to use checksum offloading.
>=20
>Glenn
_________________________________________________________________
Connect to the next generation of MSN Messenger=A0
http://imagine-msn.com/messenger/launch80/default.aspx?locale=3Den-us&sourc=
e=3Dwlmailtagline=
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 3/5] cell: updated driver for DDR2 memory on AXON
From: Arnd Bergmann @ 2007-06-19 23:03 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: Akinobu Mita, linuxppc-dev
In-Reply-To: <20070619154812.GA20347@ps3linux.grid.fixstars.com>
On Tuesday 19 June 2007, Akinobu Mita wrote:
> > + if (of_address_to_resource(device->node, 0, &resource) != 0) {
> > + dev_err(&device->dev, "Cannot access device tree\n");
> > + rc = -EFAULT;
> > + goto failed;
> > + }
>
> of_address_to_resource() returns error code on failure:
>
> rc = of_address_to_resource(device->node, 0, &resource);
> if (rc) {
> dev_err(&device->dev, "Cannot access device tree\n");
> goto failed;
> }
>
> is better.
Right.
> > + bank->ph_addr = resource.start;
> > + bank->io_addr = (unsigned long) ioremap_flags(
> > + bank->ph_addr, bank->size, _PAGE_NO_CACHE);
> > + if (bank->io_addr == 0) {
> > + dev_err(&device->dev, "ioremap() failed\n");
> > + rc = -EFAULT;
> > + goto failed;
> > + }
> > +
> > + bank->disk = alloc_disk(AXON_RAM_MINORS_PER_DISK);
> > + if (bank->disk == NULL) {
> > + dev_err(&device->dev, "Cannot register disk\n");
> > + rc = -EFAULT;
> > + goto failed;
> > + }
>
> -ENOMEM is better than -EFAULT. Because alloc_disk() failure happens
> only when it runs out of memory.
yes. EFAULT should only be used when an access to user memory has failed,
so it's wrong practically everywhere in here, your other comments are
obviously correct as well.
Arnd <><
^ 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