On 06/11/17 23:03, Paolo Pisati wrote:
> Your suggestion makes sense, but can you give me the exact steps on how
> to test it afterward?
>
> I gave a quick glance at u-boot master, but i couldn't find any 'uefi'
> or 'rpi3-uefi' target in configs. Or shall i just build the rpi3 target
> and then pass a UEFI fw as a payload? And where do i get the UEFI fw
> from? Instructions on how to setup the system are welcome.
It was lot easier to get working than I had expected. There are a couple
of gotchas left, but it works great (and is the cheapest way I know to
run arm64...) once you get through them... I intend to look at fixing
most of these for bionic.
Prepare an MBR-partitioned microSD card with a FAT16 or FAT32 partition
at the start to be used for firmware and as the UEFI ESP; 100MB is
ample. The only gotcha here is that the firmware doesn't seem to know
about partition type 0xEF (ESP), but u-boot will happily load GRUB from
a 0xE (FAT16 LBA) that the platform firmware is happy with.
Then give it firmware:
git clone git://git.denx.de/u-boot.git
pushd u-boot
make rpi_3_defconfig
make CROSS_COMPILE=aarch64-linux-gnu-
# kernel8.img is important -- the 8 forces start.elf to do aarch64.
cp u-boot.bin /PATH/TO/MICROSD/FAT16_OR_32/PART/kernel8.img
popd
Boot the RPi3 with Ethernet, HDMI and a USB keyboard. After a few
seconds of u-boot, a hideous looking, bright red, awfully corrupt, but
still readable GRUB 2 prompt will appear. d-i will automatically start,
with no visual issues.
Switch to another VT and grab bcm2835.ko for the relevant kernel. For
artful's 4.13.0-16.19:
Then switch back to tty0 and proceed with the install. The partitioner
will see the internal microSD, but care is required with partitioning:
if you recreate the partition table it will default to GPT, which the
RPi3 firmware can't read, and if you recreate the boot partition it'll
end up with no firmware and type 0xEF (both of which are fixable
afterwards from another machine). The easiest way is to just set the
existing boot partition as an ESP in the installer, which won't change
the type. Then create a partition for / etc. as, and proceed with the
install as normal.
Everything will now work fine, except nothing will be visible on HDMI
unless GRUB initialises the EFI console, which you can force after the
install by commenting out GRUB_HIDDEN_TIMEOUT in /etc/default/grub and
running update-grub, and you might also need to disable plymouth be
removing "splash".
I haven't tested GPU bits, but the only hardware I found that didn't
work was the WiFi chip, since linux-firmware is missing
brcmfmac43430-sdio.txt (it just has the .bin). But I grabbed a new
brcmfmac43430-sdio.{txt,bin}, and it all seems rock solid on -generic now.
On 06/11/17 23:03, Paolo Pisati wrote:
> Your suggestion makes sense, but can you give me the exact steps on how
> to test it afterward?
>
> I gave a quick glance at u-boot master, but i couldn't find any 'uefi'
> or 'rpi3-uefi' target in configs. Or shall i just build the rpi3 target
> and then pass a UEFI fw as a payload? And where do i get the UEFI fw
> from? Instructions on how to setup the system are welcome.
It was lot easier to get working than I had expected. There are a couple
of gotchas left, but it works great (and is the cheapest way I know to
run arm64...) once you get through them... I intend to look at fixing
most of these for bionic.
Prepare an MBR-partitioned microSD card with a FAT16 or FAT32 partition
at the start to be used for firmware and as the UEFI ESP; 100MB is
ample. The only gotcha here is that the firmware doesn't seem to know
about partition type 0xEF (ESP), but u-boot will happily load GRUB from
a 0xE (FAT16 LBA) that the platform firmware is happy with.
Then give it firmware:
git clone git://git. denx.de/ u-boot. git aarch64- linux-gnu- MICROSD/ FAT16_OR_ 32/PART/ kernel8. img
pushd u-boot
make rpi_3_defconfig
make CROSS_COMPILE=
# kernel8.img is important -- the 8 forces start.elf to do aarch64.
cp u-boot.bin /PATH/TO/
popd
git clone --depth 1 gh:raspberrypi/ firmware raspberrypi- firmware firmware MICROSD/ FAT16_OR_ 32_PART/
pushd raspberrypi-
cp bootcode.bin start.elf fixup.dat /PATH/TO/
popd
None of the dtbs are required.
Insert the microSD card into the RPi3. Also insert a USB mass storage ports.ubuntu. com/ubuntu- ports/dists/ artful/ main/installer- arm64/current/ images/ netboot/ mini.iso
device with
http://
written to it.
Boot the RPi3 with Ethernet, HDMI and a USB keyboard. After a few
seconds of u-boot, a hideous looking, bright red, awfully corrupt, but
still readable GRUB 2 prompt will appear. d-i will automatically start,
with no visual issues.
Switch to another VT and grab bcm2835.ko for the relevant kernel. For
artful's 4.13.0-16.19:
wget --no-check- certificate https:/ /williamgrant. id.au/f/ 1/2017/ bcm2835. ko
insmod bcm2835.ko
Then switch back to tty0 and proceed with the install. The partitioner
will see the internal microSD, but care is required with partitioning:
if you recreate the partition table it will default to GPT, which the
RPi3 firmware can't read, and if you recreate the boot partition it'll
end up with no firmware and type 0xEF (both of which are fixable
afterwards from another machine). The easiest way is to just set the
existing boot partition as an ESP in the installer, which won't change
the type. Then create a partition for / etc. as, and proceed with the
install as normal.
Everything will now work fine, except nothing will be visible on HDMI
unless GRUB initialises the EFI console, which you can force after the
install by commenting out GRUB_HIDDEN_TIMEOUT in /etc/default/grub and
running update-grub, and you might also need to disable plymouth be
removing "splash".
I haven't tested GPU bits, but the only hardware I found that didn't sdio.txt (it just has the .bin). But I grabbed a new sdio.{txt, bin}, and it all seems rock solid on -generic now.
work was the WiFi chip, since linux-firmware is missing
brcmfmac43430-
brcmfmac43430-