From BowTieVette at aol.com Wed Mar 9 09:32:07 2005 From: BowTieVette at aol.com (BowTieVette at aol.com) Date: Wed, 09 Mar 2005 10:32:07 -0500 Subject: [Efi332] Uploaded files Message-ID: <030F0A03.0267D268.369F2C36@aol.com> Doug, Unfortunately the diy-efi server is having some admin issues so nobody can access your files. If you would, please email them to me directly and I will get them posted. jc I just uploaded the source package for the tuning program as zut-1.0.tar.gz, and our efi332 program source as efi332-udsae-2005-code.tar.gz. Both are in the incoming directory. --Doug Brunner From Steve.Ravet at arm.com Wed Mar 9 10:40:19 2005 From: Steve.Ravet at arm.com (Steve Ravet) Date: Wed, 9 Mar 2005 10:40:19 -0600 Subject: [Efi332] lists back on Message-ID: The server was upgraded and moved to a different network which caused some problems. Everything should be back to normal. --steve -- Steve Ravet steve.ravet at arm.com ARM,Inc. www.arm.com From Steve.Ravet at arm.com Wed Mar 9 10:50:43 2005 From: Steve.Ravet at arm.com (Steve Ravet) Date: Wed, 9 Mar 2005 10:50:43 -0600 Subject: [Efi332] list subscriptions Message-ID: I think the version of mailman was upgraded, and at least one person has written that they got switched from digest to direct. If you need to change your subscription options please visit the pages below as appropriate: http://lists.diy-efi.org/mailman/listinfo/diy_efi/ http://lists.diy-efi.org/mailman/listinfo/gmecm/ http://lists.diy-efi.org/mailman/listinfo/efi332/ http://lists.diy-efi.org/mailman/listinfo/wbo2/ Put your email address into the very last field, where the button says "unsubscribe or edit options". You may need your password... you do have it written down in a safe place, right? If not the lists send them out monthly so you should be able to dig through your trash and find it... you don't ever empty your trash folder, do you? Or the list server will email you a new password. --steve -- Steve Ravet steve.ravet at arm.com ARM,Inc. www.arm.com From Steve.Ravet at arm.com Thu Mar 10 23:45:30 2005 From: Steve.Ravet at arm.com (Steve Ravet) Date: Thu, 10 Mar 2005 23:45:30 -0600 Subject: [Efi332] admin: list passwords Message-ID: A couple of users who tried their passwords have reported they don't work. Apparently mailman generated all new passwords when it was re-installed. If you need to change your account options you'll have to use the "mail me my password" button. You can get there, for each list, by following the "how to subscribe" link. --steve -- Steve Ravet steve.ravet at arm.com ARM,Inc. www.arm.com From sailors3 at comcast.net Sat Mar 12 22:49:06 2005 From: sailors3 at comcast.net (David Eicher) Date: Sat, 12 Mar 2005 20:49:06 -0800 Subject: [Efi332] GNU errors In-Reply-To: <5.2.1.1.0.20050311164902.02645cb8@mail.compusmart.ab.ca> Message-ID: Hi Andrei, I guess I got a little too excited too soon! 8-( While it is true that using this technique does get the macros expanded, when the assembler runs it complains about all the "tmp" and "reg" parameters that are being passed into these functions: Inline void archWriteEIBADR(UWord32 register reg) { Asm ("mtspr %0,reg" : : "g" (ARCH_EIBADR)); } Inline UWord32 archReadEIBADR(void) { Register UWord32 tmp; Asm ("mfspr tmp,%0" : : "g" (ARCH_EIBADR)); Return (tmp); } This code triggers these errors from GNU assembler: 5xx_board_init.s:516: Error: unsupported relocation against reg 5xx_board_init.s:524: Error: unsupported relocation against tmp The assembly code looks like this in the 5xx_board_init.s file: .align 2 .globl archWriteEIBADR .type archWriteEIBADR, @function archWriteEIBADR: mtspr 529,reg blr .size archWriteEIBADR, .-archWriteEIBADR .align 2 .globl archReadEIBADR .type archReadEIBADR, @function archReadEIBADR: stwu 1,-16(1) mfspr tmp,529 lwz 0,8(1) mr 3,0 addi 1,1,16 blr .size archReadEIBADR, .-archReadEIBADR So, it appears the issue is related to declaring tmp and reg to be of type "register". Here's the list file output for these two routines: 549 .globl archWriteEIBADR 550 .type archWriteEIBADR, @function 551 archWriteEIBADR: 552 ???? 7C1183A6 mtspr 529,reg 553 ???? 4E800020 blr 554 .size archWriteEIBADR, .-archWriteEIBADR 555 .align 2 556 .globl archReadEIBADR 557 .type archReadEIBADR, @function 558 archReadEIBADR: 559 ???? 9421FFF0 stwu 1,-16(1) 560 ???? 7C1182A6 mfspr tmp,529 561 ???? 80010008 lwz 0,8(1) 562 ???? 7C030378 mr 3,0 563 ???? 38210010 addi 1,1,16 564 ???? 4E800020 blr 565 .size archReadEIBADR, .-archReadEIBADR The assembler can't deal with "mfspr tmp,529", it needs "mfspr r5,529" for example. So I understand what the problem is, but don?t know what to do about it. Suggestions? Thanks much for your help so far! Dave ----Original Message----- From: Andrei Chichak [mailto:agchichak at compusmart.ab.ca] Sent: Friday, March 11, 2005 3:55 PM To: David Eicher Subject: RE: Re: [Efi332] GNU errors Okay, assuming that the problem was the substitution of parameters into asm("blah") statements, the following will work #define number 0x00001000 #define ARCH_ICTRL 0x00080000 #define ARCH_MSR_ME 0x00001000 #define ARCH_MSR_RI 0x00000002 void usr_init() { int index; asm ("mfspr r5, %0" : : "g" (ARCH_ICTRL)); index = (int) number; index = index + 5; asm ("ori r5,r5,%0" : : "g" (ARCH_MSR_ME | ARCH_MSR_RI)); } Since there isn't really a need to make r5 into a parameter, I encoded it right in the command. The stuff dealing with defines is taken care of using the positional parameter stuff. That syntax is usually used to access variables in C. If you declared something register int fu, then you could use "r" (fu). But the existence of r5 is hidden from you by the compiler and by dropping down to assembly becomes available (sort of), but the asm structure with the parameter substitution seems to happen at the C level (where r5 isn't available) instead of at the assembler level (where it would be available). I hope this helps, Andrei ------------------------------ Andrei Chichak 4024-120 Street (780)434-6266 Edmonton, Alberta agchichak at compusmart.ab.ca Canada T6J 1X8 Lat: 53? 28' 40" N Lon: 113? 32' 27" W From sailors3 at comcast.net Tue Mar 15 08:11:13 2005 From: sailors3 at comcast.net (David Eicher) Date: Tue, 15 Mar 2005 06:11:13 -0800 Subject: [Efi332] xfi555 Progress In-Reply-To: <410-22005354145412700@earthlink.net> Message-ID: Hello, Due to much help from many people, I have just about completed compiling the MPC500_Quick_Start software from Motorola for use on the MPC555/565 controllers (using GNU environment). I'm just working on a little test program to get this environment up and running, I now have 19 object files, and believe I'm very close to having an executable. But..., there is a file init.c that includes header files fileio.h and memfile.h that won't compile because these header files are nowhere to be found on my hard disk (not in the quickstart package). I'm not sure that I need this file init.c, I'm in the process of searching to discover why it is even considered necessary (where it is called). UltraEdit just reported that the function in init.c (init_main_guts) does not appear in any other files. Hmmm, I'll have to figure out what to do about this. If anyone is familiar with this init.c or those header files, please let me know. Thanks. But, anyway, I'm getting close to have some code to run! Regards, Dave From BowTieVette at aol.com Wed Mar 16 06:53:03 2005 From: BowTieVette at aol.com (BowTieVette at aol.com) Date: Wed, 16 Mar 2005 07:53:03 EST Subject: [Efi332] xfi555 Progress Message-ID: I think we should rename this list "Dave's Excellent Adventure" :-o. Seriously, I'm impressed that you stuck with it, its not easy. fwiw, I do not use init.c at all, I think you may have taken it from one of the Diab examples. In a message dated 3/15/2005 9:10:07 AM Eastern Standard Time, sailors3 at comcast.net writes: Hello, Due to much help from many people, I have just about completed compiling the MPC500_Quick_Start software from Motorola for use on the MPC555/565 controllers (using GNU environment). I'm just working on a little test program to get this environment up and running, I now have 19 object files, and believe I'm very close to having an executable. But..., there is a file init.c that includes header files fileio.h and memfile.h that won't compile because these header files are nowhere to be found on my hard disk (not in the quickstart package). I'm not sure that I need this file init.c, I'm in the process of searching to discover why it is even considered necessary (where it is called). UltraEdit just reported that the function in init.c (init_main_guts) does not appear in any other files. Hmmm, I'll have to figure out what to do about this. If anyone is familiar with this init.c or those header files, please let me know. Thanks. But, anyway, I'm getting close to have some code to run! Regards, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050316/e940605a/attachment.html From sailors3 at comcast.net Sun Mar 20 09:18:24 2005 From: sailors3 at comcast.net (David Eicher) Date: Sun, 20 Mar 2005 07:18:24 -0800 Subject: [Efi332] Update: GNU tools and Motorola MPC555 Quick Start Message-ID: Hello list, I've struggled for quite some time now and am close to having my first application built on the EABI API. Everything was compiling and I was having linker troubles, in my efforts to resolve the linker issues (undefined symbols), I've had to add code (startup.c). So I'm now back to compilation issues. Startup.c compiles okay but when the resultant asm code is submitted to the assembler I get four errors. I'm working on figuring that out, the errors are related to the "asm(" ");" statements in startup.c. I'm really confused about what to do with the initialization of the stack pointer. The EABI API establishes the following conventions: Register: r1 stack pointer r3 SDA2 data pointer r13 SDA data pointer The GNU extended ASM feature allows me to use registers, but it doesn't allow me to choose which one I want (that I've discovered so far). So I'm struggling to figure out how to init all these pointers and have it all work. I'm just a few errors away from having an executable, I can taste victory right around the corner here! Just gotta keep pushing. Regards, Dave