Segmentation fault with X.org and Coral-P drivers
Dear Matthias, in message you wrote: > > it finally works :-). I had to make a small modification to the x.org > source code. The file xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c Congrats! To make it perfect: could you please wrap up your modifications into a patch we can put on our FTP server, so others can benefit from this, too? Thanks in advance. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Even historians fail to learn from history -- they repeat the same mistakes. -- John Gill, "Patterns of Force", stardate 2534.7
Segmentation fault with X.org and Coral-P drivers
Dear Matthias, in message you wrote: > > > and EP5200 and Lite5200 are two different boards. > > Ok, my fault. I saw a Lite5200 on a picture somewhere and it looked > pretty much like my EP board :-). But what I can tell for sure is: > when I remove the "Embedded Planet" sticker on the board, there is a > Freescale logo and a print (directly on the board): "IceCube Version > 103" Ouch. So far for marketing methods. I didn't know this. > > Our kernel does not include any support for the EP5200 board. > > I checked it out from CVS, configured it, and it works (besides the X11 > thing). It should work on the Lite5200 board. I just expected different hardware ... > I did not use the prebuilt binaries, but I was able to compile the I see. > driver within my x.org tree. (I had to adapt the Imakefiles by myself, > the provided ones were too different from the originals.) If you want to send me your patches: they are welcome. > The last line is a message that I added. Since the output stops at > that point, it must be the next call that fails > (mb86290_driver.c:604): > > if (!xf86I2CProbeAddress(fPtr->I2C, I2C_SAA7113)) > return FALSE; > > May that be a problem with the i2c driver in the kernel which does not > exactly fit with my board? This is not the kernel's (MPC5200) I2C driver; actually I2C is only needed for external video decoder chip that _may_ be connected to the CoralP chip. It is the CoralP itself that acts as an I2C "adapter" in this case. By writing to some CoralP registers, accessible from the host (CPU) via PCI, the driver manipulates external pins of the CoralP chip, which form the I2C bus. It is an external (relative to both CoralP and the CPU) device that is controlled through I2C; in your case the Philips SA7 video decoder chip. > The following message also appears in Xorg.0.log, some lines above: > (II) MB86290(0): I2C bus "MB86290 I2C bus" removed. > > Thanks in advance for any hint that you can give me. You can disable video capture support, and thus the I2C, by setting option "Video" to "no" in the driver's X11 config file: Section "Device" Identifier "MB86290 card" Driver "mb86290" Option "Video" "no" EndSection Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Artificial Intelligence is the study of how to make real computers act like the ones in movies.
[PATCH] boot/common/util.S: Put flush_{instruction, data}_cache back in .relocate_code section
In 2.6.14, we had the following definition of _GLOBAL() in include/asm-ppc/processor.h: #define _GLOBAL(n)\ .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n;\ n: In 2.6.15, as part of the great powerpc merge, we moved this definition to include/asm-powerpc/ppc_asm.h, where it appears (to 32-bit code) as: #define _GLOBAL(n) \ .text; \ .stabs __stringify(n:F-1),N_FUN,0,0,n;\ .globl n; \ n: Mostly, this is fine. However, we also have the following, in arch/ppc/boot/common/util.S: .section ".relocate_code","xa" [...] _GLOBAL(flush_instruction_cache) [...] _GLOBAL(flush_data_cache) [...] The addition of the .text section definition in the definition of _GLOBAL overrides the .relocate_code section definition. As a result, these two functions don't end up in .relocate_code, so they don't get relocated correctly, and the boot fails. There's another suspicious-looking usage at kernel/swsusp.S:37 that someone should look into. I did not exhaustively search the source tree, though. The following is the minimal patch that fixes the immediate problem. I could easily be convinced that the _GLOBAL definition should be modified to remove the ".text;" line either instead of, or in addition to, this fix. Signed-off-by: Paul Janzen --- arch/ppc/boot/common/util.S~2005-12-24 15:47:48.0 -0800 +++ arch/ppc/boot/common/util.S 2006-01-04 14:07:12.0 -0800 @@ -234,7 +234,8 @@ udelay: * First, flush the data cache in case it was enabled and may be * holding instructions for copy back. */ -_GLOBAL(flush_instruction_cache) +.globl flush_instruction_cache +flush_instruction_cache: mflrr6 bl flush_data_cache @@ -279,7 +280,8 @@ _GLOBAL(flush_instruction_cache) * Flush data cache * Do this by just reading lots of stuff into the cache. */ -_GLOBAL(flush_data_cache) +.globl flush_data_cache +flush_data_cache: lis r3,cache_flush_buffer at h ori r3,r3,cache_flush_buffer at l li r4,NUM_CACHE_LINES -- Paul
Segmentation fault with X.org and Coral-P drivers
Hi Wolfgang, it finally works :-). I had to make a small modification to the x.org source code. The file xc/programs/Xserver/hw/xfree86/i2c/xf86i2c.c contains the initialization of the i2c bus. In function xf86I2CBusInit, I added the two lines near the beginning: if (b->I2CStart == NULL) b->I2CStart = I2CStart; which sets the start function to a default function. The problem was that mb86290_i2c.c does not provide a start function, whereas xf86I2CBusInit expects one under some circumstances. Best regards, Matthias
Problems starting /init
On January 4, 2006 06:03 pm, David H. Lynch Jr. wrote: [snip] > starting a c "Hello World" application that uses glibc, fputs, > printf, fwrite, to display a string - again works fine. > > But I can not get busybox to output a thing either run as /init or > run as /bin/sh. busybox tries to open the console device and does fairly extensive surgery with the stdio descriptors. So your apps that assume fds 0,1,2 to be stdin/stdout/stderr are functioning fine, but busybox is probably choking because it's opening/configuring the console devices. I've worked through this with someone before when we wanted busybox to just run with the existing fds - we eventually beat it into submission but then ended up changing/replacing the console driver instead and going back to vanilla busybox. If you take a look through the busybox source, you should find the various fork/dup/ctrl/exit gymnastics and with a little patience, you might be able to hack around it. But it might be easier in the long run to figure out where the opening/manipulation of /dev/console (or whatever it's opening) is going wrong. Sorry I can't help you further. Good luck. Cheers, Geoff -- Geoff Thorpe Freescale Semiconductor
RESEND:Problems starting /init
I have a kernel for a new board (Linux 2.6.14.5, Pico E12/Xilinx V4 PPC405) booting to the point of starting /init. /init appears to be getting loaded correctly - the execve call seems happy. But I get no output on the console. I have tried: executing sys_write(1,"Test",4); inside init/main.c immediately before starting /init - works fine. starting a "hello World" application written in PPC asm as /init - works fine. The kernel panics on exit but that is normal, /init is not supposed to exit. starting a c "Hello World" application that uses glibc, fputs, printf, fwrite, to display a string - again works fine. But I can not get busybox to output a thing either run as /init or run as /bin/sh. I have aslo tried /bin/sash - no output. I have even cross compiled sash - with all kinds of "I am here" debugging scattered through main(), If I runn it on a powerbook, I get what I expect. If I run it as /bin/sh on the e12 I get no output. Does anyone even have any ideas what I can look at ?
RESEND:[RFC] Pico E12 (Xilinx V4) patches to 2.6.15
Some sympathy and patience please. This is my first attempt to post a patch. Many aspects are working. A few listed below, are not. This is against git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Signed-off-by: David H. Lynch Jr. I could not figure out how to seek to the 2.6.14 tag so it is against HEAD/2.6.15 I am also presuming that git diff produces a unified diff. I do not try to read diffs - I typically do my diff/merges with vim, but it looks about right to me. There are basically 5 parts, and I have no idea how to easily separate the pieces: 1). Separating the Xilinx Virtex II Pro from the Xilinx Virtex IV. I believe Grant and others have done this too, and this may conflict. Most of these changes were "borrowed" from some 2.4 Linux stuff I got from Xilinx. 2). Pico E12 specific items. 3). Implementation of the Xilinx UartLite serial port(s). 4). Implementation of a pseudo serial port(s) driver for the Pico Keyhole port. The keyhole is a port-port interface between the E12 and a host computer over the CF connector. 5). a collection of flyspecks of debugging code scattered all over. Status/Overview: The Pico E12 is a Virtex IV/PPC405 implemented on a CF card. The objective is to leave as much of the FPGA free for the development of application specific logic. Pico provides their own SDK that includes Both windows and Linux host/development software. That software impliments a filesystem on the E12 flash, as well as loading and executing FPGA .bit files, and .elf files. The kernel built from this patch: will load with a modified version of the standard Pico loader - either they are including my trivial modifications, or I am working on moving them into the kernel boot code. Runs on the Xilinx V4/PPC405 in the current E12's. Requires an FPGA image with only the PPC405 and either the Xilinx UartLite or the Pico Keyhole. Use of the Xilinx PIC is optional, and is currently controlled by the xparameter_pico-e12.h file At this instant everything works up through and including loading /init (or a standalone shell). Executing init or a standalone shell does not appear to work - or more accurately console IO ceases without explanation when either /init or a shell start. Console input from the Keyhole port does not work - neither the host side not the kernel side are implemented. Console input from the Uartlite is pretty much untested. Boot/debugging "console" support for both the UartLite and Keyhole are implemented to the same level as similar facilities exist for the 8250. diff --git a/README.pico b/README.pico new file mode 12 index 000..3daad5a --- /dev/null +++ b/README.pico @@ -0,0 +1 @@ +pico/README.pico \ No newline at end of file diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig index cc3f64c..7c4318a 100644 --- a/arch/ppc/Kconfig +++ b/arch/ppc/Kconfig @@ -53,7 +53,7 @@ menu "Processor" choice prompt "Processor Type" - default 6xx + default 4xx config 6xx bool "6xx/7xx/74xx/52xx/82xx/83xx" diff --git a/arch/ppc/boot/common/misc-common.c b/arch/ppc/boot/common/misc-common.c index e79e6b3..a50762a 100644 --- a/arch/ppc/boot/common/misc-common.c +++ b/arch/ppc/boot/common/misc-common.c @@ -57,10 +57,15 @@ static int _cvt(unsigned long val, char void _vprintk(void(*putc)(const char), const char *fmt0, va_list ap); unsigned char *ISA_io = NULL; +#ifdef CONFIG_PICO_E12 +unsigned int *ISA_iow = NULL; +#endif #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \ || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \ - || defined(CONFIG_SERIAL_MPSC_CONSOLE) + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \ + || defined(CONFIG_SERIAL_UARTLITE_CONSOLE)\ + || defined(CONFIG_SERIAL_KEYHOLE_CONSOLE) extern unsigned long com_port; extern int serial_tstc(unsigned long com_port); @@ -83,7 +88,9 @@ int tstc(void) { #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \ || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \ - || defined(CONFIG_SERIAL_MPSC_CONSOLE) + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \ + || defined(CONFIG_SERIAL_UARTLITE_CONSOLE) \ + || defined(CONFIG_SERIAL_KEYHOLE_CONSOLE) if(keyb_present) return (CRT_tstc() || serial_tstc(com_port)); else @@ -98,7 +105,9 @@ int getc(void) while (1) { #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \ || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \ - || defined(CONFIG_SERIAL_MPSC_CONSOLE) + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \ + || defined(CONFIG_SERIAL_UARTLITE_CONSOLE) \ + || defined(CONFIG_SERIAL_KEYHOLE_CONSOLE) if (serial_tstc(com_port)) return (serial_getc(co
Problems starting /init
I have a kernel for a new board (Linux 2.6.14.5, Pico E12/Xilinx V4 PPC405) booting to the point of starting /init. /init appears to be getting loaded correctly - the execve call seems happy. But I get no output on the console. I have tried: executing sys_write(1,"Test",4); inside init/main.c immediately before starting /init - works fine. starting a "hello World" application written in PPC asm as /init - works fine. The kernel panics on exit but that is normal, /init is not supposed to exit. starting a c "Hello World" application that uses glibc, fputs, printf, fwrite, to display a string - again works fine. But I can not get busybox to output a thing either run as /init or run as /bin/sh. I have aslo tried /bin/sash - no output. I have even cross compiled sash - with all kinds of "I am here" debugging scattered through main(), If I runn it on a powerbook, I get what I expect. If I run it as /bin/sh on the e12 I get no output. Does anyone even have any ideas what I can look at ?
powerpc vs ppc build
Is there a summary of the differences between the ppc and powerpc builds for the 2.6 kernels? Or something describing what the community, in general, is trying to fix/address with the different schemes - besides the merging of ppc and ppc64? Or how about the current status of both build architectures? It seems that people are fixing one build and breaking the other... :( Jeff Angielski The PTR Group
Segmentation fault with X.org and Coral-P drivers
Hi Wolfgang, thanks for the quick response. 2006/1/4, Wolfgang Denk : > > I have been trying to get X.org running on a board called "Embedded > > Planet EP5200C" (it seems to be a "Freescale Lite5200") and a Fujitsu > > Umm... no. Embedded Plaet and Freescale are two different companies, > and EP5200 and Lite5200 are two different boards. Ok, my fault. I saw a Lite5200 on a picture somewhere and it looked pretty much like my EP board :-). But what I can tell for sure is: when I remove the "Embedded Planet" sticker on the board, there is a Freescale logo and a print (directly on the board): "IceCube Version 103" > > Coral-P (Rev 5.0). I am using the 2.4 kernel from denx.de and > > Our kernel does not include any support for the EP5200 board. I checked it out from CVS, configured it, and it works (besides the X11 thing). > > succesfully installed gentoo-ppc on nfs. The framebuffer works, I get > > a login prompt on the monitor. > > > > Now I compiled x.org-6.8.2 (gentoo -r4) and the mb86290 driver from > > denx.de. Unfortunately, it does not work and I get a segmentation > > fault when trying to startx. strace produces the output attached > > below. > > Please read the documentation that comes with the driver: > ftp://ftp.denx.de/pub/fujitsu/Coral-P/README.html That is what I already read in order to compile the driver. > Note that the driver was built and tested against xfree86-4.3.0; > don't expect the binary to work in a completely different X11 > release. You wil have to rebuild (and eventually adapt) the driver > for your environment. I did not use the prebuilt binaries, but I was able to compile the driver within my x.org tree. (I had to adapt the Imakefiles by myself, the provided ones were too different from the originals.) In the meantime, I can provide you with further debugging information: from Xorg.0.log: == (II) MB86290(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Dashed Lines (II) MB86290(0): Acceleration enabled fbdevHW: LoadPalette 0 (II) MB86290(0): fbdevHWLoadPalette succeeded == The last line is a message that I added. Since the output stops at that point, it must be the next call that fails (mb86290_driver.c:604): if (!xf86I2CProbeAddress(fPtr->I2C, I2C_SAA7113)) return FALSE; May that be a problem with the i2c driver in the kernel which does not exactly fit with my board? The following message also appears in Xorg.0.log, some lines above: (II) MB86290(0): I2C bus "MB86290 I2C bus" removed. Thanks in advance for any hint that you can give me. Best regards, Matthias
Segmentation fault with X.org and Coral-P drivers
Dear Matthias, in message you wrote: > > I have been trying to get X.org running on a board called "Embedded > Planet EP5200C" (it seems to be a "Freescale Lite5200") and a Fujitsu Umm... no. Embedded Plaet and Freescale are two different companies, and EP5200 and Lite5200 are two different boards. > Coral-P (Rev 5.0). I am using the 2.4 kernel from denx.de and Our kernel does not include any support for the EP5200 board. > succesfully installed gentoo-ppc on nfs. The framebuffer works, I get > a login prompt on the monitor. > > Now I compiled x.org-6.8.2 (gentoo -r4) and the mb86290 driver from > denx.de. Unfortunately, it does not work and I get a segmentation > fault when trying to startx. strace produces the output attached > below. Please read the documentation that comes with the driver: ftp://ftp.denx.de/pub/fujitsu/Coral-P/README.html Note that the driver was built and tested against xfree86-4.3.0; don't expect the binary to work in a completely different X11 release. You wil have to rebuild (and eventually adapt) the driver for your environment. Feel free to contact me if you need help. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de What can it profit a man to gain the whole world and to come to his property with a gastric ulcer, a blown prostate, and bifocals? -- John Steinbeck, _Cannery Row_
"argument list too long"
Am Mittwoch, den 04.01.2006, 14:36 +0100 schrieb Wolfgang Denk: > In message <1136380085.15908.15.camel at localhost> you wrote: > > > > > + find $(FINDHPATH) \( -name SCCS -o -name .svn \) -prune -o -follow > > > -name \*.h ! -name modversions.h -print | xargs scripts/mkdep -- > > > > .hdepend > > > scripts/mkdep -- init/*.c > .depend > > > > Would'nt this overwrite .depend if xargs executes mkdep more than once? > > No, why should it? The filr eredirection happens just once, in the > shell, even before xargs gets executed. It does not matter how often > mkdep gets called then. Gah. You're right, of course ;/ > > > I'd suggest (beware, manually hacked diff ;): > > I have no idea what you're trying to fix or improve with this. "problem is in front of keyboard" Oder so. > > Best regards, > > Wolfgang Denk > -- Stefan Eletzhofer InQuant GmbH Bahnhofstra?e 11 D-88214 Ravensburg http://www.inquant.de http://www.eletztrick.de +49 (0) 751 35 44 112 +49 (0) 171 23 24 529 (Mobil) +49 (0) 751 35 44 115 (FAX) -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060104/e532f2cd/attachment.pgp
Cross Compiling driver for PPC
Hi > We are trying to port a newly developed device driver for powerPC . > We are unable to compile it for powerpc driver on Host platform. > Please give us the way to compile the device driver You need to cross compile, which means having a ggc for powerpc in addition to the gcc you have for your developpement machine. I do not know whether you will find it on the net, usualy you have to recompile gcc (and "ld" and "ar" and so on, the whole gcc toolchain I think) with specific options Then you will have a powerpc-linux-gcc (for example) which will be able to compile for powerpc then, you will have some modifications to do in the makefiles: look for this string: "CROSS_COMPILE" and set it to "powerpc-linux-" (or whatever is the prefix for you gcc). I also created a ".arch" file at the base of the source tree, containing "ppc" and some other modifications in makefiles, but I cannot tell you wich... and wether they are usefull. You'll have to try. Then add "ARCH=ppc" option to the make command when you want to compile your kernel for powerpc. Have fun. +++ Nathael PAJANI Ing?nieur CPE Lyon nathael.pajani at cpe.fr
"argument list too long"
In message <1136380085.15908.15.camel at localhost> you wrote: > > > + find $(FINDHPATH) \( -name SCCS -o -name .svn \) -prune -o -follow > > -name \*.h ! -name modversions.h -print | xargs scripts/mkdep -- > .hdepend > > scripts/mkdep -- init/*.c > .depend > > Would'nt this overwrite .depend if xargs executes mkdep more than once? No, why should it? The filr eredirection happens just once, in the shell, even before xargs gets executed. It does not matter how often mkdep gets called then. > I'd suggest (beware, manually hacked diff ;): I have no idea what you're trying to fix or improve with this. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de For every complex problem, there is a solution that is simple, neat, and wrong. - Mark Twain
"argument list too long"
Hi, Am Dienstag, den 03.01.2006, 15:17 +0100 schrieb Wolfgang Denk: > In message you wrote: > > > > After a few minutes of dependency creation, I get the following error > > "argument list too long": > > > > scripts/mkdep -- `find > > /usr/src/linuxppc_2_4_devel-2005-10-25-1440/include/asm > > /usr/src/linuxppc_2_4 > > _devel-2005-10-25-1440/include/linux > > /usr/src/linuxppc_2_4_devel-2005-10-25-1440/include/scsi /usr/s > > rc/linuxppc_2_4_devel-2005-10-25-1440/include/net > > /usr/src/linuxppc_2_4_devel-2005-10-25-1440/includ > > e/math-emu \( -name SCCS -o -name .svn \) -prune -o -follow -name \*.h ! > > -name modversions.h -print` > > > .hdepend > > scripts/mkdep: argument list too long > > make: *** [dep-files] Error 2 > > > > Can someone help me understand where that comes from? > > The error comes from the fact that the find command (the part in > `...` above) generates a long list of file names which exceeds some > buffer in your shell. > > > Does it have something to do with the fact that I work under WinXP + Cygwin? > > Yes. > > > No need to say that I am a newbie to the Linux world... help me, Wolfgang > > :-) > > I try. Find the statement in the Makefile and use xargs to avoid a > long argument list. Something like this might help: > > --- Makefile.ORIG 2006-01-03 15:15:48.0 +0100 > +++ Makefile 2006-01-03 15:16:55.0 +0100 > @@ -503,7 +503,7 @@ > ifdef CONFIG_MODVERSIONS > $(MAKE) update-modverfile > endif > - scripts/mkdep -- `find $(FINDHPATH) \( -name SCCS -o -name .svn \) > -prune -o -follow -name \*.h ! -name modversions.h -print` > .hdepend > + find $(FINDHPATH) \( -name SCCS -o -name .svn \) -prune -o -follow > -name \*.h ! -name modversions.h -print | xargs scripts/mkdep -- > .hdepend > scripts/mkdep -- init/*.c > .depend Would'nt this overwrite .depend if xargs executes mkdep more than once? I'd suggest (beware, manually hacked diff ;): --- Makefile.ORIG 2006-01-03 15:15:48.0 +0100 +++ Makefile2006-01-03 15:16:55.0 +0100 @@ -503,7 +503,7 @@ ifdef CONFIG_MODVERSIONS $(MAKE) update-modverfile endif - scripts/mkdep -- `find $(FINDHPATH) \( -name SCCS -o -name .svn \) -prune -o -follow -name \*.h ! -name modversions.h -print` > .hdepend + rm -f .depend && find $(FINDHPATH) \( -name SCCS -o -name .svn \) -prune -o -follow -name \*.h ! -name modversions.h -print | xargs scripts/mkdep -- > .hdepend scripts/mkdep -- init/*.c >> .depend > > ifdef CONFIG_MODVERSIONS > > > > Best regards, > > Wolfgang Denk > -- Stefan Eletzhofer InQuant GmbH Bahnhofstra?e 11 D-88214 Ravensburg http://www.inquant.de http://www.eletztrick.de +49 (0) 751 35 44 112 +49 (0) 171 23 24 529 (Mobil) +49 (0) 751 35 44 115 (FAX) -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil Url : http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060104/3dc67a0a/attachment.pgp
Segmentation fault with X.org and Coral-P drivers
Hello everybody, I have been trying to get X.org running on a board called "Embedded Planet EP5200C" (it seems to be a "Freescale Lite5200") and a Fujitsu Coral-P (Rev 5.0). I am using the 2.4 kernel from denx.de and succesfully installed gentoo-ppc on nfs. The framebuffer works, I get a login prompt on the monitor. Now I compiled x.org-6.8.2 (gentoo -r4) and the mb86290 driver from denx.de. Unfortunately, it does not work and I get a segmentation fault when trying to startx. strace produces the output attached below. Can anybody give me a hint how to proceed? Regards, Matthias [...] mmap(NULL, 33554432, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x30042000 ioctl(6, FBIOGET_VSCREENINFO, 0x105dfa58) = 0 ioctl(6, FBIOPUT_VSCREENINFO, 0x105df9b8) = 0 ioctl(6, FBIOGET_FSCREENINFO, 0x105df974) = 0 ioctl(6, FBIOGET_VSCREENINFO, 0x105df9b8) = 0 ioctl(6, FBIOBLANK, 0x1)= 0 ioctl(6, FBIOPAN_DISPLAY, 0x105df9b8) = 0 write(0, "(==) MB86290(0): Backing store d"..., 40) = 40 write(0, "(II) MB86290(0): Using XFree86 A"..., 63) = 63 write(0, "\tScreen to screen bit blits\n", 28) = 28 write(0, "\tSolid filled rectangles\n", 25) = 25 write(0, "\t8x8 mono pattern filled rectang"..., 36) = 36 write(0, "\tIndirect CPU to Screen color ex"..., 40) = 40 write(0, "\tSolid Lines\n", 13) = 13 write(0, "\tDashed Lines\n", 14)= 14 write(0, "(II) MB86290(0): Acceleration en"..., 38) = 38 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 ioctl(6, FBIOPUTCMAP, 0x7930) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigaction(SIGSEGV, {SIG_IGN}, {0x100424d0, [SEGV], SA_RESTART}, 8) = 0 write(2, "\n *** If unresolved symbols we"..., 112 [...]
question about arch_initcall()
Hi all I would like to know how this macro is used, and when is called the function registered with it. thanks for all. Nathael PAJANI Ing?nieur CPE Lyon nathael.pajani at cpe.fr
question about arch_initcall()
Its like any other init call. As for order look at include/linux/init.h core_initcall() first and late_initcall() last. There is no guarntee of the order in which functions are called inside one group. - kumar On Jan 4, 2006, at 4:04 AM, Nathael Pajani wrote: > Hi all > > I would like to know how this macro is used, and when is called the > function registered with it. > > thanks for all. > > > > Nathael PAJANI > Ing?nieur CPE Lyon > nathael.pajani at cpe.fr > ___ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Problems starting /init
I have a kernel for a new board (Linux 2.6.14.5, Pico E12/Xilinx V4 PPC405) booting to the point of starting /init. /init appears to be getting loaded correctly - the execve call seems happy. But I get no output on the console. I have tried: executing sys_write(1,"Test",4); inside init/main.c immediately before starting /init - works fine. starting a "hello World" application written in PPC asm as /init - works fine. The kernel panics on exit but that is normal, /init is not supposed to exit. starting a c "Hello World" application that uses glibc, fputs, printf, fwrite, to display a string - again works fine. But I can not get busybox to output a thing either run as /init or run as /bin/sh. I have aslo tried /bin/sash - no output. I have even cross compiled sash - with all kinds of "I am here" debugging scattered through main(), If I runn it on a powerbook, I get what I expect. If I run it as /bin/sh on the e12 I get no output. Does anyone even have any ideas what I can look at ?
[RFC] Pico E12 (Xilinx V4) patches to 2.6.15
Some sympathy and patience please. This is my first attempt to post a patch. Many aspects are working. A few listed below, are not. This is against git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Signed-off-by: David H. Lynch Jr. I could not figure out how to seek to the 2.6.14 tag so it is against HEAD/2.6.15 I am also presuming that git diff produces a unified diff. I do not try to read diffs - I typically do my diff/merges with vim, but it looks about right to me. There are basically 5 parts, and I have no idea how to easily separate the pieces: 1). Separating the Xilinx Virtex II Pro from the Xilinx Virtex IV. I believe Grant and others have done this too, and this may conflict. Most of these changes were "borrowed" from some 2.4 Linux stuff I got from Xilinx. 2). Pico E12 specific items. 3). Implementation of the Xilinx UartLite serial port(s). 4). Implementation of a pseudo serial port(s) driver for the Pico Keyhole port. The keyhole is a port-port interface between the E12 and a host computer over the CF connector. 5). a collection of flyspecks of debugging code scattered all over. Status/Overview: The Pico E12 is a Virtex IV/PPC405 implemented on a CF card. The objective is to leave as much of the FPGA free for the development of application specific logic. Pico provides their own SDK that includes Both windows and Linux host/development software. That software impliments a filesystem on the E12 flash, as well as loading and executing FPGA .bit files, and .elf files. The kernel built from this patch: will load with a modified version of the standard Pico loader - either they are including my trivial modifications, or I am working on moving them into the kernel boot code. Runs on the Xilinx V4/PPC405 in the current E12's. Requires an FPGA image with only the PPC405 and either the Xilinx UartLite or the Pico Keyhole. Use of the Xilinx PIC is optional, and is currently controlled by the xparameter_pico-e12.h file At this instant everything works up through and including loading /init (or a standalone shell). Executing init or a standalone shell does not appear to work - or more accurately console IO ceases without explanation when either /init or a shell start. Console input from the Keyhole port does not work - neither the host side not the kernel side are implemented. Console input from the Uartlite is pretty much untested. Boot/debugging "console" support for both the UartLite and Keyhole are implemented to the same level as similar facilities exist for the 8250. diff --git a/README.pico b/README.pico new file mode 12 index 000..3daad5a --- /dev/null +++ b/README.pico @@ -0,0 +1 @@ +pico/README.pico \ No newline at end of file diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig index cc3f64c..7c4318a 100644 --- a/arch/ppc/Kconfig +++ b/arch/ppc/Kconfig @@ -53,7 +53,7 @@ menu "Processor" choice prompt "Processor Type" - default 6xx + default 4xx config 6xx bool "6xx/7xx/74xx/52xx/82xx/83xx" diff --git a/arch/ppc/boot/common/misc-common.c b/arch/ppc/boot/common/misc-common.c index e79e6b3..a50762a 100644 --- a/arch/ppc/boot/common/misc-common.c +++ b/arch/ppc/boot/common/misc-common.c @@ -57,10 +57,15 @@ static int _cvt(unsigned long val, char void _vprintk(void(*putc)(const char), const char *fmt0, va_list ap); unsigned char *ISA_io = NULL; +#ifdef CONFIG_PICO_E12 +unsigned int *ISA_iow = NULL; +#endif #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \ || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \ - || defined(CONFIG_SERIAL_MPSC_CONSOLE) + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \ + || defined(CONFIG_SERIAL_UARTLITE_CONSOLE)\ + || defined(CONFIG_SERIAL_KEYHOLE_CONSOLE) extern unsigned long com_port; extern int serial_tstc(unsigned long com_port); @@ -83,7 +88,9 @@ int tstc(void) { #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \ || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \ - || defined(CONFIG_SERIAL_MPSC_CONSOLE) + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \ + || defined(CONFIG_SERIAL_UARTLITE_CONSOLE) \ + || defined(CONFIG_SERIAL_KEYHOLE_CONSOLE) if(keyb_present) return (CRT_tstc() || serial_tstc(com_port)); else @@ -98,7 +105,9 @@ int getc(void) while (1) { #if defined(CONFIG_SERIAL_CPM_CONSOLE) || defined(CONFIG_SERIAL_8250_CONSOLE) \ || defined(CONFIG_SERIAL_MPC52xx_CONSOLE) \ - || defined(CONFIG_SERIAL_MPSC_CONSOLE) + || defined(CONFIG_SERIAL_MPSC_CONSOLE) \ + || defined(CONFIG_SERIAL_UARTLITE_CONSOLE) \ + || defined(CONFIG_SERIAL_KEYHOLE_CONSOLE) if (serial_tstc(com_port)) return (serial_getc(co