* Re: PCI Arbiter on PPC440GX?
From: Ralph Siemsen @ 2005-04-08 14:27 UTC (permalink / raw)
To: Sanjay Bajaj; +Cc: linuxppc-dev
In-Reply-To: <0007F077BB3476449151699150E8FEA20592AF@exchange.tsi-telsys.com>
Sanjay Bajaj wrote:
> How do I enable/disable PCI Arbiter on PPC440GX?
See the UserManual for all the details... but the arbiter enable/disable
is a strapping option. If you do not have a serial boot prom, then the
arbiter is off by default. You can override this in your bootloader by
poking a register. Seach the manual for "PAE" (Pci Arbiter Enable).
The register is SDR0_XCR, bit #0 (page 347).
-R
^ permalink raw reply
* MTD Mapping driver - out of vmalloc space
From: Chris Elston @ 2005-04-08 14:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
Dear all,
I'm writing an MTD mapping driver for a board with (up to) 512M SDRAM, and
(up to) 256M Flash and I've hit a bit of a problem. The standard way to write
a mapping driver seems to be to map the whole of the Flash into kernel virtual
memory space. While this is not a problem for small Flash devices, I'm hitting
the limit of the vmalloc space.
So I decided to modify my mapping driver to work through a smaller virtual
addressing window.
Basically, all reads/writes are redirected through my custom functions which
first ensure that the correct physical address range is mapped into virtual
space and then drop through to the standard read/write functions. The mapping
is achieved using ioremap/iounmap calls. (code attached)
David Woodhouse pointed out that this approach is not viable because the reads
and writes must be atomic - and ioremap can potentially sleep. So I'm stuck as
to how to proceed.
Ideally what I'd like is to be able to allocate a block of virtual addresses at
init time and then dynamically modify the physical address range that it refers to.
Since I wouldn't be requesting any more vmalloc space - just changing the mapping
for the space I have got - I'd hopefully be able to make this a non-blocking
operation. Unfortunately I have no idea how to go about this - or even if it's
possible :)
Thanks in advance,
Chris.
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
[-- Attachment #2: rsppc7d-flash.c --]
[-- Type: application/octet-stream, Size: 8944 bytes --]
/*
* Radstone Technology PPC7D Flash memory driver.
* Copyright (C) 2005 Radstone Technology <chris.elston@radstone.co.uk>
*
* Based on: ceiva.c, which has the following copyright:
* Ceiva flash memory driver.
* Copyright (C) 2002 Rob Scott <rscott@mtrob.fdns.net>
*
* Based on: sa1100-flash.c, which has the following copyright:
* Flash memory access on SA11x0 based devices
*
* (C) 2000 Nicolas Pitre <nico@cam.org>
*
*/
#include <linux/config.h>
#include <linux/module.h>
#include <linux/types.h>
#include <linux/ioport.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/map.h>
#include <linux/mtd/partitions.h>
#include <linux/mtd/concat.h>
#include <asm/io.h>
#include <asm/ppcboot.h>
#include <platforms/radstone_ppc7d.h>
extern unsigned char __res[]; /* residual data structure */
static bd_t *binfo = (bd_t *)__res;
/*
* See include/linux/mtd/partitions.h for definition of the mtd_partition
* structure.
*/
#define RSPPC7D_BOOT_PARTITION_SIZE 0x800000
#define RSPPC7D_KERNEL_PARTITION_SIZE 0x400000
static struct mtd_partition rsppc7d_partitions[] = {
{
.name = "User",
.size = 0, /* set at runtime */
.offset = 0
},{
.name = "Kernel",
.size = RSPPC7D_KERNEL_PARTITION_SIZE,
.offset = MTDPART_OFS_APPEND
},{
.name = "PPCBoot",
.size = RSPPC7D_BOOT_PARTITION_SIZE,
.offset = MTDPART_OFS_APPEND,
.mask_flags = MTD_WRITEABLE /* force read-only */
}
};
static int __init rsppc7d_static_partitions(struct mtd_partition **parts)
{
int nb_parts = 0;
rsppc7d_partitions[0].size = binfo->bi_flashsize -
RSPPC7D_KERNEL_PARTITION_SIZE -
RSPPC7D_BOOT_PARTITION_SIZE;
*parts = rsppc7d_partitions;
nb_parts = ARRAY_SIZE(rsppc7d_partitions);
return nb_parts;
}
struct rsppc7d_info {
unsigned long base;
unsigned long size;
int width;
void __iomem *vbase;
struct map_info *map;
struct mtd_info *mtd;
struct resource *res;
};
static struct map_info *io_mapped_map = NULL;
/*
* In order to avoid running out of vmalloc space, this
* function is used to 'page' the map which is currently
* being used in and out of vmalloc.
*/
static void __iomem *rsppc7d_ioremap_flash(struct map_info *map)
{
if (map != io_mapped_map) {
if (io_mapped_map) {
iounmap(io_mapped_map->virt);
io_mapped_map->virt = NULL;
}
io_mapped_map = map;
io_mapped_map->virt = ioremap(map->phys, map->size);
if (!io_mapped_map->virt) {
printk(KERN_ERR "rsppc7d_flash: unable to ioremap Flash\n");
}
}
return io_mapped_map->virt;
}
/*
* Flash access functions - fall through to default
* functions after ioremapping the current map.
*/
static inline map_word rsppc7d_flash_read(struct map_info *map, unsigned long ofs)
{
rsppc7d_ioremap_flash(map);
return inline_map_read(map, ofs);
}
static void rsppc7d_flash_write(struct map_info *map, const map_word datum, unsigned long ofs)
{
rsppc7d_ioremap_flash(map);
inline_map_write(map, datum, ofs);
}
static void rsppc7d_flash_copy_from(struct map_info *map, void *to, unsigned long from, ssize_t len)
{
rsppc7d_ioremap_flash(map);
inline_map_copy_from(map, to, from, len);
}
static void rsppc7d_flash_copy_to(struct map_info *map, unsigned long to, const void *from, ssize_t len)
{
rsppc7d_ioremap_flash(map);
inline_map_copy_to(map, to, from, len);
}
#define MAX_NR_SUBMTD 4
static struct rsppc7d_info info[MAX_NR_SUBMTD];
static int __init rsppc7d_setup_mtd(struct rsppc7d_info *rsppc7d, int nr, struct mtd_info **rmtd)
{
struct mtd_info *subdev[nr];
struct map_info *maps;
int i, found = 0, ret = 0;
/*
* Allocate the map_info structs in one go.
*/
maps = kmalloc(sizeof(struct map_info) * nr, GFP_KERNEL);
if (!maps)
return -ENOMEM;
memset(maps, 0, sizeof(struct map_info) * nr);
/*
* Claim and then map the memory regions.
*/
for (i = 0; i < nr; i++) {
if (rsppc7d[i].base == (unsigned long)-1)
break;
rsppc7d[i].res = request_mem_region(rsppc7d[i].base, rsppc7d[i].size, "rsppc7d flash");
if (!rsppc7d[i].res) {
ret = -EBUSY;
break;
}
rsppc7d[i].map = maps + i;
rsppc7d[i].map->name = "rsppc7d flash";
rsppc7d[i].map->size = rsppc7d[i].size;
rsppc7d[i].map->phys = rsppc7d[i].base;
rsppc7d[i].map->bankwidth = rsppc7d[i].width;
rsppc7d[i].map->read = rsppc7d_flash_read;
rsppc7d[i].map->write = rsppc7d_flash_write;
rsppc7d[i].map->copy_from = rsppc7d_flash_copy_from;
rsppc7d[i].map->copy_to = rsppc7d_flash_copy_to;
rsppc7d[i].mtd = do_map_probe("cfi_probe", rsppc7d[i].map);
if (rsppc7d[i].mtd == NULL) {
ret = -ENXIO;
break;
}
rsppc7d[i].mtd->owner = THIS_MODULE;
subdev[i] = rsppc7d[i].mtd;
printk(KERN_INFO "rsppc7d flash: CFI device at 0x%08lx, %dMiB, "
"%d-bit\n", rsppc7d[i].base, rsppc7d[i].mtd->size >> 20,
rsppc7d[i].width * 8);
found += 1;
}
/*
* ENXIO is special. It means we didn't find a chip when
* we probed. We need to tear down the mapping, free the
* resource and mark it as such.
*/
if (ret == -ENXIO) {
release_resource(rsppc7d[i].res);
rsppc7d[i].res = NULL;
}
/*
* If we found one device, don't bother with concat support.
* If we found multiple devices, use concat if we have it
* available, otherwise fail.
*/
if (ret == 0 || ret == -ENXIO) {
if (found == 1) {
*rmtd = subdev[0];
ret = 0;
} else if (found > 1) {
/*
* We detected multiple devices. Concatenate
* them together.
*/
#ifdef CONFIG_MTD_CONCAT
*rmtd = mtd_concat_create(subdev, found,
"rsppc7d flash");
if (*rmtd == NULL)
ret = -ENXIO;
#else
printk(KERN_ERR "rsppc7d flash: multiple devices "
"found but MTD concat support disabled.\n");
ret = -ENXIO;
#endif
}
}
/*
* If we failed, clean up.
*/
if (ret) {
do {
if (rsppc7d[i].mtd)
map_destroy(rsppc7d[i].mtd);
if (rsppc7d[i].res)
release_resource(rsppc7d[i].res);
} while (i--);
kfree(maps);
}
return ret;
}
static void __exit rsppc7d_destroy_mtd(struct rsppc7d_info *rsppc7d, struct mtd_info *mtd)
{
int i;
del_mtd_partitions(mtd);
if (mtd != rsppc7d[0].mtd)
mtd_concat_destroy(mtd);
for (i = MAX_NR_SUBMTD; i >= 0; i--) {
if (rsppc7d[i].mtd)
map_destroy(rsppc7d[i].mtd);
if (rsppc7d[i].res)
release_resource(rsppc7d[i].res);
}
if (io_mapped_map)
iounmap(io_mapped_map->virt);
kfree(rsppc7d[0].map);
}
/*
* We define the memory space, size, and width for the flash memory
* space here.
*/
#define RSPPC7D_FLASH_BANK_WIDTH 4
static int __init rsppc7d_setup_flash(void)
{
int nr, banksz, banknr;
unsigned char memcfg;
static int flash_sizes[4] = { 0x04000000, 0x02000000, 0, 0x01000000 };
static int flash_banks[4] = { 4, 3, 2, 1 };
memcfg = inb(PPC7D_CPLD_MEM_CONFIG_EXTEND);
banksz = flash_sizes[memcfg & PPC7D_CPLD_FLASH_DEV_SIZE_MASK];
banknr = flash_banks[(memcfg & PPC7D_CPLD_FLASH_BANK_NUM_MASK) >> 2];
for (nr = 0; nr < banknr; nr++)
{
info[nr].base = binfo->bi_flashstart + (nr * banksz);
info[nr].size = banksz;
info[nr].width = RSPPC7D_FLASH_BANK_WIDTH;
}
return banknr;
}
static struct mtd_partition *parsed_parts;
static const char *probes[] = { "cmdlinepart", NULL };
static void __init rsppc7d_locate_partitions(struct mtd_info *mtd)
{
const char *part_type = NULL;
int nr_parts = 0;
do {
/*
* Partition selection stuff.
*/
nr_parts = parse_mtd_partitions(mtd, probes, &parsed_parts, 0);
if (nr_parts > 0) {
part_type = "command line";
break;
}
nr_parts = rsppc7d_static_partitions(&parsed_parts);
if (nr_parts > 0) {
part_type = "static";
break;
}
printk("found: %d partitions\n", nr_parts);
} while (0);
if (nr_parts == 0) {
printk(KERN_NOTICE "rsppc7d flash: no partition info "
"available, registering whole flash\n");
add_mtd_device(mtd);
} else {
printk(KERN_NOTICE "rsppc7d flash: using %s partition "
"definition\n", part_type);
add_mtd_partitions(mtd, parsed_parts, nr_parts);
}
/* Always succeeds. */
}
static void __exit rsppc7d_destroy_partitions(void)
{
if (parsed_parts)
kfree(parsed_parts);
}
static struct mtd_info *mymtd;
static int __init rsppc7d_mtd_init(void)
{
int ret;
int nr;
nr = rsppc7d_setup_flash();
if (nr < 0)
return nr;
ret = rsppc7d_setup_mtd(info, nr, &mymtd);
if (ret)
return ret;
rsppc7d_locate_partitions(mymtd);
return 0;
}
static void __exit rsppc7d_mtd_cleanup(void)
{
rsppc7d_destroy_mtd(info, mymtd);
rsppc7d_destroy_partitions();
}
module_init(rsppc7d_mtd_init);
module_exit(rsppc7d_mtd_cleanup);
MODULE_AUTHOR("Chris Elston <chris.elston@radstone.co.uk>");
MODULE_DESCRIPTION("MTD map driver for Radstone PPC7D");
MODULE_LICENSE("GPL");
^ permalink raw reply
* Re: cross-compiling under cygwin?
From: Tom Rini @ 2005-04-08 14:46 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded PPC Linux list
In-Reply-To: <Pine.LNX.4.61.0504081010330.14089@localhost.localdomain>
On Fri, Apr 08, 2005 at 10:13:09AM -0400, Robert P. J. Day wrote:
> i've just had a request from a colleague who wants to do all the
> cross-compilation for our 8xx board on a windows box, rather than
> linux.
>
> there was talk of cygwin, and kdevelop as well. i'm still parsing
> the rest of the email but is there a canonical URL that discusses
> working in the windows environment?
>
> i'm just about to head over to denx.de to see what i can find.
> thanks for any pointers.
The cross-tool list has had some of this. As of 2.6.10 at least, the
following was still needed, and too ugly and/or cygwin version specific
to be submitted to the kernel proper (still applies cleanly to
2.6.12-rc2, but untested in Cygwin env):
Source: MontaVista Software, Inc.
MR: 8836
Type: Defect Fix
Disposition: local
Signed-off-by: Tom Rini <trini@mvista.com>
Description:
A collection of unmergeable Cygwin fixes:
- Cygwin doesn't have <inttypes.h> nor <stdint.h>, but doesn't
need them for certain values anyhow.
- For certain ELF things, we rely on libelf being provided by
the MVL environment.
- /usr/include/asm/byteorder.h provided ntohl/htonl.
- <limits.h> defines PATH_MAX as an expression, which means
it cannot be used in some places.
Index: linux-2.6.11.2/arch/ppc/boot/utils/mktree.c
===================================================================
--- linux-2.6.11.2.orig/arch/ppc/boot/utils/mktree.c
+++ linux-2.6.11.2/arch/ppc/boot/utils/mktree.c
@@ -15,9 +15,9 @@
#include <sys/stat.h>
#include <unistd.h>
#include <netinet/in.h>
-#ifdef __sun__
+#if defined(__sun__)
#include <inttypes.h>
-#else
+#elif !defined(__CYGWIN__)
#include <stdint.h>
#endif
Index: linux-2.6.11.2/scripts/mod/modpost.h
===================================================================
--- linux-2.6.11.2.orig/scripts/mod/modpost.h
+++ linux-2.6.11.2/scripts/mod/modpost.h
@@ -7,7 +7,11 @@
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
+#ifdef __CYGWIN__
+#include <libelf/libelf.h>
+#else
#include <elf.h>
+#endif
#include "elfconfig.h"
Index: linux-2.6.11.2/scripts/mod/mk_elfconfig.c
===================================================================
--- linux-2.6.11.2.orig/scripts/mod/mk_elfconfig.c
+++ linux-2.6.11.2/scripts/mod/mk_elfconfig.c
@@ -1,7 +1,11 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#ifdef __CYGWIN__
+#include <libelf/libelf.h>
+#else
#include <elf.h>
+#endif
int
main(int argc, char **argv)
Index: linux-2.6.11.2/scripts/mod/sumversion.c
===================================================================
--- linux-2.6.11.2.orig/scripts/mod/sumversion.c
+++ linux-2.6.11.2/scripts/mod/sumversion.c
@@ -1,7 +1,10 @@
+#if defined(__sun__)
#include <netinet/in.h>
-#ifdef __sun__
#include <inttypes.h>
+#elif defined(__CYGWIN__)
+#include <asm/byteorder.h> /* For ntohl/htonl */
#else
+#include <netinet/in.h>
#include <stdint.h>
#endif
#include <ctype.h>
Index: linux-2.6.11.2/scripts/mod/file2alias.c
===================================================================
--- linux-2.6.11.2.orig/scripts/mod/file2alias.c
+++ linux-2.6.11.2/scripts/mod/file2alias.c
@@ -19,9 +19,9 @@ typedef Elf32_Addr kernel_ulong_t;
#else
typedef Elf64_Addr kernel_ulong_t;
#endif
-#ifdef __sun__
+#if defined(__sun__)
#include <inttypes.h>
-#else
+#elif !defined(__CYGWIN__)
#include <stdint.h>
#endif
Index: linux-2.6.11.2/arch/ppc/boot/utils/mkbugboot.c
===================================================================
--- linux-2.6.11.2.orig/arch/ppc/boot/utils/mkbugboot.c
+++ linux-2.6.11.2/arch/ppc/boot/utils/mkbugboot.c
@@ -21,9 +21,9 @@
#include <stdlib.h>
#include <errno.h>
#include <fcntl.h>
-#ifdef __sun__
+#if defined(__sun__)
#include <inttypes.h>
-#else
+#elif !defined(__CYGWIN__)
#include <stdint.h>
#endif
Index: linux-2.6.11.2/lib/gen_crc32table.c
===================================================================
--- linux-2.6.11.2.orig/lib/gen_crc32table.c
+++ linux-2.6.11.2/lib/gen_crc32table.c
@@ -1,6 +1,8 @@
#include <stdio.h>
#include "crc32defs.h"
+#ifndef __CYGWIN__
#include <inttypes.h>
+#endif
#define ENTRIES_PER_LINE 4
Index: linux-2.6.11.2/usr/gen_init_cpio.c
===================================================================
--- linux-2.6.11.2.orig/usr/gen_init_cpio.c
+++ linux-2.6.11.2/usr/gen_init_cpio.c
@@ -10,6 +10,12 @@
#include <ctype.h>
#include <limits.h>
+/* Cygwin's <limits.h> defines PATH_MAX as (260 - 1) which just won't do. */
+#ifdef __CYGWIN__
+#undef PATH_MAX
+#define PATH_MAX 259
+#endif
+
/*
* Original work by Jeff Garzik
*
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Tom Rini @ 2005-04-08 14:54 UTC (permalink / raw)
To: Leigh Brown; +Cc: linuxppc-dev
In-Reply-To: <33467.82.10.231.190.1112960162.squirrel@82.10.231.190>
On Fri, Apr 08, 2005 at 12:36:02PM +0100, Leigh Brown wrote:
> Tom Rini said:
> > On Wed, Apr 06, 2005 at 03:47:13AM +0200, Christian wrote:
> >> Tom Rini wrote:
> >> > Can either of you verify that say 2.6.11.6 w/ "noresidual" on the
> >> > command-line works? Thanks.
> >>
> >> i booted vanilla 2.6.11.6 with noresidual (and "nopresidual" too, as
> >> Sven
> >> sugggested), but the scsi errors did not went away :(
> >>
> >> on a side note, and perhaps totally unrelated: i always have
> >> PROC_PREPRESIDUAL=y in my .config, but i never had /proc/residual as
> >> promised from the help text.
> >
> > Odd. I thought that only happened if you had no residual data at all
> > (which can happen on Powerstacks, esp if netbooting the kernel). But in
> > that case the new code shouldn't be hit at all. Leigh?
>
> Hi, I'm back from my holidays, and have had a look at this. As I spent
> lots of time understanding the horrendous mess that was
> prep_pcibios_fixup(), I'd be loath to back out the changes I made
> (especially as they work so well for me ;-) ).
>
> It turns out that prep_pib_init() is the culprit. Although it would
> appear to be coded for the non-openpic case, it obviously doesn't work.
> The old version of prep_pcibios_fixup() only called it if there is an
> openpic on the machine. We can restore that behaviour with the
> following patch:
>
> --- prep_pci.c.orig 2005-04-08 11:49:25.743718088 +0000
> +++ prep_pci.c 2005-04-08 12:23:00.541422280 +0000
> @@ -1245,8 +1245,13 @@
> pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev->irq);
> }
>
> - /* Setup the Winbond or Via PIB */
> - prep_pib_init();
> + /* Setup the Winbond or Via PIB - prep_pib_init() is coded for
> + * the non-openpic case, but it breaks (at least) the Utah
> + * (Powerstack II Pro4000), so only call it if we have an
> + * openpic.
> + */
> + if (have_openpic)
> + prep_pib_init();
> }
>
> static void __init
>
> I've no idea even what machines would be affected by this, but it
> fixes Sven's problem and restores the old behaviour, so that
> can't be bad.
>
> I guess fixing prep_pib_init() would be the better solution but
> I wouldn't know where to start. If this band-aid is good enough
> I can submit a proper patch, if you like.
If this works, I'd like to see this get into 2.6.12. Please re-send to
akpm / this list. Assuming it's just the above:
Acked-by: Tom Rini <trini@kernel.crashing.org>
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: cross-compiling under cygwin?
From: Steven Blakeslee @ 2005-04-08 15:24 UTC (permalink / raw)
To: Tom Rini, Robert P. J. Day; +Cc: Embedded PPC Linux list
> >=20
> > there was talk of cygwin, and kdevelop as well. i'm=20
> still parsing=20
> > the rest of the email but is there a canonical URL that discusses=20
> > working in the windows environment?
> >=20
> > i'm just about to head over to denx.de to see what i can find.
> > thanks for any pointers.
>=20
I do my work inside of vmware. You will have all the tools you need
within linux but it runs on different windows systems. Just make sure
you have a beefy computer.
^ permalink raw reply
* [PATCH 2.6.12-rc2] ppc32: Fix building 32bit kernel for 64bit machines (Was: Re: linux 2.6.12-rc1-bk5 compilation error)
From: Tom Rini @ 2005-04-08 15:34 UTC (permalink / raw)
To: Jerome Glisse, Andrew Morton, Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <4240b91605040803137e9e7ddc@mail.gmail.com>
On Fri, Apr 08, 2005 at 11:13:19AM +0100, Jerome Glisse wrote:
> > I think you're the only person building a zImage for a 32bit kernel with
> > a 64bit toolchain for MULTIPLATFORM, yes. :)
>
> I should move to 64bits :)
>
> > This is a valid problem, however. Does the following also work for you?
>
> It partly works (correct the problem with disable_6xx_mmu)
> but i still have to the following for resolving __flush_disable_L1
>
> I changed the makefile in arch/ppc/kernel to have this :
> obj-$(CONFIG_POWER4) += cpu_setup_power4.o
> into :
> obj-$(CONFIG_POWER4) += l2cr.o cpu_setup_power4.o
OK, I think the following is a better workaround for that (based on
arch/ppc/platforms/pmac_sleep.S):
When building a ppc32 MULTIPLATFORM kernel for a 64bit pmac, we try and
build certain files or use certain functions that make no sense in that
context. This catches the last of these.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
--- linux-2.6.orig/arch/ppc/platforms/pmac_cache.S
+++ linux-2.6/arch/ppc/platforms/pmac_cache.S
@@ -28,6 +28,9 @@
*/
_GLOBAL(flush_disable_caches)
+#ifndef CONFIG_6xx
+ blr
+#else
BEGIN_FTR_SECTION
b flush_disable_745x
END_FTR_SECTION_IFSET(CPU_FTR_SPEC7450)
@@ -323,3 +326,4 @@ END_FTR_SECTION_IFSET(CPU_FTR_L3CR)
mtmsr r11 /* restore DR and EE */
isync
blr
+#endif /* CONFIG_6xx */
--- linux-2.6.orig/arch/ppc/boot/simple/Makefile
+++ linux-2.6/arch/ppc/boot/simple/Makefile
@@ -123,10 +123,13 @@ zimageinitrd-$(pcore) := zImage.initrd
end-$(pcore) := pcore
cacheflag-$(pcore) := -include $(clear_L2_L3)
+# Really only valid if CONFIG_6xx=y
zimage-$(CONFIG_PPC_PREP) := zImage-PPLUS
zimageinitrd-$(CONFIG_PPC_PREP) := zImage.initrd-PPLUS
+ifeq ($(CONFIG_6xx),y)
extra.o-$(CONFIG_PPC_PREP) := prepmap.o
misc-$(CONFIG_PPC_PREP) += misc-prep.o mpc10x_memory.o
+endif
end-$(CONFIG_PPC_PREP) := prep
end-$(CONFIG_SANDPOINT) := sandpoint
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Christian @ 2005-04-08 15:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Tom Rini
In-Reply-To: <20050408145431.GY3396@smtp.west.cox.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Tom Rini wrote:
>
> If this works, I'd like to see this get into 2.6.12. Please re-send to
> akpm / this list. Assuming it's just the above:
> Acked-by: Tom Rini <trini@kernel.crashing.org>
yes! i just applied Leigh's patch (thanks!) to a pristine 2.6.11.6 and my
PReP here booted fine:
http://www.nerdbynature.de/bits/hal/2.6.11.6/leigh/
thank you,
Christian.
- --
BOFH excuse #284:
Electrons on a bender
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCVqiLC/PVm5+NVoYRAmsZAJ9PlBmKEi/lASAtY4xx+74FzBxxkQCggjoy
IBqhEVSNEgm7BhOVEJfBWY0=
=XgaG
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: PREP sym53c8xx sym53c8xx brokeness due to 2.6.9-rc1-bk1 introduced residual data patch ...
From: Tom Rini @ 2005-04-08 15:57 UTC (permalink / raw)
To: Christian; +Cc: linuxppc-dev
In-Reply-To: <4256A88C.70101@gmx.net>
On Fri, Apr 08, 2005 at 05:51:40PM +0200, Christian wrote:
> Tom Rini wrote:
> >
> > If this works, I'd like to see this get into 2.6.12. Please re-send to
> > akpm / this list. Assuming it's just the above:
> > Acked-by: Tom Rini <trini@kernel.crashing.org>
>
> yes! i just applied Leigh's patch (thanks!) to a pristine 2.6.11.6 and my
> PReP here booted fine:
> http://www.nerdbynature.de/bits/hal/2.6.11.6/leigh/
Great. Leigh, can you also submit to gregkh for 2.6.11.7? Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] invalid instructions in kernel mode
From: Kumar Gala @ 2005-04-08 16:02 UTC (permalink / raw)
To: Fillod Stephane; +Cc: linuxppc-dev list
In-Reply-To: <159727e9d7fb3a3d217b6edf411e43c1@freescale.com>
Fillod,
Are you running this via a ramdisk or nfs? If ramdisk can you post it
somewhere that I can get to?
Also, can you email the list with the kernel oops that shows up.
thanks
- kumar
^ permalink raw reply
* Re: cross-compiling under cygwin?
From: Wolfgang Denk @ 2005-04-08 16:49 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded PPC Linux list
In-Reply-To: <Pine.LNX.4.61.0504081010330.14089@localhost.localdomain>
In message <Pine.LNX.4.61.0504081010330.14089@localhost.localdomain> you wrote:
>
> i'm just about to head over to denx.de to see what i can find.
You won't find any Cygwin stuff. We're a 100% Micro$oft-free company
:-) We don't use any windoze. Instead, we show our customers how to
integrate a Linux server into their existing network environment.
This is MUCH more efficient.
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
The use of Microsoft crippleware systems is a sin that carries with
it its own punishment.
-- Tom Christiansen in <6bo3fr$pj8$5@csnews.cs.colorado.edu>
^ permalink raw reply
* Re: cross-compiling under cygwin?
From: Robert P. J. Day @ 2005-04-08 16:52 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Embedded PPC Linux list
In-Reply-To: <20050408164959.E108EC108D@atlas.denx.de>
On Fri, 8 Apr 2005, Wolfgang Denk wrote:
> In message <Pine.LNX.4.61.0504081010330.14089@localhost.localdomain> you wrote:
> >
> > i'm just about to head over to denx.de to see what i can find.
>
> You won't find any Cygwin stuff. We're a 100% Micro$oft-free company
> :-) We don't use any windoze. Instead, we show our customers how to
> integrate a Linux server into their existing network environment.
> This is MUCH more efficient.
trust me, i'm working hard to talk them out of this approach. on a
related issue, though, are there any IDEs that stand out for embedded
system development? more than one person has recommended i look at
eclipse, so it's downloading as we speak.
and, related to the original issue, during a conference call this
morn, when the client's tech folks asked me what development
environment i use, i said, "ELDK 3.1.1 and 'vi'". there was a
noticeable silence ... :-)
rday
^ permalink raw reply
* RE: [PATCH] invalid instructions in kernel mode
From: Fillod Stephane @ 2005-04-08 17:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list
Kumar Gala wrote:
> Are you running this via a ramdisk or nfs? If ramdisk can you post it
> somewhere that I can get to?
I'm running via NFS.
> Also, can you email the list with the kernel oops that shows up.
I'll do that next week.
Anyway, reading the source suffices to realize there's a problem when=20
MATH_EMULATION is disabled on a FPU-less system with user programs=20
using load/store fp instructions.
--=20
Stephane
^ permalink raw reply
* Re: cross-compiling under cygwin?
From: Patrick Huesmann @ 2005-04-08 17:57 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded PPC Linux list
In-Reply-To: <Pine.LNX.4.61.0504081010330.14089@localhost.localdomain>
Hi,
Robert P. J. Day wrote:
> i've just had a request from a colleague who wants to do all the
>cross-compilation for our 8xx board on a windows box, rather than
>linux.
>
> there was talk of cygwin, and kdevelop as well. i'm still parsing
>the rest of the email but is there a canonical URL that discusses
>working in the windows environment?
>
>
We use colinux (http://www.colinux.org) for that. It's a Linux kernel
that runs as application under windows. It shares networking with the
windows system so you can operate it via telnet or ssh. You can even run
IDEs like kdevelop as remote X application and use the cygwin's X window
system to use the Linux apps under windows.
Before that, we used VMware, but coLinux is free and IMO, it has better
performance because it doesn't have to simulate a whole computer (but
only a small hardware abstraction layer).
It comes with a pre-patched Debian image which gives you a minimal Linux
installation. From there you set up the networking, and simply apt-get
install your apps like you would do with a native Linux box.
HTH,
Patrick
^ permalink raw reply
* Thanks!!
From: Dustin Lang @ 2005-04-08 17:47 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I finally upgraded to 2.6 last night, and I'm really enjoying it! I have
a PowerBook G4 1GHz (with NVidia graphics card). CPU frequency scaling
is working nicely for me. The cpufreq driver reports:
> Registering PowerMac CPU frequency driver
> Low: 765 Mhz, High: 998 Mhz, Boot: 765 Mhz
Which makes me wonder if 2.4 was running at 765 the whole time. Maybe
because of this, 2.6 FEELS faster :) Also, the backlight fine control is
great! I'll play with sleep/resume this weekend and report my status.
I just wanted to thank everyone who has worked on PPC Linux. You've done
great work!
Cheers,
dustin.
^ permalink raw reply
* Re: MTD Mapping driver - out of vmalloc space
From: Ho Lee @ 2005-04-08 17:51 UTC (permalink / raw)
To: Chris Elston; +Cc: linuxppc-embedded
In-Reply-To: <F38DEABE0E171746B133C1ABBD142D9703691AFD@radmail.Radstone.Local>
Hi Chris,
How about setting PAGE_OFFSET to 0x80000000, that is 2G/2G split?
It would make enough virtual address space. I've never tried on PPC,
so I don't know the side effect of this.
-- Ho
----- Original Message -----
From: "Chris Elston" <chris.elston@radstone.co.uk>
To: <linuxppc-embedded@ozlabs.org>
Sent: Friday, April 08, 2005 7:42 AM
Subject: MTD Mapping driver - out of vmalloc space
Dear all,
I'm writing an MTD mapping driver for a board with (up to) 512M SDRAM, and
(up to) 256M Flash and I've hit a bit of a problem. The standard way to write
a mapping driver seems to be to map the whole of the Flash into kernel virtual
memory space. While this is not a problem for small Flash devices, I'm hitting
the limit of the vmalloc space.
So I decided to modify my mapping driver to work through a smaller virtual
addressing window.
Basically, all reads/writes are redirected through my custom functions which
first ensure that the correct physical address range is mapped into virtual
space and then drop through to the standard read/write functions. The mapping
is achieved using ioremap/iounmap calls. (code attached)
David Woodhouse pointed out that this approach is not viable because the reads
and writes must be atomic - and ioremap can potentially sleep. So I'm stuck as
to how to proceed.
Ideally what I'd like is to be able to allocate a block of virtual addresses at
init time and then dynamically modify the physical address range that it refers to.
Since I wouldn't be requesting any more vmalloc space - just changing the mapping
for the space I have got - I'd hopefully be able to make this a non-blocking
operation. Unfortunately I have no idea how to go about this - or even if it's
possible :)
Thanks in advance,
Chris.
________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
--------------------------------------------------------------------------------
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Best way to determine tb_ticks_per_jiffy inside todc_calibrate_decr()
From: Mark A. Greer @ 2005-04-08 18:32 UTC (permalink / raw)
To: Daniel Ann; +Cc: linuxppc-embedded
In-Reply-To: <9b7ca65705040801455b84eb0d@mail.gmail.com>
Daniel,
Daniel Ann wrote:
>Hey folks,
>
>I seem to have problem getting 1 second right. Board has no RTC so
>I've basically NULLed all the todc_XXX functions except
>todc_calibrate_decr.
>
If you don't have an RTC, you shouldn't be using any todc_xxx routines.
>
>Now question is, what value should I be assigning it to tb_ticks_per_jiffy ?
>
>I was able to dig up some info from the archive, and it read,
>=-=-=-FROM ARCHIVE =-=-=-
>You must find this value by yourself but a good starting point is your
>frequency in Hz (I think)
>Example of the code
> unsigned int freq = 28000000;
> tb_tick_per_jiffy = freq/HZ;
> tb_to_us = mulhwu_scale_factor(freq,1000000);
>=-=-=-END OF ARCHIVE =-=-=-
>
>I'm fine with working it out myself but where do I start ? My board
>has 33MHz OSC, so I've trie freq = 33 * 1000000 (where HZ is defined
>100) but it turned out to be little short. I could have just tried few
>more trial and error, but I prefer knowing what I'm doing so.. :)
>
There are several platform files that explicitly set tb_ticks_per_jiffy
and tb_to_us. Did you try looking at those?
Also, 33MHz does not sound right but then you don't say what processor
you're using so who knows. You need to find the bus freq used by the
cpu/system. Try looking for the freq of the processor's SYSCLK input.
Then you probably have to divide that by 4 to get the frequency that the
decrementer runs at. That's the value that you should use for the
'freq' variable in the example code you included in your email.
Mark
^ permalink raw reply
* Re: cross-compiling under cygwin?
From: Dan Malek @ 2005-04-08 18:32 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Embedded PPC Linux list
In-Reply-To: <Pine.LNX.4.61.0504081010330.14089@localhost.localdomain>
On Apr 8, 2005, at 10:13 AM, Robert P. J. Day wrote:
> i've just had a request from a colleague who wants to do all the
> cross-compilation for our 8xx board on a windows box, rather than
> linux.
Just remember there is lots more to building and developing
than compiling a kernel. In addition to the compiler, you need
lots of support tools. Once you get a kernel, you have to create
some kind of file system, of course NFS won't work on Windows,
creating a ramdisk without a loopback device and file system
support is quite a challenge, too.
I don't understand why you wouldn't want to develop on a
Linux (or at least Unix) host, since you need those skills
and environment for the target. Do they just like impossible
challenges in their way to getting real work done? :-)
-- Dan
^ permalink raw reply
* Re: cross-compiling under cygwin?
From: Robert P. J. Day @ 2005-04-08 18:35 UTC (permalink / raw)
To: Dan Malek; +Cc: Embedded PPC Linux list
In-Reply-To: <e6dbd8188d62839f349bec5a4cd0b352@embeddededge.com>
On Fri, 8 Apr 2005, Dan Malek wrote:
>
> On Apr 8, 2005, at 10:13 AM, Robert P. J. Day wrote:
>
> > i've just had a request from a colleague who wants to do all the
> > cross-compilation for our 8xx board on a windows box, rather than
> > linux.
> Just remember there is lots more to building and developing than
> compiling a kernel. In addition to the compiler, you need lots of
> support tools. Once you get a kernel, you have to create some kind
> of file system, of course NFS won't work on Windows, creating a
> ramdisk without a loopback device and file system support is quite a
> challenge, too.
a lot of that was part of the conversation. i suspect i may have to
be more persuasive. something involving a blunt instrument, perhaps.
> I don't understand why you wouldn't want to develop on a Linux (or
> at least Unix) host, since you need those skills and environment for
> the target. Do they just like impossible challenges in their way to
> getting real work done? :-)
i'm going to assume that was rhetorical. :-)
rday
^ permalink raw reply
* Re: MTD Mapping driver - out of vmalloc space
From: Mark A. Greer @ 2005-04-08 18:39 UTC (permalink / raw)
To: Ho Lee; +Cc: linuxppc-embedded
In-Reply-To: <013c01c53c63$8b4e98e0$0d02a8c0@acting>
Ho Lee wrote:
>
> Hi Chris,
>
> How about setting PAGE_OFFSET to 0x80000000, that is 2G/2G split?
> It would make enough virtual address space. I've never tried on PPC,
> so I don't know the side effect of this.
> -- Ho
>
Chris,
Like Ho says, you need to lower PAGE_OFFSET (although you may not want
to drop it all the way to 0x80000000). That will increase your vmalloc
space. On ppc, you do this via the 'Advanced setup' config menu.
Mark
^ permalink raw reply
* Re: MTD Mapping driver - out of vmalloc space
From: Matt Porter @ 2005-04-08 18:39 UTC (permalink / raw)
To: Ho Lee; +Cc: linuxppc-embedded
In-Reply-To: <013c01c53c63$8b4e98e0$0d02a8c0@acting>
On Fri, Apr 08, 2005 at 10:51:05AM -0700, Ho Lee wrote:
>
> Hi Chris,
>
> How about setting PAGE_OFFSET to 0x80000000, that is 2G/2G split?
> It would make enough virtual address space. I've never tried on PPC,
> so I don't know the side effect of this.
This is the ideal solution. It works fine with the caveat that
you have to be very aware of the virtual memory map of your board
port when doing this. On ppc32, we have very fine grained options
for manipulating this and other parameters under Advanced Options.
If the original poster can provide more details then we can tell
him the exact settings to use.
-Matt
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Gabriel Paubert @ 2005-04-08 18:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Paul Mackerras, linux-ppc-embedded list
In-Reply-To: <8fc7723059937dc9876c5c14fdcd92ae@freescale.com>
On Fri, Apr 08, 2005 at 09:08:28AM -0500, Kumar Gala wrote:
>
> On Apr 8, 2005, at 3:26 AM, Gabriel Paubert wrote:
>
> >On Wed, Apr 06, 2005 at 04:33:14PM -0500, Kumar Gala wrote:
> > > Here is a version that works if CONFIG_PTE_64BIT is defined. If we
> >> like this, I can simplify the pte_update so we dont need the
> >(unsigned
> >> long)(p+1) - 4) trick anymore. Let me know.
> > >
> >> - kumar
> > >
> >> #ifdef CONFIG_PTE_64BIT
> >> static inline unsigned long long pte_update(pte_t *p, unsigned long
> >clr,
> > > unsigned long set)
> > > {
> > > unsigned long long old;
> > > unsigned long tmp;
> > >
> >> __asm__ __volatile__("\
> > > 1: lwarx %L0,0,%4\n\
> > > lwzx %0,0,%3\n\
> > > andc %1,%L0,%5\n\
> >> or %1,%1,%6\n\
> > > stwcx. %1,0,%4\n\
> > > bne- 1b"
> > > : "=&r" (old), "=&r" (tmp), "=m" (*p)
> >> : "r" (p), "r" ((unsigned long)(p) + 4), "r" (clr), "r"
> >(set),
> >> "m" (*p)
> >
> >Are you sure of your pointer arithmetic? I believe that
> > you'd rather want to use (unsigned char)(p)+4. Or even better:
>
> Realize that I'm converting the pointer to an int, so its not exactly
> normal pointer math. Was stick with the pre-existing stye.
Wow, my brain saw a "*" before the closing parenthesis.
>
> >
> >:"r" (p), "b" (4), "r" (clr), "r" (set)
> >
> >and change the first line to: lwarx %L0,%4,%3.
> >
> >Even more devious, you don't need the %4 parameter:
> >
> > li %L0,4
> > lwarx %L0,%L0,%3
> >
> >since %L0 cannot be r0. This saves one register.
>
> Actually the compiler effective does this for me. If you look at the
> generated asm, the only additional instruction is an 'addi' and some
> 'mr' to handle getting things in the correct registers for the return.
> Not really sure if there is much else to do to optimize this.
Now that I read it carefully, I realize that I was wrong. But there
is still some room for optimization; the parameter that you don't
need is %3: simply replace lwzx %0,0,%3 by lwz %0,-4(%4).
But I'm not sure that OOO cannot play tricks on you, what guarantees
that the lwz is done after lwarx?
Regards,
Gabriel
^ permalink raw reply
* Re: MTD Mapping driver - out of vmalloc space
From: Eugene Surovegin @ 2005-04-08 18:48 UTC (permalink / raw)
To: Ho Lee; +Cc: linuxppc-embedded
In-Reply-To: <013c01c53c63$8b4e98e0$0d02a8c0@acting>
On Fri, Apr 08, 2005 at 10:51:05AM -0700, Ho Lee wrote:
>
> Hi Chris,
>
> How about setting PAGE_OFFSET to 0x80000000, that is 2G/2G split?
> It would make enough virtual address space. I've never tried on PPC,
> so I don't know the side effect of this.
I successfully use PAGE_OFFSET equal to 0xA000'0000 on 405-based
designs (2.4 of course :)).
--
Eugene
^ permalink raw reply
* Re: pte_update and 64-bit PTEs on PPC32?
From: Kumar Gala @ 2005-04-08 19:01 UTC (permalink / raw)
To: Gabriel Paubert
Cc: linuxppc-dev list, Paul Mackerras, linux-ppc-embedded list
In-Reply-To: <20050408184442.GA13709@iram.es>
On Apr 8, 2005, at 1:44 PM, Gabriel Paubert wrote:
> On Fri, Apr 08, 2005 at 09:08:28AM -0500, Kumar Gala wrote:
> >
> > On Apr 8, 2005, at 3:26 AM, Gabriel Paubert wrote:
> >
> > >On Wed, Apr 06, 2005 at 04:33:14PM -0500, Kumar Gala wrote:
> > > > Here is a version that works if CONFIG_PTE_64BIT is defined.=A0=20=
> If we
> > >> like this, I can simplify the pte_update so we dont need the
> > >(unsigned
> > >> long)(p+1) - 4) trick anymore.=A0 Let me know.
> > > >
> > >> - kumar
> > > >
> > >> #ifdef CONFIG_PTE_64BIT
> > >> static inline unsigned long long pte_update(pte_t *p, unsigned=20
> long
> > >clr,
> > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 unsigned long set)
> > > > {
> > > >=A0=A0=A0=A0=A0=A0=A0=A0 unsigned long long old;
> > > >=A0=A0=A0=A0=A0=A0=A0=A0 unsigned long tmp;
> > > >
> > >>=A0=A0=A0=A0=A0=A0=A0=A0 __asm__ __volatile__("\
> > > > 1:=A0=A0=A0=A0=A0 lwarx=A0=A0 %L0,0,%4\n\
> > > >=A0=A0=A0=A0=A0=A0=A0=A0 lwzx=A0=A0=A0 %0,0,%3\n\
> > > >=A0=A0=A0=A0=A0=A0=A0=A0 andc=A0=A0=A0 %1,%L0,%5\n\
> > >>=A0=A0=A0=A0=A0=A0=A0=A0 or=A0=A0=A0=A0=A0 %1,%1,%6\n\
> > > >=A0=A0=A0=A0=A0=A0=A0=A0 stwcx.=A0 %1,0,%4\n\
> > > >=A0=A0=A0=A0=A0=A0=A0=A0 bne-=A0=A0=A0 1b"
> > > >=A0=A0=A0=A0=A0=A0=A0=A0 : "=3D&r" (old), "=3D&r" (tmp), "=3Dm" =
(*p)
> > >>=A0=A0=A0=A0=A0=A0=A0=A0 : "r" (p), "r" ((unsigned long)(p) + 4), =
"r" (clr), "r"
> > >(set),
> > >> "m" (*p)
> > >
> > >Are you sure of your pointer arithmetic? I believe that
> > > you'd rather want to use (unsigned char)(p)+4. Or even better:
> >
> > Realize that I'm converting the pointer to an int, so its not =
exactly
> > normal pointer math.=A0 Was stick with the pre-existing stye.
>
> Wow, my brain saw a "*" before the closing parenthesis.
> >
> > >
> > >:"r" (p), "b" (4), "r" (clr), "r" (set)
> > >
> > >and change the first line to:=A0 lwarx %L0,%4,%3.
> > >
> > >Even more devious, you don't need the %4 parameter:
> > >
> > >=A0=A0=A0=A0=A0=A0=A0 li %L0,4
> > > =A0=A0=A0=A0=A0=A0=A0 lwarx %L0,%L0,%3
> > >
> > >since %L0 cannot be r0. This saves one register.
> >
> > Actually the compiler effective does this for me.=A0 If you look at =
the
> > generated asm, the only additional instruction is an 'addi' and =
some
> > 'mr' to handle getting things in the correct registers for the=20
> return.=A0
> > Not really sure if there is much else to do to optimize this.
>
> Now that I read it carefully, I realize that I was wrong. But there
> is still some room for optimization; the parameter that you don't
> need is %3: simply replace lwzx %0,0,%3 by lwz %0,-4(%4).
Doesn't help, realize that we are going to have "r3" with a pointer to=20=
pte. There is no way w/o an add to get to the next word for the lwarx.
> But I'm not sure that OOO cannot play tricks on you, what guarantees
> that the lwz is done after lwarx?
I'm assuming since its a single asm block, gcc is not allowed to=20
reorder it.
- kumar
^ permalink raw reply
* RE: cross-compiling under cygwin?
From: Howard, Marc @ 2005-04-08 18:48 UTC (permalink / raw)
To: Embedded PPC Linux list
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Dan Malek
> Sent: Friday, April 08, 2005 11:33 AM
> To: Robert P. J. Day
> Cc: Embedded PPC Linux list
> Subject: Re: cross-compiling under cygwin?
>=20
>=20
> On Apr 8, 2005, at 10:13 AM, Robert P. J. Day wrote:
>=20
> > i've just had a request from a colleague who wants to do all the
> > cross-compilation for our 8xx board on a windows box, rather than
> > linux.
>=20
> Just remember there is lots more to building and developing
> than compiling a kernel. In addition to the compiler, you need
> lots of support tools. Once you get a kernel, you have to create
> some kind of file system, of course NFS won't work on Windows,
If I were Catholic I'd have to say a bunch of Hail Mary's for mentioning
this but...
Yes you can run NFS on Windows. The systems we ship inside our
equipment have a Win2k Server host and the embedded boards hang off of
it. File exchange is done via NFS. Micro$oft has a huge free package
called "Windows Services for Unix". It only runs on Win2k and XP Pro
however. The other gotcha is that it can only export NTFS file systems,
not FAT32.
It is basically a better cygwin port than cygwin itself. I say this
because its compiler can compile and run some RPC apps I normally use
natively on the embedded systems. Cygwin couldn't (missing include
files, etc.).
Now I'm going to wash my mouth out with soap...
Marc W. Howard
^ permalink raw reply
* Re: Thanks!!
From: Colin Leroy @ 2005-04-08 19:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0504081039570.23066@bigrock.cs.ubc.ca>
On 08 Apr 2005 at 10h04, Dustin Lang wrote:
Hi,
> Which makes me wonder if 2.4 was running at 765 the whole time.
> Maybe because of this, 2.6 FEELS faster :)
2.6 feels faster on desktop for other reasons too, such as a faster
scheduler (at least it was the case when I switched to 2.6, maybe 2.4
got a faster one too).
> Also, the backlight fine
> control is great! I'll play with sleep/resume this weekend and
> report my status.
You mentioned you have an nVidia GPU, so I guess you won't have much
success - nVidia cards are badly supported as they're being very secret
about their hardware.
--
Colin
^ 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