On Sunday 20 December 2015 18:43:34 Michael Ströder wrote:

...

The latest update to kernel 4.3.0 for RPi1 ruined the system. It does not start anymore. The error message on the screen said: File not found dtb.bcm2835-rpi-b.dtb

Since a couple of kernel updates and only on some systems I have to manually copy the fimware files into /boot/dtb/ to make it work again.

Ciao, Michael.

Most probably your system is not properly updated, which happens as not everything is updated automatically, unfortunately. As of today, the blueprint for booting looks as follows: - RPi loader (bootcode.bin) on the first partition (FAT16) is loaded and started. - Reads Config.txt, kernel=u-boot.bin - RPi loader starts u-boot ------ handover ----- - u-boot starts, reads default environment - environment contains command to find first bootable partitions [1] -> this yields the second, ext3 boot partition - bootable partion is scanned for boot.scr - boot.scr is loaded and executed - boot.scr contains - the path to the fdt file (e.g. dtb/bcm2835-rpi-b.dtb) - the path to the kernel (zImage) - the path to the initrd (initrd) - the kernel cmdline arguments (root=...) - u-boot loads the fdt file - u-boot loads the kernel - u-boot loads the initrd - u-boot appends the initrd address to the fdt - u-boot executes the kernel ---- * The boot.scr is only created once during kiwi image creation, so this may be outdated. You can view its contents with: $> tail -c +72 /boot/boot.scr * u-boot.bin itself has to be copied to the FAT partition manually. * The dtbs are multiversion enabled since a few weeks. You should remove the old /boot/dtb/ directory and reinstall the latest dtb-bcm2835 rpm, /boot/dtb should be a symlink to the versioned dtb directory afterwards. Kind regards, Stefan [1] as of u-boot 2015.04-rc5 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424

Am 20.12.2015 um 23:23 schrieb Stefan Bruens:

On Sunday 20 December 2015 18:43:34 Michael Ströder wrote:

...

...

The latest update to kernel 4.3.0 for RPi1 ruined the system. It does not start anymore. The error message on the screen said: File not found dtb.bcm2835-rpi-b.dtb

Since a couple of kernel updates and only on some systems I have to manually copy the fimware files into /boot/dtb/ to make it work again.

Typo, I assume. .dtb files go to /boot/dtb* but not the firmware files. Currently there is no standard mount point for the FAT partition yet, cf. below.

Most probably your system is not properly updated, which happens as not everything is updated automatically, unfortunately.

As of today, the blueprint for booting looks as follows:

A nice summary, Stefan! Some corrections and updates inline.

- RPi loader (bootcode.bin) on the first partition (FAT16) is loaded and started. - Reads Config.txt, kernel=u-boot.bin - RPi loader starts u-boot

------ handover -----

- u-boot starts, reads default environment - environment contains command to find first bootable partitions [1] -> this yields the second, ext3 boot partition

Actually until today it yielded the first, fat partition. Hopefully fixed now (JeOS-raspberrypi2 >= build 355).

- bootable partion is scanned for boot.scr - boot.scr is loaded and executed

boot.scr on fat previously chain-loaded the boot.scr on ext3:

- boot.scr contains - the path to the fdt file (e.g. dtb/bcm2835-rpi-b.dtb) - the path to the kernel (zImage) - the path to the initrd (initrd) - the kernel cmdline arguments (root=...) - u-boot loads the fdt file - u-boot loads the kernel - u-boot loads the initrd - u-boot appends the initrd address to the fdt - u-boot executes the kernel ----

* The boot.scr is only created once during kiwi image creation, so this may be outdated. You can view its contents with: $> tail -c +72 /boot/boot.scr

And you can easily replace it with a much simpler version such as: setenv bootargs 'console=ttyAMA0,115200 root=/dev/mmcblk0p3 rootfstype=ext4 rw rootwait' # or whatever you were using load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} zImage load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} dtb/${fdtfile} load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} initrd bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r} Note the -b-rev2.dtb vs. -b.dtb ${fdtfile} issue discussed elsewhere.

* u-boot.bin itself has to be copied to the FAT partition manually.

https://build.opensuse.org/request/show/350127 Use /boot/vc as mount point for the FAT partition (/etc/fstab or YaST Partitioner), then new raspberrypi-firmware, raspberrypi-firmware-branding-openSUSE and soon u-boot-rpi / u-boot-rpi2 packages will update the FAT partition without manual copying.

* The dtbs are multiversion enabled since a few weeks. You should remove the old /boot/dtb/ directory and reinstall the latest dtb-bcm2835 rpm, /boot/dtb should be a symlink to the versioned dtb directory afterwards.

Note that while the packages are prepared for multiversion through distinctive folder names, they will not be installed side by side unless you create a file such as /etc/zypp/multiversion.d/my-dtb.conf that enables the new behavior with: provides:multiversion(dtb) This has the downside that once you install, e.g., dtb-bcm2835-4.4.rc5 from Kernel:HEAD it might no longer install updated 4.3.x versions from a home branch of yours. (Obsoletes do not seem to work well with custom Provides, we'll need to borrow some magic from the kernel package for improving this... also the directory names for Kernel:HEAD remain to be tidied from 4.4.rc5-x to 4.4.0-rc5-x.deadbeaf.) Another thing worth pointing out is that when you're installing two new kernel and corresponding multiversion dtb packages, there is no guarantee that kernels and dtb packages will be installed in the same order, so do check that dtb and initrd/zImage are pointing to the same version before rebooting (ll /boot/). We're slowly getting there! Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org