Closed DougieLawson closed 7 years ago
With the latest firmware-next I can boot a PiZero 1.2, but not a PiZero 1.3
My Pi Zero is an original (no camera) model. It boots to a running kernel but half of the services didn't start. I ended up having to pull the SDCard and fix it in a chroot on another Raspberry.
I took the cautious approach and reverted to 48099e1634c0d845e6619f1a18df84b895370dd4 4.4.44+ kernel.
Only things in config.txt are
[0xebd5f1e8]
# ** Falcon : ebd5f1e8 **
#dtoverlay=enc28j60,int_pin=25,speed=20000000
gpu_mem=64
dtparam=act_led_activelow=on
disable_audio_dither=1
#dtparam=i2c_vc=on
#dtdebug=on
[all]
dtparam=audio=on
dtparam=spi=on
dtparam=i2c_arm=on
Interesting. I can boot both my 1.2 Zeros and an original model A with kernel 4.9.5 and the latest firmware next, but the 1.3 Zero will only load the firmware.
I just ran a BRANCH=next rpi-update (kernel 4.9.5+ build 952, hash https://github.com/Hexxeh/rpi-firmware/commit/4ac7e545c12a221af712fb54dfd859647d7a7b44 which corresponds to firmware repo hash https://github.com/raspberrypi/firmware/commit/e215cff99acfede1abd03e0846b839a5fb8d98ac) on a 1.3 Zero and it seems OK to me.
Can you confirm if the problem is in the firmware or kernel update? Does latest master branch work okay?
No mail.
pi@falcon:/boot $ cat .firmware_revision
fce4c927013b147386a21d5eed69856ff386e5ba
Appears to be working OK.
So master is okay. Can you just bump the firmware to next, leaving kernel as it is?
sudo SKIP_KERNEL=1 BRANCH=next rpi-update
SKIP_KERNEL=1 BRANCH=next rpi-update
breaks it.
And previous BRANCH=next was okay? (https://github.com/Hexxeh/rpi-firmware/commit/f69368bd395c0dcff94f47c48db71a0f9dbc5c82)
https://github.com/Hexxeh/rpi-firmware/commit/f69368bd395c0dcff94f47c48db71a0f9dbc5c82 was OK. I can retest it if you need me to.
Assuming the previous build on next did work, then the only change that seems possible to break booting is the LED change. Can you test this firmware with LED change reverted? https://drive.google.com/uc?id=0B-6zmEDJwxZEWkZUd0wxV3dodnc&export=download
@popcornmix that works. Thanks.
I have no issue when booting from sdcard (confirmed with test firmware above). The difference between PiZero models is only apparent when loading firmware with rpiboot, so I have another issue.
@DougieLawson Could you try: https://drive.google.com/uc?id=0B-6zmEDJwxZEWDFjZFVoMzk3UFk&export=download It includes some tweaks to the LED driver.
@DougieLawson Are you also using rpiboot? If so, have you tried sdcard? I'm trying to narrow down why my testing didn't show up the problem.
@pelwell I'm not using RPiBoot my zero has an 8GB SDCard. @popcornmix firmware_9e536cee.zip works OK.
Last night's master and next releases include the changes in firmware_9e536cee.zip. Although there were problems with LED handling in the previous release, I still don't understand how it could have prevented a device from booting.
It didn't prevent it from booting, it just left it in a persistent vegative state when it was booted.
Thanks for fixing this.
Belay that.
Latest BRANCH=next rpi-update doesn't include the fix.
A substantial underclock teased my recalcitrant PiZero into action. I think the firmware may be missing an overvoltage setting.
@ED6E0F17 That is interesting. The change to LED driver could affect SMPS used for setting voltage.
Sadly that change only worked the first time, so it is still failing 99% of the time. It kept running well after it started though.
What bootcode version went into https://github.com/raspberrypi/firmware/commit/7cac124129b876a41de14368499373fca4688541 do I need to copy firmware_9e536cee.zip back in if I run rpi-update to that latest version.
bootcode.bin didn't change with https://github.com/raspberrypi/firmware/commit/7cac124129b876a41de14368499373fca4688541 - it last changed with https://github.com/raspberrypi/firmware/commit/a084e6e21ca147baaebd6841bf16a56832372e02
I rebooted with https://github.com/Hexxeh/rpi-firmware/commit/0335edc0994d495933ff16947628ae741d38ecf7 this morning and my Zero didn't work until I pulled the power and gave it a second go.
This feels like a problem of uninitialised state, but pinning it down is going to be tricky.
I've just tried with https://github.com/Hexxeh/rpi-firmware/commit/58be564106f76981b2edea5d7fbbca6fb446e236 and that shutdown and booted with no problems.
Puzzled now.
Im also not able to boot my pi 1 b+, my pi does only work with 4.4.y all other gives me only a colored square. i compiled the 4.9.y and also used the firmware next -> the same. Also i checked out the kernel.org version of linux and used the rpi1-support patches up to 4.9.7 ... the same... the kernel repo is: https://github.com/piBMC/linux
it would be nice when the firmware could print out an error code. my something like 0x00001c or led diagnostics codes.
@LipkeGu is your problem with upgrading the kernel or firmware?
E.g. if you are on 4.4 kernel and run
sudo SKIP_KERNEL=1 BRANCH=next rpi-update
does it no longer boot?
Are you using usb or network boot modes?
Im compiling the kernel from source using buildroot. buildroot is using the latest rpi-firmware and latest rpi-userland. The image is resulting in an SD card image ... and will be booted from there. The 4.4-y works fine ... 4.8-y and later results in non-boot (colored red, yellow, blue) screen.
Version: Linux version 4.9.7 (lipkegu@Medice-PC) (gcc version 5.4.0 (Buildroot 2017.02-git-00930-gc8de342-dirty) ) #1 Sat Feb 4 15:00:43 CET 2017
thats my rpi-firmware.mk:
RPI_FIRMWARE_VERSION = cf0ea7809fbbd361e8aa38de9b99255c13eaf181
RPI_FIRMWARE_SITE = $(call github,raspberrypi,firmware,$(RPI_FIRMWARE_VERSION))
RPI_FIRMWARE_LICENSE = BSD-3c
RPI_FIRMWARE_LICENSE_FILES = boot/LICENCE.broadcom
RPI_FIRMWARE_INSTALL_IMAGES = YES
And my pibmc_rp_defconfig
BR2_arm=y
BR2_arm1176jzf_s=y
BR2_ARM_EABIHF=y
BR2_TOOLCHAIN_BUILDROOT_GLIBC=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_SYSTEM_DHCP="eth0"
BR2_ENABLE_LOCALE=y
BR2_ENABLE_LOCALE_PURGE=y
BR2_ENABLE_LOCALE_WHITELIST="C de_DE de_DE.UTF-8 en_US en_US.UTF-8"
BR2_GENERATE_LOCALE="de_DE de_DE.UTF-8 en_US en_US.UTF-8"
BR2_TARGET_TZ_INFO=y
BR2_TARGET_TZ_ZONELIST="default"
BR2_TARGET_LOCALTIME="Europe/Berlin"
# Linux headers same as kernel, a 4.4 series
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_9=y
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_GIT=y
BR2_LINUX_KERNEL_CUSTOM_REPO_URL="https://github.com/piBMC/linux.git"
BR2_LINUX_KERNEL_CUSTOM_REPO_VERSION="364f6c5c254a36ac13e7ee6832dd533b3d3ebeef"
BR2_LINUX_KERNEL_USE_DEFCONFIG=y
BR2_LINUX_KERNEL_DEFCONFIG="bcmrpi"
# Build the DTBs for A/B, A+/B+ and compute module from the kernel sources
BR2_LINUX_KERNEL_DTS_SUPPORT=y
BR2_LINUX_KERNEL_INTREE_DTS_NAME="bcm2708-rpi-b bcm2708-rpi-b-plus bcm2708-rpi-cm"
BR2_PACKAGE_RPI_FIRMWARE=y
BR2_PACKAGE_RPI_USERLAND=y
# Required tools to create the SD image
BR2_PACKAGE_HOST_DOSFSTOOLS=y
BR2_PACKAGE_HOST_GENIMAGE=y
BR2_PACKAGE_HOST_MTOOLS=y
# Filesystem / image
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypi/post-build.sh"
BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypi/post-image.sh"
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_ROOTFS_OVERLAY="overlay/rp1/"
BR2_TARGET_GENERIC_HOSTNAME="pibmc"
BR2_TARGET_GENERIC_ISSUE="Welcome to piBMC"
BR2_TARGET_GENERIC_PASSWD_SHA512=y
BR2_TARGET_GENERIC_PASSWD_METHOD="sha-512"
BR2_TARGET_ENABLE_ROOT_LOGIN=n
BR2_TARGET_GENERIC_ROOT_PASSWD="pibmc"
# Packages
BR2_PACKAGE_PYTHON=y
BR2_PACKAGE_SAMBA4=y
BR2_PACKAGE_ACL=y
BR2_PACKAGE_CA_CERTIFICATES=y
BR2_PACKAGE_NTP=y
BR2_PACKAGE_KODI=y
BR2_PACKAGE_OMXPLAYER=y
BR2_PACKAGE_KODI_DBUS=y
BR2_PACKAGE_KODI_THEORA=y
BR2_PACKAGE_KODI_OPTICALDRIVE=y
BR2_PACKAGE_KODI_LIBCEC=y
BR2_PACKAGE_KODI_LIRC=y
BR2_PACKAGE_KODI_VISUALISATION_SPECTRUM=y
BR2_PACKAGE_KODI_NONFREE=y
BR2_PACKAGE_KODI_LIBSMBCLIENT=y
BR2_PACKAGE_KODI_RESOURCE_LANGUAGE_de_de=y
BR2_PACKAGE_KODI_PVR_IPTVSIMPLE=y
BR2_PACKAGE_KODI_INPUTSTREAM_ADAPTIVE=y
BR2_PACKAGE_KODI_INPUTSTREAM_RTMP=y
Using the kernels bcmrpi builds fine but doesnt boot... with 4.8.y++ When im using the 4.4.y with (https://github.com/piBMC/pibmc-buildroot/blob/kodi-17-rpi/board/raspberrypi/linux-config) it works fine with 4.4-y
to reproduce it: https://github.com/piBMC/pibmc-buildroot
1) git clone https://github.com/piBMC/pibmc-buildroot.git
2) git checkout "kodi-17-rpi"
3) run 'make pibmc_rp_defconfig'
3a) Use 'make linux-menuconfig' to manipulate the kernel config
3b) Use 'make busybox-menuconfig' to manipulate the busybox config
3c) Use 'make menuconfig' to enter buildroot configuration.
4) run 'make' and wait while it compiles...
5) write your created sdcard image (found in output/images/)
I've just tried https://github.com/Hexxeh/rpi-firmware/commit/f0b0f08d60ffc20a73ab5330a731258b9668802f and it booted on my Zero 1.2 but only after I pulled the power.
A simple sudo reboot
didn't work moving from 4.4.46+ to 4.9.8+
root@falcon /boot # uname -a
Linux falcon 4.9.8+ #960 Sun Feb 5 14:54:12 GMT 2017 armv6l GNU/Linux
root@falcon /boot # cat .firmware_revision
f0b0f08d60ffc20a73ab5330a731258b9668802f
root@falcon /boot # vcgencmd version
Feb 3 2017 17:28:22
Copyright (c) 2012 Broadcom
version 12dfe2223aa88c5d7ce0e701e9fb7746914decc3 (clean) (release)
root@falcon /boot #
How far did the reboot get? Did the display blank?
Hi @pelwell I didn't look at the TV but after a power cycle that one booted OK and the application that runs on it (which drives a MAX7219 LED) started OK.
@DougieLawson what is the status of this issue? Does the issue still occur ?
4.9.14+ is working OK.
I don't know what you've done in https://github.com/raspberrypi/firmware/commit/e215cff99acfede1abd03e0846b839a5fb8d98ac but networking, systemd and a whole bunch of other stuff simple hangs on my Zero.
Edit: fixed commit id.