Xenomai for A13 - A10

[uMinded]

I never saw the 'zip' under the tag list before... I must be blind. Good to know though as if your not going to push changes theirs no need for the extra bloat.

I made a new github repo and made it properly this time, I forked the linux-sunxi/sunxi-3.4 and I have branched off the 3.4.24-r1 commit to add I-Pipe changes then the Xenomai patch. I am building kernels and saving logs and configs at each stage. This was we can properly merge our changes back into 2.4.24 and even pull from the linux-sunxi groups changes upstream.

Its not ready to go yet as my work computer does not compile like my 16 core workstation back home.

BTW - I have talked to digikey twice now and they say they do not know of the sd card issues and that they cant pull stock to test. I'm waiting to hear back now on if I can buy it and they test it so if it fails theirs not return shipping to deal with. If not I guess I will just order it and play roulette.

[JohnS]

The SD card problems I know about are due to using cheap clone cards, the problem being the cards, and obviously they would be irrelevant to any board seller.  Which problem(s) do you mean?

John

[ehj666]

The SD card problems I know about are due to using cheap clone cards, the problem being the cards, and obviously they would be irrelevant to any board seller.  Which problem(s) do you mean?

I bought two A13-Olinuxino-wifis from Digikey. The SD ports on both boards did not work, but otherwise the boards were fine. Olimex sent me two replacements directly and the SD ports worked fine on these. I was worried that Digikey may have received a batch of boards with bad SD ports and was hoping they had the means to test one before sending them out.

[JohnS]

Oh.  Well, they probably could but it will also probably mean they sell the boards at a loss.  Just to connect them up and try a uSD card is going to wipe out their profit margin I expect, even if they have someone able to do it and equipped with the means (which they likely don't).

If the faults are an entire batch I expect they'd prefer to send the whole lot back to Olimex.  So if the faults were that kind then maybe argue it that way.

Or if they're faults that a visual inspection would reveal then maybe you could explain that to them.

John

[uMinded]

I ended up just ordering it without any checks, I was running out of time to have it delivered by Friday so I had to buy in the next 3 hours.

It will be nice to be able to actually test my own builds lol, thanks so much you guys for testing things and dumping so many logs.

Anybody interested it getting commit access to my github (once its set up properly)?

[ehj666]

Anybody interested it getting commit access to my github (once its set up properly)?

I would like to help out any way I can. So far I have pretty much been relegated to tester, but do not mind getting in and getting my hands dirty too.

[uMinded]

Linux-3.4.24-r1-vanilla+

Me and crubille have ever so slightly different ipipe patches. If the above kernel boots I will know what I need to keep when changing over some spinlocks and some if/else statements.

[ehj666]

Linux-3.4.24-r1-vanilla+

Me and crubille have ever so slightly different ipipe patches. If the above kernel boots I will know what I need to keep when changing over some spinlocks and some if/else statements.

Went a long way, but ended in a reboot loop. The boot log is here:
http://pastebin.com/yvrGxB6b

[Tele]

Went a long way, but ended in a reboot loop. The boot log is here:
http://pastebin.com/yvrGxB6b

This is good. Pbobably it has nothing to do with Xenomai. I get these errors when I forgot to link the filesystem of rootfs (ext3 or ext4) statically, but they are compiled as module. They must be compiled statically into kernel. This is my guess.

I can test in 2-3 hours. Till then Im just a spectator but I keep cheering and supporting for you.

EDIT:
Of course it has nothing to do with Xenomai, it is vanilla sunxi kernel. Im idiot.

[Tele]

This is a working vanilla sunxi3.4.24-r1 config

http://pastebin.com/Y0QX3Bhn

[Tele]

Anybody interested it getting commit access to my github (once its set up properly)?

I would like to help out any way I can. So far I have pretty much been relegated to tester, but do not mind getting in and getting my hands dirty too.

You can count on me also.

[uMinded]

I get these errors when I forgot to link the filesystem of rootfs (ext3 or ext4) statically, but they are compiled as module. They must be compiled statically into kernel.

I totally did not think of that but the only difference in regards to modules is I had the infrared one as a module (it shouldn't even be included). I did notice a few differences though as I had a different kernel compression and you had some more endianess options set. This is why having a working vanilla kernel is important as its so bloody finicky sometimes.

I will use your version as the base as it has usb networking enabled and we know it works. I am pushing working configs to the arch/arm/config/a13-olinuxino-xxx and will tag them when I do.

Went a long way, but ended in a reboot loop. The boot log is here:

It does look like it boots all the way but it does not automatically find the root filesystem which is my fault as its compiled with "CONFIG_CMDLINE_FORCE" which ignores what uBoot passes when I should of had " CONFIG_CMDLINE_EXTEND" to merge the two.

I will need a list of every ones github names to add as contributors to the repo. PM me if you want write access.

[Tele]

I will use your version as the base as it has usb networking...

Yes I forgot to say, but this is not a minimal config, USB keyboard, mouse, LCD7 framebuffer + resistive touch are working, plus RTL 8188USB->Wifi chip (I have Wifi board) + ASIX AX 88772 USB-ETH stick, (you can buy it in olimex shop), all set and working.

[uMinded]

Yes I forgot to say, but this is not a minimal config, USB keyboard, mouse, LCD7 framebuffer + resistive touch are working, plus RTL 8188USB->Wifi chip (I have Wifi board) + ASIX AX 88772 USB-ETH stick, (you can buy it in olimex shop), all set and working.

In the usual sense of the term a "vinilla" kernel is the bare minimum required to boot into a working system. As this is specific embedded hardware I classify this build vanilla. Would we rather have one _defcong for each build or a top level one with a readme on whats safe to remove?

[Tele]

...the term a "vanilla" kernel is the bare minimum required...

Yes you are right I skipped 1-2 step, because I trust in you and I think we are close, very close to the end. Of course I step back to the most naked minimum system if we will have any difficulties. We wont have.
(Relax ! Concentrate ! Be optimistic)

I live in UTC+1. You are in EST (or Pacific Time even worse). Im ahead of you at least six hours. I've seen your future. You have made it.

Would we rather have one _defcong for each build or a top level one with a readme on whats safe to remove?

Later we can decide that, if its stable its almost the same any solution, growing from minimum or shrinking from a generic full system.