LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware - ARM (http://www.linuxquestions.org/questions/slackware-arm-108/)
-   -   Slackware 14.1 for cubietruck (http://www.linuxquestions.org/questions/slackware-arm-108/slackware-14-1-for-cubietruck-4175496049/)

cycojesus 02-24-2014 12:51 PM

Slackware 14.1 for cubietruck
 
I give you a script to build a Slackware SD image for cubietruck.

It's available @ https://bitbucket.org/gwenhael/cubietruck-slackware and it's heavyly based on https://bitbucket.org/mziegler08/cubietruck-arch

louigi600 02-26-2014 01:38 AM

Did you have a go at the generic Axx miniroot image builder I made ?
ftp://ftp.slackware.org.uk/slackware...ple/louigi600/
It even has dialog interface to make it simple to use. The only thing is that I've not updated the kernel in a while because as of yet the sunxi kernel developers have not fixed the bugs afflicting the USB OTG host driver. But if you use the standard USB port on the Axx you should be ok.

cycojesus 02-26-2014 08:19 AM

Quote:

Originally Posted by louigi600 (Post 5124843)
Did you have a go at the generic Axx miniroot image builder I made ?
ftp://ftp.slackware.org.uk/slackware...ple/louigi600/
It even has dialog interface to make it simple to use. The only thing is that I've not updated the kernel in a while because as of yet the sunxi kernel developers have not fixed the bugs afflicting the USB OTG host driver. But if you use the standard USB port on the Axx you should be ok.

Interesting, I hadn't seen it. I should get a spare µSD card for testing.

cycojesus 02-26-2014 08:20 AM

I've made a serie of updates:
- builds on Slackware, no longer depends on a debian based host
- general clean-up of the script and generated image

louigi600 02-27-2014 12:25 AM

I had a look at your image builder and the instructions ...

Quote:

1 Use a debian based Linux Distribution! (sleazy, I know, we'll keep it that way until it can be hosted on a real distribution)
2 open your preferred shell
3 su -
4 cd ~
5 git clone https://bitbucket.org/gwenhael/cubietruck-slackware
6 cd cubietruck-slackware
7 chmod +x build.sh
8 sudo ./build.sh
9 cd ~/cubieslack/output
10 gunzip <image>.raw.gz
11 dd if=<image>.raw of=/dev/mmcblk0 bs=1024
12 Enjoy Slackware :)
Id you do "su -" @ step 3 you do not need to "sudo ./build.sh" @ step 8, as you are already root ... just do "./build.sh".

If you choose to put the cubietruck-slackware in what you think is a more appropriate place you end up building the image in an unexpected place "~/cubieslack" ... it would be nice to get prompted or at least put in the README.md that you can govern this by something like "DEST=<your image target directory> ./build.sh".
The same applies for the image size.

Why are you downloading a x-compile toochain to build u-boot, kernel and sunxi-tools ? If you have an ARM host for building this aint gonna work anyway.
This will download a ton of stuff and requite a long time to build, and moreover what's the point in building the kernel if you get no choice in what options are being compiled ?
Why not just use the latest available from a compatible hwpack and have the sunxi-tools native to manipulate fex from the build host ? the end user will then decide if he needs sunxi-tools on the target environment.
Basically there are 3 types of sunxi kernels sun4i sun5i and sun7iand they are not differentiated for the target ... the script.bin (binary version of fex file) does that.
Ok ... they have new products now ... so there are 5 types of kernels sun<4|5|6|7|8>i but the same idea applies.

cycojesus 02-27-2014 06:00 AM

Quote:

Originally Posted by louigi600 (Post 5125561)
I had a look at your image builder and the instructions ...



Id you do "su -" @ step 3 you do not need to "sudo ./build.sh" @ step 8, as you are already root ... just do "./build.sh".

If you choose to put the cubietruck-slackware in what you think is a more appropriate place you end up building the image in an unexpected place "~/cubieslack" ... it would be nice to get prompted or at least put in the README.md that you can govern this by something like "DEST=<your image target directory> ./build.sh".
The same applies for the image size.

Why are you downloading a x-compile toochain to build u-boot, kernel and sunxi-tools ? If you have an ARM host for building this aint gonna work anyway.
This will download a ton of stuff and requite a long time to build, and moreover what's the point in building the kernel if you get no choice in what options are being compiled ?
Why not just use the latest available from a compatible hwpack and have the sunxi-tools native to manipulate fex from the build host ? the end user will then decide if he needs sunxi-tools on the target environment.
Basically there are 3 types of sunxi kernels sun4i sun5i and sun7iand they are not differentiated for the target ... the script.bin (binary version of fex file) does that.
Ok ... they have new products now ... so there are 5 types of kernels sun<4|5|6|7|8>i but the same idea applies.

Thanks for the comments, I've updated the README.md to remove reference to debian and sudo and also to mention DEST and IMAGE_SIZE_MB parameters plus a pointer to see more parameters in the script itself.

The script is meant to be ran on a x86_64 host, not the board itself. I'm not sure why one would want to do that.
On the board itself there should another way to update the kernel.

The kernel (and other tools) are compiled because I don't want to host and maintain binaries

I haven't really looked into what the sunxi-tools are yet... I should get a spare SD card tonight or tomorrow so I'll be able to experiment more. For the moment I've mostly cleaned up the code and made it distro-agnostic.

EDIT: pushed some documentation changes

louigi600 02-27-2014 07:04 AM

Quote:

Originally Posted by cycojesus (Post 5125703)
Thanks for the comments, I've updated the README.md to remove reference to debian and sudo and also to mention DEST and IMAGE_SIZE_MB parameters plus a pointer to see more parameters in the script itself.

The script is meant to be ran on a x86_64 host, not the board itself. I'm not sure why one would want to do that.
On the board itself there should another way to update the kernel.

The kernel (and other tools) are compiled because I don't want to host and maintain binaries

I haven't really looked into what the sunxi-tools are yet... I should get a spare SD card tonight or tomorrow so I'll be able to experiment more. For the moment I've mostly cleaned up the code and made it distro-agnostic.

EDIT: pushed some documentation changes

Will it not run on a x86 32 bit machine ? is the x-compile toolchain meant only for a 64 bit machine ?
A lot of people still have 32 bit only machines or 32 bit only installations.

People might not be compiling on the cubie itself but they might have another ARM machine that is powerful enough to be favored as a native compiler for ARM. I'be a Tega2 for doing that now and might soon posses a odroid u3 which might even beet my rather outdaded PC.

In any case I did not see (might have just missed it) in the script where you set the toolchain ... or maybe the makefiles in the stuff you bind has been set to use the x-toolchain ?

Concerning sunxi-tools: my advice is not to build them if you don't know what they are ... or were you referring to hwpack ?

If you don't want to maintain kernel sunxi-tools and u-boot just pick it out of some other distro that maintains it, making the image builder download sources and compile them might not be the best solution for avoiding maintenance: software evolves at at some stage your build scripts may fail to compile from sources anyway.
I was going to give your build script a go but when I got to over 1/2 Gb downloaded and nothing even started building I killed it.

cycojesus 02-27-2014 09:49 AM

Quote:

Originally Posted by louigi600 (Post 5125735)
Will it not run on a x86 32 bit machine ? is the x-compile toolchain meant only for a 64 bit machine ?
A lot of people still have 32 bit only machines or 32 bit only installations.

People might not be compiling on the cubie itself but they might have another ARM machine that is powerful enough to be favored as a native compiler for ARM. I'be a Tega2 for doing that now and might soon posses a odroid u3 which might even beet my rather outdaded PC.

In any case I did not see (might have just missed it) in the script where you set the toolchain ... or maybe the makefiles in the stuff you bind has been set to use the x-toolchain ?

Concerning sunxi-tools: my advice is not to build them if you don't know what they are ... or were you referring to hwpack ?

If you don't want to maintain kernel sunxi-tools and u-boot just pick it out of some other distro that maintains it, making the image builder download sources and compile them might not be the best solution for avoiding maintenance: software evolves at at some stage your build scripts may fail to compile from sources anyway.
I was going to give your build script a go but when I got to over 1/2 Gb downloaded and nothing even started building I killed it.

1. I use the linaro toolchain from https://launchpad.net/linaro-toolchain-binaries/ which in fact are meant for x86 (not x86_64) it should run on any x86 (and multilib x86_64) distribution. Personally I'm running a Slackware64-current. I'm adding the possibility of building from an ARM host in the todo list.
The linaro toolchain is downloaded and set up lines 39, 40 & 42 (with 2 variables for version numbers)

2. fex2bin from sunxi-tools is used on the host (lines 119 & 120) to generate script-vga.bin and script-hdmi.bin and then at the end compiled for the guest and included in the image. I guess I could just keep the script-*.bin files and skip their generation. Also considering not including them in the generated image and leave the user compile them by themselves if needed.

3. if I can find a compatible ready-made kernel, sunxi-tools and u-boot then why not. I don't mind compiling things and this way I can experiment with newer, more vanilla kernels the the current /patwood/ fork the script is using. Also for the second and later passes you can pass COMPILE=false to skip recompiling the kernel (and I have to make it skip all compile steps as well >> todo-list...) But I'll think about it for people who don't want to or have the luxury of cloning and building everything.
I like the idea building directly from the source but I guess that's me :)

louigi600 02-27-2014 12:37 PM

Fedora images for Axx systems were downloadable from links on http://linux-sunxi.org/Fedora but they seem broken right now ... check later the site might com back online.
I found a newer redhat image over here: http://dl.cubieboard.org/software/a2...mhfp-r3.img.xz

I extracted kernel and boot loader from there ... reused the script.bin from the one android was using.
If you already built the kernel and uboot you could use whatever you built ...

I checked blog https://groups.google.com/forum/#!to...xi/PLgUj-KefKQ and cubieboard2 is supported ... but not sure about cubieboard3/cuibietruck. I suppose that since the SOC is the same if you have the right script.bin it should work too.

I found a newer image over here: http://dl.cubieboard.org/software/a2...mhfp-r3.img.xz

cycojesus 02-27-2014 04:31 PM

Quote:

Originally Posted by louigi600 (Post 5125925)
Fedora images for Axx systems were downloadable from links on http://linux-sunxi.org/Fedora but they seem broken right now ... check later the site might com back online.
I found a newer redhat image over here: http://dl.cubieboard.org/software/a2...mhfp-r3.img.xz

I extracted kernel and boot loader from there ... reused the script.bin from the one android was using.
If you already built the kernel and uboot you could use whatever you built ...

I checked blog https://groups.google.com/forum/#!to...xi/PLgUj-KefKQ and cubieboard2 is supported ... but not sure about cubieboard3/cuibietruck. I suppose that since the SOC is the same if you have the right script.bin it should work too.

I found a newer image over here: http://dl.cubieboard.org/software/a2...mhfp-r3.img.xz

I made sure that if you once made compile pass and pass COMPILE=false no compiling happens.

I'm a bit wary of other distros binaries, especially kernel so tomorrow I'll look into hosting pre-built binaries I made and offer them as an option in the script.
(probably hosting generated SD image too as its only 57M gzipped. I won't upload the current one as it's missing libmpfr.so (bug of official rootfs that I'll patch during image building tomorrow))

Sadly the SD card I got today was dead on arrival so now I have to wait for another one until saturday so no testing until then...

louigi600 02-27-2014 10:14 PM

Don't worry too much if some packages are missing from the generated image, as long as networking is functional you can add what's required later.

I found this an interesting read: http://linux-sunxi.org/New_Device_howto

Have a look at how I manipulate a modified Slackware ARM miniroot and a modified hwpack into an arbitrary size image ready to be burned into a SD card.
Would it not be better if we find an agreement on merging our work into one effort ?

I had a look at fedora's latest image for Allwinner soc (from the link I gave you above) and they now have support for the cuibieboard3/cuibietruck ... but they are using an older kernel 3.4.61. One good thing they do is to show the kernel configuration (/boot/scripts/kernel-3.4-armv7hl-sun?i.config).
Recently I updated kernel on my A13 tablet to get the wifi card working again, I'm using 3.4.75 pulled from linux-sunxi not so long ago but I see they are now @ 3.4.79 (to my understanding the just added some other boards there was no fixing).
I see you're not using the linux-sunxi branch but patricwood's branch , what's the difference ?

cycojesus 02-28-2014 02:03 AM

Bitbucket offers file hosting so here goes an image: https://bitbucket.org/gwenhael/cubie...ware/downloads
libmpfr is still missing but well...

Script-wise it should now skip setting up and x-toolchain on ARM host (untested), and also it gained --parameters. Try --help for a list

louigi600 02-28-2014 02:24 AM

I don't have anything with an A2x SOC in it so I ca'nt try it.
I tried extracting the boot stuff from the newest fedora Axx image I could find but I can't get it to boot ... it's not even loading kernel.
I rearranged my image builder to format boot in ext2 and tried both my original script.bin and the one that came with fedora for my device but it's still a no go.
I've updated my newest script .... maybe you could try and see if it can make a bootable image for the cubietruck.
It should fit in a 512MB SD... hoping you have a spare SD of at least that size.

Arnim000 02-28-2014 03:49 PM

Hello,

I buy a cubietruck some times ago, hopefully someone will create a slackware image for it. I think, you are on the right way:-)



@louigi600:

Yesterday I try your build script. There is no choice "cubietruck", so I try cubieboard2.

My cubietruck is booting, but my keyboard is not working.
Many users have this problem with the keyboard, because it is an cordless Logitech MK520 keyboard + mouse set with the Logitech Unifying USB-Reciver. /dev/hidraw raw HID device is missing in kernel, I think.



Today, I tested your updated scripts.

Test with choice cubieruck: With this, my cubietruck will not boot from SD card.
I don't know why.

So I try the option "cubieboard2". Wow, it is booting.
Also my logitech keyboard is working:-)


WLAN is not working, because the modul bcmdhd is missing.
All the other hardware, I don't tested it.




@cycojesus:

Your image is no image?
After writing it to my SD card (cat SlackwareARM_cubitruck-0.2_rootfs_SD.raw > /dev/mmcblk0), there is only one partition (rootfs) on the SD card. The boot partition is missing.

Maybe I do something wrong?



Sincerely, Arnim!

cycojesus 02-28-2014 11:36 PM

Quote:

Originally Posted by Arnim000 (Post 5126709)
[...]



@cycojesus:

Your image is no image?
After writing it to my SD card (cat SlackwareARM_cubitruck-0.2_rootfs_SD.raw > /dev/mmcblk0), there is only one partition (rootfs) on the SD card. The boot partition is missing.

Maybe I do something wrong?



Sincerely, Arnim!

Have you tried booting from the card? It should boot just fine.

Note a bug on first boot: / is mount read-write from the start and this disturbs /etc/rc.d/rc.S so there will be a warning message during boot. Just press Enter to continue booting


All times are GMT -5. The time now is 08:51 AM.