Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Image | Odroid C1 Stretch #2561

Closed
MichaIng opened this issue Feb 17, 2019 · 20 comments
Closed

Image | Odroid C1 Stretch #2561

MichaIng opened this issue Feb 17, 2019 · 20 comments
Assignees
Milestone

Comments

@MichaIng
Copy link
Owner

MichaIng commented Feb 17, 2019

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

Related issues:

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.

@Fourdee
Copy link
Collaborator

Fourdee commented May 2, 2019

@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?

image

@Fourdee Fourdee closed this as completed May 2, 2019
@Fourdee Fourdee added this to the v6.23 milestone May 2, 2019
Fourdee pushed a commit that referenced this issue May 2, 2019
@Fourdee
Copy link
Collaborator

Fourdee commented May 2, 2019

@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 Fourdee reopened this May 2, 2019
@Fourdee
Copy link
Collaborator

Fourdee commented May 2, 2019

@MichaIng

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

@MichaIng
Copy link
Owner Author

MichaIng commented May 2, 2019

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
Copy link
Owner Author

MichaIng commented May 2, 2019

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
Copy link

jcw commented May 4, 2019

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
Copy link
Owner Author

MichaIng commented May 4, 2019

@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
Copy link

jcw commented May 12, 2019

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
Copy link

jcw commented May 12, 2019

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

@MichaIng
Copy link
Owner Author

MichaIng commented May 12, 2019

@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
Copy link

jcw commented May 12, 2019

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

@MichaIng
Copy link
Owner Author

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

@MichaIng MichaIng modified the milestones: v6.23, v6.24 May 12, 2019
@MichaIng MichaIng changed the title Odroid C1 | Stretch image Image | Odroid C1 Stretch May 12, 2019
@MichaIng MichaIng modified the milestones: v6.24, v6.25 May 15, 2019
@itouch5000
Copy link

itouch5000 commented May 18, 2019

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
Copy link
Owner Author

@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
Copy link

@MichaIng
yes, apt update and upgrade works

@MichaIng
Copy link
Owner Author

@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
Copy link

itouch5000 commented May 18, 2019

@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
Copy link
Owner Author

@itouch5000
Perfect thanks.

@itouch5000
Copy link

itouch5000 commented May 20, 2019

@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 MichaIng unpinned this issue Jun 1, 2019
@MichaIng
Copy link
Owner Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants