compiling ELDK3 microwindows source paket
In message <41A24026.5070908 at gmx.net> you wrote:
>
> I want to rebuild the ELDK3 (www.denx.de) microwindows source paket
> (host system: i386 pc running SUSE 9.0; target system: embedded ppc405;
> CROSS_COMPILE=ppc_4xx-).
>
> For it I installed the source in the ELDK3 directory and tried to
> rebuild the paket with ${CROSS_COMPILE}rpmbuild -ba microwindows.spec.
> This gave some errors because the host and not the cross compiler was used.
There is a detailed description how to do this inthe ELDK manual;
please see
http://www.denx.de/twiki/bin/view/DULG/ELDKRebuildingComponents#Section_3.7.2.
Please pay special attention to the two requirements shown at the end
of this paragraph.
> After I changed the file microwindows-0.90-config.ppc.patch from
Don't do this, it will break the build.
> What can it be?
User error. Please RTFM.
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
"There's only one kind of woman ..." "Or man, for that matter. You
either believe in yourself or you don't."
-- Kirk and Harry Mudd, "Mudd's Women", stardate 1330.1
compiling ELDK3 microwindows source paket
Hello,
I want to rebuild the ELDK3 (www.denx.de) microwindows source paket
(host system: i386 pc running SUSE 9.0; target system: embedded ppc405;
CROSS_COMPILE=ppc_4xx-).
For it I installed the source in the ELDK3 directory and tried to
rebuild the paket with ${CROSS_COMPILE}rpmbuild -ba microwindows.spec.
This gave some errors because the host and not the cross compiler was used.
After I changed the file microwindows-0.90-config.ppc.patch from
...
-POWERPCTOOLSPREFIX = powerpc-linux-
+POWERPCTOOLSPREFIX =
SHTOOLSPREFIX= sh-linux-gnu
...
to
...
-POWERPCTOOLSPREFIX = powerpc-linux-
+POWERPCTOOLSPREFIX = ppc_4xx-
SHTOOLSPREFIX= sh-linux-gnu
...
the command make use of the cross tools.
Now it rebuild the rpm paket but the strip command gives the warning:
strip: Warning: Output file cannot represent architecture UNKNOWN!
and the programms are not executable (on the ppc405 board) after
installing the rpm paket.
What can it be?
Regards,
Dieter
Here an extract from the build process:
wi at wi2:~/PPC/ELDK3/usr/src/denx/SPECS> ${CROSS_COMPILE}rpmbuild -ba
microwindows.spec
Executing(%prep): /bin/sh -e /home/wi/PPC/ELDK3/var/tmp/rpm-tmp.50044
+ umask 022
+ cd /home/wi/PPC/ELDK3/usr/src/denx/BUILD
+ cd /home/wi/PPC/ELDK3/usr/src/denx/BUILD
+ rm -rf microwindows-0.90
+ /bin/gzip -dc
/home/wi/PPC/ELDK3/usr/src/denx/SOURCES/microwindows-0.90.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd microwindows-0.90
+ echo 'Patch #0 (microwindows-0.90-noroot.patch):'
Patch #0 (microwindows-0.90-noroot.patch):
+ patch -p1 -s
+ echo 'Patch #1 (microwindows-0.90-bugfix.ppc.patch):'
Patch #1 (microwindows-0.90-bugfix.ppc.patch):
+ patch -p1 -s
+ echo 'Patch #2 (microwindows-0.90-config.ppc.patch):'
Patch #2 (microwindows-0.90-config.ppc.patch):
+ patch -p1 -s
+ echo 'Patch #3 (microwindows-0.90_thick_lines.patch):'
Patch #3 (microwindows-0.90_thick_lines.patch):
+ patch -p1 -s
+ echo 'Patch #4 (microwindows-0.90-stretch.patch):'
Patch #4 (microwindows-0.90-stretch.patch):
+ patch -p1 -s
+ echo 'Patch #5 (microwindows-0.90-tsc2000.patch):'
Patch #5 (microwindows-0.90-tsc2000.patch):
+ patch -p1 -s
+ echo 'Patch #6 (microwindows-0.90-config-fonts.patch):'
Patch #6 (microwindows-0.90-config-fonts.patch):
+ patch -p1 -s
+ echo 'Patch #7 (microwindows-0.90-mtest-fix.patch):'
Patch #7 (microwindows-0.90-mtest-fix.patch):
+ patch -p1 -s
+ exit 0
Executing(%build): /bin/sh -e /home/wi/PPC/ELDK3/var/tmp/rpm-tmp.89079
+ umask 022
+ cd /home/wi/PPC/ELDK3/usr/src/denx/BUILD
+ cd microwindows-0.90
+ cd src
+ HOSTCC=/usr/bin/gcc -B/usr/bin/
+ make -e
make -C drivers
make[1]: Entering directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers'
Updating dependencies in
/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers ...
/bin/sh -ec '/usr/bin/gcc -B/usr/bin/ -MM
-DMWPIXEL_FORMAT=MWPF_TRUECOLOR565 -DVTSWITCH=1 -DHAVE_FILEIO
-DHAVE_FNT_SUPPORT=1 -DFNT_FONT_DIR="\""/usr/microwindows-fonts/bdf""\"
-DHAVE_PCF_SUPPORT=1 -DPCF_FONT_DIR="\""/usr/microwindows-fonts/pcf""\"
-DHAVE_HZK_SUPPORT=1
-DHZK_FONT_DIR="\""/usr/microwindows-fonts/chinese""\"
-DHAVE_EUCJP_SUPPORT=1
-DEUCJP_FONT_DIR=\""/usr/microwindows-fonts/japanese"\"
-DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_PNM_SUPPORT=1
-DHAVE_XPM_SUPPORT=1 -DHAVETEXTMODE=1 -DTHREADSAFE=1 -DERASEMOVE=1
-DUPDATEREGIONS=1 -DDEBUG=1 -DLINUX=1 -DUNIX=1 -DARCH_LINUX_POWERPPC=1
-DMW_CPU_BIG_ENDIAN=1 -I.
-I/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/include
fblin8.c fblin16.c fblin24.c fblin32.c fblin32alpha.c genmem.c fb.c
fblin1.c fblin2.c genfont.c scr_fb.c fbportrait_left.c
fbportrait_right.c fbportrait_down.c fblin4.c vtswitch.c mou_ser.c
kbd_tty.c \
| sed '\''s/\(\)\.o[ :]*/\1.o \.depend : $(TOP)\/config /g'\'' > .depend; \
[ -s .depend ] || rm -f .depend'
make[1]: Leaving directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers'
make[1]: Entering directory
`/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/drivers'
Compiling fblin8.c ...
ppc_4xx-gcc -c -DMWPIXEL_FORMAT=MWPF_TRUECOLOR565 -DVTSWITCH=1
-DHAVE_FILEIO -DHAVE_FNT_SUPPORT=1
-DFNT_FONT_DIR="\""/usr/microwindows-fonts/bdf""\" -DHAVE_PCF_SUPPORT=1
-DPCF_FONT_DIR="\""/usr/microwindows-fonts/pcf""\" -DHAVE_HZK_SUPPORT=1
-DHZK_FONT_DIR="\""/usr/microwindows-fonts/chinese""\"
-DHAVE_EUCJP_SUPPORT=1
-DEUCJP_FONT_DIR=\""/usr/microwindows-fonts/japanese"\"
-DHAVE_BMP_SUPPORT=1 -DHAVE_GIF_SUPPORT=1 -DHAVE_PNM_SUPPORT=1
-DHAVE_XPM_SUPPORT=1 -DHAVETEXTMODE=1 -DTHREADSAFE=1 -DERASEMOVE=1
-DUPDATEREGIONS=1 -DDEBUG=1 -DLINUX=1 -DUNIX=1 -DARCH_LINUX_POWERPPC=1
-DMW_CPU_BIG_ENDIAN=1 -fpic -I.
-I/home/wi/PPC/ELDK3/usr/src/denx/BUILD/microwindows-0.90/src/include
-msoft-float -Wall -Wpointer-arith -O3 -ggdb -o fblin8.o fblin8.c
Compiling fblin16.c ...
...
Compiling nanox.c ...
ppc_4xx-gcc -c -DNANOX=1 -DMWPIXEL_FORMAT=MWPF_TRUECOLOR565
-DVTSWITCH=1 -DHAVE_FILEIO -DHA
[PATCH][PPC32] Marvell host bridge support (mv64x60)
"Mark A. Greer" wrote: > > Andrew Morton wrote: > > >Anyway, I'll stick this as-is in -mm. Feel free to send an incremental > >patch, or a replacement. > > > > Here is an incremental patch [hopefully] with your concerns addressed. OK, thanks. I added this to the queue for post-2.6.10. I'll assume that silence means assent from the rest of the ppc team ;) (Patches are at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-marvell-host-bridge-support-mv64x60.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-support-for-marvell-ev-64260-bp-eval-platform.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc2/2.6.10-rc2-mm3/broken-out/ppc32-support-for-artesyn-katana-cpci-boards.patch
[PATCH][PPC32] Marvell host bridge support (mv64x60)
Andrew Morton wrote: >Anyway, I'll stick this as-is in -mm. Feel free to send an incremental >patch, or a replacement. > Here is an incremental patch [hopefully] with your concerns addressed. Note that the arch/ppc/boot code is not kernel code and only exists for a short period of time before execution jumps to the kernel. Please let me know if you have any more concerns. Signed-off-by: Mark A. Greer -- -- next part -- An embedded and charset-unspecified text was scrubbed... Name: mv64x60_2.patch Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20041122/e9de0d7d/attachment.txt
(no subject)
Ratin, I would suggest looking at Dan Kegel's crosstool @ http://www.kegel.com/crosstool/. Very helpful in pairing various parts of the GNU toolchain together to get a working version. For MPC5200 you want the ppc750 build. - kumar On Nov 22, 2004, at 1:23 PM, Ratin Kumar wrote: > Hi, > > I am trying to build a toolchain for MPC5200 using gcc 3.4.1. > > The bootstrap compiler build fails with a complain that it could not > locate "signal.h". This happens even though I have the kernel headers > (with signal.h) installed. A quick search on google shows that some > other people have also run into this issue, although no > patches/sloution appears. Any ideas?? > > Also, has anyone tried using 3.4.1 compiler for kernel 2.4.23 > > What are the matching glibc and binutils to use with 3.4.1?? Any > patches?? > > Thanks, > Rk. >
MPC82xx -- DPRAM1
On Nov 19, 2004, at 9:25 AM, Rune Torgersen wrote: > Send a patch to fix this in the driver. I think most people on this > list > would like the seriaql drivers to be totally independent of the > bootloader (no matter what it is). The serial driver is totally independent of the bootloader. It configures the SMC from scratch and assumes nothing of the bootloader. However, if the bootloader configures itself as Linux does, then other functions like early kgdb over serial port work properly. -- Dan
[PATCH][PPC32] Marvell host bridge support (mv64x60)
Christoph Hellwig wrote: >Just looking through this and you should share some more code with mips, >e.g. the mavell register layout should move from asm-mips/marvell.h and >your file to linux/marvell.h or something, especially as another ppc >plattform (pegasosII) needs it aswell. > Yes, and there is already include/linux/mv643xx.h that has a bunch of 64340 definitions which share offset with the 64360 (and some with the 64260). However, to be correct, there needs to be a lot of munging. mv643xx.h should be renamed to mv64xxx.h and all of the MV64340 macros need to be renamed as well. This ripples into the mips code which I didn't want to battle with right now. I would prefer that this patch go in and then submit a separate patch that fixes and combines the hdr files & macros they contain. Doing it that way, there is one patch for the ppc bridge support and one patch for the hdr file clean up. That's cleaner than mixing the two (IMHO). It is on the todo list. Mark
[PATCH][PPC32] Marvell host bridge support (mv64x60)
Andrew Morton wrote:
>"Mark A. Greer" wrote:
>
>
>>This patch adds core support for a line of host bridges from Marvell
>>(formerly Galileo). This code has been tested with a GT64260a,
>>GT64260b, MV64360, and MV64460. Patches for platforms that use these
>>bridges will be sent separately.
>>
>>
>>
>
>Shouldn't these guys:
>
>
>+ u32 cpu2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
>+ { MV64x60_CPU2MEM_0_BASE, MV64x60_CPU2MEM_0_SIZE },
>+ { MV64x60_CPU2MEM_1_BASE, MV64x60_CPU2MEM_1_SIZE },
>+ { MV64x60_CPU2MEM_2_BASE, MV64x60_CPU2MEM_2_SIZE },
>+ { MV64x60_CPU2MEM_3_BASE, MV64x60_CPU2MEM_3_SIZE }
>+ };
>+ u32 com2mem_tab[MV64x60_CPU2MEM_WINDOWS][2] = {
>+ { MV64360_MPSC2MEM_0_BASE, MV64360_MPSC2MEM_0_SIZE },
>+ { MV64360_MPSC2MEM_1_BASE, MV64360_MPSC2MEM_1_SIZE },
>+ { MV64360_MPSC2MEM_2_BASE, MV64360_MPSC2MEM_2_SIZE },
>+ { MV64360_MPSC2MEM_3_BASE, MV64360_MPSC2MEM_3_SIZE }
>+ };
>+ u32 dram_selects[MV64x60_CPU2MEM_WINDOWS] = { 0xe, 0xd, 0xb, 0x7 };
>
>be static, and maybe __devinitdata? Right now, the CPU has to populate
>them by hand at runtime.
>
Yes. I'll fix that.
>
>+wait_for_ownership(int chan)
>+{
>+ int i;
>+
>+ for (i=0; i+ if ((MV64x60_REG_READ(sdma_regs[chan].sdcm) &
>+ SDMA_SDCM_TXD) == 0)
>+ break;
>+
>+ udelay(1000);
>
>ow, big busywait. Can't use a sleep in here? I guess not :(
>
This code is in the ppc bootwrapper which is glue code to get the
hardware (and bd_info, etc.) from whatever state the f/w left it in into
something the kernel can work with. IOW, its not in the kernel and
there is no sleep mechanism...or even a thread/process entity to put to
sleep.
>+ * arch/ppc/boot/simple/mv64x60_tty.c
>
>hm. Normally we put arch-specific drivers like this into drivers/serial
>and do the appropriate Kconfig work. Is there a reason why this serial
>driver is buried under arch/ppc?
>
It isn't a part of the kernel so I don't think it belongs in
drivers/serial. This particular serial driver is required for cmd_line
editing when booting a zImage.
>+#include "../../../../drivers/serial/mpsc_defs.h"
>
>erk.
>
Ah, yeah, I'll fix that too :)
>
>+struct mv64x60_rx_desc {
>+ volatile u16 bufsize;
>+ volatile u16 bytecnt;
>+ volatile u32 cmd_stat;
>+ volatile u32 next_desc_ptr;
>+ volatile u32 buffer;
>+};
>+
>+struct mv64x60_tx_desc {
>+ volatile u16 bytecnt;
>+ volatile u16 shadow;
>+ volatile u32 cmd_stat;
>+ volatile u32 next_desc_ptr;
>+ volatile u32 buffer;
>+};
>
>Do these need to be volatile? If so, it indicates that the driver is doing
>something wrong.
>
I didn't spend much time looking at this code. I'll clean it up.
>
>+gt64260_register_hdlrs(void)
>+{
>+ /* Register CPU interface error interrupt handler */
>+ request_irq(MV64x60_IRQ_CPU_ERR, gt64260_cpu_error_int_handler,
>+ SA_INTERRUPT, CPU_INTR_STR, 0);
>
>request_irq() can fail.
>
OK.
>+int
>+mv64360_get_irq(struct pt_regs *regs)
>+{
>+ int irq;
>+ int irq_gpp;
>+
>+#ifdef CONFIG_SMP
>+ /*
>+ * Second CPU gets only doorbell (message) interrupts.
>+ * The doorbell interrupt is BIT28 in the main interrupt low cause reg.
>+ */
>+ int cpu_nr = smp_processor_id();
>
>This function has no callers, so I am unable to determine whether it is
>called from non-preemptible code. If it is called from preemptible code
>then that smp_processor_id() is buggy, because you can switch CPUs at any
>time.
>
Its called via ppc_md.get_irq() (see arch/ppc/kernel/irq.c:do_IRQ()).
ppc_md.get_irq is set up in the platform files.
>+static struct platform_device mpsc_shared_device = { /* Shared device */
>+ .name = MPSC_SHARED_NAME,
>+ .id = 0,
>+ .num_resources = ARRAY_SIZE(mv64x60_mpsc_shared_resources),
>+ .resource = mv64x60_mpsc_shared_resources,
>+ .dev = {
>+ .driver_data = (void *)&mv64x60_mpsc_shared_pd_dd,
>+ },
>+};
>
>The cast to void* is unnecessary.
>
OK.
>+ (void)mv64x60_setup_for_chip(&bh);
>
>how come you always stick that (void) in there?
>
I did that b/c the routine returns an 'int' but I'm ignoring it. I
probably shouldn't be ignoring it...
>
>+mv64x60_config_cpu2mem_windows(struct mv64x60_handle *bh,
>+ struct mv64x60_setup_info *si,
>+ u32 mem_windows[MV64x60_CPU2MEM_WINDOWS][2])
>+{
>+ u32 i, win;
>+ u32 prot_tab[] = {
>+ MV64x60_CPU_PROT_0_WIN, MV64x60_CPU_PROT_1_WIN,
>+ MV64x60_CPU_PROT_2_WIN, MV64x60_CPU_PROT_3_WIN
>+ };
>+ u32 cpu_snoop_tab[] = {
>+ MV64x60_CPU_SNOOP_0_WIN, MV64x60_CPU_SNOOP_1_WIN,
>+
MPC5200 target name
Is this -mppc=82xx?? -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20041122/cc757b10/attachment.htm
(no subject)
Hi, I am trying to build a toolchain for MPC5200 using gcc 3.4.1. The bootstrap compiler build fails with a complain that it could not locate "signal.h". This happens even though I have the kernel headers (with signal.h) installed. A quick search on google shows that some other people have also run into this issue, although no patches/sloution appears. Any ideas?? Also, has anyone tried using 3.4.1 compiler for kernel 2.4.23 What are the matching glibc and binutils to use with 3.4.1?? Any patches?? Thanks, Rk. -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20041122/dc2dabc6/attachment.htm
