pi0w won't boot, but pi3 works on linux-4.12-rc1 #2028

jeffersonchua · 2017-05-20T11:29:46Z

I'm having problem with latest kernel 4.12-rc1 trying to make it work on pi-zero-w. I compiled kernel for pi3 and works fine. Have not tried earlier versions .. perhaps it won't work either.

I used crosstool-ng-1.23.0 and build a crosstool-chain for bcm2708 for pi-zero-w and a different one for pi3. The only differences in the toolchain are:

pi0 ...

CT_PREFIX_DIR="/v5/cross-bcm2708"
CT_ARCH_CPU="arm1176jzf-s"
CT_ARCH_FPU="vfp"

pi3 ...

CT_PREFIX_DIR="/v5/cross-bcm2709"
CT_ARCH_ARCH="armv7-a"
CT_ARCH_CPU=""
CT_ARCH_TUNE="cortex-a7"
CT_ARCH_FPU="neon-vfpv4"

And in my linux kernel .config, I selected ARCH_MULTI_V7 for pi3, and ARCH_MULTI_V6 for pi0w.

I even tried with bcm2835_defconfig and bcmrpi_defconfig without success.

And I used firmware from git://github.com/raspberrypi/firmware.git for both pi0w and pi3 ...

My .config for linux-4.12-rc1 attached for both pi0w and pi3 ...
pi0w.config.txt
pi3.config.txt

My pi boot config.txt files for both pi0w and pi3 attached ...
pi0w.boot.config.txt
pi3.boot.config.txt

Again, the compiled kernel7.img (using bcm2709 toolchain) works for pi4, but kernel.img (using bcm2708 tooldchain) not for pi0w.

What am I missing?

Thanks,
Jeff

pelwell · 2017-05-20T15:47:52Z

Here are a few things to try:

Make sure you have the latest rpi-4.12.y - the rate of change is quite high.
Download our hardfp toolchain from the tools repo (https://github.com/raspberrypi/tools/tree/master/arm-bcm2708) and build your kernel config with that.
If 2 doesn't work, try with bcmrpi_defconfig.
If 2 does produce a workable kernel, compare your Crosstools configurations with ours: https://github.com/raspberrypi/tools/tree/master/configs

lategoodbye · 2017-05-20T21:58:15Z

Your error description is too general. What makes you sure that it doesn't boot (e.g. no output on serial / HDMI port)?

jeffersonchua · 2017-05-21T09:12:09Z

On Sun, May 21, 2017 at 5:58 AM, Stefan Wahren ***@***.***> wrote: Your error description is too general. What makes you sure that it doesn't boot (e.g. no output on serial / HDMI port)?

I see only one "underscore" on the HDMI output to a Sony screen. Thanks, Jeff

lategoodbye · 2017-05-21T10:01:16Z

So you don't have a USB to serial adapter?
What's the behavior of the ACT LED?

jeffersonchua · 2017-05-21T15:05:56Z

On Sun, May 21, 2017 at 6:01 PM, Stefan Wahren ***@***.***> wrote: So you don't a USB to serial adapter?

No.

What't the behavior of the ACT LED?

Blinking. Thanks, Jeff

…

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2028 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/APcav20sz1LdQKYVpcaDYKgKDzU4ap5Bks5r8At1gaJpZM4NhRYl> .

pelwell · 2017-05-21T15:10:49Z

Is it blinking in a rhythm - n long, m short ?

Don't forget my suggestions above.

jeffersonchua · 2017-05-21T15:11:05Z

On Sat, May 20, 2017 at 11:48 PM, Phil Elwell ***@***.***> wrote: Here are a few things to try: 1. Make sure you have the latest rpi-4.12.y - the rate of change is quite high. 2. Download our hardfp toolchain from the tools repo ( https://github.com/raspberrypi/tools/tree/master/arm-bcm2708 <https://github.com/raspberrypi/tools/tree/master/arm-bcm2708>) and build your kernel config with that. 3. If 2 doesn't work, try with bcmrpi_defconfig. 4. If 2 does produce a workable kernel, compare your Crosstools configurations with ours: https://github.com/ raspberrypi/tools/tree/master/configs <https://github.com/raspberrypi/tools/tree/master/configs>

Trying to compile but encountered this error ... arm-bcm2708hardfp-linux-gnueabi/bin/as: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory So now trying to compile toolchain using bcm2708hardfp-ct-ng.config Thanks, Jeff.

jeffersonchua · 2017-05-21T15:13:16Z

On Sun, May 21, 2017 at 11:11 PM, Phil Elwell ***@***.***> wrote: Is it blinking in a rhythm - long, short ?

Phil, Looks like it's doing that.

Don't forget my suggestions above.

Trying to do that, but that will take a while ... trying to compile the toolchain as I'm mssing libz.so so can't use the compiled one. :( Thanks, Jeff

pelwell · 2017-05-21T15:15:40Z

Sorry - markdown mangled my comment which should have said <n> long, <m> short. What are n and m?

jeffersonchua · 2017-05-21T15:19:56Z

On Sun, May 21, 2017 at 11:15 PM, Phil Elwell ***@***.***> wrote: Sorry - markdown mangled my comment which should have said <n> long, <m> short. What are n and m?

Phil, Power on -> blink-blink, then stay lighted (not blinking). Jeff

jeffersonchua · 2017-05-21T15:30:37Z

On Sun, May 21, 2017 at 11:11 PM, Jeff Chua ***@***.***> wrote: On Sat, May 20, 2017 at 11:48 PM, Phil Elwell ***@***.***> wrote: > > Here are a few things to try: > > Make sure you have the latest rpi-4.12.y - the rate of change is quite > high. > Download our hardfp toolchain from the tools repo > (https://github.com/raspberrypi/tools/tree/master/arm-bcm2708) and build > your kernel config with that. > If 2 doesn't work, try with bcmrpi_defconfig. > If 2 does produce a workable kernel, compare your Crosstools > configurations with ours: > https://github.com/raspberrypi/tools/tree/master/configs Trying to compile but encountered this error ... arm-bcm2708hardfp-linux-gnueabi/bin/as: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory So now trying to compile toolchain using bcm2708hardfp-ct-ng.config

Error compiling .. [CFG ] checking for broken __attribute__((alias()))... yes [INFO ] Building for multilib 1/1: '' [ERROR] configure: error: working alias attribute support required I could compile using my config but not bcm2708hardfp-ct-ng.config The only differences are as follows ... # diff my-config bcm2708hardfp-ct-ng.config 78c78 < CT_PARALLEL_JOBS=10 ---

CT_PARALLEL_JOBS=0

169c169 < CT_ARCH_FPU="vfp" ---

CT_ARCH_FPU=""

184c184 < CT_ARCH_ARM_INTERWORKING=y ---

# CT_ARCH_ARM_INTERWORKING is not set

187c187 < # CT_ARCH_ARM_TUPLE_USE_EABIHF is not set ---

CT_ARCH_ARM_TUPLE_USE_EABIHF=y

209c209 < CT_TARGET_VENDOR="" ---

CT_TARGET_VENDOR="bcm2708hardfp"

211c211 < CT_TARGET_ALIAS="arm-linux-gnueabihf" ---

CT_TARGET_ALIAS="bcm2708hardfp"

353c353 < CT_LIBC_GLIBC_EXTRA_CFLAGS="" ---

CT_LIBC_GLIBC_EXTRA_CFLAGS="-march=armv6z -mtune=arm1176jzf-s -mfloat-abi=hard"

390c390 < CT_CC_GCC_EXTRA_CONFIG_ARRAY="--with-float=hard" ---

CT_CC_GCC_EXTRA_CONFIG_ARRAY=""

Jeff

popcornmix · 2017-05-22T13:33:14Z

You should be building with this (which is what official kernel releases use):
https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin

jeffersonchua · 2017-05-22T17:36:56Z

On Mon, May 22, 2017 at 9:33 PM, popcornmix ***@***.***> wrote: You should be building with this: https://github.com/raspberrypi/tools/tree/master/ arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin

Ok, this seems to be compiling ... once compiled .. I'll test and report back. Thanks, Jeff.

jeffersonchua · 2017-05-22T18:19:15Z

On Tue, May 23, 2017 at 1:36 AM, Jeff Chua ***@***.***> wrote: On Mon, May 22, 2017 at 9:33 PM, popcornmix ***@***.***> wrote: > > You should be building with this: > > https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin Ok, this seems to be compiling ... once compiled .. I'll test and report back.

It compiled ok, but booted up to the same "underscore". So, now, I'm going to test with bcm2835_defconfig. Jeff

jeffersonchua · 2017-05-24T05:59:56Z

On Tue, May 23, 2017 at 2:18 AM, Jeff Chua ***@***.***> wrote: On Tue, May 23, 2017 at 1:36 AM, Jeff Chua ***@***.***> wrote: > On Mon, May 22, 2017 at 9:33 PM, popcornmix ***@***.***> > wrote: >> >> You should be building with this: >> >> https://github.com/raspberrypi/tools/tree/master/arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin > > Ok, this seems to be compiling ... once compiled .. I'll test and report > back. It compiled ok, but booted up to the same "underscore". So, now, I'm going to test with bcm2835_defconfig.

Tried both bcm2835_defconfigbcmrpi_defconfig and both display "underscore". The only thing displayed is the Bootup Logo. I've "device_tree=bcm2708-rpi-0-w.dtb" in /boot/config.txt ... is this correct? My config.txt below: device_tree=bcm2708-rpi-0-w.dtb start_debug=1 start_x=1 gpu_mem=128 disable_splash=1 disable_l2cache=1 dispmanx_offline=1 avoid_warnings=2 dtparam=audio=on hdmi_drive=2 disable_overscan=0 overscan_left=-48 overscan_right=-48 overscan_top=-52 overscan_bottom=-43 Thanks, Jeff

pelwell · 2017-05-24T08:53:36Z

What is in cmdline.txt?

If you have a spare uSD card you can:

Install a fresh Raspbian, and check it boots OK.
Copy your new kernel and modules over and see if that boots. If you give your alternate kernel a different name you can select it using kernel=<whatever> in config.txt.
If your kernel works on Raspbian then there is an issue with your distribution (which I suspect isn't Raspbian).

As a general comment, you shouldn't need to explicitly set device_tree= - the firmware will load the correct one unless you are trying 64-bit builds on a Pi3 or otherwise using non-standard DTB names.

jeffersonchua · 2017-05-24T14:50:25Z

On Wed, May 24, 2017 at 4:53 PM, Phil Elwell ***@***.***> wrote: What is in cmdline.txt?

dwc_otg.lpm_enable=0 console=tty1 consoleblank=0 root=/dev/mmcblk0p2 quiet rootwait elevator=noop sdhci-bcm2708.sync_after_dma=0 ro As a general comment, you shouldn't need to explicitly set device_tree= -

the firmware will load the correct one unless you are trying 64-bit builds on a Pi3 or otherwise using non-standard DTB names.

It's interesting. After commenting out device_tree=bcm2708-rpi-0-w.dtb, the system boots up! But this shouldn't prevent it from bootup by specifying 'device_tree=bcm2708-rpi-0-w.dtb' ... So my toolchain are ok, it's just this line is causing the issue. Why? Thanks, Jeff

pelwell · 2017-05-24T14:55:15Z

What does sudo vcdbg log msg |& grep dtb return?

jeffersonchua · 2017-05-24T16:13:00Z

On Wed, May 24, 2017 at 10:55 PM, Phil Elwell ***@***.***> wrote: What does sudo vcdbg log msg |& grep dtb return

002088.148: Loading 'bcm2708-rpi-0-w.dtb' to 0x2650fc size 0x54af Thanks, Jeff

jeffersonchua · 2017-05-24T16:17:26Z

On Thu, May 25, 2017 at 12:12 AM, Jeff Chua ***@***.***> wrote: On Wed, May 24, 2017 at 10:55 PM, Phil Elwell ***@***.***> wrote: > > What does sudo vcdbg log msg |& grep dtb return 002088.148: Loading 'bcm2708-rpi-0-w.dtb' to 0x2650fc size 0x54af

I'm seeing this ... 002081.122: Loading 'kernel.img' to 0x8000 size 0x25d0fc 002084.819: Kernel trailer DTOK property says yes 002084.835: Kernel trailer DDTK property says yes 002088.148: Loading 'bcm2708-rpi-0-w.dtb' to 0x2650fc size 0x54af 003282.644: dterror: out of memory 003314.399: Device tree loaded to 0x1bfea700 (size 0x58e0) Thanks, Jeff

pelwell · 2017-05-24T16:25:52Z

That's odd, because the firmware appears to be loading the same dtb as the one you explicitly asked it to use. And I've never seen an "out of memory" dterror before. You could turn on some extra tracing by adding dtdebug=1 to config.txt.

pelwell · 2017-05-24T16:30:55Z

You could also remove start_debug=1, which will stop it loading start_db.elf instead of start_x.elf.

jeffersonchua · 2017-05-24T17:06:29Z

On Thu, May 25, 2017 at 12:31 AM, Phil Elwell ***@***.***> wrote: You could also remove start_debug=1, which will stop it loading start_db.elf instead of start_x.elf.

Removed start_debug=1, but still same message ... 001654.527: Read command line from file 'cmdline.txt' dwc_otg.lpm_enable=0 console=tty1 consoleblank=0 root=/dev/mmcblk0p2 quiet rootwait elevator=noop sdhci-bcm2708.sync_after_dma=0 ro pi0w 001821.955: Loading 'kernel.img' to 0x8000 size 0x25d0fc 001825.643: Kernel trailer DTOK property says yes 001825.658: Kernel trailer DDTK property says yes 001828.936: Loading 'bcm2708-rpi-0-w.dtb' to 0x2650fc size 0x54af 003027.566: dterror: out of memory 003059.386: Device tree loaded to 0x1bfea700 (size 0x58e0) 003060.774: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined 006280.176: vchiq_core: vchiq_init_state: slot_zero = 0x5b580000, is_master = 1 Thanks, Jeff

jeffersonchua · 2017-05-24T17:09:30Z

On Mon, May 22, 2017 at 9:33 PM, popcornmix ***@***.***> wrote: You should be building with this: https://github.com/raspberrypi/tools/tree/master/ arm-bcm2708/arm-rpi-4.9.3-linux-gnueabihf/bin

Turn out it's something to do with the line 'device_tree=bcm2708-rpi-0-w.dtb' because after removing the line, it boots fine. Could be something else I'm not doing right ... still debugging. Thanks, Jeff

popcornmix · 2017-05-24T17:12:03Z

What does sudo vcdbg log msg |& grep dtb report when it works?

jeffersonchua · 2017-05-24T17:59:10Z

On Thu, May 25, 2017 at 1:12 AM, popcornmix ***@***.***> wrote: What does sudo vcdbg log msg |& grep dtb report when it works?

Mine shows this ... but I don't think this is not work ... 001753.598: Loading 'kernel.img' to 0x8000 size 0x25d0fc 001757.284: Kernel trailer DTOK property says yes 001757.298: Kernel trailer DDTK property says yes 001760.576: Loading 'bcm2708-rpi-0-w.dtb' to 0x2650fc size 0x54af 002964.862: dterror: out of memory 002996.682: Device tree loaded to 0x1bfea700 (size 0x58e0) wireless and bluetooth both working, so I don't know what's wrong. Jeff

jeffersonchua · 2017-05-25T05:35:04Z

On Thu, May 25, 2017 at 1:59 AM, Jeff Chua ***@***.***> wrote: On Thu, May 25, 2017 at 1:12 AM, popcornmix ***@***.***> wrote: > > What does sudo vcdbg log msg |& grep dtb report when it works? Mine shows this ... but I don't think this is not work ... 001753.598: Loading 'kernel.img' to 0x8000 size 0x25d0fc 001757.284: Kernel trailer DTOK property says yes 001757.298: Kernel trailer DDTK property says yes 001760.576: Loading 'bcm2708-rpi-0-w.dtb' to 0x2650fc size 0x54af 002964.862: dterror: out of memory 002996.682: Device tree loaded to 0x1bfea700 (size 0x58e0)

Here's from working 4.9.29+ kernel ... 002102.364: Loading 'bcm2708-rpi-0-w.dtb' to 0x434d78 size 0x3d2c I'll try to recompile based on working .confg to see what's the differences. Jeff

jeffersonchua · 2017-05-25T12:17:25Z

On Thu, May 25, 2017 at 1:35 PM, Jeff Chua ***@***.***> wrote: On Thu, May 25, 2017 at 1:59 AM, Jeff Chua ***@***.***> wrote: > On Thu, May 25, 2017 at 1:12 AM, popcornmix ***@***.***> > wrote: >> >> What does sudo vcdbg log msg |& grep dtb report when it works? > > Mine shows this ... but I don't think this is not work ... > > 001753.598: Loading 'kernel.img' to 0x8000 size 0x25d0fc > 001757.284: Kernel trailer DTOK property says yes > 001757.298: Kernel trailer DDTK property says yes > 001760.576: Loading 'bcm2708-rpi-0-w.dtb' to 0x2650fc size 0x54af > 002964.862: dterror: out of memory > 002996.682: Device tree loaded to 0x1bfea700 (size 0x58e0) Here's from working 4.9.29+ kernel ... 002102.364: Loading 'bcm2708-rpi-0-w.dtb' to 0x434d78 size 0x3d2c I'll try to recompile based on working .confg to see what's the differences.

Still working on the kernel compile. But, just want to share that with the working kernel, setting 'device_tree=bcm2708-rpi-0-w.dtb' doesn't hang up the boot process. Jeff

jeffersonchua · 2017-05-25T14:57:31Z

On Thu, May 25, 2017 at 8:17 PM, Jeff Chua ***@***.***> wrote: On Thu, May 25, 2017 at 1:35 PM, Jeff Chua ***@***.***> wrote: > On Thu, May 25, 2017 at 1:59 AM, Jeff Chua ***@***.***> wrote: >> On Thu, May 25, 2017 at 1:12 AM, popcornmix ***@***.***> >> wrote: >>> >>> What does sudo vcdbg log msg |& grep dtb report when it works? >> >> Mine shows this ... but I don't think this is not work ... >> >> 001753.598: Loading 'kernel.img' to 0x8000 size 0x25d0fc >> 001757.284: Kernel trailer DTOK property says yes >> 001757.298: Kernel trailer DDTK property says yes >> 001760.576: Loading 'bcm2708-rpi-0-w.dtb' to 0x2650fc size 0x54af >> 002964.862: dterror: out of memory >> 002996.682: Device tree loaded to 0x1bfea700 (size 0x58e0) > > Here's from working 4.9.29+ kernel ... > 002102.364: Loading 'bcm2708-rpi-0-w.dtb' to 0x434d78 size 0x3d2c > > I'll try to recompile based on working .confg to see what's the differences. Still working on the kernel compile. But, just want to share that with the working kernel, setting 'device_tree=bcm2708-rpi-0-w.dtb' doesn't hang up the boot process. Jeff

Encountered this error trying to compile with the config from 4.9.29+ ... MODPOST vmlinux.o drivers/built-in.o: In function `vc_sm_connected_init': arm_pmu_platform.c:(.text+0x7269c): undefined reference to `vchi_initialise' arm_pmu_platform.c:(.text+0x726ac): undefined reference to `vchi_connect' drivers/built-in.o: In function `vc_vchi_sm_videocore_io': arm_pmu_platform.c:(.text+0x74794): undefined reference to `vchi_service_release' arm_pmu_platform.c:(.text+0x747b0): undefined reference to `vchi_service_use' arm_pmu_platform.c:(.text+0x7480c): undefined reference to `vchi_queue_kernel_message' arm_pmu_platform.c:(.text+0x74870): undefined reference to `vchi_msg_peek' arm_pmu_platform.c:(.text+0x748cc): undefined reference to `vchi_msg_remove' drivers/built-in.o: In function `vc_vchi_sm_init': arm_pmu_platform.c:(.text+0x74b74): undefined reference to `vchi_service_open' arm_pmu_platform.c:(.text+0x74bfc): undefined reference to `vchi_service_close' drivers/built-in.o: In function `vc_vchi_sm_stop': arm_pmu_platform.c:(.text+0x74cc0): undefined reference to `vchi_service_use' arm_pmu_platform.c:(.text+0x74cc8): undefined reference to `vchi_service_close' drivers/built-in.o: In function `vc_sm_init': arm_pmu_platform.c:(.init.text+0x4ba0): undefined reference to `vchiq_add_connected_callback' Makefile:997: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 1 How to fix this? Or does this have anything to do with device tree? Thanks, Jeff

pelwell · 2017-05-25T15:02:09Z

Are you sure you are using the defconfigs from the 4.9 tree? That was an error I saw building 4.12 last week.

I often build the 4.9 kernel multiple times a day so I know it builds OK with bcmrpi_defconfig and bcm2709_defconfig.

jeffersonchua · 2017-05-25T16:02:45Z

On Thu, May 25, 2017 at 11:02 PM, Phil Elwell ***@***.***> wrote: Are you sure you are using the defconfigs from the 4.9 tree? That was an error I saw building 4.12 last week. I often build the 4.9 kernel multiple times a day so I know it builds OK with bcmrpi_defconfig and bcm2709_defconfig.

Phil, No, I wasn't using the defconfig from 4.9 tree. I booted up the working kernel downloaded from https://github.com/raspberrypi/firmware/branches, modprobe configs and use the /proc/config.gz from there ... I'll go back try bcmrpi_defconfig and bcm2709_defconfig again. Thanks, Jeff

jeffersonchua · 2017-05-25T18:42:20Z

On Fri, May 26, 2017 at 12:02 AM, Jeff Chua ***@***.***> wrote: On Thu, May 25, 2017 at 11:02 PM, Phil Elwell ***@***.***> wrote: > Are you sure you are using the defconfigs from the 4.9 tree? That was an > error I saw building 4.12 last week. > > I often build the 4.9 kernel multiple times a day so I know it builds OK > with bcmrpi_defconfig and bcm2709_defconfig. Phil, No, I wasn't using the defconfig from 4.9 tree. I booted up the working kernel downloaded from https://github.com/raspberrypi/firmware/branches, modprobe configs and use the /proc/config.gz from there ... I'll go back try bcmrpi_defconfig and bcm2709_defconfig again.

Phil, I really don't know what I'm doing wrong. Compiled with bcmrpi_defconfig and ended up same issue. I compiled for pi3 and it's working correctly .. 001919.351: Loading 'bcm2710-rpi-3-b.dtb' to 0x278940 size 0x5a80 002074.550: dtparam: audio=on 003163.629: Device tree loaded to 0x2efea100 (size 0x5eaf) I just don't understand why pi0w don't work. But the downloaded compiled kernel works. Thanks, Jeff

pelwell · 2017-05-25T20:21:51Z

If you upload your kernel and .dtb somewhere I'll try them tomorrow.

pelwell · 2017-05-25T20:23:09Z

Also the .config and the commit hash for the head of the tree.

jeffersonchua · 2017-05-26T15:13:32Z

On Fri, May 26, 2017 at 4:22 AM, Phil Elwell ***@***.***> wrote: If you upload your kernel and .dtb somewhere I'll try them tomorrow. Also the .config and the commit hash for the head of the tree.

Where is a good place to upload to? I just tried bcm2835_defconfig ... nothing shows up. And led didn't even blink. Jeff

jeffersonchua · 2017-05-26T16:06:16Z

On Fri, May 26, 2017 at 11:13 PM, Jeff Chua ***@***.***> wrote: On Fri, May 26, 2017 at 4:22 AM, Phil Elwell ***@***.***> wrote: > If you upload your kernel and .dtb somewhere I'll try them tomorrow. > Also the .config and the commit hash for the head of the tree. Where is a good place to upload to? I just tried bcm2835_defconfig ... nothing shows up. And led didn't even blink.

Phil, I've uploaded my compiled kernel and modules to ... https://github.com/jeffersonchua/pi0w/tree/bcm2709_defconfig https://github.com/jeffersonchua/pi0w/tree/bcmrpi_defconfig Thanks, Jeff

jeffersonchua · 2017-05-29T06:05:17Z

On Sat, May 27, 2017 at 12:06 AM, Jeff Chua ***@***.***> wrote: On Fri, May 26, 2017 at 11:13 PM, Jeff Chua ***@***.***> wrote: > On Fri, May 26, 2017 at 4:22 AM, Phil Elwell ***@***.***> > wrote: >> If you upload your kernel and .dtb somewhere I'll try them tomorrow. >> Also the .config and the commit hash for the head of the tree.

And here's the hash ... commit 3be22f2 Author: P33M <[email protected]> Date: Thu May 25 16:04:53 2017 +0100 dwc_otg: make periodic scheduling behave properly for FS buses If the root port is in full-speed mode, transfer times at 12mbit/s would be calculated but matched against high-speed quotas. Reinitialise hcd->frame_usecs[i] on each port enable event so that full-speed bandwidth can be tracked sensibly. Also, don't bother using the FIQ for transfers when in full-speed mode - at the slower bus speed, interrupt frequency is reduced by an order of magnitude. Related issue: #2020 Thanks, Jeff

pelwell · 2017-05-30T10:51:35Z

Using your kernel, modules, .dtb, config.txt and cmdline.txt my Zero W boots to a GUI without any problems.

jeffersonchua · 2017-05-30T15:51:16Z

On Tue, May 30, 2017 at 6:51 PM, Phil Elwell ***@***.***> wrote: Using your kernel, modules, .dtb, config.txt and cmdline.txt my Zero W boots to a GUI without any problems.

Phil, But 'vcdbg log msg' will show 'dterror: out of memory'. And if you add 'device_tree=bcm2708-rpi-0-w.dtb' to config.txt, the pi won't boot. Jeff

pelwell · 2017-05-30T16:19:25Z

Yes, I do see the "dterror: out of memory" message, but the device boots - I can investigate this. Adding device_tree=bcm2708-rpi-0-w.dtb makes no difference (as it shouldn't).

pelwell · 2017-05-30T16:43:13Z

Ah - I understand the "out of memory" message. It is harmless, but I'll make sure it doesn't occur in future releases.

jeffersonchua · 2017-05-30T17:11:19Z

On Wed, May 31, 2017 at 12:43 AM, Phil Elwell ***@***.***> wrote: Ah - I understand the "out of memory" message. It is harmless, but I'll make sure it doesn't occur in future releases.

Interesting ... what caused that?

Adding device_tree=bcm2708-rpi-0-w.dtb makes no difference (as it

shouldn't). Really? On my pi. it refused to boot ... unless it was another config as I compiled so many versions. Pretty sure the default config won't boot with device_tree set. Jeff.

pelwell · 2017-05-31T07:55:41Z

Ah - I understand the "out of memory" message. It is harmless, but I'll
make sure it doesn't occur in future releases.

Interesting ... what caused that?

The DT for the BCM2835-based devices now includes an empty arm_freq property to prevent a warning, but part of setting a parameter includes making a copy of the parameter declaration. Calling malloc on a zero-length block returns NULL on the VPU - under glibc you get a pointer to a zero-sized block - making it look like an error. Errors resulting from setting parameters are intentionally non-fatal, so everything else continues as normal.

Pretty sure the default config won't boot with device_tree set.

Don't you think it's strange that you are the only person reporting problems? I've spent a few hours on this with no success and I've run out of things to try.

I suggest you try to find the newest branch+commit that still works for you, starting with head-of-tree rpi-4.9.y, partly in the hope that you can identify a specific commit and partly just to confirm that it isn't a tool problem. Be careful to always copy the rebuilt dtbs, particularly when switching kernel versions.

kernel: dwc_otg: make periodic scheduling behave properly for FS buses See: raspberrypi/linux#2038 kernel: dwc_otg: fiq_fsm: Make isochronous compatibility checks work properly See: raspberrypi/linux#2049 kernel: Add support for Allo Digione Driver See: raspberrypi/linux#2048 kernel: config: Adding SENSOR_JC42 See: raspberrypi/linux#2046 kernel: BCM270X_DT: Improve i2c-sensor and i2c-rtc overlay kernel: overlays: Fix i2c-rtc order and fragment numbering See: raspberrypi/linux#2059 kernel: BCM270X_DT: Add midi-uart1 overlay See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=183860 firmware: dtoverlay: Short-circuit empty parameter handling See: raspberrypi/linux#2028 firmware: rtos: Protect against null timer callback See: http://forum.kodi.tv/showthread.php?tid=280408 firmware: arm_dt: Add txp node to device tree parsing to mask off transposer interrupt firmware: venc: Correct the validation on custom mb/mbps/br settings See: #819

kernel: dwc_otg: make periodic scheduling behave properly for FS buses See: raspberrypi/linux#2038 kernel: dwc_otg: fiq_fsm: Make isochronous compatibility checks work properly See: raspberrypi/linux#2049 kernel: Add support for Allo Digione Driver See: raspberrypi/linux#2048 kernel: config: Adding SENSOR_JC42 See: raspberrypi/linux#2046 kernel: BCM270X_DT: Improve i2c-sensor and i2c-rtc overlay kernel: overlays: Fix i2c-rtc order and fragment numbering See: raspberrypi/linux#2059 kernel: BCM270X_DT: Add midi-uart1 overlay See: https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=183860 firmware: dtoverlay: Short-circuit empty parameter handling See: raspberrypi/linux#2028 firmware: rtos: Protect against null timer callback See: http://forum.kodi.tv/showthread.php?tid=280408 firmware: arm_dt: Add txp node to device tree parsing to mask off transposer interrupt firmware: venc: Correct the validation on custom mb/mbps/br settings See: raspberrypi/firmware#819

JamesH65 · 2017-09-13T11:13:42Z

Closing due to lack of activity. Not really a problem at the RPF end, and really should be dealt with on the forum.

- firmware: platform: Move trait initialisation out of #ifdef'd function - firmware: usb: Change USB PHY settings to make device mode work correctly - firmware: dtoverlay: Update fixups when a node is renamed - firmware: dtoverlay app: Add the -D (dry-run) option See: raspberrypi/linux#2002 - firmware: dispserver: Adjust open/close refcount on application exit See: #778 - firmware: filex: Optimise directory search of the root directory - firmware: Revert Change USB PHY settings to make device mode work correctly. See: #816 - firmware: Comments: Replace copyright symbol with (c) - firmware: arm_display: Remove unused sdtv variables - firmware: tvservice: Avoid referencing uninitialised state when unsuccessful See: raspberrypi/userland#397 - firmware: dtoverlay: Short-circuit empty parameter handling See: raspberrypi/linux#2028 - firmware: rtos: Protect against null timer callback See: http://forum.kodi.tv/showthread.php?tid=280408 - firmware: arm_dt: Add txp node to device tree parsing to mask off transposer interrupt - firmware: venc: Correct the validation on custom mb/mbps/br settings See: #819 - firmware: venc: Correct the validation on custom mb/mbps/br settings See: #819 - firmware: vc_image: Remove structure definition duplication - firmware: vc_image/mmal/il/isp: Add support for 16bit/component YUV420 and YUVUV - firmware: vcdbg: Don't use dma when file provided - firmware: rtos: Avoid sleeping delay when RTOS is not present - firmware: bootcode: Remove reliance on scanf to reduce bootcode.bin size - firmware: bootcode: Changes to force to full speed - firmware: bootcode: Make sure bootcode drops out - firmware: bootcode: Mass storage changes to power off/on USB block - firmware: bootcode: Change USB 1.1 to have 64 byte endpoints - firmware: bootcode: Set MSD serial number to be the Pi serial number - firmware: imx219: Extend line length for long frame times - firmware: 2ndstage: Improve i2c_gpio support - firmware: i2c_gpio: Improve implementation and usage - firmware: Camplus: Enable RAW12 support in the ISP input formatter - firmware: scalerlib: Don't flip tiled format and swap R/B - firmware: arm_display: Provide mechanism to request tiled format framebuffer See: #820 - firmware: platform: Set BT LPO frequency to 32768Hz See: #831 - firmware: arm_display: Fix mixup with xres/xres_virtual See: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=187058 - firmware: video_render: Relax the alignment requirements for pitches - firmware: vc_image: Use vpitch when determining size of YUV buffers - firmware: Fix regression in uart clock frequency See: #833 - bootcode: usb: Dont overwrite configured parameters - firmware: usb: Force MSD app to use CM3 pin conf - firmware: IL ISP: Fix typo in logging - firmware: IL ISP: Add black level and lens shading controls - firmware: isp: Correct ISP Bayer stride calcs for supported formats - firmware: Remove unused duplicate versions of vc_sm_defs.h - firmware: IL camera: add get_parameter for OMX_IndexConfigCustomAwbGains - firmware: IL resize: Support get_parameter OMX_IndexConfigCommonInputCro - firmware: MMAL/RIL: Add MMAL_PARAMETER_RESIZE_PARAMS / OMX_IndexParamResize mapping - firmware: ISP IL: Add lresize output - firmware: MMAL/RIL: Add mapping for OMX_IndexConfigCommon[In|Out]putCrop - firmware: MMAL/RIL: Correct handling of MMAL_PARAMETER_VIDEO_SOURCE_PATTERN - firmware: IL ISP: Add H & V flip support - firmware: IL ISP: Implement OMX_IndexConfigCommonInputCrop - firmware: imx219: Refactor exposure calculations - firmware: dmalib: Stop spinning on dma_pause if END is signalled See: #824 - firmware: MMAL: Avoid lockup with opaque stripes into opaque frame callback See: raspberrypi/userland#390 - firmware: RIL null_sink: Support MMAL opaque input See: raspberrypi/userland#388 - firmware: arm_display: Avoid hang when display_rotate is used with vc4-kms-v3d driver See: guysoft/FullPageOS#137 - firmware: 2ndstage: Fix printing of zero as a decimal in uart_printf - firmware: cdi_camera: Allow GPIO control on FS and FE events - firmware: IL ISP: Add option to alter the shift in the output stage - firmware: IL ISP: Add option for adjusting the input CCM - firmware: vc_image: fix size calcs for YUV_UV_16 - firmware: vc_image_helper: Add YUV 16 bit formats to second header - firmware: isp: Avoid setting vpitch in YUVUV16 cases - firmware: isp: Handle 16 bit yuv in ip_is_supported_format - firmware: hello_fft: Fixup offset calculation when mapping/unmapping buffers See: raspberrypi/userland#408 - bootcode: Default to using total_mem=1024 - firmware: logging: Avoid wraparound issue with total_mem=1024 - firmware: armstubs: Add wfe to ARMv7/ARMv8-32 stubs See: raspberrypi/linux#1989 - firmware: arm_loader: Use ethernet0 as fallback for placing DT MAC address See: #846 - firmware: dt-blob: Remove Zero W static I2C0 mapping on 28 & 29 See: raspberrypi/linux#2130 - firmware: Revert arm_display: Avoid hang when display_rotate is used with vc4-kms-v3d driver - firmware: arm_display: Avoid hang when display_rotate is used with vc4-kms-v3d driver 2 See: #849 See: #853 - firmware: vc_image headers: Tidy up duplication - firmware: video_splitter: Only copy eColorFormat if not already set See: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=189830 - firmware: vcsm: Add new clean/invalidate command for 2D blocks - firmware: gpuserver: Switch to using custom queue - firmware: gpuserver: Add priority to queue - firmware: MMAL/IL I420 and YUVUV 10bpp formats, + VCSM DMABUF import - firmware: CEC: Fix crash when remote button release is received without a pressed See: https://forum.kodi.tv/showthread.php?tid=280408 - firmware: arm_loader display: Correct variable scope by renaming See: https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=84889

jeffersonchua · 2017-09-14T14:21:50Z

On Wed, Sep 13, 2017 at 7:14 PM, James Hughes ***@***.***> wrote: Closed #2028 <#2028>. It was due to cross-toolchain issue. All sorted out. Sorry for not

replying. Thanks, Jeff

JamesH65 closed this as completed Sep 13, 2017

pi0w won't boot, but pi3 works on linux-4.12-rc1 #2028

pi0w won't boot, but pi3 works on linux-4.12-rc1 #2028

Comments

jeffersonchua commented May 20, 2017

pi0 ...

pi3 ...

pelwell commented May 20, 2017

Uh oh!

lategoodbye commented May 20, 2017

Uh oh!

jeffersonchua commented May 21, 2017 via email

Uh oh!

lategoodbye commented May 21, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jeffersonchua commented May 21, 2017 via email

Uh oh!

pelwell commented May 21, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jeffersonchua commented May 21, 2017 via email

Uh oh!

jeffersonchua commented May 21, 2017 via email

Uh oh!

pelwell commented May 21, 2017

Uh oh!

jeffersonchua commented May 21, 2017 via email

Uh oh!

jeffersonchua commented May 21, 2017 via email

Uh oh!

popcornmix commented May 22, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jeffersonchua commented May 22, 2017 via email

Uh oh!

jeffersonchua commented May 22, 2017 via email

Uh oh!

jeffersonchua commented May 24, 2017 via email

Uh oh!

pelwell commented May 24, 2017

Uh oh!

jeffersonchua commented May 24, 2017 via email

Uh oh!

pelwell commented May 24, 2017

Uh oh!

jeffersonchua commented May 24, 2017 via email

Uh oh!

jeffersonchua commented May 24, 2017 via email

Uh oh!

pelwell commented May 24, 2017

Uh oh!

pelwell commented May 24, 2017

Uh oh!

jeffersonchua commented May 24, 2017 via email

Uh oh!

jeffersonchua commented May 24, 2017 via email

Uh oh!

popcornmix commented May 24, 2017

Uh oh!

jeffersonchua commented May 24, 2017 via email

Uh oh!

jeffersonchua commented May 25, 2017 via email

Uh oh!

jeffersonchua commented May 25, 2017 via email

Uh oh!

jeffersonchua commented May 25, 2017 via email

Uh oh!

pelwell commented May 25, 2017

Uh oh!

jeffersonchua commented May 25, 2017 via email

Uh oh!

jeffersonchua commented May 25, 2017 via email

Uh oh!

pelwell commented May 25, 2017

Uh oh!

pelwell commented May 25, 2017

Uh oh!

jeffersonchua commented May 26, 2017 via email

Uh oh!

jeffersonchua commented May 26, 2017 via email

lategoodbye commented May 21, 2017 •

edited

Loading

pelwell commented May 21, 2017 •

edited

Loading

popcornmix commented May 22, 2017 •

edited

Loading