Where is the July 4 release?

JolleyLama

The latest kickstarter update said there would be a release for Le Frite today. Where is the July 4 OS release? I don't even see an -805- folder in http://share.loverpi.com/board/. I'm probably just missing something as far as the location of the files.

loverpi

We are actually responsible for the software images. There's like 2 more that needs to be built before we upload it all.

abrugsch

http://share.loverpi.com/board/libre-computer-project/libre-computer-board/image/Debian

And
http://share.loverpi.com/board/libre-computer-project/libre-computer-board/image/ubuntu/
Has a load of images now

JolleyLama

Thank you for posting the image and replying to this forum for everyone to know.

jimm0thy

Are any of these able to be flashed to eMMC through the usb_burning_tool directly? If not how do we go about booting from usb when then eMMC already has an OS on it?

blood

jimm0thy said:

Are any of these able to be flashed to eMMC through the usb_burning_tool directly? If not how do we go about booting from usb when then eMMC already has an OS on it?

Indeed, it would be great to have guidance on this. I already flashed the previous image to eMMC and uboot automatically prefers it when rebooting. I'm about to dig into the uboot docs to try to figure this out, but if anyone has the recipe please post it.

blood

To force the next boot to use usb rather than eMMC, reset the device and halt the boot by pressing 'esc'. I modified the boot_targets variable to prefer usb and that was enough. To view the current value:

=> echo $boot_targets

Then to change it, use something like:

=> setenv boot_targets usb0 romusb mmc0 pxe dhcp

Follow that by "boot" which should boot off the usb drive. You can verify it used the intended storage by logging in (libre/computer) and running "mount" and observing that it's using /dev/sda2 for / and /dev/sda1 for the /boot/efi/ - if it still shows /dev/mmc stuff something went wrong. Once booted off USB, do the procedure you followed before with lc_distro_transfer to reflash the eMMC. Then reboot - even with the USB stick present it should prefer eMMC (the setenv isn't permanent) and so should use it.

jimm0thy

blood said:

To force the next boot to use usb rather than eMMC, reset the device and halt the boot by pressing 'esc'. I modified the boot_targets variable to prefer usb and that was enough. To view the current value:

=> echo $boot_targets

Then to change it, use something like:

=> setenv boot_targets usb0 romusb mmc0 pxe dhcp

Follow that by "boot" which should boot off the usb drive. You can verify it used the intended storage by logging in (libre/computer) and running "mount" and observing that it's using /dev/sda2 for / and /dev/sda1 for the /boot/efi/ - if it still shows /dev/mmc stuff something went wrong. Once booted off USB, do the procedure you followed before with lc_distro_transfer to reflash the eMMC. Then reboot - even with the USB stick present it should prefer eMMC (the setenv isn't permanent) and so should use it.

Very nice thanks

djismgaming

also after pressing Escape on keyboard to halt boot from eMMC, use this to run from USB

run bootcmd_usb0

loverpi

We already upstreamed support for La Frite to emulate itself as a flash drive that you can directly flash. That feature will go into the next firmware and will allow you to directly flash the eMMC like a flash drive from a computer.

jimm0thy

loverpi said:

We already upstreamed support for La Frite to emulate itself as a flash drive that you can directly flash. That feature will go into the next firmware and will allow you to directly flash the eMMC like a flash drive from a computer.

Awesome, thanks

rdl_03

Has anyone had success with these images? I've downloaded the Ubuntu bionic xfce mali one. Copied it to a 16 gig USB key using etcher on Ubunto). (it only uses 4 gigs of the drives capacity).

It comes up as what I'm familiar with as the Ubuntu startup, but very quickly runs into btrfs errors, and stops.

Ingmar

Same problem. Been on it for days with all kinds of media and methods.

rdl_03

Tried the Debian image stretch lxde mali 4.19.57 - same problem.

FransM

btrfs errors means a bad download or a bad USB disk.

I didn't try the xfce images but the debian headless image worked for me.

I used a lexar micro-sd card i(32 GB) n a lexar usb card reader.

Oh, thinking of it, it may also be that the transfer to your USB caused issues. You might want to read back your image to a different filename and compare. I used a linux system and the dd command to transfer the image to USB.

rdl_03

I tried the Debian headless, with the same problem. I transfer stuff between SSD and USB cards all the time, and have never seen an issue. Seems pretty low probability that that's the issue.

Since the image is expanded onto  the USB key, and an .img file after extracting from the zip, not sure how you would compare them.

loverpi

A lot of tool has a "verify" checkbox to verify data written. BTRFS errors means the checksum didn't match which means disk error happened.

hemant

I have installed ubuntu-18.04.2-server-arm64.iso using USB boot. I want to use TP-Link (TL-WN725) USB Wi-Fi dongle, but it gets disconnected frequently from Wi-Fi.  On the net I found a method to install the driver from source.

---------------------------------------------------------------------
sudo apt-get update

sudo apt-get install -y linux-headers-$(uname -r) build-essential git

git clone https://github.com/lwfinger/rtl8188eu

cd rtl8188eu

make all

sudo make install

sudo insmod 8188eu.ko
--------------------------------------------------------------------
make all fails

$ make all

make ARCH=arm64 CROSS_COMPILE= -C /lib/modules/4.19.57+/build M=/home/libre/TL-WN725/rtl8188eu  modules

make[1]: Entering directory '/usr/src/linux-headers-4.19.57+'

  CC [M]  /home/libre/TL-WN725/rtl8188eu/core/rtw_ap.o

  CC [M]  /home/libre/TL-WN725/rtl8188eu/core/rtw_br_ext.o

 ....... deleted many lines

  CC [M]  /home/libre/TL-WN725/rtl8188eu/os_dep/xmit_linux.o

  LD [M]  /home/libre/TL-WN725/rtl8188eu/8188eu.o

  Building modules, stage 2.

  MODPOST 1 modules

/bin/bash: scripts/mod/modpost: cannot execute binary file: Exec format error

scripts/Makefile.modpost:92: recipe for target '__modpost' failed

make[2]: *** [__modpost] Error 126

Makefile:1520: recipe for target 'modules' failed

make[1]: *** [modules] Error 2

make[1]: Leaving directory '/usr/src/linux-headers-4.19.57+'

Makefile:151: recipe for target 'modules' failed

make: *** [modules] Error 2

----------------------------------------------------

The make is failing because /usr/src/linux-headers-4.19.57+/scripts/mod/modpost executable has x86 architecture instead of arm64.

$ file /usr/src/linux-headers-4.19.57+/scripts/mod/modpost: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=8fb5ddab78c3326c61b9239f0442964005f1d67a, not stripped

$ ls /usr/src/linux-headers-4.19.57+/scr

devicetable-offsets.c  elfconfig.h   file2alias.o    modpost    modules.order

devicetable-offsets.h  empty.c       Makefile        modpost.c  sumversion.c

devicetable-offsets.o  empty.o       mk_elfconfig    modpost.h  sumversion.o

devicetable-offsets.s  file2alias.c  mk_elfconfig.c  modpost.o
So I tried to make the modpost as all source files are included. But it fails.

$ make 

make: *** No rule to make target '/devicetable-offsets.s', needed by '/devicetable-offsets.h'.  Stop.

$ cat Makefile

# SPDX-License-Identifier: GPL-2.0

OBJECT_FILES_NON_STANDARD := y

hostprogs-y := modpost mk_elfconfig

always := $(hostprogs-y) empty.o

modpost-objs := modpost.o file2alias.o sumversion.o

devicetable-offsets-file := devicetable-offsets.h

$(obj)/$(devicetable-offsets-file): $(obj)/devicetable-offsets.s FORCE

$(call filechk,offsets,__DEVICETABLE_OFFSETS_H__)

targets += $(devicetable-offsets-file) devicetable-offsets.s

# dependencies on generated files need to be listed explicitly

$(obj)/modpost.o $(obj)/file2alias.o $(obj)/sumversion.o: $(obj)/elfconfig.h

$(obj)/file2alias.o: $(obj)/$(devicetable-offsets-file)

$(obj)/elfconfig.h: $(obj)/empty.o $(obj)/mk_elfconfig FORCE

$(call if_changed,elfconfig)

targets += elfconfig.h

--------------------------------------
Couple of queries ...
1) Why does linux-headers-4.19.57+ . have x86 binaries instead of arm64 binaries?
2) Can someone guide how to build the modpost & mk_elfconfig ( two executables in mod directory) or perhaps the entire linux-header-4.19-57+ ?

DaveP

I'm unclear... are you doing this build on the La Frite itself, or are you cross-compiling on an X86 host?

My guess is that you are trying to build natively on the La Frite, and that the kernel and headers packages there were probably cross-compiled using an X86 host.  The modules package probably has the binaries needed/used during cross compilation, not binaries cross-compiled for the target (since these would not be usable on the cross-compiling host).

You probably have two choices.  You can try transferring all of the La Frite kernel headers to an X86 system, and try cross-compiling the module there.  Or you can download the whole La Frite kernel source tree to the La Frite, configure it identically with the one in your distro, build (getting a modpost etc. as a side effect) and then install the binaries this built in place of the not-useful X86 binaries in your headers directory... and then build your module.

loverpi

@hemant ;https://forum.loverpi.com/discussion/555/how-to-fix-dkms-error-bin-sh-1-scripts-basic-fixdep-exec-format-error