Command line teensy loader bug on Mac

Status
Not open for further replies.
J

JonathanClineIEEE

Member
Command line teensy loader bug, see below. Can the binary of an older version of the command line loader from someone's archives be put on this page ? https://www.pjrc.com/teensy/loader_cli.html The teensy_loader_cli on this page says it is OSX 10.5 compatible but that is incorrect because it is a x86-64 executable (at a minimum that would be OSX 10.6).


Running on a Mac x86-32 (OSX 10.5 or OSX 10.6) the trouble is:

Code: 
$ file teensy_loader_cli 
teensy_loader_cli: Mach-O 64-bit executable x86_64

So the cli loader is not usable. OSX 10.5 is always either x86-32 or ppc32 (universal binary). OSX 10.6 is either x86-32 or x86-64 (no more universal binary for ppc32 supported). I'd like to get a previous old executable that is for OSX 10.5 or 10.6 targeted for arch x86-32. I am burning Teensy 2.0 thus newer chipset/bootloader compatibility is not a concern. I could run the entire toolchain in a linux vm but hoping not to go there.
 
Version 2.1 adds support for Teensy 3.5 & 3.6, and support for all Teensy boards on Windows.

Version 2.0 has been tested on Ubuntu 9.04, Mac OS-X 10.5, Windows XP, FreeBSD 8.0, OpenBSD (20-Jan-2010 snapshot), and NetBSD 5.0.1. All versions of NT-based Windows with USB support (2000 and later) are believed to work.

if your clicking the mac link above that will most likely be the latest one
you'll need to compile it to your OS(X), try the github link.

As per github:

Compiling on Mac OS-X 10.6 may require adding "-mmacosx-version-min=10.5" to the Makefile. Thanks to Morgan Sutherland for reporting this.

$(CC) $(CFLAGS) -DUSE_APPLE_IOKIT -isysroot $(SDK) -o teensy_loader_cli teensy_loader_cli.c -Wl,-syslibroot,$(SDK) -framework IOKit -framework CoreFoundation -mmacosx-version-min=10.5
 
Last edited:
If it's an old binary then I assumed someone already had it in archives to make available and building from source isn't necessary. Maybe not? Wayback machine does not show a mac cli binary for the last 2.0 update on the page from 2013, http://web.archive.org/web/20130927121412/http://www.pjrc.com/teensy/loader_cli.html

The current page should be best updated to indicate the binary works for only 64-bit mac's (regardless of OSX version). Though this could probably be resolved in another way, if someone contributed the 2.1 version which is also targeted as 32-bit which presumably would run on both 32-bit and 64-bit.
 
Long, long ago Teensy Loader (GUI-based) was able to run on 10.5 Leopard and was even built as a fat binary with PPC and I386 support. But those days are long in the past, and a variety of subtle bugs on newer systems forced updating to a newer version of wxWidgets which isn't compatible beyond 10.7.

Maybe try (GUI-based) Teensy Loader from an old copy of Teensyduino. On the download page, view the html source for info about downloading old versions. When you run the installer, pay careful attention to the first intro page (which ordinarily nobody reads) to make sure you get an old copy of Arduino is will recognize. If the "Next" button won't enable, you've got an incompatible Arduino. The very old installers don't have the "?" help button, so just know that's the issue. Read that intro page! PJRC doesn't keep only versions linked from any pages, because stuff like this is a support nightmare...

Alternately, you could try to find an old version of Xcode, which can compile the source for your ancient machine. Back in the 10.5 days, Apple bundled the command line tools with the GUI Xcode. At some point they became separate. In some copies from the 10.6 & 10.7 days, they included an older toolchain as "gcc-4.0" and newer as just "gcc", so you may need to fiddle with the command to run the older one capable of building old formats. Apple tends to make building for more than 1 or 2 prior OS releases quite difficult.
 
According to some apple stats the number of mac users still running x86-i386 is less than 1% so this is a rare situation.

I can use the old teensy loader GUI that I have. I was able to download it from the web site. At least the loader GUI seems to be doing 'something' (not sure if my firmware is good, so maybe it is not working, but says it downloads OK). My Teensy 2.0 is good since it was previously doing a blinky. I'm using the CrossPack (CrossPack-AVR-20131216, the OSX 10.5 compatible version) starting with template project created by the avr-project command which creates a Makefile with targets. FYI going the prior-released arduino/teensyduino install route did not work because those installers also 64-bit binaries so the apps won't run (OSX shows an "X" over the icon). Altho there could be a magic combination of older versions that might be out there.. going CLI and library-free is what I want anyways.

Note for Mac the xcode flag for forcing the 32-bit target is, I believe,
gcc -arch i386

That could would work if the cli loader (if attempting to build for 10.5 as well) doesn't require any 64-bit only libraries but I don't know.

I guess at least, the web page should indicate that the binary link is for version 2.1.
 
True, but the only binary link on the website is almost always the latest version anyways, on any site. not just here. older releases should be looked deeper into the archives, it wouldnt make sense to keep an outdated/older software at the top of the list of any download site
 
Ok, I've tried building it with Xcode 3.2, but I have no way to test if it actually works.

I put it on the web page anyway. Please let me know if this build actually runs on your old machine?
 
Okay I was able to build a working cli binary from the latest github (version 2.1 I suppose) using an OSX 10.5 SDK from an old drive. It appears that the cli burns OK. At least, both the GUI and the cli are both blinking the Teensy 2.0 after downloading the blinky hex. I'll post a link to my 10.5 compat binary later. gcc used was:


$ /Volumes/JCLINE/Developer/usr/bin/gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)


Makefile changes were:

CC = /Volumes/JCLINE/Developer/usr/bin/gcc
SDK ?= /Volumes/JCLINE/Developer/SDKs/MacOSX10.5.sdk


Since it's a 32-bit machine I dont have to specify anything to force 32-bit but the relevant gcc flag is supposedly,

-m32 Generate 32bit i386 code


The successful result (without special flags) being,

$ file teensy_loader_cli
teensy_loader_cli: Mach-O executable i386


I am running it on OSX 10.6 (x86-32).
 
Oh, I see you managed to compile it yourself.

I guess that means you're probably not going to test and confirm the one I built, just for you?
 
Last edited:
PaulStoffregen said:
Ok, I've tried building it with Xcode 3.2, but I have no way to test if it actually works.

I put it on the web page anyway. Please let me know if this build actually runs on your old machine?
Click to expand...

ah! I didnt see that post before I built mine. I just tested it. I have to say though that the web page maybe couldn't say 'ancient'.. uhh..

So here are the results: Blinky OK! (I renamed the binary to teensy_loader_cli-ppc-x8632)

$ ./teensy_loader_cli-ppc-x8632 -v -w --mcu=atmega32u4 teensy_loader_cli-master/blinky-atmega32u4.hex
Teensy Loader, Command Line, Version 2.1
Read "teensy_loader_cli-master/blinky-atmega32u4.hex": 1912 bytes, 5.9% usage
Waiting for Teensy device...
(hint: press the reset button)
Found HalfKay Bootloader
Read "teensy_loader_cli-master/blinky-atmega32u4.hex": 1912 bytes, 5.9% usage
Programming...............
Booting

$ file teensy_loader_cli-ppc-x8632
teensy_loader_cli-ppc-x8632: Mach-O universal binary with 2 architectures
teensy_loader_cli-ppc-x8632 (for architecture i386): Mach-O executable i386
teensy_loader_cli-ppc-x8632 (for architecture ppc7400): Mach-O executable ppc


Universal binary looks OK! (I have no way to test PPC)
 
Off topic -
So, not that I have plans for a Teensy >=3.6 yet, but at what point will this magic number in the cli loader cause a problem?

// the maximum flash image size we can support
// chips with larger memory may be used, but only this
// much intel-hex data can be loaded into memory!
#define MAX_MEMORY_SIZE 0x100000
 
If the .hex has both full flash and EEPROM data (I forget, isn't EEPROM typically first in the file), then, it would exceed this, yes? Maybe that does not apply to Teensy 3.5/3.6 chipsets, if the EEPROM is mapped or not. Actually I haven't looked into how EEPROM is mapped (or if it is mapped) into the .hex. So I don't know.
 
Last edited:
Status
Not open for further replies.
Back
Top