Building the bootloader on Mac OS X

Just for clarify I have the latest Arduino installed and I’ve installed CrossPack-AVR in the past. Looks like I have CrossPack-AVR-20131216. That’s what it’s using but I assume I could also have talked it into using the AVR toolset that came with Arduino.

I wanted to rebuild the Caterina bootloader to make some changes and learn it’s actually size. I found it a bit more annoying than I’d like so I wanted to document the process:

  • cd /Applications/
  • Read Caterina-Leonardo.txt and find out I need LUFA
  • Pull LUFA from github and checkout the LUFA-111009 tag
  • Edit the Catarina Makefile
  • Set LUFA_PATH… it must be relative even if that’s insane - …/…/…/…/…/…/…/…/…/…/Users/… in my case (absolute path gave funny errors)
  • Uncomment the VID and PID lines near the top of the file
  • run make

I assume the absolute/relative path tip might be helpful on other *NIX platforms, but I’m not sure.


AVR Memory Usage
Device: atmega32u4

Program:    3900 bytes (11.9% Full)
(.text + .data + .bootloader)

Data:        188 bytes (7.3% Full)
(.data + .bss + .noinit)

Thought I would share incase anyone else gets stuck on the same issues.

There is some room to be had, but not a lot. Since we only have one LED we can rip out all the references to 3 different LEDs… we can either replace them by referencing our single LED or remove the code entirely. I did a little tweaking here and saved 36 bytes. You could probably start stripping functionality from the bootloader too, but I assume we’d want to leave that pretty much alone.

Why care about the size at all (since it seems we can’t possibly hit 2k)? I thought if we had a nice boot logo it would be nice to push that image into the bootloader so no one could complain about it taking up room in their sketch. The logo image I had in mind is only 22 bytes (88x16).

Neat info. I’m sure you’re familiar with…

Nice intro for newcomers:

Perhaps going through the includes there’s some fat that can be trimmed… but it does look like a challenge :wink:

Can a sketch even read from the bootloader section? If Boot Lock Bit1 Protection bit BLB12 is programmed (to 0), then I don’t believe it would be able to. If a sketch can read from the bootloader area, how does it determine the address of where the data is located?

If even a single sketch relies on being able to retrieve something from the bootloader area, then the space that this data takes up is forever lost for other, possibly more important, bootloader enhancements. It also means that a standard, of the shelf, Arduino bootloader could never be used by the Arduboy. A customised version with this enhancement would always have to be available to be programmed and used.

Why do we even need a nice logo? I’d prefer that a sketch just went straight into whatever it’s designed to do.

Unless the hardware design of the Arduboy deviates from a standard Arduino in such a way as to make it impossible, I’d prefer that a standard bootloader be used. Likewise, maintaining hardware compatibility with a standard Arduino, so as to work with a standard bootloader, should be a consideration in the design of the Arduboy. If hardware differences make a standard bootloader unusable, then changes made to customise it should only be to address these hardware differences.

Good points. Probably not possible, but slimming from 4kb -> 2kb to free up space for a sketch seems like a nice goal. However, this could break Leonardo /Arduino IDE compatibility- so may not be worth it…?
If it’s possible to access data, could store Font tables, etc. Although again I agree, could create a heck of a legacy that would bite when moving to Arduboy2 on a different MCU.
I like the idea of a config / settings option that comes up when holding ‘B’ while switching on. (Menu to adjust volume and contrast).

1 Like

Some further interesting reading…

Teensyduino uses a custom loader and a 512B bootoader…

Seems kinda extreme… but then having a simple .hex loader App for users who don’t want to download and install the Arduino IDE might not be so crazy…

Yeah if we wanted to do it we’d just set the fuses properly. And a simple checksum in the first byte or two could make sure the data was there and intact before being used by the core lib. If it appeared the data was different or had been refreshed then it could be skipped. Flexibility and the best of both worlds.

We’re already going to be flashing the bootloader to change the delay and LEDs, so it would be 100% standard in the first place. Adding a small data area with an image doesn’t make the bootloader any less "standard’. 99% of users aren’t going to do anything with the bootloader anyways, so it’s a great place to get a little extra storage. If you want a 100% standard bootloader you can always reflash the original one yourself.

If a sketch can read from the bootloader area, how does it determine the address of where the data is located?

This isn’t hard to do at all. If it can’t be programmed it can be determined manually after the final bootloader is finished.

If @bateske decides to do something neat with the bootloader I would completely support it. The hardware is custom for a reason. We should do what we can to make the most of it. Super-DIYers can always do what they want with it later anyways (as long as it’s reprogrammable, etc).

Branding and just to be nice. Why do people put logos on anything? This is all up to @bateske I think. I was just finding a way to get the logo for “free” and now I have. :slight_smile:

I don’t think we can use that. I just looked and I don’t see ANY USB code at all. Unless I’m missing it. The USB overhead is what takes up a lot of the 4k, not the programming code. As long as we have to do all the USB stuff in software I think we’re stuck with Catarina as a bootloader. Happy to be proven wrong though.

Well the Teensy bootloader works over USB in 512 bytes of hand-crafted ASM :wink:
Personally I think it’s more important to be an open, easily accessible platform- with low barrier to entry. So I’m happy that performance is secondary to using more standard approaches (works with Arduino IDE out of the box). But that’s just IMHO.

That’s crazy. Looks like it requires custom boot loading software vs a normal avrdude programmer, etc.

I think having the little arduboy image (that is in some of the official examples) and their little ping noise at startup would be kind of cool. It reminds me of the gameboy. Even if it does create a slight delay to getting into my sketch I’m all for it.

Has anyone (@bateske) tried rolling a bootloader with V-USB?
While transfers would be slower, it would allow a 2KB bootloader, freeing up 2048 glorious bytes for elaborate game design or stunning graphics. :slight_smile:

1 Like

Just an update I just tried this again on a new computer with Arduino IDE 1.6.7 and latest Crosspack:

I used homebrew this time for Crosspack:

brew install Caskroom/cask/crosspack-avr

I had to restart the Terminal to get the paths updated. Otherwise same steps as before.

Interesting but it would require hardware support… since it’s a software implementation of USB you have to replace the ACTUAL USB connection we’re using now with IO pins on the chip instead (i.e., the USB port needs entirely different wiring)… so unless there is any interest in the main project doing that then V-USB would be a non-starter.