* Re: mv643xx_eth SA_SHIRQ support patch
From: Sven Luther @ 2005-03-08 6:49 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: Nicolas DET, linuxppc-dev
In-Reply-To: <20050307225401.GA31041@xyzzy>
On Mon, Mar 07, 2005 at 03:54:01PM -0700, Dale Farnsworth wrote:
> On Mon, Mar 07, 2005 at 12:57:39PM +0000, Nicolas DET wrote:
> > Hello James,
> > > - why do you need to use SA_SHIRQ in the ethernet driver?
> >
> > Because the IRQ we use for ethernet is shared with others devices.
>
> I've included an untested patch below that adds support for passing
> IRQ flags via platform device.
Notice that benh is telling me that you should use SA_SHIRQ always and that
SA_INTERRUPT should go away, and that you should contact him online if you
have trouble with that.
> For the pegasos 2, you'll need the second patch which applies after
> the one I previously sent for chrp_setup.c.
Ok, will test this anyway, and tell you how it works.
> Sven + Nicolas, please let me know if this compiles/works for you.
Yep.
Friendly,
Sven Luther
^ permalink raw reply
* MPC82xx and linux-2.6.
From: leo @ 2005-03-08 2:57 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
Anyone who has experience in booting linux-2.6 on Motorola ADS8260 platform?
BRs!
^ permalink raw reply
* Re: find the new link of " http://lists.linuxppc.org"
From: Kumar Gala @ 2005-03-08 2:01 UTC (permalink / raw)
To: Xie Haichun; +Cc: inuxppc-embedded
In-Reply-To: <422D048E.6000608@centecnetworks.com>
Are you looking for:
http://ozlabs.org/pipermail/linuxppc-embedded/
http://ozlabs.org/pipermail/linuxppc-dev/
- kumar
On Mar 7, 2005, at 7:49 PM, Xie Haichun wrote:
> Hi all:
>
>
>
> =A0=A0 who can tell me the new link of http://lists.linuxppc.org
> <http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/=20
> msg00045.html>
> I can't acces the website.
>
>
>
> =A0=A0 thansk very much
>
> anchor xie
> 8 mar. 2005
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* find the new link of " http://lists.linuxppc.org"
From: Xie Haichun @ 2005-03-08 1:49 UTC (permalink / raw)
To: inuxppc-embedded
In-Reply-To: <20050308012941.8430A67A67@ozlabs.org>
Hi all:
who can tell me the new link of http://lists.linuxppc.org
<http://lists.linuxppc.org/listarcs/linuxppc-embedded/199912/msg00045.html>
I can't acces the website.
thansk very much
anchor xie
8 mar. 2005
^ permalink raw reply
* Re: MPC82XX and SATA hardisk performance.
From: Kumar Gala @ 2005-03-08 1:46 UTC (permalink / raw)
To: leo; +Cc: linuxppc-embedded
In-Reply-To: <20050308012941.8430A67A67@ozlabs.org>
Have you tried bonnie++ (http://www.coker.com.au/bonnie++/)
- kumar
On Mar 7, 2005, at 7:22 PM, leo wrote:
> Hi all,
> =A0=A0=A0=A0=A0=A0=A0 I use the PCI bus and PCI-SATA bridge SII3112 =
to expand two=20
> SATA port, my MPC8250 work frequency is CORE/CPM/BUS 200/133/66M,=20
> filesystem use ext2 under linux, i write a program to test the maxmium=20=
> written speed, the result is about 60MBps/S, maybe it's too slow?=A0=20=
> Anyone who has experience can give me some advice? How can I increase=20=
> the written speed?
>
> Best Regards!
>
> Leo.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* MPC82XX and SATA hardisk performance.
From: leo @ 2005-03-08 1:22 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I use the PCI bus and PCI-SATA bridge SII3112 to expand two SATA port, my MPC8250 work frequency is CORE/CPM/BUS 200/133/66M, filesystem use ext2 under linux, i write a program to test the maxmium written speed, the result is about 60MBps/S, maybe it's too slow? Anyone who has experience can give me some advice? How can I increase the written speed?
Best Regards!
Leo.
^ permalink raw reply
* mv643xx_eth SA_SHIRQ support patch
From: Dale Farnsworth @ 2005-03-07 22:54 UTC (permalink / raw)
To: Nicolas DET, linuxppc-dev
In-Reply-To: <20050307125808.6585A200008A@mwinf0308.wanadoo.fr>
On Mon, Mar 07, 2005 at 12:57:39PM +0000, Nicolas DET wrote:
> Hello James,
> > - why do you need to use SA_SHIRQ in the ethernet driver?
>
> Because the IRQ we use for ethernet is shared with others devices.
I've included an untested patch below that adds support for passing
IRQ flags via platform device.
For the pegasos 2, you'll need the second patch which applies after
the one I previously sent for chrp_setup.c.
Sven + Nicolas, please let me know if this compiles/works for you.
Thanks,
-Dale
------------------------- Begin IRQ_flags Patch --------------------------
mv643xx: support passing ethernet IRQ flags via platform device
This patch adds a field to struct mv643xx_eth_platform_data for
passing the IRQ flags value that is passed to request_irq.
Default value is (SA_INTERRUPT | SA_SAMPLE_RANDOM).
Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
Index: linux-2.5-enet/drivers/net/mv643xx_eth.h
===================================================================
--- linux-2.5-enet.orig/drivers/net/mv643xx_eth.h
+++ linux-2.5-enet/drivers/net/mv643xx_eth.h
@@ -328,6 +328,7 @@
u32 port_config_extend; /* User port config extend value*/
u32 port_sdma_config; /* User port SDMA config value */
u32 port_serial_control; /* User port serial control value */
+ u32 irq_flags; /* Flags for request_irq */
u32 port_tx_queue_command; /* Port active Tx queues summary*/
u32 port_rx_queue_command; /* Port active Rx queues summary*/
Index: linux-2.5-enet/include/linux/mv643xx.h
===================================================================
--- linux-2.5-enet.orig/include/linux/mv643xx.h
+++ linux-2.5-enet/include/linux/mv643xx.h
@@ -1302,6 +1302,7 @@
u32 port_config_extend;
u32 port_sdma_config;
u32 port_serial_control;
+ u32 irq_flags;
u32 tx_queue_size;
u32 rx_queue_size;
u32 tx_sram_addr;
Index: linux-2.5-enet/drivers/net/mv643xx_eth.c
===================================================================
--- linux-2.5-enet.orig/drivers/net/mv643xx_eth.c
+++ linux-2.5-enet/drivers/net/mv643xx_eth.c
@@ -667,8 +667,8 @@
spin_lock_irq(&mp->lock);
- err = request_irq(dev->irq, mv643xx_eth_int_handler,
- SA_INTERRUPT | SA_SAMPLE_RANDOM, dev->name, dev);
+ err = request_irq(dev->irq, mv643xx_eth_int_handler, mp->irq_flags,
+ dev->name, dev);
if (err) {
printk(KERN_ERR "Can not assign IRQ number to MV643XX_eth%d\n",
@@ -1427,6 +1427,7 @@
mp->port_config_extend = MV643XX_ETH_PORT_CONFIG_EXTEND_DEFAULT_VALUE;
mp->port_sdma_config = MV643XX_ETH_PORT_SDMA_CONFIG_DEFAULT_VALUE;
mp->port_serial_control = MV643XX_ETH_PORT_SERIAL_CONTROL_DEFAULT_VALUE;
+ mp->irq_flags = SA_INTERRUPT | SA_SAMPLE_RANDOM;
mp->rx_ring_size = MV643XX_ETH_PORT_DEFAULT_RECEIVE_QUEUE_SIZE;
mp->tx_ring_size = MV643XX_ETH_PORT_DEFAULT_TRANSMIT_QUEUE_SIZE;
@@ -1450,6 +1451,9 @@
if (pd->port_serial_control || pd->force_port_serial_control)
mp->port_serial_control = pd->port_serial_control;
+ if (pd->irq_flags)
+ mp->irq_flags = pd->irq_flags;
+
if (pd->rx_queue_size)
mp->rx_ring_size = pd->rx_queue_size;
------------------------- End IRQ_flags Patch --------------------------
------------------------- Begin chrp_setup Patch --------------------------
Index: linux-2.5-enet/arch/ppc/platforms/chrp_setup.c
===================================================================
--- linux-2.5-enet.orig/arch/ppc/platforms/chrp_setup.c
+++ linux-2.5-enet/arch/ppc/platforms/chrp_setup.c
@@ -246,7 +246,9 @@
},
};
-static struct mv643xx_eth_platform_data eth0_pd;
+static struct mv643xx_eth_platform_data eth0_pd = {
+ .irq_flags = SA_SHIRQ | SA_SAMPLE_RANDOM;
+};
static struct platform_device eth0_device = {
.name = MV643XX_ETH_NAME,
@@ -267,7 +269,9 @@
},
};
-static struct mv643xx_eth_platform_data eth1_pd;
+static struct mv643xx_eth_platform_data eth1_pd = {
+ .irq_flags = SA_SHIRQ | SA_SAMPLE_RANDOM;
+};
static struct platform_device eth1_device = {
.name = MV643XX_ETH_NAME,
------------------------- End chrp_setup Patch --------------------------
^ permalink raw reply
* Re: Read TCN-register in user space
From: Kumar Gala @ 2005-03-07 21:41 UTC (permalink / raw)
To: Björn Östby; +Cc: linuxppc-embedded
In-Reply-To: <004B1D7A5257174C9044A1B7BD0E60ED0178CBF5@ratatosk.combitechsystems.com>
There is a proper way to do this and hackish way. The proper way is to=20=
eventually provide some interface via the work BenH has been doing with=20=
vDSO (while out). The hackish way is to export it via some /proc or=20
sysfs attribute. The hackish way will not make its way into a mainline=20=
tree.
- kumar
On Mar 7, 2005, at 5:02 AM, Bj=F6rn =D6stby wrote:
> I'm currently using ELDK 3.0 (kernel 2.4.25) and a mpc823e trying to=20=
> do some latency measurements for my final thesis project.
>
> I'm wondering if there is any possibility to read the Timer Counter=20
> Register (TCN1) in user space. I have initially used gettimeofday(),=20=
> which provides sufficient resolution (usec), but I suppose that=20
> solution probably adds on some kind of unknown context-switch latency.=20=
> Does anyone have a clue on how to access this in user space? Could=20
> inline assembler or perhaps mmap() do the trick (I'm using C as=20
> programming language)?.
>
>
>
> Regards,
> Bjorn
>
>
>
> <ATT07173.txt>=
^ permalink raw reply
* Re: gcc-3.3.3 from YDL4 problems?
From: Kumar Gala @ 2005-03-07 21:39 UTC (permalink / raw)
To: Clemens Koller; +Cc: ppcembed Mailing List
In-Reply-To: <422C30CF.5010906@anagramm.de>
Thanks,
The problem I'm having is that it builds fine, when running it fails.
- kumar
On Mar 7, 2005, at 4:45 AM, Clemens Koller wrote:
> Hello, Kumar!
>
> > Has anyone else had any issues with building kernels (2.6.11) with
> > gcc-3.3.3 from YDL4.=A0 Ran into a problem today were a 2.6.11 build=20=
> for
> > MPC8540 ADS breaks with gcc-3.3.3 but works ok with a 3.4.3.
>
> You know that I build the mpc8540_ads also.
> I use the Denx ELDK 3.1 with gcc 3.3.3 and it breaks due to an =
unknown
> rfci instruction:
>
> $ make
> =A0=A0 CHK=A0=A0=A0=A0 include/linux/version.h
> =A0=A0 CC=A0=A0=A0=A0=A0 scripts/mod/empty.o
> =A0=A0 MKELF=A0=A0 scripts/mod/elfconfig.h
> =A0=A0 HOSTCC=A0 scripts/mod/file2alias.o
> =A0=A0 HOSTCC=A0 scripts/mod/modpost.o
> =A0=A0 HOSTCC=A0 scripts/mod/sumversion.o
> =A0=A0 HOSTLD=A0 scripts/mod/modpost
> =A0=A0 CC=A0=A0=A0=A0=A0 arch/ppc/kernel/asm-offsets.s
> =A0=A0 CHK=A0=A0=A0=A0 include/asm-ppc/offsets.h
> =A0=A0 CC=A0=A0=A0=A0=A0 init/main.o
> =A0=A0 CHK=A0=A0=A0=A0 include/linux/compile.h
> =A0=A0 UPD=A0=A0=A0=A0 include/linux/compile.h
> =A0=A0 CC=A0=A0=A0=A0=A0 init/version.o
> =A0=A0 CC=A0=A0=A0=A0=A0 init/do_mounts.o
> =A0=A0 CC=A0=A0=A0=A0=A0 init/do_mounts_devfs.o
> =A0=A0 CC=A0=A0=A0=A0=A0 init/do_mounts_rd.o
> =A0=A0 CC=A0=A0=A0=A0=A0 init/do_mounts_initrd.o
> =A0=A0 LD=A0=A0=A0=A0=A0 init/mounts.o
> =A0=A0 CC=A0=A0=A0=A0=A0 init/initramfs.o
> =A0=A0 CC=A0=A0=A0=A0=A0 init/calibrate.o
> =A0=A0 LD=A0=A0=A0=A0=A0 init/built-in.o
> =A0=A0 CHK=A0=A0=A0=A0 usr/initramfs_list
> =A0=A0 AS=A0=A0=A0=A0=A0 usr/initramfs_data.o
> =A0=A0 LD=A0=A0=A0=A0=A0 usr/built-in.o
> =A0=A0 AS=A0=A0=A0=A0=A0 arch/ppc/kernel/entry.o
> arch/ppc/kernel/entry.S: Assembler messages:
> arch/ppc/kernel/entry.S:800: Error: Unrecognized opcode: `rfci'
> make[1]: *** [arch/ppc/kernel/entry.o] Error 1
> make: *** [arch/ppc/kernel] Error 2
>
> But if I use your powerpc-linux-gnuspe-* (cross-)toolchain it
> builds fine. Maybe some compile options for 3.3.3 might be sufficient
> to fix that... my way is to use 3.4.3.
>
> 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: MV64360 MPSC - console problem
From: Mark A. Greer @ 2005-03-07 20:46 UTC (permalink / raw)
To: Hegde Ashok-aah024; +Cc: linuxppc-embedded
In-Reply-To: <772BCEF88A1DD91191F80011856715F301C2B56C@zin24exm01.ap.mot.com>
Hegde Ashok-aah024 wrote:
> I took this mpsc driver from "bk://source.mvista.com/linux-2.5-marvell" as
>mentioned in ppc mailinglist.
>
>
Also, this tree has long since been dead. In fact, its been deleted.
You should be using the official kernel.org source base.
Mark
^ permalink raw reply
* Re: MV64360 MPSC - console problem
From: Mark A. Greer @ 2005-03-07 18:27 UTC (permalink / raw)
To: Hegde Ashok-aah024; +Cc: linuxppc-embedded
In-Reply-To: <772BCEF88A1DD91191F80011856715F301C2B56C@zin24exm01.ap.mot.com>
Hi Ashok.
Hegde Ashok-aah024 wrote:
>Hi All,
>
> I am trying to bring up linux-2.6.10 on ppc based system with
>MV64360(marvell controller).
>I am unable to use mpsc as the console, serial text debug messages are
>coming fine i.e. ppc_md.progress able to print properly on the serial port.
>I observed that when console_init() is being called from init/main.c none
>of our "mpsc" init functions are called.
>Also I see that there is no call to "console_initcall" in mpsc driver.
>According to my understanding this call is required in serial drivers used
>as consoles.
> I took this mpsc driver from "bk://source.mvista.com/linux-2.5-marvell" as
>mentioned in ppc mailinglist.
> Hardware has been tested with linux-2.4.20 flavour and it is absolutely
>fine.
>
>Appreciate any help.
>
>
It almost sounds like you don't have the mpsc config option selected.
Make sure that "Marvell MPSC serial port support" and "Support for
consol on Marvell MPSC serial port" under "Device Drivers"/"Character
devices"/"Serial drivers" are selected. If they don't appear then you
don't have CONFIG_PPC and/or CONFIG_MV64X60 defined. Those two should
be defined in arch/ppc/Kconfig under the appropriate board selection.
You also have to have the platform_data that is passed into the MPSC
driver set up correctly for it to work correctly.
Mark
^ permalink raw reply
* Re: Adding machine types to the kernel tree...
From: Kumar Gala @ 2005-03-07 17:38 UTC (permalink / raw)
To: Jakob Viketoft; +Cc: Linux PPC Embedded list
In-Reply-To: <422C27FE.6000709@bitsim.se>
On Mar 7, 2005, at 4:07 AM, Jakob Viketoft wrote:
> Thanks for the comments!
>
> Andrew May wrote:
> > I think a huge first step would be to banish xparameters.h from all
> the
> > kernel code.
> > Our HW guys just seem to do the strangest things without checking.
> > So I have 2 spins of a board with 2 Virtex-II pro's each.
> > The 2 spins have a small refrence clock change and the 2 CPU's have
> > different IRQ mappings.
>
> I understand that there is numerous resentment against having this file
> in the kernel and I've been thinking of a solution without it. One such
> path would be serving the kernel with a OCP list of the devices used,
> but I'm unsure about the current status of OCP. Is this The Right Way
> to
> do it, or are OCP likely to be abandoned further along the 2.6 road?
If you are talking about 2.6, dont use OCP. Use the driver model and
platform devices. You can take a look at the arch/ppc/syslib/ppc_sys.c
and arch/ppc/platforms/85xx for examples.
- kumar
^ permalink raw reply
* Re: mv64x60 updates
From: Mark A. Greer @ 2005-03-07 17:24 UTC (permalink / raw)
To: Sven Luther; +Cc: Nicolas DET, linuxppc-embedded, linuxppc-dev
In-Reply-To: <20050307132003.GA21030@pegasos>
Sven Luther wrote:
>I have appended a (slightly revised) version of the patch, which is against a
>saturday/sunday checkout of bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet,
>which is what Mark and Dale are working on. Viewed like that the patch is
>against to really manageable size, altough it may need some fine-tuning. The
>rest of your comments probably apply to Dale's and Mark's work in the above
>tree though.
>
>
Hi guys. I got in late today so I'm just reading this thread now.
I basically want to reiterate and expand on what Brian
<linwoes@gmail.com> stated.
The arch/ppc/syslib/mv64x60* code is really for embedded systems only.
More accurately, its for systems whose firmwares don't do a good job of
configuring the bridge or if you want to significantly change that
configuration. This ends up including many embedded systems but
basically no "desktop"-like systems (e.g., ones with openfirmware) so
that's why this thread should stay on linuxppc-embedded only.
Sven, et. al., your system has openfirmware and apparenly does a very
good job of configuring the bridge so just ignore the mv64x60 stuff.
You can use the platform_data code from there as an example of what
needs to be passed into the enet driver (and mpsc & i2c & wdt, if you
use them (and find all the patches :)).
If I missed something or you have any more questions, I'l be happy to help.
Mark
^ permalink raw reply
* Re: Linux 2.6 port for M8260 PPC
From: Vijay Padiyar @ 2005-03-07 14:49 UTC (permalink / raw)
To: Ramsay, Jim, LinuxPPC Support
In-Reply-To: <797470E884C6D611B7A500B0D0AA56D0025960D9@batistuta.spider.com>
Hi there
Ya I found that the code related to the MDIO implementation (CONFIG_MDIO)
hasn't been completely ported yet for the 2.6 kernel. Therefore, disabling
the option CONFIG_MDIO in menuconfig should solve the problem.
In case you wish to retain the option, you can copy the appropriate header
files from the 2.4 kernel source into the 2.6 tree. I think the relevant
file is kernel/context.c. Also, in another file, they're referring to a
structure tq_struct, which is defined in linux/tqueue.h. You can copy this
file to your 2.6 source tree as well.
However, this is not recommended, since we're mixing code from two separate
kernels. The tqueue.h header file is related to task queues, which have been
replaced in 2.6 with work queues. It's just that the file calling tq_struct
hasn't been ported yet, apparently. Therefore, it's best to omit the
erroneous code by not selecting the appropriate option in menuconfig. In
this case, all you need to do is disable CONFIG_MDIO.
Regards
Vijay Padiyar
http://www.vijaypadiyar.eu.tf
----- Original Message -----
From: "Ramsay, Jim" <jimr@artesyncp.com>
To: <vijay_padiyar@hotmail.com>
Sent: Monday, March 07, 2005 7:56 PM
Subject: Linux 2.6 port for M8260 PPC
> Hi,
>
> I found this using google, going through EXACTLY the same problems trying
to
> port some 2.4 code we have to 2.6.
>
> Did you find out how to get around these problems?
>
> Thanks,
>
> Jim
>
>
>
> Hi all I wish to discuss some strange issues that I faced with respect to
> the Linux 2.6.8 kernel (downloaded from kernel.org). Firstly, I wish to
know
> whether this has been known to work on an MPC8260 PowerPC target.
Secondly,
> when I tried to compile the Linux kernel with my toolchain (built with Dan
> Kegel's crosstool for the PowerPC 603e core, which is what my processor
> has), I got some errors which I found to rather queer after investigation.
> Firstly, let me state the errors that I got:
> ------------------------------------------------------ LD init/built-in.o
LD
> .tmp_vmlinux1 arch/ppc/8260_io/built-in.o(.text+0x103c): In function
> `mii_queue_relink': arch/ppc/8260_io/fcc_enet.c:1254: undefined reference
to
> `schedule_task' arch/ppc/8260_io/built-in.o(.text+0x1074): In function
> `mii_queue_config': arch/ppc/8260_io/fcc_enet.c:1263: undefined reference
to
> `schedule_task' ------------------------------------------------------ On
> further investigation, I find that 'schedule_task()' is simply not defined
> anywhere in the 2.6.8 kernel sources. This is quite wierd! However, it is
> defined in a file 'context.c' (linux-src/kernel) in the 2.4.27 kernel
> sources, which we were using earlier. How is it that a function is being
> called but its definition has been removed from the sources? Another such
> example is with the structure 'tq_struct'. It is referred to in the file
> 'fcc_enet.c' (linux-src/arch/ppc/8260_io) but it's not defined anywhere!
> Again, after checking in the 2.4.27 sources, I find that it's defined in
the
> file 'tqueue.h' (linux-src/include/linux)! A third thing is that the
2.4.27
> kernel source file 'uart.c' (linux-src/arch/ppc/cpm2_io) is not present in
> the corresponding folder in the 2.6.8 source (linux-src/arch/ppc/8260_io).
> There is one 'uart.c' in the folder '8xx_io', but it doesn't get compiled
> during the kernel build process. Will my UART work correctly with this
> build? Can someone please tell me if there's some explanation for this
that
> I'm unaware of? Which would be the proper forum to report this? Again I
> would like to ask: Has the 2.6.8 kernel been tested successfully on the
> MPC8260 PowerPC platform? Regards Vijay Padiyar
>
>
>
>
>
^ permalink raw reply
* Re: mv64x60 updates
From: Linwoes @ 2005-03-07 13:23 UTC (permalink / raw)
To: linuxppc-dev, Nicolas DET, James Chapman
In-Reply-To: <20050307125808.6585A200008A@mwinf0308.wanadoo.fr>
>
> About arch/ppc/syslibs/ mv64x60 code. Well, it's a bit evil as it has
> hardcoded IRQ, hardcoded register base, it changes
> chipset configuration... whereas all of these is already done by the
> Pegasos II OpenFirmWare.
>
All of the hardcoded IRQs are not really hardcoded. They are easily
overridable in you platform file using a fixup routine as seen in katana.c
flags can be added also.
As far as the register base being hardcoded, I don't see it. The config
options:
CONFIG_MV64X60_BASE=0xf1000000
CONFIG_MV64X60_NEW_BASE=0xf1000000
will allow you register base to be anywhere you would like it.
If you don't need to reinitialize the chip, then don't call mv64x60_init().
The only part of mv64x60_init() I see that is not chip related is the
pci_alloc_hoses(). I guess you could make a new function for that part and
maybe others you need so the code does not get duplicated in your platform
files.
Again, mv64x60_early_init() does very little non-chipset stuff and you could
probably just place the:
mv64x60_bridge_pbase = bh->p_base;
mv64x60_bridge_vbase = bh->v_base;
initializers into your platform files.
Thanks
Brian
^ permalink raw reply
* Re: mv64x60 updates
From: Sven Luther @ 2005-03-07 13:20 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <20050307125808.6585A200008A@mwinf0308.wanadoo.fr>
[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]
On Mon, Mar 07, 2005 at 01:57:39PM +0100, Nicolas DET wrote:
> Hello James,
>
> On 07/03/2005, you wrote:
> > Hi Nicolas,
>
> > A few general comments:-
>
> > - mv64x60 stuff is best posted to linuxppc-embedded
>
> ok.
> I would just add that our platform (Pegasos II) is using MV64361 from
> Marvell and is a complete computer.
Cross-posting to linuxppc-embedded to reach everyone. In particular comments
from Mark and Dale are welcome.
> > - you change several generic files to support your platform. It should
> > be possible to support new mv64x60 platforms by writing a new
> > xxx_setup.c file in arch/ppc/platforms with no other generic changes.
> > It is a goal that all mv64x60 boards can be supported by the generic
> > code in arch/ppc/syslib. If some changes need to be made outside
> > arch/ppc/platforms to support your board, try to make them generic so
> > that other similar boards would be able to use them. I suggest you
> > clone chrp_setup.c or katana.c rather than adding conditionals in
> > chrp_setup.c for your board. Then use code in your board specific
> > setup file to call arch/ppc/syslib mv64x60 routines as appropriate.
>
> There is almost no changes compare to 2.6.11 (from kernel.org).
I have appended a (slightly revised) version of the patch, which is against a
saturday/sunday checkout of bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet,
which is what Mark and Dale are working on. Viewed like that the patch is
against to really manageable size, altough it may need some fine-tuning. The
rest of your comments probably apply to Dale's and Mark's work in the above
tree though.
Friendly,
Sven Luther
[-- Attachment #2: nico2.diff --]
[-- Type: text/plain, Size: 9389 bytes --]
--- linux-2.5-mv643xx-enet/arch/ppc/boot/simple/Makefile 2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/boot/simple/Makefile 2005-03-07 14:13:14.000000000 +0100
@@ -162,7 +162,7 @@
boot-$(CONFIG_8260) += embed_config.o
boot-$(CONFIG_BSEIP) += iic.o
boot-$(CONFIG_MBX) += iic.o pci.o qspan_pci.o
-boot-$(CONFIG_MV64X60) += misc-mv64x60.o
+boot-$(CONFIG_MV64X60) += misc-mv64x60.o mv64x60_stub.o
boot-$(CONFIG_RPXCLASSIC) += iic.o pci.o qspan_pci.o
boot-$(CONFIG_RPXLITE) += iic.o
# Different boards need different serial implementations.
--- linux-2.5-mv643xx-enet/arch/ppc/platforms/chrp_setup.c 2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/platforms/chrp_setup.c 2005-03-07 14:13:14.000000000 +0100
@@ -217,8 +217,13 @@
}
}
+#ifdef CONFIG_MV64X60
+#include <linux/mv643xx.h>
+#include <asm/mv64x60.h>
+#endif
+
-static void __init pegasos_set_l2cr(void)
+static void __init pegasos_stuff(void)
{
struct device_node *np;
@@ -242,6 +247,19 @@
_set_L2CR((*l2cr) | 0x80000000);
}
}
+
+#ifdef CONFIG_MV64X60
+ // Pegasos II (MV64361)
+ // We have to call mv64x60_init() in arch/ppc/syslib/mv64x60.c
+ // This call will do NOTHING but set the correct value for IRQ & reg base...
+ // This is needed because new Marvell ethernet driver get theses info from
+ // there
+ {
+ static struct mv64x60_handle bh;
+ static struct mv64x60_setup_info si;
+ mv64x60_init(&bh, &si);
+ }
+#endif
}
void __init chrp_setup_arch(void)
@@ -262,7 +280,7 @@
ROOT_DEV = Root_SDA2; /* sda2 (sda1 is for the kernel) */
/* On pegasos, enable the L2 cache if not already done by OF */
- pegasos_set_l2cr();
+ pegasos_stuff();
/* Lookup PCI host bridges */
chrp_find_bridges();
--- linux-2.5-mv643xx-enet/arch/ppc/syslib/Makefile 2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/syslib/Makefile 2005-03-07 14:13:14.000000000 +0100
@@ -59,8 +59,8 @@
open_pic.o i8259.o hawk_common.o
obj-$(CONFIG_MENF1) += todc_time.o i8259.o mpc10x_common.o \
pci_auto.o indirect_pci.o
-obj-$(CONFIG_MV64360) += mv64360_pic.o
-obj-$(CONFIG_MV64X60) += mv64x60.o mv64x60_win.o indirect_pci.o
+obj-$(CONFIG_MV64360) +=
+obj-$(CONFIG_MV64X60) += mv64x60.o mv64x60_win.o indirect_pci.o mv64360_pic.o
obj-$(CONFIG_MVME5100) += open_pic.o todc_time.o indirect_pci.o \
pci_auto.o hawk_common.o
obj-$(CONFIG_MVME5100_IPMC761_PRESENT) += i8259.o
--- linux-2.5-mv643xx-enet/arch/ppc/syslib/mv64360_pic.c 2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/syslib/mv64360_pic.c 2005-03-07 14:13:14.000000000 +0100
@@ -369,6 +369,10 @@
u32 mask;
int rc;
+ if ( mv64360_ispegasos2() ) return 0;
+
+ printk("not pegasos\n");
+
/* Clear old errors and register CPU interface error intr handler */
mv64x60_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
if ((rc = request_irq(MV64x60_IRQ_CPU_ERR,
--- linux-2.5-mv643xx-enet/arch/ppc/syslib/mv64x60.c 2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/arch/ppc/syslib/mv64x60.c 2005-03-07 14:21:04.000000000 +0100
@@ -314,15 +314,15 @@
static struct resource mv64x60_eth_shared_resources[] = {
[0] = {
.name = "ethernet shared base",
- .start = MV64340_ETH_SHARED_REGS,
- .end = MV64340_ETH_SHARED_REGS +
- MV64340_ETH_SHARED_REGS_SIZE - 1,
+ .start = MV643XX_ETH_SHARED_REGS,
+ .end = MV643XX_ETH_SHARED_REGS +
+ MV643XX_ETH_SHARED_REGS_SIZE - 1,
.flags = IORESOURCE_MEM,
},
};
static struct platform_device mv64x60_eth_shared_device = {
- .name = MV64XXX_ETH_SHARED_NAME,
+ .name = MV643XX_ETH_SHARED_NAME,
.id = 0,
.num_resources = ARRAY_SIZE(mv64x60_eth_shared_resources),
.resource = mv64x60_eth_shared_resources,
@@ -341,7 +341,7 @@
static struct mv64xxx_eth_platform_data eth0_pd;
static struct platform_device eth0_device = {
- .name = MV64XXX_ETH_NAME,
+ .name = MV643XX_ETH_NAME,
.id = 0,
.num_resources = ARRAY_SIZE(mv64x60_eth0_resources),
.resource = mv64x60_eth0_resources,
@@ -361,10 +361,10 @@
},
};
-static struct mv64xxx_eth_platform_data eth1_pd;
+static struct mv643xx_eth_platform_data eth1_pd;
static struct platform_device eth1_device = {
- .name = MV64XXX_ETH_NAME,
+ .name = MV643XX_ETH_NAME,
.id = 1,
.num_resources = ARRAY_SIZE(mv64x60_eth1_resources),
.resource = mv64x60_eth1_resources,
@@ -475,17 +475,58 @@
{
u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2];
- if (ppc_md.progress)
- ppc_md.progress("mv64x60 initialization", 0x0);
+ if (ppc_md.progress) ppc_md.progress("mv64x60 initialization", 0x0);
+
+#if defined(CONFIG_PPC_MULTIPLATFORM)
+ if (mv64360_ispegasos2())
+ {
+ // Pegasos II stuff
+
+ if (ppc_md.progress)
+ ppc_md.progress("mv64x60: Pegasos II Detected, skiping most of the init code & patching the ressources tables", 0x0);
+
+ spin_lock_init(&mv64x60_lock);
+
+ if (mv64x60_get_type(bh) || mv64x60_setup_for_chip(bh))
+ {
+ if (ppc_md.progress) ppc_md.progress("mv64x60_init: Init error", 0x0);
+ return -1;
+ }
+
+ // Pegasos II use IRQ 9 for every port
+ // Also notice that the ethernet driver (& others) have to
+ // use SA_SHIRQ instead of SA_INTERRUPT
+ // Also the Pegasos II has only port 0 & 1 available (MV64361)
+
+#ifdef CONFIG_MV643XX_ETH_0
+ mv64x60_eth0_resources[0].start = 9;
+ mv64x60_eth0_resources[0].end = 9;
+#endif
+#ifdef CONFIG_MV643XX_ETH_1
+ mv64x60_eth1_resources[0].start = 9;
+ mv64x60_eth1_resources[0].end = 9;
+#endif
+
+ // Marvell register is at 0xf1000000 on Pegasos II
+ mv64x60_eth_shared_resources[0].start = 0xf1000000 + MV643XX_ETH_SHARED_REGS;
+ mv64x60_eth_shared_resources[0].end = 0xf1000000 + MV643XX_ETH_SHARED_REGS + MV643XX_ETH_SHARED_REGS_SIZE - 1;
+
+ // For Pegasos II, we stop here
+ // Indeed, we only need the resources info for
+ // the ethernet driver ATM
+ if (ppc_md.progress) ppc_md.progress("mv64x60: End", 0x0);
+ return 0;
+ }
+#endif
+
spin_lock_init(&mv64x60_lock);
mv64x60_early_init(bh, si);
if (mv64x60_get_type(bh) || mv64x60_setup_for_chip(bh)) {
iounmap(bh->v_base);
bh->v_base = 0;
- if (ppc_md.progress)
- ppc_md.progress("mv64x60_init: Can't determine chip",0);
+ if (ppc_md.progress) ppc_md.progress("mv64x60_init: Can't determine chip",0);
return -1;
}
@@ -823,6 +864,18 @@
u16 val;
u8 save_exclude;
+#if defined(CONFIG_PPC_MULTIPLATFORM)
+ if (mv64360_ispegasos2())
+ {
+ // we could use the OF pci stuff
+ // but we know Pegasos II use the MV64361 chipset
+ // If people think it's not nice enough I could add some PCI code
+ // to detect that using OF
+ bh->type = MV64x60_TYPE_MV64360;
+ return 0;
+ }
+#endif
+
memset(&hose, 0, sizeof(hose));
setup_indirect_pci_nomap(&hose, bh->v_base + MV64x60_PCI0_CONFIG_ADDR,
bh->v_base + MV64x60_PCI0_CONFIG_DATA);
--- linux-2.5-mv643xx-enet/drivers/net/Kconfig 2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/drivers/net/Kconfig 2005-03-07 14:13:14.000000000 +0100
@@ -2094,11 +2094,11 @@
config MV643XX_ETH
tristate "MV-643XX Ethernet support"
- depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360
+ depends on MOMENCO_OCELOT_CA || MOMENCO_JAGUAR_ATX || MV64X60
help
This driver supports the gigabit Ethernet on the Marvell MV643XX
- chipset which is used in the Momenco Ocelot C and Jaguar ATX and
- Pegasos II, amongst other PPC and MIPS boards.
+ chipset which is used in the Momenco Ocelot C, Jaguar ATX and
+ bPlan Pegasos II computer.
config MV643XX_ETH_0
bool "MV-643XX Port 0"
--- linux-2.5-mv643xx-enet/drivers/net/mv643xx_eth.c 2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/drivers/net/mv643xx_eth.c 2005-03-07 14:25:38.000000000 +0100
@@ -44,6 +44,7 @@
#include <asm/pgtable.h>
#include <asm/system.h>
#include <asm/delay.h>
+#include <asm/mv64x60.h>
#include "mv643xx_eth.h"
/*
@@ -664,11 +665,16 @@
struct mv643xx_private *mp = netdev_priv(dev);
unsigned int port_num = mp->port_num;
int err;
-
+#if defined(CONFIG_PPC_MULTIPLATFORM)
+ int IRQ_Flags = mv64360_ispegasos2() ? SA_SHIRQ : SA_INTERRUPT;
+#else
+ int IRQ_Flags = SA_INTERRUPT;
+#endif
+
spin_lock_irq(&mp->lock);
err = request_irq(dev->irq, mv643xx_eth_int_handler,
- SA_INTERRUPT | SA_SAMPLE_RANDOM, dev->name, dev);
+ IRQ_Flags | SA_SAMPLE_RANDOM, dev->name, dev);
if (err) {
printk(KERN_ERR "Can not assign IRQ number to MV643XX_eth%d\n",
@@ -1383,6 +1389,8 @@
BUG_ON(!res);
dev->irq = res->start;
+ printk(KERN_INFO "%s: Using IRQ %d\n", __func__, dev->irq);
+
mp->port_num = port_num;
dev->open = mv643xx_eth_open;
@@ -1587,6 +1595,8 @@
if (rc)
driver_unregister(&mv643xx_eth_shared_driver);
}
+
+ printk("%s: return %d\n", __func__, rc);
return rc;
}
--- linux-2.5-mv643xx-enet/include/asm-ppc/mv64x60.h 2005-03-07 14:15:29.000000000 +0100
+++ kernel-source-2.6.11/include/asm-ppc/mv64x60.h 2005-03-07 14:18:27.000000000 +0100
@@ -27,6 +27,19 @@
#include <asm/pci-bridge.h>
#include <asm/mv64x60_defs.h>
+/*
+ * return 1 if you are on a Pegasos II, 0 otherwise
+ * this code is useful to execute the correct code
+ * on the correct machine
+ *
+*/
+#if defined(CONFIG_PPC_MULTIPLATFORM)
+extern inline int mv64360_ispegasos2(void)
+{
+ return ((_machine == _MACH_chrp) && (_chrp_type == _CHRP_Pegasos)) ? 1 : 0;
+}
+#endif
+
extern u8 mv64x60_pci_exclude_bridge;
extern spinlock_t mv64x60_lock;
^ permalink raw reply
* Re: mv64x60 updates
From: Nicolas DET @ 2005-03-07 12:57 UTC (permalink / raw)
To: James Chapman, linuxppc-dev
In-Reply-To: <422C495B.8090805@katalix.com>
Hello James,
On 07/03/2005, you wrote:
> Hi Nicolas,
> A few general comments:-
> - mv64x60 stuff is best posted to linuxppc-embedded
ok.
I would just add that our platform (Pegasos II) is using MV64361 from
Marvell and is a complete computer.
> - you change several generic files to support your platform. It should
> be possible to support new mv64x60 platforms by writing a new
> xxx_setup.c file in arch/ppc/platforms with no other generic changes.
> It is a goal that all mv64x60 boards can be supported by the generic
> code in arch/ppc/syslib. If some changes need to be made outside
> arch/ppc/platforms to support your board, try to make them generic so
> that other similar boards would be able to use them. I suggest you
> clone chrp_setup.c or katana.c rather than adding conditionals in
> chrp_setup.c for your board. Then use code in your board specific
> setup file to call arch/ppc/syslib mv64x60 routines as appropriate.
There is almost no changes compare to 2.6.11 (from kernel.org).
Pegasos II is a CHRP machine, as a result all related code is inside
arch/ppc/platform/chrp_*
There is almost nothing to do (but normal CHRP stuff) for the Pegasos
machine. I don't think it's plan clone
chrp_setup.c
I think Sven Luther could answer this better than me anyway.
About arch/ppc/syslibs/ mv64x60 code. Well, it's a bit evil as it has
hardcoded IRQ, hardcoded register base, it changes
chipset configuration... whereas all of these is already done by the
Pegasos II OpenFirmWare.
I'm open to any solution to have every MV64x60 platform supported.
The Pegasos would _only_ requiere to get correct IRQ and register base for
get_resources stuff and to have the correct flags for the request_irq().
This is only for the ethernet driver.
> - you shouldn't need to add board-specific changes in mv643xx_eth.c.
> Setup device platform data for your board in your platform file.
> If something needs to be added to the platform data for a generic
> change to mv643xx_eth, do that rather than add platform conditionals
> in the driver.
In this case, the ethernet driver should get the request_irq() flags from
something in arch/ppc/ or arch/mips/
> - why do you need to use SA_SHIRQ in the ethernet driver?
Because the IRQ we use for ethernet is shared with others devices.
Regards
--
Nicolas DET
MorphOS & Linux developer
^ permalink raw reply
* Re: mv64x60 updates
From: Sven Luther @ 2005-03-07 12:46 UTC (permalink / raw)
To: James Chapman; +Cc: Nicolas DET, linuxppc-dev
In-Reply-To: <422C495B.8090805@katalix.com>
On Mon, Mar 07, 2005 at 12:30:19PM +0000, James Chapman wrote:
> Hi Nicolas,
>
> A few general comments:-
>
> - mv64x60 stuff is best posted to linuxppc-embedded
The pegasos is not an embedded machine though, but i guess it is on -embedded
where the people using it are.
> - you change several generic files to support your platform. It should
> be possible to support new mv64x60 platforms by writing a new
> xxx_setup.c file in arch/ppc/platforms with no other generic changes.
Well, the pegasos is a chrp, so most of the stuff is in chrp_setup.c already.
> It is a goal that all mv64x60 boards can be supported by the generic
> code in arch/ppc/syslib. If some changes need to be made outside
I don't think this is sane. The generic mv64x60 stuff is for embedded boards,
and does initialize too much stuff for the pegasos. At least in the current
state of it, which is why i asked about Mark's comments about our case.
> arch/ppc/platforms to support your board, try to make them generic so
> that other similar boards would be able to use them. I suggest you
> clone chrp_setup.c or katana.c rather than adding conditionals in
Why ? The pegasos is a chrp, and it works perfectly with the chrp_setup stuff,
we just need to add the necessary code for making use of the gige interface of
the marvell, the rest works perfectly in chrp.
> chrp_setup.c for your board. Then use code in your board specific
> setup file to call arch/ppc/syslib mv64x60 routines as appropriate.
Yep.
> - you shouldn't need to add board-specific changes in mv643xx_eth.c.
> Setup device platform data for your board in your platform file.
> If something needs to be added to the platform data for a generic
> change to mv643xx_eth, do that rather than add platform conditionals
> in the driver.
Ok.
> - why do you need to use SA_SHIRQ in the ethernet driver?
I think because the two ports share the irq with other devices, not sure
though.
Friendly,
Sven Luther
^ permalink raw reply
* Re: mv64x60 updates
From: James Chapman @ 2005-03-07 12:30 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev
In-Reply-To: <20050307105838.3DB6C1C007DE@mwinf0309.wanadoo.fr>
Hi Nicolas,
A few general comments:-
- mv64x60 stuff is best posted to linuxppc-embedded
- you change several generic files to support your platform. It should
be possible to support new mv64x60 platforms by writing a new
xxx_setup.c file in arch/ppc/platforms with no other generic changes.
It is a goal that all mv64x60 boards can be supported by the generic
code in arch/ppc/syslib. If some changes need to be made outside
arch/ppc/platforms to support your board, try to make them generic so
that other similar boards would be able to use them. I suggest you
clone chrp_setup.c or katana.c rather than adding conditionals in
chrp_setup.c for your board. Then use code in your board specific
setup file to call arch/ppc/syslib mv64x60 routines as appropriate.
- you shouldn't need to add board-specific changes in mv643xx_eth.c.
Setup device platform data for your board in your platform file.
If something needs to be added to the platform data for a generic
change to mv643xx_eth, do that rather than add platform conditionals
in the driver.
- why do you need to use SA_SHIRQ in the ethernet driver?
/james
Nicolas DET wrote:
> Hello Sven,
>
> On 07/03/2005, you wrote:
>
>
>>But i hear Nicolas has done some useful work yesterday evening, i will
>>review it as soon as he is back from dreamland :)
>
>
> You can find the patch against 2.6.11 from kernel.org here:
> http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2
>
> This patch shouldn't break mv code for others platform (non PegasosII), and
> fix Pegasos II init...
>
> Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:
>
> in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code
> in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the
> ressources tables for Pegasos II hardware (register base & IRQ).
> in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
> in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call
> mv64x60_init() if CONFIG_MV64x60
> in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for
> request_irq if pegasos II detected
>
> The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/...
> because I use this function to use the correct flags in the ethernet
> driver.
>
> Of course, this patch may be discuss as there are several architecture
> using Marvell chipsets and each requieres some specific code.
> I don't know where it's the best to place mv64360_ispeasos2(), maybe this
> func could even be renamed mv64x60_ispegasos2()..
>
> Please, people from others MV64x60 architectures review this patch, modify
> if it neeeded and check it doesn't break your architecture (I shouldn't but
> for MIPS ethernet).
>
> Regards
^ permalink raw reply
* Re: Adding machine types to the kernel tree...
From: Matt Porter @ 2005-03-07 12:27 UTC (permalink / raw)
To: Jakob Viketoft; +Cc: Linux PPC Embedded list
In-Reply-To: <422C27FE.6000709@bitsim.se>
On Mon, Mar 07, 2005 at 11:07:58AM +0100, Jakob Viketoft wrote:
> Thanks for the comments!
>
> Andrew May wrote:
> > I think a huge first step would be to banish xparameters.h from all the
> > kernel code.
> > Our HW guys just seem to do the strangest things without checking.
> > So I have 2 spins of a board with 2 Virtex-II pro's each.
> > The 2 spins have a small refrence clock change and the 2 CPU's have
> > different IRQ mappings.
>
> I understand that there is numerous resentment against having this file
> in the kernel and I've been thinking of a solution without it. One such
> path would be serving the kernel with a OCP list of the devices used,
> but I'm unsure about the current status of OCP. Is this The Right Way to
> do it, or are OCP likely to be abandoned further along the 2.6 road?
>
> Matt (Porter), I've seen that you've "ported" this to the 2.6 kernel,
> what do you say?
Don't tie anything permanently to OCP. :) Eventually, 4xx will convert
to platform devices like other similar SoC type subarches in ppc32 have
already done. The only reason it hasn't been done yet is that there
are some other higher priority things on my plate at the moment.
That said, anything you do with OCP additions maps right into
platform_data in the platform device world.
However, it seems you are talking about passing information to
the kernel from some bootrom or full featured firmware. That is
a separate issue from how information is passed from the arch-code
into drivers (this is what OCP and platform devices accomplish).
For now, you could define a birec type for xparameters and
standardize around passing the info in that. In the future,
birecs should be replaced by the "flattened OF device tree" method
that has been discussed here a bit (I know Jon Masters is lurking
around here, maybe with some code).
> > There is no way I wanted to build 4 kernels to handle these.
> > I don't have the code with me, but the basic thing I did was fixup
> > the compiled in arrays like rs_table in the board_io_mapping.
> >
> > So the quick way to start tracking things down may be to just
> > replace all the constants in xparmaters.h with function calls
> > that got the info from the boot loader if possible.
> > You will get plenty of compile errors for the arrays, but then
> > just this type of code needs to be fixed up to setup the arrary
> > at run time rather than just get the pointer to it at run time.
>
> The question is, do you want to have a bootloader (as U-boot) on a small
> embedded system? In the FPGA case, you might need something that puts
> the bitstream in the right place, but I'm not quite sure it would
> constitute a bootloader. Maybe just having a static OCP list at a
> certain location in flash and let the little bitstream prog send the
> pointer to it as a kernel parameter at startup?
Even the smallest bootloader rom could put the xparameters.h info in
a location and point to it using the standard birec method when
transferring control to the kernel.
I belive this would give Andrew the kind of flexibility he would like.
We've even talked about moving (in many cases at least) the SoC device
descriptions for other PPC SoCs out of the kernel so they are passed in
via birecs or the future flattened OF device tree.
-Matt
^ permalink raw reply
* Read TCN-register in user space
From: Björn Östby @ 2005-03-07 11:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
I'm currently using ELDK 3.0 (kernel 2.4.25) and a mpc823e trying to do some latency measurements for my final thesis project.
I'm wondering if there is any possibility to read the Timer Counter Register (TCN1) in user space. I have initially used gettimeofday(), which provides sufficient resolution (usec), but I suppose that solution probably adds on some kind of unknown context-switch latency. Does anyone have a clue on how to access this in user space? Could inline assembler or perhaps mmap() do the trick (I'm using C as programming language)?.
Regards,
Bjorn
[-- Attachment #2: Type: text/html, Size: 1195 bytes --]
^ permalink raw reply
* Re: mv64x60 updates
From: Nicolas DET @ 2005-03-07 10:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20050307065210.GA21270@pegasos>
Hello Sven,
On 07/03/2005, you wrote:
> But i hear Nicolas has done some useful work yesterday evening, i will
> review it as soon as he is back from dreamland :)
You can find the patch against 2.6.11 from kernel.org here:
http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2
This patch shouldn't break mv code for others platform (non PegasosII), and
fix Pegasos II init...
Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:
in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code
in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the
ressources tables for Pegasos II hardware (register base & IRQ).
in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call
mv64x60_init() if CONFIG_MV64x60
in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for
request_irq if pegasos II detected
The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/...
because I use this function to use the correct flags in the ethernet
driver.
Of course, this patch may be discuss as there are several architecture
using Marvell chipsets and each requieres some specific code.
I don't know where it's the best to place mv64360_ispeasos2(), maybe this
func could even be renamed mv64x60_ispegasos2()..
Please, people from others MV64x60 architectures review this patch, modify
if it neeeded and check it doesn't break your architecture (I shouldn't but
for MIPS ethernet).
Regards
--
Nicolas DET
MorphOS & Linux developer
^ permalink raw reply
* Re: mv64x60 updates
From: Nicolas DET @ 2005-03-07 10:56 UTC (permalink / raw)
To: Sven Luther, linuxppc-embedded
In-Reply-To: <20050307065210.GA21270@pegasos>
Hello Sven,
On 07/03/2005, you wrote:
> But i hear Nicolas has done some useful work yesterday evening, i will
> review it as soon as he is back from dreamland :)
You can find the patch against 2.6.11 from kernel.org here:
http://powernico.free.fr/patch_2.6.11_mv64x60.diff.bz2
This patch shouldn't break mv code for others platform (non PegasosII), and
fix Pegasos II init...
Basicly, I added mv64360_ispegasos2() in include/asm-ppc/mv64x60.h. Then:
in arch/ppc/syslibs/mv64360_pic.c, I skip the IRQ init code
in arch/ppc/syslibs/mv64x60.c, I skip all the chip init & patch the
ressources tables for Pegasos II hardware (register base & IRQ).
in include/asm-ppc/mv64x60.h: added mv64360_ispegasos2()
in arch/ppc/kernel/chrp_setup.c, rename/added pegasos2_stuff() and call
mv64x60_init() if CONFIG_MV64x60
in drivers/net/mv64xx_eth.c, use SA_SHIRQ instead of SA_INTERRUPT for
request_irq if pegasos II detected
The only thing to do is to add mv64360_ispegasos2() in include/asm-mips/...
because I use this function to use the correct flags in the ethernet
driver.
Of course, this patch may be discuss as there are several architecture
using Marvell chipsets and each requieres some specific code.
I don't know where it's the best to place mv64360_ispeasos2(), maybe this
func could even be renamed mv64x60_ispegasos2()..
Please, people from others MV64x60 architectures review this patch, modify
if it neeeded and check it doesn't break your architecture (I shouldn't but
for MIPS ethernet).
Regards
--
Nicolas DET
MorphOS & Linux developer
^ permalink raw reply
* Re: gcc-3.3.3 from YDL4 problems?
From: Clemens Koller @ 2005-03-07 10:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppcembed Mailing List
In-Reply-To: <58ddcf3f9fe35315256e2fa3d7361081@freescale.com>
Hello, Kumar!
> Has anyone else had any issues with building kernels (2.6.11) with
> gcc-3.3.3 from YDL4. Ran into a problem today were a 2.6.11 build for
> MPC8540 ADS breaks with gcc-3.3.3 but works ok with a 3.4.3.
You know that I build the mpc8540_ads also.
I use the Denx ELDK 3.1 with gcc 3.3.3 and it breaks due to an unknown
rfci instruction:
$ make
CHK include/linux/version.h
CC scripts/mod/empty.o
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
CC arch/ppc/kernel/asm-offsets.s
CHK include/asm-ppc/offsets.h
CC init/main.o
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
CC init/do_mounts.o
CC init/do_mounts_devfs.o
CC init/do_mounts_rd.o
CC init/do_mounts_initrd.o
LD init/mounts.o
CC init/initramfs.o
CC init/calibrate.o
LD init/built-in.o
CHK usr/initramfs_list
AS usr/initramfs_data.o
LD usr/built-in.o
AS arch/ppc/kernel/entry.o
arch/ppc/kernel/entry.S: Assembler messages:
arch/ppc/kernel/entry.S:800: Error: Unrecognized opcode: `rfci'
make[1]: *** [arch/ppc/kernel/entry.o] Error 1
make: *** [arch/ppc/kernel] Error 2
But if I use your powerpc-linux-gnuspe-* (cross-)toolchain it
builds fine. Maybe some compile options for 3.3.3 might be sufficient
to fix that... my way is to use 3.4.3.
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
* MV64360 MPSC - console problem
From: Hegde Ashok-aah024 @ 2005-03-07 10:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am trying to bring up linux-2.6.10 on ppc based system with
MV64360(marvell controller).
I am unable to use mpsc as the console, serial text debug messages are
coming fine i.e. ppc_md.progress able to print properly on the serial port.
I observed that when console_init() is being called from init/main.c none
of our "mpsc" init functions are called.
Also I see that there is no call to "console_initcall" in mpsc driver.
According to my understanding this call is required in serial drivers used
as consoles.
I took this mpsc driver from "bk://source.mvista.com/linux-2.5-marvell" as
mentioned in ppc mailinglist.
Hardware has been tested with linux-2.4.20 flavour and it is absolutely
fine.
Appreciate any help.
Thanks,
Ashok
^ 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