Image | Odroid C1 Stretch #2561

MichaIng · 2019-02-17T12:43:14Z

Okay, I thought open up a separate issue makes sense here, as things turn out to be more complicated.

Related issues:

https://github.com/Fourdee/DietPi/issues/2026#issuecomment-461925950
More and more software titles drop Jessie support, e.g.: https://github.com/Fourdee/DietPi/issues/2521
Aim to drop Jessie support with DietPi, as above makes it more and more complicated to keep it: https://github.com/Fourdee/DietPi/issues/2332

The problem seems to be, that from Meverics repo (and hardkernel sources) the latest kernel version is 3.10, while Debian Stretch usually requires 3.16 at least.

EDIT: Although Sparky SBC runs with Stretch fine as well with kernel `3.10`

Some successful distro upgrades have been done by users, but they might have unexpected issues and limitations in cases: https://forum.odroid.com/viewtopic.php?f=114&t=17569&start=250

ARMbian offers a Stretch image based on kernel 4.18 but it has critical limitations as well, especially no graphics output, serial console only, no eMMC support: https://www.armbian.com/odroid-c1/#kernels-archive

Both above options don't lead to a reliable and functional Stretch image, although distro upgrading Meverics Jessie image at least does not touch kernel/driver so core functionality should stay?
If we have an Odroid C1, at least it is worth testing, distro upgrading to Stretch and test core + desktop + Kodi functionality.

Since I don't have one and Fourdee can't find his C1 currently, if there is anyone willing to try the above, this would be a great first step to check feasibility.

The text was updated successfully, but these errors were encountered:

Fourdee · 2019-05-02T14:01:17Z

@MichaIng
Image live, based on ARMbian 4.18 kernel.
https://dietpi.com/downloads/images/DietPi_OdroidC1-ARMv7-Stretch.7z

Some notes:

Due to jessie support drop in v6.23. This image is now the main image, jessie removed.
CPU clocks appear lower, however, no kernel support to obtain clocks. cpu bench +10 seconds compared to 3.x kernel.
Rebooting the system does not always "reboot", may hang with blue light on. Simply re-plug power cable
No GPU support
No hdmi output
No eMMC support?

Fourdee · 2019-05-02T14:15:15Z

@MichaIng

Hmm, alot of negatives for Stretch on the C1. Yes I could probably use Meverics kernel on Stretch, but even then we loose GPU support and Kodi.
Low user count (the jessie image would fail aswell).

Debating if we should drop the device altogether as all dev/support by open source comminuty seems to have stopped?

Spent 3 days on/off with this, not having much luck if iam honest ☹️

Fourdee · 2019-05-02T14:27:19Z

@MichaIng

I'll do 1 more try with Meveric 3.x under Stretch, when I can. See if any joy.

MichaIng · 2019-05-02T14:28:30Z

Hmm dist-upgrading from Meverics Jessie kernel 3.10 image does not work as well?

Yeah I also believe in case we just offer the final Jessie image which user will have at least DietPi v6.24 support for and then drop it, respectively ship as EOL final image.

MichaIng · 2019-05-02T14:33:26Z

Ah as said, I plan to merge DietPi v6.24 into the jessie-support branch as well, then most likely remove Jessie support from code with v6.25. The branch migration is done now already to have most users migrated as soon as possible. This allows to remove the migration code itself midterm earlier as we cannot guarantee DietPi-Globals (loaded from patch_file) Jessie support for old Jessie images/systems forever.

jcw · 2019-05-04T19:06:30Z

C1+ user here - I understand and respect your reasons for dropping support. Let me just mention that the board is still sold (even marked "hot" on hardkernel.org - maybe it's their way to clear inventory?). Even without GPU support, it's still a nice server with its 1 Gbit Ethernet, which is how I've used it.

MichaIng · 2019-05-04T21:21:29Z

@jcw

marked "hot" on hardkernel.org - maybe it's their way to clear inventory?

This is how it must be interpreted. Sadly this is common practice across SBC manufacturers. Never buy an SBC that is older than one year. Kernels major versions are often never updated, limiting the support for newer distro versions. For manufacturer images its mostly the same. Hardkernel at least ships relatively current Ubuntu images, but the kernel is never updated. We use the well maintained minimal Debian images from Meveric but his possibilities are limited as well due to lack of kernel development.
As a result in case of C1 I couldn't fine any open source Debian derivatives that still supports C1 images.

This is the reason I would still never buy anything else than an RPi for personal use. This is the ONLY SBC that is at current stage forever supported with current kernel versions and very regular OS updates. Soon you can run your very day-1 RPi1 with Buster image and kernel 4.19. Outstanding from that point of view. Sadly very limited performance.

To be fair about the above:

The Raspberry Pi Foundation sells muuch more SBCs than any other manufacturer. So they simply have the financial background that allows active kernel development.
Kernel development is very difficult work that is implicit when using ARM. You can imagine this when facing certain limitations and issues with the provided images, as well when using 3rd party images with custom kernels that are developed by larger capable teams.
This is also the reason why we (DietPi) do no own kernel development. It would take way too much time, exceeding our man power and abilities and only raises the risk to ship introduced bugs with them. So we have to be careful with blaming kernel development and respect + honour the work that is done, even facing limitations here and there! 😉

jcw · 2019-05-12T10:33:41Z

Thanks for keeping the Odroid C1 supported - I'm trying the new 6.23 beta, but seem to be running into some issues. Context: image flashed to eMMC (via µSD adapter) on MacOS using dd. The first difference I note is that the result complains about not being mountable on MacOS (it used to come up as /Volumes/boot after the dd completes).

And then, in the Odroid, on bootup, with console attached, I get this:

 QA5:A;SVN:B72;POC:17F;STS:0;BOOT:0;INIT:0;READ:41;READ:41;READ:0;CHECK:0;PASS:0;
-----------------------------------------------------------------------
* Welcome to Hardkernel's ODROID-C... (Built at 19:33:00 Dec  8 2014) *
-----------------------------------------------------------------------
CPU : AMLogic S805
MEM : 1024MB (DDR3@792MHz)
BID : HKC1310001
S/N : HKC11122F37E012E
0x0000009f
Loading U-boot...success.


U-boot-00000-gb7b8dc2-dirty(odroidc@b7b8dc21) (Sep 19 2018 - 12:23:57)

I2C:   clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[25]=0
clear pinmux reg8[12]=0
clear pinmux reg1[3]=0
clear pinmux reg1[2]=0
set output en 0xc1108054[20]=1
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[25]=0
clear pinmux reg8[12]=0
clear pinmux reg1[3]=0
clear pinmux reg1[2]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[20]=0
set output val 0xc1108058[20]=0
clear pinmux reg1[25]=0
clear pinmux reg8[12]=0
clear pinmux reg1[3]=0
clear pinmux reg1[2]=0
set output en 0xc1108054[20]=1
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=fffcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffdcfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[25]=0
clear pinmux reg8[12]=0
clear pinmux reg1[3]=0
clear pinmux reg1[2]=0
out reg=c1108058,value=ffccfa00
set output en 0xc1108054[20]=0
set output val 0xc1108058[20]=0
clear pinmux reg1[24]=0
clear pinmux reg1[1]=0
out reg=c1108058,value=ffecfa00
set output en 0xc1108054[21]=0
set output val 0xc1108058[21]=0
clear pinmux reg1[25]=0
clear pinmux reg8[12]=0
clear pinmux reg1[3]=0
clear pinmux reg1[2]=0
set output en 0xc1108054[20]=1
clear pinmux reg1[25]=0
clear pinmux reg8[12]=0
clear pinmux reg1[3]=0
clear pinmux reg1[2]=0
set output en 0xc1108054[20]=1
clear pinmux reg1[25]=0
clear pinmux reg8[12]=0
clear pinmux reg1[3]=0
clear pinmux reg1[2]=0
set output en 0xc1108054[20]=1
ready
DRAM:  1 GiB
relocation Offset is: 2ff18000
MMC:   eMMC: 0, SDCARD: 1
IR init is done!
vpu clk_level = 3
set vpu clk: 182150000Hz, readback: 182150000Hz(0x701)
mode = 6  vic = 4
set HDMI vic: 4
mode is: 6
viu chan = 1
config HPLL
config HPLL done
reconfig packet setting done
MMC read: dev # 0, block # 33984, count 12288 ... 12288 blocks read: OK
Error: Bad gzipped data
There is no valid bmp file at the given address
============================================================
Vendor: Man 110100 Snr 418f538f Rev: 3.3 Prod: 064G9
            Type: Removable Hard Disk
            Capacity: 59640.0 MB = 58.2 GB (122142720 x 512)
------------------------------------------------------------
Partition     Start Sector     Num Sectors     Type
    1		      8192	   1024000	83
============================================================
Net:   Meson_Ethernet
init suspend firmware done. (ret:0)
Hit Enter key to stop autoboot -- :  0
exit abortboot: 0

** Unable to use mmc 0:1 for fatload **
Loading file "/boot/boot.ini" from mmc device 0:1 xxa1
3929 bytes read
Loading boot.ini from mmc0:1 (ext4)
Executing the script...
setenv rootdev "UUID=18ef9117-8b19-4fa0-a35b-aa6023dd1e3d"
setenv rootfstype "ext4"
setenv m "1080p"                # 1080P@60Hz
setenv vout_mode "hdmi"
setenv m_bpp "32"
setenv monitor_onoff "false" # true or false
setenv hpd "0"
setenv cec "0"
setenv disableuhs "disableuhs"
setenv vpu "1"
setenv hdmioutput "1"
if test -e mmc 0:1 boot/.next; then setenv condev "console=ttyAML0,115200n8"; else setenv condev "console=ttyS0,115200n8 console=tty0"; fi
setenv disable_vu7 "false" # false
setenv max_freq "1536"
if test "${hpd}" = "0"; then setenv hdmi_hpd "disablehpd=true"; fi
if test "${cec}" = "1"; then setenv hdmi_cec "hdmitx=cecf"; fi
if test "${disable_vu7}" = "false"; then setenv hid_quirks "usbhid.quirks=0x0eef:0x0005:0x0004"; fi
setenv bootargs "root=${rootdev} rootwait rw ${condev} rootfstype=${rootfstype} loglevel=3 no_console_suspend consoleblank=0 vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout_mode} ${disableuhs} ${hdmi_hpd} ${hdmi_cec} ${enabledac} monitor_onoff=${monitor_onoff} max_freq=${max_freq} ${hid_quirks} ${extraargs}"
ext4load mmc 0:1 0x21000000 /boot/uImage || fatload mmc 0:1 0x21000000 uImage || ext4load mmc 0:1 0x21000000 uImage
Loading file "/boot/uImage" from mmc device 0:1 xxa1
7426624 bytes read
ext4load mmc 0:1 0x22000000 /boot/uInitrd || fatload mmc 0:1 0x22000000 uInitrd || ext4load mmc 0:1 0x22000000 uInitrd
Loading file "/boot/uInitrd" from mmc device 0:1 xxa1
3272729 bytes read
ext4load mmc 0:1 0x21800000 /boot/dtb/meson8b_odroidc.dtb || fatload mmc 0:1 0x21800000 dtb/meson8b_odroidc.dtb || ext4load mmc 0:1 0x21800000 dtb/meson8b_odroidc.dtb
Loading file "/boot/dtb/meson8b_odroidc.dtb" from mmc device 0:1 xxa1
** File not found /boot/dtb/meson8b_odroidc.dtb

** Unable to use mmc 0:1 for fatload **
Loading file "dtb/meson8b_odroidc.dtb" from mmc device 0:1 xxa1
** File not found dtb/meson8b_odroidc.dtb
ext4load mmc 0:1 0x21800000 /boot/dtb/meson8b-odroidc1.dtb
Loading file "/boot/dtb/meson8b-odroidc1.dtb" from mmc device 0:1 xxa1
10827 bytes read
fdt addr 21800000
if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi
if test "${hdmioutput}" = "0"; then fdt rm /mesonfb; fi
bootm 0x21000000 0x22000000 0x21800000
## Booting kernel from Legacy Image at 21000000 ...
   Image Name:   Linux kernel
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    7426560 Bytes = 7.1 MiB
   Load Address: 00208000
   Entry Point:  00208000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 22000000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    3272665 Bytes = 3.1 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 21800000
   Booting using the fdt blob at 0x21800000
   Loading Kernel Image ... OK
OK
uboot time: 6087588 us.
Using machid 0xf81 from environment
faild to get aml_reserved_end address
the default relocate ramdisk and fdt address-relocate_addr: 0x20000000
   Loading Ramdisk to 1fce1000, end 1fffffd9 ... OK
   Loading Device Tree to 1fcdb000, end 1fce0a4a ... OK
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND
libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND

Starting kernel ...

Loading, please wait...
starting version 232
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=18ef9117-8b19-4fa0-a35b-aa6023dd1e3d does not exist.  Dropping to a shell!
(initramfs)

PS. This is using the image from the C1 download page, DietPi_OdroidC1-ARMv7-Stretch.7z.

jcw · 2019-05-12T10:49:36Z

Aha, a few comments up: "no eMMC support" - that's probably it. This is unfortunate, for server use.

MichaIng · 2019-05-12T11:33:41Z

@jcw

"no eMMC support" - that's probably it. This is unfortunate, for server use.

Jep that is one limitation of the mainline kernel that allows Debian Stretch, sadly.

@Fourdee
Hah, ARMbian ships a new image with Linux 5.0 and no hint about missing GPU support anymore: https://www.armbian.com/odroid-c1/
Might it be possible the mainline kernel added/widened support for this chip?

Digging: https://kernelnewbies.org/Linux_5.0#ARM

Many new SBCs, platforms, Cortex-A5 and two Mali entries in the graphics section. I can't find it explicitly but who knows which little quirk made video break before.

I know you invested much time for the current C1 Stretch image, so don't take this as a request, but as information. I just wanted to verify the "no-eMMC" and found it by chance 😄.

Fun fact: https://en.wikipedia.org/wiki/Year_2038_problem
But Linux tries to solve it: https://lwn.net/Articles/776435/
Reminds be about to millennium issue that time 😄.

Linux 5.1 comes with NanoPi T4+M4 + ROCK Pi 4 support btw, although the question is if all features are fully supported. At least on ROCK Pi forum I read about this a longer time, so their devs seem to be heavy involved. This should make image creation for these boards much easier.

jcw · 2019-05-12T12:48:03Z

Could this be of use? - https://forum.odroid.com/viewtopic.php?f=111&p=255093

MichaIng · 2019-05-12T13:40:23Z

@jcw
Thanks for posting this as another source to hopefully get some feedback about C1 feature support of Linux 5.0.

itouch5000 · 2019-05-18T17:23:05Z

I am currently running Armbian_5.84_Odroidc1_Debian_stretch_next_5.0.12.img as tiny backup server. And it's working great even reboots are possible with this new 5.0.12 kernel.
As stated usb hotplug and HDMI output is not working. I have not tested eMMC support because of missing hardware.

MichaIng · 2019-05-18T17:44:39Z

@itouch5000
Many thanks for reporting. Jep we should update our image to use this kernel as well.
But it is also possible to update it via APT package, right?

Okay, so still no HDMI. "serial console only" somehow implies this. "eMMC not supported" stated by ARMbian, so this will definitely not work: https://www.armbian.com/odroid-c1/

itouch5000 · 2019-05-18T17:45:48Z

@MichaIng
yes, apt update and upgrade works

MichaIng · 2019-05-18T17:51:13Z

@itouch5000
Also to upgrade the kernel version, right? I.e. dpkg -l contains some linux-image-* like package?
However new DietPi image still makes sense to avoid issues on first boot, especially since apt-get dist-upgrade (most likely required for Linux upgrade) is not called automatically.

itouch5000 · 2019-05-18T17:56:46Z

@MichaIng
yes I think so:

ii    linux-image-next-odroidc1    5.84    armhf    Linux kernel, version 5.0.12-odroidc1

full output: https://pastebin.com/raw/uE7hNVDG

MichaIng · 2019-05-18T18:00:25Z

@itouch5000
Perfect thanks.

itouch5000 · 2019-05-20T19:03:38Z

@MichaIng
I recently noticed that usb and even usb hotplug is working under certain conditions:
Boot with a 8GB usb stick -> device not recognised
Boot with a 3TB hdd -> device not recognised
Boot with a 2GB usb stick -> device recognised
(usb stick with a GUID partiton table and formatted with libreelec installer)
Boot with this 2GB usb stick and the 8GB usb stick and/or the 3TB hdd -> all devices are recognised

Very odd. I'm not shure if that helps.

MichaIng · 2019-06-24T21:37:21Z

Okay I mark this as closed. Issues should be reported as separate issues from now on.

MichaIng added Help wanted 🆘 Odroid C1 Stretch Image request 💾 labels Feb 17, 2019

MichaIng pinned this issue Feb 17, 2019

This was referenced Feb 17, 2019

General | Drop Jessie support #2332

Closed

Images | Update all images #2026

Closed

DietPi-Software | Emby server: Install fails on ARM+Jessie due to too old libc6 #2521

Closed

MichaIng mentioned this issue Apr 29, 2019

Beta v6.23.0 #2744

Merged

Fourdee closed this as completed May 2, 2019

Fourdee added this to the v6.23 milestone May 2, 2019

Fourdee removed the Help wanted 🆘 label May 2, 2019

Fourdee pushed a commit that referenced this issue May 2, 2019

C1: #2561

9522745

Fourdee reopened this May 2, 2019

MichaIng added Solution available 🥂 Definite solution has been done Testing/testers required 🔽 labels May 6, 2019

This was referenced May 6, 2019

Open Beta v6.23 | Please help testing and hardening the upcoming release #2750

Closed

v6.23 #2784

Merged

MichaIng modified the milestones: v6.23, v6.24 May 12, 2019

MichaIng changed the title ~~Odroid C1 | Stretch image~~ Image | Odroid C1 Stretch May 12, 2019

MichaIng modified the milestones: v6.24, v6.25 May 15, 2019

MichaIng assigned Fourdee May 18, 2019

MichaIng unpinned this issue Jun 1, 2019

MichaIng closed this as completed Jun 24, 2019

MichaIng removed the Testing/testers required 🔽 label Jun 24, 2019

MichaIng mentioned this issue Jun 24, 2019

Open Beta v6.25 | Please help testing and hardening the upcoming release #2936

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Image | Odroid C1 Stretch #2561

Image | Odroid C1 Stretch #2561

MichaIng commented Feb 17, 2019 •

edited

Loading

Fourdee commented May 2, 2019 •

edited

Loading

Fourdee commented May 2, 2019 •

edited

Loading

Fourdee commented May 2, 2019

MichaIng commented May 2, 2019

MichaIng commented May 2, 2019 •

edited

Loading

jcw commented May 4, 2019

MichaIng commented May 4, 2019 •

edited

Loading

jcw commented May 12, 2019 •

edited

Loading

jcw commented May 12, 2019

MichaIng commented May 12, 2019 •

edited

Loading

jcw commented May 12, 2019

MichaIng commented May 12, 2019

itouch5000 commented May 18, 2019 •

edited

Loading

MichaIng commented May 18, 2019

itouch5000 commented May 18, 2019

MichaIng commented May 18, 2019

itouch5000 commented May 18, 2019 •

edited

Loading

MichaIng commented May 18, 2019

itouch5000 commented May 20, 2019 •

edited

Loading

MichaIng commented Jun 24, 2019

Image | Odroid C1 Stretch #2561

Image | Odroid C1 Stretch #2561

Comments

MichaIng commented Feb 17, 2019 • edited Loading

EDIT: Although Sparky SBC runs with Stretch fine as well with kernel 3.10

Fourdee commented May 2, 2019 • edited Loading

Fourdee commented May 2, 2019 • edited Loading

Fourdee commented May 2, 2019

MichaIng commented May 2, 2019

MichaIng commented May 2, 2019 • edited Loading

jcw commented May 4, 2019

MichaIng commented May 4, 2019 • edited Loading

To be fair about the above:

jcw commented May 12, 2019 • edited Loading

jcw commented May 12, 2019

MichaIng commented May 12, 2019 • edited Loading

jcw commented May 12, 2019

MichaIng commented May 12, 2019

itouch5000 commented May 18, 2019 • edited Loading

MichaIng commented May 18, 2019

itouch5000 commented May 18, 2019

MichaIng commented May 18, 2019

itouch5000 commented May 18, 2019 • edited Loading

MichaIng commented May 18, 2019

itouch5000 commented May 20, 2019 • edited Loading

MichaIng commented Jun 24, 2019

MichaIng commented Feb 17, 2019 •

edited

Loading

EDIT: Although Sparky SBC runs with Stretch fine as well with kernel `3.10`

Fourdee commented May 2, 2019 •

edited

Loading

Fourdee commented May 2, 2019 •

edited

Loading

MichaIng commented May 2, 2019 •

edited

Loading

MichaIng commented May 4, 2019 •

edited

Loading

jcw commented May 12, 2019 •

edited

Loading

MichaIng commented May 12, 2019 •

edited

Loading

itouch5000 commented May 18, 2019 •

edited

Loading

itouch5000 commented May 18, 2019 •

edited

Loading

itouch5000 commented May 20, 2019 •

edited

Loading