BCM270x: Move power module

[notro]

This makes it possible to boot ARCH_BCM2835 directly from the VideoCore bootloader.
The power module turns on USB power, so u-boot is not strictly necessary anymore.

Tested on Pi1 and Pi2 regular kernel + ARCH_BCM2835.

On ARCH_BCM2835 add dtb to /boot/config.txt

device_tree=bcm2835-rpi-b-plus.dtb
or
device_tree=bcm2835-rpi-b.dtb

[notro]

@pelwell It would have been nice if mkknlimg could tag the ARCH_BCM2835 kernel specially so the firmware can set device_tree= automatically for us.

[popcornmix]

It's okay by me.

[pelwell]

I can arrange for the tagging and DTB selection, but I'm not available until Wednesday.

[pelwell]

@notro My proposal is to put an "architecture" prefix into the trailer, where the default is bcm2708 or bcm2709, and then arrange that mkknlimg adds bcm2835/bcm2836 for you (either automatically or as a command line option). For this to work, the bcm2835/bcm2836 .dtbs will have to maintain the same filename structure as the bcm2708/bcm2709 equivalents, e.g. bcm2836-rpi-2-b.dtb.

[notro]

For this to work, the bcm2835/bcm2836 .dtbs will have to maintain the same filename structure as the bcm2708/bcm2709 equivalents, e.g. bcm2836-rpi-2-b.dtb.

That seems to be the case. From [PATCH 3/9] ARM: Make a copy of the 2835 dts for the 2836.:

This is not hooked up to anything yet, but it means that our later
2836-specific changes will be more obvious.  The bcm2836-rpi-2-b.dts
actually comes from bcm2835-rpi-2-b-plus, which apparently is the
closest.

Signed-off-by: Eric Anholt <eric at anholt.net>
---
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 30 +++++++++++++++++++++

I don't know what filenames Warren refers to in his follow up:

Eventually, I'd like to get around to revamping the bcm283x DTs so
there's a DT for each separate board model, which would match the DT
filenames that U-Boot is looking for. Still, that's separate from these
patches.

But anyway, I believe dts files will be the last bit to match mainline (if ever), so even if we end up diverging here it's no big deal.

[pelwell]

Tested on a Pi 1 and Pi 2, with and without DT. Merging.

[pelwell]

@notro How are you booting ARCH_BCM2835 builds? Are you using kernel_old with custom startup code? I get a boot failure because the machine ID isn't supported:

Error: unrecognized/unsupported machine ID (r1 = 0x00000c42).

Available machine support:

ID (hex)        NAME
ffffffff        Generic DT based system
ffffffff        BCM2835

Please check your kernel config and/or bootloader.

[notro]

I just add this to /boot/config.txt:

device_tree=bcm2835-rpi-b-plus.dtb

[pelwell]

Are you building with an unmodified bcm2835_defconfig?

[notro]

Yes.

If you want onboard audio you currently have to manually enable: CONFIG_SOUND, CONFIG_SND, CONFIG_SND_BCM2835

I look forward to having an ARCH_BCM2835 tagged kernel, because I frequently forget to toggle the device_tree= setting when I switch between kernels, ending up with a system that doesn't boot.

[pelwell]

Unless you are using either a custom kernel header (or u-boot) and kernel_old, or a modified bcm2835 build that expects the 0xc42/3138 magic number, then I don't understand how it is working for you.

Can you upload your kernel image somewhere and briefly outline your build steps?

[notro]

Are you tagging your kernel with the --dtok option?

sudo ~/work/tools/mkimage/mkknlimg --dtok ~/work/notro-raspberrypi-linux/workdir.bcm2708/linux/arch/arm/boot/zImage /boot/kernel.img

[pelwell]

Yes - the problem isn't DT support, it's the machine ID, which the firmware sets to 0xc42 for all Pi's.

[notro]

/boot files: http://tronnes.org/downloads/bcm2835-vcboot.tar.gz

[pelwell]

Thanks.

[notro]

The error you get indicates that the kernel doesn't find a matching Device Tree, because the error you get is the atags fallback.
AFAIK machine id is not used with Device Tree, the compatible property fills that role.

void __init setup_arch(char **cmdline_p)
{
        const struct machine_desc *mdesc;

        setup_processor();
        mdesc = setup_machine_fdt(__atags_pointer);
        if (!mdesc)
                mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);

http://lxr.free-electrons.com/source/arch/arm/kernel/setup.c#L895

const struct machine_desc * __init
setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr)
{
...
        if (!mdesc) {
                early_print("\nError: unrecognized/unsupported machine ID"
                            " (r1 = 0x%08x).\n\n", machine_nr);
                dump_machine_table(); /* does not return */
        }

http://lxr.free-electrons.com/source/arch/arm/kernel/atags_parse.c#L182

[pelwell]

I'd just reached the same conclusion. A stray dtoverlay was failing because of missing labels and aborting the DT support.

With an empty config.txt it boots.

[pelwell]

The firmware patch that implements this feature depends on a more complex patch to the loader. Once we're happy that both patches are good they will appear in a future release.

[notro]

Thank you.

[pelwell]

@popcornmix has pushed the updated firmware.

[notro]

That worked just fine, thank you!

[notro]

@pelwell Booting ARCH_BCM2835 with an overlay that references an unknown label prevents the kernel from booting:

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x00000c42).

Available machine support:

ID (hex)        NAME
ffffffff        Generic DT based system
ffffffff        BCM2835

Please check your kernel config and/or bootloader.

I guess the loader falls back to atags when there is a problem with the overlay, but this is not good on ARCH_BCM2835. Better drop the overlay(s) and use the DT as-is.
This is probably what you experienced when you tested earlier.

[pelwell]

@popcornmix already has a firmware patch from me to make the loader much more resilient when faced with errors like that.

[pelwell]

The latest firmware (released yesterday) includes the patch.