* Re: PPC 440GX kernel 2.6 NAPI driver
From: emre kara @ 2005-03-18 10:25 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
I have patched emac_3-2.6-9.diff against kernel 2.6.11
release version and fixed the rejections, but the
problem that I faced is not only from the .rej files,I
have succeeded to compile the kernel and load the
target, but it take long time to boot and there was
some errors printed on the console, I think the patch
corrupted some other files
And also tested ethernet performance with the patched
kernel, it was not as good as 2.4 version, especialy
there was a huge performance decrease on the receive
side.
Second (big) problem is, I dont know how to log on to
BK tree :)
Maybe I can patch emac_3-2.6-8.diff against kernel
2.6.11, but I dont have this file(It is not on your
web site at the present.), where can I download it?
Thanks alot.
Emre
--- Eugene Surovegin <ebs@ebshome.net> wrote:
> On Fri, Mar 18, 2005 at 09:41:43AM +0000, emre kara
> wrote:
> > but I can't patch the file for
> > kernel 2.6.11 (emac_3-2.6-9.diff)(on kernel.org).
> > Some .rej files created by patch.(ie mii.rej).
> Which
> > kernel source must I use as base?
>
> emac_3-2.6-9.diff is against 2.6 BK tree as of
> 2005-03-07 11:01pm PST.
> I'll try to find some time this weekend and re-diff
> (if needed)
> against latest BK, in the meantime, try resolving
> those rejects -
> mii.rej shouldn't be very difficult.
>
> If you applying patch to the 2.6.11 _release_ (not
> current BK tree),
> try emac_3-2.6-8.diff.
>
> --
> Eugene
>
Send instant messages to your online friends http://uk.messenger.yahoo.com
^ permalink raw reply
* Re: PPC 440GX kernel 2.6 NAPI driver
From: Eugene Surovegin @ 2005-03-18 10:14 UTC (permalink / raw)
To: emre kara, linuxppc-embedded
In-Reply-To: <20050318101034.GD20239@gate.ebshome.net>
On Fri, Mar 18, 2005 at 02:10:34AM -0800, Eugene Surovegin wrote:
> 2.6.12-pre1.
Doh, it's too late for me, 2.6.12-rc1, of course.
--
Eugene
^ permalink raw reply
* Re: PPC 440GX kernel 2.6 NAPI driver
From: Eugene Surovegin @ 2005-03-18 10:10 UTC (permalink / raw)
To: emre kara; +Cc: linuxppc-embedded
In-Reply-To: <20050318095100.GC20239@gate.ebshome.net>
On Fri, Mar 18, 2005 at 01:51:00AM -0800, Eugene Surovegin wrote:
> On Fri, Mar 18, 2005 at 09:41:43AM +0000, emre kara wrote:
> > but I can't patch the file for
> > kernel 2.6.11 (emac_3-2.6-9.diff)(on kernel.org).
> > Some .rej files created by patch.(ie mii.rej). Which
> > kernel source must I use as base?
>
> emac_3-2.6-9.diff is against 2.6 BK tree as of 2005-03-07 11:01pm PST.
> I'll try to find some time this weekend and re-diff (if needed)
> against latest BK,
OK, I just checked, emac_3-2.6-9.diff should apply cleanly on
2.6.12-pre1.
--
Eugene
^ permalink raw reply
* Re: PPC 440GX kernel 2.6 NAPI driver
From: Eugene Surovegin @ 2005-03-18 9:51 UTC (permalink / raw)
To: emre kara; +Cc: linuxppc-embedded
In-Reply-To: <20050318094143.34185.qmail@web25708.mail.ukl.yahoo.com>
On Fri, Mar 18, 2005 at 09:41:43AM +0000, emre kara wrote:
> but I can't patch the file for
> kernel 2.6.11 (emac_3-2.6-9.diff)(on kernel.org).
> Some .rej files created by patch.(ie mii.rej). Which
> kernel source must I use as base?
emac_3-2.6-9.diff is against 2.6 BK tree as of 2005-03-07 11:01pm PST.
I'll try to find some time this weekend and re-diff (if needed)
against latest BK, in the meantime, try resolving those rejects -
mii.rej shouldn't be very difficult.
If you applying patch to the 2.6.11 _release_ (not current BK tree),
try emac_3-2.6-8.diff.
--
Eugene
^ permalink raw reply
* PPC 440GX kernel 2.6 NAPI driver
From: emre kara @ 2005-03-18 9:41 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: linuxppc-embedded
Dear Eugene;
I have downloaded diff file for both kernel 2.6 and
2.4 on http://kernel.ebshome.net, I can succesfully
patch diff file for 2.4(emac_3-2.4-8.diff) and it's
working (very) good but I can't patch the file for
kernel 2.6.11 (emac_3-2.6-9.diff)(on kernel.org).
Some .rej files created by patch.(ie mii.rej). Which
kernel source must I use as base?
Thanks alot
Emre
Send instant messages to your online friends http://uk.messenger.yahoo.com
^ permalink raw reply
* SMC91111 Delay Problem
From: Vijesh VH @ 2005-03-18 8:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I Compiled the SMC91111.c Driver in 2.4.29 Kernel and Booted the
system. I faced a difficulty in delay i.e TX and RX is not properly
working. Any Packet transfer from Chip is not reaching the PHY. But
receives a TX Empty interrupt. Can any one help me.........
--
Thanks and Regards,
Vijesh V H
^ permalink raw reply
* RE: Mounta Vista Linux prompt on serial console
From: srinivas.surabhi @ 2005-03-18 8:17 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
Hi,
We are facing the problem with MVlinux3.1 having kernel 2.4.20 booting
once the PCI is enabled in config kernel.
Even the message " linux banner " which is at the beginning of the
start_kernel function is not seen. Once the multi image( kernel + ram
disk File system) is extracted into RAM. After that it hangs=0D
bootm 0xfef80000 ## Booting image at fef80000 ...
Image Name: MultiImage
Image Type: PowerPC Linux Multi-File Image (gzip compressed)
Data Size: 4647626 Bytes =3D 4.4 MB
Load Address: 00000000
Entry Point: 00000000
Contents:
Image 0: 551181 Bytes =3D 538.3 kB
Image 1: 4096430 Bytes =3D 3.9 MB
Verifying Checksum ... OK
Uncompressing Multi-File Image ... =3D0=3D
OK
Booting Linux
Loading Ramdisk to 07417000, end 077ff1ae ... OK
...Then hangs ....
SO please help me out in finding out the relation of PCI and the
start_kernel. As per my knowledge once the kernel_init is entered then
the pci_init is invoked. But strangely I am seeing with pci enabled,
hang at the very beginning..
Thanks & Rgds
SS
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=0D
Sent: Thursday, February 17, 2005 5:13 PM
To: Srinivas Surabhi (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Mounta Vista Linux prompt on serial console=0D
In message
<EF9B29C78F41FA488927FCBC7750AF0E08DA14@hyd-mdp-msg.wipro.com> you
wrote:
>=0D
> But the problem is that it was stopping at
>=0D
> "No init found. Try passing init=3D option to kernel". Before that
there
> were no errors. Everthing looks fine Mounted VFS root file system was
also
Fine. So you can mount the root filesystem, but it obviously does not
contain all the required files.
> seen. From the net I understood is that the fstab file was the cause.
So
> edited the filesytem parameter for / as /dev/ram earlier it used to
be
> /dev/root.
No. /etc/fstab has absolutley nothing to do with your problem. The
kernel cannot start the init porocess - make sure init is in the
filesystem, plus all required libraries.
> So please tell me whether the given fstab file will suffice? The
filesystem
This is completley unrelated.
> 2. I have one more doubt /sbin/init utility comes with what package?
> Because in /sbin directory although the init binary is present, not
shown
> in the file system heirarchy view. For eg. if I select DHCPD package
then
> able to see dhcpd related binary in the /sbin similarly my question
was
> which package has to be selected to have init included.
Please contact MV support. I have no idea how they package their
distribution, or how their config tools might work. You paid for
their stuff, so ask _them_.
Best regards,
Wolfgang Denk
--=0D
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
-- Isaac Asimov
Confidentiality Notice=0D
The information contained in this electronic message and any attachments to=
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or=
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or=
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
^ permalink raw reply
* Re: building ppc_htab?
From: Kumar Gala @ 2005-03-18 5:12 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list
In-Reply-To: <20050317215852.GJ8345@smtp.west.cox.net>
> > Crap :(
> >
> > > #ifdef CONFIG_PPC32
> > >=A0=A0=A0=A0=A0=A0=A0=A0 {
> > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 extern struct =
file_operations ppc_htab_operations;
> > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 entry =3D =
create_proc_entry("ppc_htab",=20
> S_IRUGO|S_IWUSR,
> > > NULL);
> > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (entry)
> > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0 entry->proc_fops =3D &ppc_htab_operations;
> > >=A0=A0=A0=A0=A0=A0=A0=A0 }
> > > #endif
> > >
> > > Are you suggesting this should live elsewhere?=A0 I'm not that=20
> familiar
> > > with proc code.
> >
> > Yes, it should live in ppc_htab.c.=A0 See the CONFIG_SYSCTL stuff=20
> already
> > in ppc_htab.c for l2crvec.
>
> Der, that's not the same thing!=A0 I still swear there's a way to do =
this
> w/o messing w/ fs/proc/proc_misc.c, but I don't recall a good =
example.
Will, for now I will add a conditional on CONFIG_PPC_STD_MMU. We can=20
move this out once we figure out how to do it outside of=20
fs/proc/proc_misc.c.
- kumar
^ permalink raw reply
* Re: DMA appears broken in 2.6.11 for Mac 7200
From: linuxppcdev @ 2005-03-18 2:55 UTC (permalink / raw)
To: linuxppc-dev
Ben Said:
> On Mon, 2005-03-14 at 03:51 +0000, linuxppcdev@qbjnet.com wrote:
> > Just updated a couple of old Mac 7200 (601) boxen and ran into trouble with
> > the ide driver and a promise PDC20267 card.
> >
> > The very same drives and card work fine on a 9500 but hang on a 7200. If
> > I set the kernel arg ide=nodma I get in the dmesg:
> > ide_setup: ide=nodma : Prevented DMA
> > and the 7200 boots and runs fine.
> >
> > Another suspect, the mace ethernet driver (which also appears to use DMA)
> > doesn't work on the 7200 with 2.6.11 but does with 2.4.28 and it works
> > with 2.6.11 on the 9500.
>
> Interesting. Not sure what's up, though. Those old machines were known
> to have bugs relative to cache coherency... also check wetehr we are
> setting the cache line size properly in PCI devices. You can also try to
> disable use of PCI memory write & invalidate command in all devices.
Did some more testing on this. Built a 2.4.30-pre1 kernel from bk source.
DMA works fine booting 2.4.30
I compared the dmesg and lspci and I see no differences in the cache line
size.
Is it possible that the ppc 601 kernel fixes aren't getting done properly
in 2.6??
Bob
^ permalink raw reply
* Re: [PATCH] ppc32: 0/2 add support for Sky Computers HDPU Compute blade
From: Mark A. Greer @ 2005-03-17 23:56 UTC (permalink / raw)
To: Brian Waite; +Cc: linuxppc-embedded
In-Reply-To: <200503171247.20161.waite@skycomputers.com>
Brian Waite wrote:
>On Thursday 17 March 2005 12:44, Mark A. Greer wrote:
>
>
>>Brian Waite wrote:
>>
>>
>>
>>>+#define HDPU_INTERNAL_SRAM_BASE 0xfbfc0000
>>>+#define HDPU_INTERNAL_SRAM_SIZE 0x00040000
>>>
>>>
>>>
>>>
>>I haven't gone through in detail yet but one thing I did notice was that
>>you don't have the proper SRAM alignment or size. The SRAM on the
>>64[34]60 is 2MB so it must be aligned on a boundary that's a multiple of
>>2MB.
>>
>>
>>
>Mark,
> Argh that is a carry over from a bad experiment in consolidating memory space.
>I don't use the SRAM for anything so it will not break the code so I will provide a patch on top
>of the platform patch to fix this if that works for you.
>
>
Brian,
I stand corrected. Dale Farnsworth pointed out to me that its 2Mb (as
in "bit") not byte. I was reading the manual wrong.
Sorry 'bout that.
Mark
^ permalink raw reply
* Re: looking for a model for building CRAMFS(?)-based system
From: Wolfgang Denk @ 2005-03-17 22:52 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0503171134230.22767@localhost.localdomain>
In message <Pine.LNX.4.61.0503171134230.22767@localhost.localdomain> you wrote:
>
> > See http://www.denx.de/e/news.php#MINI_FO
>
> i'd already read that paper a few months back, but wasn't sure if this
> was actually being used, or was just a concept idea. if it's actually
> in practise, i'll take another look at it.
As mentioned before, it's in use in commercial products. See also
http://www.denx.de/twiki/bin/view/Know/MiniFOHome
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
"Wagner's music is better than it sounds." - Mark Twain
^ permalink raw reply
* Re: building ppc_htab?
From: Tom Rini @ 2005-03-17 21:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <20050317174137.GH8345@smtp.west.cox.net>
On Thu, Mar 17, 2005 at 10:41:37AM -0700, Tom Rini wrote:
> On Thu, Mar 17, 2005 at 11:34:14AM -0600, Kumar Gala wrote:
> >
> > On Mar 16, 2005, at 4:11 PM, Tom Rini wrote:
> >
> > >On Wed, Mar 16, 2005 at 12:57:24AM -0600, Kumar Gala wrote:
> > >
> > >> Is there any reason not to make the following change so we build
> > >> ppc_htab only on PPC STD MMU?? This would also require fixing up
> > >> fs/proc/proc_misc.c.
> > >
> > >I could have sworn, but maybe my memory sucks, that we no longer messed
> > >w/ fs/proc/proc_misc.c for any of the PPC-specific things (since in 2.6
> > > you can do all of that proc magic in your 'driver').? So this patch
> > > would make a great deal of sense to do, and if it lacks what I'm
> > >talking
> > > about, we should do that part as well :)
> >
> > I'm not exactly clear on what you are talking about. There is this
> > snippet in fs/proc/proc_misc.c:
>
> Crap :(
>
> > #ifdef CONFIG_PPC32
> > {
> > extern struct file_operations ppc_htab_operations;
> > entry = create_proc_entry("ppc_htab", S_IRUGO|S_IWUSR,
> > NULL);
> > if (entry)
> > entry->proc_fops = &ppc_htab_operations;
> > }
> > #endif
> >
> > Are you suggesting this should live elsewhere? I'm not that familiar
> > with proc code.
>
> Yes, it should live in ppc_htab.c. See the CONFIG_SYSCTL stuff already
> in ppc_htab.c for l2crvec.
Der, that's not the same thing! I still swear there's a way to do this
w/o messing w/ fs/proc/proc_misc.c, but I don't recall a good example.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH 2.6.12] mtd: Remove MTD map file for Chestnut platform.
From: Josh Boyer @ 2005-03-17 18:24 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linux-mtd, Jörn Engel, dwmw2, Embedded PPC Linux list
In-Reply-To: <4239C51B.70101@mvista.com>
On Thu, 2005-03-17 at 10:57 -0700, Mark A. Greer wrote:
> Jörn Engel wrote:
> >
> >Applied to mtd cvs. It will make its way to Linus eventually...
> >
> >Thanks!
> >
> >
>
> Jörn,
>
> Thanks for looking into this but Andrew has already pushed that through
> from his end. (I had posted an earler patch with the map removal in it
> before I broke it out and sent that part to you and the rest to Andrew
> again.)
>
> Sorry for wasting your time.
Not a waste of time. It's been removed from MTD CVS so it doesn't
magically reappear later (or cause headaches when doing a merge).
Jörn meant that the next time the MTD BK tree is synced with Linus,
it'll show up. If it's already there, then no big deal :).
josh
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Make sleep/wakeup work with USB on powerbooks
From: David Brownell @ 2005-03-17 18:58 UTC (permalink / raw)
To: linux-usb-devel; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <16953.5968.397116.341920@cargo.ozlabs.ibm.com>
On Wednesday 16 March 2005 9:36 pm, Paul Mackerras wrote:
> I am currently using this patch on my powerbook to fix the problems
> that USB was causing with sleep and wakeup. Basically one of the USB
> controllers was getting a spurious wakeup immediately when put it
> into the suspend state. This would cause the resume routine to be run
> after we had turned off the device, causing a machine check.
Do you know yet why the spurious wakeup happened? As I recall from
earlier discussions, that was indeed the root cause of the problem,
although there were a few other oddnesses that needed handling too.
But without the spurious wakeup, they'd have been quite rare.
> Also we had some races where we would turn off the clock to the apple
> OHCI cell(s) and then try to access them. With this patch, sleep and
> wakeup are quite reliable. The patch is against 2.6.11.
Thanks, I'll have a more detailed look soon. Most of it looks fine,
except for the stuff related to this:
> +#ifdef CONFIG_USB_SUSPEND
> /* wake on ConnectStatusChange, matching external hubs */
> ohci_writel (ohci, RH_HS_DRWE, &ohci->regs->roothub.status);
> +#endif
Thing is, that change would also prevent us from getting rid of
the root hub timer for OHCI. IRQ on connect status change is
not specific to USB_SUSPEND.
- Dave
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Make sleep/wakeup work with USB on powerbooks
From: Alan Stern @ 2005-03-17 18:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <16953.5968.397116.341920@cargo.ozlabs.ibm.com>
On Thu, 17 Mar 2005, Paul Mackerras wrote:
> I am currently using this patch on my powerbook to fix the problems
> that USB was causing with sleep and wakeup. Basically one of the USB
> controllers was getting a spurious wakeup immediately when put it
> into the suspend state. This would cause the resume routine to be run
> after we had turned off the device, causing a machine check.
Is this just a hardware glitch or does it go deeper?
> Also we had some races where we would turn off the clock to the apple
> OHCI cell(s) and then try to access them. With this patch, sleep and
> wakeup are quite reliable. The patch is against 2.6.11.
Aside from the ppc-specific portions, the changes you made to hcd-pci.c
resemble those I just posted in
http://lists.osdl.org/pipermail/linux-pm/2005-March/000616.html
(meant for the gregkh-2.6 USB development tree).
Alan Stern
^ permalink raw reply
* Re: [PATCH 2.6.12] mtd: Remove MTD map file for Chestnut platform.
From: Jörn Engel @ 2005-03-17 18:32 UTC (permalink / raw)
To: Josh Boyer; +Cc: dwmw2, linux-mtd, Embedded PPC Linux list
In-Reply-To: <1111083871.7610.3.camel@windu.rchland.ibm.com>
On Thu, 17 March 2005 12:24:31 -0600, Josh Boyer wrote:
>
> Jörn meant that the next time the MTD BK tree is synced with Linus,
> it'll show up. If it's already there, then no big deal :).
Not for me at least. ;)
Bk could automatically detect if the same changeset went in through
different trees. From cvs, it may give dwmw2 a slight headache.
Jörn
--
tglx1 thinks that joern should get a (TM) for "Thinking Is Hard"
-- Thomas Gleixner
^ permalink raw reply
* Re: Problems with MontaVista Linux on a Memec Virtex-II pro ff672 board
From: Peter Ryser @ 2005-03-17 18:04 UTC (permalink / raw)
To: S. van Beek; +Cc: Linuxppc-embedded
In-Reply-To: <001501c52b0a$0ee36ca0$9c9c9182@ddns.htc.nl.philips.com>
Also try to boot the first Linux kernel (the one without the Flash
support) on the EDK design with Flash support. It will help narrow down
the problem to the HW or the SW.
- Peter
S. van Beek wrote:
>>How did you add the Flash (EMC) peripheral? Did you use the Base System
>>Builder to generate your hardware?
>>
>>
>
>Yes, we started a new project using the base system builder with the same
>options as the previous (working) project and flash, so the address range
>should be ok. I'll check tomorrow, right now its time to go home ;)
>
>Regards,
>Sander
>
>----- Original Message -----
>From: "Peter Ryser" <Peter.Ryser@xilinx.com>
>To: "S. van Beek" <nlv11891@prle>
>Cc: <Linuxppc-embedded@ozlabs.org>
>Sent: Thursday 17 March 2005 16:37
>Subject: Re: Problems with MontaVista Linux on a Memec Virtex-II pro ff672
>board
>
>
>
>
>>How did you add the Flash (EMC) peripheral? Did you use the Base System
>>Builder to generate your hardware?
>>
>>If you configure the hardware manually and use the OPB EMC make sure
>>that you add the address range to the PLB2OPB bridge.
>>
>>- Peter
>>
>>
>>S. van Beek wrote:
>>
>>
>>
>>>Hello there,
>>>
>>>This is our first post on this list, hi all!
>>>We're two Dutch students working with a Virtex-II pro ff672 board from
>>>Memec with the Communications 2 module. We've compiled a simple kernel
>>>wich comes with MontaVista Linux 3.1 (2.4.20) with ethernet and a
>>>serial port. It mounts its root filesystem over NFS and everything
>>>seems to work nicely. The next step we wanted to make was
>>>adding support for the Flash on the com board. We added the IP to the
>>>hardware and loaded the new bitstream in the FPGA. Next thing, we
>>>enabled support for MTD devices in the kernel. After that, the kernel
>>>did not seem to boot anymore. It stopped at the message 'Now booting
>>>the kernel'. So we read some documentation about debugging. We
>>>recompiled this kernel with the -g -ggdb options and removed the -O
>>>(optimalization) flag. Then we did not even see the ppc boot loader
>>>messages anymore when trying to boot. So we tried to compile the first
>>>kernel (with only serial and ethernet support) -wich worked fine
>>>before- with debugging and it gave us the same result.. no output at
>>>
>>>
>all.
>
>
>>>Can anyone give us some hints on what we can try more to find out what
>>>is going wrong?
>>>
>>>Regards,
>>>Sander van Beek
>>>Daniel van Os
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Linuxppc-embedded mailing list
>>>Linuxppc-embedded@ozlabs.org
>>>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH 2.6.12] mtd: Remove MTD map file for Chestnut platform.
From: Mark A. Greer @ 2005-03-17 17:57 UTC (permalink / raw)
To: Jörn Engel; +Cc: linux-mtd, dwmw2, Embedded PPC Linux list
In-Reply-To: <20050317163526.GB10864@wohnheim.fh-wedel.de>
Jörn Engel wrote:
>On Fri, 11 March 2005 17:40:55 -0700, Mark A. Greer wrote:
>
>
>>Remove Chestnut mtd map file.
>>
>>The chestnut now sets up its MTD map from its platform-specific file so
>>the map file drivers/mtd/maps/chestnut.c is no longer needed. This
>>patch removes the file & the Kconfig/Makefile hooks.
>>
>>Please apply.
>>
>>
>
>Applied to mtd cvs. It will make its way to Linus eventually...
>
>Thanks!
>
>
Jörn,
Thanks for looking into this but Andrew has already pushed that through
from his end. (I had posted an earler patch with the map removal in it
before I broke it out and sent that part to you and the rest to Andrew
again.)
Sorry for wasting your time.
Mark
^ permalink raw reply
* Re: [PATCH] ppc32: 0/2 add support for Sky Computers HDPU Compute blade
From: Brian Waite @ 2005-03-17 17:47 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4239C1FD.7060308@mvista.com>
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
On Thursday 17 March 2005 12:44, Mark A. Greer wrote:
> Brian Waite wrote:
>
> >+#define HDPU_INTERNAL_SRAM_BASE 0xfbfc0000
> >+#define HDPU_INTERNAL_SRAM_SIZE 0x00040000
> >
> >
> I haven't gone through in detail yet but one thing I did notice was that
> you don't have the proper SRAM alignment or size. The SRAM on the
> 64[34]60 is 2MB so it must be aligned on a boundary that's a multiple of
> 2MB.
>
Mark,
Argh that is a carry over from a bad experiment in consolidating memory space.
I don't use the SRAM for anything so it will not break the code so I will provide a patch on top
of the platform patch to fix this if that works for you.
Thanks
Brian
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ppc32: 0/2 add support for Sky Computers HDPU Compute blade
From: Mark A. Greer @ 2005-03-17 17:44 UTC (permalink / raw)
To: Brian Waite; +Cc: Andrew Morton, linuxppc-embedded
In-Reply-To: <200503170953.02626.waite@skycomputers.com>
Brian Waite wrote:
>+#define HDPU_INTERNAL_SRAM_BASE 0xfbfc0000
>+#define HDPU_INTERNAL_SRAM_SIZE 0x00040000
>
>
I haven't gone through in detail yet but one thing I did notice was that
you don't have the proper SRAM alignment or size. The SRAM on the
64[34]60 is 2MB so it must be aligned on a boundary that's a multiple of
2MB.
Mark
^ permalink raw reply
* Re: building ppc_htab?
From: Tom Rini @ 2005-03-17 17:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
In-Reply-To: <a74c02a8aa54e529b296eeac31bdec4e@freescale.com>
On Thu, Mar 17, 2005 at 11:34:14AM -0600, Kumar Gala wrote:
>
> On Mar 16, 2005, at 4:11 PM, Tom Rini wrote:
>
> >On Wed, Mar 16, 2005 at 12:57:24AM -0600, Kumar Gala wrote:
> >
> >> Is there any reason not to make the following change so we build
> >> ppc_htab only on PPC STD MMU?? This would also require fixing up
> >> fs/proc/proc_misc.c.
> >
> >I could have sworn, but maybe my memory sucks, that we no longer messed
> >w/ fs/proc/proc_misc.c for any of the PPC-specific things (since in 2.6
> > you can do all of that proc magic in your 'driver').? So this patch
> > would make a great deal of sense to do, and if it lacks what I'm
> >talking
> > about, we should do that part as well :)
>
> I'm not exactly clear on what you are talking about. There is this
> snippet in fs/proc/proc_misc.c:
Crap :(
> #ifdef CONFIG_PPC32
> {
> extern struct file_operations ppc_htab_operations;
> entry = create_proc_entry("ppc_htab", S_IRUGO|S_IWUSR,
> NULL);
> if (entry)
> entry->proc_fops = &ppc_htab_operations;
> }
> #endif
>
> Are you suggesting this should live elsewhere? I'm not that familiar
> with proc code.
Yes, it should live in ppc_htab.c. See the CONFIG_SYSCTL stuff already
in ppc_htab.c for l2crvec.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: building ppc_htab?
From: Kumar Gala @ 2005-03-17 17:34 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list
In-Reply-To: <20050316221152.GZ8345@smtp.west.cox.net>
On Mar 16, 2005, at 4:11 PM, Tom Rini wrote:
> On Wed, Mar 16, 2005 at 12:57:24AM -0600, Kumar Gala wrote:
>
> > Is there any reason not to make the following change so we build
> > ppc_htab only on PPC STD MMU?=A0 This would also require fixing up
> > fs/proc/proc_misc.c.
>
> I could have sworn, but maybe my memory sucks, that we no longer =
messed
> w/ fs/proc/proc_misc.c for any of the PPC-specific things (since in =
2.6
> you can do all of that proc magic in your 'driver').=A0 So this patch
> would make a great deal of sense to do, and if it lacks what I'm=20
> talking
> about, we should do that part as well :)
I'm not exactly clear on what you are talking about. There is this=20
snippet in fs/proc/proc_misc.c:
#ifdef CONFIG_PPC32
{
extern struct file_operations ppc_htab_operations;
entry =3D create_proc_entry("ppc_htab", =
S_IRUGO|S_IWUSR,=20
NULL);
if (entry)
entry->proc_fops =3D &ppc_htab_operations;
}
#endif
Are you suggesting this should live elsewhere? I'm not that familiar=20
with proc code.
- kumar
^ permalink raw reply
* Re: Problems with MontaVista Linux on a Memec Virtex-II pro ff672 board
From: Mark A. Greer @ 2005-03-17 17:14 UTC (permalink / raw)
To: S. van Beek; +Cc: Linuxppc-embedded
In-Reply-To: <002001c52aef$d29dbb70$9c9c9182@ddns.htc.nl.philips.com>
S. van Beek wrote:
> Hello there,
>
> This is our first post on this list, hi all!
> We're two Dutch students working with a Virtex-II pro ff672 board from
> Memec with the Communications 2 module. We've compiled a simple kernel
> wich comes with MontaVista Linux 3.1 (2.4.20) with ethernet and a
> serial port. It mounts its root filesystem over NFS and everything
> seems to work nicely. The next step we wanted to make was
> adding support for the Flash on the com board. We added the IP to the
> hardware and loaded the new bitstream in the FPGA. Next thing, we
> enabled support for MTD devices in the kernel. After that, the kernel
> did not seem to boot anymore. It stopped at the message 'Now booting
> the kernel'. So we read some documentation about debugging. We
> recompiled this kernel with the -g -ggdb options and removed the -O
> (optimalization) flag. Then we did not even see the ppc boot loader
> messages anymore when trying to boot. So we tried to compile the first
> kernel (with only serial and ethernet support) -wich worked fine
> before- with debugging and it gave us the same result.. no output at all.
> Can anyone give us some hints on what we can try more to find out what
> is going wrong?
There are lots of possible problems that may be causing this but my
guess is that you are accessing some piece of hardware that you don't
have ioremap'd/io_block_mapping'd. IOW, you don't have a virt->phys
translation set up for the hardware register you're trying to access.
If you can find a COPS/JTAG debugger and your board has a connector, set
it up and run your kernel again. When it hangs stop the processor and
dump the 'log_buf' that's in memory (you can get the address from your
System.map file). That's where printk msgs are logged before the
console is set up. In there you will likely see a panic msg and a
register dump. That should point you to where things went wrong.
If you don't have access to a debugger like that, you could try running
KGDB. If the kernel is running long enough to reach the initial
breakpoint and you have correctly configured your code so that KGDB will
work, that can be big help too.
Mark
^ permalink raw reply
* Re: looking for a model for building CRAMFS(?)-based system
From: Robert P. J. Day @ 2005-03-17 16:35 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20050317163223.6C37EC1510@atlas.denx.de>
On Thu, 17 Mar 2005, Wolfgang Denk wrote:
> Dear Robert,
>
> in message <Pine.LNX.4.61.0503171011220.20335@localhost.localdomain> you wrote:
> >
> > now this is the sticky part. imagine this system out in the field,
> > where you need to make an update to something in the initrd in the
> > root filesystem.
>
> This is the szenario where an overly filesystem enters the stage.
>
> See http://www.denx.de/e/news.php#MINI_FO
i'd already read that paper a few months back, but wasn't sure if this
was actually being used, or was just a concept idea. if it's actually
in practise, i'll take another look at it.
rday
^ permalink raw reply
* Re: [PATCH 2.6.12] mtd: Remove MTD map file for Chestnut platform.
From: Jörn Engel @ 2005-03-17 16:35 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linux-mtd, dwmw2, Embedded PPC Linux list
In-Reply-To: <42323A97.5070105@mvista.com>
On Fri, 11 March 2005 17:40:55 -0700, Mark A. Greer wrote:
>
> Remove Chestnut mtd map file.
>
> The chestnut now sets up its MTD map from its platform-specific file so
> the map file drivers/mtd/maps/chestnut.c is no longer needed. This
> patch removes the file & the Kconfig/Makefile hooks.
>
> Please apply.
Applied to mtd cvs. It will make its way to Linus eventually...
Thanks!
Jörn
--
Sometimes, asking the right question is already the answer.
-- Unknown
^ 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