[opensuse-arm] openSUSE 13.2 on cubieboard works
I have managed to get oS 13.2 to boot on a cubieboard by doctoring the installation image and transplanting the factory boot loader and kernel into it. Steps are a bit complicated so I made a script[1]. Inputs are the 13.2 and factory installation images, and script constants need version adjustment. When installing the modified image the system boots, reboots (not something to take for granted...), and at least passes the sanity checks. So far, so good. Is the 13.2 kernel working on the cubieboard? I couldn't get that one to go, it hangs at "starting kernel", even with a newer boot loader. The 13.2 boot loader is broken and needs a newer version, but that shouldn't affect the kernel directly. Never mind. I've updated https://en.opensuse.org/HCL:CubieBoard accordingly. Volker [1] http://volker.top.geek.nz/soft/script/cubieboard-oS13.2-transplant-boot -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 27.04.2015 um 12:52 schrieb Volker Kuhlmann <list0570@paradise.net.nz>:
I have managed to get oS 13.2 to boot on a cubieboard by doctoring the installation image and transplanting the factory boot loader and kernel into it. Steps are a bit complicated so I made a script[1]. Inputs are the 13.2 and factory installation images, and script constants need version adjustment.
When installing the modified image the system boots, reboots (not something to take for granted...), and at least passes the sanity checks. So far, so good.
Is the 13.2 kernel working on the cubieboard? I couldn't get that one to go, it hangs at "starting kernel", even with a newer boot loader. The 13.2 boot loader is broken and needs a newer version, but that shouldn't affect the kernel directly. Never mind.
I've updated https://en.opensuse.org/HCL:CubieBoard accordingly.
Awesome. Would you be willing to maintain a contrib for 13.2 so that we have a working version? I'd create a repo for you then and you could just copy the current kernel and uboot into it :). Alex
Volker
[1] http://volker.top.geek.nz/soft/script/cubieboard-oS13.2-transplant-boot
-- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
I have managed to get oS 13.2 to boot on a cubieboard by doctoring the installation image and transplanting the factory boot loader and kernel into it. Steps are a bit complicated so I made a script[1]. Inputs are the 13.2 and factory installation images, and script constants need version adjustment.
When installing the modified image the system boots, reboots (not something to take for granted...), and at least passes the sanity checks. So far, so good.
Is the 13.2 kernel working on the cubieboard? I couldn't get that one to go, it hangs at "starting kernel", even with a newer boot loader. The 13.2 boot loader is broken and needs a newer version, but that shouldn't affect the kernel directly. Never mind.
I've updated https://en.opensuse.org/HCL:CubieBoard accordingly.
Awesome. Would you be willing to maintain a contrib for 13.2 so that we have a working version? I'd create a repo for you then and you could just copy the current kernel and uboot into it :).
Alex
Volker
[1] http://volker.top.geek.nz/soft/script/cubieboard-oS13.2-transplant-boot
--
Nice to hear this! I have similar problem with Cubietruck (aka Cubieboard 3). It boots with Factory but not with 13.2. -- Wojciech -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon 27 Apr 2015 23:40:46 NZST +1200, Wojciech Kazubski wrote:
Nice to hear this! I have similar problem with Cubietruck (aka Cubieboard 3). It boots with Factory but not with 13.2.
That has an A20. Change the script (trivial) for the cubietruck 13.2 and factory images and try it out on a spare uSD card. Let us know if it boots and if you improve the script I'll combine. Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon 27 Apr 2015 23:40:46 NZST +1200, Wojciech Kazubski wrote:
Nice to hear this! I have similar problem with Cubietruck (aka Cubieboard 3). It boots with Factory but not with 13.2.
That has an A20. Change the script (trivial) for the cubietruck 13.2 and factory images and try it out on a spare uSD card. Let us know if it boots and if you improve the script I'll combine.
Volker
I changed a script accordingly and created modified images of oS 13.2. I had to download some of your other scripts and I had some problems with auto retrieving disk ID-s (manual mode worked). Image with Factory u-boot and distribution kernel is booting until "Starting kernel" message and screen goes off. I could not idnentify a log file, so I can't tell what goes wrong. Image with Factory u-boot and kernel boots correctly. I can login in text mode, everythig works as expected. Wojciech -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Fri 01 May 2015 23:11:55 NZST +1200, wk@ire.pw.edu.pl wrote:
I changed a script accordingly and created modified images of oS 13.2. I had to download some of your other scripts and I had some problems with auto retrieving disk ID-s (manual mode worked).
Does the script not parse the output of fdisk -l for the disk ID? I wonder whether it fails for non-English. Try running the script with env LANG=C LC_ALL=C cubie...
Image with Factory u-boot and distribution kernel is booting until "Starting kernel" message and screen goes off.
Screen goes off? Does the cubietruck not have a serial interface to use as console? If it hangs at "starting kernel" it means the kernel and initrd were loaded from partition 1 of the installation flash card, but the kernel doesn't run, which could mean kicking the factory initrd into shape for 13.2 failed or is incomplete.
I could not idnentify a log file, so I can't tell what goes wrong.
There isn't one at that point I think.
Image with Factory u-boot and kernel boots correctly. I can login in text mode, everythig works as expected.
Did the script fail in any of the steps? If not my guess is the cubietruck needs more things copied from the factory system. Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Cytowanie Volker Kuhlmann <list0570@paradise.net.nz>:
On Fri 01 May 2015 23:11:55 NZST +1200, wk@ire.pw.edu.pl wrote:
I changed a script accordingly and created modified images of oS 13.2. I had to download some of your other scripts and I had some problems with auto retrieving disk ID-s (manual mode worked).
Does the script not parse the output of fdisk -l for the disk ID? I wonder whether it fails for non-English. Try running the script with env LANG=C LC_ALL=C cubie...
It was a problem calling the subroutine get_disk_id () The script exited just after writing "Getting disk IDs:" (line 147)
Image with Factory u-boot and distribution kernel is booting until "Starting kernel" message and screen goes off.
Screen goes off? Does the cubietruck not have a serial interface to use as console?
In theory it has several serial ports, but hidden somewhere on expansion connectors inside case. Probably requiring some kind of dotherboard to provide voltage conversion.
If it hangs at "starting kernel" it means the kernel and initrd were loaded from partition 1 of the installation flash card, but the kernel doesn't run, which could mean kicking the factory initrd into shape for 13.2 failed or is incomplete.
I could not idnentify a log file, so I can't tell what goes wrong.
There isn't one at that point I think.
If the kernel does not run, no log can be written. I also have Beagleboard, which does not show anything on screen due to misconfigured/failed video driver. In this case the log file is written
Image with Factory u-boot and kernel boots correctly. I can login in text mode, everythig works as expected.
Did the script fail in any of the steps? If not my guess is the cubietruck needs more things copied from the factory system.
The files copied by the script (including Factory kernel) are suficient to make working system. Please add a notice that another script mount-img-partitions is needed. Wojciech -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Sat 02 May 2015 11:38:43 NZST +1200, wk@ire.pw.edu.pl wrote:
It was a problem calling the subroutine get_disk_id () The script exited just after writing "Getting disk IDs:" (line 147)
I suspected that. I can try and fix it, but you have to send me the output of "fdisk -l openSUSE...img.xz", preferably as compressed tar file directly to me.
In theory it has several serial ports, but hidden somewhere on expansion connectors inside case. Probably requiring some kind of dotherboard to provide voltage conversion.
The USB/serial cable shipped with the cubieboard works fine, although the Vcc line is 5V - "DO NOT CONNECT" are the instructions. Very useful, can get access and boot progress without keyboard, monitor, Ethernet connected. But up to you :-)
The files copied by the script (including Factory kernel) are suficient to make working system.
I must have misunderstood you yesterday. You DO get a booting system with the image produced by te script, as long as you manually edit the script to use the correct disk ID? That would be splendid.
Please add a notice that another script mount-img-partitions is needed.
Ah this is the problem. I still need the output of fdisk -l. You'll find my scripts in package scriptutils except for the really new ones. I just updated it to 1.56. It's noarch so you don't need an ARM version. You might find dolog useful with cubieboard-oS13.2-transplant-boot. Thanks, Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Cytowanie Volker Kuhlmann <list0570@paradise.net.nz>:
On Sat 02 May 2015 11:38:43 NZST +1200, wk@ire.pw.edu.pl wrote:
It was a problem calling the subroutine get_disk_id () The script exited just after writing "Getting disk IDs:" (line 147)
I suspected that. I can try and fix it, but you have to send me the output of "fdisk -l openSUSE...img.xz", preferably as compressed tar file directly to me.
I did some test and it is most probably locale problem. Setting LANG and LC_ALL to C makes script working. I think it would be possible to put locale setting in the script.
In theory it has several serial ports, but hidden somewhere on expansion connectors inside case. Probably requiring some kind of dotherboard to provide voltage conversion.
The USB/serial cable shipped with the cubieboard works fine, although the Vcc line is 5V - "DO NOT CONNECT" are the instructions. Very useful, can get access and boot progress without keyboard, monitor, Ethernet connected. But up to you :-)
The Cubietruck has different design of the PCB. There are no long expansion connectors along the long sides, but two shorter near short sides. Available external connectors are 2xUSB, 1x microUSB/OTG, phone jack, VGA D-sub, HDMI, SPDIF, IR port and Ethernet.
The files copied by the script (including Factory kernel) are suficient to make working system.
I must have misunderstood you yesterday. You DO get a booting system with the image produced by te script, as long as you manually edit the script to use the correct disk ID? That would be splendid.
It is correct. I expect that Cubieboard2 will suffer similar problem too.
Please add a notice that another script mount-img-partitions is needed.
Ah this is the problem. I still need the output of fdisk -l.
In the attachment.
You'll find my scripts in package scriptutils except for the really new ones. I just updated it to 1.56. It's noarch so you don't need an ARM version. You might find dolog useful with cubieboard-oS13.2-transplant-boot.
Thanks,
Volker
Thanks for help. Wojciech
On Sat 02 May 2015 20:50:22 NZST +1200, wk@ire.pw.edu.pl wrote:
I did some test and it is most probably locale problem. Setting LANG and LC_ALL to C makes script working. I think it would be possible to put locale setting in the script.
Yes, that's the problem. Funnily enough "Identyfikator dysku" doesn't parse too well as "Disk identifier"... ;-) I've put up a new mount-img-partitions that fixes this. Thanks for your help! Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon 27 Apr 2015 23:26:30 NZST +1200, Alexander Graf wrote:
Awesome. Would you be willing to maintain a contrib for 13.2 so that we have a working version? I'd create a repo for you then and you could just copy the current kernel and uboot into it :).
Willing yes, ability will have to show. ;-) I know nothing about the whole build system setup but it's essential to know. One of the problems I found on 13.2 was the initrd being created without the sunxi-mmc module required to access the uSD card for booting. Someone fixed factory by having the build process drop a file in /etc/dracut.conf.d/ (it's not owned by anything so it's inserted glue). Solving problems twice is not good use of anyone's time so I'd like to know where to look or who to ask. Something like my script is unmaintainable kludge. It would be cool to have a better setup, there are still some rough edges. Just now trying to move the system to SATA fails booting because of no SATA drivers in initrd... But I'd like to see this working. Allwinner are a bunch of ^%!#($ but the board is good with SATA and real Ethernet. Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 27.04.15 23:26, Volker Kuhlmann wrote:
On Mon 27 Apr 2015 23:26:30 NZST +1200, Alexander Graf wrote:
Awesome. Would you be willing to maintain a contrib for 13.2 so that we have a working version? I'd create a repo for you then and you could just copy the current kernel and uboot into it :).
Willing yes, ability will have to show. ;-) I know nothing about the whole build system setup but it's essential to know. One of the problems
No worries, it'll come over time ;).
I found on 13.2 was the initrd being created without the sunxi-mmc module required to access the uSD card for booting. Someone fixed factory by having the build process drop a file in /etc/dracut.conf.d/ (it's not owned by anything so it's inserted glue). Solving problems
This happens in "config.sh" which is defined in the "JeOS" package. The file already exists in 13.2, but apparently a space was missing. Duh.
twice is not good use of anyone's time so I'd like to know where to look or who to ask. Something like my script is unmaintainable kludge.
Usually any magic like the one above happens inside the image assembly description, namely the "JeOS" package that the respective JeOS builds link to.
It would be cool to have a better setup, there are still some rough edges. Just now trying to move the system to SATA fails booting because of no SATA drivers in initrd... But I'd like to see this working. Allwinner are a bunch of ^%!#($ but the board is good with SATA and real Ethernet.
Ok, I've added a Contrib for Allwinner (sunxi) chips for 13.2 at https://build.opensuse.org/project/show/devel:ARM:13.2:Contrib:Allwinner I've also copied the Factory u-boot and kernel into it and modified JeOS so that it hopefully picks the correct binaries from the devel repository. I've also added you as maintainer for the repository. Let's see how far this gets us and what is still missing. Please also always fix problems you encounter in Factory first and only then backport them to the 13.2 contrib repository. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue 28 Apr 2015 10:16:46 NZST +1200, Alexander Graf wrote:
The file already exists in 13.2, but apparently a space was missing. Duh.
/etc/dracut.conf.d/sunxi_modules.conf does not exist in 13.2 openSUSE-13.2-ARM-JeOS-cubieboard.armv7l-1.12.1-Build33.6.raw.xz (one of the showstoppers). Without it the initrd can't access the SD card to boot from. Interestingly, the missing space throws dracut errors (array index) but still gets the sunxi-mmc module included. I've updated my script with fixes and automagic so people have a chance of getting a functional 13.2. Still to verify that all the udev etc things work with a newer kernel that the release wasn't designed for.
Ok, I've added a Contrib for Allwinner (sunxi) chips for 13.2 at
https://build.opensuse.org/project/show/devel:ARM:13.2:Contrib:Allwinner
Thanks! I'll do what I can. 13.2 was probably close to functional with a number of small but critical fixes. dracut should probably be upgraded to the factory version too because it shouldn't be kernel- or distro-release dependent but it has had fixes for sunxi hardware. Thanks for your help, Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 28.04.15 05:41, Volker Kuhlmann wrote:
On Tue 28 Apr 2015 10:16:46 NZST +1200, Alexander Graf wrote:
The file already exists in 13.2, but apparently a space was missing. Duh.
/etc/dracut.conf.d/sunxi_modules.conf does not exist in 13.2 openSUSE-13.2-ARM-JeOS-cubieboard.armv7l-1.12.1-Build33.6.raw.xz
Interesting. The code to create it does exist in the JeOS config.sh file.
(one of the showstoppers). Without it the initrd can't access the SD card to boot from. Interestingly, the missing space throws dracut errors (array index) but still gets the sunxi-mmc module included.
I've updated my script with fixes and automagic so people have a chance of getting a functional 13.2. Still to verify that all the udev etc things work with a newer kernel that the release wasn't designed for.
Ok, I've added a Contrib for Allwinner (sunxi) chips for 13.2 at
https://build.opensuse.org/project/show/devel:ARM:13.2:Contrib:Allwinner
Thanks! I'll do what I can. 13.2 was probably close to functional with a number of small but critical fixes. dracut should probably be upgraded to the factory version too because it shouldn't be kernel- or distro-release dependent but it has had fixes for sunxi hardware.
Oh? Well, you can do that yourself now :). Just run $ osc copypac -e openSUSE:Factory dracut devel:ARM:13.2:Contrib:Allwinner and the Allwinner contrib images should get newer dracut. Don't forget to cross your fingers ;). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Tue 28 Apr 2015 19:41:39 NZST +1200, Alexander Graf wrote: Using devel:ARM:13.2:Contrib:Allwinner, how do I compile install images locally? This doesn't work:
cd devel:ARM:13.2:Contrib:Allwinner/JeOS-cubieboard osc repos standard armv7l images armv7l osc build images armv7l WARNING: native compile is not possible, an emulator must be configured! ... [ 7s] running aaa_base preinstall script [ 7s] chroot: failed to run command 'sh': Exec format error
It is obvious that osc build runs natively (x86_64) inside the target system's armv7l chroot. Installing qemu doesn't change that: qemu-linux-user-2.1.0-2.9.x86_64 qemu-extra-2.1.0-2.9.x86_64 qemu-arm-2.1.0-2.9.x86_64 qemu-block-curl-2.1.0-2.9.x86_64 qemu-2.1.0-2.9.x86_64 qemu-tools-2.1.0-2.9.x86_64 osc-0.151.2-11.1.noarch Host system is oS 13.2 x86_64. Online suggestions of inserting qemu in the command line somewhere all fail badly (wrong arguments). --vm-type=qemu dies over kvm. What is the incantation to build a cubieboard image locally? What needs to be done to only build for cubieboard (not the other dozen arm boards too)? Is it possible to build without re-building all the many dozen unchanged packages included in the image? osc copypac -e openSUSE:Factory dracut devel:ARM:13.2:Contrib:Allwinner Ok that's the easy bit. How does this package end up in the image then, instead of the version that was there before? Thanks, Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 04.05.15 06:32, Volker Kuhlmann wrote:
On Tue 28 Apr 2015 19:41:39 NZST +1200, Alexander Graf wrote:
Using devel:ARM:13.2:Contrib:Allwinner, how do I compile install images locally? This doesn't work:
cd devel:ARM:13.2:Contrib:Allwinner/JeOS-cubieboard osc repos standard armv7l images armv7l osc build images armv7l WARNING: native compile is not possible, an emulator must be configured! ... [ 7s] running aaa_base preinstall script [ 7s] chroot: failed to run command 'sh': Exec format error
It is obvious that osc build runs natively (x86_64) inside the target system's armv7l chroot.
Installing qemu doesn't change that: qemu-linux-user-2.1.0-2.9.x86_64 qemu-extra-2.1.0-2.9.x86_64 qemu-arm-2.1.0-2.9.x86_64 qemu-block-curl-2.1.0-2.9.x86_64 qemu-2.1.0-2.9.x86_64 qemu-tools-2.1.0-2.9.x86_64 osc-0.151.2-11.1.noarch
Host system is oS 13.2 x86_64.
Online suggestions of inserting qemu in the command line somewhere all fail badly (wrong arguments). --vm-type=qemu dies over kvm.
What is the incantation to build a cubieboard image locally?
We used to build images using emulation on x86_64 in the past. Back then, because the repository was configured for it, you could also build it on x86_64 locally. However, we since switched over to native builds as we gained more ARM hardware in OBS. To compile packages in emulated mode on x86_64 you can use the "qemu" repository (osc build qemu armv7l *.spec), but we don't have such a thing set up for images. Bottom line is that you probably just want to build images on an ARM system. I suppose you do have the cubieboard working well enough to run osc build now?
What needs to be done to only build for cubieboard (not the other dozen arm boards too)?
"osc build images armv7l JeOS-cubieboard.kiwi" should do the trick.
Is it possible to build without re-building all the many dozen unchanged packages included in the image?
Locally yes, on the server only if you manually disable builds for the links. But when you branch we usually try to keep everything built to make sure things still work after you changes ;).
osc copypac -e openSUSE:Factory dracut devel:ARM:13.2:Contrib:Allwinner
Ok that's the easy bit. How does this package end up in the image then, instead of the version that was there before?
That's what the following lines in the kiwi xml do: <repository type="rpm-md" priority="5"> <source path="obs://devel:ARM:13.2:Contrib:Allwinner/standard"/> </repository> With this kiwi (and OBS) know then any package residing in the Allwinner contrib repository should take precedence over the ones in openSUSE:13.2. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon 04 May 2015 20:16:05 NZST +1200, Alexander Graf wrote:
Bottom line is that you probably just want to build images on an ARM system. I suppose you do have the cubieboard working well enough to run osc build now?
Ok thanks, will try. Perhaps it'll bring up memories of compiling kernels on a 486... ;-) Yes as soon as I had a 13.2 install image that booted and could install kernels and initrds I started this thread. Thanks for the help! Btw osc doesn't flush stdout if output isn't to a terminal, not even after displaying a prompt and waiting for input when stdin is still a terminal. I like to log the output with osc | tee -a. Using script is unsatisfactory. If there's a trick to persuade it to behave as with a terminal I'd love to hear. Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Mon 27 Apr 2015 22:52:06 NZST +1200, Volker Kuhlmann wrote: Just for the record: Once the modified oS 13.2 installation image is booted, installing these packages from factory gives a functional system. dracut-037-32.1.armv7hl dtb-sun4i-3.19.0-40.1.armv7hl u-boot-cubieboard-2015.04-1.1.armv7hl u-boot-cubieboard-doc-2015.04-1.1.armv7hl u-boot-tools-2015.04-1.1.armv7hl kernel-default-3.19.3-1.1.armv7hl (<-- install last!) I'll see how I get these updated in the jeos package, Alex. Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
I claim success with making new installation images that give a working system. Details are referenced from here: https://en.opensuse.org/HCL:CubieBoard#Installing_the_openSUSE_13.2_Image Unfortunately I couldn't get it to work with the 3.16 kernel in oS 13.2. If anyone knows whether it should be possible to boot 3.16 on a cubieboard I'd like to hear, even better would be to hear how ;-) Big thanks to Alexander Graf for helping me outwith the specifics of building ARM images, and some of the details of the OBS. Cheers, Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (4)
-
Alexander Graf -
Volker Kuhlmann -
wk＠ire.pw.edu.pl -
Wojciech Kazubski