Raspberry Pi 4: usB first!

At the time of this writing the boot-from-usb has just been made available as a Beta feature for the Raspberry Pi 4.

There are a few tutorials on how to activate that feature but I had an additional requirement: Boot from USB first, then boot from SD which requires a few additional steps.

This document might still be useful if you just want the SD first approach. Just ignore the second last part in that case.

But before we begin:

Use at your own risk. We are writing data to the EEPROM here using beta contents and even manipulate configs for that. If something fails your pi might be bricked. Not even reinstall Linux will repair that.

Additional warning: Don’t try this on a N00bs install.

Still here? So let’s begin. (I will asume you use Raspbian Buster)

Updating the Pi

Before we start we should always have the most current Linux version installed. So make sure your internet connection works and enter

sudo apt-get update

followed by

sudo apt-get upgrade

and in addition

sudo rpi-update

to update the firmware on the sdcard

Switching to beta

now change rpi to switch to beta – state. (If you are reading this from the future: Hi there! Cars still a thing? And maybe you don’t need to switch to beta anymore)

do this by using your favourite editor like vi or nano to change the rpi-config:

sudo nano /etc/default/rpi-eeprom-update

change the release-status from critical to beta and save the file.

Flashing the EEPROM

Now check the most current version on your pi:

ls /lib/firmware/raspberrypi/bootloader/beta/pieeprom*.bin

At time of this writing the most current version there is 2020-05-15. So flash the eeprom with that version:

sudo rpi-eeprom-update -d -f /lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-05-15.bin

You will be thrown back to the prompt a while after. Now reboot your pi and hope nothing went wrong:

sudo shutdown - r now

now check if the version has been installed by typing

sudo vcgencmd bootloader_version

the response should display the date corresponding to your file. So something like May 15

Changing the boot order

By default now the boot order will be SD first, USB second. So if you just want to throw away your SD and boot grom USB: Ignore this chapter. If you need a “hardware multiboot” (boot from USB if attached but still have a fallback SD in place if not) follow these instructions:

First make sure I did not lie about the default order and display the current config:

sudo vcgencmd bootloader_config

this should display some information about the configuration. Most interesting for us is the last part called BOOT_ORDERwhich will contain the entry


where 4=USB and 1=SD. More details like network boot can be found at the bootloader documentation.

While this might look like just how we want it you have to read this right to left. So it is SD (1) first and USB (4) second. But we are about to change that.

First it is highly recommend to not fiddle with the official ROM files but make a copy of that. Let’s do that:

sudo cp /lib/firmware/respberrypi/bootloader/beta/pieeprom-2015-05-15.bin pieeprom.bin

Now create a config from that rom:

sudo rpi-eeprom-config pieeprom-usbfirst.bin >bootconf.txt

You now created a config file containing the config-output which you can edit by nano again:

sudo nano bootconf.txt

and change the last line to:


At the last step we now apply our changed config und update the eeprom again:

sudo rpi-eeprom-config --out pieeprom-usbfirst.bin --config bootconf.txt pieeprom.bin
sudo rpi-eeprom-update -d -f ./pieeprom-usbfirst.bin
sudo shutdown -r now

Finalizing the USB drive

Now our raspberry can boot from USB (and boot from there first) but the linux on our USB does not really know how to handle that. This part is simple:

First you need to flash a Raspbian image onto your USB-drive (just like you would to with an SD-card) . Then attach and mount the usb drive and copy the most current firmware files from the /boot – directory of the sdcard to the Usb drive. Alternatively you can select those files from the master-branch on github.

Have fun 🙂

FlashAirDownloader – development: Now it’s your turn

Hi,. folks,

I just programmed a small windows service to automatically FlashAir-pictures when I found out that I lost my FlashAir – card

So I am not able to test that program anymore. I decided for myself that I need something better than the unstable FlashAir-Cards and bought a camera with WiFi inside. (Just in case you are curious: It is a Sony HX400)

I do not publish this as a working download, because I am not able to test it. So there is a big chance that this even breaks the original program. But FAD2 is open source, so I checked the code in into the development-branch on GitHub.

So if there is any C# – developer out there who is willing to invest one or two hours to finish that, feel free to do that.


P.S: No, please don’t buy me a new FlashAir 🙂

Two Apps at the same time: Deploy SharePoint Add-In to Cloud AND On-Premise

What the fuzz is this about?

I am not absolutely sure if I am the first one who did this, but it seems at least noone else wrote it down until now. 🙂
We hat a customer who liked our Office365 Provider-Hosted App “Mydea”, but wanted us to install that on his SharePoint 2013 – Installation. In Germany a lot of companies do not trust the cloud. So we had three options:

  1. Tell the customer this does not work
  2. Copy&paste the whole solution and change it so it works on OnPrem
  3. Do something else

The first option – of course – wasn’t valid for me. The second would have worked. But I did not want to end up in maintanance hell. Our product is about innovation management. And the most innovative about that is the product itself. We develop agile, adding new features (and sometimes bugs) continuously. We do not want to do that twice.

So I ended up on the third option: Changing my solution so it will run in an Office365 – SharePoint and on an On-Premise installation of SharePoint 2013 (or above).

Continue reading

Wayback Machine and 301 redirects

As you might know: the wayback machine from saves snapshots of websites. It does this automatically or can be forced to do so. However. If you ever had a 301 redirect on your site you are very much doomed.

Like browsers also the wayback-machine caches the redirect and does not continue to take snapshots from your sites. Even if you enter your url into the wayback-machine, you still will be redirected.

You can however force it to ignore the cache by manually store your site again:[YOURSITE]

for example:

Et voílà: Everything works nice from now on.


[Image is CC-BY-NC-ND © David Baldinger]

Getting rid of Proxy limitations using Fiddler

If you work in a company that uses Proxy authentication (aka forces you to enter a password to access websites) and are a developer you know my pain: Some Most applications just don’t really like proxies. Visual Studio itself for example does not like proxy authentication at all and responses with a wide variety of error codes (407 for example).

You can get rid of all these errors through different workarounds, but these are a real PITA.

In addition the application you code itself needs Internet access, for example if you develop Office365 AddIns, you are very much screwed.

After a long research I finally found a solution using Fiddler.

Most developers already use Fiddler for debugging reasons so there isn’t even any software that needs to be installed.

Continue reading