Device Tree revisited

[notro]

I have a proposal for a way to get Device Tree support and move to ARCH_BCM2835.

Steps

• Enable the Common Clock framework (COMMON_CLK). This also works without DT.
  Replaces arch/arm/mach-bcm2708/clock.c which is removed
• Add bootloader option to set ATAG_MEM to usable memory only, and fill chosen/bootargs with the non-DT (extended) ATAG_CMDLINE.
  I expand on this further down.
• Add Device Tree IRQ mapping to arch/arm/mach-bcm2708/armctrl.c
  GPIO interrupts is mapped to a virtual bank 3 since we can't use irq-bcm2835 (at least I couldn't get it to work).
• Add Device Tree support to arch/arm/mach-bcm2708/bcm2708.c
• Add minimal Device Tree files
  bcm2708.dtsi
  bcm2708-rpi-b.dts
• Enable Device Tree support (OF_USE)

At this point the kernel boots with Device Tree.
Platform devices can now be added through Device Tree.

Next steps

• Add pinctrl driver (modified version of pinctrl-bcm2835)
  It provides DT support to the gpio_chip added in bcm2708_gpio
• Add DT support to i2c-bcm2708 and spi-bcm2708
  Move SPI/I2C devices to DT
  It is also possible to enable i2c-bcm2835 and spi-bcm2835 as well. Testing can begin and maybe we can move to them sooner than later.

At this point SPI and I2C devices can also be added, and pins/GPIOs can be configured (in/out, alt0 etc.) in DT.

Move drivers to DT
Now the rest of the drivers can get DT support and the devices be moved from bcm2708.c to DT
(I have done most of these already in patches lying around)

At this point all devices are added through Device Tree.

Normal ATAG_CMDLINE

Now the normal ATAG_CMDLINE can be used for chosen/bootargs.

Normal chosen/bootargs
Now config.txt can be used for chosen/bootargs if preferred.

Start using dmaengine
Currently most of the drivers manipulate the DMA registers directly.
To remedy this, bcm2708-dmaengine/bcm2835-dma has to get support for slave_sg (I believe this is what is needed).
Then bcm2708_fb, sdhci-bcm2708 and others can start using dmaengine.

Mailbox driver
There is work going on upstream for this (Lubomir Rintel and others).
The Mailbox API isn't settled yet (latest patch version).
Drivers would need to start using this.

FIQ
We need to have FIQ support in ARCH_BCM2835.
I don't know if it is already supported in irq-bcm2835.
Is shortcut the same as FIQ?

At this point, switching to ARCH_BCM2835 should (hopefully) be close at hand.
Some of these steps can of course happen in parallel.

rpi-update
Maybe rpi-update could handle config.txt for Device Tree kernels.
If a .dtb is present
add DT options and use the .dtb
else
remove DT options if present.

VideoCore Bootloader in DT mode
Current behaviour and proposed changes (through a new config option or something similar if needed):

config.txt

device_tree=bcm2708-rpi-b.dtb
device_tree_address=0x100
disable_commandline_tags=1

ATAG_MEM
This is set to the amount of installed memory, not the part that's available to the CPU.
This requires a /memreserve/ node in DT to keep Linux from using memory it doesn't have.
The value of this node depends on the GPU/CPU memory split value in config.txt.
Changing this to available memory, removes the need for /memreserve/. This is how ARCH_BCM2835 expects it, and U-boot delivers it.

ATAG_CMDLINE

chosen/bootargs
This is the contents of cmdline.txt.
Changing this to the extended commandline used in non-DT mode, means no drivers have to be changed when moving to DT.

One caveat with the VC bootloader is that chosen/bootargs has to be prefilled with 1024 characters (COMMAND_LINE_SIZE), since the bootloader isn't equipped to allocate more space in the Device Tree.
The bootloader must have this ability to be able to boot vanilla Linux and pass in cmdline.txt.
libfdt is in use in many projects to provide Device Tree manipulation abilities (Linux, U-boot and others).

Example
I have a working example using a modified U-Boot to get the desired bootloader behaviour.
It sort of covers the steps up to SPI/I2C (it was made before this text was written).

Install

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

Patches used in this example:

• U-boot
• Linux (here DT support is controlled with CONFIG_BCM2708_DT)

Issue history

• Need help with Device Tree 2013-09-21
• Device tree population 2012-05-17

[notro]

Device Tree Overlays (2014-05-28) support in mainline is getting closer:

The following patchset introduces Device Tree overlays, a method
of dynamically altering the kernel's live Device Tree.

Comment by Grant Likely on the latest patch version:

Good changes. This version is considerably better than the past one.
I've still got comments, but I'm a lot more comfortable with the
approach.

When this is in, the BeagleBone capemanager patchset will shrink in size/width and maybe we can use it in some form on the DT enabled Pi.

[popcornmix]

Okay, I'm interested in this plan.

If you want to submit any kernel PRs that bring us closer to supporting DT, and don't break things for non-DT users, then go ahead.

I should be able to provide a test start.elf that fills in the DT as desired.
If you could produce a dtb file and kernel image that prints out the device tree fields, and what you would like the fields to contain (i.e. what you get from uboot), that would make my life easier.

[notro]

I wrote ATAG_CMDLINE a couple of places where it should have been chosen/bootargs, sorry about that. I have fixed it.

Bootloader
This is the bootloader behaviour I need (enable with disable_commandline_tags=2 if you prefer to keep the current behaviour as an option):

• ATAG_MEM = Memory available to the CPU (default: 512 total - 64 GPU = 448 CPU)
• DT chosen/bootargs = extended command line (dmachans etc. + cmdline.txt)

No other bootloader changes are needed at this time.
We'll deal with Device Tree needs for drivers when we get to that.

Kernel config
CONFIG_BCM2708_DT will be used to enable Device Tree

Pull Requests
How about this for starters:
PR for Common Clock Framework
PR with individual commits for: armctrl.c, bcm2708.c, dts files and config options (or should I split this into more PR's?)
PR for new pinctrl driver
PR for spi-bcm2708
PR for i2c-bcm2708

Should I make PR's against rpi-3.15.y?

[popcornmix]

Yes, I think PR against rpi-3.15.y makes sense.
The PR's mentioned sound okay (no need to split more finely)
I'll have a go at updated firmware tomorrow.

[notro]

Thanks.
You can test the firmware with these if you want:

• https://github.com/notro/rpi-firmware/blob/dt/bcm2708-rpi-b.dtb
• https://github.com/notro/rpi-firmware/blob/dt/zImage

Or I can do the testing if the change is trivial.

[notro]

The clocks are added in a different way with the Common Clock Framework, so I'm reworking that.
Can I remove the CONFIG_ARCH_BCM2708_CHIPIT #ifdef's?
There's no such config option, so even if it was added manually to .config, make oldconfig would remove it.

Ref: https://github.com/raspberrypi/linux/blob/rpi-3.15.y/arch/arm/mach-bcm2708/bcm2708.c#L208

New clock setup: https://gist.github.com/notro/b3e5ef5e9a51bb21e4ac

# cat /sys/kernel/debug/clk/clk_summary
   clock                        enable_cnt  prepare_cnt  rate        accuracy
---------------------------------------------------------------------------------
 sdhost_clk                     1           1            250000000  0
 osc_clk                        0           0            500000000  0
 uart_clk                       3           4            3000000    0

[popcornmix]

CONFIG_ARCH_BCM2708_CHIPIT hasn't been used for years, so feel free to remove it.

[popcornmix]

I've added to config.txt

device_tree=bcm2708-rpi-b.dtb
device_tree_address=0x100
disable_commandline_tags=1
kernel=zImage

and put the linked zImage and bcm2708-rpi-b.dtb in /boot.

Would you expect to get any console output or anything on framebuffer? I get nothing.

[ghollingworth]

Just to note, I've got an intern working on creating suitable drivers that can be upstreamed in such a way that we get here by starting with the upstream kernel and moving our support across rather than add more hackery to support upstream facilities....

Currently he's working on a new mmc driver for the bcm2835 architecture which doesn't then require sdhci hackery to upstream

Gordon

[notro]

Just to note, I've got an intern working on creating suitable drivers that can be upstreamed in such a way that we get here by starting with the upstream kernel and moving our support across rather than add more hackery to support upstream facilities....

Do you have a timeline for that and does he/she have previous kernel development experience?
Is there anything in this plan you regard as hackery (except the pinctrl driver)?

Currently he's working on a new mmc driver for the bcm2835 architecture which doesn't then require sdhci hackery to upstream

This is good news. My brief testing of that driver (sdhci-bcm2835.c) was disappointing.

[popcornmix]

@notro
Can you confirm if what I asked in #627 (comment) should boot?

[notro]

Can you confirm if what I asked in #627 (comment) should boot?

I'm sorry, I missed that. Sometimes I don't get e-mail alerts in this thread when new messages comes in.

I don't have a HDMI monitor, so I tried it (with U-boot) on my sons monitor, and it worked fine.

Back on my desk with serial, I added the config.txt changes and booted. I get output, but it crashes before the framebuffer driver is loaded.
I thought it was because of missing commandline options, but adding those to cmdline.txt didn't help.

This is what I get

[    1.269194] Unable to handle kernel NULL pointer dereference at virtual address 00000026

Instead of

[    1.297300] bcm2708_dma: DMA manager at f2007000

I have to investigate this further.

Full console output: https://gist.github.com/notro/376d63def4bab8c1c8b3

[notro]

This is the ATAG_MEM issue.
The VC bootloader sets ATAG_MEM=512MB, whereas U-boot sets ATAG_MEM=448MB
The kernel crashes because it also uses the GPU only memory.

VC

[    0.000000] Memory: 504404K/524288K available (4508K kernel code, 260K rwdata, 1448K rodata, 152K init, 702K bss, 19884K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)

U-boot

[    0.000000] Memory: 439380K/458752K available (4508K kernel code, 260K rwdata, 1448K rodata, 152K init, 702K bss, 19372K reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     lowmem  : 0xc0000000 - 0xdc000000   ( 448 MB)

[popcornmix]

Okay I was missing "kernel_address=0x8000". Now I get some boot messages (including the Memory line one) and the panic.
I'll see if I can get the same numbers as u-boot.

[notro]

This seems to be the way U-boot gets the RAM size:

#define BCM2835_MBOX_TAG_GET_ARM_MEMORY         0x00010005

BCM2835_MBOX_INIT_TAG(&msg->get_arm_mem, GET_ARM_MEMORY);

Ref: http://git.denx.de/?p=u-boot/u-boot-arm.git;a=blob;f=board/raspberrypi/rpi_b/rpi_b.c;h=f33fae91700cadf344905ae0f31198ee38be6c53;hb=HEAD#l44

[notro]

@popcornmix
Sorry about my talk about ATAG_MEM all the time, this info is passed with the Device Tree right?
Passed in the reg property if I'm not mistaken.

early_init_dt_scan_memory() looks to be the place where the kernel picks this up:
http://lxr.free-electrons.com/source/drivers/of/fdt.c#L881

[notro]

And this seem to be the place where U-boot fills in the memory node:
fdt_fixup_memory_banks(): http://git.denx.de/?p=u-boot/u-boot-arm.git;a=blob;f=common/fdt_support.c#l415

The memory node from /proc

$ cat /proc/device-tree/memory/device_type
memory
$ cat /proc/device-tree/memory/name
memory
$ hexdump /proc/device-tree/memory/reg
0000000 0000 0000 001c 0000
0000008

[kukabu]

@notro, what about bcm2835_wdt and bcm2835-rng?

[notro]

@kukabu
I'm not sure what you mean here, but they are good examples of drivers that it should be easy switching to once we start using Device Tree (unlikely to break anything). Thanks.

[P33M]

@notro
Moving to an upstream (or at the very least, DT-using) kernel is one of our objectives. The way that you propose is to take the out-of-tree port (bcm2708) and incorporate bcm2835 features?

My preferred method is the inverse - the upstream mach already has most of the stuff required for a minimally functional system.

We have succeeded in getting a mach-bcm2835 kernel to boot directly off Videocore's setup but with the aforementioned memory trampling. Further investigation required as to why this happens in the DT case but not the normal boot mode case.

Some modification of the VC bootloader is required to split it into two distinct behaviours - standard ATAGS boot or multiplatform boot (r1=0xFFFFFFFF, no ATAGS, r2= pointer to dtb). Currently, the bootloader does not support adding nodes - something our intern is working on adding.

Given the bootloader limitation of not being able to expand a dtb in-memory, all that's required is additional padding (say 4k) and a 1024 char command-line string.

Regarding FIQ support - the mach-bcm2835 armctrl IRQchip needs expanding to write to the FIQ select register. FIQ lines in ARM linux are just IRQ numbers >= FIQ_START. Some sort of refcounting would be required to ensure that the FIQ is not enabled from different sources simultaneously - the hardware can only support a single, nominated IRQ line to promote to the FIQ input.

[notro]

@PM33

The way that you propose is to take the out-of-tree port (bcm2708) and incorporate bcm2835 features?

Yes to some degree. I see this as working the issue on two fronts, to speed things up and maintain stability. This is my current view of the two fronts:

BCM2708
With Device Tree support here, we can do the following:
Add DT support to a BCM2708 driver and build the matching BCM2835 driver as well.
Now by changing the DT compatible property, we can switch between those drivers.
We start by using the BCM2708 driver, but testing of the BCM2835 driver can now be done easily.
Later we change to use the BCM2835 driver by default, but keep building the BCM2708 driver. If an issue arises with the driver, it's easy to switch back to the BCM2708 driver to see if that solves the problem.
After some time with success, the BCM2708 driver can be removed.

If we make a timeschedule for all the drivers, we can make sure we have only one driver change in a certain period of time. This gives us a high level of change control for many of the drivers, in a short period of time. And by doing the low hanging fruit first, we can get some BCM2708 drivers out of the way quite easily.
Some of the drivers only need 10 lines of code and a DT node, so with those there's not a lot of work.

Another benefit is that any new BCM2835 drivers can be used/tested easily, because we have Device Tree support.
I see no point in moving a driver (device) to DT just for doing so. The main purpose is shedding non-vanilla drivers for the benefit of the vanilla ones.

And we get this with very little change to ARCH_BCM2708.

BCM2835
There are some changes that I believe are quite disruptive and might be better done upstream:
Start using dmaengine (slave_sg needed) for drivers that need that.
Start using the new mailbox driver when the new API is in place.
Add FIQ support, and enable the USB driver to use it.
A decision has to be made about whether to continue (for some time) with the rpi USB driver, or switch to the DWC2 driver in staging.
vc04_services: I don't know anything about this, so I'm blank on this.

I propose adding a wiki page to this repo that lists all the arch/core drivers and details the status with regards to upstreaming.

My preferred method is the inverse - the upstream mach already has most of the stuff required for a minimally functional system.

Yes, I understand that. That was my first line of work.
I have done some testing and there are several WorkInProcess drivers as well, but in my view the main problem is performance (USB/MMC: FIQ/DMA is missing).

Another issue is that the implementation of ARCH_BCM2835 (and tegra) has lead to (been part of) the generation of new API's in the kernel. This slows down the process.
In a long term maintenance perspective this is a good thing, but in a short term: let's switch now perspective, this can be frustrating.
Stephen Warren is the maintainer of ARCH_BCM2835, and to me he seems to be a very compentent kernel developer with a high level perspective on things.
Getting him involved early [RFC] might be a good thing.
This is my personal feeling about this, and I might very well be off on this.

Disclaimer: I have done kernel development for only 18 months and haven't sent any patches upstream. This is quite new to me.

We have succeeded in getting a mach-bcm2835 kernel to boot directly off Videocore's setup but with the aforementioned memory trampling. Further investigation required as to why this happens in the DT case but not the normal boot mode case.

Has there been any discussion about using U-boot as bootloader?
Stephen Warren's uboot repo has support for USB, which would also give us network booting and direct booting from USB devices.

[popcornmix]

My view is that switching from bcm2708 to bcm2835 is going to be a big step that has potential to break a lot of people's set-ups.

It seems logical to make some small steps to bring bcm2708 closer to bcm2835, if they can be done in a harmless way (e.g. #630).

I think u-boot should be an option, and we should make it as straightforward as possible to use (e.g. document how to build/use u-boot in official documentation).

Whether it should be the default option is another question. I'd imagine it adds a little to boot time, adds another file to sdcard, and involves another step in booting that could fail.

The benefits are pretty niche. You can already network/usb boot a root filesystem, so the only advantage is if you also want to network/usb boot the kernel (presumably because you are building your own). That's very much a benefit for <1% of users.

Here is a firmware file (a test build with 256M/256M memory split).
When disable_commandline_tags=2 we report just the arm memory in /memory/reg, and it does boot your zImage.
https://dl.dropboxusercontent.com/u/3669512/temp/start_dtrev.elf

[N8Fear]

I think the biggest benefit of using a bootloader is that a kernel update that introduces breakage can be recovered from without pluging the SD-card into another host but by simply selecting another kernel image...

[notro]

I'd imagine it adds a little to boot time, adds another file to sdcard, and involves another step in booting that could fail.

I was thinking about building U-boot for the GPU, so it becomes start.elf

https://dl.dropboxusercontent.com/u/3669512/temp/start_dtrev.elf

I get Not Found when I try to download.

[popcornmix]

I was thinking about building U-boot for the GPU, so it becomes start.elf

u-boot has a lot of arm assembly code and hardware drivers (e.g for USB/network) - it would be far from easy to port to the GPU.

I get Not Found when I try to download.

Sorry - try now.

[notro]

u-boot has a lot of arm assembly code and hardware drivers (e.g for USB/network) - it would be far from easy to port to the GPU.

Ok.

When disable_commandline_tags=2 we report just the arm memory in /memory/reg, and it does boot your zImage.

I can confirm that, but I had to add the extended kernel parameters to cmdline.txt to get it all the way.

[notro]

I have started a wiki page: https://github.com/raspberrypi/linux/wiki/Upstreaming

[popcornmix]

I can confirm that, but I had to add the extended kernel parameters to cmdline.txt to get it all the way.

Just to be clear, are you saying that the contents of cmdline.txt get inserted into /chosen/bootargs, but the firmware generated arguments (like dma.dmachans) are missing?

[notro]

Just to be clear, are you saying that the contents of cmdline.txt get inserted into /chosen/bootargs, but the firmware generated arguments (like dma.dmachans) are missing?

Correct

start.elf

$ ls -l /boot/start.elf
-rwxr-xr-x 1 root root 3526632 Jul  7 18:19 /boot/start.elf

config.txt

device_tree=bcm2708-rpi-b.dtb
device_tree_address=0x100
kernel_address=0x8000
disable_commandline_tags=2
kernel=zImage

cmdline.txt

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

Kernel messages

[    0.000000] Kernel command line: dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

[    0.000000] Memory: 244508K/262144K available (4508K kernel code, 260K rwdata, 1448K rodata, 152K init, 702K bss, 17636K reserved)

[popcornmix]

Okay, that should be fixable...

[popcornmix]

Try:
https://dl.dropboxusercontent.com/u/3669512/temp/start_dtrev2.elf

which should include extended command line parameters

[notro]

That gave me the contents of chosen/bootargs with a lot of spaces

[    0.000000] Kernel command line: earlyprintk console=ttyAMA0                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

The command line with spaces is 690 characters long.

chosen/bootargs in the DT is 791 characters long including trailing spaces.
It will be 1024 in the final version.

[popcornmix]

I don't know what to suggest. Using your zImage and bcm2708-rpi-b.dtb along with start_dtrev2.elf (renamed to start.elf) I get:

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 3.12.22+ #1 PREEMPT Mon Jun 16 20:03:12 CEST 2014 armv6l GNU/Linux
pi@raspberrypi:~ $ vcgencmd version
Jul  8 2014 16:54:44 
Copyright (c) 2012 Broadcom
version eea731686487a978dece7411386f6f5ef3a64fbd (tainted) (release)
pi@raspberrypi:~ $ cat /boot/cmdline.txt
earlyprintk=ttyAMA0,115200 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 nfsroot=10.177.13.16:/home/dc4/rootfs ip=dhcp rootwait trace_event=console 
#dwc_otg.fiq_fix_enable=0 dwc_otg.fiq_split_enable=0 sdhci-bcm2708.enable_llm=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
pi@raspberrypi:~ $ cat /proc/cmdline 
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=1080 bcm2708.boardrev=0x4100000f bcm2708.serial=0xe smsc95xx.macaddr=B8:27:EB:00:00:0E sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  earlyprintk=ttyAMA0,115200 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 nfsroot=10.177.13.16:/home/dc4/rootfs ip=dhcp rootwait trace_event=console
pi@raspberrypi:~ $ vcgencmd get_config int && vcgencmd get_config str
disable_overscan=1
program_serial_random=1
config_hdmi_boost=2
disable_commandline_tags=2
emmc_pll_core=1
device_tree_address=256
kernel_address=32768
hdmi_force_cec_address=65535
temp_limit=85
force_pwm_open=1
pause_burst_frames=1
avoid_fix_ts=1
kernel=zImage
device_tree=bcm2708-rpi-b.dtb

[notro]

I started with a fresh image, and it's working now.
Don't know what went wrong.

I also tried it with 3.15 and the DT patches I'm working on, boots fine here to.
Thanks.

[notro]

@popcornmix
Adding DT support to a BCM2708 driver involves the following changes:

• Add DT support to driver.
• Add DT node to dtsi/dts file(s)
• Change bcm2708.c to not register the device when CONFIG_OF
• Enable BCM2835 driver to be available on ARCH_BCM2708

How many commits do you want this split into?

Here's a suggestion for SPI. 3 commits in one PR.

spi: bcm2708: add device tree support

Add DT support to driver and add to .dtsi file.
Setup pins and spidev in .dts file.
SPI is disabled by default.

Signed-off-by: Noralf Tronnes <notro@tronnes.org>

BCM2708: don't register SPI controller when using DT

The device for the SPI controller is in the DT.
Only register the device when not using DT.

Signed-off-by: Noralf Tronnes <notro@tronnes.org>

spi: bcm2835: make driver available on ARCH_BCM2708

Make this driver available on ARCH_BCM2708

Signed-off-by: Noralf Tronnes <notro@tronnes.org>

[popcornmix]

DT changes are in latest (rpi-update) firmware.
The split for PR sounds okay. It's possible some squashing will occur when rebasing to a future kernel, but for now it sounds okay.

[skrll]

This seems to change the cmdline.txt behaviour such that NetBSD can no longer fetch cmdline via the mailbox property interface. Having
root=ld0a console=fb
gives an empty cmdline string whereas just root=ld0a gives.
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1280 bcm2708_fb.fbheight=1024 bcm2708.boardrev=0x2 bcm2708.serial=0x9b541b2d smsc95xx.macaddr=B8:27:EB:54:1B:2D sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0xec00000 vc_mem.mem_size=0x10000000 root=ld0a

i.e. the first token appended to a long string of linux stuff (no idea where it comes from)

Am I missing something?

[popcornmix]

@skrll
The extra command line options are prepended by the firmware to describe firmware specific features.
Can you describe the mailbox command being sent? I suspect that the buffer supplied is not large enough.

[skrll]

Duh, should have realised the buffer wasn't big enough. Not sure when it happened, but the "new" firmware specific features seem redundant information, i.e. it can all be obtained via the mailbox property interface. Should I just ignore the added info?

[popcornmix]

Yes, many options are available through command line, mailbox and device tree.
Feel free to ignore command line options if you are getting them from mailbox or device tree.

One day they may be removed from command line, when everyone is using a device tree kernel, but that won't be happening soon.

[notro]

I have added a separate wiki page for BCM2708 and DT: https://github.com/raspberrypi/linux/wiki/Device-Tree-on-ARCH_BCM2708

Also added a Summary to the Upstreaming page: https://github.com/raspberrypi/linux/wiki/Upstreaming

[notro]

raspberrypi/linux:rpi-3.15.y have Device Tree support now.
Platform, SPI and I2C devices can be added using Device Tree.
This should be enough to satisfy end users.

I have built a kernel for those who want to try it:

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

I have also updated the wiki with some usage info: Device Tree on ARCH_BCM2708