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 over 8 years ago

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 seehwan over 8 years ago in reply to Mark Nicholson

Hi Mark,

I have downloaded prebuilt image using workspace_1612.py script.
It includes Image, juno.dtb, ramdisk, etc. in the SOFTWARE directory.
However, it does not boot. u-boot stops as you seen, it does not search for booting media, nor kernel.

For serial connection concern, what is the correct setting?
Does the kernel/bootloader changes uart setting in the booting procedure?
I'm using static environment 115200,8n1; if it's wrong, please let me know.

For making sure to check whether the board is hung or not, I've waited for tens of seconds. Isn't it enough time to check failure? It does not print out any messages after this
"
U-Boot 2016.11-ge0c62721cc (Dec 15 2016 - 16:52:42 +0000) vexpress_aemv8a, Build: jenkins-armlt-platforms-release-48

DRAM: 8 GiB
PCIe XR3 Host Bridge enabled: x4 link (Gen 2)
Flash: 64 MiB
*** Warning - bad CRC, using default environment

In: serial_pl01x
Out: serial_pl01x
Err: serial_pl01x
Net: smc911x-0
Hit any key to stop autoboot: 0
"

Regards,
Seehwan
Cancel
Vote up 0 Vote down

Cancel

Reply

0 seehwan over 8 years ago in reply to Mark Nicholson

Hi Mark,

I have downloaded prebuilt image using workspace_1612.py script.
It includes Image, juno.dtb, ramdisk, etc. in the SOFTWARE directory.
However, it does not boot. u-boot stops as you seen, it does not search for booting media, nor kernel.

For serial connection concern, what is the correct setting?
Does the kernel/bootloader changes uart setting in the booting procedure?
I'm using static environment 115200,8n1; if it's wrong, please let me know.

For making sure to check whether the board is hung or not, I've waited for tens of seconds. Isn't it enough time to check failure? It does not print out any messages after this
"
U-Boot 2016.11-ge0c62721cc (Dec 15 2016 - 16:52:42 +0000) vexpress_aemv8a, Build: jenkins-armlt-platforms-release-48

DRAM: 8 GiB
PCIe XR3 Host Bridge enabled: x4 link (Gen 2)
Flash: 64 MiB
*** Warning - bad CRC, using default environment

In: serial_pl01x
Out: serial_pl01x
Err: serial_pl01x
Net: smc911x-0
Hit any key to stop autoboot: 0
"

Regards,
Seehwan
Cancel
Vote up 0 Vote down

Cancel

Children

+1 Mark Nicholson over 8 years ago in reply to seehwan

Hi Seehwan,
Serial UART setting are documented in www.community.arm.com/.../using-linaros-deliverables-on-juno (as long as flow control is OFF that looks correct)

Yes even without a USB stick, you should see some moans about the missing ramdisk after the autoboot countdown. This should happen after a couple of seconds.

** You didn't confirm you'd erased the board's flash? **

** Also (if you didn't already) you must erase the whole contents of the MMC card & copy across the entire contents of /juno-lsk-android-uboot (So that's the MB, SITE1, SOFTWARE and the 3 top level text files) not just the SOFTWARE directory - as per instructions. **

But... If neither of these things help, I'm afraid we will need to arrange for you to return the board.

To do this
1. email juno-support@arm.com with a brief summary (essentially reference this Community thread).
2. Fill in & attach this fault form to the email:
infocenter.arm.com/.../ka4138.html

Note we can't do anything to progress a repair without the information in the fault form.
MarkN.
Cancel
Vote up 0 Vote down

Cancel
0 seehwan over 8 years ago in reply to Mark Nicholson

Hi Mark,

Thanks for the comments; but I made sure that the flash, MMC are clean for every trial.

When I boot up the board, I do the followings to make sure that I erase the entire flash.
1) usb_on
2) when the board is attached to host PC, then I delete the entire Juno drive literally clean all the files and directories.
3) flash
4) flash command usually fails; and, re-power the board
5) usb_on
6) when the board is attached to host PC, then I copy all the files into Juno drive from prebuilt directory
7) flash
8) eraseall
9) exit
10) re-power the board, to check whether it works with new binary.

Now, my choice could be one of followings:
-. recompile and booting with new firmware as Jerome suggested
-. return the board with failure description
-. try with (ancient-)old binary

Thankfully, still binary is updated; if I update binary with UEFI-sth, the uboot does not show up, and UEFI shell-like command appears.
However UEFI shell also seems to fail at some moment. It does not take input, and stops to print message at some point.

Before I return the board, I will/want to check for the option 1) and 3).
Is firmware, bootloader source available? How can I get the custom build?
(As far as I remember, there should be some git repo, where I can download.)

Regards,
Seehwan
Cancel
Vote up 0 Vote down

Cancel
0 seehwan over 8 years ago in reply to seehwan

My old binary boots up the board...
What I found for small differences in booting print out messages:

ARM V2M-Juno Boot loader v1.0.0
HBI0262 build 1794

MBbios update in progress DO NOT SWITCH OFF...
Device programmed: 39%
MBbios update complete.

Any idea on this?

Regards,
Seehwan
Cancel
Vote up 0 Vote down

Cancel
0 Mark Nicholson over 8 years ago in reply to seehwan

Hi,
>Is firmware, bootloader source available? How can I get >the custom build?

With each release we may also update the motherboard BIOS code, along with various other elements of proprietary software. So it's expected that the versions vary. This is why it's critical to update the whole contents of the recovery image (as per my last mail) rather than just the SOFTWARE directory. There might be dependencies. We don't release this motherboard code and you shouldn't need it.

>recompile and booting with new firmware as >Jerome suggested

For every release the binaries (and sources) are tested and should work "as is". We know the binaries work as supplied on our Juno r0 (and various others in ARM). Of course it is possible problems are only exposed on specific boards.

Regardless, recompiling with different upstream sources (in this scenario) doesn't seem likely to be profitable unless we know there's a problem to be fixed. But, you are free to try. You can also download the older binaries manually as zip archives if you want to experiment. Simply edit the YY.MM suffix using: releases.linaro.org/.../

It would definitely be interesting to know if there's a point where things start/stop working for you.

>Thankfully, still binary is updated; if I update binary >with UEFI-sth, the uboot does not show up, and UEFI >shell-like command appears.
>However UEFI shell also seems to fail at some >moment. It does not take input, and stops to print >message at some point.

Sorry I'm confused about what exactly you have tried. you wrote:

>My old binary boots up the board...

You mean.. you can boot all the way to a Linux command prompt? (Which release is this binary from)?

>However UEFI shell also seems to fail at >some moment. It does not take input, >and stops to print message at some point.

You mean you tried the 16.12 (UEFI) based binaries & these freeze?

I'll double check with a wider (Juno r0 using) audience internally at ARM to see if anyone else has had similar problems. But, it's likely a return is the only way forward (ARM can provide) if I don't hear anything useful.
Cancel
Vote up 0 Vote down

Cancel
0 Mark Nicholson over 8 years ago in reply to Mark Nicholson

OK. All the folks in ARM with r0 I've spoken to have no issue with 16.12 binaries. It's worth noting that the USB/serial adapters are often unreliable. If you can an adapter with a different chipset (or better) find a PC with a physical serial port it may be worth doing.
Cancel
Vote up 0 Vote down

Cancel
0 seehwan over 8 years ago in reply to Mark Nicholson

Mark,

Thanks for your effort.
Yesterday, I successfully boot up the android, mixing some binaries.

The final result is as follows:
MBbios-1.4.4
SOFTWARE directory is from my old binary.
(Unfortunately, I don't know where exactly it came from. It boots up with UEFI bootmgr, the old binary seems to be oe-minimal boot with UEFI.)
Then, I overwrite the following three files in order to have Android boot up.
-. kernel image, dtb, initrd
I took those files from recent prebuilt binary's SOFTWARE directory;
At the UEFI bootmgr, I set up another entry, fill in kernel bootargs, etc.

My conclusion.
Some of SOFTWARE directory files do not work with my board.
If kernel works with UEFI, I would be okay.
I hope for future kernel-firmware interface does not change.

I have failed when I try with u-boot, so u-boot would not work with me, for now.

Regards,
Seehwan
Cancel
Vote up 0 Vote down

Cancel
0 Mark Nicholson over 8 years ago in reply to seehwan

OK. I'm glad you have something booting, but as we know 16.12 works on multiple r0 boards....Clearly there's something wrong here that's specific to you board/environment. Possibly something operating at the outside edge of tolerances that just happens to be exposed by a change in the SW stack. Possibly something much more mundane, but I'm unable to guess what that would be. It may even be a serial / terminal emulation specific issue. i.e. the board might have booted (and you simply fail to see I/O via serial). You could try plugging a monitor in to check. Impossible to say for sure.

An Android environment that boots with UEFI will be based on deliverables 1 year (ish?) old.

>I hope for future kernel-firmware interface does not change.

Unfortunately we can't guarantee that. Nor can we guarantee that the "mixed" environment you have booting is reliable. Obviously you need to balance the desire to carry on with your work, with the delays involved in a return/repair.
MarkN.
Cancel
Vote up 0 Vote down

Cancel