• State Accepted Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 16 replies
  • Subscribers 20 subscribers
  • Views 52159 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Juno r0 does not boot with linaro android after u-boot

seehwan

Hi, 

I am using Juno r0, and want to run android on that. 

So, I tried to work with 1) prebuilt linaro repo, 2) build from source for linaro 16.12.

However, it does not working after u-boot.

In fact, it seems like it stops in the middle of u-boot.

When I stop the boot process in the u-boot, the entire board stops in a few second. 

When it stops, u-boot terminal console does not work, and I cannot give any input to boot command to u-boot.

It seems like I am working with wrong version.

 

Please let me know whether the latest linaro version does not work with Juno r0.

In addition, if it is the case, please let me know which is the correct version I can work with.

 

Regards,

Parents
  • 0 in reply to Mark Nicholson
    Indeed it must work like this.

    Manufacturers provide a version of the kernel that walks with their board, this is an obligation in some countries.

    But often when trying to get out of the way by changing the kernel versions on this boards some corrections must be made.

    I had the experience on several board ... The simple update of the kernel can induce the mistake. This is also what makes linus tovalds in desgrace with ARM boards: D

    I know that the work started on the CMSIS harmonization project is the logical continuation of these embedments.

    Modifications aren't always needed, just recompilation may correct this.
Reply
  • 0 in reply to Mark Nicholson
    Indeed it must work like this.

    Manufacturers provide a version of the kernel that walks with their board, this is an obligation in some countries.

    But often when trying to get out of the way by changing the kernel versions on this boards some corrections must be made.

    I had the experience on several board ... The simple update of the kernel can induce the mistake. This is also what makes linus tovalds in desgrace with ARM boards: D

    I know that the work started on the CMSIS harmonization project is the logical continuation of these embedments.

    Modifications aren't always needed, just recompilation may correct this.
Children
No data