odroid c2 owner here

odroid c2 owner here

[David Marceau]

Hi there,

I would just like to make my odroid c2(amlogic S905) available for any
tests of new kernel images.  I currently have archlinux/lxdm installed
on one emmc and the other emmc has the stock android image that came
with it.

I recently bought a ZoomTak Uplus(amlogic S912), but documentation to
flash it in a manner similar to the odroid c2 is sparse/scattered.  It
has the stock android 6.0 kernel on it.  If there are any diagnostics
tools or tests you would like to make from within the existing android,
I would volunteer myself to those also.

Cheers,
David Marceau

ZoomTak UPlus flashing (was: odroid c2 owner here)

[Andreas Färber]

Hi David,

Am 27.04.2017 um 03:49 schrieb David Marceau:
> I recently bought a ZoomTak Uplus(amlogic S912), but documentation to
> flash it in a manner similar to the odroid c2 is sparse/scattered.  It
> has the stock android 6.0 kernel on it.  If there are any diagnostics
> tools or tests you would like to make from within the existing android,
> I would volunteer myself to those also.

Your help in making meson-tools [1] work with S912 would be appreciated!

IIRC S905X and S912 were lacking the initial @AML header at offset 16
that my tools currently expect.

You should backup (via dd from Android) the first ~4 MB of your eMMC for
non-destructive offline analysis.

First steps would then be to tweak unamlbootsig code to deal with
aml_encrypt_gxl [2] format input, then modify amlbootsig code to
correctly generate the @AML headers, matching your original input.
README.md has some hints on how to use hexdump and diff tools for this.

Next step would then be to split off fip.bin at the appropriate offset
of unamlbootsig output (via dd), modify fip.bin via fip_create or
(patched) fiptool, write it back into unamlbootsig's output (using dd)
and run amlbootsig on it. If you're really lucky, writing that onto an
SD card and powering up the box with it would give you serial output you
can distinguish from the eMMC's (to make sure you're actually booting
from SD). If you're unlucky, eMMC comes first in the boot order, so that
shorting eMMC pins or zero'ing/overwriting the eMMC would be the only
ways to test new bootloaders, which might brick your board, and at least
meson-tools v0.1 doesn't include any recovery tools.


Note that currently there is no mainline U-Boot for S912. If you wanted
to hack on that based on existing S905 code, you could instead try to
chain-load your U-Boot from your box's U-Boot by loading it from a FAT
partition on SD/USB to some memory location (at least on my R-Box Pro
tftp boot wasn't working) and then running it via "go" command.

But then again you should just start with enabling the mainline kernel
for your box and loading it from a FAT partition on SD/USB or via TFTP.
Once Linux has a .dts, it is much easier to import that into U-Boot.

Cheers,
Andreas

[1] https://github.com/afaerber/meson-tools
[2] https://github.com/khadas/u-boot/tree/ubuntu/fip

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

ZoomTak UPlus flashing

[David Marceau]

Odroid c2 device advantages:
============================
1)necessary accessories were reasonably inexpensive
#1)emmc 5.0 to microsd reader/writer which plugs into
#2)USB 3.0 microsd reader/writer

2)archlinux wiki recipe to write the archlinux image to that emmc module
was straightforward and succeeded the very first time

3)network/terminal/lxde desktop all needed a bit of tweaking to get up
with archlinux, but the result was adequate.

Odroid c2 device drawbacks with archlinux:
==========================================
-the kernel seems to be stuck at 3.14 and the recipes to change that are
clearly described as risky.  The time and investment to build the kernel
is significant.  Unless it is already built and ready to install easily,
the desire to install is very low if we have a low-confidence level of
installing a working bootable and improved kernel.
-android5.0 youtube didn't work properly even with the android updates
and the odroid utility image updates.  It was hit and miss and media
playing would freeze 5s to 10s in a youtube video.
-full throughput of the the graphics chipset within archlinux never seem
to be achieved when compared to the android 5.0 within certain
applications like chrome and tvplus.


RECOMMENDATIONS
===============

To encourage more archlinux/amlogic s905 odroid c2 users to do more
newer kernel testing, here is what I would recommend:
1.1)we need a quick test and recover cycle
1.1.0)we need download links to the latest amlogic images to test
against for which the amlogic linux user group needs bug reports for.

2)we need the steps to flash the particular boot image and kernel image
and other respective partitions on the appropriate devices(emmc or microsd)

3)we need links to the accessories we can buy to make that quick test
and recover cycle happen.
ODROID's C2 ACCESSORIES STORE is wonderful, I have what I need to wipe
and write the emmc5.0 storage with a new image.
THE ZOOMTAK UPLUS box on the other hand with the S912 chipset uses a
different emmc5.0 layout(FBGA169?) which means I need to find a
different reader/writer for it.  I am still uncertain which
reader/writer to get. I have not found the documentation to read/write
the image for the board in the ZoomTAK uplus.  What little info I did
find about usb fbga169 readers was they were significantly more
expensive discouraging me from the idea of backing up the current image
and reflashing it with something else.  I believe I can pull it out in
the same way the odroid c2's emmc modules can be pulled out, but I have
yet to try.  I haven't found much out there about zoomtak uplus
teardowns and my mother-in-law's constantly watching her Chinese soaps
so I have to minimize my tinkering with the inside of the box :)
Does anyone have a good url where we can buy a reasonably priced usb
emmc reader/writer for zoomtak uplus emmc modules?
I bought 2 emmc modules for the odroid c2, one for android and the other
for archlinux.  It worked out well.  The android emmc is for the
mother-in-law during the day.  The archlinux emmc is for me when I am
trying different thing on my spare time.  I aim to do something similar
with the zoomtak box, but I need to do some research first before
actually tearing up the box and risking breaking things in the process.

4)faster recover procedures to allow to get on with daily usage after
testing/reporting bugs on newer kernels will encourage more testers.
For archlinux, it's very easy to update the packages of the os itself,
but not to install and test the newer kernels.  If it crashes and can't
boot up, that implies a reflash of the entire emmc storage or at least
that's the quick answer.  The longer more precise answer pointing to the
older existing kernel from within the boot on arm-based boards is
trickier than on intel-boards.  On intel-boards we can backtrack by
simply reverting back to an older kernel by deleting the questionable
kernel and refreshing the boot table using a grub-update or
mkgrubinitcfg from a usb bootable thumb drive. Honestly my familiarity
to do something on arm-based boards with uboot is very little(NONE) and
tend to avoid and focus on running applications rather than kernels.
I've read about tools that can help on radxa boards(NON-AMLOGIC) but
the procedures to use them particular for radxa boards were unclear
which left me to sticking with stock radxa kernel.  I'm currently
feeling encouraged to use the latest kernel from amlogic, but I am
feeling incapable of going from the current archlinux stable kernel to
the amlogic latest kernel and then back to the archlinux stable kernel.
Anything out to alleviate the painpoint to save time to recover to the
older kernel with certainly help with great certainty for others to join
the testing knowing full well no matter what they test won't brick their
device to take them a great amount of time to recover from the tested
kernel that bricks the device.

You are probably aware of this already:  having the stock android image
for the zoomtak uplus image is that there usually is a special directory
in the android image that has the android linux kernel build config
file...which is used to build the custom zoomtak uplus kernel in the
first place.

There were rumors floating that 32-bit amlogic linux images could run
without changes on the odroid c2, is that true?  If that is the case, is
it possible that an odroid c2 64-bit archlinux image could run without
changes on the zoomtak uplus box?  Are the amlogic chipset boards
somewhat compatible boards or are they entirely incompatible?

Thank you for listening.


On 05/01/2017 07:52 AM, Andreas F?rber wrote:
> Hi David,
> 
> Am 27.04.2017 um 03:49 schrieb David Marceau:
>> I recently bought a ZoomTak Uplus(amlogic S912), but documentation to
>> flash it in a manner similar to the odroid c2 is sparse/scattered.  It
>> has the stock android 6.0 kernel on it.  If there are any diagnostics
>> tools or tests you would like to make from within the existing android,
>> I would volunteer myself to those also.
> 
> Your help in making meson-tools [1] work with S912 would be appreciated!
> 
> IIRC S905X and S912 were lacking the initial @AML header at offset 16
> that my tools currently expect.
> 
> You should backup (via dd from Android) the first ~4 MB of your eMMC for
> non-destructive offline analysis.
> 
> First steps would then be to tweak unamlbootsig code to deal with
> aml_encrypt_gxl [2] format input, then modify amlbootsig code to
> correctly generate the @AML headers, matching your original input.
> README.md has some hints on how to use hexdump and diff tools for this.
> 
> Next step would then be to split off fip.bin at the appropriate offset
> of unamlbootsig output (via dd), modify fip.bin via fip_create or
> (patched) fiptool, write it back into unamlbootsig's output (using dd)
> and run amlbootsig on it. If you're really lucky, writing that onto an
> SD card and powering up the box with it would give you serial output you
> can distinguish from the eMMC's (to make sure you're actually booting
> from SD). If you're unlucky, eMMC comes first in the boot order, so that
> shorting eMMC pins or zero'ing/overwriting the eMMC would be the only
> ways to test new bootloaders, which might brick your board, and at least
> meson-tools v0.1 doesn't include any recovery tools.
> 
> 
> Note that currently there is no mainline U-Boot for S912. If you wanted
> to hack on that based on existing S905 code, you could instead try to
> chain-load your U-Boot from your box's U-Boot by loading it from a FAT
> partition on SD/USB to some memory location (at least on my R-Box Pro
> tftp boot wasn't working) and then running it via "go" command.
> 
> But then again you should just start with enabling the mainline kernel
> for your box and loading it from a FAT partition on SD/USB or via TFTP.
> Once Linux has a .dts, it is much easier to import that into U-Boot.
> 
> Cheers,
> Andreas
> 
> [1] https://github.com/afaerber/meson-tools
> [2] https://github.com/khadas/u-boot/tree/ubuntu/fip
> 

ZoomTak UPlus flashing

[Andreas Färber]

Hey David,

Am 03.05.2017 um 03:39 schrieb David Marceau:
> Odroid c2 device advantages:
[...]
> RECOMMENDATIONS
> ===============
> 
> To encourage more archlinux/amlogic s905 odroid c2 users to do more
> newer kernel testing, here is what I would recommend:
[snip]

SUSE is clearly the wrong addressee for complaints about Arch Linux!!!

My JeOS-odroidc2 openSUSE Tumbleweed images do use GRUB, making it very
easy to switch between multiple kernels; the only part requiring manual
updates for us is U-Boot. This is all Open Source and mainline (and we
published a paper "UEFI on top of U-Boot" at Embedded World Conference
2017 - copy available on request). If your Linux distro doesn't use the
existing bootloader mechanisms, you need to contact them instead.

https://en.opensuse.org/HCL:OdroidC2

You specifically asked about flashing your S912 TV box, which my
response (and the subject) was about. If you have other topics, don't
address them to random people that happened to reply to unrelated
questions, and pose your questions clearly, without top-posting.
Remember, this mailing list is about the mainline Linux kernel, not
about random "amlogic images", whatever exactly you mean by that.
Providing pre-built images is what distros do, not the kernel community.

You also seem to have some misconceptions about eMMC: It will be a chip
soldered onto the main PCB of your TV box. Ball Grid Array (BGA) means
that the contacts are on the bottom of your chip, so you have no
realistic chance to find a "reader/writer" for it like there is for the
Odroid-C2. Had you taken any look inside your box you would've noticed
that... Which is why I was cautioning about making changes to flash and
instead suggesting to investigate things in a safe backup made from your
Android, on another machine.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)

ZoomTak UPlus flashing

[David Marceau]

On 05/03/2017 07:02 AM, Andreas F?rber wrote:
> SUSE is clearly the wrong addressee for complaints about Arch Linux!!!

Thank you for clarifying and I apologize for the noise.