Device tree population

[nomis]

Example template .dts: http://s85.org/6o9R3Ev2:view
Example compiled .dtb: http://s85.org/6A9h2c6X:raw

Could you automatically populate the following fields in the device tree file?

/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)
/chosen/bootargs with the contents of the command line file (without any additional arguments)

/system/revision with the u32 system revision
/system/serial with the high u32 followed by the low u32 of the serial number

/axi/usb/hub/ethernet/mac-address with the system mac address (this is six u8 bytes in network byte order, e.g. 00:11:22:33:44:55)

/axi/dma/broadcom,channels with the u32 mask of allowed channels (this is currently on the command line as dma.dmachans)

/axi/sdhci/clock-frequency with the u32 clock frequency in Hz
/axi/uart0/clock-frequency with the u32 clock frequency in Hz

/display/broadcom,width with the u32 display pixel width (this is currently on the command line as bcm2708_fb.fbwidth)
/display/broadcom,height with the u32 display pixel height (this is currently on the command line as bcm2708_fb.fbheight)
/display/broadcom,depth with the u32 display bit depth (this is currently on the command line as bcm2708_fb.fbdepth)

If there's anything you think I've missed let me know (the setting for dwc_otg.lpm_enable=0 can be put in the static template so the GPU doesn't need to provide it).

[nomis]

Updated to use /system-serial instead of separate /system-serial-high and /system-serial-low (although I haven't changed the .dts/.dtb).

[nomis]

Updated to move the mac address to /axi/usb/hub/ethernet/mac-address.

I've been advised that putting a mac-address at / is going to be a problem we don't want to re-open. Putting it at this location exactly matches the physical hardware devices.

[popcornmix]

You did earlier say: "Everything's be32 so it should be simple to overwrite default values as required. There's already a placeholder for the memory"

But I think the bootargs breaks that. Looks like I have to decompile then compile the dtb file. Unless I've missed something?

[nomis]

I was sure I had seen padding in one of the .dts for this but I can't find one now, so you may need to do that. I'm not sure exactly how the format works but you might be able to append another string to the end.

[popcornmix]

What happens if you say:
chosen { bootargs = " "; };
(for a sufficiently large number of spaces)?

[nomis]

Problem solved!

Put this in arch/arm/mach-bcm2708/Makefile.boot:
DTC_FLAGS ?= -p 4096

[popcornmix]

Great. I'll start work on this issue.

[popcornmix]

Okay, I've had a go at filling in the required device tree fields. Let me know if there are any problems:
https://dl.dropbox.com/u/3669512/start.elf

[bootc]

Nearly. I haven't spent much time on this yet, but with disable_cmdline_tags=1 I get no command-line options in /chosen - or at least my kernel doesn't pick them up. With disable_cmdline_tags=0 it uses ATAGs I think, and the kernel doesn't boot because the device tree isn't there.

[popcornmix]

Can you try making space in the:
chosen { bootargs = " "; };
in bcm2835.dtsi. I will only fill in up to the original length of the bootargs string.

[bootc]

Oh it doesn't use the padding space left at the end of the dtb? I'll see if I can't give it a go in a few, but may not be able to until about 20:30.

[popcornmix]

From my limited understanding, the data in the bootargs is just contained inline with the devtree tags, so it's not possible to store that in the padding space without recompiling a new devtree.

It does seem to work if you store a string of, say, 1024 spaces in the bootargs, and I overwrite that with real command line (leaving length as 1024 and spaces intact).

I've updated the start.elf to not store the '\0' inside string, which I think is more correct (it makes is_printable_string return true).

P.S. I'm expecting you to define disable_cmdline_tags=1.

[bootc]

Trouble with the big empty string full of spaces is I doubt we'd ever be able to get a device tree with that into mainline. How does fdtput do it? Is http://git.jdl.com/gitweb/?p=dtc.git any help?

[popcornmix]

Looking at code, it won't
* 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

If the big empty string is a blocker for upstreaming, then I'm sure we'll find a solution.
However it may be a temporary solution for the current developement.

[bootc]

Right, with the extra padding that lp0 has added when generating the .dtb (DTC_FLAGS ?= -p 4096) those should never trigger. The padding is added specifically so that fdtput can add in the command-line args without having to expand the fdt. Consider my code for building the .dtb files manually, below:

dtc -O dtb -o bcm2835-rpi-b.dtb -p 128 ~/Projects/linux-lp0/arch/arm/boot/dts/bcm2835-rpi-b.dts
fdtput -t x bcm2835-rpi-b.dtb /memory reg 0 0e000000
fdtput bcm2835-rpi-b.dtb / system-rev 2
fdtput -t x bcm2835-rpi-b.dtb / system-serial 0 12345678
fdtput -t hhx bcm2835-rpi-b.dtb / mac-address 11 22 33 44 55 66
fdtput bcm2835-rpi-b.dtb /display width 656
fdtput bcm2835-rpi-b.dtb /display height 416
fdtput bcm2835-rpi-b.dtb /display depth 16
fdtput -t x bcm2835-rpi-b.dtb /axi/dma channels 3c
fdtput -t s bcm2835-rpi-b.dtb /chosen bootargs "console=ttyAMA0,115200 debug earlyprintk root=/dev/mmcblk0p2 rootwait"

This works, including the bootargs bit at the bottom, because of the added 128 bytes of padding when I called dtc.

[nomis]

It works ok for me with the padding:
$ fdtput -t s arch/arm/boot/bcm2835-rpi-b.dtb /chosen bootargs "test"

Here's a sample .dtb with 4KB of padding: http://s85.org/EkRirRIb:raw

[popcornmix]

Okay, I'll look more closely at how fdtput does it.

[nomis]

The memory value should be changed to reserve the GPU's memory area instead of pretending it doesn't exist:

On 01/06/12 02:47, Stephen Warren wrote:

On 05/30/2012 07:25 PM, Stephen Warren wrote:

On 05/30/2012 05:12 AM, Simon Arlott wrote:

On Wed, May 30, 2012 04:45, Stephen Warren wrote:
...
These are not required. If not using the future bootloader, ftdput can be
used to set up those values. Memory is not fixed (256MB below is invalid as
the GPU requires some memory).

One thing I forgot to mention on the memory front. It's typical for the
memory property to represent the entire physical RAM on the board, even
if something else is using parts of it, so Linux can't touch it. You can
prevent Linux from using parts of the memory with the /memreserve/
syntax in the .dts file, which the bootloader should be able to add or
adjust as appropriate based on system configuration.

[nomis]

libfdt has functions to delete and add reserved memory but fdtput has no functionality to use them.

128MB:
(echo -ne "\x00\x00\x00\x00\x08\x00\x00\x00"; echo -e "\x00\x00\x00\x00\x08\x00\x00\x00") | \ dd conv=notrunc bs=8 count=2 seek=5 of=arch/arm/boot/bcm2835-rpi-b.dtb

192MB:
(echo -ne "\x00\x00\x00\x00\x0c\x00\x00\x00"; echo -e "\x00\x00\x00\x00\x04\x00\x00\x00") | \ dd conv=notrunc bs=8 count=2 seek=5 of=arch/arm/boot/bcm2835-rpi-b.dtb

224MB:
(echo -ne "\x00\x00\x00\x00\x0e\x00\x00\x00"; echo -e "\x00\x00\x00\x00\x02\x00\x00\x00") | \ dd conv=notrunc bs=8 count=2 seek=5 of=arch/arm/boot/bcm2835-rpi-b.dtb

[nomis]

Could you explain the purpose of the the DMA channels mask?

Channels 11 and 12 generate unexpected interrupts constantly.
Channels 13 and 14 haven't got interrupts.
Channel 15 never generates any interrupts (and it has an AXI ID of 0).

If I try to use channels 0-10 then 0-1 and 6 don't generate any interrupts but 2-5 and 7-10 work.
If I try to use channels 2-5 and 7-10 then only 2-5 work and 7-10 don't generate any interrupts.

[nomis]

I've updated the location and name of the /system attributes, and the name of the /display and /axi/dma attributes to include "broadcom," prefixes.

[nomis]

Channel 11 generates interrupts as normal
Channels 12-14 all generate interrupts on the IRQ for channels 11 and 12
Channel 15 isn't enabled and can't be enabled

Unless I try to use channel 6 (which never works), channels 7-10 don't work... channels 2-5 and 11-14 always work.

[popcornmix]

Some info first. DMA is shared with GPU. This is typical usage:

DMA1: PWM audio
DMA2: ARM SDCARD
DMA6: GPU SDCARD
DMA15: GPU dma_memcpy

Once the ARM boots, DMA6 won't be used again by GPU (although I haven't tested what happens if interrupts go off - possibly something bad).

The DMA mask is the channels the GPU guarantees not to use. So 0x3c means GPU won't use 2,3,4,5.

So 2,3,4,5 should definitely work. Anything is not designed to be used by ARM, and possibly the GPU will also respond to interrupts, making behaviour undefined.

However as the GPU is never going to use more than a few DMA channels, it might be worth increasing the DMA mask to allow the ARM to make use of the channels, and see if the extra channels start working.

As background he's some info I discovered for teh-orph about burst sizes and lockups:

"If you do a big read burst then the DMA will ask for the required no
of beats but only consume 2 128 bit word. The DMA will then stall its
read bus, write out the data and then consume some more.
This runs the risk of a system wide lockup where the stalled read is
preventing the DMA write from completing due to some circular
dependency somewhere in the AXI system.

To make this safe, DMA0 and the VPU DMA (DMA15) have an 8 deep FIFO fitted to
the read data path. This adsorbs the extra read words and the read
bus then completes and becomes ready. The DMA then sucks the data out
of the fifo as it needs it.

You should be able to do read bursts of 9 with DMA0. 8 beats in the
fifo and 1 gets eaten by the DMA. 10 might also make it if the data
is aligned, else it gets stuck in the DMA arbiter which may stall all
the other channels until it clears.

However if he is managing 5 on a dma with no fifo then I assume that 2
in the DMA , and 1 in the DMA arbiter, and then 1 in the system
arbiter, 1 in the L2 or sdram arbiter and then you have a possible
system lock up so 6 would make sense."

[nomis]

Could the GPU use one of the Lite channels for audio? Presumably this is related to audio/video playback by the GPU as the audio driver could do DMA itself.

It appears that the GPU is doing something odd with DMA6 causing DMA7-10 to stop working.

[nomis]

Added /axi/sdhci/clock-frequency

[nomis]

Added /axi/uart0/clock-frequency

The kernel has a subsystem to manage clock frequencies and enable/disable clocks so an interface to do that would be better than having to pass it through device tree.

[popcornmix]

Can you check: raspberrypi/firmware#47