On Thu, 11 Apr 2013 20:41:39 +0100
luke.leighton luke.leigh...@gmail.com wrote:
http://lkcl.net/reports/odroid-u2.html
this is an install report (successful one!) with full bootstrap
instructions on how to get from android to debian GNU/Linux (armhf
variant) on an ODroid-U2 device. it's got quirks (the hardware) but
the sheer tiny size for something that has 3 USBs and Ethernet is
just... i couldn't resist.
Software Freedom Caveats:
a) i'm deeply unhappy to have learned that Hardkernel have enabled DRM
in the bootloader, and require that, if you want to modify u-boot, you
must send them the u-boot image and *they* will sign it with their
private key. this is deeply unimpressive but at least they will
actually sign it... unlike e.g. the fucked-up arrangement with UEFI
boot and microsoft and the linux foundation. try asking microsoft
excuse me could you please sign my linux kernel i built and see how
far that gets.
regardless of that screw-up-of-an-arrangement, i found that the
pre-installed pre-built u-boot did not need modifying so i did not
need to contact hardkernel.com: the default parameters of the default
pre-built u-boot will look for a kernel on the NAND partition first,
followed by looking for one on the SD Card partition. personally i
feel this should be the other way round, but hey, it worked.
I have an older ODROID-X board. And if I remember correctly (I played
with it more than half a year ago), it had u-boot sources available
which could be compiled and used.
It is sad to know that Samsung is tightening security and restricting
users' freedom. But it's their choice, and they may be a bit paranoid
after the /dev/exynos-mem incident and other security breaches.
b) the HDMI framebuffer appears to need a proprietary library (as
usual) to compile up the X11 driver. as this qualifies as a System
Library and thus is covered by the GPL Exceptions Clauses it's kinda
ok, only not really if you know what i mean.
The only proprietary bit is the libMali.so library. And it is not even
loaded into Xorg server process. It is only needed for GLES/EGL
applications and is used on the client side.
Also unless you have a desperate need for 3D hardware acceleration, I
would advise against using xf86-video-mali ddx driver. It is 2D
performance challenged because of some EXA abuse and the traditional
x11 linux desktop runs slower than necessary. Admittedly the fast
Cortex-A9 processor can make this performance issue harder to notice
and you should not get an obvious slideshow in a majority of
applications. Especially with low 1280x720 screen resolution.
You may also try https://github.com/ssvb/xf86-video-sunxifb
Despite the poor choice of name, it should work with the ump based
mali400 blobs also on the platforms other than sunxi.
i've spoken to libv on #lima and he's got an odroid-x2 which he's just
started playing with, and will be getting the mali wrapper library
back up-and-running in order to start tackling xorg.
Sounds great. Please keep us updated on your progress.
--
Best regards,
Siarhei Siamashka
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130412035220.3f29cee5@i7
