Documenting the steps taken to build a new, clean, Linux development environment.
To make the experience fit your profile, pick a username and tell us what interests you.
So, looking to revive my enthusiasm for playing with ARM MCUs, I picked up a Teensy 3.1 last weekend. I'd been vaguely aware of the Teensy for some time, and had seen Paul Stoffregen described on hackaday, amongst other place, as 'brilliant'. I'd thought 'meh, another arduino clone'. I couldn't have been more wrong. Stoffregen is brilliant, and the Teensy 3.1 is an amazing piece of engineering: 72MHz (overclockable to 96MHz), 32 bit ARM cortex-M4 CPU, breadboard friendly and compatible with most Arduino libraries.
I was tipped over the edge into buying the Teensy when I read that it could be programmed via gcc & makefile, rather than purely through the Teensyduino IDE. I thought that playing with the makefiles would give me some insight into getting the LPC810 and FRDM-KL86Z working without Nexpresso and Codewarrior. It will, but not until I'm done having fun with the Teensy with the huge array of compatible Arduino libraries.
Up to now, I've struggled a bit to see much use (for a hobbyist tinkerer like me) for bare metal 32-bit MCUs. To be honest, an ATmega328P has been fast enough, and had enough memory, for all of my low-level hardware projects, and the Raspberry Pi and Beaglebone Black have been cheap enough to throw at the upper end (and fast enough to program in Python under Linux).
Like all really great hacker products, the Teensy seems to open up a whole new range of possibilities somewhere in the middle ground.
I'm not dead, and haven't given up on getting an ARM toolchain up and running: just busy doing my taxes, and spinning my wheels a little on the ARM stuff. I wanted to be able to program the FRDM board using gcc and make before jumping into Eclipse and its Freescale add-ins. In order to do this I need to get hold of a link command file (linker script) to tell the linker how the memory is organized on the FRDM-KL46Z. Googling turned up a ".ld" file for the FRDM-KL25Z, but, given that the 46Z has twice the memory, and given my resolution not to just cut-and-paste-and-hope, it looks like I'll have to learn just enough about linker configuration to hack the file.
An alternative approach is to use the "export to desktop IDE" feature of mbed.org to download a KL46Z project and to pick around in the files looking for something equivalent.
Either way, the prospect of doing this worthy-but-dull stuff has driven me to finish my tax prep.
I've been a Linux user, off-and-on, since Ubuntu 6.10 (Edgy Eft). By Ubuntu 12.04 (names no longer cute) my Linux use had withered away to 2 days fixing a broken update every 6 months. I spent most of my play-time in my Compaq Presario's XP partition.
And this wasn't a problem, as most of my play-time activities were better suited to Windows. I'd program PIC microcontrollers in assember using Microchip's Windows tools, write Nintendo DS homebrew using devKitPro libraries and Windows emulators, or write Java roguelikes in Netbeans (which sucks anywhere).
And then the Presario died. Stone cold dead. Yipee! Time for a new laptop.
I eventually settled on a Toshiba Satellite L775D-S7340 as it was cheap, has a 17 inch screen, was cheap, has a quad core (but AMD) CPU, was cheap, and has decent graphics (Radeon HD 6520). (It also has a BlueRay drive, which I've never used.)
The Toshiba came with Windows 7, and I sort of got the Presario's XP partition working on it (until a Windows Update killed it), but I knew I also wanted a Linux partition. After a last look of cold contempt at Ubuntu I installed Mint 13 (Maya) with the retro (Gnome 2) Mate GUI. And I was smitten: Mint13+Mate was everything I liked about Ubuntu back in the mid-naughties. Pretty soon I stopped booting into Windows at all.
I'd been in a Java phase when tragedy struck and it was pretty easy to get Netbeans and the JDK installed to continue my "work". Netbeans was just as flaky on a new, fast, Linux machine as on an aging Windows XP box so the continuity was seamless.
I drifted on to tinkering with USB drivers in Vanilla C with Geany and makefiles, dabbled with writing an Android app using Eclipse Indigo, got really into programming AVRs in C with command line tools, wrote Python programs to monitor my Beaglebone Black-based robot, tried Arduino with a Trinket, and had a nostalgia fling with programming PICs in C. LIfe was good.
Then, on a whim, I ordered a couple of LPC810s and a Freescale FRDM-KL46Z from element14. Time to get ARMed. I had, after all, done a lot of ARM programming on the NIntendo DS, and a (very) little for Android, and the Raspberry Pi and BBB were ARM, so how hard could it be? Very hard. So far I've only managed to write some "hello world" stuff for the FRDM board using the online IDE at mbed.org.
My attempts to get a clean install of Eclipse Kepler working with Gnu ARM cross-building tools and Freescale's Processor-Expert add-in have gone nowhere. Rather than just thrash around piling more random cruft onto Mint13, I decided to make a clean install of the latest Mint (16) and then to methodically (?) follow mcuoneclipse.com's 10 part (!!!) series of articles on installing a "DIY Free Toolchain for Kinetis". I'll document my progress here.
TL;DR - Notes on installing ARM development tools in Linux.
INSTALLING MINT ON A RELUCTANT TOSHIBA SATELLITE LAPTOP
Downloaded the latest Linux Mint 16 with Mate image via torrent from linuxmint.org. Burned to DVD and used it to boot the Toshiba. All seemed to be going well untill the boot finished and I tried to use the touchpad: no reponse. I tried to use the keyboard to bring up a terminal (<Ctrl><Alt><F2>). Again, no response. Uh-Oh.
Googling for "linux live cd keyboard mouse not working toshiba satellite" brought up some vague forum posts pointing to "function key settings". So, I squinted at the cryptic, grey-on-black icons on the Toshiba's function keys and saw one, <Fn><F9> which might mean "mouse/no mouse".
Pressing this combination brought the mouse and keyboard to life and allowed me to kick-off the installation process.
I installed the Mint16 root file system (/) on a new 50GB (ext4) partition on my laptop. I used the existing Mint13 swap partition and the existing (ext4) home partition (/home).
I used a new user name ("posh" - short for Petra Toshiba) to avoid overwriting the /home/tosh directory for my existing Mint13 user.
All of this was completly painless using the "expert install" option from the linuxmin.org live cd.
When complete, with all looking well, I rebooted and... ran slap into the same problem: no touchpad or keyboard response. This time however, the <Fn><F9> combo did nothing.
Back to google. A search on "linux toshiba satellite keyboard mouse not working" brought up (amongst a sea of irrelevant crud) some references to i8042. At last, my memory was jogged. Looking at the file /etc/default/grub on my old Mint13 partition I found the line :
# 120623 Added "i8042.nomux=1 i8042.reset nomodeset" to fix
# intermittent touchpad/keyboard bug. Removed "quiet & splash"
Oh well, at least I commented the fix last time.
From Mint13, I edited the Mint16 /boot/grub/grub.cfg file to add these three options to the linux command line: intending to do a proper fix to the Mint 16 /etc/default/grub after a reboot.
Oops. The system seemed to be booting into Mint16 okay, until it tried to bring up X-windows, at which point the system froze with a grey-black screen.
Rebooting into a root shell in recovery mode showed a lot of bitching in the Mint16 /var/log/Xorg.0.log file.
So, time for some trial and error. Rebooted to the grub menu, selected the Mint16 normal boot option and pressed "e" to edit the command line. After a couple of goes, I found that if I removed the "nomodeset" argument, pressed <Ctrl X> to save and reboot, the system booted into Mint16 with working graphics, mouse and touchpad.
Added the line
to the Mint16 file /etc/default/grub and ran
to rebuild the Mint16 /boot/grub/grub.cfg.
So what went wrong?
The Toshiba Satellite L775D-S7340 connects the keyboard and touchpad via the motherboard's i8042 PS/2 controller. The Linux driver for the controller assumes support for multiplexing: adding additional PS/2 devices like a trackstick or external PS/2 port. Great on a Thinkpad with a little red nipple thing, not so great on a Toshiba with no extra hardware and hence no multiplexing support. So "i8042.nomux=1 i8042.reset" switches off multiplexing support in the driver and forces a reset of the PS/2 controller.
The "nomodeset" argument in my Mint13 installation was a relict of my having installed prorietary ATI catalyst drivers before addressing the touchpad bug. With the proprietary drivers, the kernel has to stick to default text mode, and leave graphics mode setting to the X-Windows server. With a more recent kernel and the recommended (Mint default) xserver-xorg-video-radeon driver, the nomodeset argument was preventing the kernel from setting the graphics mode (KMS) while X-windows was assuming that graphics mode had already been set by the kernel when trying to startx.
Morals of the story:
1. Don't just comment your tweaks, log them somewhere - like maybe in a hackaday project.
2. Don't just blindly cut-and-paste fixes. Do an extra google-due-dilligence search to understand what you're tweaking.
Bonus google bomb: before installing Mint16 I'd installed Debian to the same partition. (I quite like Raspbian, so why wait for the Debian->Ubuntu->Mint trickle-down?). The Debian installation went okay (apart from some Stallmanesque hurdles to installing proprietary Wifi, Ethernet and graphics drivers), but the laptop would give me the above grey-black screen on attempting to resume from suspend (opening the lid).
With hindsight, Debian has some version of the same i8042/KMS nomodeset problem when installed on a Toshiba Satellite.
Become a member to follow this project and never miss any updates