La Frite, boot in NON-headless mode

Is there anyone out there who managed to get the La Frite running in NON-headless mode?

I have tried for somewhat like 6 days with every possible booting method/device, I even set up a TFTP server. But no matter what, it always crashes mostly BTRFS errors, but also inaccessible keyboard at boot, boot loops with keyboard USB keys inserted.

I managed to get a headless image running (but don't even remember which one it was). Or at least I could SSH into it.



  • Have you tried the latest images on
    If they say XFCE | LXDE | MATE those are all GUI (non-headless) images available to boot from the USB port on the right.
  • Your USB device is not reliable. BTRFS has strict checksums for disk data. Find another USB device.
  • edited July 9
    I downloaded the MATE version image from 07/06 onto a SANDISK 32GB drive using Win32DiskImager. I inserted the USB stick and after a short time (less than 2 minutes), it booted into the UBUNTU GUI. Other than the fact that I was suppose to receive the working version already burned onto my 8GB eMMC, I am a happy camper. 

    Update - 07/09/2019 = got the eMMC loaded with image using the article "la frite how to flash emmc".  Here is the dump of the command and the process it went through to load it...  I first started up the terminal program from within UBUNTU GUI interface... The ONLY thing I typed was the command in bold type. The rest was automatic and generated by the command.
    libre@libre-computer:~$ sudo lc_distro_transfer libre-computer/aml-s805x-ac /dev/mmcblk0 lc-ubuntu-18.04-mate
    [sudo] password for libre:
    1+0 records in
    1+0 records out
    1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0325175 s, 32.2 MB/s

    Welcome to fdisk (util-linux 2.31.1).
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.

    Device does not contain a recognized partition table.
    Created a new DOS disklabel with disk identifier 0xc3c17c7c.

    Command (m for help): Created a new DOS disklabel with disk identifier 0xc4210b21.

    Command (m for help): Partition type
       p   primary (0 primary, 0 extended, 4 free)
       e   extended (container for logical partitions)
    Select (default p): Partition number (1-4, default 1): First sector (2048-15269887, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (2048-15269887, default 15269887):
    Created a new partition 1 of type 'Linux' and of size 255 MiB.

    Command (m for help): Selected partition 1
    The bootable flag on partition 1 is enabled now.

    Command (m for help): Selected partition 1
    Hex code (type L to list all codes): Changed type of partition 'Linux' to 'EFI (FAT-12/16/32)'.

    Command (m for help): Partition type
       p   primary (1 primary, 0 extended, 3 free)
       e   extended (container for logical partitions)
    Select (default p): Partition number (2-4, default 2): First sector (524288-15269887, default 524288): Last sector, +sectors or +size{K,M,G,T,P} (524288-15269887, default 15269887):
    Created a new partition 2 of type 'Linux' and of size 7 GiB.

    Command (m for help): Disk /dev/mmcblk0: 7.3 GiB, 7818182656 bytes, 15269888 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0xc4210b21

    Device         Boot  Start      End  Sectors  Size Id Type
    /dev/mmcblk0p1 *      2048   524287   522240  255M ef EFI (FAT-12/16/32)
    /dev/mmcblk0p2      524288 15269887 14745600    7G 83 Linux

    Command (m for help): The partition table has been altered.
    Calling ioctl() to re-read partition table.
    Syncing disks.

    mkfs.fat 4.1 (2017-01-24)
    btrfs-progs v4.15.1
    See for more information.

    Detected a SSD, turning off metadata duplication.  Mkfs with -m dup if you want to force metadata duplication.
    Label:              SYSTEM
    UUID:               9a4cf0b4-60a5-49e9-b19b-12a695adaedf
    Node size:          16384
    Sector size:        4096
    Filesystem size:    7.03GiB
    Block group profiles:
      Data:             single            8.00MiB
      Metadata:         single            8.00MiB
      System:           single            4.00MiB
    SSD detected:       yes
    Incompat features:  extref, skinny-metadata
    Number of devices:  1
       ID        SIZE  PATH
        1     7.03GiB  /dev/mmcblk0p2

    At subvol /tmp/tmp.qy5J1N5qlE/@lc-ubuntu-18.04-mate
    At subvol @lc-ubuntu-18.04-mate
    3.41GiB [14.5MiB/s] [=====================================================] 105%
    Create a snapshot of '/tmp/tmp.SmDwqkD8oA/@lc-ubuntu-18.04-mate' in '/tmp/tmp.SmDwqkD8oA/@'
    Installing for arm64-efi platform.
    Installation finished. No error reported.
    Sourcing file `/etc/default/grub'
    Generating grub configuration file ...
    Found linux image: /boot/vmlinuz-4.19.57+
    Found initrd image: /boot/initrd.img-4.19.57+
    DEVICE /dev/mmcblk0 READY!

  • edited July 9
    Tried all of these images:

    Tried these media:
    32 Gb cheap USB 3.0 disk (on which I ran a full analysis the first time I encountered the BTRFS errors. Test completed no errors)
    4 Gb Toshiba USB drive
    64 Gb SanDisk Cruzer Extreme
    Cheap 4Gb sandisk SD card
    8 Gb SanDisk Extreme SD card with Sandisk adaptor
    4 Gb SanDisk Ultra microSD card with Sandisk adaptor
    128 Gb Samsung EVO Plus U3 microSD with Samsung adaptor

    Tried these methods:
    Burned with Balena with verification
    Burned with Win32DiskImager
    Booting through TFTP (Solarwinds free TFTPserver)

    Tried these USB ports:
    Left and right USB port.
    When a keyboard dongle is in the left port, the system bootloops, no matter what image is on the disk

    I have been on this for days on end, reformatting the drives and memory cards every single time. I only succeeded once to get a headless with SSH login.

  • u-boot's USB support is not very reliable in 2019.04. Some USB dongles that come with keyboards will cause hangs. We will build the 2019.07 version soon. Can you boot without the keyboard until you are in Linux and then plug the keyboard in?
  • No, that doesn't work either.
    I can give you a link to the video I took while it was booting (with and without USB keyboard/dongle keyboard).

  • Finally managed to boot, using an Emtec external 10 in 1 adapter fitted with a  Sandisk Ultra 8Gb, and without keyboard or dongle inserted at first (when I did, it boot looped again)
    Successfully managed to transfer the system to EMMC, however, once it went into standby mode, I couldn't revive it.

  • Just shutdown the board or leave it on. There's no standby mode. It uses less than 1W anyway.
  • After a bunch of failures, I switched to a brand new 32gb SanDisk CZ48 Ultra USB 3.0. Got to the primary screen, able to bring up Firefox, Even recognized my mouse / keyboard behind the KVM. Appears to have frozen already, but this is a huge improvement over brtfs errors.
  • Well, as there is no standby mode, it appears frozen then as rdl_03 here above mentions.
    Point is, that when returning after one hour, the GUI had disappeared, there was a time tagged error, and it was dead.
    So up to now, I have NOT succeeded in running anything at all.

    BTW: how do we get into Uboot mode when an image is already flashed into the eMMC? I wanted to try other images, but I can't get them to boot from USB anymore (even though it recognizes the partitions). Pressing ESC on the keyboard does not work as the keyboard can only be inserted (activated) once the OS has loaded. Meaning that I am currently stuck with a working Debian XFCE which I cannot let go to "sleep" because it crashes if I do not use it.

  • the ubuntu-mate version I tried booted from USB but when transferred to emmc will not boot
  • Actually, I haven't had one single image or device that booted consistently.
    The only thing I now have, is a Debian XFCE image flashed eMMC which I can't reflash because I can't get into Uboot.
    Kind of a paperweight currently.
  • Have you tried double pressing escape on boot and just running run boot_usb0?
  • I did using
    run bootcmd_usb0
    on u-boot. I have two keyboards and one gets activated on u-boot for pressing Escape, only on RIGHT USB but the other keyboard works on both USBs. Different keyboards seem to work differently for u-boot.
  • @djismgaming u-boot's USB stack is steadily improving. The version on La Frite that was shipped is u-boot 2019.04. We will update to 2019.10 when that is released to see if the situation improves.
  • @Loverpi:
    I have tested about 8 keyboards, both direct USB ones and dongle based ones., and on both USB ports, left and right. None react before the system boots to the OS that is installed to eMMC. After booting to Debian, I can use the keyboard, but NOT before.
  • The reliable fallback for u-boot access is to use another PC, and a USB-to-3.3V-serial adapter, plugged into the correct three pins of the GPIO header.  This lets you completely bypass the board's USB interfaces and the u-boot USB stack.

  • Did you press escape escape at the very beginning?
  • Yup, started pushing it in a 2 per second rythm even before i pressed the power button.

  • @DaveP: precise instructions? Using serial or ....?
  • You need a "USB to 3.3-volt serial" debug cable (or a USB dongle, plus a set of jumpers). You can buy these from Mouser, DigiKey, AdaFruit, SparkFun, and similar vendors. I personally prefer the ones with FTDI chipsets (DigiKey and Mouser are authorized distributors so you can be confident that these are genuine). The SiLabs CP2102 and the CH340 also seem to be OK. Be cautious about ones claiming to have the ProLogic PL2302 chip, as many of these are counterfeits and may not work with recent versions of Windows. All of these need chipset-specific drivers; I think they're all well-supported by the drivers built into current Linux kernels. For Windows you may need to download and install a driver. You'll need to connect three wires on the cable (or dongle) to three pins on the 40-pin GPIO header. "For UART, it's pin 3,5,6 for TX,RX,GND respectively" according to the serial-debug thread in this forum (and that's what works for me as well). These are *not* the same pins as the Raspberry Pi uses for the serial UART! Plug the dongle into your PC's USB port. Fire up a decent terminal emulator program. Select the correct communication port (on Linux it will probably be /dev/ttyUSB0, and some COM port on Windows). Select 8-bit, no parity, 1 stop bit (8-N-1). Select the correct baud rate (I think it's 115200 but it might be twice that - I do not remember). Un-select hardware and software handshaking (flow control) and "data carrier detect". Power on the La Frite. You should see a bunch of readable output appear in the the terminal emulator window - this is the u-boot output. Immediately hit the ESC key a few times. This should interrupt the boot sequence and get you to a u-boot prompt. At that point you can type "printenv" to dump out all of the u-boot environment variables. A bunch of these control the boot process and device sequence. Read and interpret, and change or overrride as you see fit. Hope this helps!
  • edited July 15
    Some documentation is always useful. (Or did I miss that on La Frite somehwere?)
    Thx DaveP.
    Trying tomorrow.

  • So I'm actually typing this in the browser on La Frite. It's been consistently booting (key was getting the right USB drive (mentioned above) - USB hub has a keyboard and a Logitech unified adapter supporting a mouse. Speed is underwhelming - clearly this isn't what this is intended to be used for. But it's working - so bravo!  Looking forward to when Android images will be available (and when my eMMC arrives....)
Sign In or Register to comment.