In November’s image of the 4.3 Beta Android Jelly Bean image, we mentioned that the General Availability (GA) version was close to release, and we promised images.
These images are now on-line:
The first (nitrogen6x) image is bootable on our Nitrogen6x, Nitrogen6x-SOM, or BD-SL-i.MX6 (SABRE Lite) boards and contains kernels for both the OV5640-MIPI and OV5642 parallel cameras with multiple uImage files in the /boot partition.
The second (nit6xlite) image is for our Nitrogen6_Lite board.
As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 4GB SD card image that can be restored using zcat and dd under Linux or Alex Page’s USB Image Tool under Windows.
Sources
The sources for this release are in the boundary-imx_jb4.3_1.0.0-ga branch of our Github repository, and the build steps are otherwise the same as in the second beta release.
Documents
The Freescale documentation for this release are in their release page here.
Let us know how this image works for you.
Our experience has been that there are few differences from the beta, and that both have been solid.
Many thanks to the Freescale teams involved.
I think the paragraph:
“The second (nitrogen6x) image is for our Nitrogen6_Lite board.”
was meant to be:
“The second (nit6xlite) image is for our Nitrogen6_Lite board.”
Thanks Diego. It seems that I have nitrogen6x in muscle-memory…
I see on your Gtihub repository you have an alpha release for kitkat imx, any chance on an ETA for the nitrogen (boundary) release? Thanks.
Hi Marcos,
It’s too early to project a date with certainty, but early indications are good, and I suspect that we’ll have something before the end of February.
I’ve successfully built (not run) this release from sources, but I had a few minor problems:
1. Right at the beginning it tries to build 6x_bootscript, but bootable/bootloader/uboot-imx/tools/mkimage doesn’t exist yet, so the build aborts. I’ve fixed this by building U-Boot for nitrogen6q in bootable/bootloader/uboot-imx manually before building Android.
bootable/bootloader/uboot-imx/tools/mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n “boot script” -d device/boundary/nitrogen6x/6x_bootscript_jb.txt out/target/product/nitrogen6x/boot/6x_bootscript
/bin/bash: bootable/bootloader/uboot-imx/tools/mkimage: No such file or directory
2. Later building the kernel fails:
Kernel: arch/arm/boot/zImage is ready
UIMAGE arch/arm/boot/uImage
“mkimage” command not found – U-Boot images will not be built
I could probably have installed U-Boot-utils, but instead I added bootable/bootloader/uboot-imx/tools to PATH.
Am I doing something wrong here?
Later device/boundary/mksdcard.sh fails with the following error Messages:
——————mounting BOOT, RECOVER, DATA partitions
BLKRRPART: Device or resource busy
This disk is currently in use.
— mounting /dev/sdc1
Cannot find device with major:minor 8:33: No such device
— mounting /dev/sdc2
Cannot find device with major:minor 8:34: No such device
— mounting /dev/sdc4
Cannot find device with major:minor 8:36: No such device
I’ve fixed this by raising the sleep values in the following line (mksdcard.sh):
sync && sleep 1 && sudo sfdisk -R ${diskname}${prefix} && sleep 1
10 seconds didn’t work, so I’m using 60 seconds now. Could be a Problem with by SD Card writer which is hooked to a Linux Guest running on VirtualBox on a Windows host.
The resulting SD Card appears to boot, but there’s no Display on my Monitor and the board keeps going to sleep mode. The prebuilt binaries work fine, btw.
Response to part 1 (mkimage not found)…
I ran across this the other day and haven’t (yet) figured it out.
I certainly caused the problem when I changed bootscript.mk to use the locally-built version of mkimage so customers wouldn’t have to pull in the dependency separately.
If you look at the dependencies on lines 2 and 7, it appears that the $(TARGET_BOOTLOADER_IMAGE) dependency is present.
In English, this says to build U-Boot before building the boot script, but something isn’t working right.
You can work around this in the near term by replacing $(TOPDIR)bootable/bootloader/uboot-imx/tools/mkimage with simply mkimage. You’ll also need to have mkimage installed using apt-get install uboot-mkimage or somesuch.
Extra eyeballs would be appreciated here.
I’m not exactly a make expert…
rm -f out/target/product/nitrogen6x/boot/6x_bootscript
m out/target/product/nitrogen6x/boot/6x_bootscript -d
yields the following
Odd. When the dependency graph for out/target/product/nitrogen6x/boot/6xbootscript is created, TARGET_BOOTLOADER_IMAGE is empty. Yet when the recipe is run it has the correct value (the line where it dumps the value of TARGET_BOOTLOADER_IMAGE is caused by an echo command that I inserted into the recipe).
Looks like this is caused by the make variable type being used (TARGET_BOOTLOADER_IMAGE is a simply expanded variable) in conjunction with the order the makefiles (*.mk and Makefile) are seen by make.
Also I have no idea whether this is related or a different broblem, but on my machine U-Boot is rebuilt every time I run make, even if nothing (as far as I can tell) should be rebuilt at all.
OK…
m out/target/product/nitrogen6x/u-boot.imx
causes U-Boot to be rebuilt, but afterwards, out/target/product/nitrogen6x/u-boot.imx (that is, TARGET_BOOTLOADER_IMAGE) does not exist. Now…
1. The recipe for TARGET_BOOTLOADER_IMAGE cleans, configures and builds U-Boot. It does so 3 times: for nitrogen6q, nitrogen6dl and nitrogen6s.
2. It doesn’t create out/target/product/nitrogen6x/u-boot.imx. Instead it creates u-boot.nitrogen6dl, u-boot.nitrogen6q and u-boot.nitrogen6s in out/target/product/nitrogen6x/boot.
So that’s why U-Boot gets rebuilt every time I run make. It doesn’t explain why it isn’t built before the bootscript is built, though.
If I define TARGET_BOOTLOADER_IMAGE at the top of device/boundary/bootscript.mk rather than somewhere inside build/core/Makefile, then U-Boot gets built before the boot script:
Here’s the relevant output of m -d
Note how make says now also “Considering target file `out/target/product/nitrogen6x/u-boot.imx’.”.
So it’s indeed the variable type and the order makefiles are seen in.
Hi Tom,
I’m still not seeing why this isn’t working, but I think this patch to build/core will make things cleaner:
diff --git a/core/Makefile b/core/Makefile index 520eb0e..b863c59 100644 --- a/core/Makefile +++ b/core/Makefile @@ -742,7 +742,7 @@ ifneq ($(strip $(TARGET_BOOTLOADER_CONFIG)),) BOOTLOADER_CROSS_TOOLCHAIN := `pwd`/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin/arm-eabi- BOOTLOADER_ENV := ARCH=arm CROSS_COMPILE=$(BOOTLOADER_CROSS_TOOLCHAIN) HOST_PROCESSOR := $(shell cat /proc/cpuinfo | grep processor | wc -l) -TARGET_BOOTLOADER_IMAGE := $(PRODUCT_OUT)/u-boot.imx +TARGET_BOOTLOADER_IMAGE := $(PRODUCT_OUT)/System.map BOOTLOADER_PATH := bootable/bootloader/uboot-imx/ BOOTLOADER_CONFIG_FILE := $(BOOTLOADER_PATH)/include/config.h @@ -780,14 +780,17 @@ KERNEL_OUT := $(TARGET_OUT_INTERMEDIATES)/KERNEL_OBJ .PHONY: $(TARGET_PREBUILT_KERNEL) kernelimage: $(TARGET_PREBUILT_KERNEL) +$(TOPDIR)bootable/bootloader/uboot-imx/tools/mkimage: + make -C $(TOPDIR)bootable/bootloader/uboot-imx/ tools + $(KERNEL_CONFIGURE): kernel_imx/arch/arm/configs/$(TARGET_KERNEL_DEFCONF) $(TARGET_KERNEL_CONFIGURE): kernel_imx/arch/arm/configs/$(TARGET_KERNEL_DEFCONF) $(KERNEL_CONFIGURE) $(MAKE) -C kernel_imx $(TARGET_KERNEL_DEFCONF) $(KERNEL_ENV) install -D $(KERNEL_CONFIGURE) $(TARGET_KERNEL_CONFIGURE) -$(TARGET_PREBUILT_KERNEL): $(TARGET_KERNEL_CONFIGURE) - $(MAKE) -C kernel_imx -j$(HOST_PROCESSOR) uImage $(KERNEL_ENV) +$(TARGET_PREBUILT_KERNEL): $(TARGET_KERNEL_CONFIGURE) $(TOPDIR)bootable/bootloader/uboot-imx/tools/mkimage + PATH=$(PATH):$(TOPDIR)bootable/bootloader/uboot-imx/tools/ $(MAKE) -C kernel_imx -j$(HOST_PROCESSOR) uImage $(KERNEL_ENV) install -D $(KERNEL_UIMAGE) $(PRODUCT_OUT)/uImage install -D $(KERNEL_ZIMAGE) $(PRODUCT_OUT)/kernelIn English, this sets the boot loader dependency to a file that will be built and won’t get re-named (System.map). This is a bit of a kludge, because as you pointed out, we’re faking the U-Boot build to create binaries for multiple platforms without properly expressing how to build each.
This patch also creates a rule for building the mkimage program directly, and uses it as the dependency for building the kernel.
I’m doing a clean build now to test, but I think this will help. If so, then a companion patch to device/boundary/bootscript.mk can use the mkimage target as a dependency before building the boot scripts (instead of the pseudo-target of TARGET_BOOTLOADER_IMAGE.
Hi Eric,
sounds good.
Regarding while the original implementation didn’t work: it’s really due to the fact that the rule for 6x_buildscript is seen by make before TARGET_BOOTLOADER_IMAGE is assigned. This can be seen by analyzing the output of
make -d. The ouput from the -d switch includes information on which makefiles are scanned in which order.The following makefile reproduces the problem:
bootscript.out: bootscript.in $(TARGET_BOOTLOADER_IMAGE) @echo "TARGET_BOOTLOADER_IMAGE=$(TARGET_BOOTLOADER_IMAGE)" touch $@ bootscript.in: touch $@ TARGET_BOOTLOADER_IMAGE := target_bootloader_image $(TARGET_BOOTLOADER_IMAGE): @echo "Building $(TARGET_BOOTLOADER_IMAGE)" touch $@ .PHONY: clean clean: rm -f bootscript.out rm -f bootscript.in rm -f $(TARGET_BOOTLOADER_IMAGE)bootscript.in is the only dependency of bootscript.out, since TARGET_BOOTLOADER_IMAGE is not yet defined when make sees the rule. Note how the echo statement still prints the proper value. This is because variable substitution inside recipe commands isn’t done until the recipe is executed. Obviously at this point the entire makefile has been scanned and TARGET_BOOTLOADER_IMAGE is defined.
If you move the definition of TARGET_BOOTLOADER_IMAGE to the top of the file, everything works as desired.
Thanks Tom,
That clarifies things.
BTW, I pushed some patches to build/core/Makefile and device/boundary/ to address the issue.
The patches create a proper build target for the uboot-imx/tools/mkimage binary and the use it as a dependency rather than using the pseudo-target TARGET_BOOTLOADER_IMAGE.
Response to the first part of part 2 (missing mkimage again).
It seems that I didn’t even get rid of the need to install mkimage…
Use apt-get install uboot-mkimage or apt-get install u-boot-tools to pull in this tool, depending on your build system version.
Response to second part of part 2 (problems with mksdcard.sh).
This script is littered with timing issues that stem from the asynchronous nature of device and partition enumeration. Different machines (esp. virtual machines) will take varying amounts of time to properly enumerate the devices.
I have spent a bit of time looking at how some others (like Linaro) do this, and haven’t yet found a reasonable solution.
Linaro’s linaro-media-create tool, for instance, uses some dbus commands several levels deep in Python to disable auto-mounting entirely. Unfortunately, they didn’t work for me on an Ubuntu Raring machine.
If I don’t find something soon, I’ll likely switch to using a fake SD card and mount things using losetup and the like. That’s much more cumbersome to work with though, and I’ll need to pre-define the DATA partition size.
Here again, we’re open to suggestions.
is there nfs boot support well like ICS.
has anyone tried booting this by NFS on imx6q sabrelite ?
There isn’t any out-of-the-box support for NFS, but you can achieve this by extracting the layers:
You’ll likely need to preserve UIDs in the process, since JB is finicky about such things.
When in doubt, logcat, logcat, logcat.
I extracted the jb4.3-ga-nitrogen6x-20131219.img.gz to my sd card and I get the following on the sabre-lite:
mmc0 is current device
** No partition table – mmc 0 **
** No partition table – mmc 0 **
MMC: no card present
mmc1(part 0) is current device
MMC: no card present
** Bad device mmc 1 **
MMC: no card present
** Bad device mmc 1 **
6x_bootscript not found
serial console at 115200, 8N1
details at http://boundarydevice.wpengine.com/6q_bootscript
My uboot is:
U-Boot 2013.01-rc1-00130-g1e88922 (Feb 11 2013 – 13:46:35)
Should I be updating the uboot? I checked and the 6x_bootscript is there. Note, I ran the raring image using this uboot so I’m pretty sure uboot is not an issue. Please advise.
I figured this out. Had to use the mmc1 (smaller sd card slot). However a related problem remains. I still get the above error after copying a new kernel + modules to the raring image. I’ve done this twice and both times I get this:
** Unable to read file /boot/uImage **
Error loading kernel image
6x_bootscript not found
serial console at 115200, 8N1
details at http://boundarydevice.wpengine.com/6q_bootscript
Partition Map for MMC device 1 — Partition Type: DOS
Part Start Sector Num Sectors UUID Type
1 2048 7370752 000d4ba9-01 83
U-Boot >
If I dd a fresh raring image, I don’t get the above error.
I flashed in the image (nitrogen6x) and could boot successfully on the BD-SL-i.MX6. I have see that this image only contains kernels for both the OV5640-MIPI and OV5642 parallel cameras. I need to have access to a USB camera. Can someone guide my to the required steps to support USB camera? Do I need to rebuild from source? Is there a userguide to support USB webcam (Logitech C250) somewhere?
I can not get the jb4.3-ga-nitrogen6x-20131219.img.gz image to boot from sd card on SabreLite board. I used zcat and dd to get the image on the card, but nothing happens when I power on the board. There is no signal being sent through hdmi to the display.
Can you post the output from Power-on to kernel load from the serial console (115200,8,N,1)?
If the kernel loads, can you also post the line that says “Kernel command-line”?
Nothing is posting to the serial console. Once the image is placed on the sd card, is there more that needs to be done or should it just boot on power?
Since we boot from SPI-NOR (serial EEPROMYou should get something on the serial console, even without an SD card present.
Since we boot from SPI-NOR (serial EEPROM), you should get something on the serial console, even without an SD card present.
Have you flashed this board with an over-ride of U-Boot’s normal boot process?
No reflash on this board. All I’ve done is plug in the “bootable” image card. I’ve tried with the demo card, the bootable card, and with no card at all. The demo card boots and displays properly, but nothing is showing on the serial console. Perhaps I don’t have something set up properly. I’m still pretty new to this.
Hi Stone,
If the other image boots, then it’s like that something has gone wrong with your serial cable or connection.
What happens if you hit <enter> in your terminal emulator?
Do you by chance have another instance of the terminal emulator running that might be receiving the data (I ask because I’ve done that).
No other instances of the terminal running. Nothing happens when I hit <enter>. I’ve ordered a preloaded android card. Once it arrives I’ll see if the result changes.
No luck with the preloaded jellybean card. Only the demo will boot. Not sure what to do with this board now.
Hi Stone,
Can you post the output of the ‘printenv’ command from the U-Boot prompt?
Can you also post the output of a boot with no SD card present?
This may help us assess the situation.
I realized the board I was using was an E14 board and not a BD board. I have since purchased a Nitrogen6x board and the android image boots perfectly.
Now I am trying to configure the display. It is a 1080, 10-pt multi-touch monitor. Everything displays properly but the touch input is not. It will only recognize when all 10 fingers are placed on the screen and will not recognize anything less. The pointer tracks properly with a usb mouse. Where do I find the setup for the touch interface and how do I make it recognize single touches? This same display works perfectly when connected to my Ubuntu laptop.
Thanks!
Hi Stone,
First off, thanks for your support.
In general, you need two things to get a touch screen working under Android:
The second is usually trivially easy, and involves matching the name of the device to the name of the driver in /proc/bus/input/devices.
It’s doubtful that we’ve included support for your touch screen in the kernel configuration. If you search in kernel_imx/drivers/input/touchscreen and kernel_imx/drivers/hid for the VID/PID of the USB device, you can determine whether driver sources are present.
Does this current driver utilize code similar to:
#define MAX_USING_FINGER_NUM 2
and if so, could you use the process described at:
http://forum.xda-developers.com/showthread.php?t=891030
If I am building JB Android for the Sabre Lite do I need to do anything other than build for a nitrogen6x target?
The build I have at the moment semi works but the board reboots from time to time and seems sluggish when compared to a build I have running on a Sabresd (created from the Freescale bsp).
The simptoms are similar to earlier messages so :- The sabre lite is a new board with V1.2 silicon and there is little reported cpu activity. Reboots seem to happen if left inactive. Video out is 1080p via HDMI and the onboard temp is returning ~50 deg. Processer feels hotter to the touch than the sabresd board.
There’s only a single build target (named nitrogen6x) for both SABRE Lite and Nitrogen because our kernels auto-detect the differences.
Both of these will naturally run a bit hotter (~10C under load) than a SABRE SD because neither one has an external PMIC and use the on-chip LDOs for voltage and frequency scaling.
There shouldn’t be any difference in performance if using the same type of media (SD card), though the performance of the eMMC on SABRE SD than on either of those two boards of ours, and neither one should reboot.
Can you grab the output from the serial port at the time of re-boot?
Thanks for the clarification.
My random crashing problem has disappeared, either due to upgrading uboot to the prebuilt V2014 or because I did a clean rebuild of the kernel. This also fixed my performance issue.
I have not tried my own uboot source build yet as extracted by repo sync but presumably it is the latest?
One last question the “penguin” logo was removed from uboot 2014 and I have a bootloaderanimation. So where do the “four penguin” logos come from between uboot and bootloaderanimation?
I’m glad to hear that things are working better for you with the latest U-Boot. The last update related to crashes was in ~2/2013 for 1GiB boards.
The U-Boot built in the Android tree will include some updates not in the 2014-01 release, but most of those are for added peripherals (displays, touch screens), so they probably won’t affect you.
The U-Boot penguin was removed a while back because of a request from our friends at QNX.
The penguin logo (x4) between U-Boot and Android animation comes from the kernel startup. You can edit kernel_imx/arch/arm/configs/nitrogen6x_defconfig and remove CONFIG_LOGO if you want to remove them.
Thanks that worked perfectly.
One last question (honest!). On first (clean) boot everything works fine with the exception that the network never receives a DHCP address. I can live with that but on a second boot there is an “Inconsistant System UID” error message prompt to the effect that continuing may cause an unstable system.
Checking /data/system/uiderrors.txt points to a mismatch in the uid of “com.android.browser” which is set to 10003 on disk and 10005 in settings.
I’m not sure what is causing this.
A web search suggested creating my own security certificates would fix it but it does not.
I have removed a number of packages, added my own and modified init.rc. I have tried backing out the changes and verified the reversal using “repo diff” but I still suffer from this issue.
Any thoughts?
My System UID issue was due to adding new packages which caused ‘com.android.browser’ to get a new UID compaired to a default install.
This in inself is not a problem but a section of the init.rc script deals with mounting a tmp ramfs for use as the browser cache and this code assumes the browser always has a preset UID. It changes the /data/data/com.android.browser to it on boot in my case to the wrong UID.
For now I can update the chown command in the init.rc scrip to my new value. But I will have a look at re-writting this section of the init script over the next few days.
That’s exactly right. We haven’t figured out a way to read the UID for com.android.browser so this line of init.rc could be wrong as packages are added.
It works properly with HDMI monitor connected, but when HDMI is not connected the board reboots continuosly with following error in logcat :
01-01 00:13:06.250 W/InterfaceController( 2400): Warning (dlopen failed: library “/system/lib/libnetcmdiface.so” not found) while opening the y
01-01 00:13:08.510 I/SurfaceFlinger( 2402): SurfaceFlinger is starting
01-01 00:13:08.520 I/SurfaceFlinger( 2402): SurfaceFlinger’s main thread ready to run. Initializing graphics H/W…
01-01 00:13:09.060 D/libEGL ( 2402): loaded /system/lib/egl/libEGL_VIVANTE.so
01-01 00:13:09.510 E/uim-sysfs( 2465): uim: Inside main
01-01 00:13:09.510 E/uim-sysfs( 2465): uim:BT/FM/GPS would be unavailable on system
01-01 00:13:09.780 D/libEGL ( 2402): loaded /system/lib/egl/libGLESv1_CM_VIVANTE.so
01-01 00:13:10.650 D/libEGL ( 2402): loaded /system/lib/egl/libGLESv2_VIVANTE.so
01-01 00:13:11.810 E/imx6.gralloc( 2402): open /dev/fb0 failed
01-01 00:13:11.830 F/libc ( 2402): Fatal signal 11 (SIGSEGV) at 0x0000000c (code=1), thread 2457 (SurfaceFlinger)
01-01 00:13:11.980 I/DEBUG ( 2401): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-01 00:13:11.980 I/DEBUG ( 2401): Build fingerprint: ‘boundary/nitrogen6x/nitrogen6x:4.3/4.3_1.0.0-ga/eng.harsh.20141111.224727:eng/dev-ke’
01-01 00:13:11.980 I/DEBUG ( 2401): Revision: ‘405522’
01-01 00:13:11.990 I/DEBUG ( 2401): pid: 2402, tid: 2457, name: SurfaceFlinger >>> /system/bin/surfaceflinger <<<
01-01 00:13:11.990 I/DEBUG ( 2401): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0000000c
01-01 00:13:12.400 I/DEBUG ( 2401): r0 00000000 r1 00000000 r2 00000001 r3 00000001
01-01 00:13:12.400 I/DEBUG ( 2401): r4 40f11390 r5 400a2004 r6 400a20c0 r7 fffffffe
01-01 00:13:12.400 I/DEBUG ( 2401): r8 40f10da4 r9 402101f4 sl 405ddf00 fp 40f107a8
01-01 00:13:12.400 I/DEBUG ( 2401): ip 00000001 sp 405ddd18 lr 400a0457 pc 400a04be cpsr 200f0030
01-01 00:13:12.420 I/DEBUG ( 2401): d0 0000000000000000 d1 0000000000000000
01-01 00:13:12.420 I/DEBUG ( 2401): d2 0000000000000000 d3 0000000000000000
01-01 00:13:12.420 I/DEBUG ( 2401): d4 0000020000000100 d5 0000100000000000
01-01 00:13:12.420 I/DEBUG ( 2401): d6 0000010000001800 d7 0000000000000100
01-01 00:13:12.420 I/DEBUG ( 2401): d8 0000000000000000 d9 0000000000000000
01-01 00:13:12.420 I/DEBUG ( 2401): d10 0000000000000000 d11 0000000000000000
01-01 00:13:12.420 I/DEBUG ( 2401): d12 0000000000000000 d13 0000000000000000
01-01 00:13:12.420 I/DEBUG ( 2401): d14 0000000000000000 d15 0000000000000000
01-01 00:13:12.420 I/DEBUG ( 2401): d16 4024511940245015 d17 0000000100000001