Dear all, I am working with the new colibri module V1.1A using our production linux based on BSP 2.5b3 and kernel 3.14.28.
I expect that moving from colibri i.MX6 V1.0A to colibri i.MX6 V1.1A there will be no changes in kernel and rootfs, but I am unable to boot the new V1.1A board in some cases.
I am using the bootloader from the BSP 2.7.3 and the kernel and rootfs form my 2.5b3 build.
Sometimes the created image doesn’t boot, any other times if I rebuild the entire rootfs it may be boot with few errors…
I attach a boot sequence when the boot fail. link text
Change kernel is not an option, beacuse we want to provide upgrades and back compatibility with our installation in the field…
Thank you for your time,
Stefano.
Update: rebuilding the image the board stop loading the kernel in a kernel panic state.
The full boot log is here link text
Dear all, I am working with the new colibri module V1.1A using our production linux based on BSP 2.5b3 and kernel 3.14.28.
Our BSP V2.5 was only ever released as beta versions intended to be run on the sample hardware of that time and was really never ever meant to be used for anything even remotely going into production. We long since stopped supporting such ancient beta versions.
I expect that moving from colibri i.MX6 V1.0A to colibri i.MX6 V1.1A there will be no changes in kernel and rootfs, but I am unable to boot the new V1.1A board in some cases.
This combination really has never ever been tested and is quite likely to have issues.
I am using the bootloader from the BSP 2.7.3 and the kernel and rootfs form my 2.5b3 build.
While this is probably even the only approach remotely making sense that combination really has never ever been tested.
Sometimes the created image doesn’t boot, any other times if I rebuild the entire rootfs it may be boot with few errors…
That sounds unfortunate but could really have various causes.
I attach a boot sequence when the boot fail. link text
It looks like the MMC stack has some issue(s). With the limited information currently available it could be anything really, be it a bug or some misconfiguration. Unless of course it is just a hardware defect. I assume you tested this on more than just one single module, right?
Change kernel is not an option, beacuse we want to provide upgrades and back compatibility with our installation in the field…
Such a beta BSP should really never ever have gotten introduced in the field I’m afraid.
Thank you for your time, Stefano.
You are very welcome.
Here it failed even earlier just after mounting the root file system upon attempting to access some library.
Hi Marcel, thank you for your answer!
Our BSP V2.5 was only ever released as beta versions intended to be run on the sample
hardware of that time and was really never ever meant to be used for anything even remotely
going into production. We long since stopped supporting such ancient beta versions.
At the time we start the project it was the latest supposed stable BSP, what would we have to do?
It looks like the MMC stack has some issue(s). With the limited information currently available it
could be anything really, be it a bug or some misconfiguration. Unless of course it is just a
hardware defect. I assume you tested this on more than just one single module, right?
Yes I have tested on some modules with the same result…
In the end I try to move our project to the latest BSP 2.7.3, which I suppose will be stable.
Regards,
Stefano.
At the time we start the project it was the latest supposed stable BSP,
I’m not sure where you got that information from resp. which part of beta did tell you so.
what would we have to do?
I guess update to any supported BSPs being stable V2.6 or latest beta 2.7b3 at the time of this writing. However for production deployment I would stick to stable.
Yes I have tested on some modules with the same result…
Then it does not seem to be a simple hardware defect of one single module.
In the end I try to move our project to the latest BSP 2.7.3, which I suppose will be stable.
No, it is the latest beta. However the upcoming 2.7b4 may eventually pass full validation & verification and be declared stable afterwards.
I guess update to any supported BSPs being stable V2.6 or latest beta 2.7b3 at the time of
this writing. However for production deployment I would stick to stable.
Ok, where I can found this information about stable or unstable BSP?
V2.6 mean the V2.6.1?
From toradex git I see this [upload|WdZxLTwB6NWtPwNqSqiTS0eUK9M=] and 2.6 is tagged in beta, right?
From toradex developer site there aren’t any information about beta/stable state of BSP [upload|/BNOISY3FW9LqvFWYNdBH8fqrCk=] . How can I distinguish that V2.5 is in beta and V2.6 (2.6.1?) is stable and V2.7 again is not stable?
Regards,
Stefano.
Thank you for your answer Marcel!
As I can see on that page it seems that my BSP is stable
…
So I can make it work on new module colibri V1.1A, right?
No, that release was exclusively declared stable for Colibri VF50/VF61.
Dear Marcel,
I have rebuild our system using BSP V2.6 but I have the following kernel error after the boot link text .
I am using Iris carrier board V1.1A.
Best regards,
Stefano.
Yes, that is probably the following issue. Please use the update device tree available on resp. -next branch. We will update the stable V2.6 meta data shortly.
