Need help with Device Tree

notro commented 11 years ago

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

notro commented 11 years ago

I believe the existing /chosen/bootargs is always overwritten. Are you seeing different behaviour?

I think I have deciphered it. If cmdline.txt fits into /chosen/bootargs, it is copied. If not, it stays unchanged.

How do you want it to behave?

I want it not to be touched. It's difficult to debug, and I see no benefit either, as it is just as easy to change /chosen/bootargs, as it is to change cmdline.txt. Well almost as easy:

sudo fdtput --type s /boot/bcm2708-rpi-b.dtb /chosen bootargs "dtb debug dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait"

(considering there may or may not be a /chosen/bootargs and there may or may not be a cmdline.txt)

If for some reason /chosen/bootargs is missing, the contents of CONFIG_CMDLINE will be used.

CONFIG_CMDLINE="dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait"

popcornmix commented 11 years ago

@lp0 Do you agree that /chosen/bootargs should be passed through untouched? (compared to being replaced with contents of cmdline.txt)

nomis commented 11 years ago

/chosen/bootargs is to be populated by the bootloader, so it should always be replaced with the command line

(Editing the .dtb is not intended as a way to set a command line)

notro commented 11 years ago

I found this statement by Grant Likely that expands a bit on that:

Correct; the purpose of the 'chosen' node is to pass configuration information from boot firmware to the kernel. You can put properties int the /chosen node in your .dts files, but they are merely a suggestion when firmware is devicetree aware.

When that is the case, what's the rationale behind not passing the extended command line, as with ATAGS?

I found this in #24

* TODO: add options to:
* - expand fdt if value doesn't fit
and:
./fdtput -ts bcm2835.dtb /chosen bootargs "root=nfs"
Error at 'bootargs': FDT_ERR_NOSPACE

fdtput from source is able to do this now. I see that U-Boot uses libfdt to manipulate the FDT.

For now, I'll just add a /chosen/bootargs string of length: #define COMMAND_LINE_SIZE 1024 to the Device Tree.

notro commented 11 years ago

I have made a pre-built kernel for anyone who wants to try out Device Tree with BCM2708.

Install

# Update rpi-update, to make sure we have REPO_URI support.
sudo wget https://raw.github.com/Hexxeh/rpi-update/master/rpi-update -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update

sudo REPO_URI=https://github.com/notro/rpi-firmware BRANCH=dt rpi-update

Build info

DYNAMIC_DEBUG is enabled. Kernel config: bcmrpi_defconfig. Changes from that is avaialble in the Readme: https://github.com/notro/rpi-firmware/tree/dt Patches used: https://github.com/notro/rpi-build/tree/master/patches/dt Some more info: https://github.com/notro/rpi-firmware/wiki/Device-Tree

USB

I was not able to put USB in the Device Tree. Here's the boot log from my attempt: https://gist.github.com/notro/7070491

Firmware

The firmware is not filling in /memreserve/ and /axi/vc_mem/reg. This means that they have to be changed manually before booting on a 256MB Pi (I haven't tried it).

Thanks for all the help in getting this far.

notro commented 11 years ago

@popcornmix are you interested in pulling something like this?

If you are, I will continue and see if I can use drivers/irqchip/irq-bcm2835.c and the whole of drivers/pinctrl/pinctrl-bcm2835.c. That would give us level triggered gpio interrupts #408 , and move even closer towards BCM2835.

If not, I think I'll stop here, at least for now. Even though it turned out to be quite an interesting endeavour, I have more than achieved my initial objective.

popcornmix commented 11 years ago

I did add /axi/vc_mem/reg to a recent firmware update (possibly only on the "next" firmware tree).

@notro I'm pretty keen on using upstream bcm2835 as the machine type for raspberry pi, with a (smaller) set of patches for out-of-tree bits (e.g. dwc_otg and vchiq).

If that is your end goal, then I'm interested. It's obviously something that has a lot of potential from breaking things, so would need to be done carefully, e.g.. a 2835 linux and firmware branch that can be got from "BRANCH=2835 rpi-update".

cleverca22 commented 11 years ago

is there a device-tree branch that is currently bootable?, ive got some other changes i was wanting to do that need device-tree in the i2c bus area

notro commented 11 years ago

@popcornmix my end goal is BCM2835, but there is so much missing there, so I thought having DT support with BCM2708 could be a way to get Device Tree support sooner than later.

I'm currently giving it another go with BCM2835 and USB. Using https://github.com/swarren/linux-rpi.git (3.11) I get USB (dwc2) and networking, but applying the pathces to 3.12 gives me problems:

[    0.000000] Linux version 3.12.0+ (pi@raspi1) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #1 Sat Nov 9 20:54:03 CET 2013
[    0.000000] Machine: BCM2835, model: Raspberry Pi Model B

[   23.859983] ERROR: 256 KiB atomic DMA coherent pool is too small!
[   23.859983] Please increase it with coherent_pool= kernel parameter!
[   23.860030] dwc2 20980000.usb: dwc2_assign_and_init_hc: Failed to allocate memory to handle non-dword aligned buffer
[   23.871258] dwc2 20980000.usb: dwc2_assign_and_init_hc: Failed to allocate memory to handle non-dword aligned buffer

Keyboard and mouse works, but not networking.

If I add coherent_pool=1M to the kernel command line, it boots without errors, but locks up seconds later. ACT led stops blinking as well (heartbeat).

notro commented 11 years ago

is there a device-tree branch that is currently bootable?, ive got some other changes i was wanting to do that need device-tree in the i2c bus area

These are the options that I know of:

Vanilla 3.12 - BCM2835: gives you SPI, I2C and serial
rpi-3.12.y branch - BCM2835 won't boot because of the changes to the mmc core. If you revert them it works. I had to use u-boot, since booting with the firmware gave me random lockups. Same drivers as above.
https://github.com/swarren/linux-rpi.git (3.11-next) - BCM2835: gives you USB and networking as well
rpi-3.10.y - BCM2708: all drivers with the patches I mentioned further up the thread.

There is one caveat regarding memory size. Linux uses /memory/reg to find how much memory is available.

U-Boot populates this with the size available to the ARM CPU, excluding gpu_mem.
The firmware gives the total size of the memory. This means that the /memreserve/ node has to be used to exclude gpu_mem. This is not filled in by the firmware.

As far as I know, the upstream developers uses U-Boot.

popcornmix commented 11 years ago

This commit https://github.com/raspberrypi/linux/commit/c7768e2beacacbef7d6d05f40f45f0aa96cf7082 should fix mmc issue with 3.12.y. We normally set coherent pool size to 4M - does that work?

notro commented 11 years ago

This commit c7768e2 should fix mmc issue with 3.12.y.

It didn't help when using BCM2835 (sdhci-bcm2835):

[    1.990212] sdhci: Secure Digital Host Controller Interface driver
[    1.996392] sdhci: Copyright(c) Pierre Ossman
[    2.000802] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.047536] mmc0: SDHCI controller on 20300000.sdhci [20300000.sdhci] using PIO

[    2.109865] Waiting for root device /dev/mmcblk0p2...
[    2.137184] mmc0: new SDHC card at address e624
[    2.142336] mmcblk0: mmc0:e624 SU16G 14.8 GiB
[    2.149765]  mmcblk0: p1 p2
[   12.227505] mmc0: Timeout waiting for hardware interrupt - cmd18.
[   12.233863] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[   12.243039] mmcblk0: error -110 transferring data, sector 122882, nr 2, cmd response 0x900, card status 0x0
[   12.252804] mmcblk0: retrying using single block read
[   12.259140] EXT3-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (240)
[   12.269973] EXT2-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (244)
[   22.307500] mmc0: Timeout waiting for hardware interrupt - cmd18.
[   32.327501] mmc0: Timeout waiting for hardware interrupt - cmd12.
[   42.347491] mmc0: Timeout waiting for hardware interrupt - cmd13.
[   42.353655] mmcblk0: error -110 sending status command, retrying
[   52.387497] mmc0: Timeout waiting for hardware interrupt - cmd13.
[   52.393661] mmcblk0: error -110 sending status command, retrying
[   62.427501] mmc0: Timeout waiting for hardware interrupt - cmd13.
[   62.433663] mmcblk0: error -110 sending status command, aborting
[   72.467499] mmc0: Timeout waiting for hardware interrupt - cmd13.
[   82.487492] mmc0: Timeout waiting for hardware interrupt - cmd13.
[   92.507489] mmc0: Timeout waiting for hardware interrupt - cmd13.
[  102.527501] mmc0: Timeout waiting for hardware interrupt - cmd13.
[  102.534091] mmc0: card e624 removed
[  102.537818] EXT4-fs error (device mmcblk0p2): __ext4_get_inode_loc:3917: inode #8: block 206: comm swapper: unable to read itable block
[  102.550403] EXT4-fs (mmcblk0p2): no journal found
[  102.558049] VFS: Cannot open root device "mmcblk0p2" or unknown-block(179,2): error -6
[  102.566007] Please append a correct "root=" boot option; here are the available partitions:
[  102.574404] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(179,2)

It works if I revert the core mmc changes to vanilla 3.12

Applied patch drivers/mmc/card/block.c cleanly.
Applied patch drivers/mmc/core/sd.c cleanly.
Applied patch drivers/mmc/host/sdhci.c cleanly.
Applied patch drivers/mmc/host/sdhci.h cleanly.
Applied patch include/linux/mmc/host.h cleanly.
Applied patch include/linux/mmc/sdhci.h cleanly.

We normally set coherent pool size to 4M - does that work?

It gave me a few more seconds. I did a few more ping's before the one shown here. It locked up right after that dmesg.

$ ping -i 10 -D 192.168.10.1
PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.
[1384091979.014229] 64 bytes from 192.168.10.1: icmp_req=1 ttl=64 time=1.34 ms
[1384091983.679992] 64 bytes from 192.168.10.1: icmp_req=1 ttl=64 time=4667 ms (DUP!)
wrong data byte #24 should be 0x18 but was 0xd6
#8      8 9 a b c d e f 10 11 12 13 14 15 16 17 d6 2a f aa ff f6 1a a4 d6 2a f ab 0 44 cf d4
#40     d6 2a f ab 0 45 fb 7f b ac 32 33 34 35 36 37
^C

$ dmesg
[   69.584058] UDP: bad checksum. From 192.168.10.1:53 to 192.168.10.230:41424 ulen 74
[   75.953942] <unknown>: hw csum failure
[   75.953986] CPU: 0 PID: 1986 Comm: ntpd Not tainted 3.12.0+ #1
[   75.954070] [<c00155a8>] (unwind_backtrace+0x0/0x128) from [<c0012480>] (show_stack+0x20/0x24)
[   75.954131] [<c0012480>] (show_stack+0x20/0x24) from [<c0465314>] (dump_stack+0x20/0x28)
[   75.954177] [<c0465314>] (dump_stack+0x20/0x28) from [<c0332514>] (netdev_rx_csum_fault+0x3c/0x48)
[   75.954245] [<c0332514>] (netdev_rx_csum_fault+0x3c/0x48) from [<c032bf14>] (skb_copy_and_csum_datagram_iovec+0xec/0x118)
[   75.954302] [<c032bf14>] (skb_copy_and_csum_datagram_iovec+0xec/0x118) from [<c037bcc8>] (udp_recvmsg+0x12c/0x3a8)
[   75.954357] [<c037bcc8>] (udp_recvmsg+0x12c/0x3a8) from [<c0385370>] (inet_recvmsg+0x50/0x64)
[   75.954405] [<c0385370>] (inet_recvmsg+0x50/0x64) from [<c031ddbc>] (sock_recvmsg+0x8c/0xa8)
[   75.954459] [<c031ddbc>] (sock_recvmsg+0x8c/0xa8) from [<c031e540>] (___sys_recvmsg.part.26+0xd4/0x194)
[   75.954506] [<c031e540>] (___sys_recvmsg.part.26+0xd4/0x194) from [<c0320328>] (__sys_recvmsg+0x60/0x84)
[   75.954647] [<c0320328>] (__sys_recvmsg+0x60/0x84) from [<c0320364>] (SyS_recvmsg+0x18/0x1c)
[   75.954709] [<c0320364>] (SyS_recvmsg+0x18/0x1c) from [<c000ea20>] (ret_fast_syscall+0x0/0x30)

notro commented 11 years ago

I'm giving up on BCM2835. There is too much missing, and the USB driver is far from production quality. I'm not skilled for this kind of work. Stephen Warren currently seem to be the main driver behind the work done on BCM2835.

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.

BCM2835

This is a list of the BCM2835 related commit messages I could find.

2013

June watchdog: Add Broadcom BCM2835 watchdog timer driver

May ARM: bcm2835: override the HW UART periphid

March hwrng: bcm2835 - Add Broadcom BCM2835 RNG driver ARM: bcm2835: add Broadcom BCM2835 RNG to the device tree ARM: bcm2835: convert to multi-platform spi: add driver for BCM2835

February ARM: bcm2835: add SPI device to DT ARM: bcm2835: fix I2C module clock rate i2c: add bcm2835 driver

January mmc: add BCM2835 driver

2012

December ARM: bcm2835: add I2C controllers to DT

November irqchip: add basic infrastructure

September ARM: bcm2835: enable GPIO/pinctrl ARM: bcm2835: implement machine restart hook pinctrl: add bcm2835 driver MAINTAINERS: add an entry for the BCM2835 ARM sub-architecture ARM: bcm2835: add stub clock driver ARM: bcm2835: add system timer ARM: bcm2835: add interrupt controller driver

May ARM: add infra-structure for BCM2835 and Raspberry Pi

DWC2

The DWC2 USB driver has seen commits (>70) all months since it entered the tree in March 2013.

DWC2 TODO file: https://github.com/torvalds/linux/blob/master/drivers/staging/dwc2/TODO

Informative commit message

commit 20f2eb9c4cf8d770dae0c6e85991809c2f93663a
Author: Dom Cobley <popcornmix@gmail.com>
Date:   Mon Sep 23 14:23:34 2013 -0700

    staging: dwc2: add microframe scheduler from downstream Pi kernel

    The transfer scheduler in the dwc2 driver is pretty basic, not to
    mention buggy. It works fairly well with just a couple of devices
    plugged in, but if you add, say, multiple devices with periodic
    endpoints, the scheduler breaks down and can't even enumerate all
    the devices.

    To improve this, import the "microframe scheduler" patch from the
    driver in the downstream Raspberry Pi kernel, which is based on
    the Synopsys vendor driver. The original patch came from Denx
    (http://git.denx.de/?p=linux-denx.git) and was commited to the
    raspberrypi.org git tree by "popcornmix" (Dom Cobley).

    I have added a driver parameter for this, enabled by default, in
    case anyone has problems with it and needs to disable it. I don't
    think we should add a DT binding for that, though, since I plan
    to remove the option once any bugs are fixed.

    [raspberrypi.org patch from Dom Cobley]
    Signed-off-by: Dom Cobley <popcornmix@gmail.com>
    [adapted to dwc2 driver by Paul Zimmerman]
    Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

First commit

commit 56f5b1cff22a1d6eeb3f7fc6981b8a55af43332b
Author: Paul Zimmerman <Paul.Zimmerman@synopsys.com>
Date:   Mon Mar 11 17:47:58 2013 -0700

    staging: Core files for the DWC2 driver

    The core code provides basic services for accessing and managing
    the DWC_otg hardware. These services are used by both the Host
    Controller Driver and (in future) the Peripheral Controller Driver.

    Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
    Reviewed-by: Felipe Balbi <balbi@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

popcornmix commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

@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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

There is mailbox code here: https://github.com/lp0/linux/commit/917bdfc3045151cda896bf0cbf1542340892f58d

It needs to be updated for the new kernel interface.

koalo commented 11 years ago

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 commented 11 years ago

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

Yes, I have just copied them.

notro commented 11 years ago

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 commented 11 years ago

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

popcornmix commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 11 years ago

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 commented 10 years ago

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_aliasscan() is not exported.

cleverca22 commented 10 years ago

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 commented 10 years ago

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

raspberrypi / linux

Need help with Device Tree #381

BCM2835

DWC2