IMX6 SabreLite: same sdcard on different board gives different bootup?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IMX6 SabreLite: same sdcard on different board gives different bootup?

Jump to solution
1,171 Views
motting
Contributor I

I have found a strange problem on IMX6 SabreLite from Boundary Device.

I created my own linux 3.0.35 platform with a camera driver OV5640 enabled on an micro-sdcard.

On start up, my platform would check the presence of OV5640 camera and show a message.

My colleague who is working on OV8820 on another IMX6 SabreLite board.

When I put my micro-sdcard into my colleague's board, it shows me "OV8820 is not found" instead of OV5640.

I have not even built OV8820 driver into my micro-sdcard.

We both did not change the u-Boot in SPI flash, it is U-Boot 2015.07-15072-g45cfc85 (Jan 28 2016 - 17:41:49 -0700), Build: jenkins-uboot_v2015.07-30.

It looks like some contents of my colleague's project is burnt into his board and mix up with my project.

I am pretty sure our board is booting up on micro-sdcard (mmc1) because without my card the system does not boot.

This will cause a huge problem because I cannot even know whether any new problem is due my project or the mix-up of two project.

Can any body knows how to solve this project mix-up issue and how I can confirm the project is purely mine?

Labels (3)
0 Kudos
1 Solution
773 Views
gary_bisson
Senior Contributor III

Hi,

Do you have the same U-Boot environment (where the U-Boot variables are saved)?

Can you please try:

=> env default -a

=> boot

Does it help? Are you both using the same 3.0.35 kernel? Is there any reference of the OV8820 in the board file although the driver doesn't exist? (like in the registered I2C devices)

Regards,

Gary

View solution in original post

0 Kudos
6 Replies
773 Views
igorpadykov
NXP Employee
NXP Employee

do both sensors have the same address, then OV5640 camera

driver could find OV8820 and throw that message.

Best regards

igor

0 Kudos
773 Views
motting
Contributor I

Hi Igor,

They both have the same address (0x20).

But the driver of OV8820 was not even built into my project.

The message "OV8820 is not found" is a constant string instead of something like ("%s is not found", your_camera).

Motti

0 Kudos
774 Views
gary_bisson
Senior Contributor III

Hi,

Do you have the same U-Boot environment (where the U-Boot variables are saved)?

Can you please try:

=> env default -a

=> boot

Does it help? Are you both using the same 3.0.35 kernel? Is there any reference of the OV8820 in the board file although the driver doesn't exist? (like in the registered I2C devices)

Regards,

Gary

0 Kudos
773 Views
motting
Contributor I

Hi Gary,

Yes, we are using the same 3.0.35 kernel.

There is no reference of the OV8820 in the board file.

I am not sure if my colleague have the same environment but the env default -a command does help.

I can now boot up my kernel on my colleague's board.

I am wondering why u-boot environment can cause such a difference.

In my colleague's u-boot environment, I can see his custom module being loaded into the kernel (through lsmod).

There is no way his modules appear in my micro-sdcard out of nowhere.

On the other side, it does not seem possible that his modules was hiding in the u-boot environment.

What could have make this happen?

Motti

0 Kudos
773 Views
gary_bisson
Senior Contributor III

Hi Motti,

No the modules cannot be in the U-Boot env. What I suspect though is that the env was specifying another uImage file, different from yours, which tries to load the OV8820 camera.

Are you sure it was your kernel booted up when the camera issue appeared? If you check the first line of the dmesg output you'll see when it has been built and on which machine. Is there only one sdcard plugged into the board? No SATA nor USB drive?

Regards,

Gary

0 Kudos
773 Views
motting
Contributor I

Without my card, the system did not boot.

This was why I thought I booted up my kernel.

I checked the log for the first line of dmesg you have mentioned, it was found that the kernel booted-up was NOT MINE!

However, I am 100% sure there is no other boot device inserted to our boards.

I think the only possible solution is that his kernel was somehow written into SPI flash.

0 Kudos