Hello.
I'd like to know what is the status if arm-dev project? I recently bought A20- OlinuXino-MICRO board (https://www.olimex.com/wiki/A20-OLinuXino-MICRO) and successfully run it with their official Linux image. But it's Debian...
I don't have any experience in porting Linux to other architectures and configuring for particularly board but i'm eager to learn it (i plan to use some kind of embedded computer to develop home automation system).
Could you point me into right direction - how to begin and what should i know (i've been compiling kernels some time ago but i can't say i'm a kernel hacker). I would like to use CentOS for my purposes (i have some more ideas for small appliances and they are mainly ARM-based i think).
Thanks for any help and information.
On 12/02/2014 05:44 AM, Marcin Trendota wrote:
Hello.
I'd like to know what is the status if arm-dev project? I recently bought A20- OlinuXino-MICRO board (https://www.olimex.com/wiki/A20-OLinuXino-MICRO) and successfully run it with their official Linux image. But it's Debian...
And another Allwinner user!
See if there is a Fedora 19 or 20 remix for your board to test with for starters.
Get the Fedora 21 beta:
https://dl.fedoraproject.org/pub/alt/stage/21_RC1/Images/armhfp/
We are up to the final release candidate. I suspect you will have to run minimal, as there is no video support in the uboot for Allwinners, yet. And probably won't be until Fedora 22. You will have to run off the serial console (you DO have a TTL usb uart?).
Here are the general instructions for installing the beta:
http://fedoraproject.org/wiki/Architectures/ARM/F21/Installation
Your board is supported in the uboot:
/usr/share/uboot/A20-OLinuXino_MICRO
You will have to do the manual install for your uboot. Once you figure it out, you might want to tell Paul what changes to make to his install script to support your board (I provided him with the Cubieboard2 change).
You will have to do the following mod to get the serial console working with this uboot:
Modify the following line in __boot/extlinux/extlinux.conf adding the console line.
append ro root=UUID=b6a0bdb6-46ac-4206-b116-72e95429cfcd console=ttyS0,115200
I **think** I have provided you everything I have learned about getting the F21 beta working. This is stuff we will have to follow for the Centos7-arm port.
I don't have any experience in porting Linux to other architectures and configuring for particularly board but i'm eager to learn it (i plan to use some kind of embedded computer to develop home automation system).
Could you point me into right direction - how to begin and what should i know (i've been compiling kernels some time ago but i can't say i'm a kernel hacker). I would like to use CentOS for my purposes (i have some more ideas for small appliances and they are mainly ARM-based i think).
Thanks for any help and information.
I'd say get the F21 working on your board. Perhaps join the fedora-arm list. Get familiar with your board with redhatish stuff until we finally get this port underway. Centos7 is built on F19, so there is enough common still in F21.
We DO need to set a direction for uboot for this port. I vote for using the F21 uboot. This is based on the sunxi work:
http://linux-sunxi.org/Linux_mainlining_effort
It was frozen in October and lots of improvements since then, but at least it is one uboot for a lot of boards. It is the only way to approach a sane install process. I have also seen messages on the uboot list for patches for kirkwood boards. If I understand this right, they are also backporting to armv5/6 boards. As well as the armv8 (64bit) boards. Oh and there is a F21 arm64 beta available as well.
Dnia wtorek, 2 grudnia 2014 7:54:25 AM Robert Moskowitz pisze:
I'd like to know what is the status if arm-dev project? I recently bought A20- OlinuXino-MICRO board (https://www.olimex.com/wiki/A20-OLinuXino-MICRO) and successfully run it with their official Linux image. But it's Debian...
And another Allwinner user!
Not yet exactly (:) i'm at pretty early stage of research - but this looks promising (also the price).
[...]
Here are the general instructions for installing the beta: http://fedoraproject.org/wiki/Architectures/ARM/F21/Installation Your board is supported in the uboot: /usr/share/uboot/A20-OLinuXino_MICRO You will have to do the manual install for your uboot. Once you figure it out, you might want to tell Paul what changes to make to his install script to support your board (I provided him with the Cubieboard2 change).
This board has bootloader included as it seems.
You will have to do the following mod to get the serial console working with this uboot: Modify the following line in __boot/extlinux/extlinux.conf adding the console line. append ro root=UUID=b6a0bdb6-46ac-4206-b116-72e95429cfcd console=ttyS0,115200
And it works! As for now it fall into endless loop throwing many errors (with FS also) - i need to investigate it further. Maybe i will write card again?
I **think** I have provided you everything I have learned about getting the F21 beta working. This is stuff we will have to follow for the Centos7-arm port.
And it was very helpful indeed! Many, many thanks!
I'd say get the F21 working on your board. Perhaps join the fedora-arm list. Get familiar with your board with redhatish stuff until we finally get this port underway. Centos7 is built on F19, so there is enough common still in F21.
Yes, there is for sure long way ahead of me. I'll need to dig deeper (uboot stuff for example is magic for me right now as it worked OOTB).
Good to know there's a point to begin. Thanks again, you saved me a lot of time and frustration at the beginning.
Spoke too soon - it was Android image from NAND FLASH (:)
It'll be harder than a though so. Now im trying to figure out hot too boot from SD Card from U-Boot. But it's not topic for this group - still thanks for help! (:)
On 12/03/2014 11:22 AM, Marcin Trendota wrote:
Spoke too soon - it was Android image from NAND FLASH (:)
It'll be harder than a though so. Now im trying to figure out hot too boot from SD Card from U-Boot. But it's not topic for this group - still thanks for help! (:)
You might want to look at the RedSleeve wiki for some info. RS approach is to use whatever kernel ships with the device and apply the RS userspace to it. The standard Android kernel should work fine to get the basic system up and running.
What hardware are you using?
Gordan
Dnia środa, 3 grudnia 2014 11:26:34 AM Gordan Bobic pisze:
You might want to look at the RedSleeve wiki for some info. RS approach is to use whatever kernel ships with the device and apply the RS userspace to it. The standard Android kernel should work fine to get the basic system up and running.
Yes, this may be best choice for the beginning, i'll give it a chance. Of course in long term i want be able to upload arbitrary bootloader and kernel / Linux distribution (CentOS to be specific).
What hardware are you using?
https://www.olimex.com/wiki/A20-OLinuXino-MICRO
Last entry - i successfully installed Fedora 21 on microSD card, put U-Boot on it (same way as for BananaPi and CubieTruck) and boot system (even modification in extlinux.conf wasn't necessary and still i have serial console available). As for now it works.
On 12/03/2014 09:40 AM, Marcin Trendota wrote:
Last entry - i successfully installed Fedora 21 on microSD card, put U-Boot on it (same way as for BananaPi and CubieTruck) and boot system (even modification in extlinux.conf wasn't necessary and still i have serial console available). As for now it works.
Welcome to the party. I have been using that serial console append since the problem first came up. They said there would be a fix eventually; seems like they may have. So next test I will leave it; worst case the test won't work because no console and I will have to rebuild the card image.
I have been exchanging emails with the Redhat uboot developer who is an Allwinner user (and has done much of the Allwinner work for uboot). He has video working, but you have to build your own uboot. I am working on this. It also supposedly takes kernel => 3.19, and right now Rawhide (pre F22 beta) is only at 3.18. I am waiting for him to get back to me on how to get a 3.19 kernel into a rawhide image for testing.
He said still no wifi, but he DOES have a sata multiplexer working:
http://www.ebay.com/itm/1-To-5-SATA-2-0-Port-Multiplier-Card-3Gbps-SATAII-Ri...
Again, you need the newer uboot and kernel.
armv7 is very much a moving target. The longer it takes us to get going, the more we may have working!
Of course, Gordon's approach is also valid. Use the manufacture's buggy uboot and kernel and go with that. Thing is, you are locked into that kernel and kernel updates will get very messy.
On 2014-12-03 18:10, Robert Moskowitz wrote:
Of course, Gordon's approach is also valid. Use the manufacture's buggy uboot and kernel and go with that. Thing is, you are locked into that kernel and kernel updates will get very messy.
Not at all. Once upstream gets a working uboot and kernel, you can replace what you have end upgrade to the upstream packaged versions. Using the kernel the device ships with is the pragmatic course of action when the working kernel sources aren't readily available, it doesn't lock you into sticking with it in any way.
The problem from the distribution maintenance point of view is that you cannot plausibly maintain dozens of different kernels for various different hardware. In the interest of pragmatism both from the point of view of users wanting to have something up and running on their hardware sooner rather than later and the practical constraints on distro maintenance, using the kernel that ships with the device is the least bad option, especially if the alternative is no kernel at all.
Gordan
On 12/03/2014 01:19 PM, Gordan Bobic wrote:
On 2014-12-03 18:10, Robert Moskowitz wrote:
Of course, Gordon's approach is also valid. Use the manufacture's buggy uboot and kernel and go with that. Thing is, you are locked into that kernel and kernel updates will get very messy.
Not at all. Once upstream gets a working uboot and kernel, you can replace what you have end upgrade to the upstream packaged versions. Using the kernel the device ships with is the pragmatic course of action when the working kernel sources aren't readily available, it doesn't lock you into sticking with it in any way.
The problem from the distribution maintenance point of view is that you cannot plausibly maintain dozens of different kernels for various different hardware. In the interest of pragmatism both from the point of view of users wanting to have something up and running on their hardware sooner rather than later and the practical constraints on distro maintenance, using the kernel that ships with the device is the least bad option, especially if the alternative is no kernel at all.
And Allwinner is not known for good uboot and kernels...
One of the arguments for going with the more pricey wandboards. Freescale is VERY directly active in uboot open development instead of doing their own, secret uboot as Allwinner has.
I am waiting to hear back from another US manufacturer on their new armv7 boards. They are boasting a lot of capability for a very low price. At least the engineer I work with on another project. See if they come through with something before the year is out.
-
Gordan Bobic -
Marcin Trendota -
Robert Moskowitz