Here is a 'generic' step-by-step to getting an AVR development platform going on your computer using the free AVR toolchain (avr-gcc, avr-libc and avrdude) Pretty much every project uses this toolset so its a good way to get going
- Fedora Sorcerer (le4d) Mac Os X
- Fedora Sorcerer (le4d) Mac Os Update
- Fedora Sorcerer (le4d) Mac Os Download
Emulation™ is a DMX 512 lighting controller for intelligent lights, LED, dimmers, lasers and various other effects. The program is platform-independent and available on Mac OS X and Microsoft Windows. The software is shipped with a USB-to-DMX adapter cable, compliant with the new DMX512-A standard. Key to the design of Emulation™ is its intuitive graphical user-interface. 1951 LEO I 'Lyons Electronic Office' was the commercial development of EDSAC computing platform, supported by British firm J. Lyons and Co.; 1955 MIT's Tape Director operating system made for UNIVAC 1103; 1955 General Motors Operating System made for IBM 701; 1956 GM-NAA I/O for IBM 704, based on General Motors Operating System; 1957 Atlas Supervisor (Manchester University) (Atlas.
The following two methods both place all of the files in the /usr/local/bin directory in the hard driver. Unfortunately that directory is not in the default path. That means that when you type avrdude into the terminal it cant figure out where to look. In this prep-step you'll change the profile of your Terminal to add /usr/local/bin to the path.
Find the Terminal program, you'll be using this to do most of this stuff. Its in the Applications/Utilities folder
In the new Terminal window, type in echo $SHELL and press return
If the output is /bin/bash then type the following command:
echo 'PATH=$PATH:/usr/local/bin' >> ~/.bash_profile
all on one line. Press return.
If the output is /bin/csh or /bin/tcsh then type the following command:
echo 'set path = ($path /usr/local/bin)' >> ~/.cshrc
all on one line. Press return.
Close any Terminal windows and open up a new one. This makes sure the .bash_profile or .cshrc is reloaded. Now type in echo $PATH (for bash) or echo $path (for t/csh) you should get something like the following:
The important thing is that at the end of the line is /usr/local/bin
This is the suggested method
Download the ready to go nice package from ObDev, I havent tried it but a friendly email'er said its great.
This isnt suggested, and is an older method, but we leave the documentation here in case its handy
You will need make which is included in XCode, as OSX-AVR doesn't come with it (ugh)
Step 1. Download and install the mac developer tools (XCode).
You need to have make installed, but it doesn't come with the OSXAVR package. You can try installing it with fink, which will require a lot less space but the following is guaranteed. If you want to have the latest avr-gcc you may also have to do it the 'old way' which guarantees the most recent tools will be installed.
To install XCode you will need the official packages. These are available on your Mac OS X Install CD, or from apple at: apple developer tools. The file is about 900MB so unless you have a fast connection I strongly encourage grabbing it off of the Install CDs that came with your Mac (you do still have those, right?) Basically we need the native Mac OS X compiler tools so that we can generate the AVR compiler tools.
There's finally a good/fast way of installing all these tools under Mac OS X PPC or i386! First, download the OSX-AVR packge for PPC (older macs) or i386 (Intel macs, latest ones) from sourceforge.
Maskplosion mac os. Run the OSX-AVR.mpkg
You're done!
(Images of installation and process are forthcoming but its rather easy so go ahead and try it anyways)
Don't forget you have to install XCode as make doesn't come with this package.
Can't get it working? Dont worry, help is available in the forums!
This is the advanced method, for when you need bleeding-edge development and hackability. Not suggested
The following steps are essentially the same for MacOS X or Linux, BSD or any other unixy OS. This is the 'old style' of installing avr-gcc, its longer and more tedious but you are guaranteed to have the latest version.
(Note that this doesn't seem to work on Intel Macs for unknown reasons, we're investigating.)
Leah Buchley has an excellent tutorial, and you should follow it. I've reduplicated it here in case the site goes down. (also with a few minor 'improvements' and images
Step 2. Download & install binutils (an essential utility for the C compiler)
Download the current release of binutils from : http://www.gnu.org/software/binutils/ (you can also go straight to the download site here) For these examples, we'll be using binutils-2.17.tar.gz but you should use whatever is most recent. Save it into your home directory, not the desktop.
Decompress the downloaded file and double click on it to decompress it (or use Stuffit Expander, in the Applications folder). You should now have a folder called binutils-2.17 which you should drag into your Home directory
Open up a Terminal window and navigate to the binutils directory. Type: cd binutils-2.17 (or whatever you downloaded) theb type in ls to verify everythings there
Configure binutils for AVR. type: ./configure --target=avr
this will start a long process that will spit out a lot of text.
Once its done, compile binutils. type: make
this will start an even longer compilation process
Once that's done, install binutils. type: sudo make install
You will be prompted to enter your password. Only administrators can install software thats why the password is necessary.
Step 3. Download & install gcc (the C compiler)
First, download the current release of gcc from: http://gcc.gnu.org/mirrors.html currently thats gcc 4.2.0
Decompress the downloaded file and put the decompressed folder in your home directory. Open up a new Terminal window in your home directory, type cd gcc-4.2.0 and then ls to verify its all in there.
Next, c reate another directory to install gcc into.
type: cd . to go back into the home directory, then
type: mkdir avrgcc-4.2 (substituting your gcc version for the 4.2)
Navigate to the folder you created.
type: cd avrgcc-4.2 (or whatever you named your folder)
Configure gcc for AVR.
Type: ./gcc-4.2.0/configure --target=avr --enable-languages=c --disable-libssp
(substituting the name of the folder you decompressed for the gcc-4.2.0)
**thanks to Seth Raphael for the --disable-libssp tip
Once the configuration is done, compile gcc.
type: make CC='cc --no-cpp-precomp'
This will take a long time so go have a sandwich
When its done and you've washed your plate and silverware, install gcc. type: sudo make install
and enter your password when prompted
Step 4. Download and install avr-libc (an essential C library for AVR chips)
Download the current release of avr-libc from : http://savannah.nongnu.org/projects/avr-libc/
Decompress the downloaded file and put the decompressed folder in your home directory
In a new Terminal window, navigagte to the avr-libc directory. from your home directory
type: cd avr-libc-1.4.6 (or whatever you downloaded)
Configure avr-libc. type: ./configure --host=avr Piou-piou mac os.
Compile avr-libc. type: make
Install avr-libc. type: sudo make install
Step 5. Download and install avrdude (the software that loads programs from your machine onto the chips)
Download the current release of avrdude from : http://download.savannah.gnu.org/releases/avrdude/
Decompress the downloaded file and put the decompressed folder in your home directory
In a Terminal window, navigate to the avrdude directory. From your home directory type: cd avrdude-5.2 (or whatever you downloaded)
Configure avrdude. type: ./configure
Compile avrdude. type: make
Install avrdude. type: sudo make install
Yay all the software is installed!
Can't get it working? Dont worry, help is available in the forums!
08 August 2013 Karim ElatovI was using my new Mac and there are just something that I missed from my previous Linux Laptops. So I decided to install Fedora on my new MacBook Pro :). The biggest challenge is getting around the EUFI interface.
BIOS VS EUFI
After dusk mac os. The Arch Page entitled 'Unified Extensible Firmware Interface' has a good summary and helped me out during the preparation of the install:
Unified Extensible Firmware Interface (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used 'MBR boot code' method followed for BIOS systems.
The only piece of beauty in that flesh you call a body mac os. Booting an OS using BIOSA BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware has been initialized and the POST operation has completed, the BIOS executes the first boot code in the first device in the device booting list.
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.
Multiboot on BIOSSince very little can be achieved by a program that fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like GRUB or Syslinux or LILO would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.
Booting an OS using UEFIUEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems.
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called EFI SYSTEM PARTITION in which files required to be launched by the firmware are stored. Each vendor can store its files under /EFI//
folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.
Under UEFI, every program whether it is an OS loader or a utility (e.g. a memory testing app or recovery tool), should be a UEFI Application corresponding to the EFI firmware architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use i386 EFI are older (pre 2008) Apple Macs.
An x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike x86_64 Linux and Windows versions which include such support. Therefore the bootloader must be compiled for that specific architecture.
Multibooting on UEFISince each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.
To confirm that my Mac was using 'x86_64 EFI firmware', I ran the following:
GRUB and EUFI
Since I will be installing Fedora, I will be using GRUB for my boot loader. Here is how GRUB handles EUFI, from GRUB and the boot process on UEFI-based x86 systems':
GRUB loads itself into memory in the following stages:
- The UEFI-based platform reads the partition table on the system storage and mounts the EFI System Partition (ESP), a VFAT partition labeled with a particular globally unique identifier (GUID). The ESP contains EFI applications such as bootloaders and utility software, stored in directories specific to software vendors. Viewed from within the Fedora 19 file system, the ESP is /boot/efi/, and EFI software provided by Red Hat is stored in /boot/efi/EFI/fedora/.
The /boot/efi/EFI/fedora/ directory contains grub.efi, a version of GRUB compiled for the EFI firmware architecture as an EFI application. In the simplest case, the EFI boot manager selects grub.efi as the default bootloader and reads it into memory.
If the ESP contains other EFI applications, the EFI boot manager might prompt you to select an application to run, rather than load grub.efi automatically.
- GRUB determines which operating system or kernel to start, loads it into memory, and transfers control of the machine to that operating system.
Because each vendor maintains its own directory of applications in the ESP, chain loading is not normally necessary on UEFI-based systems. The EFI boot manager can load any of the operating system bootloaders that are present in the ESP.
The above sounds great, but with Fedora 19, there is a known bug. From 'Common F19 bugs':
If you try to do a native UEFI install of Fedora 19 alongside a native UEFI install of OS X and re-use the existing EFI system partition, the installer will incorrectly consider the existing EFI system partition as invalid and report that you have not created a bootloader stage1 target device. Unfortunately, the Fedora automatic partitioning algorithm will actually attempt to re-use the EFI system partition, and so you will run into this bug in any Fedora 19 installation attempt where you use the automatic partitioning algorithm and do not choose to delete the existing EFI system partition.
Practically speaking, there are a few different approaches to dealing with this problem. If you do not mind losing your OS X installation, you can simply choose to delete it (including the EFI system partition), and let Fedora occupy the rest of the disk. Fedora should create a new EFI system partition and install successfully.
If you wish to preserve your OS X installation, install Fedora 19 Final, and dual boot, you must use the installer's ‘custom partitioning' path. Make sure to leave the existing EFI system partition intact, but do not set a mount point for it. Do not use the Create partitions for me button. Instead, manually create a new EFI system partition, and set it to be mounted at /boot/efi. Manually create other partitions as usual. Complete custom partitioning, and your installation should proceed successfully.
You could also try installing Fedora 18 or Fedora 19 Beta. These should allow you to use automatic partitioning to install alongside OS X, assuming you do not run into any other bugs they may have contained. You could then upgrade to Fedora 19 Final - with FedUp from Fedora 18, or yum from Fedora 19 Beta. You will still wind up with two EFI system partitions in this case.
We are investigating the possibility of producing an updates image to make it easier to deal with this bug. We apologize for any inconvenience it causes you.
It looks like there are still some issues with the new UEFI and different OSes.
Download Appropriate Install Media
From Fedora's Installation Guide:
Important — UEFI for 32-bit x86 systemsFedora 19 does not support UEFI booting for 32-bit x86 systems. Only BIOS booting is supported.
Important — UEFI for AMD64 and Intel 64Note that the boot configurations of UEFI and BIOS differ significantly from each other. Therefore, the installed system must boot using the same firmware that was used during installation. You cannot install the operating system on a system that uses BIOS and then boot this installation on a system that uses UEFI. Fedora 19 supports version 2.2 of the UEFI specification.
I was going to install to install Fedora 19 64bit from the get-go so this didn't really impact me.
Shrinking the OS Disk
I just needed 50GB for my Linux install. Before I made any changes, here is how disk was partitioned:
While in Mac OS X, From Utilities (Command-Shift-U), I started up DiskUtility. Then I selected the OS Hard-Drive, selected the Partition tab, re-sized the OS partition , and clicked apply:
That was really easy.
Install Fedora 19 on Mac Book Pro
After I burned the DVD ISO, I inserted into the Disk drive and rebooted. Right after I rebooted, I held down the 'Alt/Option' key and I saw that the following media was bootable:
I selected the Fedora Media and booted from it. During the install I selected the 'Custom partition' method and I made the follow partitioning schema:
Even after following the instruction in the bug, it still gave the 'you have not created a bootloader stage1 target device' error. So I decided not to install a boot-loader at all. This is done by clicking on 'Full Disk Summary and bootloader' and then selecting 'Do not install bootloader':
After opting out of the bootloading, the install started.
Boot into Rescue Mode and Create the GRUB Configuration manually
After the install finished, I rebooted into the Install DVD again and selected 'Troubleshooting':
I selected to discover any previous Linux installs and the rescue CD mounted it under /mnt/sysimage. After it dropped me into the shell, I did the following to create the GRUB configuration:
I then exited from the recovery shell and let the OS boot. Since I didn't install any boot loader it booted into Mac OS X.
Bless the Other EFI Partition
To boot from the other EFI partition we need to bless it and set it as bootable. After you boot back into Mac OS X, you will see the following partitions:
You will also notice the second EFI Partition automatically mounted:
So to bless our second EFI partition, we can run the following:
I rebooted one more time and I saw the GRUB menu. After it auto-selected the 'Fedora' Menu, it showed the following error:
error: failure to read sector 0x0 from hd0
But then kept booting without issues :) Apparently there is workaround described here, but I wasn't too worried about it.
Installing the Wireless Firmware
Initially the wireless card won't be recognized. Here is the lspci output of the card:
I downloaded the firmware from here:
and then installed it like so:
After one more reboot, it came up without issues:
Fixing the Fn Keys
By default the Fn keys will be mapped to the media keys of the Mac Keyboard. To temporarily fix it, you can run the following:
You can then run xev and confirm that your keys are reporting the appropriate key code. Here is how my F1 key looked like after the fix:
Fedora Sorcerer (le4d) Mac Os X
To make it permanent, you should be able to add the following into the /etc/modprobe.d/hid_apple.conf file:
But it actually didn't work out for me. Doing some research it looks like we need to set as a kernel parameter. This is discussed here. You can usually do this with the /etc/sysconfig/grub file on Fedora. For some reason that file didn't exist on my install (or rather the link was missing). Usually /etc/sysconfig/grub points to /etc/default/grub, but the /etc/default/grub file was missing. I even re-installed the package that provided that file:
But it still didn't help out, so I created one manually with the following contents: https://bestdload852.weebly.com/rescue-operations-mac-os.html.
After that I regenerated the GRUB config:
Then after yet another reboot, the Fn keys were permanently fixed. Another person wrote a systemd service to run the above command upon boot. Check out the instructions at 'Changing the default Function key behaviour in Fedora'.
Rebooting into Mac OS X
If you want to reboot into Mac OS X, you can reboot the MacBook Pro and hold down ‘Alt/Option' during the boot and you will available bootable media, like so:
Select 'Macintosh HD' and it will boot back into Mac OS X. To set it permanently to boot into Mac OS X. While in Mac OS X, open up System Preferences and select the 'Start Up Disk':
Fedora Sorcerer (le4d) Mac Os Update
Then select 'Macintosh HD' and it will reboot into Mac OS X permanently. Or you can run this command to re-enable boot in the Mac OS HD:
Please enable JavaScript to view the comments powered by Disqus.blog comments powered by