Operating-system: Running Odroid-C2

Created on 27 Jul 2018  路  36Comments  路  Source: home-assistant/operating-system

Working on getting the Odroid-C2 working. (Will fork and post a pull request once I get everything working and tidied-up)

Seems I've gotten most of the "difficult" items worked out, but the docker instances seem not to play nice with the network interfaces? I can't see HomeAssistant on :8123, and I get:

hassio > ha info
The HTTP request failed with the error: Get http://hassio/homeassistant/info: dial tcp 172.30.32.2:80: getsockopt: connection refused

When I try to run any hassio commands.
Network is up (can ping into/out of and ssh into busybox).

Any thoughts?

boarodroid

All 36 comments

Any update on this?

The dev branch is revving so much and touching so many things that I'm going to wait for some of those changes to hit master (or slowing down a good bit) before trying to merge them into a fork.

Up here: https://github.com/rbray89/hassos Gonna try to track the dev branch.

Still haven't determined why it is failing. All the services return OK status.

Ah, seems the docker image is missing the landingpage tag for aarch64:
https://hub.docker.com/r/homeassistant/aarch64-homeassistant/tags/

see:
home-assistant/hassio-build#105

Once I swapped out the HomeAssistant Docker Repository with something with the landingpage tag, it works! Now just have to wait fro fix in hassio-build.

If you want to try it out yourself, change HOMEASSISTANT_REPOSITORY
https://github.com/rbray89/hassos/blob/0458041d3ecff82284d1def6887f0cac8f72e82b/buildroot-external/configs/odroidc2_defconfig#L86
to HOMEASSISTANT_REPOSITORY=homeassistant/raspberrypi3-64-homeassistant

Nice work!

see: home-assistant/hassio-build#106

Awesome! Do you think the configuration would also work for the odroid xu4?

No, it won't work at all for the XU4 unfortunately. They use completely different boot loader binaries and device trees. The XU4 has similar challenges as the C2 in that it requires MBR partitioning (can't use GPT)(see edit) and uses a special SPL/SBL process. Luckily Hardkernel documents everything really well in their device wiki:
https://wiki.odroid.com/odroid-xu4/software/partition_table
https://wiki.odroid.com/odroid-xu4/software/building_u-boot_mainline

Most of the changes I've made though should apply and make the process to get other hardkernel boards working much easier though.

EDIT:
While the Odroid-C2 is limited to MBR partitioning, the Odroid-XU4 seems like it should be able to use GPT partitioning.
EDIT EDIT:
According to Hardkernel forums and documentation, GPT is likely not usable for boot on the XU4. Looks like they write their SBL1 to sector 1, and their SBL2 to Sector 31, which is still inside the GPT Partition Entry Array.

That is not correct. Any device can use GPT with our build system. We support now with 2.1 also SPL bootloading with GPT

@pvizeli The GPT issue isn't a problem with Home Assistant. It is an limitation with the Odroid-C2. It doesn't use a traditional Boot chain (LBA Ptrs to boot code), and enters through sector 4, which is within the GPT partition table entries. From what I understand, this is the same on the XU4, but I could be wrong about that.

EDIT: Seems the XU4 does NOT have the same issue. They boot from sector 31: Looks like they write their SBL1 to sector 1, and their SBL2 to Sector 31 (which is still inside the GPT Partition Entry Array) https://wiki.odroid.com/odroid-xu4/software/partition_table

For the Odroid-C2 boot: https://wiki.odroid.com/odroid-c2/software/partition_table and https://wiki.odroid.com/odroid-c2/software/building_u-boot (sd_fusing.sh)

Hmmm... After looking at Hardkernel's documentation more (and reading a bunch on the hardkernel forums) It seems the XU4 may have the same issue with occupying the same space as the GPT header, so it will also likely be limited to MBR as well.

We can have GPT header on every place of SD card but we need own the first 1024 bytes of SD card. Please make a PR if I should look into odroid c2

@pvizeli unfortunately the way the odroid C2 board is booting is by loading hardcoded sectors and booting to them. On the Odroid C2 we're booting from 0x0400 (sector 2), but a bunch of data is occupying 0x200-0x400 (Sector 2) where the GPT header would normally live. The only way to use GPT would be to reverse engineer the bl1.bin.hardkernel binary and relocate things. I've got everything working with MBR on the odroid. It does require some script changes and replacing UUIDs with other disk labels.

Just tried the pre-release of the Odroid C2 image. Unfortunately doesn't boot with the eMMC module. MicroSD boots.

@iuro Yeah, I recently purchased an eMMC module. Will be working on getting that booting this weekend.

Great, going to try it out right away!

Just booted from eMMC. Working without problems so far. Initial impressions is that it is a lot faster than the RPI.

Note that it isn't an "official" image, and will not get OTA updates. We're working on getting the odroid devices into mainline though.

Thx for the headsup. I will wait for the final release before I use it in production.

Why would OTA updates not work? I just updated to 0.76.1 without issues.

@iuro Base OS updates won't happen due to me using a developer RAUC key. HASS will still update as it is just pulling down a new docker container.

I am currently giving the Odroid image a try and ran into the issue that it seems to have no internet access (see: https://community.home-assistant.io/t/no-cloud-polling-sensor-data-on-hassos-for-odroid-c2-beta/). Is that something to mention here or create a separate issue or something? (want to contribute my findings, but not sure what the best way it so do so)

@aetjansen It'd be best to post a separate issue.

I'm very excited about the progress being made here. Thank you all.

What are the chances of getting a XU4 to boot with eMMC?

@MartyTremblay It's already in the dev build https://github.com/home-assistant/hassos/releases. I'm running it on an eMMC with an XU4 right now.

Super, I'll give it a go!

I'm still getting a solid blue LED and thought I'd share my steps to test: I did an eMMC recovery using Odroid's image first on the SD, booted the XU4 with it. Rebooted using the recovered eMMC successfully, reflashed the eMMC with the dev build image, lastly rebooted with a solid blue LED.

I think I'm missing something obvious here

I'm still getting a solid blue LED and thought I'd share my steps to test: I did an eMMC recovery using Odroid's image first on the SD, booted the XU4 with it. Rebooted using the recovered eMMC

I'm getting the exact same problem with the dev version. Not possible to boot with eMMC.

@MartyTremblay @iuro See here for the XU4 eMMC: https://github.com/home-assistant/hassos/blob/dev/Documentation/boards/odroid-xu4.md#emmc

Basically, the eMMC is setup very differently from all other boards. It has a "hidden" boot sector that needs to be written/overwritten. If it already had an image from Hardkernel, it will have an old uBoot that will likely not boot the device. The instructions in the link above outline the steps needed to properly prepare the boot sector to boot HassOS off eMMC.

I followed the eMMC instructions link from @rbray89 . I was getting an "Operation not permitted" error when using dd on /dev/mmcblk0boot0. A bit of googling told me that write access to boot partitions are often disabled. To enable dd to write to it, I had to do the following:

echo 0 > /sys/block/mmcblk0boot0/force_ro
dd if=/dev/mmcblk0 of=/dev/mmcblk0boot0 bs=512 skip=63 seek=62 count=1440

to re-enable read-only access:

echo 1 > /sys/block/mmcblk0boot0/force_ro

Thanks everyone for your help!

Was this page helpful?
0 / 5 - 0 ratings