New device tree kernel is in testing

[PeterO]

Right, I **think** I'm getting somewhere now, BUT..

Code: Select all

sudo vcdbg log msg
.......
000782.987: Loading 'kernel.img' from SD card
001020.326: Kernel trailer DTOK property says yes
001020.499: Loading 'bcm2708-rpi-b-plus.dtb' from SD card
001025.720: dtparam: i2s=on
001031.087: Failed to load overlay 'pjoaudio-adc'

Hardly the most informative error message !!!! I would help if if told me something I didn't already know

Is there a way to get more detailed debug info ?

PeterO

[PhilE]

You can set dtdebug=1, but it is almost certainly because the file isn't there. Can you run ls /boot/overlays?

[PeterO]

You can set dtdebug=1, but it is almost certainly because the file isn't there. Can you run ls /boot/overlays?

Yeah, a little bit of finger trouble which I spotted before I read that

Code: Select all

001034.446: Loaded overlay 'overlays/pjoaudio-adc.dtb'

Now all I have to do is work out why the alsa record device doesn't appear !!!

PeterO

[PeterO]

WOO HOO !!!!

Code: Select all

pi@raspberrypi ~/alsacap $ ./alsacap -R
*** Scanning for recording devices ***
Card 0, ID `sndrpipjoaudioa', name `snd_rpi_pjoaudio_adc'
  Device 0, ID `pjoaudio ADC HiFi pcm1803a-hifi-0', name `', 1 subdevices (1 available)
    2 channels, sampling rate 96000..96000 Hz
    Sample formats: S32_LE
      Subdevice 0, name `subdevice #0'
Card 1, ID `ALSA', name `bcm2835 ALSA'
pi@raspberrypi ~/alsacap $ 

[PhilE]

I'm happy that your perseverance was rewarded. That's no small achievement.

[PeterO]

I'm happy that your perseverance was rewarded. That's no small achievement.

Thanks Phil,

Sorry if I got a bit frustrated earlier, but we got there in the end

It was your post referencing the HiFiBerry DAC overlay that was the key. It was the simple example that I needed to see inorder to work out just what was needed I also went and looked at the source for the corresponding module which used a different way to specify the ALSA interface, and when I changed my driver to do it the same way everything started to work

Thanks again for sticking with me (even when I got grumpy)

PeterO

[PhilE]

@notro I've added support for 8-, 16- and 64-bit parameters to the loader. The syntax is:

Code: Select all

 8-bit: <&node>,"property.offset"
16-bit: <&node>,"property;offset"
32-bit: <&node>,"property:offset"
64-bit: <&node>,"property#offset"

The updated firmware with this feature should make its way out in the next day or two.

[fivdi]

@PhilE did you invent the following syntax?

Code: Select all

8-bit: <&node>,"property.offset"
16-bit: <&node>,"property;offset"
32-bit: <&node>,"property:offset"
64-bit: <&node>,"property#offset"

If so, here's a possible improvement where ';' and ':' have been swapped:

Code: Select all

8-bit: <&node>,"property.offset"
16-bit: <&node>,"property:offset"
32-bit: <&node>,"property;offset"
64-bit: <&node>,"property#offset"

Here's the "logic" behind it:
'.' is visually smaller than ':' which is visually smaller than ';' which is visually smaller than '#'.
This corresponds to 8 < 16 < 32 < 64 and might make things easier to remember, assuming you're aware of this rule.

On the other hand, maybe the idea is a little to crazy to be of any help to anyone.

[PhilE]

Yes, I invented the syntax. Although I take your point about the visual element, bear in mind that the colon (:) was already in use for 32-bit ints. And I liked this order because the semicolon (;) is half a colon (:), but that may be an Anglocentric joke.

[fivdi]

Yes, that's nice. If half a colon is 16 bits then a colon is obviously 32 bits.
That's easy enough to remember

[PhilE]

Support for the new DT parameter sizes is in the latest firmware release, available via rpi-update.

[notro]

I've added support for 8-, 16- and 64-bit parameters to the loader.

16-bit worked fine, thanks Phil.

[msperl]

Would it be possible to add a means to update 2 fields with one "parameter"?

Its most practical use would be to configure incoming interrupts with one "parameter".

Right now we have to provide 2 parameters:

Code: Select all

		can0_interrupt =	<&can0_pins>,"brcm,pins:0";
		can0_interrupt2 =	<&can0>,"interrupts:0";

with identical content to make it work, which seems a bit "stupid" from a user perspective...

maybe something like:

Code: Select all

 parameter = <ref>,"def"[,<ref>,"def"]...

Also from my perspective it is a bit unclear if the parameters would be unique to the overlay or would be of "global" impact.

so:

Code: Select all

dtoverlay=mcp2515-spi0.0,oscillator=16000000,interrupt=25
dtoverlay=mcp2515-spi0.1,interrupt=26

would mean we set oscillator to identical values for both overlays or not and if interrupt would be set to 25/26 for the respective device. Or if I would need to prefix them like the "can0_oscillator" example above.

[PhilE]

Code: Select all

parameter = <ref>,"def"[,<ref>,"def"]...

You can do that already - try it. Some of the existing overlays use it for the same reason. Yes, it's on the list to document...

Code: Select all

dtoverlay=mcp2515-spi0.0,oscillator=16000000,interrupt=25
dtoverlay=mcp2515-spi0.1,interrupt=26

Now this is documented. There are up to two DTBs in "scope" (their parameters are available for use) at any time. The most recently loaded overlay, if there is one, and the base DTB for the board. When you use a parameter, it searches for the declarations in the DTBs in that order. You can end the scope of an overlay explicitly should you wish, for example to access a parameter in the base DTB that has been masked by an overlay (don't do this!), using "dtoverlay=".

Note that if you are using a HAT, any overlay stored in the EEPROM is considered to be active at the top of config.txt. You can suppress the use of that overlay by adding "dtoverlay=" before doing anything else related to overlays or parameters.

[notro]

Is it possible to enable a boolean DT property with an overlay argument (ie. insert property)?
of_property_read_bool() returns true if the property is present in the tree, so I can't set the value to zero.

[PhilE]

No, annoyingly. Do you want to suggest a syntax? How about:

Code: Select all

"bool_parameter?"

?

[notro]

I see that property names can contain all your special markers except colon. But since we are already violating this, I can't see questionmark being very likely to hit in a prop name. And ? is descriptive.

Code: Select all

Table 2-2 Characters for property names
Character Description
0-9       digit
a-z       lowercase letter
,         comma
.         period
_         underscore
+         plus sign
-         dash
?         question mark
#         hash

Ref: 2.2.4.1Property Names https://www.power.org/wp-content/upload ... D_v1.1.pdf

[PhilE]

The code is finished, but it requires integrating and testing. It will probably be released tomorrow.

[PhilE]

The new firmware was released yesterday. If you rpi-update you will get support for boolean parameters as discussed.

Also, if you have a HAT with a programmed eeprom then you will find that the vendor and product information now appears in /proc/device-tree/hat.

[notro]

Boolean argument working fine, thanks Phil.

HAT eeprom values as well

Code: Select all

pi@raspberrypi:~$ ls -l /proc/device-tree/hat/
total 0
-r--r--r-- 1 root root  4 Mar 16 17:03 name
-r--r--r-- 1 root root 14 Mar 16 17:03 product
-r--r--r-- 1 root root  6 Mar 16 17:03 product_id
-r--r--r-- 1 root root  6 Mar 16 17:03 product_ver
-r--r--r-- 1 root root 36 Mar 16 17:03 uuid
-r--r--r-- 1 root root 20 Mar 16 17:03 vendor

pi@raspberrypi:/proc/device-tree/hat$ for f in *; do (cat "${f}"; echo); done
hat
RPi-Display B+
0x0001
0x0001
90a11443-7057-4587-8e56-fe7d5d1c7022
Watterott electronic

[gaverlan]

Hi everyone.

I'm trying to figure out how to use device tree with the config option kernel_old=1.
I did some tests, and as soon as I set this option the device tree is not loaded into memory even if I force it
(by setting device_tree=bcm2709-rpi-2-b.dtb, device_tree_address=0x100 and disable_commandline_tags=2).

Is this the right behavior or do I miss something ?

[PhilE]

That is the intended behaviour. All kernel_old does is set a default kernel address of 0 (which can be overridden using the kernel_address option) and disable the device tree processing.

What are you trying to achieve? If you want the kernel image to start at 0, then try using kernel_address=0 instead. You will need to either make room for the device tree in your image or tell the firmware where you would like it loaded. These are the defaults:

Code: Select all

device_tree_address=0x100
device_tree_end=0x4000

The end is exclusive (0x3fff is the final byte), and is necessary to allow the DT to grow when overlays are applied. If you want to get an idea of how large the combined DT is, try this:

Code: Select all

dtc -I fs -O dtb -o current.dtb /proc/device-tree

This will read the files and directories under /proc/device-tree and save a Flattened Device Tree blob in current.dtb. This is the same format used by the firmware, so the size should be approximately the same.

[gaverlan]

Thank you for your quick answer.

My goal is to create a boot-loader that does not lock monitor mode and hyp mode in order to use them (as demonstrated here : viewtopic.php?f=72&t=100752).
For this purpose I have to use kernel_old=1 to override the default boot-loader.
Actually it works very well with atags, I leave free space in my binary between 0x100 and 0x4000 so that they can be loaded successfully. But since new kernel use DT instead of atags, I was trying to achieve the same thing with them.

[PhilE]

OK - I can now see the matching brace in the loader code, and the main difference with kernel_old set is bypassing the automatic insertion of the startup code, so as it stands you are stuck without DT.

I can't think of a reason not to support DT loading in kernel_old mode. It shouldn't be any more code, just a minor reshuffle.
When loading a normal kernel, the address of the ATAGs or DT is communicated in one of the registers - r2, I think. Am I right in thinking that your kernel expects the ATAGs at a fixed 0x100, and that using the same arrangement for DT is acceptable?

I'm not promising that this change would happen - I need to talk it through with the other engineers to see if I've missed some gotcha - but there's a chance we could make this work in a future firmware release.

[gaverlan]

When loading a normal kernel, the address of the ATAGs or DT is communicated in one of the registers - r2, I think. Am I right in thinking that your kernel expects the ATAGs at a fixed 0x100, and that using the same arrangement for DT is acceptable?

Yes you are right, my kernel's behavior is the same as the default raspbian kernel, it expects DT at 0x100 (or anything passed in r2 I think, I didn't try other addresses) .

Thank you very much for all your help !