From doug at udel.edu  Fri Jul  1 22:11:21 2005
From: doug at udel.edu (Doug Brunner)
Date: Fri, 01 Jul 2005 23:11:21 -0400
Subject: [Efi332] BDM troubles
Message-ID: <42C605D9.5000309@udel.edu>

I'm trying to start talking to my Phytec 555 board and having lots of 
trouble. It's on the Phytec development board, so I'm using their BDM, 
which I can't get GDB to interact with. I'm running all this under Linux.

What have the rest of you been using for BDM support?

       --Doug Brunner


From PaulHelmuth at SprintMail.com  Fri Jul  1 22:28:56 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Fri, 1 Jul 2005 22:28:56 -0500
Subject: [Efi332] BDM troubles
References: <42C605D9.5000309@udel.edu>
Message-ID: <011201c57eb6$2e352670$6b7ba8c0@p2450>

I'm (reasonably) sure everyone that has done anything with the Phytec 
development board has used the JTAG/BDM port.

Since you are using GDB, I assume that you are using the GCC tool chain. 
Since you are using that, I also assume that you are using the external BDM 
port. This means you have some BDM port interface (like a Wiggler).

So - you need to make sure that all of your pin-outs match between your BDM 
interface and the Phytec BDM port. As an example, two of the pins are 
reversed between the Phytec port and my Macraigor Wiggler. I have a note on 
James' 555 web page about that switch. Also, you need to follow Phytec's 
bulletin on setting the development board jumpers for using the external BDM 
port.

Other than that, everything should work - but I haven't used these tools 
with Linux.

-Paul


----- Original Message ----- 
From: "Doug Brunner" <doug at udel.edu>
To: <efi332 at diy-efi.org>
Sent: Friday, July 01, 2005 10:11 PM
Subject: [Efi332] BDM troubles


> I'm trying to start talking to my Phytec 555 board and having lots of 
> trouble. It's on the Phytec development board, so I'm using their BDM, 
> which I can't get GDB to interact with. I'm running all this under Linux.
>
> What have the rest of you been using for BDM support?
>
>       --Doug Brunner
> _______________________________________________
> Efi332 mailing list
> Efi332 at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/efi332
> 



From PaulHelmuth at SprintMail.com  Fri Jul  1 22:39:44 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Fri, 1 Jul 2005 22:39:44 -0500
Subject: [Efi332] HW Question (for JC)
References: <00ee01c57cf2$b272b940$6b7ba8c0@p2450>
	<8C74B2C7469CC18-CA0-7F5A@FWM-R26.sysops.aol.com>
Message-ID: <012001c57eb7$b35da1a0$6b7ba8c0@p2450>

Jeff,

Thanks!

I found the Panasonic devices at Digikey - they appear to be ideal for the application. The only problem for me is they also appear to be available in SMD only. After some searching, I found some units by Xicon (at Mouser) which are low ESR and come in an old fashioned package (with legs). The only thing is, I did have to bump up my capacitor value to 220 uf to be safely within the ESR at colder temperatures (not that this is really long term solution - but it doesn't hurt anything for that output cap to be bigger).

So, after everyone is back from the long holiday weekend and they ship my capacitors, I'll finally be ready to do my ignition-only testing (that is, if I have the crank trigger wheel mounted).

-Paul
  ----- Original Message ----- 
  From: bowtievette at aol.com 
  To: efi332 at diy-efi.org 
  Sent: Wednesday, June 29, 2005 8:44 PM
  Subject: Re: [Efi332] HW Question (for JC)


  Hi Paul,
  I would include the 47uF on the input side. I don't think you will have any problems with it running from the car's battery/alternator.
  On the output side, you're right, ESR values are typically not quoted in catalogs other than to say low ESR, so you usually have to dig up the datasheet(s) to get the tables for it. If you do a search for low ESR capacitor at digikey it will narrow the search to caps that advertise low ESR. Pick a 22 uF one from the selection table presented and follow it to the datasheet. For this application, aluminum electrolytics are common, and occasionally tantalums. Some folks recommend against using tantalums in power supplies since they have a tendency to blow up under rapid transient conditions. With the electrolytics, you may have to watch the temperature variation since the ESR varies quite a bit.
   
  -----Original Message-----
  From: Paul Helmuth <PaulHelmuth at SprintMail.com>
  To: efi332 at diy-efi.org
  Sent: Wed, 29 Jun 2005 16:37:06 -0500
  Subject: [Efi332] HW Question (for JC)


  Jeff,

  I managed to source a couple of National LM2940T (9volt output) regulators. I am hoping to use this part to power my Phytec development board from the car's 12v battery.

  The "Typical Application" section of the data sheet shows only two external components. 

  One is a .47 microfarad capacitor on V-in to ground. An asterisk note indicates that this is required if the regulator is located far from the "power supply filter". Which seems to imply that there should be some filtering in place between the battery and the regulator (though there is no diagram of what such a filter should look like).

  The second external component is a 22 microfarad (minimum) capacitor on V-out to ground. The interesting note on the output capacitor is that the equivalent series resistance is critical. Reading the performance characteristics table relating to the output capacitor ESR, I see that I need to use a capacitor with an ESR between .1 and 1 ohm. I have never seen ESR given for capacitors. Can you give me any pointers as to how I can determine and arrive at an acceptable ESR for the output capacitor(s)?

  Thanks,
  -Paul
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332


------------------------------------------------------------------------------


  _______________________________________________
  Efi332 mailing list
  Efi332 at diy-efi.org
  http://lists.diy-efi.org/mailman/listinfo/efi332
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050701/99a311af/attachment.html 

From doug at udel.edu  Sat Jul  2 10:51:00 2005
From: doug at udel.edu (Doug Brunner)
Date: Sat, 02 Jul 2005 11:51:00 -0400
Subject: [Efi332] BDM troubles
In-Reply-To: <011201c57eb6$2e352670$6b7ba8c0@p2450>
References: <42C605D9.5000309@udel.edu> <011201c57eb6$2e352670$6b7ba8c0@p2450>
Message-ID: <42C6B7E4.3080801@udel.edu>

My problems have been with GDB's support for the BDM interface. I'm 
actually using the Phytec board's internal BDM (parallel port on the 
board) rather than the 10-pin header for an external BDM, since my only 
BDM is a Tilbury unit from way back when that has been more than a 
little flaky.

As I understand it, GDB needs some kind of addon to talk to a BDM via 
the parallel port. I've tried MPCBDM as discussed on James' 555 Webpage, 
running gdb 5.0 (since that's the only version I've seen the patch for) 
as root, and it doesn't seem to accomplish anything--it just hangs when 
I try to connect to the board. What has everyone else been using?

       --Doug Brunner

Paul Helmuth wrote:

> I'm (reasonably) sure everyone that has done anything with the Phytec 
> development board has used the JTAG/BDM port.
>
> Since you are using GDB, I assume that you are using the GCC tool 
> chain. Since you are using that, I also assume that you are using the 
> external BDM port. This means you have some BDM port interface (like a 
> Wiggler).
>
> So - you need to make sure that all of your pin-outs match between 
> your BDM interface and the Phytec BDM port. As an example, two of the 
> pins are reversed between the Phytec port and my Macraigor Wiggler. I 
> have a note on James' 555 web page about that switch. Also, you need 
> to follow Phytec's bulletin on setting the development board jumpers 
> for using the external BDM port.
>
> Other than that, everything should work - but I haven't used these 
> tools with Linux.
>
> -Paul
>
>
> ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu>
> To: <efi332 at diy-efi.org>
> Sent: Friday, July 01, 2005 10:11 PM
> Subject: [Efi332] BDM troubles
>
>
>> I'm trying to start talking to my Phytec 555 board and having lots of 
>> trouble. It's on the Phytec development board, so I'm using their 
>> BDM, which I can't get GDB to interact with. I'm running all this 
>> under Linux.
>>
>> What have the rest of you been using for BDM support?
>>
>>       --Doug Brunner
>> _______________________________________________
>> Efi332 mailing list
>> Efi332 at diy-efi.org
>> http://lists.diy-efi.org/mailman/listinfo/efi332
>>
>
> _______________________________________________
> Efi332 mailing list
> Efi332 at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/efi332
>



From PaulHelmuth at SprintMail.com  Sat Jul  2 11:11:50 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Sat, 2 Jul 2005 11:11:50 -0500
Subject: [Efi332] BDM troubles
References: <42C605D9.5000309@udel.edu> <011201c57eb6$2e352670$6b7ba8c0@p2450>
	<42C6B7E4.3080801@udel.edu>
Message-ID: <013f01c57f20$c167bf10$6b7ba8c0@p2450>

I suspect (mind you, I don't have much to go on here) that your problem is 
related to trying to use Phytec's "built-in" interface with anything other 
than the Codewarrior software that they ship with it.

Of course, it should be possible to use that connection, but I think things 
are a whole LOT "cleaner" switching to their external BDM header. At least 
there you have all of the pins documented.

I use a Macraigor Wiggler to supply the BDM-to-parallel port interface and 
as I mentioned in my previous email, there is a link on James' web page that 
gives some direction for matching the Macraigor outputs with the Phytec 
external BDM header.

The Macraigor unit has been 100% reliable for me. It's not the fastest 
interface, (they also have faster ones - just more $$$) but it's pretty 
inexpensive.


----- Original Message ----- 
From: "Doug Brunner" <doug at udel.edu>
To: <efi332 at diy-efi.org>
Sent: Saturday, July 02, 2005 10:51 AM
Subject: Re: [Efi332] BDM troubles


> My problems have been with GDB's support for the BDM interface. I'm 
> actually using the Phytec board's internal BDM (parallel port on the 
> board) rather than the 10-pin header for an external BDM, since my only 
> BDM is a Tilbury unit from way back when that has been more than a little 
> flaky.
>
> As I understand it, GDB needs some kind of addon to talk to a BDM via the 
> parallel port. I've tried MPCBDM as discussed on James' 555 Webpage, 
> running gdb 5.0 (since that's the only version I've seen the patch for) as 
> root, and it doesn't seem to accomplish anything--it just hangs when I try 
> to connect to the board. What has everyone else been using?
>
>       --Doug Brunner
>
> Paul Helmuth wrote:
>
>> I'm (reasonably) sure everyone that has done anything with the Phytec 
>> development board has used the JTAG/BDM port.
>>
>> Since you are using GDB, I assume that you are using the GCC tool chain. 
>> Since you are using that, I also assume that you are using the external 
>> BDM port. This means you have some BDM port interface (like a Wiggler).
>>
>> So - you need to make sure that all of your pin-outs match between your 
>> BDM interface and the Phytec BDM port. As an example, two of the pins are 
>> reversed between the Phytec port and my Macraigor Wiggler. I have a note 
>> on James' 555 web page about that switch. Also, you need to follow 
>> Phytec's bulletin on setting the development board jumpers for using the 
>> external BDM port.
>>
>> Other than that, everything should work - but I haven't used these tools 
>> with Linux.
>>
>> -Paul
>>
>>
>> ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu>
>> To: <efi332 at diy-efi.org>
>> Sent: Friday, July 01, 2005 10:11 PM
>> Subject: [Efi332] BDM troubles
>>
>>
>>> I'm trying to start talking to my Phytec 555 board and having lots of 
>>> trouble. It's on the Phytec development board, so I'm using their BDM, 
>>> which I can't get GDB to interact with. I'm running all this under 
>>> Linux.
>>>
>>> What have the rest of you been using for BDM support?
>>>
>>>       --Doug Brunner
>>> _______________________________________________
>>> Efi332 mailing list
>>> Efi332 at diy-efi.org
>>> http://lists.diy-efi.org/mailman/listinfo/efi332
>>>
>>
>> _______________________________________________
>> Efi332 mailing list
>> Efi332 at diy-efi.org
>> http://lists.diy-efi.org/mailman/listinfo/efi332
>>
>
> _______________________________________________
> Efi332 mailing list
> Efi332 at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/efi332
> 



From bowtievette at aol.com  Sat Jul  2 11:58:33 2005
From: bowtievette at aol.com (bowtievette at aol.com)
Date: Sat, 02 Jul 2005 12:58:33 -0400
Subject: [Efi332] BDM troubles
In-Reply-To: <013f01c57f20$c167bf10$6b7ba8c0@p2450>
References: <42C605D9.5000309@udel.edu>
	<011201c57eb6$2e352670$6b7ba8c0@p2450>	<42C6B7E4.3080801@udel.edu>
	<013f01c57f20$c167bf10$6b7ba8c0@p2450>
Message-ID: <8C74D3E6A8C5E4F-B9C-A6DF@mblk-d33.sysops.aol.com>

The BDM interface built into the Phytec development board is functionally identical to the wiggler interface, if not completely identical. You should be able to connect using either interface so thats probably not your problem. 
 
One thing I found when investigating using gdb was that out of the box, it did not support a parallel interface to the BDM. It only supported the ethernet interface, so the only way I was able to get it to work was with Macraigor's OCDemon program which essentially echoes the ethernet port activity on the parallel port. Your gdb version may have parallel BDM support but thats something to verify.
 
As a stopgap, you might try using Macraigor's OCD Commander as they have a linux version for it. Thats probably not a final solution for you though since it only allows assembly level debugging. But it would get you connected so that you can load software at least. David Eicher is using commander I think and can probably help out with initialization scripts and such.
 
-----Original Message-----
From: Paul Helmuth <PaulHelmuth at SprintMail.com>
To: efi332 at diy-efi.org
Sent: Sat, 2 Jul 2005 11:11:50 -0500
Subject: Re: [Efi332] BDM troubles


I suspect (mind you, I don't have much to go on here) that your problem is related to trying to use Phytec's "built-in" interface with anything other than the Codewarrior software that they ship with it. 
 
Of course, it should be possible to use that connection, but I think things are a whole LOT "cleaner" switching to their external BDM header. At least there you have all of the pins documented. 
 
I use a Macraigor Wiggler to supply the BDM-to-parallel port interface and as I mentioned in my previous email, there is a link on James' web page that gives some direction for matching the Macraigor outputs with the Phytec external BDM header. 
 
The Macraigor unit has been 100% reliable for me. It's not the fastest interface, (they also have faster ones - just more $$$) but it's pretty inexpensive. 
 
----- Original Message ----- From: "Doug Brunner" <doug at udel.edu> 
To: <efi332 at diy-efi.org> 
Sent: Saturday, July 02, 2005 10:51 AM 
Subject: Re: [Efi332] BDM troubles 
 
> My problems have been with GDB's support for the BDM interface. I'm > actually using the Phytec board's internal BDM (parallel port on the > board) rather than the 10-pin header for an external BDM, since my only > BDM is a Tilbury unit from way back when that has been more than a little > flaky. 
> 
> As I understand it, GDB needs some kind of addon to talk to a BDM via the > parallel port. I've tried MPCBDM as discussed on James' 555 Webpage, > running gdb 5.0 (since that's the only version I've seen the patch for) as > root, and it doesn't seem to accomplish anything--it just hangs when I try > to connect to the board. What has everyone else been using? 
> 
> --Doug Brunner 
> 
> Paul Helmuth wrote: 
> 
>> I'm (reasonably) sure everyone that has done anything with the Phytec >> development board has used the JTAG/BDM port. 
>> 
>> Since you are using GDB, I assume that you are using the GCC tool chain. >> Since you are using that, I also assume that you are using the external >> BDM port. This means you have some BDM port interface (like a Wiggler). 
>> 
>> So - you need to make sure that all of your pin-outs match between your >> BDM interface and the Phytec BDM port. As an example, two of the pins are >> reversed between the Phytec port and my Macraigor Wiggler. I have a note >> on James' 555 web page about that switch. Also, you need to follow >> Phytec's bulletin on setting the development board jumpers for using the >> external BDM port. 
>> 
>> Other than that, everything should work - but I haven't used these tools >> with Linux. 
>> 
>> -Paul 
>> 
>> 
>> ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu> 
>> To: <efi332 at diy-efi.org> 
>> Sent: Friday, July 01, 2005 10:11 PM 
>> Subject: [Efi332] BDM troubles 
>> 
>> 
>>> I'm trying to start talking to my Phytec 555 board and having lots of >>> trouble. It's on the Phytec development board, so I'm using their BDM, >>> which I can't get GDB to interact with. I'm running all this under >>> Linux. 
>>> 
>>> What have the rest of you been using for BDM support? 
>>> 
>>> --Doug Brunner 
>>> _______________________________________________ 
>>> Efi332 mailing list 
>>> Efi332 at diy-efi.org 
>>> http://lists.diy-efi.org/mailman/listinfo/efi332 
>>> 
>> 
>> _______________________________________________ 
>> Efi332 mailing list 
>> Efi332 at diy-efi.org 
>> http://lists.diy-efi.org/mailman/listinfo/efi332 
>> 
> 
> _______________________________________________ 
> Efi332 mailing list 
> Efi332 at diy-efi.org 
> http://lists.diy-efi.org/mailman/listinfo/efi332 
>  
_______________________________________________ 
Efi332 mailing list 
Efi332 at diy-efi.org 
http://lists.diy-efi.org/mailman/listinfo/efi332 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050702/8a29986b/attachment.html 

From PaulHelmuth at SprintMail.com  Sat Jul  2 12:56:12 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Sat, 2 Jul 2005 12:56:12 -0500
Subject: [Efi332] BDM troubles
References: <42C605D9.5000309@udel.edu><011201c57eb6$2e352670$6b7ba8c0@p2450>	<42C6B7E4.3080801@udel.edu><013f01c57f20$c167bf10$6b7ba8c0@p2450>
	<8C74D3E6A8C5E4F-B9C-A6DF@mblk-d33.sysops.aol.com>
Message-ID: <014f01c57f2f$55ca7810$6b7ba8c0@p2450>

Humm... I think I'll try switching my board back to use the built-in interface. It would be nice to eliminate the "extra" cords, power, and hardware.

David - are you using the parallel cable that came with the Phytec kit, or a standard cable (I haven't tested the pins with a meter, but I seem to remember that the cable that comes with the Phytec kit is not a standard parallel cable)?
  ----- Original Message ----- 
  From: bowtievette at aol.com 
  To: efi332 at diy-efi.org 
  Sent: Saturday, July 02, 2005 11:58 AM
  Subject: Re: [Efi332] BDM troubles


  The BDM interface built into the Phytec development board is functionally identical to the wiggler interface, if not completely identical. You should be able to connect using either interface so thats probably not your problem. 

  One thing I found when investigating using gdb was that out of the box, it did not support a parallel interface to the BDM. It only supported the ethernet interface, so the only way I was able to get it to work was with Macraigor's OCDemon program which essentially echoes the ethernet port activity on the parallel port. Your gdb version may have parallel BDM support but thats something to verify.

  As a stopgap, you might try using Macraigor's OCD Commander as they have a linux version for it. Thats probably not a final solution for you though since it only allows assembly level debugging. But it would get you connected so that you can load software at least. David Eicher is using commander I think and can probably help out with initialization scripts and such.
   
  -----Original Message-----
  From: Paul Helmuth <PaulHelmuth at SprintMail.com>
  To: efi332 at diy-efi.org
  Sent: Sat, 2 Jul 2005 11:11:50 -0500
  Subject: Re: [Efi332] BDM troubles


  I suspect (mind you, I don't have much to go on here) that your problem is related to trying to use Phytec's "built-in" interface with anything other than the Codewarrior software that they ship with it. 
   
  Of course, it should be possible to use that connection, but I think things are a whole LOT "cleaner" switching to their external BDM header. At least there you have all of the pins documented. 
   
  I use a Macraigor Wiggler to supply the BDM-to-parallel port interface and as I mentioned in my previous email, there is a link on James' web page that gives some direction for matching the Macraigor outputs with the Phytec external BDM header. 
   
  The Macraigor unit has been 100% reliable for me. It's not the fastest interface, (they also have faster ones - just more $$$) but it's pretty inexpensive. 
   
  ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu> 
  To: <efi332 at diy-efi.org> 
  Sent: Saturday, July 02, 2005 10:51 AM 
  Subject: Re: [Efi332] BDM troubles 
   
  > My problems have been with GDB's support for the BDM interface. I'm > actually using the Phytec board's internal BDM (parallel port on the > board) rather than the 10-pin header for an external BDM, since my only > BDM is a Tilbury unit from way back when that has been more than a little > flaky. 
  > 
  > As I understand it, GDB needs some kind of addon to talk to a BDM via the > parallel port. I've tried MPCBDM as discussed on James' 555 Webpage, > running gdb 5.0 (since that's the only version I've seen the patch for) as > root, and it doesn't seem to accomplish anything--it just hangs when I try > to connect to the board. What has everyone else been using? 
  > 
  > --Doug Brunner 
  > 
  > Paul Helmuth wrote: 
  > 
  >> I'm (reasonably) sure everyone that has done anything with the Phytec >> development board has used the JTAG/BDM port. 
  >> 
  >> Since you are using GDB, I assume that you are using the GCC tool chain. >> Since you are using that, I also assume that you are using the external >> BDM port. This means you have some BDM port interface (like a Wiggler). 
  >> 
  >> So - you need to make sure that all of your pin-outs match between your >> BDM interface and the Phytec BDM port. As an example, two of the pins are >> reversed between the Phytec port and my Macraigor Wiggler. I have a note >> on James' 555 web page about that switch. Also, you need to follow >> Phytec's bulletin on setting the development board jumpers for using the >> external BDM port. 
  >> 
  >> Other than that, everything should work - but I haven't used these tools >> with Linux. 
  >> 
  >> -Paul 
  >> 
  >> 
  >> ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu> 
  >> To: <efi332 at diy-efi.org> 
  >> Sent: Friday, July 01, 2005 10:11 PM 
  >> Subject: [Efi332] BDM troubles 
  >> 
  >> 
  >>> I'm trying to start talking to my Phytec 555 board and having lots of >>> trouble. It's on the Phytec development board, so I'm using their BDM, >>> which I can't get GDB to interact with. I'm running all this under >>> Linux. 
  >>> 
  >>> What have the rest of you been using for BDM support? 
  >>> 
  >>> --Doug Brunner 
  >>> _______________________________________________ 
  >>> Efi332 mailing list 
  >>> Efi332 at diy-efi.org 
  >>> http://lists.diy-efi.org/mailman/listinfo/efi332 
  >>> 
  >> 
  >> _______________________________________________ 
  >> Efi332 mailing list 
  >> Efi332 at diy-efi.org 
  >> http://lists.diy-efi.org/mailman/listinfo/efi332 
  >> 
  > 
  > _______________________________________________ 
  > Efi332 mailing list 
  > Efi332 at diy-efi.org 
  > http://lists.diy-efi.org/mailman/listinfo/efi332 
  >  
  _______________________________________________ 
  Efi332 mailing list 
  Efi332 at diy-efi.org 
  http://lists.diy-efi.org/mailman/listinfo/efi332 



------------------------------------------------------------------------------


  _______________________________________________
  Efi332 mailing list
  Efi332 at diy-efi.org
  http://lists.diy-efi.org/mailman/listinfo/efi332
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050702/53b2f53e/attachment.html 

From doug at udel.edu  Sat Jul  2 13:38:29 2005
From: doug at udel.edu (Doug Brunner)
Date: Sat, 02 Jul 2005 14:38:29 -0400
Subject: [Efi332] BDM troubles
In-Reply-To: <8C74D3E6A8C5E4F-B9C-A6DF@mblk-d33.sysops.aol.com>
References: <42C605D9.5000309@udel.edu>	<011201c57eb6$2e352670$6b7ba8c0@p2450>	<42C6B7E4.3080801@udel.edu>	<013f01c57f20$c167bf10$6b7ba8c0@p2450>
	<8C74D3E6A8C5E4F-B9C-A6DF@mblk-d33.sysops.aol.com>
Message-ID: <42C6DF25.3040806@udel.edu>

Hmmm...I have a laptop that I use for tuning, set up as dual-boot. Maybe 
run OCDRemote on it?

       --Doug Brunner

bowtievette at aol.com wrote:

> The BDM interface built into the Phytec development board is 
> functionally identical to the wiggler interface, if not completely 
> identical. You should be able to connect using either interface so 
> thats probably not your problem.
>  
> One thing I found when investigating using gdb was that out of the 
> box, it did not support a parallel interface to the BDM. It only 
> supported the ethernet interface, so the only way I was able to get it 
> to work was with Macraigor's OCDemon program which essentially echoes 
> the ethernet port activity on the parallel port. Your gdb version may 
> have parallel BDM support but thats something to verify.
>  
> As a stopgap, you might try using Macraigor's OCD Commander as they 
> have a linux version for it. Thats probably not a final solution for 
> you though since it only allows assembly level debugging. But it would 
> get you connected so that you can load software at least. David Eicher 
> is using commander I think and can probably help out with 
> initialization scripts and such.
>  
> -----Original Message-----
> From: Paul Helmuth <PaulHelmuth at SprintMail.com>
> To: efi332 at diy-efi.org
> Sent: Sat, 2 Jul 2005 11:11:50 -0500
> Subject: Re: [Efi332] BDM troubles
>
> I suspect (mind you, I don't have much to go on here) that your 
> problem is related to trying to use Phytec's "built-in" interface with 
> anything other than the Codewarrior software that they ship with it. 
>  
> Of course, it should be possible to use that connection, but I think 
> things are a whole LOT "cleaner" switching to their external BDM 
> header. At least there you have all of the pins documented. 
>  
> I use a Macraigor Wiggler to supply the BDM-to-parallel port interface 
> and as I mentioned in my previous email, there is a link on James' web 
> page that gives some direction for matching the Macraigor outputs with 
> the Phytec external BDM header. 
>  
> The Macraigor unit has been 100% reliable for me. It's not the fastest 
> interface, (they also have faster ones - just more $$$) but it's 
> pretty inexpensive. 
>  
> ----- Original Message ----- From: ! "Doug Brunner" <doug at udel.edu 
> <mailto:doug%40udel.edu>> 
> To: <efi332 at diy-efi.org <mailto:efi332%40diy-efi.org>> 
> Sent: Saturday, July 02, 2005 10:51 AM 
> Subject: Re: [Efi332] BDM troubles 
>  
> > My problems have been with GDB's support for the BDM interface. I'm 
> > actually using the Phytec board's internal BDM (parallel port on the 
> > board) rather than the 10-pin header for an external BDM, since my 
> only > BDM is a Tilbury unit from way back when that has been more 
> than a little > flaky. 
> > 
> > As I understand it, GDB needs some kind of addon to talk to a BDM 
> via the > parallel port. I've tried MPCBDM as discussed on James' 555 
> Webpage, > running gdb 5.0 (since that's the only version I've seen 
> the patch for) as > root, and it doesn't seem to accomplish 
> anything--it just hangs when I try > to connect to the board. What has 
> everyone else been using? 
> > 
> > --Doug Brunner 
> > 
> > Paul Helmuth wrote: 
> > 
> >> I'm (reasonably) sure everyone that has done anything with the 
> Phytec >> development board has used the JTAG/BDM port. 
> >> 
> >> Since you are using GDB, I assume that you are using the GCC tool 
> chain. >> Since you are using that, I also assume that you are using 
> the external >> BDM port. This means you have some BDM port interface 
> (like a Wiggler). 
> >> 
> >> So - you need to make sure that all of your pin-outs match between 
> your >> BDM interface and the Phytec BDM port. As an example, two of 
> the pins are >> reversed between the Phytec port and my Macraigor 
> Wiggler. I have a note >> on James' 555 web page about that switch. 
> Also, you need to follow >> Phytec's bulletin on setting the 
> development board jumpers for using the >> external BDM port. 
> >>&nbs! p;
> >> Other than that, everything should work - but I haven't used these 
> tools >> with Linux. 
> >> 
> >> -Paul 
> >> 
> >> 
> >> ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu 
> <mailto:doug%40udel.edu>> 
> >> To: <efi332 at diy-efi.org <mailto:efi332%40diy-efi.org>> 
> >> Sent: Friday, July 01, 2005 10:11 PM 
> >> Subject: [Efi332] BDM troubles 
> >> 
> >> 
> >>> I'm trying to start talking to my Phytec 555 board and having lots 
> of >>> trouble. It's on the Phytec development board, so I'm using 
> their BDM, >>> which I can't get GDB to interact with. I'm running all 
> this under >>> Linux. 
> >>> 
> >>> What have the rest of you been using for BDM support? 
> >>> 
> >>> --Doug Brunner 
> >! >> _______________________________________________ 
> >>> Efi332 mailing list 
> >>>
> _______________________________________________ Efi332 mailing list 
> Efi332 at diy-efi.org http://lists.diy-efi.org/mailman/listinfo/efi332 
> <m%0A%0A%3Cpre%20wrap%3E%3CBR%3E%3CHR%20WIDTH=>




From PaulHelmuth at SprintMail.com  Sat Jul  2 18:15:08 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Sat, 2 Jul 2005 18:15:08 -0500
Subject: [Efi332] BDM troubles
References: <42C605D9.5000309@udel.edu><011201c57eb6$2e352670$6b7ba8c0@p2450>	<42C6B7E4.3080801@udel.edu><013f01c57f20$c167bf10$6b7ba8c0@p2450><8C74D3E6A8C5E4F-B9C-A6DF@mblk-d33.sysops.aol.com>
	<014f01c57f2f$55ca7810$6b7ba8c0@p2450>
Message-ID: <001401c57f5b$e3dc3c20$6b7ba8c0@p2450>

Unfortunately, I can't get Macraigor software to interact with the Phytec BDM interface correctly. I get a "Power not on target" type of error when trying to connect with OCD commander or with Macraigor's Flash Memory programmer.

David, if you are connecting to Phytec BDM interface can you share any details (jumper settings, tricks, etc.)?
  ----- Original Message ----- 
  From: Paul Helmuth 
  To: efi332 at diy-efi.org 
  Sent: Saturday, July 02, 2005 12:56 PM
  Subject: Re: [Efi332] BDM troubles


  Humm... I think I'll try switching my board back to use the built-in interface. It would be nice to eliminate the "extra" cords, power, and hardware.

  David - are you using the parallel cable that came with the Phytec kit, or a standard cable (I haven't tested the pins with a meter, but I seem to remember that the cable that comes with the Phytec kit is not a standard parallel cable)?
    ----- Original Message ----- 
    From: bowtievette at aol.com 
    To: efi332 at diy-efi.org 
    Sent: Saturday, July 02, 2005 11:58 AM
    Subject: Re: [Efi332] BDM troubles


    The BDM interface built into the Phytec development board is functionally identical to the wiggler interface, if not completely identical. You should be able to connect using either interface so thats probably not your problem. 

    One thing I found when investigating using gdb was that out of the box, it did not support a parallel interface to the BDM. It only supported the ethernet interface, so the only way I was able to get it to work was with Macraigor's OCDemon program which essentially echoes the ethernet port activity on the parallel port. Your gdb version may have parallel BDM support but thats something to verify.

    As a stopgap, you might try using Macraigor's OCD Commander as they have a linux version for it. Thats probably not a final solution for you though since it only allows assembly level debugging. But it would get you connected so that you can load software at least. David Eicher is using commander I think and can probably help out with initialization scripts and such.
     
    -----Original Message-----
    From: Paul Helmuth <PaulHelmuth at SprintMail.com>
    To: efi332 at diy-efi.org
    Sent: Sat, 2 Jul 2005 11:11:50 -0500
    Subject: Re: [Efi332] BDM troubles


    I suspect (mind you, I don't have much to go on here) that your problem is related to trying to use Phytec's "built-in" interface with anything other than the Codewarrior software that they ship with it. 
     
    Of course, it should be possible to use that connection, but I think things are a whole LOT "cleaner" switching to their external BDM header. At least there you have all of the pins documented. 
     
    I use a Macraigor Wiggler to supply the BDM-to-parallel port interface and as I mentioned in my previous email, there is a link on James' web page that gives some direction for matching the Macraigor outputs with the Phytec external BDM header. 
     
    The Macraigor unit has been 100% reliable for me. It's not the fastest interface, (they also have faster ones - just more $$$) but it's pretty inexpensive. 
     
    ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu> 
    To: <efi332 at diy-efi.org> 
    Sent: Saturday, July 02, 2005 10:51 AM 
    Subject: Re: [Efi332] BDM troubles 
     
    > My problems have been with GDB's support for the BDM interface. I'm > actually using the Phytec board's internal BDM (parallel port on the > board) rather than the 10-pin header for an external BDM, since my only > BDM is a Tilbury unit from way back when that has been more than a little > flaky. 
    > 
    > As I understand it, GDB needs some kind of addon to talk to a BDM via the > parallel port. I've tried MPCBDM as discussed on James' 555 Webpage, > running gdb 5.0 (since that's the only version I've seen the patch for) as > root, and it doesn't seem to accomplish anything--it just hangs when I try > to connect to the board. What has everyone else been using? 
    > 
    > --Doug Brunner 
    > 
    > Paul Helmuth wrote: 
    > 
    >> I'm (reasonably) sure everyone that has done anything with the Phytec >> development board has used the JTAG/BDM port. 
    >> 
    >> Since you are using GDB, I assume that you are using the GCC tool chain. >> Since you are using that, I also assume that you are using the external >> BDM port. This means you have some BDM port interface (like a Wiggler). 
    >> 
    >> So - you need to make sure that all of your pin-outs match between your >> BDM interface and the Phytec BDM port. As an example, two of the pins are >> reversed between the Phytec port and my Macraigor Wiggler. I have a note >> on James' 555 web page about that switch. Also, you need to follow >> Phytec's bulletin on setting the development board jumpers for using the >> external BDM port. 
    >> 
    >> Other than that, everything should work - but I haven't used these tools >> with Linux. 
    >> 
    >> -Paul 
    >> 
    >> 
    >> ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu> 
    >> To: <efi332 at diy-efi.org> 
    >> Sent: Friday, July 01, 2005 10:11 PM 
    >> Subject: [Efi332] BDM troubles 
    >> 
    >> 
    >>> I'm trying to start talking to my Phytec 555 board and having lots of >>> trouble. It's on the Phytec development board, so I'm using their BDM, >>> which I can't get GDB to interact with. I'm running all this under >>> Linux. 
    >>> 
    >>> What have the rest of you been using for BDM support? 
    >>> 
    >>> --Doug Brunner 
    >>> _______________________________________________ 
    >>> Efi332 mailing list 
    >>> Efi332 at diy-efi.org 
    >>> http://lists.diy-efi.org/mailman/listinfo/efi332 
    >>> 
    >> 
    >> _______________________________________________ 
    >> Efi332 mailing list 
    >> Efi332 at diy-efi.org 
    >> http://lists.diy-efi.org/mailman/listinfo/efi332 
    >> 
    > 
    > _______________________________________________ 
    > Efi332 mailing list 
    > Efi332 at diy-efi.org 
    > http://lists.diy-efi.org/mailman/listinfo/efi332 
    >  
    _______________________________________________ 
    Efi332 mailing list 
    Efi332 at diy-efi.org 
    http://lists.diy-efi.org/mailman/listinfo/efi332 



----------------------------------------------------------------------------


    _______________________________________________
    Efi332 mailing list
    Efi332 at diy-efi.org
    http://lists.diy-efi.org/mailman/listinfo/efi332



------------------------------------------------------------------------------


  _______________________________________________
  Efi332 mailing list
  Efi332 at diy-efi.org
  http://lists.diy-efi.org/mailman/listinfo/efi332
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050702/5d9cd28f/attachment.html 

From BowTieVette at aol.com  Sat Jul  2 18:42:32 2005
From: BowTieVette at aol.com (BowTieVette at aol.com)
Date: Sat, 2 Jul 2005 19:42:32 EDT
Subject: [Efi332] BDM troubles
Message-ID: <1ad.3a885fe7.2ff88068@aol.com>

 
I had not thought of that possibility, but I can't see why that  wouldn't 
work.
jc
 
 
In a message dated 7/2/2005 2:39:20 PM Eastern Standard Time, doug at udel.edu  
writes:

Hmmm...I  have a laptop that I use for tuning, set up as dual-boot. Maybe 
run  OCDRemote on it?

--Doug  Brunner

bowtievette at aol.com wrote:


 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050702/c4340925/attachment.html 

From doug at UDel.Edu  Sat Jul  2 22:15:21 2005
From: doug at UDel.Edu (doug at UDel.Edu)
Date: Sat, 2 Jul 2005 23:15:21 -0400
Subject: [Efi332] BDM troubles
Message-ID: <316337d4.15de09e9.81a0600@ms3.nss.udel.edu>

I set up OCDRemote successfully, but it doesn't work--it keeps
saying the target's power isn't on. Same thing with OCD
Commander. However, when I hit the reset button in OCD
Commander, I can see the reset LED flash, so it's definitely
communicating. Any ideas?

BTW, my command line for OCDRemote looks like this:
ocdremote -c MPC55X -d WIGGLER -a 1 -s 7

        --Doug Brunner


From sailors3 at comcast.net  Sat Jul  2 22:26:49 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sat, 2 Jul 2005 20:26:49 -0700
Subject: [Efi332] BDM troubles
In-Reply-To: <001401c57f5b$e3dc3c20$6b7ba8c0@p2450>
Message-ID: <mailman.9.1311919742.4788.efi332@diy-efi.org>

Hi Guys,

 

Sorry, been out of the country for nearly a month.

 

I'm using the cable parallel cable that came with the Phytec board, I
connected it to the Phytec board parallel connector and to my desktop
parallel (printer) interface. I use OCD Commander to debug. It talks to the
Phytec very well, no problems. My desktop is a Windoze XP machine. So., I've
got the Phytec development kit including the carrier board the MPC555 sits
on, I believe this carrier board has a BDM interface on it. I never changed
any setting on the Phytec or carrier board, just plugged in the cable and it
worked.

 

I very soon need to move to a more capable debugger though, OCD Commander is
strictly a assembly level debugger, and does not even have the capability to
set breakpoints. I've had to manually set them by going into the code and
changing an instruction to all zeros to cause a break. It's crude, and
doesn't always work so well.

 

I'm hoping to use Insight/GDB, and I believe I will need to use OCDRemote to
make that work. OCD Remote "listens" on a TCP/IP port number (configurable
to match the GDB), and re-issues the commands over the parallel interface.
I'll work on this and let you know how it goes. I'm using CYGWIN so I start
OCDRemote in a shell as follows:

 

OCDRemote -c MPC55X

 

OCDRemote launches then, and states that it is listening on port 8888,
apparently this is the default for GDB. The port number can be changed with
a command line switch.

 

Hope this helps,

 

Regards,

 

Dave

 

 

 

 

  _____  

From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Paul Helmuth
Sent: Saturday, July 02, 2005 3:15 PM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] BDM troubles

 

Unfortunately, I can't get Macraigor software to interact with the Phytec
BDM interface correctly. I get a "Power not on target" type of error when
trying to connect with OCD commander or with Macraigor's Flash Memory
programmer.

 

David, if you are connecting to Phytec BDM interface can you share any
details (jumper settings, tricks, etc.)?

----- Original Message ----- 

From: Paul <mailto:PaulHelmuth at SprintMail.com>  Helmuth 

To: efi332 at diy-efi.org 

Sent: Saturday, July 02, 2005 12:56 PM

Subject: Re: [Efi332] BDM troubles

 

Humm... I think I'll try switching my board back to use the built-in
interface. It would be nice to eliminate the "extra" cords, power, and
hardware.

 

David - are you using the parallel cable that came with the Phytec kit, or a
standard cable (I haven't tested the pins with a meter, but I seem to
remember that the cable that comes with the Phytec kit is not a standard
parallel cable)?

----- Original Message ----- 

From: bowtievette at aol.com 

To: efi332 at diy-efi.org 

Sent: Saturday, July 02, 2005 11:58 AM

Subject: Re: [Efi332] BDM troubles

 

The BDM interface built into the Phytec development board is functionally
identical to the wiggler interface, if not completely identical. You should
be able to connect using either interface so thats probably not your
problem. 

 

One thing I found when investigating using gdb was that out of the box, it
did not support a parallel interface to the BDM. It only supported the
ethernet interface, so the only way I was able to get it to work was with
Macraigor's OCDemon program which essentially echoes the ethernet port
activity on the parallel port. Your gdb version may have parallel BDM
support but thats something to verify.

 

As a stopgap, you might try using Macraigor's OCD Commander as they have a
linux version for it. Thats probably not a final solution for you though
since it only allows assembly level debugging. But it would get you
connected so that you can load software at least. David Eicher is using
commander I think and can probably help out with initialization scripts and
such.

 
-----Original Message-----
From: Paul Helmuth <PaulHelmuth at SprintMail.com>
To: efi332 at diy-efi.org
Sent: Sat, 2 Jul 2005 11:11:50 -0500
Subject: Re: [Efi332] BDM troubles

I suspect (mind you, I don't have much to go on here) that your problem is
related to trying to use Phytec's "built-in" interface with anything other
than the Codewarrior software that they ship with it. 
 
Of course, it should be possible to use that connection, but I think things
are a whole LOT "cleaner" switching to their external BDM header. At least
there you have all of the pins documented. 
 
I use a Macraigor Wiggler to supply the BDM-to-parallel port interface and
as I mentioned in my previous email, there is a link on James' web page that
gives some direction for matching the Macraigor outputs with the Phytec
external BDM header. 
 
The Macraigor unit has been 100% reliable for me. It's not the fastest
interface, (they also have faster ones - just more $$$) but it's pretty
inexpensive. 
 
----- Original Message ----- From: "Doug Brunner" <doug at udel.edu
<mailto:doug%40udel.edu> > 
To: <efi332 at diy-efi.org <mailto:efi332%40diy-efi.org> > 
Sent: Saturday, July 02, 2005 10:51 AM 
Subject: Re: [Efi332] BDM troubles 
 
> My problems have been with GDB's support for the BDM interface. I'm >
actually using the Phytec board's internal BDM (parallel port on the >
board) rather than the 10-pin header for an external BDM, since my only >
BDM is a Tilbury unit from way back when that has been more than a little >
flaky. 
> 
> As I understand it, GDB needs some kind of addon to talk to a BDM via the
> parallel port. I've tried MPCBDM as discussed on James' 555 Webpage, >
running gdb 5.0 (since that's the only version I've seen the patch for) as >
root, and it doesn't seem to accomplish anything--it just hangs when I try >
to connect to the board. What has everyone else been using? 
> 
> --Doug Brunner 
> 
> Paul Helmuth wrote: 
> 
>> I'm (reasonably) sure everyone that has done anything with the Phytec >>
development board has used the JTAG/BDM port. 
>> 
>> Since you are using GDB, I assume that you are using the GCC tool chain.
>> Since you are using that, I also assume that you are using the external
>> BDM port. This means you have some BDM port interface (like a Wiggler). 
>> 
>> So - you need to make sure that all of your pin-outs match between your
>> BDM interface and the Phytec BDM port. As an example, two of the pins are
>> reversed between the Phytec port and my Macraigor Wiggler. I have a note
>> on James' 555 web page about that switch. Also, you need to follow >>
Phytec's bulletin on setting the development board jumpers for using the >>
external BDM port. 
>> 
>> Other than that, everything should work - but I haven't used these tools
>> with Linux. 
>> 
>> -Paul 
>> 
>> 
>> ----- Original Message ----- From: "Doug Brunner" <doug at udel.edu
<mailto:doug%40udel.edu> > 
>> To: <efi332 at diy-efi.org <mailto:efi332%40diy-efi.org> > 
>> Sent: Friday, July 01, 2005 10:11 PM 
>> Subject: [Efi332] BDM troubles 
>> 
>> 
>>> I'm trying to start talking to my Phytec 555 board and having lots of
>>> trouble. It's on the Phytec development board, so I'm using their BDM,
>>> which I can't get GDB to interact with. I'm running all this under >>>
Linux. 
>>> 
>>> What have the rest of you been using for BDM support? 
>>> 
>>> --Doug Brunner 
>>> _______________________________________________ 
>>> Efi332 mailing list 
>>> Efi332 at diy-efi.org <mailto:Efi332%40diy-efi.org>  
>>> http://lists.diy-efi.org/mailman/listinfo/efi332 
>>> 
>> 
>> _______________________________________________ 
>> Efi332 mailing list 
>> Efi332 at diy-efi.org <mailto:Efi332%40diy-efi.org>  
>> http://lists.diy-efi.org/mailman/listinfo/efi332 
>> 
> 
> _______________________________________________ 
> Efi332 mailing list 
> Efi332 at diy-efi.org <mailto:Efi332%40diy-efi.org>  
> http://lists.diy-efi.org/mailman/listinfo/efi332 
>  
_______________________________________________ 
Efi332 mailing list 
Efi332 at diy-efi.org <mailto:Efi332%40diy-efi.org>  
http://lists.diy-efi.org/mailman/listinfo/efi332 


  _____  


_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332


  _____  


_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050702/f30f87b7/attachment.html 

From sailors3 at comcast.net  Sat Jul  2 22:40:16 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sat, 2 Jul 2005 20:40:16 -0700
Subject: [Efi332] BDM troubles
In-Reply-To: <316337d4.15de09e9.81a0600@ms3.nss.udel.edu>
Message-ID: <mailman.10.1311919742.4788.efi332@diy-efi.org>

Hi Doug,

If you click on the reset button on OCD Commander, and the reset LED flashes
on the Phytec development kit carrier board (is that what you mean?), you
are definitely talking to the board. So..., the only difference between your
setup and mine is..., you are using a wiggler and the 10pin BDM interface on
the carrier board. And I'm using a parallel cable and the BDM parallel
connector (and carrier board BDM interface) on the carrier board (PPC-995).

Just looking at the schematic for the PPC-995, it looks like you might need
to remove some jumpers to use the 10-pin interface to make sure the PPC-995
BDM interface doesn't interfere with the wiggler. It looks like you need to
pull JP5, JP6, and JP1. That should take the on board BDM interface out of
the picture.

HTH,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of doug at UDel.Edu
Sent: Saturday, July 02, 2005 7:15 PM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] BDM troubles

I set up OCDRemote successfully, but it doesn't work--it keeps
saying the target's power isn't on. Same thing with OCD
Commander. However, when I hit the reset button in OCD
Commander, I can see the reset LED flash, so it's definitely
communicating. Any ideas?

BTW, my command line for OCDRemote looks like this:
ocdremote -c MPC55X -d WIGGLER -a 1 -s 7

        --Doug Brunner
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From sailors3 at comcast.net  Sat Jul  2 22:47:50 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sat, 2 Jul 2005 20:47:50 -0700
Subject: [Efi332] HW Question (for JC)
In-Reply-To: <012001c57eb7$b35da1a0$6b7ba8c0@p2450>
Message-ID: <mailman.11.1311919742.4788.efi332@diy-efi.org>

Hi Paul,

 

What engine are you using this on?

 

Thanks,

 

Dave

 

 

  _____  

From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Paul Helmuth
Sent: Friday, July 01, 2005 7:40 PM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] HW Question (for JC)

 

Jeff,

 

Thanks!

 

I found the Panasonic devices at Digikey - they appear to be ideal for the
application. The only problem for me is they also appear to be available in
SMD only. After some searching, I found some units by Xicon (at Mouser)
which are low ESR and come in an old fashioned package (with legs). The only
thing is, I did have to bump up my capacitor value to 220 uf to be safely
within the ESR at colder temperatures (not that this is really long term
solution - but it doesn't hurt anything for that output cap to be bigger).

 

So, after everyone is back from the long holiday weekend and they ship my
capacitors, I'll finally be ready to do my ignition-only testing (that is,
if I have the crank trigger wheel mounted).

 

-Paul

----- Original Message ----- 

From: bowtievette at aol.com 

To: efi332 at diy-efi.org 

Sent: Wednesday, June 29, 2005 8:44 PM

Subject: Re: [Efi332] HW Question (for JC)

 

Hi Paul,

I would include the 47uF on the input side. I don't think you will have any
problems with it running from the car's battery/alternator.

On the output side, you're right, ESR values are typically not quoted in
catalogs other than to say low ESR, so you usually have to dig up the
datasheet(s) to get the tables for it. If you do a search for low ESR
capacitor at digikey it will narrow the search to caps that advertise low
ESR. Pick a 22 uF one from the selection table presented and follow it to
the datasheet. For this application, aluminum electrolytics are common, and
occasionally tantalums. Some folks recommend against using tantalums in
power supplies since they have a tendency to blow up under rapid transient
conditions. With the electrolytics, you may have to watch the temperature
variation since the ESR varies quite a bit.

 
-----Original Message-----
From: Paul Helmuth <PaulHelmuth at SprintMail.com>
To: efi332 at diy-efi.org
Sent: Wed, 29 Jun 2005 16:37:06 -0500
Subject: [Efi332] HW Question (for JC)

Jeff,

 

I managed to source a couple of National LM2940T (9volt output) regulators.
I am hoping to use this part to power my Phytec development board from the
car's 12v battery.

 

The "Typical Application" section of the data sheet shows only two external
components. 

 

One is a .47 microfarad capacitor on V-in to ground. An asterisk note
indicates that this is required if the regulator is located far from the
"power supply filter". Which seems to imply that there should be some
filtering in place between the battery and the regulator (though there is no
diagram of what such a filter should look like).

 

The second external component is a 22 microfarad (minimum) capacitor on
V-out to ground. The interesting note on the output capacitor is that the
equivalent series resistance is critical. Reading the performance
characteristics table relating to the output capacitor ESR, I see that I
need to use a capacitor with an ESR between .1 and 1 ohm. I have never seen
ESR given for capacitors. Can you give me any pointers as to how I can
determine and arrive at an acceptable ESR for the output capacitor(s)?

 

Thanks,

-Paul

_______________________________________________

Efi332 mailing list

Efi332 at diy-efi.org <mailto:Efi332%40diy-efi.org> 

http://lists.diy-efi.org/mailman/listinfo/efi332


  _____  

size=2 width="100%" align=center> 

_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050702/bbea9e83/attachment.html 

From PaulHelmuth at SprintMail.com  Sat Jul  2 23:43:03 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Sat, 2 Jul 2005 23:43:03 -0500
Subject: [Efi332] What engine am I using...
References: <200507022346.1dOVr67ai3Nl34f0@mx-roseate.atl.sa.earthlink.net>
Message-ID: <004e01c57f89$b4370940$6b7ba8c0@p2450>

Dave,

My first "victim" is an 1800-B. That's the in-line 4 cylinder that came in the MG B's.

I had previously converted the stock ignition to a Crane Fireball system (a few years ago). After a little detective work I have sorted out how to trigger the Crane system. It's pretty similar to triggering a single coil MSD system.

Once I have the ignition stuff sorted, I am going to start working on the fuel injection. For the 1800-B I am going to attempt to fit a throttle body injection system from the GM 2.5 L "Iron Duke". That is a suggestion that I got from Steve Ravet on DIY-EFI. Apparently those engines produced around 100 HP and that should be about right for the 1800-B.

-Paul
  ----- Original Message ----- 
  From: David Eicher 
  To: efi332 at diy-efi.org 
  Sent: Saturday, July 02, 2005 10:47 PM
  Subject: RE: [Efi332] HW Question (for JC)


  Hi Paul,

   

  What engine are you using this on?

   

  Thanks,

   

  Dave

   

   


------------------------------------------------------------------------------

  From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Paul Helmuth
  Sent: Friday, July 01, 2005 7:40 PM
  To: efi332 at diy-efi.org
  Subject: Re: [Efi332] HW Question (for JC)

   

  Jeff,

   

  Thanks!

   

  I found the Panasonic devices at Digikey - they appear to be ideal for the application. The only problem for me is they also appear to be available in SMD only. After some searching, I found some units by Xicon (at Mouser) which are low ESR and come in an old fashioned package (with legs). The only thing is, I did have to bump up my capacitor value to 220 uf to be safely within the ESR at colder temperatures (not that this is really long term solution - but it doesn't hurt anything for that output cap to be bigger).

   

  So, after everyone is back from the long holiday weekend and they ship my capacitors, I'll finally be ready to do my ignition-only testing (that is, if I have the crank trigger wheel mounted).

   

  -Paul

    ----- Original Message ----- 

    From: bowtievette at aol.com 

    To: efi332 at diy-efi.org 

    Sent: Wednesday, June 29, 2005 8:44 PM

    Subject: Re: [Efi332] HW Question (for JC)

     

    Hi Paul,

    I would include the 47uF on the input side. I don't think you will have any problems with it running from the car's battery/alternator.

    On the output side, you're right, ESR values are typically not quoted in catalogs other than to say low ESR, so you usually have to dig up the datasheet(s) to get the tables for it. If you do a search for low ESR capacitor at digikey it will narrow the search to caps that advertise low ESR. Pick a 22 uF one from the selection table presented and follow it to the datasheet. For this application, aluminum electrolytics are common, and occasionally tantalums. Some folks recommend against using tantalums in power supplies since they have a tendency to blow up under rapid transient conditions. With the electrolytics, you may have to watch the temperature variation since the ESR varies quite a bit.


    -----Original Message-----
    From: Paul Helmuth <PaulHelmuth at SprintMail.com>
    To: efi332 at diy-efi.org
    Sent: Wed, 29 Jun 2005 16:37:06 -0500
    Subject: [Efi332] HW Question (for JC)

    Jeff,

     

    I managed to source a couple of National LM2940T (9volt output) regulators. I am hoping to use this part to power my Phytec development board from the car's 12v battery.

     

    The "Typical Application" section of the data sheet shows only two external components. 

     

    One is a .47 microfarad capacitor on V-in to ground. An asterisk note indicates that this is required if the regulator is located far from the "power supply filter". Which seems to imply that there should be some filtering in place between the battery and the regulator (though there is no diagram of what such a filter should look like).

     

    The second external component is a 22 microfarad (minimum) capacitor on V-out to ground. The interesting note on the output capacitor is that the equivalent series resistance is critical. Reading the performance characteristics table relating to the output capacitor ESR, I see that I need to use a capacitor with an ESR between .1 and 1 ohm. I have never seen ESR given for capacitors. Can you give me any pointers as to how I can determine and arrive at an acceptable ESR for the output capacitor(s)?

     

    Thanks,

    -Paul

    _______________________________________________

    Efi332 mailing list

    Efi332 at diy-efi.org

    http://lists.diy-efi.org/mailman/listinfo/efi332

    size=2 width="100%" align=center> 
    _______________________________________________
    Efi332 mailing list
    Efi332 at diy-efi.org
    http://lists.diy-efi.org/mailman/listinfo/efi332



------------------------------------------------------------------------------


  _______________________________________________
  Efi332 mailing list
  Efi332 at diy-efi.org
  http://lists.diy-efi.org/mailman/listinfo/efi332
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050702/6df56771/attachment.html 

From doug at UDel.Edu  Sat Jul  2 23:46:13 2005
From: doug at UDel.Edu (doug at UDel.Edu)
Date: Sun, 3 Jul 2005 00:46:13 -0400
Subject: [Efi332] BDM troubles
Message-ID: <7662306f.15e65bce.81a0600@ms3.nss.udel.edu>

Actually, I'm using the integral BDM, so I have the same setup
as you...very strange, I'll try setting it up on another
computer...

        --Doug Brunner


From PaulHelmuth at SprintMail.com  Sat Jul  2 23:55:53 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Sat, 2 Jul 2005 23:55:53 -0500
Subject: [Efi332] BDM troubles
References: <316337d4.15de09e9.81a0600@ms3.nss.udel.edu>
Message-ID: <005201c57f8b$7e25df00$6b7ba8c0@p2450>

That is pretty much what I get (with all of the BDM related jumpers 
replaced: JP1, JP2, JP5, JP6, JP7, JP8, JP9, JP17).

----- Original Message ----- 
From: <doug at UDel.Edu>
To: <efi332 at diy-efi.org>
Sent: Saturday, July 02, 2005 10:15 PM
Subject: Re: [Efi332] BDM troubles


>I set up OCDRemote successfully, but it doesn't work--it keeps
> saying the target's power isn't on. Same thing with OCD
> Commander. However, when I hit the reset button in OCD
> Commander, I can see the reset LED flash, so it's definitely
> communicating. Any ideas?
>
> BTW, my command line for OCDRemote looks like this:
> ocdremote -c MPC55X -d WIGGLER -a 1 -s 7
>
>        --Doug Brunner
> _______________________________________________
> Efi332 mailing list
> Efi332 at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/efi332
> 



From doug at UDel.Edu  Sun Jul  3 01:34:32 2005
From: doug at UDel.Edu (doug at UDel.Edu)
Date: Sun, 3 Jul 2005 02:34:32 -0400
Subject: [Efi332] BDM troubles
Message-ID: <f9bb1008.15f04653.81c1900@ms3.nss.udel.edu>

Curiouser and curiouser...OCD Commander works fine running on
my desktop PC, but breaks on the laptop. Both parallel ports
are configured in the BIOS as EPP 1.9. (Actually, even on the
laptop, it can step through code and get register states and
such, but I always see error messages. OCDRemote fails on
startup though.) I wonder if it's because the laptop is
running XP SP2 whereas the desktop was never updated from
SP1... What versions of XP are you all running?

        --Doug Brunner


From PaulHelmuth at SprintMail.com  Sun Jul  3 05:48:46 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Sun, 3 Jul 2005 05:48:46 -0500
Subject: [Efi332] BDM troubles
References: <f9bb1008.15f04653.81c1900@ms3.nss.udel.edu>
Message-ID: <006301c57fbc$cb1d6e50$6b7ba8c0@p2450>

SP2 Here, and I don't have anything running otherwise to test SP1, NT, 2000, 
etc.


----- Original Message ----- 
From: <doug at UDel.Edu>
To: <efi332 at diy-efi.org>
Sent: Sunday, July 03, 2005 1:34 AM
Subject: Re: [Efi332] BDM troubles


> Curiouser and curiouser...OCD Commander works fine running on
> my desktop PC, but breaks on the laptop. Both parallel ports
> are configured in the BIOS as EPP 1.9. (Actually, even on the
> laptop, it can step through code and get register states and
> such, but I always see error messages. OCDRemote fails on
> startup though.) I wonder if it's because the laptop is
> running XP SP2 whereas the desktop was never updated from
> SP1... What versions of XP are you all running?
>
>        --Doug Brunner
> _______________________________________________
> Efi332 mailing list
> Efi332 at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/efi332
> 



From sailors3 at comcast.net  Sun Jul  3 09:13:40 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sun, 3 Jul 2005 07:13:40 -0700
Subject: [Efi332] BDM troubles
In-Reply-To: <006301c57fbc$cb1d6e50$6b7ba8c0@p2450>
Message-ID: <mailman.12.1311919742.4788.efi332@diy-efi.org>

SP2 here also.

FYI: I'm told that OCDRemote has nothing to do with OCDCommander, you don't
want to run OCDRemote when you are running OCDCommander.

Hmm, anyone know how the debugger decides the target is powered up (what
signal it monitors)?



-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Paul Helmuth
Sent: Sunday, July 03, 2005 2:49 AM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] BDM troubles

SP2 Here, and I don't have anything running otherwise to test SP1, NT, 2000,

etc.


----- Original Message ----- 
From: <doug at UDel.Edu>
To: <efi332 at diy-efi.org>
Sent: Sunday, July 03, 2005 1:34 AM
Subject: Re: [Efi332] BDM troubles


> Curiouser and curiouser...OCD Commander works fine running on
> my desktop PC, but breaks on the laptop. Both parallel ports
> are configured in the BIOS as EPP 1.9. (Actually, even on the
> laptop, it can step through code and get register states and
> such, but I always see error messages. OCDRemote fails on
> startup though.) I wonder if it's because the laptop is
> running XP SP2 whereas the desktop was never updated from
> SP1... What versions of XP are you all running?
>
>        --Doug Brunner
> _______________________________________________
> Efi332 mailing list
> Efi332 at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/efi332
> 

_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From sailors3 at comcast.net  Wed Jul  6 07:56:12 2005
From: sailors3 at comcast.net (David Eicher)
Date: Wed, 6 Jul 2005 05:56:12 -0700
Subject: [Efi332] S19 to C
In-Reply-To: <003b01c570a4$926ad6f0$6b7ba8c0@p2450>
Message-ID: <mailman.13.1311919742.4788.efi332@diy-efi.org>

Hi List,

 

Does anyone have the C source for a utility program to convert S19 files to
C header files? I need this utility to convert my Flash based executable to
an array of bytes (data) so my flash burn software can access it. I am
looking for a utility that will fill in the gaps in the S record file to
make a contiguous array.

 

Thanks,

 

Dave

 

 

  _____  

From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Paul Helmuth
Sent: Monday, June 13, 2005 9:48 PM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Question regarding PMMX

 

Jeff, Thanks.

 

I'll hunt through SourceForge and see what I can find.

 

-Paul

----- Original Message ----- 

From: bowtievette at aol.com 

To: efi332 at diy-efi.org 

Sent: Monday, June 13, 2005 7:57 AM

Subject: Re: [Efi332] Question regarding PMMX

 

Paul,

You may want to scrub through the SourceForge code as there are a number of
lessons learned embedded in there. And yes, the microcode in CVS on
SourceForge is modified from what you have. Since I needed those other
functions as well (SM for stepper motor IAC, rwtpin for discrete pin IO, and
ITC for a cam counter), another list member and I packaged up a new
combination of functions.  When you compile the "stock" 58XX tpu functions
with these into a custom mask, you will find that it won't fit the 332's
emulation RAM. Something had to go so the crank window function psp12d was
removed and pmmx8 and psp3 doctored to get them to work without psp12d.
Other than that, its the same microcode.

The 555 has more emulation ram available so even if you need these extra
functions, they should fit.

Jeff

 
-----Original Message-----
From: Paul Helmuth <PaulHelmuth at SprintMail.com>
To: efi332 at diy-efi.org
Sent: Sun, 12 Jun 2005 21:50:08 -0500
Subject: Re: [Efi332] Question regarding PMMX

Jeff,

 

Thanks for the additional info. Very useful, especially the part about
re-syncing.

 

It seems that those TPU notes describe a different emulation mask from the
one that I found in the archive. The code that I am working with was under 

ftp://ftp.diy-efi.org/pub/efi332/tpu/. The code under this directory must
have been an earlier snapshot as it doesn't contain the SM, ITC, and RWTPIN
referenced in the TPU Notes, and it does contain PSP3 (along with LPWM2, and
PTA). At least that is what it looks like if you reference the "main8.asc"
(TPUMASM build file).

 

Do you know if there is a set of code archived that matches the description
in the TPU Notes page (are you using something close to this)?

 

I looked through the "pub" stuff and didn't find it. I don't seem to have
access to "incoming" and don't see it in "uploads".

 

Thanks again,

-Paul

 

 

 


  _____  

size=2 width="100%" align=center> 

_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050706/218562d2/attachment.html 

From doug at UDel.Edu  Wed Jul  6 11:26:27 2005
From: doug at UDel.Edu (doug at UDel.Edu)
Date: Wed, 6 Jul 2005 12:26:27 -0400
Subject: [Efi332] BDM troubles
Message-ID: <9759e4ce.17b1f45f.81a0600@ms3.nss.udel.edu>

>From examining the Phytec development board schematic, it
looks like the PC monitors the ACK line (pin 10 on the
target's DB-25 connector) to determine whether the target
board is powered up. No idea why the computer wouldn't be able
to get its signal though...


From sailors3 at comcast.net  Thu Jul 14 09:12:03 2005
From: sailors3 at comcast.net (David Eicher)
Date: Thu, 14 Jul 2005 07:12:03 -0700
Subject: [Efi332] Using libraries with GNU C for MPC555
In-Reply-To: <018f01c56f1a$d79ed270$6b7ba8c0@p2450>
Message-ID: <mailman.14.1311919742.4788.efi332@diy-efi.org>

Hello,

 

Does anyone have any experience with the linker in the subject environment?
I am having trouble getting ld to find the libraries GNU C is suppose to be
using for Stdio. I can't figure out how to set the path so the linker will
find the library, and I haven't been able to figure out what the name of the
library is that I need to resolve a reference to printf( ).

 

Thanks for any insight you might be able to offer.

 

Dave

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050714/aca7a68c/attachment.html 

From sailors3 at comcast.net  Fri Jul 22 07:21:31 2005
From: sailors3 at comcast.net (David Eicher)
Date: Fri, 22 Jul 2005 05:21:31 -0700
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <003b01c570a4$926ad6f0$6b7ba8c0@p2450>
Message-ID: <mailman.15.1311919742.4788.efi332@diy-efi.org>

Hello list,

 

Has anyone built a standard C library for the GNU C running on cygwin? I'm
looking for the prinf( ) function (and others), that have been re-directed
to the SCI serial interface for MPC555/565.

 

Thanks,

 

Dave

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050722/062dc4d9/attachment.html 

From gm at ib-magin.de  Fri Jul 22 09:01:34 2005
From: gm at ib-magin.de (Gunter Magin)
Date: Fri, 22 Jul 2005 16:01:34 +0200
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <200507221228.j6MCSbhu030526@shirkhan.intra>
References: <003b01c570a4$926ad6f0$6b7ba8c0@p2450>
	<200507221228.j6MCSbhu030526@shirkhan.intra>
Message-ID: <20050722140134.GA31534@mailhub.intra>

On Fri, Jul 22, 2005 at 05:21:31AM -0700, David Eicher wrote:
> Has anyone built a standard C library for the GNU C running on cygwin? I'm
> looking for the prinf( ) function (and others), that have been re-directed
> to the SCI serial interface for MPC555/565.

The "standard C library" you are looking for is newlib, and I vaguely
remember you have been checking that option a couple weeks ago.

What you need is libgloss, which some people call board
support package. Try to understand the files and concepts in
newlib-x.xx.x/libgloss/rs6000. Some of the supported boards have a
bootloader monitor, where the application jumps in for UART service via
a SW trap interface (you probably don't have that). Other systems rely
on an underlying operating system, more precisely on the BSP of that
OpSys.

Probably your system isn't supported directly, and you are operating on
the naked HW, so you have to supply your own libgloss by implementing
read(), write(), open(), sbrk() and friends, by just using the HW.
You may find an pure SCI driver or fragments of that driver also in the
68k libgloss tree, e.g. for the 6833x.

For printf you probably only need to populate write(), while other
functions can be stubbed. The linker will tell you by its error messages 
what is really needed.

gm


From KevinY at cybertech.ca  Fri Jul 22 12:33:15 2005
From: KevinY at cybertech.ca (Kevin Yachimec)
Date: Fri, 22 Jul 2005 11:33:15 -0600
Subject: [Efi332] Standard GNU C library for CYGWIN
Message-ID: <E39F32897EC52545B4B42A0842D292718B7FA4@cyb-e004.cyb-edm.local>

Dave,
 
I haven't built GCC for the 555 but I have re-built GCC for the 332 many
times and I have found that newlib is much better than stdlib that comes
with GCC.  For example if you build the 332 source code on Sourceforge
with the newlib it's almost half the size of stdlib.  As far as printf()
I have seen a number of versions for embedded work but you would be
required to build from source in order to use it.  I don't know of
anything that's ready to work with SCI out of the box.
 
Kevin


________________________________

	From: efi332-bounces at diy-efi.org
[mailto:efi332-bounces at diy-efi.org] On Behalf Of David Eicher
	Sent: Friday, July 22, 2005 6:22 AM
	To: efi332 at diy-efi.org
	Subject: [Efi332] Standard GNU C library for CYGWIN
	
	

		Hello list,

		 

		Has anyone built a standard C library for the GNU C
running on cygwin? I'm looking for the prinf( ) function (and others),
that have been re-directed to the SCI serial interface for MPC555/565.

		 

		Thanks,

		 

		Dave

		 

		 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050722/23252628/attachment.html 

From sailors3 at comcast.net  Fri Jul 22 21:21:51 2005
From: sailors3 at comcast.net (David Eicher)
Date: Fri, 22 Jul 2005 19:21:51 -0700
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <20050722140134.GA31534@mailhub.intra>
Message-ID: <mailman.16.1311919742.4788.efi332@diy-efi.org>

Thanks Gunter, appreciate the help.

Yep, I believe I'm dealing with the naked HW. But...., I am using the
Quickstart API, so I believe I need to use that convention for accessing the
HW. 

I believe I see a path to go down here to get newlib to work for me. I'll
head down that path and see how far I can get.

Thanks much,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Friday, July 22, 2005 6:02 AM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Standard GNU C library for CYGWIN

On Fri, Jul 22, 2005 at 05:21:31AM -0700, David Eicher wrote:
> Has anyone built a standard C library for the GNU C running on cygwin? I'm
> looking for the prinf( ) function (and others), that have been re-directed
> to the SCI serial interface for MPC555/565.

The "standard C library" you are looking for is newlib, and I vaguely
remember you have been checking that option a couple weeks ago.

What you need is libgloss, which some people call board
support package. Try to understand the files and concepts in
newlib-x.xx.x/libgloss/rs6000. Some of the supported boards have a
bootloader monitor, where the application jumps in for UART service via
a SW trap interface (you probably don't have that). Other systems rely
on an underlying operating system, more precisely on the BSP of that
OpSys.

Probably your system isn't supported directly, and you are operating on
the naked HW, so you have to supply your own libgloss by implementing
read(), write(), open(), sbrk() and friends, by just using the HW.
You may find an pure SCI driver or fragments of that driver also in the
68k libgloss tree, e.g. for the 6833x.

For printf you probably only need to populate write(), while other
functions can be stubbed. The linker will tell you by its error messages 
what is really needed.

gm
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From sailors3 at comcast.net  Fri Jul 22 21:26:29 2005
From: sailors3 at comcast.net (David Eicher)
Date: Fri, 22 Jul 2005 19:26:29 -0700
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <E39F32897EC52545B4B42A0842D292718B7FA4@cyb-e004.cyb-edm.local>
Message-ID: <mailman.17.1311919742.4788.efi332@diy-efi.org>

Hi Kevin,

 

Yep, I'm not aware that a library exists for SCI either. So.., it looks like
I'm going to build one. One thing I struggle with is, use SCI or QSCI? My
ultimate goal is to be using QSCI with interrupts. But that might be a bit
much to hope for initially. Maybe I'll try to walk before I run, and just
use basic character puts and gets. Then, when I'm more familiar with the
process of building a library (never done it), I'll go for the more powerful
approach.

 

That is nice to know that the stdlib with GCC is so big, gotta stay away
from that!

 

Thanks,

 

Dave

 

 

  _____  

From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Kevin Yachimec
Sent: Friday, July 22, 2005 9:33 AM
To: efi332 at diy-efi.org
Subject: RE: [Efi332] Standard GNU C library for CYGWIN

 

Dave,

 

I haven't built GCC for the 555 but I have re-built GCC for the 332 many
times and I have found that newlib is much better than stdlib that comes
with GCC.  For example if you build the 332 source code on Sourceforge with
the newlib it's almost half the size of stdlib.  As far as printf() I have
seen a number of versions for embedded work but you would be required to
build from source in order to use it.  I don't know of anything that's ready
to work with SCI out of the box.

 

Kevin

 


  _____  


From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of David Eicher
Sent: Friday, July 22, 2005 6:22 AM
To: efi332 at diy-efi.org
Subject: [Efi332] Standard GNU C library for CYGWIN

Hello list,

 

Has anyone built a standard C library for the GNU C running on cygwin? I'm
looking for the prinf( ) function (and others), that have been re-directed
to the SCI serial interface for MPC555/565.

 

Thanks,

 

Dave

 

 





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050722/c65586b2/attachment.html 

From doug at udel.edu  Sat Jul 23 05:25:51 2005
From: doug at udel.edu (Doug Brunner)
Date: Sat, 23 Jul 2005 06:25:51 -0400
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <200507230229.BKC14882@md3.nss.udel.edu>
References: <200507230229.BKC14882@md3.nss.udel.edu>
Message-ID: <42E21B2F.6070902@udel.edu>

I don't know if it'll help you or not, but I've written an ISR in 
assembly (currently untested) that uses the QSCI, and a pair of circular 
buffers to feed it--this allows the ISR to keep feeding the transmit 
queue and pulling data off the receive queue without intervention by the 
main program.

Let me know if you're interested,

--Doug Brunner

David Eicher wrote:

> Hi Kevin,
>
> Yep, I?m not aware that a library exists for SCI either. So.., it 
> looks like I?m going to build one. One thing I struggle with is, use 
> SCI or QSCI? My ultimate goal is to be using QSCI with interrupts. But 
> that might be a bit much to hope for initially. Maybe I?ll try to walk 
> before I run, and just use basic character puts and gets. Then, when 
> I?m more familiar with the process of building a library (never done 
> it), I?ll go for the more powerful approach.
>
> That is nice to know that the stdlib with GCC is so big, gotta stay 
> away from that!
>
> Thanks,
>
> Dave
>
> ------------------------------------------------------------------------
>
> *From:* efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] 
> *On Behalf Of *Kevin Yachimec
> *Sent:* Friday, July 22, 2005 9:33 AM
> *To:* efi332 at diy-efi.org
> *Subject:* RE: [Efi332] Standard GNU C library for CYGWIN
>
> Dave,
>
> I haven't built GCC for the 555 but I have re-built GCC for the 332 
> many times and I have found that newlib is much better than stdlib 
> that comes with GCC. For example if you build the 332 source code on 
> Sourceforge with the newlib it's almost half the size of stdlib. As 
> far as printf() I have seen a number of versions for embedded work but 
> you would be required to build from source in order to use it. I don't 
> know of anything that's ready to work with SCI out of the box.
>
> Kevin
>
>     ------------------------------------------------------------------------
>
>     *From:* efi332-bounces at diy-efi.org
>     [mailto:efi332-bounces at diy-efi.org] *On Behalf Of *David Eicher
>     *Sent:* Friday, July 22, 2005 6:22 AM
>     *To:* efi332 at diy-efi.org
>     *Subject:* [Efi332] Standard GNU C library for CYGWIN
>
>         Hello list,
>
>         Has anyone built a standard C library for the GNU C running on
>         cygwin? I?m looking for the prinf( ) function (and others),
>         that have been re-directed to the SCI serial interface for
>         MPC555/565.
>
>         Thanks,
>
>         Dave
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>  
>



From bowtievette at aol.com  Sat Jul 23 08:28:26 2005
From: bowtievette at aol.com (bowtievette at aol.com)
Date: Sat, 23 Jul 2005 09:28:26 -0400
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <200507222229.2a142e1ab74119@rly-yh01.mx.aol.com>
Message-ID: <8C75DA18AE16417-938-37510@FWM-R40.sysops.aol.com>

Just use the SCI for now Dave. The QSCI is tricky to implement and its main advantage is when you want to do continuous transmission. For printf, I assume you will be sending short strings out so I would think a simple polled SCI implementation will get you what you need. You probably won't be using this interface when you are actually running your efi application.
I'm puzzled by Kevins statement with stdlib though. The efi332 code makes very little use of library functions and I have not found too much executable size change with different libraries so I'm curious what is going on there. 
 
-----Original Message-----
From: David Eicher <sailors3 at comcast.net>
To: efi332 at diy-efi.org
Sent: Fri, 22 Jul 2005 19:26:29 -0700
Subject: RE: [Efi332] Standard GNU C library for CYGWIN


Hi Kevin,
 
Yep, I?m not aware that a library exists for SCI either. So.., it looks like I?m going to build one. One thing I struggle with is, use SCI or QSCI? My ultimate goal is to be using QSCI with interrupts. But that might be a bit much to hope for initially. Maybe I?ll try to walk before I run, and just use basic character puts and gets. Then, when I?m more familiar with the process of building a library (never done it), I?ll go for the more powerful approach.
 
That is nice to know that the stdlib with GCC is so big, gotta stay away from that!
 
Thanks,
 
Dave
 
 



From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of Kevin Yachimec
Sent: Friday, July 22, 2005 9:33 AM
To: efi332 at diy-efi.org
Subject: RE: [Efi332] Standard GNU C library for CYGWIN
 
Dave,
 
I haven't built GCC for the 555 but I have re-built GCC for the 332 many times and I have found that newlib is much better than stdlib that comes with GCC.  For example if you build the 332 source code on Sourceforge with the newlib it's almost half the size of stdlib.  As far as printf() I have seen a number of versions for embedded work but you would be required to build from source in order to use it.  I don't know of anything that's ready to work with SCI out of the box.
 
Kevin
 



From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On Behalf Of David Eicher
Sent: Friday, July 22, 2005 6:22 AM
To: efi332 at diy-efi.org
Subject: [Efi332] Standard GNU C library for CYGWIN
Hello list,
 
Has anyone built a standard C library for the GNU C running on cygwin? I?m looking for the prinf( ) function (and others), that have been re-directed to the SCI serial interface for MPC555/565.
 
Thanks,
 
Dave
 
 



_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050723/90f821d6/attachment.html 

From bowtievette at aol.com  Sat Jul 23 08:31:00 2005
From: bowtievette at aol.com (bowtievette at aol.com)
Date: Sat, 23 Jul 2005 09:31:00 -0400
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <42E21B2F.6070902@udel.edu>
References: <200507230229.BKC14882@md3.nss.udel.edu>
	<42E21B2F.6070902@udel.edu>
Message-ID: <8C75DA1E61D0643-938-3751D@FWM-R40.sysops.aol.com>

I'm interested in that Doug, as I've had plenty of trouble with the QSCI already. I just can't seem to get it to work as advertised and according the traffic on the Freescale list, several others have had trouble too.  
 
-----Original Message-----
From: Doug Brunner <doug at udel.edu>
To: efi332 at diy-efi.org
Sent: Sat, 23 Jul 2005 06:25:51 -0400
Subject: Re: [Efi332] Standard GNU C library for CYGWIN


I don't know if it'll help you or not, but I've written an ISR in assembly (currently untested) that uses the QSCI, and a pair of circular buffers to feed it--this allows the ISR to keep feeding the transmit queue and pulling data off the receive queue without intervention by the main program. 
 
Let me know if you're interested, 
 
--Doug Brunner 
 
David Eicher wrote: 
 
> Hi Kevin, 
> 
> Yep, I not aware that a library exists for SCI either. So.., it > looks like I going to build one. One thing I struggle with is, use > SCI or QSCI? My ultimate goal is to be using QSCI with interrupts. But > that might be a bit much to hope for initially. Maybe Il try to walk > before I run, and just use basic character puts and gets. Then, when > I more familiar with the process of building a library (never done > it), Il go for the more powerful approach. 
> 
> That is nice to know that the stdlib with GCC is so big, gotta stay > away from that! 
> 
> Thanks, 
> 
> Dave 
> 
> ------------------------------------------------------------------------ 
> 
> *From:* efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] > *On Behalf Of *Kevin Yachimec 
> *Sent:* Friday, July 22, 2005 9:33 AM 
> *To:* efi332 at diy-efi.org 
> *Subject:* RE: [Efi332] Standard GNU C library for CYGWIN 
> 
> Dave, 
> 
> I haven't built GCC for the 555 but I have re-built GCC for the 332 > many times and I have found that newlib is much better than stdlib > that comes with GCC. For example if you build the 332 source code on > Sourceforge with the newlib it's almost half the size of stdlib. As > far as printf() I have seen a number of versions for embedded work but > you would be required to build from source in order to use it. I don't > know of anything that's ready to work with SCI out of the box. 
> 
> Kevin 
> 
> ------------------------------------------------------------------------ 
> 
> *From:* efi332-bounces at diy-efi.org 
> [mailto:efi332-bounces at diy-efi.org] *On Behalf Of *David Eicher 
> *Sent:* Friday, July 22, 2005 6:22 AM 
> *To:* efi332 at diy-efi.org 
> *Subject:* [Efi332] Standard GNU C library for CYGWIN 
> 
> Hello list, 
> 
> Has anyone built a standard C library for the GNU C running on 
> cygwin? I looking for the prinf( ) function (and others), 
> that have been re-directed to the SCI serial interface for 
> MPC555/565. 
> 
> Thanks, 
> 
> Dave 
> 
> 
> 
>------------------------------------------------------------------------ 
> 
>_______________________________________________ 
>Efi332 mailing list 
>Efi332 at diy-efi.org 
>http://lists.diy-efi.org/mailman/listinfo/efi332 
> > 
 
_______________________________________________ 
Efi332 mailing list 
Efi332 at diy-efi.org 
http://lists.diy-efi.org/mailman/listinfo/efi332 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.diy-efi.org/pipermail/efi332/attachments/20050723/41efe2b3/attachment.html 

From sailors3 at comcast.net  Sat Jul 23 09:02:48 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sat, 23 Jul 2005 07:02:48 -0700
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <42E21B2F.6070902@udel.edu>
Message-ID: <mailman.18.1311919742.4788.efi332@diy-efi.org>

Oh yeah, I'm interested. It sounds like exactly what I need for the efi
code.

Thanks,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Doug Brunner
Sent: Saturday, July 23, 2005 2:26 AM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Standard GNU C library for CYGWIN

I don't know if it'll help you or not, but I've written an ISR in 
assembly (currently untested) that uses the QSCI, and a pair of circular 
buffers to feed it--this allows the ISR to keep feeding the transmit 
queue and pulling data off the receive queue without intervention by the 
main program.

Let me know if you're interested,

--Doug Brunner

David Eicher wrote:

> Hi Kevin,
>
> Yep, I'm not aware that a library exists for SCI either. So.., it 
> looks like I'm going to build one. One thing I struggle with is, use 
> SCI or QSCI? My ultimate goal is to be using QSCI with interrupts. But 
> that might be a bit much to hope for initially. Maybe I'll try to walk 
> before I run, and just use basic character puts and gets. Then, when 
> I'm more familiar with the process of building a library (never done 
> it), I'll go for the more powerful approach.
>
> That is nice to know that the stdlib with GCC is so big, gotta stay 
> away from that!
>
> Thanks,
>
> Dave
>
> ------------------------------------------------------------------------
>
> *From:* efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] 
> *On Behalf Of *Kevin Yachimec
> *Sent:* Friday, July 22, 2005 9:33 AM
> *To:* efi332 at diy-efi.org
> *Subject:* RE: [Efi332] Standard GNU C library for CYGWIN
>
> Dave,
>
> I haven't built GCC for the 555 but I have re-built GCC for the 332 
> many times and I have found that newlib is much better than stdlib 
> that comes with GCC. For example if you build the 332 source code on 
> Sourceforge with the newlib it's almost half the size of stdlib. As 
> far as printf() I have seen a number of versions for embedded work but 
> you would be required to build from source in order to use it. I don't 
> know of anything that's ready to work with SCI out of the box.
>
> Kevin
>
>
------------------------------------------------------------------------
>
>     *From:* efi332-bounces at diy-efi.org
>     [mailto:efi332-bounces at diy-efi.org] *On Behalf Of *David Eicher
>     *Sent:* Friday, July 22, 2005 6:22 AM
>     *To:* efi332 at diy-efi.org
>     *Subject:* [Efi332] Standard GNU C library for CYGWIN
>
>         Hello list,
>
>         Has anyone built a standard C library for the GNU C running on
>         cygwin? I'm looking for the prinf( ) function (and others),
>         that have been re-directed to the SCI serial interface for
>         MPC555/565.
>
>         Thanks,
>
>         Dave
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>  
>

_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From doug at udel.edu  Sun Jul 24 09:16:25 2005
From: doug at udel.edu (Doug Brunner)
Date: Sun, 24 Jul 2005 10:16:25 -0400
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <200507231405.BKD04636@md3.nss.udel.edu>
References: <200507231405.BKD04636@md3.nss.udel.edu>
Message-ID: <42E3A2B9.7080603@udel.edu>

Here's my current codebase. The ISR is located in interrupt.s, which 
contains the exception service routine for all my interrupts, and the 
actual communications functions are in comm.c.

       --Doug Brunner

David Eicher wrote:

>Oh yeah, I'm interested. It sounds like exactly what I need for the efi
>code.
>
>Thanks,
>
>Dave
>
>
>-----Original Message-----
>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
>Behalf Of Doug Brunner
>Sent: Saturday, July 23, 2005 2:26 AM
>To: efi332 at diy-efi.org
>Subject: Re: [Efi332] Standard GNU C library for CYGWIN
>
>I don't know if it'll help you or not, but I've written an ISR in 
>assembly (currently untested) that uses the QSCI, and a pair of circular 
>buffers to feed it--this allows the ISR to keep feeding the transmit 
>queue and pulling data off the receive queue without intervention by the 
>main program.
>
>Let me know if you're interested,
>
>--Doug Brunner
>
>David Eicher wrote:
>
>  
>
>>Hi Kevin,
>>
>>Yep, I'm not aware that a library exists for SCI either. So.., it 
>>looks like I'm going to build one. One thing I struggle with is, use 
>>SCI or QSCI? My ultimate goal is to be using QSCI with interrupts. But 
>>that might be a bit much to hope for initially. Maybe I'll try to walk 
>>before I run, and just use basic character puts and gets. Then, when 
>>I'm more familiar with the process of building a library (never done 
>>it), I'll go for the more powerful approach.
>>
>>That is nice to know that the stdlib with GCC is so big, gotta stay 
>>away from that!
>>
>>Thanks,
>>
>>Dave
>>
>>------------------------------------------------------------------------
>>
>>*From:* efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] 
>>*On Behalf Of *Kevin Yachimec
>>*Sent:* Friday, July 22, 2005 9:33 AM
>>*To:* efi332 at diy-efi.org
>>*Subject:* RE: [Efi332] Standard GNU C library for CYGWIN
>>
>>Dave,
>>
>>I haven't built GCC for the 555 but I have re-built GCC for the 332 
>>many times and I have found that newlib is much better than stdlib 
>>that comes with GCC. For example if you build the 332 source code on 
>>Sourceforge with the newlib it's almost half the size of stdlib. As 
>>far as printf() I have seen a number of versions for embedded work but 
>>you would be required to build from source in order to use it. I don't 
>>know of anything that's ready to work with SCI out of the box.
>>
>>Kevin
>>
>>
>>    
>>
>------------------------------------------------------------------------
>  
>
>>    *From:* efi332-bounces at diy-efi.org
>>    [mailto:efi332-bounces at diy-efi.org] *On Behalf Of *David Eicher
>>    *Sent:* Friday, July 22, 2005 6:22 AM
>>    *To:* efi332 at diy-efi.org
>>    *Subject:* [Efi332] Standard GNU C library for CYGWIN
>>
>>        Hello list,
>>
>>        Has anyone built a standard C library for the GNU C running on
>>        cygwin? I'm looking for the prinf( ) function (and others),
>>        that have been re-directed to the SCI serial interface for
>>        MPC555/565.
>>
>>        Thanks,
>>
>>        Dave
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Efi332 mailing list
>>Efi332 at diy-efi.org
>>http://lists.diy-efi.org/mailman/listinfo/efi332
>> 
>>
>>    
>>
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>
>  
>



From sailors3 at comcast.net  Sun Jul 24 09:51:10 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sun, 24 Jul 2005 07:51:10 -0700
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <42E3A2B9.7080603@udel.edu>
Message-ID: <mailman.19.1311919742.4788.efi332@diy-efi.org>

Hi Doug,

Appreciate this. But..., I don't see an attachment. Did you embed the code
in the email? I'm not finding it.

Thanks,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Doug Brunner
Sent: Sunday, July 24, 2005 6:16 AM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Standard GNU C library for CYGWIN

Here's my current codebase. The ISR is located in interrupt.s, which 
contains the exception service routine for all my interrupts, and the 
actual communications functions are in comm.c.

       --Doug Brunner

David Eicher wrote:

>Oh yeah, I'm interested. It sounds like exactly what I need for the efi
>code.
>
>Thanks,
>
>Dave
>
>
>-----Original Message-----
>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
>Behalf Of Doug Brunner
>Sent: Saturday, July 23, 2005 2:26 AM
>To: efi332 at diy-efi.org
>Subject: Re: [Efi332] Standard GNU C library for CYGWIN
>
>I don't know if it'll help you or not, but I've written an ISR in 
>assembly (currently untested) that uses the QSCI, and a pair of circular 
>buffers to feed it--this allows the ISR to keep feeding the transmit 
>queue and pulling data off the receive queue without intervention by the 
>main program.
>
>Let me know if you're interested,
>
>--Doug Brunner
>
>David Eicher wrote:
>
>  
>
>>Hi Kevin,
>>
>>Yep, I'm not aware that a library exists for SCI either. So.., it 
>>looks like I'm going to build one. One thing I struggle with is, use 
>>SCI or QSCI? My ultimate goal is to be using QSCI with interrupts. But 
>>that might be a bit much to hope for initially. Maybe I'll try to walk 
>>before I run, and just use basic character puts and gets. Then, when 
>>I'm more familiar with the process of building a library (never done 
>>it), I'll go for the more powerful approach.
>>
>>That is nice to know that the stdlib with GCC is so big, gotta stay 
>>away from that!
>>
>>Thanks,
>>
>>Dave
>>
>>------------------------------------------------------------------------
>>
>>*From:* efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] 
>>*On Behalf Of *Kevin Yachimec
>>*Sent:* Friday, July 22, 2005 9:33 AM
>>*To:* efi332 at diy-efi.org
>>*Subject:* RE: [Efi332] Standard GNU C library for CYGWIN
>>
>>Dave,
>>
>>I haven't built GCC for the 555 but I have re-built GCC for the 332 
>>many times and I have found that newlib is much better than stdlib 
>>that comes with GCC. For example if you build the 332 source code on 
>>Sourceforge with the newlib it's almost half the size of stdlib. As 
>>far as printf() I have seen a number of versions for embedded work but 
>>you would be required to build from source in order to use it. I don't 
>>know of anything that's ready to work with SCI out of the box.
>>
>>Kevin
>>
>>
>>    
>>
>------------------------------------------------------------------------
>  
>
>>    *From:* efi332-bounces at diy-efi.org
>>    [mailto:efi332-bounces at diy-efi.org] *On Behalf Of *David Eicher
>>    *Sent:* Friday, July 22, 2005 6:22 AM
>>    *To:* efi332 at diy-efi.org
>>    *Subject:* [Efi332] Standard GNU C library for CYGWIN
>>
>>        Hello list,
>>
>>        Has anyone built a standard C library for the GNU C running on
>>        cygwin? I'm looking for the prinf( ) function (and others),
>>        that have been re-directed to the SCI serial interface for
>>        MPC555/565.
>>
>>        Thanks,
>>
>>        Dave
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Efi332 mailing list
>>Efi332 at diy-efi.org
>>http://lists.diy-efi.org/mailman/listinfo/efi332
>> 
>>
>>    
>>
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>
>  
>

_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From sailors3 at comcast.net  Sun Jul 24 11:30:10 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sun, 24 Jul 2005 09:30:10 -0700
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <20050722140134.GA31534@mailhub.intra>
Message-ID: <mailman.20.1311919742.4788.efi332@diy-efi.org>

Hello,

Okay, I'm starting to get oriented here a bit. I'm trying to figure out what
configure does, and what to use for host and target (what configure does
with these arguments). 

My host is WindowsXP (win32?), but config.sub doesn't recognize that as a
valid alias for anything, not sure if configure will accept that.

My target is MPC555, but in this context is that just powerpc? Not sure what
configure does with the target info I give it. Maybe it uses that to select
the appropriate libgloss?

I'm trying to understand which libgloss to use, don't know if it is more
appropriate to use m68k or rs6000. What actually is rs6000, when I do a
google search on it I just get IBM RS6000 server (a complete computer, not a
processor chip).

Little by little I'm unraveling the mystery here, building this library will
probably take 5 minutes, when I have all the info I need. 

Thanks,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Friday, July 22, 2005 6:02 AM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Standard GNU C library for CYGWIN

On Fri, Jul 22, 2005 at 05:21:31AM -0700, David Eicher wrote:
> Has anyone built a standard C library for the GNU C running on cygwin? I'm
> looking for the prinf( ) function (and others), that have been re-directed
> to the SCI serial interface for MPC555/565.

The "standard C library" you are looking for is newlib, and I vaguely
remember you have been checking that option a couple weeks ago.

What you need is libgloss, which some people call board
support package. Try to understand the files and concepts in
newlib-x.xx.x/libgloss/rs6000. Some of the supported boards have a
bootloader monitor, where the application jumps in for UART service via
a SW trap interface (you probably don't have that). Other systems rely
on an underlying operating system, more precisely on the BSP of that
OpSys.

Probably your system isn't supported directly, and you are operating on
the naked HW, so you have to supply your own libgloss by implementing
read(), write(), open(), sbrk() and friends, by just using the HW.
You may find an pure SCI driver or fragments of that driver also in the
68k libgloss tree, e.g. for the 6833x.

For printf you probably only need to populate write(), while other
functions can be stubbed. The linker will tell you by its error messages 
what is really needed.

gm
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From gm at ib-magin.de  Sun Jul 24 13:27:25 2005
From: gm at ib-magin.de (Gunter Magin)
Date: Sun, 24 Jul 2005 20:27:25 +0200
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <200507241634.j6OGYrx6000468@shirkhan.intra>
References: <20050722140134.GA31534@mailhub.intra>
	<200507241634.j6OGYrx6000468@shirkhan.intra>
Message-ID: <20050724182725.GA2207@mailhub.intra>

Hi,

just a few notes:

On Sun, Jul 24, 2005 at 09:30:10AM -0700, David Eicher wrote:
> Okay, I'm starting to get oriented here a bit. I'm trying to figure out what
> configure does, and what to use for host and target (what configure does
> with these arguments). 
> 
> My host is WindowsXP (win32?), but config.sub doesn't recognize that as a
> valid alias for anything, not sure if configure will accept that.

Irrelevant. Let configure find out what your host system is, by NOT
specifying the host system. In 99.9% configure's guess is correct.

> My target is MPC555, but in this context is that just powerpc? Not sure what
> configure does with the target info I give it. Maybe it uses that to select
> the appropriate libgloss?

<path_to_newlib_top_level_source_directory>/configure --target=powerpc-eabi 

newlib configure system usually builds a libgloss library for each
supported system. Just looked at an old 68k installation. There is a
libmvme162, libidp, libdbug, libbcc libgloss available, all variants
of the libgloss for a certain architecture. This would be the "golden"
way to configure your system: add a libgloss for your particular target
system, and adjust the configure.in files in that tree. It is a little
guess work, but doable.

> I'm trying to understand which libgloss to use, don't know if it is more
> appropriate to use m68k or rs6000. What actually is rs6000, when I do a
> google search on it I just get IBM RS6000 server (a complete computer, not a
> processor chip).

The POWER architecture (POWER = Performance Optimization With Enhanced
Risc) was invented and defined 20 years ago by a industry cooperation
consisting of Apple, IBM and Motorola (AIM-consortium). IBM was the
first who came out with a workstation series called RS6000 with a
multi-chip processor chipset. Soon after that, GNU got ported to that
architecture. This is the reason why we have a rs6000 subdirectory with
PowerPC usable code. At that time Apple made the transition from the 68k
MAC to the Power MAC. And Motorola used the freedom of the architecture
specification and defined the PowerPC architecture, tailored towards deep
embedded usage, by simplifying the architecture.  On of the first Motorola
chips was the MPC60x. This is the Grandfather of the MPC555's core.

As newlib uses assembler parts, you cannot use a libc made for 68k
architecture when compiling for a non-68k architecture. Furthermore, if
you configure newlib for 68k, you end up with a library which contains
(binary) code for that architecture. You cannot run 68k binary code on
a PPC core.

What I meant in a previous post regarding glancing at the 68k subtree
was to lift source code from that part of the tree (for example an SCI
driver for the 68332) into the rs6000 subtree of libgloss. You then
have to compile that lifted code with a powerpc-eabi compiler to get
something usable. The configure system for newlib enforces that. Don't
work against the configure system.

So use "--target=powerpc-eabi" as the target architecture and don't
worry about the host/build architecture. You might get tempted to use
powerpc-linux, or other powerpc target specs, but that requires an
underlying operating system, which you don't have.

BTW: Seems you have a cross compiler. Make sure you configure newlib
with the same target spec as the other cross tools, and install them
at the same prefix (normally /usr/local, unless you have specified
--prefix=...) You might fall into subtile troubles during compilation if
you don't adhere to this. Rather reconfigure and recompile binutils, gcc
with powerpc-eabi...

Bottom line: powerpc-eabi for the naked HW, and write your device drivers
bottom up. 

> Little by little I'm unraveling the mystery here, building this library will
> probably take 5 minutes, when I have all the info I need. 

5 minutes, if you have a fast host machine, and have limited the multilib
scope. In the past I have compiled newlibs for more that 4 hours only
to find I have run out of disk space...

gm


From PaulHelmuth at SprintMail.com  Sun Jul 24 14:53:58 2005
From: PaulHelmuth at SprintMail.com (Paul Helmuth)
Date: Sun, 24 Jul 2005 14:53:58 -0500
Subject: [Efi332] Building newlib/libgloss for MPC555
References: <200507241232.1dWJpi1oX3Nl34l0@mx-emperor.atl.sa.earthlink.net>
Message-ID: <00a701c59089$6e5a2d10$6b7ba8c0@p2450>

Dave,

This isn't going to be a great deal of help, but the IBM RS6000 was (maybe 
is) a line of mini-computers (at least what we used to call a mini-computer) 
from IBM that ran IBM's flavor of Unix (which was AIX). From what I have 
seen in some code fragments and other miscellaneous references, I think the 
RS6000's must have been based on IBM's PowerPC processors.

Hopefully one of the other guys that have dug through the details of 
building GCC (or at least a library) will ring in with the real answer to 
your question regarding the correct symbols/constants to have defined for 
GCC compiling on Win32 for the PowerPC target.

-Paul


----- Original Message ----- 
From: "David Eicher" <sailors3 at comcast.net>
To: <efi332 at diy-efi.org>
Sent: Sunday, July 24, 2005 11:30 AM
Subject: [Efi332] Building newlib/libgloss for MPC555


> Hello,
>
> Okay, I'm starting to get oriented here a bit. I'm trying to figure out 
> what
> configure does, and what to use for host and target (what configure does
> with these arguments).
>
> My host is WindowsXP (win32?), but config.sub doesn't recognize that as a
> valid alias for anything, not sure if configure will accept that.
>
> My target is MPC555, but in this context is that just powerpc? Not sure 
> what
> configure does with the target info I give it. Maybe it uses that to 
> select
> the appropriate libgloss?
>
> I'm trying to understand which libgloss to use, don't know if it is more
> appropriate to use m68k or rs6000. What actually is rs6000, when I do a
> google search on it I just get IBM RS6000 server (a complete computer, not 
> a
> processor chip).
>
> Little by little I'm unraveling the mystery here, building this library 
> will
> probably take 5 minutes, when I have all the info I need.
>
> Thanks,
>
> Dave
>
>
> -----Original Message-----
> From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
> Behalf Of Gunter Magin
> Sent: Friday, July 22, 2005 6:02 AM
> To: efi332 at diy-efi.org
> Subject: Re: [Efi332] Standard GNU C library for CYGWIN
>
> On Fri, Jul 22, 2005 at 05:21:31AM -0700, David Eicher wrote:
>> Has anyone built a standard C library for the GNU C running on cygwin? 
>> I'm
>> looking for the prinf( ) function (and others), that have been 
>> re-directed
>> to the SCI serial interface for MPC555/565.
>
> The "standard C library" you are looking for is newlib, and I vaguely
> remember you have been checking that option a couple weeks ago.
>
> What you need is libgloss, which some people call board
> support package. Try to understand the files and concepts in
> newlib-x.xx.x/libgloss/rs6000. Some of the supported boards have a
> bootloader monitor, where the application jumps in for UART service via
> a SW trap interface (you probably don't have that). Other systems rely
> on an underlying operating system, more precisely on the BSP of that
> OpSys.
>
> Probably your system isn't supported directly, and you are operating on
> the naked HW, so you have to supply your own libgloss by implementing
> read(), write(), open(), sbrk() and friends, by just using the HW.
> You may find an pure SCI driver or fragments of that driver also in the
> 68k libgloss tree, e.g. for the 6833x.
>
> For printf you probably only need to populate write(), while other
> functions can be stubbed. The linker will tell you by its error messages
> what is really needed.
>
> gm
> _______________________________________________
> Efi332 mailing list
> Efi332 at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/efi332
>
> _______________________________________________
> Efi332 mailing list
> Efi332 at diy-efi.org
> http://lists.diy-efi.org/mailman/listinfo/efi332
> 



From doug at udel.edu  Sun Jul 24 17:49:18 2005
From: doug at udel.edu (Doug Brunner)
Date: Sun, 24 Jul 2005 18:49:18 -0400
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <200507241453.BKH95269@md4.nss.udel.edu>
References: <200507241453.BKH95269@md4.nss.udel.edu>
Message-ID: <42E41AEE.600@udel.edu>

Oops...forgot to attach it.

David Eicher wrote:

>Hi Doug,
>
>Appreciate this. But..., I don't see an attachment. Did you embed the code
>in the email? I'm not finding it.
>
>Thanks,
>
>Dave
>
>
>-----Original Message-----
>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
>Behalf Of Doug Brunner
>Sent: Sunday, July 24, 2005 6:16 AM
>To: efi332 at diy-efi.org
>Subject: Re: [Efi332] Standard GNU C library for CYGWIN
>
>Here's my current codebase. The ISR is located in interrupt.s, which 
>contains the exception service routine for all my interrupts, and the 
>actual communications functions are in comm.c.
>
>       --Doug Brunner
>
>David Eicher wrote:
>
>  
>
>>Oh yeah, I'm interested. It sounds like exactly what I need for the efi
>>code.
>>
>>Thanks,
>>
>>Dave
>>
>>
>>-----Original Message-----
>>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
>>Behalf Of Doug Brunner
>>Sent: Saturday, July 23, 2005 2:26 AM
>>To: efi332 at diy-efi.org
>>Subject: Re: [Efi332] Standard GNU C library for CYGWIN
>>
>>I don't know if it'll help you or not, but I've written an ISR in 
>>assembly (currently untested) that uses the QSCI, and a pair of circular 
>>buffers to feed it--this allows the ISR to keep feeding the transmit 
>>queue and pulling data off the receive queue without intervention by the 
>>main program.
>>
>>Let me know if you're interested,
>>
>>--Doug Brunner
>>
>>David Eicher wrote:
>>
>> 
>>
>>    
>>
>>>Hi Kevin,
>>>
>>>Yep, I'm not aware that a library exists for SCI either. So.., it 
>>>looks like I'm going to build one. One thing I struggle with is, use 
>>>SCI or QSCI? My ultimate goal is to be using QSCI with interrupts. But 
>>>that might be a bit much to hope for initially. Maybe I'll try to walk 
>>>before I run, and just use basic character puts and gets. Then, when 
>>>I'm more familiar with the process of building a library (never done 
>>>it), I'll go for the more powerful approach.
>>>
>>>That is nice to know that the stdlib with GCC is so big, gotta stay 
>>>away from that!
>>>
>>>Thanks,
>>>
>>>Dave
>>>
>>>------------------------------------------------------------------------
>>>
>>>*From:* efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] 
>>>*On Behalf Of *Kevin Yachimec
>>>*Sent:* Friday, July 22, 2005 9:33 AM
>>>*To:* efi332 at diy-efi.org
>>>*Subject:* RE: [Efi332] Standard GNU C library for CYGWIN
>>>
>>>Dave,
>>>
>>>I haven't built GCC for the 555 but I have re-built GCC for the 332 
>>>many times and I have found that newlib is much better than stdlib 
>>>that comes with GCC. For example if you build the 332 source code on 
>>>Sourceforge with the newlib it's almost half the size of stdlib. As 
>>>far as printf() I have seen a number of versions for embedded work but 
>>>you would be required to build from source in order to use it. I don't 
>>>know of anything that's ready to work with SCI out of the box.
>>>
>>>Kevin
>>>
>>>
>>>   
>>>
>>>      
>>>
>>------------------------------------------------------------------------
>> 
>>
>>    
>>
>>>   *From:* efi332-bounces at diy-efi.org
>>>   [mailto:efi332-bounces at diy-efi.org] *On Behalf Of *David Eicher
>>>   *Sent:* Friday, July 22, 2005 6:22 AM
>>>   *To:* efi332 at diy-efi.org
>>>   *Subject:* [Efi332] Standard GNU C library for CYGWIN
>>>
>>>       Hello list,
>>>
>>>       Has anyone built a standard C library for the GNU C running on
>>>       cygwin? I'm looking for the prinf( ) function (and others),
>>>       that have been re-directed to the SCI serial interface for
>>>       MPC555/565.
>>>
>>>       Thanks,
>>>
>>>       Dave
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Efi332 mailing list
>>>Efi332 at diy-efi.org
>>>http://lists.diy-efi.org/mailman/listinfo/efi332
>>>
>>>
>>>   
>>>
>>>      
>>>
>>_______________________________________________
>>Efi332 mailing list
>>Efi332 at diy-efi.org
>>http://lists.diy-efi.org/mailman/listinfo/efi332
>>
>>_______________________________________________
>>Efi332 mailing list
>>Efi332 at diy-efi.org
>>http://lists.diy-efi.org/mailman/listinfo/efi332
>>
>> 
>>
>>    
>>
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: code.tar.gz
Type: application/x-gzip
Size: 12893 bytes
Desc: not available
Url : http://lists.diy-efi.org/pipermail/efi332/attachments/20050724/4c558b00/attachment.gz 

From sailors3 at comcast.net  Sun Jul 24 20:36:26 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sun, 24 Jul 2005 18:36:26 -0700
Subject: [Efi332] Standard GNU C library for CYGWIN
In-Reply-To: <42E41AEE.600@udel.edu>
Message-ID: <mailman.21.1311919742.4788.efi332@diy-efi.org>

Thanks Doug, I'll take a look at it.

Regards,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Doug Brunner
Sent: Sunday, July 24, 2005 2:49 PM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Standard GNU C library for CYGWIN

Oops...forgot to attach it.

David Eicher wrote:

>Hi Doug,
>
>Appreciate this. But..., I don't see an attachment. Did you embed the code
>in the email? I'm not finding it.
>
>Thanks,
>
>Dave
>
>
>-----Original Message-----
>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
>Behalf Of Doug Brunner
>Sent: Sunday, July 24, 2005 6:16 AM
>To: efi332 at diy-efi.org
>Subject: Re: [Efi332] Standard GNU C library for CYGWIN
>
>Here's my current codebase. The ISR is located in interrupt.s, which 
>contains the exception service routine for all my interrupts, and the 
>actual communications functions are in comm.c.
>
>       --Doug Brunner
>
>David Eicher wrote:
>
>  
>
>>Oh yeah, I'm interested. It sounds like exactly what I need for the efi
>>code.
>>
>>Thanks,
>>
>>Dave
>>
>>
>>-----Original Message-----
>>From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
>>Behalf Of Doug Brunner
>>Sent: Saturday, July 23, 2005 2:26 AM
>>To: efi332 at diy-efi.org
>>Subject: Re: [Efi332] Standard GNU C library for CYGWIN
>>
>>I don't know if it'll help you or not, but I've written an ISR in 
>>assembly (currently untested) that uses the QSCI, and a pair of circular 
>>buffers to feed it--this allows the ISR to keep feeding the transmit 
>>queue and pulling data off the receive queue without intervention by the 
>>main program.
>>
>>Let me know if you're interested,
>>
>>--Doug Brunner
>>
>>David Eicher wrote:
>>
>> 
>>
>>    
>>
>>>Hi Kevin,
>>>
>>>Yep, I'm not aware that a library exists for SCI either. So.., it 
>>>looks like I'm going to build one. One thing I struggle with is, use 
>>>SCI or QSCI? My ultimate goal is to be using QSCI with interrupts. But 
>>>that might be a bit much to hope for initially. Maybe I'll try to walk 
>>>before I run, and just use basic character puts and gets. Then, when 
>>>I'm more familiar with the process of building a library (never done 
>>>it), I'll go for the more powerful approach.
>>>
>>>That is nice to know that the stdlib with GCC is so big, gotta stay 
>>>away from that!
>>>
>>>Thanks,
>>>
>>>Dave
>>>
>>>------------------------------------------------------------------------
>>>
>>>*From:* efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] 
>>>*On Behalf Of *Kevin Yachimec
>>>*Sent:* Friday, July 22, 2005 9:33 AM
>>>*To:* efi332 at diy-efi.org
>>>*Subject:* RE: [Efi332] Standard GNU C library for CYGWIN
>>>
>>>Dave,
>>>
>>>I haven't built GCC for the 555 but I have re-built GCC for the 332 
>>>many times and I have found that newlib is much better than stdlib 
>>>that comes with GCC. For example if you build the 332 source code on 
>>>Sourceforge with the newlib it's almost half the size of stdlib. As 
>>>far as printf() I have seen a number of versions for embedded work but 
>>>you would be required to build from source in order to use it. I don't 
>>>know of anything that's ready to work with SCI out of the box.
>>>
>>>Kevin
>>>
>>>
>>>   
>>>
>>>      
>>>
>>------------------------------------------------------------------------
>> 
>>
>>    
>>
>>>   *From:* efi332-bounces at diy-efi.org
>>>   [mailto:efi332-bounces at diy-efi.org] *On Behalf Of *David Eicher
>>>   *Sent:* Friday, July 22, 2005 6:22 AM
>>>   *To:* efi332 at diy-efi.org
>>>   *Subject:* [Efi332] Standard GNU C library for CYGWIN
>>>
>>>       Hello list,
>>>
>>>       Has anyone built a standard C library for the GNU C running on
>>>       cygwin? I'm looking for the prinf( ) function (and others),
>>>       that have been re-directed to the SCI serial interface for
>>>       MPC555/565.
>>>
>>>       Thanks,
>>>
>>>       Dave
>>>
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>Efi332 mailing list
>>>Efi332 at diy-efi.org
>>>http://lists.diy-efi.org/mailman/listinfo/efi332
>>>
>>>
>>>   
>>>
>>>      
>>>
>>_______________________________________________
>>Efi332 mailing list
>>Efi332 at diy-efi.org
>>http://lists.diy-efi.org/mailman/listinfo/efi332
>>
>>_______________________________________________
>>Efi332 mailing list
>>Efi332 at diy-efi.org
>>http://lists.diy-efi.org/mailman/listinfo/efi332
>>
>> 
>>
>>    
>>
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>
>_______________________________________________
>Efi332 mailing list
>Efi332 at diy-efi.org
>http://lists.diy-efi.org/mailman/listinfo/efi332
>
>  
>




From sailors3 at comcast.net  Sun Jul 24 21:54:00 2005
From: sailors3 at comcast.net (David Eicher)
Date: Sun, 24 Jul 2005 19:54:00 -0700
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <20050724182725.GA2207@mailhub.intra>
Message-ID: <mailman.22.1311919742.4788.efi332@diy-efi.org>

Wow, thanks Gunter! Appreciate the history on PowerPC, not wonder I'm so
confused all the time. I designed and built a 68000 based computer in the
late 1970s (1977,8?), I paid $360 for an engineering sample of the part. I
learned and loved that instruction set (only 58 instructions and 14
addressing modes). But my company went Intel......, no tools for Motorola
processors, so I lost track of where that all went, I saw a little here and
there on 68010, 68020 --- 68040, and then lost it completely. For years I've
thought the PowerPC was just where those processors ended up. You can
imagine my shock when I started debugging the ported quickstart/eabi code
and discovered the instruction set was nothing like I remembered. 

Thanks to you I think I'm starting to pull this thing together.

>BTW: Seems you have a cross compiler. Make sure you configure newlib
>with the same target spec as the other cross tools, and install them
>at the same prefix (normally /usr/local, unless you have specified
>--prefix=...) You might fall into subtile troubles during compilation if
>you don't adhere to this. Rather reconfigure and recompile binutils, gcc
>with powerpc-eabi...

My GNU tools (Macraigor) are at usr/local/bin (gcc, as, ld). I want to make
sure I correctly interpret your comments. My newlib-1.13.0 under
usr/local/powerpc-elf/newlib-1.13.0 because of the way I interpreted the
instructions in their readme file. So, would you say that is the correct
prefix then? Another concern I have then, I'm not sure what the target spec
is for my cross tools, I just took what Macraigor had on their website. One
of my linker flags is -melf32ppc, which I believe I saw in a Macraigor demo
makefile. I'm not sure it this is a useful hint of what the target spec
might be or not.

>What I meant in a previous post regarding glancing at the 68k subtree
>was to lift source code from that part of the tree (for example an SCI
>driver for the 68332) into the rs6000 subtree of libgloss. You then
>have to compile that lifted code with a powerpc-eabi compiler to get
>something usable. The configure system for newlib enforces that. Don't
>work against the configure system.

I see..., okay. I've got tested routines for SCI, routines built on the
eabi. So.., it looks like I can just go into the inbyte and outbyte routines
and replace with code with mine. No..., at least one of the inbyte.c files
under libgloss has a read( ) call in it. So there must be a read and write I
need to modify. Well, I'll just try running the configure. Maybe during the
build somewhere the linker will tell me what it needs (like you suggested
earlier).

MERCY! I just worked up the courage to run configure, then make. Configure
made some wrong decisions, and make didn't go very far. I suspect I have the
troubles you are referring to above, I'm not in the right directories.

So..., it looks like I have to find the right place in the directory
structure. Problems include:

1) Configure decided I don't have a cross compiler, but I do.
2) Configure found the tools to build GNU on the host (i686), not the tools
to build a powerpc program..., hmmm.
3) make assumed the compiler is powerpc-eabi-gcc, but mine is
powerpc-elf-gcc, could this be a result of using target=powerpc-eabi?

Man oh man, this thing is complicated! A 256k makefile! I'm a beginner at
makefile language, this could take a while.....

It could be I just have one or two issues to fix, the key is identifying
what they are, and taking the correct action. I've included the outputs from
configure and make below, if anyone has the time to look them over. I know
you are all busy too...

Sure do appreciate the help, thanks again,

Dave

===================configure===========================
Dave at Dell8400 /usr/local/powerpc-elf/newlib-ppc-aout
$ ../newlib-1.13.0/configure --target=powerpc-eabi
creating cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... powerpc-unknown-eabi
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
-v: not found
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for correct version of gmp.h... no
checking for bison... bison
checking for bison... bison -y
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for i686-pc-cygwin-ar... no
checking for ar... ar
checking for i686-pc-cygwin-as... no
checking for as... as
checking for i686-pc-cygwin-dlltool... no
checking for dlltool... dlltool
checking for i686-pc-cygwin-ld...
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld.exe
checking for i686-pc-cygwin-nm... no
checking for nm... nm
checking for i686-pc-cygwin-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-cygwin-windres... no
checking for windres... windres
checking for i686-pc-cygwin-objcopy... no
checking for objcopy... objcopy
checking for i686-pc-cygwin-objdump... no
checking for objdump... objdump
checking for powerpc-eabi-ar... no
checking for powerpc-eabi-as... no
checking for powerpc-eabi-dlltool... no
checking for powerpc-eabi-ld... no
checking for powerpc-eabi-nm... no
checking for powerpc-eabi-ranlib... no
checking for powerpc-eabi-windres... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking if symbolic links between directories work... yes
updating cache ./config.cache
creating ./config.status
creating Makefile

=======================Make ============================
Dave at Dell8400 /usr/local/powerpc-elf/newlib-ppc-aout
$ make
Configuring in etc
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
updating cache ./config.cache
creating ./config.status
creating Makefile
make[1]: Entering directory `/usr/local/powerpc-elf/newlib-ppc-aout/etc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/local/powerpc-elf/newlib-ppc-aout/etc'
Checking multilib configuration...
powerpc-eabi-gcc: not found
mv: cannot stat `multilib.tmp': No such file or directory
make: *** [multilib.out] Error 1

Dave at Dell8400 /usr/local/powerpc-elf/newlib-ppc-aout
$



From gm at ib-magin.de  Mon Jul 25 00:59:21 2005
From: gm at ib-magin.de (Gunter Magin)
Date: Mon, 25 Jul 2005 07:59:21 +0200
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <200507250300.j6P30G4d014920@shirkhan.intra>
References: <20050724182725.GA2207@mailhub.intra>
	<200507250300.j6P30G4d014920@shirkhan.intra>
Message-ID: <20050725055921.GA17019@mailhub.intra>

Hi,

On Sun, Jul 24, 2005 at 07:54:00PM -0700, David Eicher wrote:
> >BTW: Seems you have a cross compiler. Make sure you configure newlib
> >with the same target spec as the other cross tools, and install them
> >at the same prefix (normally /usr/local, unless you have specified
> >--prefix=...) You might fall into subtile troubles during compilation if
> >you don't adhere to this. Rather reconfigure and recompile binutils, gcc
> >with powerpc-eabi...
> 
> My GNU tools (Macraigor) are at usr/local/bin (gcc, as, ld). I want to make
> sure I correctly interpret your comments. My newlib-1.13.0 under
> usr/local/powerpc-elf/newlib-1.13.0 because of the way I interpreted the
> instructions in their readme file. 

Your newlib SOURCE tree can be anywhere. I find it a little strange
(though not false) to put it where normally executables and libraries
live. Maybe a misunderstanding on your part. Anyway, it is only important
where you install the libraries, so the linker can find it in the end.
And this has to do with which --prefix= binutils have been compiled. 

It seems Macraiger used --target=powerpc-elf for configuring,
and you should adhere to that for configuring newlib, instead
of powerpc-eabi. This is the reason why configure didn't find the
cross compiler. Also make sure the Macraigor cross tools are in your
search-$PATH for executables.

> So, would you say that is the correct
> prefix then? Another concern I have then, I'm not sure what the target spec
> is for my cross tools, I just took what Macraigor had on their website. One
> of my linker flags is -melf32ppc, which I believe I saw in a Macraigor demo
> makefile. I'm not sure it this is a useful hint of what the target spec
> might be or not.

Don't worry for that at the moment. However, once you have newlib and
start building actual target code, this might become an issue. But less
an issue, if you build on the naked HW. I use a "-mcpu=505 -msoft-float"
in my MPC5xx projects, but you might try "-mcpu=555 -msoft-float" as
well.

> >What I meant in a previous post regarding glancing at the 68k subtree
> >was to lift source code from that part of the tree (for example an SCI
> >driver for the 68332) into the rs6000 subtree of libgloss. You then
> >have to compile that lifted code with a powerpc-eabi compiler to get
> >something usable. The configure system for newlib enforces that. Don't
> >work against the configure system.
> 
> I see..., okay. I've got tested routines for SCI, routines built on the
> eabi. So.., it looks like I can just go into the inbyte and outbyte routines
> and replace with code with mine. No..., at least one of the inbyte.c files
> under libgloss has a read( ) call in it. So there must be a read and write I
> need to modify. Well, I'll just try running the configure. Maybe during the
> build somewhere the linker will tell me what it needs (like you suggested
> earlier).

Have look at the mbx target in libgloss/rs6000: this is a MPC860/MPC823
evaluation board with a monitor. If you lift the mbx-files and substitute
the inbyte/outbyte functions with your SCI driver functions, I guess
this would be the easiest path. Just have a look for "mbx" and
duplicate/modify/adjust.

> So..., it looks like I have to find the right place in the directory
> structure. Problems include:
> 
> 1) Configure decided I don't have a cross compiler, but I do.

Give powerpc-eabi -> powerpc-elf a try. Not sure if configure treats it
the same anyway....

> 2) Configure found the tools to build GNU on the host (i686), not the tools
> to build a powerpc program..., hmmm.

Probably the same cuase.

> 3) make assumed the compiler is powerpc-eabi-gcc, but mine is
> powerpc-elf-gcc, could this be a result of using target=powerpc-eabi?

Exactly.

> Man oh man, this thing is complicated! A 256k makefile! I'm a beginner at
> makefile language, this could take a while.....

Don't waste your time understanding that Makefile in full extent. I
don't either and still have a working cross tool chain...

> Dave at Dell8400 /usr/local/powerpc-elf/newlib-ppc-aout
                                       ^^^^^^^^^^^^^^^
Any reason for choosing that particular name for the wrk subdirectory?
I guess these are historical reasons, and only the chosen name reflects
an obsolete wish to generate an ppc-aout cross tool chain....

> $ ../newlib-1.13.0/configure --target=powerpc-eabi
> creating cache ./config.cache
> checking host system type... i686-pc-cygwin
                               ^^^^^^^^^^^^^^
Configure isn't that bad in guessing the host system, is it??

> checking target system type... powerpc-unknown-eabi
                                 ^^^^^^^^^^^^^^^^^^^^
Configure's expansion of your given shortcut "powerpc-eabi"

> checking build system type... i686-pc-cygwin
....
> checking for powerpc-eabi-ar... no

So configure looks for $(TARGET)-ar and doesn't find it. That's ok,
because you have powerpc-elf-ar and friends instead. Adjust --target,
and you will be in the position to compile newlib. Only then start to
modify libgloss with your SCI driver.

And another hint: Once you have installed a libgloss for your system,
test it by calling inbyte/outbyte directly from the application. Avoid
the detour over printf(), read()/write() until you are sure that
inbyte()/outbyte() does what you want. You should also pull the relevant
source files for inbyte()/outbyte() into your working directory, and
let the linker not pull it from /usr/local/powerpc-elf/lib/libxxx.a,
so you can debug them. 

This makes sense even before you fire up the big newlib make: when you
let the linker pull in functions from a library, you might have a hard
time to explain the debugger where the source code for that library
function is. This is especially troublesome for libgloss functions, as
there is a set of source files all implementing the same function, just
for a different target board.  Usually a debugger picks the first one...

gm


From sailors3 at comcast.net  Mon Jul 25 22:01:13 2005
From: sailors3 at comcast.net (David Eicher)
Date: Mon, 25 Jul 2005 20:01:13 -0700
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <20050725055921.GA17019@mailhub.intra>
Message-ID: <mailman.23.1311919742.4788.efi332@diy-efi.org>

Hello, thanks again for the input:

1) I chose usr/local/power-elf because I thought that was what the readme
file at source.redhat.com was telling me to do. It is definitely not the
only thing I have misinterpreted.

I moved it to usr/local/newlib-1.13.0.

I followed the instructions in the readme exactly and created a new
directory called newlib-ppc-aout (following their convention in the
instructions). 

I ran configure using --target=powerpc-elf

It did better this time, it found my compiler/linker/etc. But still decided
I don't have a cross compiler. Hmmmm, not sure what is going on there.

Maybe issue 1 and 2 below are corrected, can't tell from the configure
output for sure, I suppose I'll run make and see what happens. Issue 3 is
fixed. 

I picked the name newlib-ppc-aout because the readme file with newlib gave
mewlib-m68k-aout as an example, so I just used their suggestion with ppc.
Bad idea? 

Not sure what you mean by obsolete wish, but there is abviously something
going on that I don't understand. I thought I wanted to build the newlib
with code for the ppc (powerpc), is that not correct? And I want to modify
libgloss to be an interface to my hardware, so I need to compile that for
powerpc too, no? If I have this all mixed up, that could be why I'm not
getting much to run.

Thanks for the input on the order to do things, there is no info on that in
the readme file. So I should run make and get newlib to build before I
modify libgloss. I suppose the linker errors will tell me what I need in
libgloss.

I know this is bad, but I don't even have a source level debugger working
yet. So far I've debugged everything using OCDCommander in assembly
language. I'm hoping to get gdb and insight working soon, and then I'll have
to figure out how to tell if where the source is. Thanks for the hints.

Well, I kicked off make, it's been running for 5 minutes and is showing no
signs of finishing..., it must be doing something good. I hope I don't run
out of disk space. I forgot to ask how to limit the scope of this build.

Regards,

Dave

=========== configure output =========================

Dave at Dell8400 /usr/local/newlib-1.13.0
$ mkdir ../newlib-ppc-aout

Dave at Dell8400 /usr/local/newlib-1.13.0
$ cd ../newlib-ppc-aout

Dave at Dell8400 /usr/local/newlib-ppc-aout
$ ../newlib-1.13.0/configure --target=powerpc-elf
creating cache ./config.cache
checking host system type... i686-pc-cygwin
checking target system type... powerpc-unknown-elf
checking build system type... i686-pc-cygwin
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
-v: not found
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... no
checking whether compiler driver understands Ada... no
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1
$$f2
checking for correct version of gmp.h... no
checking for bison... bison
checking for bison... bison -y
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for i686-pc-cygwin-ar... no
checking for ar... ar
checking for i686-pc-cygwin-as... no
checking for as... as
checking for i686-pc-cygwin-dlltool... no
checking for dlltool... dlltool
checking for i686-pc-cygwin-ld...
/usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld.exe
checking for i686-pc-cygwin-nm... no
checking for nm... nm
checking for i686-pc-cygwin-ranlib... no
checking for ranlib... ranlib
checking for i686-pc-cygwin-windres... no
checking for windres... windres
checking for i686-pc-cygwin-objcopy... no
checking for objcopy... objcopy
checking for i686-pc-cygwin-objdump... no
checking for objdump... objdump
checking for powerpc-elf-ar... powerpc-elf-ar
checking for powerpc-elf-as... powerpc-elf-as
checking for powerpc-elf-dlltool... no
checking for powerpc-elf-ld... powerpc-elf-ld
checking for powerpc-elf-nm... powerpc-elf-nm
checking for powerpc-elf-ranlib... powerpc-elf-ranlib
checking for powerpc-elf-windres... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking if symbolic links between directories work... yes
updating cache ./config.cache
creating ./config.status
creating Makefile




-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Sunday, July 24, 2005 9:59 PM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Building newlib/libgloss for MPC555

> 
> 1) Configure decided I don't have a cross compiler, but I do.

Give powerpc-eabi -> powerpc-elf a try. Not sure if configure treats it
the same anyway....

> 2) Configure found the tools to build GNU on the host (i686), not the
tools
> to build a powerpc program..., hmmm.

Probably the same cuase.

> 3) make assumed the compiler is powerpc-eabi-gcc, but mine is
> powerpc-elf-gcc, could this be a result of using target=powerpc-eabi?

Exactly.




From sailors3 at comcast.net  Tue Jul 26 06:27:36 2005
From: sailors3 at comcast.net (David Eicher)
Date: Tue, 26 Jul 2005 04:27:36 -0700
Subject: [Efi332] Building newlib/libgloss for MPC555
Message-ID: <mailman.24.1311919742.4788.efi332@diy-efi.org>

Hello,

I started make before going to bed, I don't know how long it ran, but it was
quite a while. Under the directory I created I now have:

Usr/local/newlib-ppc-aout
		Etc
		Powerpc-elf

Under powerpc-elf I have:
		Le
		Newlib
		Nof
		Und

Under each of these directory le I have:
		Libgloss
		Newlib
		und

Under each of these directory nof I have:
		Le
		Libgloss
		Newlib
		Und

Under each of these directory und I have:
		Libgloss
		Newlib

Under each of these subdirectories there are tons of files and libraries. I
am now looking for documentation that explains which of these sets of
directories I'm suppose to work with to get me a lib or two I can link in
with my target code. There are almost countless numbers of libraries here,
how does one choose?

This is exciting progress, thanks much for all the help.

Thanks,

Dave





From gm at ib-magin.de  Tue Jul 26 08:10:18 2005
From: gm at ib-magin.de (Gunter Magin)
Date: Tue, 26 Jul 2005 15:10:18 +0200
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <200507261131.j6QBVh91005403@shirkhan.intra>
References: <200507261131.j6QBVh91005403@shirkhan.intra>
Message-ID: <20050726131017.GA7329@mailhub.intra>

On Tue, Jul 26, 2005 at 04:27:36AM -0700, David Eicher wrote:
> Hello,
> 
> I started make before going to bed, I don't know how long it ran, but it was
> quite a while. Under the directory I created I now have:

<...>
Looks good. Congrats.

Don't forget to run a "make install" in the toplevel newlib work
directory, (the one in which you called ../newlib-x.x.x/configure). This
run transfers the relevant end results of your nightly compile run into
the installation directory. Otherwise, your target app Makefile will
not find the libs and include files. You have specified the install path
with the --prefix option (or left the default /usr/local), and that is
merged into the Makefiles in the work tree.

After that, you are free to cleanup (purge) the build tree, and recover
some MB disk space, for example run a "make clean". But wait, you still
have to add libgloss support for your particular target board....

> Under each of these subdirectories there are tons of files and libraries. I
> am now looking for documentation that explains which of these sets of
> directories I'm suppose to work with to get me a lib or two I can link in
> with my target code. There are almost countless numbers of libraries here,
> how does one choose?

Now you know why your Makefile is that long: it contains these
informations.

gm


From sailors3 at comcast.net  Tue Jul 26 09:08:26 2005
From: sailors3 at comcast.net (David Eicher)
Date: Tue, 26 Jul 2005 07:08:26 -0700
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <20050726131017.GA7329@mailhub.intra>
Message-ID: <mailman.25.1311919742.4788.efi332@diy-efi.org>

Thanks Gunter, Hmmmm, there is no mention of an "install" step in the readme
file on the newlib website. I think you saved my bacon here.

I'll do that tonight when I get home from work. I assume it will be obvious
which library to use, and what to modify to get the new libgloss, and how to
build libgloss after it is modified.

Thanks much,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Tuesday, July 26, 2005 5:10 AM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Building newlib/libgloss for MPC555

On Tue, Jul 26, 2005 at 04:27:36AM -0700, David Eicher wrote:
> Hello,
> 
> I started make before going to bed, I don't know how long it ran, but it
was
> quite a while. Under the directory I created I now have:

<...>
Looks good. Congrats.

Don't forget to run a "make install" in the toplevel newlib work
directory, (the one in which you called ../newlib-x.x.x/configure). This
run transfers the relevant end results of your nightly compile run into
the installation directory. Otherwise, your target app Makefile will
not find the libs and include files. You have specified the install path
with the --prefix option (or left the default /usr/local), and that is
merged into the Makefiles in the work tree.

After that, you are free to cleanup (purge) the build tree, and recover
some MB disk space, for example run a "make clean". But wait, you still
have to add libgloss support for your particular target board....

> Under each of these subdirectories there are tons of files and libraries.
I
> am now looking for documentation that explains which of these sets of
> directories I'm suppose to work with to get me a lib or two I can link in
> with my target code. There are almost countless numbers of libraries here,
> how does one choose?

Now you know why your Makefile is that long: it contains these
informations.

gm
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From sailors3 at comcast.net  Tue Jul 26 22:03:12 2005
From: sailors3 at comcast.net (David Eicher)
Date: Tue, 26 Jul 2005 20:03:12 -0700
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <20050726131017.GA7329@mailhub.intra>
Message-ID: <mailman.26.1311919742.4788.efi332@diy-efi.org>

Well, I ran the install, it installed in my compiler directory
(powerpc-elf), so I moved the lib and include directories to
usr/local/lib/powerpc-elf/lib and usr/local/lib/powerpc-elf/include. It's
amazing I've got this far, thanks much for all the help. 

The bad news..., I have libraries in the lib directory, but also a
subdirectory called "le" has libraries in it, as well as "nof" and "nof/le"
and "nof/und" and "und". So, there are about six libc, six libm, etc.

Does anyone know what these directories are for? Which copy of the libraries
should I point my linker to when I build target code?

I need to modify my libgloss too, and am looking for documentation/input on
how to build that library.

Thanks much for any insight you might be able to offer.

Dave




-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Tuesday, July 26, 2005 5:10 AM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Building newlib/libgloss for MPC555

On Tue, Jul 26, 2005 at 04:27:36AM -0700, David Eicher wrote:
> Hello,
> 
> I started make before going to bed, I don't know how long it ran, but it
was
> quite a while. Under the directory I created I now have:

<...>
Looks good. Congrats.

Don't forget to run a "make install" in the toplevel newlib work
directory, (the one in which you called ../newlib-x.x.x/configure). This
run transfers the relevant end results of your nightly compile run into
the installation directory. Otherwise, your target app Makefile will
not find the libs and include files. You have specified the install path
with the --prefix option (or left the default /usr/local), and that is
merged into the Makefiles in the work tree.

After that, you are free to cleanup (purge) the build tree, and recover
some MB disk space, for example run a "make clean". But wait, you still
have to add libgloss support for your particular target board....

> Under each of these subdirectories there are tons of files and libraries.
I
> am now looking for documentation that explains which of these sets of
> directories I'm suppose to work with to get me a lib or two I can link in
> with my target code. There are almost countless numbers of libraries here,
> how does one choose?

Now you know why your Makefile is that long: it contains these
informations.

gm
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From gm at ib-magin.de  Wed Jul 27 01:55:10 2005
From: gm at ib-magin.de (Gunter Magin)
Date: Wed, 27 Jul 2005 08:55:10 +0200
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <200507270309.j6R39uGV026980@shirkhan.intra>
References: <20050726131017.GA7329@mailhub.intra>
	<200507270309.j6R39uGV026980@shirkhan.intra>
Message-ID: <20050727065510.GA30126@mailhub.intra>

On Tue, Jul 26, 2005 at 08:03:12PM -0700, David Eicher wrote:
> Well, I ran the install, it installed in my compiler directory
> (powerpc-elf), so I moved the lib and include directories to
> usr/local/lib/powerpc-elf/lib and usr/local/lib/powerpc-elf/include. It's
> amazing I've got this far, thanks much for all the help. 

I am not sure if you got that right in all the details, as from the
paths you reported, the install run shouldn't have put it into the
wrk directory /usr/local/powerpc-elf/ppc-aout, and also not under
/usr/local/powerpc-elf/newlib-1.13.0. What bothered you seems that it
installed it into /usr/local/powerpc-elf, but that is exactly where
it should live. IMHO it would be more safe if you had your source and
work directories somewhere outside /usr/local/powerpc-elf.  Just keep
in mind this might be the cause of trouble once powerpc-elf-gcc barks
at you for not finding stuff when linking... I'd redo the unpack
newlib/configure/compile/install step from another directory, after
renaming /usr/local/powerpc-elf into something else...

> The bad news..., I have libraries in the lib directory, but also a
> subdirectory called "le" has libraries in it, as well as "nof" and "nof/le"
> and "nof/und" and "und". So, there are about six libc, six libm, etc.

Normal. This is the result of the multilib approach, that is, the libs
are generated for each configured variant of target architecture. 'le' is
little endian, 'nof' is 'no floating point'.  Not sure what 'und' means.
Subdirectories contain combinations, that is 'nof/le' is nofloatingpt &&
little endian.

Newlib's configure fetches the possible multilib combinations from the
crosscompiler (try "powerpc-elf -print-multi-lib" and "powerpc-elf
-print-multi-directory"), which is a good thing, because then only those
multilib combinations are generated, for which the compiler also has
support, and your app code can be taylored for. Which target arch is
addressed for your app code is controlled with gcc's -m options. And the
gcc frontend fetches libraries from the right multilib subdirectory if
you call the linking phase with the same arch options than the compilation
runs. That's why I suggested to use -mcpu=505 or something.

> Does anyone know what these directories are for? Which copy of the libraries
> should I point my linker to when I build target code?

You don't need to worry which lib to choose as long as you use gcc for
linking, and not ld directly. For using ld (not recommended), you are
right: you have to select the lib path on your own, and this can lead to
a lot of hidden bugs if, for example, your app code has soft-float, but
you link in a hard-float library, where your processor has no fpu, or
has the fpu switched off.

> I need to modify my libgloss too, and am looking for documentation/input on
> how to build that library.

cd <newlib-wrk-directory>/powerpc-elf/libgloss; make; make install

That is a shortcut, to avoid building the whole newlib enchilada.
However, this shortcut would not be absolutely necessary, as re-building
the whole tree would require a significant less amount of time, as
most .o files are already available from the initial make run for all
newlib. (once again: this is Makefile magic)

You might try "make dvi" or "make html" or something in newlib's top
workdir, or some relevant subdirectory of your wrk tree, but I doubt
there is anything on libgloss. Haven't checked recently, though. Ok,
a quick glance revealed that there is the document "Embed with GNU",
and there are also examples to show the general principle, however not
for powerpc. Don't let you get disturbed by the statement that there is
libgloss support only for 68k, mips, sparc, PA risc. This document is
10 years old... so it might be no BIG help.

To actually write (or rather to port, as I understood, you already have
a driver source fragment from somewhere else) the device driver layer:
this is just work, and there is no hidden secret, we haven't talked
about. I repeat myself when I say: study the rs6000/mbx8xx example, in
connection with read.c/write.c in newlib-x.x.x/libgloss. 

gm


From sailors3 at comcast.net  Wed Jul 27 08:02:15 2005
From: sailors3 at comcast.net (David Eicher)
Date: Wed, 27 Jul 2005 06:02:15 -0700
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <20050727065510.GA30126@mailhub.intra>
Message-ID: <mailman.27.1311919742.4788.efi332@diy-efi.org>

Okay, thanks much for the info! Things are making a lot more sense now.
Sorry to be such a pain here....

Install put the lib in usr/local/powerpc-elf/
The only directory I have with ppc-aout in it is:
Usr/local/newlib-ppc-aout/ which was used to build newlib.

I don't think I did any damage, I just dragged those lib directories back to
usr/local/powerpc-elf/..., there are just two (include, and lib). So I now
have the following directories in usr/local/powerpc-elf/

Bin (gcc.exe, etc)
Include (stdio.h, etc)
Lib (libc.a, etc.)

Do you think I need to re-run the install (would gcc find the libs during
linking)?

It sounds like I need to rewrite my makefile for building my target code, it
does use ld for linking. I'll hunt around and find an example of how to use
gcc to do linking. You say gcc will expect the libs in the directories the
install placed them in?

Thanks much for your kind willingness to help,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Tuesday, July 26, 2005 10:55 PM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Building newlib/libgloss for MPC555

On Tue, Jul 26, 2005 at 08:03:12PM -0700, David Eicher wrote:
> Well, I ran the install, it installed in my compiler directory
> (powerpc-elf), so I moved the lib and include directories to
> usr/local/lib/powerpc-elf/lib and usr/local/lib/powerpc-elf/include. It's
> amazing I've got this far, thanks much for all the help. 

I am not sure if you got that right in all the details, as from the
paths you reported, the install run shouldn't have put it into the
wrk directory /usr/local/powerpc-elf/ppc-aout, and also not under
/usr/local/powerpc-elf/newlib-1.13.0. What bothered you seems that it
installed it into /usr/local/powerpc-elf, but that is exactly where
it should live. IMHO it would be more safe if you had your source and
work directories somewhere outside /usr/local/powerpc-elf.  Just keep
in mind this might be the cause of trouble once powerpc-elf-gcc barks
at you for not finding stuff when linking... I'd redo the unpack
newlib/configure/compile/install step from another directory, after
renaming /usr/local/powerpc-elf into something else...

> The bad news..., I have libraries in the lib directory, but also a
> subdirectory called "le" has libraries in it, as well as "nof" and
"nof/le"
> and "nof/und" and "und". So, there are about six libc, six libm, etc.

Normal. This is the result of the multilib approach, that is, the libs
are generated for each configured variant of target architecture. 'le' is
little endian, 'nof' is 'no floating point'.  Not sure what 'und' means.
Subdirectories contain combinations, that is 'nof/le' is nofloatingpt &&
little endian.

Newlib's configure fetches the possible multilib combinations from the
crosscompiler (try "powerpc-elf -print-multi-lib" and "powerpc-elf
-print-multi-directory"), which is a good thing, because then only those
multilib combinations are generated, for which the compiler also has
support, and your app code can be taylored for. Which target arch is
addressed for your app code is controlled with gcc's -m options. And the
gcc frontend fetches libraries from the right multilib subdirectory if
you call the linking phase with the same arch options than the compilation
runs. That's why I suggested to use -mcpu=505 or something.

> Does anyone know what these directories are for? Which copy of the
libraries
> should I point my linker to when I build target code?

You don't need to worry which lib to choose as long as you use gcc for
linking, and not ld directly. For using ld (not recommended), you are
right: you have to select the lib path on your own, and this can lead to
a lot of hidden bugs if, for example, your app code has soft-float, but
you link in a hard-float library, where your processor has no fpu, or
has the fpu switched off.

> I need to modify my libgloss too, and am looking for documentation/input
on
> how to build that library.

cd <newlib-wrk-directory>/powerpc-elf/libgloss; make; make install

That is a shortcut, to avoid building the whole newlib enchilada.
However, this shortcut would not be absolutely necessary, as re-building
the whole tree would require a significant less amount of time, as
most .o files are already available from the initial make run for all
newlib. (once again: this is Makefile magic)

You might try "make dvi" or "make html" or something in newlib's top
workdir, or some relevant subdirectory of your wrk tree, but I doubt
there is anything on libgloss. Haven't checked recently, though. Ok,
a quick glance revealed that there is the document "Embed with GNU",
and there are also examples to show the general principle, however not
for powerpc. Don't let you get disturbed by the statement that there is
libgloss support only for 68k, mips, sparc, PA risc. This document is
10 years old... so it might be no BIG help.

To actually write (or rather to port, as I understood, you already have
a driver source fragment from somewhere else) the device driver layer:
this is just work, and there is no hidden secret, we haven't talked
about. I repeat myself when I say: study the rs6000/mbx8xx example, in
connection with read.c/write.c in newlib-x.x.x/libgloss. 

gm
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332



From sailors3 at comcast.net  Fri Jul 29 07:18:00 2005
From: sailors3 at comcast.net (David Eicher)
Date: Fri, 29 Jul 2005 05:18:00 -0700
Subject: [Efi332] Building newlib/libgloss for MPC555
In-Reply-To: <20050727065510.GA30126@mailhub.intra>
Message-ID: <mailman.28.1311919742.4788.efi332@diy-efi.org>

Progress! Thanks much for all your help, I have modified libgloss, built the
library, and installed it.

Next step is to figure out how to configure my build of my target code to
use gcc linking rather than ld, then build my target code and test. 

Thanks again for all the input here.

Regards,

Dave


-----Original Message-----
From: efi332-bounces at diy-efi.org [mailto:efi332-bounces at diy-efi.org] On
Behalf Of Gunter Magin
Sent: Tuesday, July 26, 2005 10:55 PM
To: efi332 at diy-efi.org
Subject: Re: [Efi332] Building newlib/libgloss for MPC555

On Tue, Jul 26, 2005 at 08:03:12PM -0700, David Eicher wrote:
> Well, I ran the install, it installed in my compiler directory
> (powerpc-elf), so I moved the lib and include directories to
> usr/local/lib/powerpc-elf/lib and usr/local/lib/powerpc-elf/include. It's
> amazing I've got this far, thanks much for all the help. 

I am not sure if you got that right in all the details, as from the
paths you reported, the install run shouldn't have put it into the
wrk directory /usr/local/powerpc-elf/ppc-aout, and also not under
/usr/local/powerpc-elf/newlib-1.13.0. What bothered you seems that it
installed it into /usr/local/powerpc-elf, but that is exactly where
it should live. IMHO it would be more safe if you had your source and
work directories somewhere outside /usr/local/powerpc-elf.  Just keep
in mind this might be the cause of trouble once powerpc-elf-gcc barks
at you for not finding stuff when linking... I'd redo the unpack
newlib/configure/compile/install step from another directory, after
renaming /usr/local/powerpc-elf into something else...

> The bad news..., I have libraries in the lib directory, but also a
> subdirectory called "le" has libraries in it, as well as "nof" and
"nof/le"
> and "nof/und" and "und". So, there are about six libc, six libm, etc.

Normal. This is the result of the multilib approach, that is, the libs
are generated for each configured variant of target architecture. 'le' is
little endian, 'nof' is 'no floating point'.  Not sure what 'und' means.
Subdirectories contain combinations, that is 'nof/le' is nofloatingpt &&
little endian.

Newlib's configure fetches the possible multilib combinations from the
crosscompiler (try "powerpc-elf -print-multi-lib" and "powerpc-elf
-print-multi-directory"), which is a good thing, because then only those
multilib combinations are generated, for which the compiler also has
support, and your app code can be taylored for. Which target arch is
addressed for your app code is controlled with gcc's -m options. And the
gcc frontend fetches libraries from the right multilib subdirectory if
you call the linking phase with the same arch options than the compilation
runs. That's why I suggested to use -mcpu=505 or something.

> Does anyone know what these directories are for? Which copy of the
libraries
> should I point my linker to when I build target code?

You don't need to worry which lib to choose as long as you use gcc for
linking, and not ld directly. For using ld (not recommended), you are
right: you have to select the lib path on your own, and this can lead to
a lot of hidden bugs if, for example, your app code has soft-float, but
you link in a hard-float library, where your processor has no fpu, or
has the fpu switched off.

> I need to modify my libgloss too, and am looking for documentation/input
on
> how to build that library.

cd <newlib-wrk-directory>/powerpc-elf/libgloss; make; make install

That is a shortcut, to avoid building the whole newlib enchilada.
However, this shortcut would not be absolutely necessary, as re-building
the whole tree would require a significant less amount of time, as
most .o files are already available from the initial make run for all
newlib. (once again: this is Makefile magic)

You might try "make dvi" or "make html" or something in newlib's top
workdir, or some relevant subdirectory of your wrk tree, but I doubt
there is anything on libgloss. Haven't checked recently, though. Ok,
a quick glance revealed that there is the document "Embed with GNU",
and there are also examples to show the general principle, however not
for powerpc. Don't let you get disturbed by the statement that there is
libgloss support only for 68k, mips, sparc, PA risc. This document is
10 years old... so it might be no BIG help.

To actually write (or rather to port, as I understood, you already have
a driver source fragment from somewhere else) the device driver layer:
this is just work, and there is no hidden secret, we haven't talked
about. I repeat myself when I say: study the rs6000/mbx8xx example, in
connection with read.c/write.c in newlib-x.x.x/libgloss. 

gm
_______________________________________________
Efi332 mailing list
Efi332 at diy-efi.org
http://lists.diy-efi.org/mailman/listinfo/efi332