LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 02-24-2014, 12:51 PM   #1
cycojesus
Member
 
Registered: Dec 2005
Location: Lyon, France
Distribution: Slackware-current
Posts: 116

Rep: Reputation: 79
Lightbulb 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
 
Old 02-26-2014, 01:38 AM   #2
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 634
Blog Entries: 20

Rep: Reputation: 81
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.

Last edited by louigi600; 02-26-2014 at 03:09 AM.
 
Old 02-26-2014, 08:19 AM   #3
cycojesus
Member
 
Registered: Dec 2005
Location: Lyon, France
Distribution: Slackware-current
Posts: 116

Original Poster
Rep: Reputation: 79
Quote:
Originally Posted by louigi600 View Post
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.
 
Old 02-26-2014, 08:20 AM   #4
cycojesus
Member
 
Registered: Dec 2005
Location: Lyon, France
Distribution: Slackware-current
Posts: 116

Original Poster
Rep: Reputation: 79
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
 
Old 02-27-2014, 12:25 AM   #5
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 634
Blog Entries: 20

Rep: Reputation: 81
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.

Last edited by louigi600; 02-27-2014 at 12:35 AM.
 
Old 02-27-2014, 06:00 AM   #6
cycojesus
Member
 
Registered: Dec 2005
Location: Lyon, France
Distribution: Slackware-current
Posts: 116

Original Poster
Rep: Reputation: 79
Quote:
Originally Posted by louigi600 View Post
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

Last edited by cycojesus; 02-27-2014 at 06:03 AM.
 
Old 02-27-2014, 07:04 AM   #7
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 634
Blog Entries: 20

Rep: Reputation: 81
Quote:
Originally Posted by cycojesus View Post
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.

Last edited by louigi600; 02-27-2014 at 07:10 AM.
 
Old 02-27-2014, 09:49 AM   #8
cycojesus
Member
 
Registered: Dec 2005
Location: Lyon, France
Distribution: Slackware-current
Posts: 116

Original Poster
Rep: Reputation: 79
Quote:
Originally Posted by louigi600 View Post
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
 
Old 02-27-2014, 12:37 PM   #9
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 634
Blog Entries: 20

Rep: Reputation: 81
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

Last edited by louigi600; 02-27-2014 at 01:57 PM.
 
Old 02-27-2014, 04:31 PM   #10
cycojesus
Member
 
Registered: Dec 2005
Location: Lyon, France
Distribution: Slackware-current
Posts: 116

Original Poster
Rep: Reputation: 79
Quote:
Originally Posted by louigi600 View Post
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...
 
Old 02-27-2014, 10:14 PM   #11
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 634
Blog Entries: 20

Rep: Reputation: 81
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 ?

Last edited by louigi600; 02-27-2014 at 11:31 PM.
 
Old 02-28-2014, 02:03 AM   #12
cycojesus
Member
 
Registered: Dec 2005
Location: Lyon, France
Distribution: Slackware-current
Posts: 116

Original Poster
Rep: Reputation: 79
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
 
Old 02-28-2014, 02:24 AM   #13
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 634
Blog Entries: 20

Rep: Reputation: 81
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.

Last edited by louigi600; 02-28-2014 at 04:20 AM.
 
Old 02-28-2014, 03:49 PM   #14
Arnim000
LQ Newbie
 
Registered: Feb 2014
Location: Germany
Distribution: Slackware
Posts: 7

Rep: Reputation: Disabled
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!
 
1 members found this post helpful.
Old 02-28-2014, 11:36 PM   #15
cycojesus
Member
 
Registered: Dec 2005
Location: Lyon, France
Distribution: Slackware-current
Posts: 116

Original Poster
Rep: Reputation: 79
Quote:
Originally Posted by Arnim000 View Post
[...]



@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
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Cubieboard2 open SBC ships, Cubietruck model revealed LXer Syndicated Linux News 0 06-27-2013 04:20 AM
About Slackware 9.1 boot disk?? ftp://ftp.kpn.be/pub/linux/slackware/slackware-9.1-is AL3OMDAH Slackware 4 04-18-2007 09:54 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 05:01 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration