CuBox-i from SolidRun

[phenigma]

  Time...  it's really all I need more of. 

J.

[Marie.O]

Change your sleeping pattern: http://en.wikipedia.org/wiki/Polyphasic_sleep

Et Voila! way more time

[phenigma]

Change your sleeping pattern: http://en.wikipedia.org/wiki/Polyphasic_sleep

Et Voila! way more time

/hmm.  How did I know you were going to hit me with that!   

[Marie.O]

Probably because you know, problem fixing is in my genes

[pigdog]

My supervisor didn't buy the concept that during a 12 hour shift that a 2 hour nap would actually make me more productive.

(I know it has nothing to do with polyphasic sleep but one has to try to extend the theory.  )

Cheers.

[Marie.O]

In a 12hour shift you would only sleep 60 minutes

[pigdog]

Getting paid for two hours of sleep seems more amicable.

If only we were unionized.

[theteju]

I subscribe this thread, Looking forward to see updates. The configurations looks pretty awesome.

[pigdog]

Hi,

I'm at a point where I figure the way to boot the Cubox is to create a pxelinux menu in-order to chose between Pluto x86 default and Cubox ARM.

If anyone has a different approach, please advise.

I am going to look at TBZ shell to see if I'm missing something as well.

I'm up to my knees but not drowning yet!

Cheers.

[pigdog]

Hi,

Oooowww!

I shouldn't have looked at TBZ.  My HACKABILLY approach wasn't the way to go.

I always had a concern re: CreateDiskless.  Oh well, up to my waist now!

Cheers.

[phenigma]

Diskless_Create will need to be altered/enhanced to build an armv7 trusty image.  The armv7 trusty packages first have to be in the repo, I've been intending to put them in but I have not gotten around to it yet.

U-Boot will have to be compiled specifically for our use as there are patches required for passing kernel boot parameters.

A default pxe-boot kernel/config will need to be placed in the /tftboot directory on the core.

A kernel for the cu-box (ideally in a packaged form) will also need to be available for the diskless image.

J.

[pigdog]

Hi,

I just cut and pasted part of my notes as what I had kinda done to date.

Tftpboot and other junk not included.

This is based on the installation of the 12.04 variant of LMCE.

My notes (so far) for investigation of Cubox ARM support on LMCE.


Log in as root.

apt-get update
apt-get upgrade
apt-get dist-upgrade


Preparing to build from sources.


We need to have gcc-arm-linux-gnueabi installed.

apt-get install gcc-arm-linux-gnueabi


We also need to have u-boot-tools installed (for mkimage).

apt-get install u-boot-tools


Plus, we need to have lzop installed (for "make zImage").

apt-get install lzop


Finally, we need git installed

apt-get install git


If logged in as root when we check our directory tree...

ls

... we have 'Desktop' and 'new-installer' as directories.



Step 1. - u-boot for cu-box with pxe patches

To build the bootloader...

git clone https://github.com/SolidRun/u-boot-imx6.git


Now when we check our directory tree...

ls

... we now have 'Desktop', 'new-installer' and 'u-boot-imx6' as directories.


Then,

cd u-boot-imx6


Set up our environment variables.

export ARCH=arm
export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-


Then we build the bootloader.

make mx6_cubox-i_config

make


A successful build will create u-boot-* files (including u-boot-img) plus a SPL file.

The SPL file is used for the actual machine detection and initialization. 
This file must be flashed on offset 1KByte of the boot micro SD.

The  u-boot.img is the second stage bootloader.
It can be flashed at offset 42KByte from the start of the boot micro SD. 
Or it can alternatively be put as-is on the first partition of the micro SD.


The general bootloader flashing procedure is...

dd if=SPL of=/dev/sdX bs=1K seek=1

...where /dev/sdX is the location of your microSD card.

     
For flashing u-boot.img as raw to the micro SD -

dd if=u-boot.img of=/dev/sdX bs=1K seek=42


WARNING: Make sure you are flashing u-boot to the proper target device.  Putting the wrong device identifier could wipe your hard drive.



You can boot from the microSD at this point without booting a Linux system (only the u-boot).


Step 2. - Kernel build (with appropriate patches)

Compiling the kernel.


Change directory to /u-boot-imx6/arch/arm in order to edit the file config.mk

modify the line

CROSS_COMPILE ?= arm-linux-

to

CROSS_COMPILE ?= arm-linux-gnueabi-


cd back to the 'Desktop', 'new-installer' and 'u-boot-imx6' directories


The 3.10 LTS kernel is the main kernel to be used for end users and general availability.

It is based on Linaro kernel 3.10 LTS, i.MX6 Freescale patches and patches from Russell King, Jon Nettleton and various other developers.


The kernel can be built using the following commands.

git clone https://github.com/SolidRun/linux-linaro-stable-mx6.git


Upon completion when we now check our directory tree...

ls

... we now have 'Desktop', 'new-installer', 'u-boot-imx6' and 'linux-linaro-stable-mx6' as directories.


Then,
 
cd linux-linaro-stable-mx6
 
Set up our environment variables.

export ARCH=arm
export CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-

make imx_v7_cbi_hb_defconfig

make zImage imx6q-cubox-i.dtb imx6dl-cubox-i.dtb imx6dl-hummingboard.dtb
 
make modules


The generated files are -

 arch/arm/boot/zImage
 arch/arm/boot/dts/imx6q-cubox-i.dtb
 arch/arm/boot/dts/imx6dl-cubox-i.dtb
 arch/arm/boot/dts/imx6dl-hummingboard.dtb


The first file is the actual kernel. The other three are device tree files loaded by the boot loader.

So from what I looked at in DisklessCreate - yeah this approach was 'different'.

Don't know if I can use "trusty image" because of the patches.

I was going to create a menuconfig for pxelinux.cfg and chose the package I wanted to install something like...

DISPLAY message
DEFAULT cubox blah blah
PROMPT 1
TIMEOUT 0
LABEL cubox blah blah
   kernel /where the heck my vmlinux is
   append root=/dev/nfs boot=casper netboot=nfs nfsroot=IP.OF.YOUR.SERVER:/srv/tftpboot/cubox blah blah initrd= cubox/blah blah/initrd.lz --

kinda thing.  You know. HACKABILLY.

I also need those .dtb files to support the different variants of the cubox-hummimgboard I believe.  (I don't know for sure.  Suppose to automatically load the proper .dtb depending upon hardware).

Anyway I'll poke around at this end.

Cheers.

[phenigma]

yikes.  ok.  there's lots there to look at. 

• u-boot, once setup correctly, will pick the proper default kernel from the tftpboot directory.
• what distro of linux are you running? any arm version will require a proper build of lmce.(ubuntu 1404 armv7 is built but not pushed to the lmce repos)
• If I can get specific instructions wrt the kernel then I can create a default kernel image for the device. (You may have provided these but there is a lot there to sort through. 
• u-boot needs some patches which are written specific to the rpi version, I will need to alter them for the cubox (or more generically for many devices if I can, but I've only ever seen one so far ;-|  )  Can you provide specific references to the board and version to use with mainline u-boot?
• the device tree files are becoming the standard method of differentiating hardware for non-i386/arm64 based systems.  u-boot can handle these for the most part but, again, I may need specifics.

I see there are kernel build instructions included, is there any other way to get the kernel?

Although I do not own one I do see the potential of these devices.  They are in-line with rpi2 specs and hdmi-cec is supported with libcec.  This makes is easy for us to support cec control as well.

I'm super occupied so I'm trying to be succinct, which may seem terse or short.  Not my intent.

You're doing some great investigations!  Let's get things to a point where we can actually boot a device!

In fact, we can ignore PXE booting completely for now if you can install ubuntu trusty on it somehow   I can guide you through creating a disked MD that doesn't need u-boot and PXE booting for now.

J.

[pigdog]

Hi,

I will take a peek at installing ubuntu trusty on a microSD.  I should be able to shoe-horn onto a 16gig card.  If not I'll pick up a 32.

I have Android running on one mSD.  Fedora 20 on another.

I am working nights this w/e so hopefully will have some news next week.

Cheers.

[phenigma]

Sounds good.  I'll see about rebuilding the armv7 build to ensure its' recent.

J.