Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need help with Device Tree #381

Closed
notro opened this issue Sep 21, 2013 · 81 comments
Closed

Need help with Device Tree #381

notro opened this issue Sep 21, 2013 · 81 comments

Comments

@notro
Copy link
Contributor

notro commented Sep 21, 2013

I'm trying to get Device Tree working, but has failed in my attempts so far.
I have seen that it's reported working with U-boot, but I'm distributing my kernel with rpi-update, so I would like this to work without U-boot. Is it even possible?
I tried adding all config.txt parameters from https://github.com/raspberrypi/linux/wiki/How-to-boot-using-device-tree, but then it wouldn't boot. So I only use the device_tree* parameters.

I'm using the next firmware with the rpi-3.10.y branch from raspberrypi/linux and use the device tree test data.

Added to kernel config

Boot options  --->
  [*] Flattened Device Tree support

Device Drivers  --->  Device Tree and Open Firmware support  --->
  [*] Support for device tree in /proc
  [*] Device Tree Runtime self tests

bcm2708.dts

/dts-v1/;
/include/ "testcases/tests.dtsi"

Compile device tree

./linux/scripts/dtc/dtc linux/arch/arm/boot/dts/bcm2708.dts -O dtb -o bcm2708.dtb

Added to /boot/config.txt

device_tree=bcm2708.dtb
device_tree_address=0x100

Kernel boot messages

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.12+ (pi@raspi1) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #1 Fri Sep 20 22:51:32 CEST 2013
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: BCM2708
[    0.000000] cma: CMA: reserved 16 MiB at 1b000000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
[    0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x4939788f smsc95xx.macaddr=B8:27:EB:39:78:8F sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 448MB = 448MB total
[    0.000000] Memory: 430684k/430684k available, 28068k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0614cf4   (6196 kB)
[    0.000000]       .init : 0xc0615000 - 0xc0659aa0   ( 275 kB)
[    0.000000]       .data : 0xc065a000 - 0xc069d968   ( 271 kB)
[    0.000000]        .bss : 0xc069d968 - 0xc076e968   ( 836 kB)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1


[    2.558239] ### dt-test ### No testcase data in device tree; not running tests

Nothing in proc

pi@raspberrypi:~$ ls -l /proc/device-tree/
total 0

Why?
I want to use Device Tree to configure some framebuffer drivers I'm working on, not the base drivers.

Framebuffer drivers: https://github.com/notro/fbtft
rpi-update distributed kernel: https://github.com/notro/rpi-firmware

@popcornmix
Copy link
Collaborator

Read:
#24
first. As far as I know, the firmware populating the device tree was largely working, but there is probably a bug remaining. If you can dump the device tree recieved by the kernel and spot any discrepancies then I expect I can fix the firmware.

@notro
Copy link
Contributor Author

notro commented Sep 23, 2013

I have tested three scenarios:

Firmware boot without disable_commandline_tags
The kernel boots, but the Device Tree test case is not found.
The kernel command line does not reflect the one in bcm2708.dtb
Nothing in /proc/device-tree

Firmware boot with disable_commandline_tags=1
Nothing happens

U-boot
Device Tree tests is passed
/proc/device-tree is populated

Am I doing something wrong in the Firmware boot case?

I also tried setting config.txt: device_tree= to a nonextisting file, but no error message.

Additional kernel config changes

Kernel hacking  ---> 
    [*] Kernel low-level debugging functions (read help!)
        Kernel low-level debugging port (Broadcom BCM2708 UART0 (PL011))  --->
            (X) Broadcom BCM2708 UART0 (PL011)
    [*] Early printk

Kernel source changes

I got this error (using U-boot) before changing arch/arm/mach-bcm2708/bcm2708.c:

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported device tree compatible list:
[ 'brcm,bcm2708' ]

Available machine support:

ID (hex)        NAME
00000c42        BCM2708

Please check your kernel config and/or bootloader.

arch/arm/mach-bcm2708/bcm2708.c

diff --git a/arch/arm/mach-bcm2708/bcm2708.c b/arch/arm/mach-bcm2708/bcm2708.c
index 5662c1a..40d7ef1 100644
--- a/arch/arm/mach-bcm2708/bcm2708.c
+++ b/arch/arm/mach-bcm2708/bcm2708.c
@@ -900,6 +903,11 @@ static void __init board_reserve(void)
 #endif
 }

+static const char * const bcm2708_compat[] = {
+       "brcm,bcm2708",
+       NULL
+};
+
 MACHINE_START(BCM2708, "BCM2708")
     /* Maintainer: Broadcom Europe Ltd. */
        .map_io = bcm2708_map_io,
@@ -909,6 +917,7 @@ MACHINE_START(BCM2708, "BCM2708")
        .init_early = bcm2708_init_early,
        .reserve = board_reserve,
        .restart        = bcm2708_restart,
+       .dt_compat = bcm2708_compat,
 MACHINE_END

 module_param(boardrev, uint, 0644);

arch/arm/boot/dts/bcm2708.dts

/dts-v1/;
/include/ "bcm2835.dtsi"

/ {
    compatible = "brcm,bcm2708";
    model = "BCM2708";

    memory {
        reg = <0 0x10000000>;
    };

    chosen {
        bootargs = "earlyprintk loglevel=8 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x4939788f smsc95xx.macaddr=B8:27:EB:39:78:8F sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait";
    };

    soc {
    };
};

/include/ "testcases/tests.dtsi"

Fimware boot without disable_commandline_tags

/boot/config.txt

device_tree=bcm2708.dtb
#disable_commandline_tags=1

Kernel messages

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.12+ (pi@raspi1) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #3 Mon Sep 23 19:44:32 CEST 2013
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: BCM2708
[    0.000000] cma: CMA: reserved 16 MiB at 1b000000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
[    0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x4939788f smsc95xx.macaddr=B8:27:EB:39:78:8F sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait


[    2.567583] ### dt-test ### No testcase data in device tree; not running tests

øø
Debian GNU/Linux 7 raspberrypi ttyAMA0

raspberrypi login:

/proc/device-tree

pi@raspberrypi:~$ ls -l /proc/device-tree/
total 0

Fimware boot with disable_commandline_tags=1

/boot/config.txt

device_tree=bcm2708.dtb
disable_commandline_tags=1

Kernel messages

nothing happens

U-boot

Built from git.denx.de/u-boot-arm.git


U-Boot 2013.10-rc2-15890-gad31ff6 (Sep 22 2013 - 15:12:08)

DRAM:  448 MiB
WARNING: Caches not enabled
MMC:   bcm2835_sdhci: 0
Using default environment

In:    serial
Out:   lcd
Err:   lcd
Hit any key to stop autoboot:  0
mmc0 is current device
reading boot.scr.uimg
** Unable to read file boot.scr.uimg **

U-Boot> fatload ${devtype} ${devnum}:1 ${kernel_addr_r} /uImage.img
reading /uImage.img
3301280 bytes read in 524 ms (6 MiB/s)

U-Boot> fatload ${devtype} ${devnum}:1 ${fdt_addr_r} /bcm2708.dtb
reading /bcm2708.dtb
3411 bytes read in 14 ms (237.3 KiB/s)

U-Boot> bootm ${kernel_addr_r} - ${fdt_addr_r}
## Booting kernel from Legacy Image at 01000000 ...
   Image Name:   Linux-3.10.12+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3301216 Bytes = 3.1 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x2000000
   Loading Kernel Image ... OK
   Loading Device Tree to 1bb8a000, end 1bb8dd52 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.12+ (pi@raspi1) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #3 Mon Sep 23 19:44:32 CEST 2013
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: BCM2708, model: BCM2708
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: CMA: reserved 16 MiB at 1a800000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 114688
[    0.000000] free_area_init_node: node 0, pgdat c069af8c, node_mem_map c0771000
[    0.000000]   Normal zone: 896 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 114688 pages, LIFO batch:31
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
[    0.000000] Kernel command line: earlyprintk loglevel=8 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x4939788f smsc95xx.macaddr=B8:27:EB:39:78:8F sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 448MB = 448MB total
[    0.000000] Memory: 430668k/430668k available, 28084k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     vmalloc : 0xdc800000 - 0xff000000   ( 552 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0616d5c   (6204 kB)
[    0.000000]       .init : 0xc0617000 - 0xc065bbac   ( 275 kB)
[    0.000000]       .data : 0xc065c000 - 0xc069f988   ( 271 kB)
[    0.000000]        .bss : 0xc069f988 - 0xc0770988   ( 836 kB)
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS:330
[    0.000000] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms
[    0.000000] Switching to timer-based delay loop
[    0.000000] Console: colour dummy device 80x30
[    0.000000] console [tty1] enabled, bootconsole disabled
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
[    0.000000] Linux version 3.10.12+ (pi@raspi1) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #3 Mon Sep 23 19:44:32 CEST 2013
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: BCM2708, model: BCM2708
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: CMA: reserved 16 MiB at 1a800000
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 114688
[    0.000000] free_area_init_node: node 0, pgdat c069af8c, node_mem_map c0771000
[    0.000000]   Normal zone: 896 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 114688 pages, LIFO batch:31
[    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[    0.000000] pcpu-alloc: [0] 0
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 113792
[    0.000000] Kernel command line: earlyprintk loglevel=8 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x4939788f smsc95xx.macaddr=B8:27:EB:39:78:8F sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait


[    2.654689] ### dt-test ### start of selftest - you will see error messages
[    2.663315] ### dt-test ### pass drivers/of/selftest.c:40
[    2.670273] ### dt-test ### pass drivers/of/selftest.c:93
[    2.677175] ### dt-test ### pass drivers/of/selftest.c:93
[    2.684015] ### dt-test ### pass drivers/of/selftest.c:93
[    2.690753] ### dt-test ### pass drivers/of/selftest.c:93
[    2.697457] ### dt-test ### pass drivers/of/selftest.c:93
[    2.704124] ### dt-test ### pass drivers/of/selftest.c:93
[    2.710688] ### dt-test ### pass drivers/of/selftest.c:93
[    2.717214] ### dt-test ### pass drivers/of/selftest.c:93
[    2.723694] ### dt-test ### pass drivers/of/selftest.c:99
[    2.730083] ### dt-test ### pass drivers/of/selftest.c:102
[    2.736548] /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider1
[    2.750460] ### dt-test ### pass drivers/of/selftest.c:107
[    2.757026] /testcase-data/phandle-tests/consumer-a: could not get #phandle-cells-missing for /testcase-data/phandle-tests/provider1
[    2.771091] ### dt-test ### pass drivers/of/selftest.c:110
[    2.777603] /testcase-data/phandle-tests/consumer-a: could not find phandle
[    2.785657] ### dt-test ### pass drivers/of/selftest.c:115
[    2.792230] /testcase-data/phandle-tests/consumer-a: could not find phandle
[    2.800264] ### dt-test ### pass drivers/of/selftest.c:118
[    2.806856] /testcase-data/phandle-tests/consumer-a: arguments longer than property
[    2.816840] ### dt-test ### pass drivers/of/selftest.c:123
[    2.823648] /testcase-data/phandle-tests/consumer-a: arguments longer than property
[    2.834053] ### dt-test ### pass drivers/of/selftest.c:126
[    2.841082] ### dt-test ### start
[    2.845917] ### dt-test ### pass drivers/of/selftest.c:142
[    2.852990] ### dt-test ### pass drivers/of/selftest.c:144
[    2.860031] ### dt-test ### pass drivers/of/selftest.c:146
[    2.867089] ### dt-test ### pass drivers/of/selftest.c:148
[    2.874098] ### dt-test ### pass drivers/of/selftest.c:150
[    2.881063] ### dt-test ### pass drivers/of/selftest.c:152
[    2.887933] ### dt-test ### pass drivers/of/selftest.c:154
[    2.894747] ### dt-test ### end of selftest - PASS


[   10.255991] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[   10.634122] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
øø
Debian GNU/Linux 7 raspberrypi ttyAMA0

raspberrypi login:

/proc/device-tree

pi@raspberrypi:~$ ls -l /proc/device-tree/
total 0
-r--r--r--  1 root root  4 Sep 23 19:19 #address-cells
dr-xr-xr-x  2 root root  0 Sep 23 19:19 aliases
dr-xr-xr-x  2 root root  0 Sep 23 19:19 chosen
dr-xr-xr-x  5 root root  0 Sep 23 19:19 clocks
-r--r--r--  1 root root 13 Sep 23 19:19 compatible
dr-xr-xr-x  2 root root  0 Sep 23 19:19 framebuffer
-r--r--r--  1 root root  4 Sep 23 19:19 interrupt-parent
dr-xr-xr-x  2 root root  0 Sep 23 19:19 memory
-r--r--r--  1 root root  8 Sep 23 19:19 model
-r--r--r--  1 root root  1 Sep 23 19:19 name
-r--r--r--  1 root root  4 Sep 23 19:19 #size-cells
dr-xr-xr-x 12 root root  0 Sep 23 19:19 soc
dr-xr-xr-x  3 root root  0 Sep 23 19:19 testcase-data

@popcornmix
Copy link
Collaborator

You want these settings:

device_tree=bcm2835.dtb
device_tree_address=0x100
kernel_address=0x8000
disable_commandline_tags=1

Do you have a uart attached?
With these settings and a stock kernel, I can see uart output.
It's not very happy due to the mising atags/command line but it shows the kernel is booting with disable_commandline_tags enabled.

http://pastebin.com/Bi28A5jw

@P33M
Copy link
Contributor

P33M commented Sep 23, 2013

I'm going to interject a bit here:

If you have a multi-platform enabled kernel, it will always panic because the machine ID passed in r1 is the 2708 machine ID. Multi-platform relies on the correct device tree being passed in r2 by the bootloader, thus the kernel expects the machine ID to be 0xFFFFFFFF if a specific arch hasn't been compiled in.

For reference: http://lwn.net/Articles/496400/

(I think the 2835 mainline port has actually been converted to multi-platform, therefore won't boot unless you use U-boot)

@popcornmix
Copy link
Collaborator

So would a config.txt option (e.g. linux_machine_id=0xffffffff) be useful (it will find it's way into r2 on kernel boot).

@notro
Copy link
Contributor Author

notro commented Sep 24, 2013

I haven't been able to replicate what you did. Which kernel is the 'stock kernel' ?

I have tested raspberrypi/linux:3.10.y and torvalds/linux.

Image: 2013-09-10-wheezy-raspbian

config.txt

device_tree=bcm2835-rpi-b.dtb
device_tree_address=0x100
kernel_address=0x8000
disable_commandline_tags=1

Added to arch/arm/boot/dts/bcm2835-rpi-b.dts

    chosen {
        bootargs = "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait";
    };

Build

make mrproper
make bcm2835_defconfig
make -j4

Copy:
arch/arm/boot/Image -> /boot/kernel.img
arch/arm/boot/dts/bcm2835-rpi-b.dtb -> /boot/bcm2835-rpi-b.dtb

raspberrypi/linux 3.10.y

[    0.000000] Linux version 3.10.12+ (pi@raspi1) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #1 Tue Sep 24 09:27:00 CEST 2013
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: BCM2835, model: Raspberry Pi Model B

[    0.706014] VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5
ø[    0.715692] Waiting for root device /dev/mmcblk0p2...
[    0.756968] mmc0: new SDHC card at address e624
[    0.762077] mmcblk0: mmc0:e624 SU16G 14.8 GiB
[    0.769401]  mmcblk0: p1 p2
[   10.837267] mmc0: Timeout waiting for hardware interrupt - cmd18.
[   10.843613] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[   10.852787] mmcblk0: error -110 transferring data, sector 122882, nr 2, cmd response 0x900, card status 0x0
[   10.862551] mmcblk0: retrying using single block read
[   20.877265] mmc0: Timeout waiting for hardware interrupt - cmd18.
[   30.897265] mmc0: Timeout waiting for hardware interrupt - cmd12.
[   40.917279] mmc0: Timeout waiting for hardware interrupt - cmd13.
[   40.923507] mmcblk0: error -110 sending status command, retrying
[   50.957278] mmc0: Timeout waiting for hardware interrupt - cmd13.
[   50.963500] mmcblk0: error -110 sending status command, retrying

https://gist.github.com/notro/6687398

torvalds/linux

[    0.000000] Linux version 3.12.0-rc1 (pi@raspi1) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #2 Tue Sep 24 00:46:31 CEST 2013
[    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: BCM2835, model: Raspberry Pi Model B

[info] Skipping font and keymap setup (handled by console-setup).
[ ok ] Setting up console font and keymap...done.
[ ok ] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.
INIT: PANIC: segmentation violation! sleeping for 30 seconds.

https://gist.github.com/notro/6687345

@P33M
Copy link
Contributor

P33M commented Sep 24, 2013

@popcornmix

It would be useful in the long term for "generic" multiarch kernels to boot on the Pi. Basically a kernel compiled for an ARM1176 / ARMv6 processor (and had necessary device drivers built-in) would run on anything that provided it with a device tree with enough compatible devices. r1 needs to be 0xfffffff in these cases, indicating that the bootloader has passed through a devicetree describing the machine, rather than r1 being one of the set-in-stone machine IDs.

In the short term, it would allow for building multiarch kernels with a pi-specific DTB appended to the kernel zImage. This is useful for getting the dtb correct in the first place before pushing it across to videocore which (in theory) can then magically determine if we are running on a model A / B / rev1 / rev2 and pass the necessary stuff across (ram size in particular).

r2 still ends up as a pointer to ATAGS, but the kernel basically ignores ATAGS if a device tree tag is present.

@popcornmix
Copy link
Collaborator

My kernel is from "sudo BRANCH=next rpi-update".
It is a non-device tree kernel. I've never attempted to run with bcm2835_defconfig.

I was just suggesting that the there is enough life in the kernel boot with the device tree config.txt options to get some debug infomation out (e.g. with printk through uart).

If you can perhaps dump the raw binary device tree data when booting from uboot and when booting direct, we might see where the problem is.

@notro
Copy link
Contributor Author

notro commented Sep 25, 2013

With a Device Tree enabled kernel and disable_commandline_tags=1 (and the other lines), I get nothing on the console after reset.
Removing that line, it boots fine using atags.
Booting with U-boot and Device Tree works fine.

Since not even Booting Linux on physical CPU 0 is displayed, the problem seems to be before start_kernel() is called, since a non Device Tree kernel boots with disable_commandline_tags=1.
I don't know assembly, so I'm lost here.

config.txt

device_tree=bcm2835-rpi-b.dtb
device_tree_address=0x100
kernel_address=0x8000
disable_commandline_tags=1

Relevant source code snippets

arch/arm/kernel/head-common.S

/*
 * The following fragment of code is executed with the MMU on in MMU mode,
 * and uses absolute addresses; this is not position independent.
 *
 *  r0  = cp#15 control register
 *  r1  = machine ID
 *  r2  = atags/dtb pointer
 *  r9  = processor ID
 */
[...]

    b       start_kernel
[...]
    .long   __atags_pointer                 @ r6
[...]

source/init/main.c

asmlinkage void __init start_kernel(void)
{
    char * command_line;
    extern const struct kernel_param __start___param[], __stop___param[];

    /*
     * Need to run as early as possible, to initialize the
     * lockdep hash:
     */
    lockdep_init();
    smp_setup_processor_id();
[...]
    setup_arch(&command_line);
[...]
}

arch/arm/kernel/setup.c

void __init smp_setup_processor_id(void)
{
[...]
    printk(KERN_INFO "Booting Linux on physical CPU 0x%x\n", mpidr);
}

arch/arm/kernel/setup.c

void __init setup_arch(char **cmdline_p)
{

    struct machine_desc *mdesc;

    setup_processor();
    mdesc = setup_machine_fdt(__atags_pointer);
    if (!mdesc)
        mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
[...]
}

arch/arm/kernel/devtree.c

/**
 * setup_machine_fdt - Machine setup when an dtb was passed to the kernel
 * @dt_phys: physical address of dt blob
 *
 * If a dtb was passed to the kernel in r2, then use it to choose the
 * correct machine_desc and to setup the system.
 */
struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
{
    struct boot_param_header *devtree;
[...]
    if (!dt_phys)
        return NULL;

    devtree = phys_to_virt(dt_phys);

    /* check device tree validity */
    if (be32_to_cpu(devtree->magic) != OF_DT_HEADER)
        return NULL;
[...]
    pr_info("Machine: %s, model: %s\n", mdesc_best->name, model);
[...]
}

arch/arm/kernel/atags_parse.c

struct machine_desc * __init setup_machine_tags(phys_addr_t __atags_pointer,
                                                unsigned int machine_nr)
{
[...]
    for_each_machine_desc(p)
        if (machine_nr == p->nr) {
            printk("Machine: %s\n", p->name);
            mdesc = p;
            break;
        }
[...]
}

Sidenote:
It is possible to see in the kernel messages whether the kernel detects a Device Tree or not.
When a Device Tree is detected, it also prints out model.

setup_machine_fdt()

pr_info("Machine: %s, model: %s\n", mdesc_best->name, model);

setup_machine_tags()

printk("Machine: %s\n", p->name);

@P33M
Copy link
Contributor

P33M commented Sep 25, 2013

If you have early_printk, then the first set of console messages will be printed to the serial console ONLY. Are you connected to the gpio uart?

@notro
Copy link
Contributor Author

notro commented Sep 25, 2013

Yes, I have a serial console and CONFIG_EARLY_PRINTK=y.

@notro
Copy link
Contributor Author

notro commented Sep 25, 2013

I used zImage instead of Image and that gave me

Uncompressing Linux... done, booting the kernel.

@notro
Copy link
Contributor Author

notro commented Sep 26, 2013

I was wrong in my assumption that start_kernel() wasn't called.
Using early_print's I can see more.

I can see that the firmware alters the memory node from 256 to 512MB:
This is what the .dtb file has:

    memory {
        reg = <0 0x10000000>;
    };

This is what the kernel receives and does:

data: 0 20 2000000 1000000,
early_init_dt_add_memory_arch(base=0x0, size=0x20000000)

Anything in particular I should look into ?

Uncompressing Linux... done, booting the kernel.
start_kernel()
setup_machine_fdt(dt_phys=0x100)
    Machine: BCM2708, model: Raspberry Pi Model B
early_init_dt_scan_chosen()
    search "chosen", depth: 0, uname:
early_init_dt_scan_chosen()
    search "chosen", depth: 1, uname: chosen
    Command line is: dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
    early_init_dt_scan_chosen returned 1
early_init_dt_scan_root()
    dt_root_size_cells = 1
    dt_root_addr_cells = 1
    early_init_dt_scan_root returned 1
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
    memory scan node memory, reg size 8, data: 0 20 2000000 1000000,
early_init_dt_add_memory_arch(base=0x0, size=0x20000000)
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
early_init_dt_scan_memory()
    early_init_dt_scan_memory returned 0
Kernel command line: dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
rest_init()
cpu_startup_entry()
cpu_idle_loop()

@notro
Copy link
Contributor Author

notro commented Sep 26, 2013

I have found a way to make zImage boot. U-boot sets the memory size to 0x1C000000 and the firmware sets it to 0x20000000.
Forcing size=0x1C000000 in drivers/of/fdt.c, makes zImage boot also.

Here is a kernel output diff without forcing the size:
https://gist.github.com/notro/6712488

@notro
Copy link
Contributor Author

notro commented Sep 26, 2013

By the way, this is zImage memory without DT

[    0.000000] Memory: 448MB = 448MB total
[    0.000000] Memory: 430716k/430716k available, 28036k reserved, 0K highmem

compared to U-boot with DT

[    0.000000] Memory: 448MB = 448MB total
[    0.000000] Memory: 430708k/430708k available, 28044k reserved, 0K highmem

@popcornmix
Copy link
Collaborator

Is the difference in 0x20000000 and 0x1c000000 due to the gpu_mem?
Is your gpu_mem set to 64M?

Currenly I have: (with 512M part and 64M gpu_mem)
totalmemsize = 512M
memsize = 448M

"/memory/reg" to totalmemsize (e.g. 512M)
and
"//memreserve" to totalmemsize-memsize (e.g. 64M)

Would you prefer I set this to:
"/memory/reg" to memsize (e.g. 448M)
and
"//memreserve" to totalmemsize-memsize (e.g. 64M). Or should this be 0?

@notro
Copy link
Contributor Author

notro commented Sep 26, 2013

Is the difference in 0x20000000 and 0x1c000000 due to the gpu_mem?
Is your gpu_mem set to 64M?

The only parameters I have in config.txt, is the DT related ones. So since the default gpu_mem is 64, I assume it is 64M.

This is how U-boot determines ramsize:
http://git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=blob;f=board/raspberrypi/rpi_b/rpi_b.c;hb=HEAD#l38

With regards to memreserve, it doesn't look like it is used (scripts/dtc/ is excluded):

pi@raspi1:~/3.10/linux$ grep -r memreserve .
./Documentation/arm64/booting.txt:  of memory (communicated to the kernel by a /memreserve/ region in the
./arch/arm/boot/dts/ecx-2000.dts:/memreserve/ 0x00000000 0x0001000;
./arch/arm/boot/dts/omap5.dtsi:/memreserve/ 0x9d000000 0x03000000;
./arch/arm/boot/dts/highbank.dts:/memreserve/ 0x00000000 0x0001000;
./arch/arm/boot/dts/omap4.dtsi:/memreserve/ 0x9d000000 0x03000000;
./arch/arm64/boot/dts/rtsm_ve-aemv8a.dts:/memreserve/ 0x80000000 0x00010000;
./arch/powerpc/boot/dts/currituck.dts:/memreserve/ 0x01f00000 0x00100000;       // spin table
./arch/powerpc/boot/dts/iss4xx-mpic.dts:/memreserve/ 0x01f00000 0x00100000;
./arch/powerpc/boot/dts/wii.dts: * contiguous RAM range and will BUG() if the memreserve is outside
./arch/powerpc/boot/dts/wii.dts:/*/memreserve/ 0x10000000 0x0004000;*/  /* DSP RAM */
./arch/powerpc/boot/dts/mpc836x_mds.dts:/memreserve/    00000000 1000000;
./arch/mips/mti-sead3/sead3.dts:/memreserve/ 0x00000000 0x00001000;     // reserved
./arch/mips/mti-sead3/sead3.dts:/memreserve/ 0x00001000 0x000ef000;     // ROM data
./arch/mips/mti-sead3/sead3.dts:/memreserve/ 0x000f0000 0x004cc000;     // reserved

This is the kernel function that reads the memory node: http://lxr.free-electrons.com/source/drivers/of/fdt.c?v=3.10;a=arm#L613

U-boot seem to honour it: http://lists.linaro.org/pipermail/linaro-kernel/2011-March/000161.html

Does the firmware set memreserve today? I can't find it in /proc/device-tree/

Would you prefer I set this to:
"/memory/reg" to memsize (e.g. 448M)

Yes

and
"//memreserve" to totalmemsize-memsize (e.g. 64M). Or should this be 0?

Skip this one?

@popcornmix
Copy link
Collaborator

#24 requested:
/memreserve/ (u32 offset, u32 size of VideoCore memory - this is not a normal attribute)
/memory/reg with the u32 memory range (e.g. 0x0 0x10000000 for 256MB)

so I am doing as requested by @lp0

I'll agree to change to your requested way at the weekend if no one shouts out that that is incorrect.

@notro
Copy link
Contributor Author

notro commented Sep 26, 2013

I have another request.
Can you make a config.txt parameter: device_tree_bootargs_add=1 or something.
This will add the usual stuff to the chosen/bootargs property, like it does with cmdline.txt in ATAGS mode.

Some of these settings is needed to boot the 3.10.y kernel (I haven't tried to find out which). And this would make a FDT work correct on all boards with regards to bcm2708.boardrev for instance, and macaddr can't be hardcoded either. I don't know if any of the other parameters differ between boards.

usual stuff

dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0xe bcm2708.serial=0x4939788f smsc95xx.macaddr=B8:27:EB:39:78:8F sdhci-bcm2708.emmc_clock_freq=100000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  

@popcornmix
Copy link
Collaborator

The mac address does come through device tree (as does serial/revision)
/axi/usb/hub/ethernet/mac-address
Does the 2835 kernel still use command line arguments for any of these? I'd be interested to know which.

But, yes, in theory I can send the "extended" command line through (just would be nice to know what is actually needed).

@nomis
Copy link
Contributor

nomis commented Sep 26, 2013

/memory/reg is always the total memory
/memreserve/ is the memory to reserve

Just because omitting the reserved memory from /memory/reg works too does not mean it is correct.

@notro
Copy link
Contributor Author

notro commented Sep 26, 2013

The mac address does come through device tree (as does serial/revision)
/axi/usb/hub/ethernet/mac-address

I couldn't find any of those in /proc/device-tree
https://gist.github.com/notro/6718376

Does the 2835 kernel still use command line arguments for any of these? I'd be interested to know which.

I extract the kernel config from the image in the rpi-firmware next branch and add DT support to that.
So I don't know if that qualifies it as a BCM2708 or BCM2835 kernel. The next kernel uses arch/arm/mach-bcm2708/bcm2708.c which I have added .dt_compat support to. So that may qualify it as a BCM2708?
Earlier in the thread I tried bcm2835_defconfig, but that was just for testing.

@popcornmix
Copy link
Collaborator

bcm2835_defconfig will actually use device tree for the hardware, and will purely use upstream kernel code.
bcmrpi_defconfig will not use device tree for any pi specific hardware, and will use our own patches.

@notro
Copy link
Contributor Author

notro commented Sep 26, 2013

Power.org™ Standard for Embedded Power Architecture™ Platform Requirements
(ePAPR)
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf

3.4 Memory node
A memory device node is required for all device trees and describesthe physical memory layout for the system. If a system has multiple ranges of memory, multiple memory nodes can be created, or the ranges can be specified in the reg property of a single memory node.
[...]
The client program may access memory not covered by any memory reservations(see section 8.3) using any storage attributes it chooses.

8.3 Memory Reservation Block
8.3.1 Purpose
The memory reservation block provides the client program with a list of areas in physical memory which are reserved; that is, which shall not be used for general memory allocations. It is used to protect vital data structures from being overwritten by the client program.

/memory/reg is always the total memory

ePAPR states that multiple memory nodes/ranges can be used to describe the physical memory layout. driver/of/fdt.c seem to support that.
I haven't found anything that states that all memory HAS to be accounted for.

/memreserve/ is the memory to reserve

Yes, but I haven't found anything in the 3.10.y tree that uses memreserve. And if that is the case, all memory can't be put in the memory node. Please prove me wrong.

Just because omitting the reserved memory from /memory/reg works too does not mean it is correct.

I agree with that, but I haven't found anything that proves it wrong.

@notro
Copy link
Contributor Author

notro commented Sep 26, 2013

bcm2835_defconfig will actually use device tree for the hardware, and will purely use upstream kernel code.
bcmrpi_defconfig will not use device tree for any pi specific hardware, and will use our own patches.

I want to deviate as little as possible from rpi-firmware. This way I benefit from the tesing of a lot of users. The upstream kernel code doesn't have that yet I believe. And I don't think the users of my kernel want to be part of that testing.

So while in rpi patched kernel land, I would like all extra ATAGS arguments to be added.

When 3.10.y becomes the standard, will the next branch start using Device Tree for the drivers that is already upstream?

@popcornmix
Copy link
Collaborator

We will move the main firmware branch to 3.10 in a few weeks.
Moving to dev tree and 2835 machine is desirable but not planned by me.
It is a significant amount of work, and will cause breakage.
A number of drivers (like vchiq and dwc_otg) are not supported by 2835 and will need patching in.

@nomis
Copy link
Contributor

nomis commented Sep 27, 2013

The code that handles memserve on arm is arm_dt_memblock_reserve() in arch/arm/kernel/devtree.c called from arm_memblock_init() in arch/arm/mm/init.c

I know this works, because when you don't reserve it, the framebuffer memory overlaps with some kernel memory early in the boot process and bad things happen.

@nomis
Copy link
Contributor

nomis commented Sep 27, 2013

I don't see a real benefit to combining the original command line based parameters and device tree support. If you have device tree support enabled then it won't boot without it. All the configuration data should be there in device tree so you can trivially modify the existing drivers to use it.

@notro
Copy link
Contributor Author

notro commented Sep 27, 2013

The code that handles memserve on arm is arm_dt_memblock_reserve() in arch/arm/kernel/devtree.c called from arm_memblock_init() in arch/arm/mm/init.c

Thanks, I stand corrected.

I added this to bcm2835-rpi-b.dts

/memreserve/ 0x9d000000 0x03000000;

And got this output

memblock_reserve: [0x0000009d000000-0x000000a0000000] arm_dt_memblock_reserve+0x94/0xa4

@notro
Copy link
Contributor Author

notro commented Sep 27, 2013

I don't see a real benefit to combining the original command line based parameters and device tree support.

The point is, I don't want to spend a lot of time making all the drivers work with Device Tree. For the moment I only care about some framebuffer drivers and ads7846 (touch controller).
It will be a transitional thing, before having full DT support.
Having that expanded command line, makes the non-DT drivers work. Well, at least they load.

Except that this doesn't look right

[    2.190023] vc-cma: Videocore CMA driver
[    2.195405] vc-cma: vc_cma_base      = 0x00000000
[    2.201428] vc-cma: vc_cma_size      = 0x00000000 (0 MiB)
[    2.208119] vc-cma: vc_cma_initial   = 0x00000000 (0 MiB)

If you have device tree support enabled then it won't boot without it.

Not sure what you mean here.
If you mean DT support is compiled in, but no DT is provided:
With MACH_BCM2708 it will boot, but with ARCH_BCM2835 it won't. I use MACH_2708 as the rpi-firmware does.

All the configuration data should be there in device tree so you can trivially modify the existing drivers to use it.

For me it wouldn't be trivial, since I first looked into Device Tree a week ago, and all the kernel development I have done is writing some framebuffer drivers :-)

It looks like I would have to patch 6 files/drivers to achieve that:

dma.dmachans=0x7f35

bcm2708_fb.fbwidth=656
bcm2708_fb.fbheight=416

bcm2708.boardrev=0xe
bcm2708.serial=0x4939788f

smsc95xx.macaddr=B8:27:EB:39:78:8F

sdhci-bcm2708.emmc_clock_freq=100000000

vc_mem.mem_base=0x1ec00000
vc_mem.mem_size=0x20000000

OK, it's not as bad as I thought. I'll give it a go.
Is this list from #24 valid in the current firmware?

I've updated to these field names:

"/memory/reg";
"/chosen/bootargs";
"/system/linux,revision";
"/system/linux,serial";
"/axi/usb/hub/ethernet/mac-address";
"/axi/dma/broadcom,channels";
"/display/broadcom,width";
"/display/broadcom,height";
"/display/broadcom,depth";
"/axi/sdhci/clock-frequency";
"/axi/uart0/clock-frequency";

@popcornmix
Copy link
Collaborator

One option is to get the dcw_otg driver working with bcm835 and the dwc2 can be considered in the future if it improves.

@P33M
Copy link
Contributor

P33M commented Nov 11, 2013

My opinion:
 Unless the foundation pools some resources into this work, I suspect that it will take a while for BCM2835 to be useful for the Raspberry Pi community at large.
 The USB driver (dwc2) should be a priority.

You are correct. Namely that the missing resource is manpower - a port to the bcm2835 arch is possible (and desirable for a number of reasons) but there is plenty of work required to take the established 2708 port and move it "closer" to mainline.

A good example is the dwc2 driver - Synopsys driver upstreamed by the vendor; it would make sense to publish further updates to that one rather than our current out-of-tree branch if it were in a state where the feature sets of both were comparable.

@notro
Copy link
Contributor Author

notro commented Nov 14, 2013

I now have have a working BCM2835 with USB (dwc2) and networking (no DHCP) based on vanilla 3.12.
Stephen Warren pointed out a patch that I was missing.

Here's the patches I used: https://github.com/notro/rpi-build/tree/master/patches/bcm2835
The first patch is only needed to make one of the other patches apply.
U-Boot is needed with the addition mentioned in: HACK: enable DWC2 OTG on RPi

This is the U-Boot script I used: https://github.com/notro/rpi-build/blob/master/bcm2835.py#L74

@popcornmix
Copy link
Collaborator

@notro sounds interesting. You say no DHCP - is that just something not enabled/tested, or is it not working with dwc2?
Do with your 2835 kernel, what works and what doesn't?
I assume vchiq is missing? Anything else you are aware of?

@notro
Copy link
Contributor Author

notro commented Nov 14, 2013

One option is to get the dcw_otg driver working with bcm835 and the dwc2 can be considered in the future if it improves.

Yes, of course. I failed in my attempt to do so: #393

Does dwc_oth depend on DMA or some other stuff that is not supported by BCM2835?
(Understanding that piece of code, is not for the faint of heart)
And what is FIQ?

@notro
Copy link
Contributor Author

notro commented Nov 14, 2013

You say no DHCP - is that just something not enabled/tested, or is it not working with dwc2?

Not enabled I would say. I tried to find the correct kernel config options, but gave up in the middle of NETFILTER and friends.

Do with your 2835 kernel, what works and what doesn't?

I have only tested that I can ping the outside world, and that it doesn't just die on me. I had it running over night.

I assume vchiq is missing? Anything else you are aware of?

It's easier to list what is present:
gpio (pinctrl), i2c, spi, simplefb (don't have a HDMI to test with), USB (dwc2), LAN.

There are some other patches floating around (mailbox and i2s at least), but I haven't looked into them.

What is vchiq?

@nomis
Copy link
Contributor

nomis commented Nov 14, 2013

There is mailbox code here: nomis/linux@917bdfc

It needs to be updated for the new kernel interface.

@koalo
Copy link
Contributor

koalo commented Nov 14, 2013

Hurray! It really works!
Networking is running fine (ssh).
HDMI does not run out of the box. The u-boot message appears, but nothing else.

And of course: I2S audio is working ;-)
(with the patches submitted to the mailing list)

Are these patches already in the swarren repo or have you changed anything in the patches?

@notro
Copy link
Contributor Author

notro commented Nov 14, 2013

Are these patches already in the swarren repo or have you changed anything in the patches?

Yes, I have just copied them.

@notro
Copy link
Contributor Author

notro commented Nov 14, 2013

I have also added most of the patches from: https://github.com/hackerspace/rpi-linux/commits/lr-usb

https://github.com/notro/rpi-build/tree/master/patches/bcm2835
Only those that end with .patch is applied.

Here's the boot log from that build: https://gist.github.com/notro/7475528
One thing stands out:

[    2.361561] bcm2835-mbox 2000b880.mailbox: Bad response from property mailbox
[    2.368779] bcm2835-mbox 2000b880.mailbox: overflow on channel (8)

I will continue tomorrow going through the mailing list to see what's there. At least I2S I understand. Hopefully an updated mailbox driver as well.

@nomis
Copy link
Contributor

nomis commented Nov 14, 2013

My version of the mailbox driver doesn't have this obscure idea of an "overflow" when reading from a mailbox.

@popcornmix
Copy link
Collaborator

Does dwc_oth depend on DMA or some other stuff that is not supported by BCM2835?

No DMA. I can't think of a reason for dwc_otg not to work on 2835.

And what is FIQ?

Fast interrupt. A single interrupt can be designated as the FIQ, and a much faster/cheaper interrupt service routine is used. On Pi we designate the USB interrupt as the FIQ as it generates >8000 interrupts/second.
The majority of these interrupts we handle in the FIQ, and only fall back to the IRQ when there is more complicated processing that needs to be done from an IRQ context (i.e. calling kernel functions).
Using the FIQ gains about 10% performance in most cases.

You are probably better off disabling the FIQ initially (dwc_otg.fiq_fix_enable=0) in case that is causing a problem.

@cleverca22
Copy link

i'm trying to get a kernel from the rpi-3.10.y branch to boot using device tree, and it appears to be locking up at either the semaphores, irq, or mailbox

https://github.com/raspberrypi/linux/blob/rpi-3.10.y/arch/arm/mach-bcm2708/power.c#L101
this line in the power code to read a mailbox never returns
and i've traced it to a down() call over in vcio.c
https://github.com/raspberrypi/linux/blob/rpi-3.10.y/arch/arm/mach-bcm2708/vcio.c#L125
the irq in mbox_irq is never ran

the only other difference i can see, is that down() with atags leads to cpu_idle_loop and the irq
but down() with devicetree just hangs

am i right to assume that the semaphore isnt releasing the cpu and allowing the irq?

@notro
Copy link
Contributor Author

notro commented Nov 18, 2013

i'm trying to get a kernel from the rpi-3.10.y branch to boot using device tree

Unpatched, or with my patches? From your references I assume you use ARCH_BCM2708 (bcmrpi_defconfig)?

@cleverca22
Copy link

i only have the .dt_compat patch, i'll go over your other posts and look for more after supper if i don't have a reply by then

using a slightly modified default config, which can boot when atags are enabled, and it has early_printk

@notro
Copy link
Contributor Author

notro commented Feb 26, 2014

I have a solution to my original problem: How to load devices from Device Tree for some video drivers.

The solution is a builtin module that can load a Device Tree from /lib/firmware.
I also have a pinctrl module (copied from pinctrl-bcm2835.c).
https://github.com/notro/fdt_loader
https://github.com/notro/fdt_loader/wiki

I went this route because of all the problems I faced getting full DT support.
fdt_loader hasn't been tested much yet, as the drivers that will use it is still in the design phase.

fdt_loader has to be builtin to get DT alias support, since of_alias_scan() is not exported.

@cleverca22
Copy link

that sounds like it may be one way to solve the MPR121 issues i had

the driver expects the element->keyboard mapping to be under platform_data, which currently must be compiled into a shim driver that simply says 'this hardware is present on the platform, here is the key mapping'

basically, exactly what DT is meant to replace
but the issue i ran into, is that the kernel cant spawn an i2c slave driver without first having the entire i2c bus present in the DT

@notro
Copy link
Contributor Author

notro commented Mar 3, 2014

You can use i2c-bcm2835.c instead, which has DT support.
Just hack Kconfig to depend on ARCH_BCM2708 so you can enable it: http://lxr.free-electrons.com/source/drivers/i2c/busses/Kconfig?v=3.10;a=arm#L334

This patch is probably relevant for your use case: http://lists.infradead.org/pipermail/linux-rpi-kernel/2013-November/000744.html

Or as I did with spi-bcm2708, add DT support to i2c-bcm2708 and use the fdt_loader argument: remove-pdevs=bcm2708_i2c.0 to remove the device added in arch/arm/mach-bcm2708/bcm2708.c

@notro notro closed this as completed Mar 10, 2014
popcornmix pushed a commit that referenced this issue Apr 10, 2017
In crc32c_vpmsum() we call enable_kernel_altivec() without first
disabling preemption, which is not allowed:

  WARNING: CPU: 9 PID: 2949 at ../arch/powerpc/kernel/process.c:277 enable_kernel_altivec+0x100/0x120
  Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c vmx_crypto ...
  CPU: 9 PID: 2949 Comm: docker Not tainted 4.11.0-rc5-compiler_gcc-6.3.1-00033-g308ac7563944 #381
  ...
  NIP [c00000000001e320] enable_kernel_altivec+0x100/0x120
  LR [d000000003df0910] crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum]
  Call Trace:
    0xc138fd09 (unreliable)
    crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum]
    crc32c_vpmsum_update+0x3c/0x60 [crc32c_vpmsum]
    crypto_shash_update+0x88/0x1c0
    crc32c+0x64/0x90 [libcrc32c]
    dm_bm_checksum+0x48/0x80 [dm_persistent_data]
    sb_check+0x84/0x120 [dm_thin_pool]
    dm_bm_validate_buffer.isra.0+0xc0/0x1b0 [dm_persistent_data]
    dm_bm_read_lock+0x80/0xf0 [dm_persistent_data]
    __create_persistent_data_objects+0x16c/0x810 [dm_thin_pool]
    dm_pool_metadata_open+0xb0/0x1a0 [dm_thin_pool]
    pool_ctr+0x4cc/0xb60 [dm_thin_pool]
    dm_table_add_target+0x16c/0x3c0
    table_load+0x184/0x400
    ctl_ioctl+0x2f0/0x560
    dm_ctl_ioctl+0x38/0x50
    do_vfs_ioctl+0xd8/0x920
    SyS_ioctl+0x68/0xc0
    system_call+0x38/0xfc

It used to be sufficient just to call pagefault_disable(), because that
also disabled preemption. But the two were decoupled in commit 8222dbe
("sched/preempt, mm/fault: Decouple preemption from the page fault
logic") in mid 2015.

So add the missing preempt_disable/enable(). We should also call
disable_kernel_fp(), although it does nothing by default, there is a
debug switch to make it active and all enables should be paired with
disables.

Fixes: 6dd7a82 ("crypto: powerpc - Add POWER8 optimised crc32c")
Cc: [email protected] # v4.8+
Signed-off-by: Michael Ellerman <[email protected]>
ED6E0F17 pushed a commit to ED6E0F17/linux that referenced this issue Apr 12, 2017
commit 4749228 upstream.

In crc32c_vpmsum() we call enable_kernel_altivec() without first
disabling preemption, which is not allowed:

  WARNING: CPU: 9 PID: 2949 at ../arch/powerpc/kernel/process.c:277 enable_kernel_altivec+0x100/0x120
  Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c vmx_crypto ...
  CPU: 9 PID: 2949 Comm: docker Not tainted 4.11.0-rc5-compiler_gcc-6.3.1-00033-g308ac7563944 raspberrypi#381
  ...
  NIP [c00000000001e320] enable_kernel_altivec+0x100/0x120
  LR [d000000003df0910] crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum]
  Call Trace:
    0xc138fd09 (unreliable)
    crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum]
    crc32c_vpmsum_update+0x3c/0x60 [crc32c_vpmsum]
    crypto_shash_update+0x88/0x1c0
    crc32c+0x64/0x90 [libcrc32c]
    dm_bm_checksum+0x48/0x80 [dm_persistent_data]
    sb_check+0x84/0x120 [dm_thin_pool]
    dm_bm_validate_buffer.isra.0+0xc0/0x1b0 [dm_persistent_data]
    dm_bm_read_lock+0x80/0xf0 [dm_persistent_data]
    __create_persistent_data_objects+0x16c/0x810 [dm_thin_pool]
    dm_pool_metadata_open+0xb0/0x1a0 [dm_thin_pool]
    pool_ctr+0x4cc/0xb60 [dm_thin_pool]
    dm_table_add_target+0x16c/0x3c0
    table_load+0x184/0x400
    ctl_ioctl+0x2f0/0x560
    dm_ctl_ioctl+0x38/0x50
    do_vfs_ioctl+0xd8/0x920
    SyS_ioctl+0x68/0xc0
    system_call+0x38/0xfc

It used to be sufficient just to call pagefault_disable(), because that
also disabled preemption. But the two were decoupled in commit 8222dbe
("sched/preempt, mm/fault: Decouple preemption from the page fault
logic") in mid 2015.

So add the missing preempt_disable/enable(). We should also call
disable_kernel_fp(), although it does nothing by default, there is a
debug switch to make it active and all enables should be paired with
disables.

Fixes: 6dd7a82 ("crypto: powerpc - Add POWER8 optimised crc32c")
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
popcornmix pushed a commit that referenced this issue Apr 13, 2017
commit 4749228 upstream.

In crc32c_vpmsum() we call enable_kernel_altivec() without first
disabling preemption, which is not allowed:

  WARNING: CPU: 9 PID: 2949 at ../arch/powerpc/kernel/process.c:277 enable_kernel_altivec+0x100/0x120
  Modules linked in: dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c vmx_crypto ...
  CPU: 9 PID: 2949 Comm: docker Not tainted 4.11.0-rc5-compiler_gcc-6.3.1-00033-g308ac7563944 #381
  ...
  NIP [c00000000001e320] enable_kernel_altivec+0x100/0x120
  LR [d000000003df0910] crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum]
  Call Trace:
    0xc138fd09 (unreliable)
    crc32c_vpmsum+0x108/0x150 [crc32c_vpmsum]
    crc32c_vpmsum_update+0x3c/0x60 [crc32c_vpmsum]
    crypto_shash_update+0x88/0x1c0
    crc32c+0x64/0x90 [libcrc32c]
    dm_bm_checksum+0x48/0x80 [dm_persistent_data]
    sb_check+0x84/0x120 [dm_thin_pool]
    dm_bm_validate_buffer.isra.0+0xc0/0x1b0 [dm_persistent_data]
    dm_bm_read_lock+0x80/0xf0 [dm_persistent_data]
    __create_persistent_data_objects+0x16c/0x810 [dm_thin_pool]
    dm_pool_metadata_open+0xb0/0x1a0 [dm_thin_pool]
    pool_ctr+0x4cc/0xb60 [dm_thin_pool]
    dm_table_add_target+0x16c/0x3c0
    table_load+0x184/0x400
    ctl_ioctl+0x2f0/0x560
    dm_ctl_ioctl+0x38/0x50
    do_vfs_ioctl+0xd8/0x920
    SyS_ioctl+0x68/0xc0
    system_call+0x38/0xfc

It used to be sufficient just to call pagefault_disable(), because that
also disabled preemption. But the two were decoupled in commit 8222dbe
("sched/preempt, mm/fault: Decouple preemption from the page fault
logic") in mid 2015.

So add the missing preempt_disable/enable(). We should also call
disable_kernel_fp(), although it does nothing by default, there is a
debug switch to make it active and all enables should be paired with
disables.

Fixes: 6dd7a82 ("crypto: powerpc - Add POWER8 optimised crc32c")
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
popcornmix pushed a commit that referenced this issue Jun 17, 2020
commit e18035c upstream.

Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink
implementation.  The code is fine, but generates a lockdep complaint:

============================================
WARNING: possible recursive locking detected
5.7.1mq+ #381 Tainted: G           O
--------------------------------------------
pulseaudio/4180 is trying to acquire lock:
ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm]

but task is already holding lock:
ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&group->lock);
  lock(&group->lock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by pulseaudio/4180:
 #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm]
 #1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
[...]

Cc: [email protected]
Fixes: f57f3df ("ALSA: pcm: More fine-grained PCM link locking")
Signed-off-by: Michał Mirosław <[email protected]>
Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Signed-off-by: Takashi Iwai <[email protected]>
popcornmix pushed a commit that referenced this issue Jun 17, 2020
commit e18035c upstream.

Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink
implementation.  The code is fine, but generates a lockdep complaint:

============================================
WARNING: possible recursive locking detected
5.7.1mq+ #381 Tainted: G           O
--------------------------------------------
pulseaudio/4180 is trying to acquire lock:
ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm]

but task is already holding lock:
ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&group->lock);
  lock(&group->lock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by pulseaudio/4180:
 #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm]
 #1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
[...]

Cc: [email protected]
Fixes: f57f3df ("ALSA: pcm: More fine-grained PCM link locking")
Signed-off-by: Michał Mirosław <[email protected]>
Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Signed-off-by: Takashi Iwai <[email protected]>
popcornmix pushed a commit that referenced this issue Jun 17, 2020
commit e18035c upstream.

Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink
implementation.  The code is fine, but generates a lockdep complaint:

============================================
WARNING: possible recursive locking detected
5.7.1mq+ #381 Tainted: G           O
--------------------------------------------
pulseaudio/4180 is trying to acquire lock:
ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm]

but task is already holding lock:
ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&group->lock);
  lock(&group->lock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by pulseaudio/4180:
 #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm]
 #1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
[...]

Cc: [email protected]
Fixes: f57f3df ("ALSA: pcm: More fine-grained PCM link locking")
Signed-off-by: Michał Mirosław <[email protected]>
Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Signed-off-by: Takashi Iwai <[email protected]>
sigmaris pushed a commit to sigmaris/linux that referenced this issue Jun 27, 2020
Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink
implementation.  The code is fine, but generates a lockdep complaint:

============================================
WARNING: possible recursive locking detected
5.7.1mq+ raspberrypi#381 Tainted: G           O
--------------------------------------------
pulseaudio/4180 is trying to acquire lock:
ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm]

but task is already holding lock:
ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&group->lock);
  lock(&group->lock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

2 locks held by pulseaudio/4180:
 #0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm]
 raspberrypi#1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
[...]

Cc: [email protected]
Fixes: f57f3df ("ALSA: pcm: More fine-grained PCM link locking")
Signed-off-by: Michał Mirosław <[email protected]>
Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl

Signed-off-by: Takashi Iwai <[email protected]>
herrnst pushed a commit to herrnst/linux-raspberrypi that referenced this issue Jan 2, 2023
…nslate the same key

[ Upstream commit 5476fcf ]

The hid-apple driver does not support chaining translations or
dependencies on other translations. This creates two problems:

1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are
swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this
problem. The quirk is not set for the Macs where these bugs happen yet
(see the 2nd patch for that), but this can be forced by setting the
iso_layout parameter. Unfortunately, this only partially works.
KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get
translated to KEY_102ND, so both of them end up functioning as
KEY_GRAVE. This is because the driver translates the keys as if Fn was
pressed and the original is sent if it is not pressed, without any
further translations happening on the key[raspberrypi#463]. KEY_GRAVE is present at
macbookpro_no_esc_fn_keys[raspberrypi#195], so this is what happens:

    - KEY_GRAVE -> KEY_ESC (as if Fn is pressed)
    - KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded)
    - KEY_GRAVE -> KEY_102ND (this part is not reached!)
    ...

2 - In case the touchbar does not work, the driver supports sending
Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND
is actually KEY_GRAVE and needs to be translated before this happens.

Normally, these are the steps that should happen:

    - KEY_102ND -> KEY_GRAVE
    - KEY_GRAVE -> KEY_ESC (Fn is pressed)
    - KEY_ESC is returned

Though this is what happens instead, as dependencies on other
translations are not supported:

    - KEY_102ND -> KEY_ESC (Fn is pressed)
    - KEY_ESC is returned

This patch fixes both bugs by ordering the translations correctly and by
making the translations continue and not return immediately after
translating a key so that chained translations work and translations can
depend on other ones.

This patch also simplifies the implementation of the swap_fn_leftctrl
option a little bit, as it makes it simply use a normal translation
instead adding extra code to translate a key to KEY_FN[raspberrypi#381]. This change
wasn't put in another patch as the code that translates the Fn key needs
to be changed because of the changes in the patch, and those changes
would be discarded with the next patch anyway (the part that originally
translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of
the part that transltes KEY_LEFTCTRL to KEY_FN).

Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit
20afcc4 ("HID: apple: Add "GANSS" to the non-Apple list").

Note: These bugs are only present on Macs with a keyboard with no
dedicated escape key and a non-English layout.

Signed-off-by: Kerem Karabay <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
popcornmix pushed a commit that referenced this issue Jan 3, 2023
…nslate the same key

[ Upstream commit 5476fcf ]

The hid-apple driver does not support chaining translations or
dependencies on other translations. This creates two problems:

1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are
swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this
problem. The quirk is not set for the Macs where these bugs happen yet
(see the 2nd patch for that), but this can be forced by setting the
iso_layout parameter. Unfortunately, this only partially works.
KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get
translated to KEY_102ND, so both of them end up functioning as
KEY_GRAVE. This is because the driver translates the keys as if Fn was
pressed and the original is sent if it is not pressed, without any
further translations happening on the key[#463]. KEY_GRAVE is present at
macbookpro_no_esc_fn_keys[#195], so this is what happens:

    - KEY_GRAVE -> KEY_ESC (as if Fn is pressed)
    - KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded)
    - KEY_GRAVE -> KEY_102ND (this part is not reached!)
    ...

2 - In case the touchbar does not work, the driver supports sending
Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND
is actually KEY_GRAVE and needs to be translated before this happens.

Normally, these are the steps that should happen:

    - KEY_102ND -> KEY_GRAVE
    - KEY_GRAVE -> KEY_ESC (Fn is pressed)
    - KEY_ESC is returned

Though this is what happens instead, as dependencies on other
translations are not supported:

    - KEY_102ND -> KEY_ESC (Fn is pressed)
    - KEY_ESC is returned

This patch fixes both bugs by ordering the translations correctly and by
making the translations continue and not return immediately after
translating a key so that chained translations work and translations can
depend on other ones.

This patch also simplifies the implementation of the swap_fn_leftctrl
option a little bit, as it makes it simply use a normal translation
instead adding extra code to translate a key to KEY_FN[#381]. This change
wasn't put in another patch as the code that translates the Fn key needs
to be changed because of the changes in the patch, and those changes
would be discarded with the next patch anyway (the part that originally
translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of
the part that transltes KEY_LEFTCTRL to KEY_FN).

Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit
20afcc4 ("HID: apple: Add "GANSS" to the non-Apple list").

Note: These bugs are only present on Macs with a keyboard with no
dedicated escape key and a non-English layout.

Signed-off-by: Kerem Karabay <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
valkerice112 pushed a commit to valkerice112/Raspi-Firmware that referenced this issue Jan 9, 2025
…isconnected

See http://forum.stmlabs.com/showthread.php?tid=11053

firmware: gencmd: Add option to enable force_audio at runtime

firmware: audioplus: Need to close/open a forced hdmi output when channels change

bootcode: Updates to speed up bootocode sdcard accesses from gsh

firmware: devtree: populate /axi/vc_mem/reg
See: raspberrypi/linux#381

firmware: audio: Updates to support multichannel hdmi audio more accurately

linux: bump to 3.10.17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants