How to configure SPI on BBB?

Discussion about U-Boot and the kernel.

How to configure SPI on BBB?

Postby wulfspider » Fri Mar 16, 2018 12:59 am

Hi all,

I want to use SPI on my BeagleBone Black. How do I configure this? I read somewhere that uEnv.txt is deprecated and that it won't be used anymore.

Thanks!
wulfspider
 
Posts: 4
Joined: Tue Sep 06, 2016 6:41 pm

Re: How to configure SPI on BBB?

Postby summers » Fri Mar 16, 2018 1:37 pm

OK, so first off - I've never done this myself, so this is untested. But I did look into it at one stage, as a route to put a pressure sensor and computer in a kinder egg, before moving onto a teensy3.2 ....

First off, the am335x spi pin out are IIRC shared with the HDMI, so that needs disabling.

The main BBB site does this in uboot, using a heavily modified uboot with BBB specific commands in it. That isn't the uboot that Arm Arch uses. So in Arm Arch we have to do it the preferred arm linux way, and that means modifying the device tree. Now whilst the device tree in /boot/dtbs could be modified - this isn't a good solution as it will get overwritten when the kernel gets updated.

So how else to modify the device tree, well there are device tree overlays in /lib/firmware/ looks like several are to do with BBB and SPI:

$this->bbcode_second_pass_code('', '/lib/firmware/BB-LCD-ADAFRUIT-18-SPI1-00A0.dtbo
/lib/firmware/BB-SPI0-ADS8688-0A00.dtbo
/lib/firmware/BB-SPI0-MCP3008-00A0.dtbo
/lib/firmware/BB-SPIDEV0-00A0.dtbo
/lib/firmware/BB-SPIDEV1-00A0.dtbo
/lib/firmware/BB-SPIDEV1A1-00A0.dtbo
')

Wether any of those are any good or not, I don't know - some googling may tell you what they are for.

But first we need to go the way of removing the HDMI, I'm not sure if overlays can do that, so we need the uboot code to do this. Now this is known and tested, assuming you are on the latest BBB image you have two files /boot/boot.src and /boot/boot.txt .The src file is created with mkimage, thats coded in the file mksrc.

So we just edit boot.txt, then recreate boot.src with mksrc.

To remove the hdmi, after the lines:

$this->bbcode_second_pass_code('', ' if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile};
then
gpio set 55
')

You need to add

$this->bbcode_second_pass_code('', ' fdt addr ${fdt_addr_r}
# take out the framer
fdt rm /ocp/i2c@44e0b000/tda19988
# disable the lcdc and remove its pins
fdt set /ocp/lcdc@4830e000 status "disabled"
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/nxp_hdmi_bonelt_pins
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/nxp_hdmi_bonelt_off_pins
# disable the sound and remove pins
fdt set /ocp/mcasp@48038000 status "disabled"
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/mcasp0_pins
')

So thats the HDMI removed. Now loading of SPI definition. Lets follow the overlay direction first. Need a bit of background, the memory map that uboot uses, which is the lowmen. To quote from a uboot source file (ti_armv7_common.h)

$this->bbcode_second_pass_quote('', ' ') 33 /*
34 * We setup defaults based on constraints from the Linux kernel, which should
35 * also be safe elsewhere. We have the default load at 32MB into DDR (for
36 * the kernel), FDT above 128MB (the maximum location for the end of the
37 * kernel), and the ramdisk 512KB above that (allowing for hopefully never
38 * seen large trees). We say all of this must be within the first 256MB
39 * as that will normally be within the kernel lowmem and thus visible via
40 * bootm_size and we only run on platforms with 256MB or more of memory.
41 */

And it sets up:
$this->bbcode_second_pass_code('', ' 42 #define DEFAULT_LINUX_BOOT_ENV \
43 "loadaddr=0x82000000\0" \
44 "kernel_addr_r=0x82000000\0" \
45 "fdtaddr=0x88000000\0" \
46 "fdt_addr_r=0x88000000\0" \
47 "rdaddr=0x88080000\0" \
48 "ramdisk_addr_r=0x88080000\0" \
49 "scriptaddr=0x80000000\0" \
50 "pxefile_addr_r=0x80100000\0" \
51 "bootm_size=0x10000000\0" \
52 "boot_fdt=try\0"
53 ')
So think to note is that the kernel is loaded into 0x82...; the device tree into 0x88..; and the initramdisk into 0x8808.

Reason for giving these is we need somewhere to load the overlay. The overlay should be small so go for:

0x88060000

So we pinch a bit of the device tree allocation. We could also pinch some of the ramdisk, as that isn't really needed on BBB - but I won't go there.

So after the code above to remove hdmi add:

$this->bbcode_second_pass_code('', '
load ${devtype} ${devnum}:${bootpart} 0x88060000 /lib/firmware/BB-SPIDEV0-00A0.dtbo
fdt resize
fdt apply 0x88060000
fdt resize
')
You could obvious try other overlay files, or disable them to see what they contain.

Then after creating boot.src and rebooting, hopefully you'll have spi dev 0.

I'll do another post after this as to how to do this without the overlay. Also do recall, aside from removing HDMI this hasn't been tested ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: How to configure SPI on BBB?

Postby summers » Fri Mar 16, 2018 1:57 pm

Oh yes - what I also should have said is this is a good read:

https://elinux.org/BeagleBone_Black_Enable_SPIDEV

And you can view the source of the overlays e.g. using:

$this->bbcode_second_pass_code('', 'dtc -O dts -I dtb /lib/firmware/BB-SPIDEV0-00A0.dtbo')
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: How to configure SPI on BBB?

Postby claydonkey » Sat Mar 17, 2018 11:59 am

That's quite an effort summers. Great stuff.
Unfortunately I have tried this method with no success.

$this->bbcode_second_pass_code('', '$ uname -a

Linux alarm 4.15.10-1-ARCH #1 Sat Mar 17 00:10:41 UTC 2018 armv7l GNU/Linux

$ lsmod
evdev 24576 1
uio_pdrv_genirq 16384 0
uio 20480 1 uio_pdrv_genirq
cpufreq_dt 16384 0
sch_fq_codel 20480 3
usb_f_ecm 20480 1
g_ether 16384 0
usb_f_rndis 32768 2 g_ether
u_ether 20480 3 usb_f_ecm,g_ether,usb_f_rndis
libcomposite 57344 3 usb_f_ecm,g_ether,usb_f_rndis
ip_tables 24576 0
x_tables 28672 1 ip_tables
')

You'll have to excuse me but I last worked with a BBB three years ago and I am about to potter around with it once more...

Currently, is your method the generally accepted way of loading Device Tree Overlays in Arch Linux for BBB?
(what happened to bone_capemgr and uenv.txt?)
Also what are and where do the variables: ${devtype} ${devnum}:${bootpart} come from and is there any documentation on this method?
Thanks
claydonkey
 
Posts: 2
Joined: Thu Dec 07, 2017 4:03 pm

Re: How to configure SPI on BBB?

Postby summers » Sun Mar 18, 2018 2:56 pm

OK, do you have a serial adaptor connected to the BBB uart? If so you would be able to see what uboot said when doing the commands. That would give some idea of if it worked.

Now from looking at my BBB device tree, if you manage to enable SPI0 then:
$this->bbcode_second_pass_code('', 'cat /proc/device-tree/ocp/spi\@48030000/status')
Should give "okay", mine gives "disabled" - but I havn't enabled SPI ....

Looking at /lib/firmware/BB-SPIDEV0-00A0.dtbo, and I'm not completely clear on how these overlays work, it looks to me like it is just adding pins to the spi definition.

If so the directory
$this->bbcode_second_pass_code('', 'ls /proc/device-tree/ocp/spi\@48030000/')
Should have some pinctrl files, and also two directories call channel@0 and channel@1.

If all this checks out I'd use "dmesg| grep spi"

Now your question as to is this the accepted arch method of loading device trees, I don't know how to answer.

BBB is an ArmArch supported board, Arch though generally just installs plain vanilla code. As far as I'm know, no one is paid to devlop, any solutions, let alone BBB overlay solutions.

So the only way to answer your question, is how does plain vanilla code do BBB overlays.

So first off, need to consider where the BBB people themselves have gone in the last few years. First off Read : https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Where_did_the_slots_file_go.3F and then move onto https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays.

So the story there is they have moved to doing overlays in uboot, and using a heavily modified version of uboot.

Now this isn't what ArmArch is doing, the uboot here is the plain valillla one from https://www.denx.de/wiki/U-Boot.

Now how device trees are handled in uboot is not well documented. But if you search long and hard enough you find the "ftd apply" command, that is the *only* method I've found that officially does overlays.

You other option is to rewrite the device tree in uboot, I may try that later.

Is this a good situation? Again I don't know how to answer this. The beagle world is a SBC with huge pin out options, that is its beauty. However multi pin out options doesn't fit well inside and OS, who configures those options and how? The device tree is a natural solution, but it just changes the question as to who changes the device tree. I think its generally agreed that it can be done in boot loader stage, e.g. uboot. Views vary on making changes in the OS.

Take for example, the commands I gave in uboot, to remove the HDMI. That is literally just cutting out part BBB hardware, like it isn't their. If that was done on a running kernel, it would probably crash. Kernels don't expect HDMI interfaces to suddenly disappear.

I suspect this hasn't answered your question, but think its the best answer I can give ...
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: How to configure SPI on BBB?

Postby summers » Sun Mar 18, 2018 3:08 pm

OK, I just tried it. Changed my /boot/boot.txt to

$this->bbcode_second_pass_code('', '# After modifying, run ./mkscr

if test -n ${distro_bootpart}; then setenv bootpart ${distro_bootpart}; else setenv bootpart 1; fi
part uuid ${devtype} ${devnum}:${bootpart} uuid

setenv bootargs "console=ttyS0 console=${console} root=PARTUUID=${uuid} rw rootwait"

if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /boot/zImage; then
gpio set 54
echo fdt: ${fdtfile}
if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
gpio set 55
fdt addr ${fdt_addr_r}
# take out the framer
fdt rm /ocp/i2c@44e0b000/tda19988
# disable the lcdc and remove its pins
fdt set /ocp/lcdc@4830e000 status "disabled"
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/nxp_hdmi_bonelt_pins
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/nxp_hdmi_bonelt_off_pins
# disable the sound and remove pins
fdt set /ocp/mcasp@48038000 status "disabled"
fdt rm /ocp/l4_wkup@44c00000/scm@210000/pinmux@800/mcasp0_pins
# enable an overlay
load ${devtype} ${devnum}:${bootpart} 0x88060000 /lib/firmware/BB-SPIDEV0-00A0.dtbo
fdt resize
fdt apply 0x88060000
fdt resize
if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /boot/initramfs-linux.img; then
gpio set 56
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r};
else
gpio set 56
bootz ${kernel_addr_r} - ${fdt_addr_r};
fi;
fi;
fi
')
Ran "mksrc". Rebooted - and all I said above worked. I now have two files:
$this->bbcode_second_pass_code('', '/dev/spidev0.0
/dev/spidev0.1')
And that seems to be SPI enabled.

So we just need to work out what you didn't do ...
Last edited by summers on Mon Mar 19, 2018 1:52 pm, edited 1 time in total.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: How to configure SPI on BBB?

Postby claydonkey » Sun Mar 18, 2018 8:11 pm

So just to tell you what you already know.
I made an error and put the statement "load ${devtype} ${devnum}:${bootpart} 0x88060000 /temp/BB-SPIDEV0-00A0.dtbo
" after bootz. Duh!
The spi devices work as expected now

$this->bbcode_second_pass_code('', '
$ lsmod
Module Size Used by
uio_pruss 16384 1
spidev 20480 0
evdev 24576 2
cpufreq_dt 16384 0
uio_pdrv_genirq 16384 0
uio 20480 4 uio_pruss,uio_pdrv_genirq
sch_fq_codel 20480 3
usb_f_ecm 20480 1
g_ether 16384 0
usb_f_rndis 32768 2 g_ether
u_ether 20480 3 usb_f_ecm,g_ether,usb_f_rndis
libcomposite 57344 3 usb_f_ecm,g_ether,usb_f_rndis
ip_tables 24576 0
x_tables 28672 1 ip_tables
')

Thanks for you help :)
claydonkey
 
Posts: 2
Joined: Thu Dec 07, 2017 4:03 pm

Re: How to configure SPI on BBB?

Postby summers » Mon Mar 19, 2018 8:43 pm

Glad it worked. Oh yes I forgot to say, the overlay file had the lines:
$this->bbcode_second_pass_quote('', ' ') __overlay__ {

P9_17_pinmux {
status = "disabled";
};

P9_18_pinmux {
status = "disabled";
};

P9_21_pinmux {
status = "disabled";
};

P9_22_pinmux {
status = "disabled";
};

That looks like its grabbing back the spi pins, so it can use them. Makes me wonder if the lines to take out the HDMI that I had are needed, mine rather agressivlty took out the HDMI, because when we tried taking it out in a lesser way, bits complained. But maybe just disabling the pins, rather than the whole HDMI would work. I havn't tried it myself, the way to be sure would be to look at the default device tree, and see what the above pins are for, e.g. are they some of the pins that I just removed from the tree?
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Re: How to configure SPI on BBB?

Postby Zeno » Fri Mar 23, 2018 5:19 pm

Hi everyone,
I've been solving related problem to this new way of loading overlay files, so I decided to post my findings in this topic. Regarding SPIs, seems like there is usefull base DTB am335x-boneblack-bbbmini.dtb which has no HDMI by default and exposes all SPI interfaces, this way, you could avoid loading that additional overlay - simplifies things a bit. Afterwards, I wanted to load my own overlay (which just changes modes of some other pins) using your method, but according to boot log, fdt apply command resulted in fdt_overlay_apply(): FDT_ERR_NOSPACE. Tried some other chaotic experiments with it but to no avail. So I googled around a bit and found an inspiration in RC Nelson's work https://github.com/RobertCNelson/Bootloader-Builder/blob/6f3929a577056d10a7994252aa521835bf3f3984/patches/next/0002-U-Boot-BeagleBone-Cape-Manager.patch and used it accordingly in my boot.txt just after loading the main DTB, as follows:
$this->bbcode_second_pass_code('', '
.....
#use bbbmini base fdt
setenv fdtfile "am335x-boneblack-bbbmini.dtb"
if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /boot/dtbs/${fdtfile}; then
gpio set 55
#load overlay to safe free space, so it does not overlap with anything else
load ${devtype} ${devnum}:${bootpart} ${rdaddr} /lib/firmware/custom_cape-00A0.dtbo
#select base fdt to work on
fdt addr ${fdtaddr}
#from u-boot doc: Resize fdt to size + padding to 4k addr? just grow fdt so it can fit applied overlays..
fdt resize 0x60000
#apply overlay loaded at rdaddr
fdt apply ${rdaddr}
#seems like the second resize is not necessary, works both with and without it
# fdt resize 0x60000
.....
')
This in the end successfully loaded my overlay. Only difference in the end is that resize has additional size parameter, load address is not that important (works both with using rdaddr=0x88080000 and 0x88060000 summers proposed). Seems to me like that fdt resize whithout size parameter just added none or too little space to apply my overlay. I assume that fdt resize 0x60000 could then accomodate for 384kB DTB and also 0x88060000 is in this case just right and safe address to use for loading overlays, seems like largest DTBs on BBB are around 150kB anyways (this info could be usefull while loading several overlays). Using rdaddr (ram disk address) is probably ok too, that space will be then just overwritten by initramfs image (last lines of boot.txt).
Have a nice day!
Zeno
Zeno
 
Posts: 14
Joined: Wed May 03, 2017 5:00 pm

Re: How to configure SPI on BBB?

Postby summers » Sat Mar 24, 2018 2:41 pm

@zeno. Excellent stuff! I'm glad someone is continuing this. The BBB is great kit for its many and various IO ports, so its good that people that are using Arch, are also doing the various IO things. My own BBB, usually sits headless attached to my NAS. Its rare I go physically near it, let alone plug in the UART, or attach a cape. Alas my life is to busy. So I'm glad that others are doing so, and improving the methods of doing capes under arch.

Guess I should give some background to my method, where it came from. This is probably needed, as modifying device trees is terribly documented. Me I came across "fdt apply" browsing the uboot source code - I had a PocketBeagle, and uboot needed modifying to bring it, so whilst browsing source code - I came across "fdt apply", it needed an option set in uboot for it to be configured, but that option was on by default in the various Beagle configurations. I had never seen or heard of "fdt apply" - it wasn't documented on the denx web site. However digging like you came across: http://git.denx.de/?p=u-boot.git;a=commit;h=e6628ad7b99b285b25147366c68a7b956e362878, "fdt apply" came into uboot something like 2 years ago, and if you read up on what Maxime has been doing - he's been patching master source code everywhere to these kind of embedded arm boards working in linux. But also like you came across RobertCNelson https://groups.google.com/forum/#!topic/beagleboard/W0QPDee5u2s, Robert was using "fdt apply" before he went the direction of franken style uboot. Robert is the main man maintaining BBB and BBB overlays, don't know if he is a TI employee or not - but he must be pretty close.

Anyway Robert suggested "fdt resize; ftd apply; fdt resize", and said that the kernel bombed without this. Now I when I looked at removing the HDMI from the device tree, and doing overlays - my BBB was still attached to the NAS. This means that if you brick the device, I need to recover it - and its a hassle for me to plug in the UART, that at the moment being used on a Teensy, developing code. Hence when I made changes to the boot.txt - these were on the conservative side, as I needed it to come back up again. So before every change much research, and hence why I used the Robert "fdt resize; ftd apply; fdt resize"; but like you I questioned the need for the second "fdt resize" - as when its issued it is too late; anyway conservatism applied -so I kept it, at least until I could get the box to boot correctly.

One thing I did dig into, was the memory map, and that was why I posted it. Yes Robert said could write the overlay to the ramdisk memory area, I didn't like that as by default, as ArchArm uses a ramdisk, now the ramdisk I don't think has anything important in it - so the BBB could boot without the initramdisk, but wanted to keep the default, and didn't know if the overlay would interfere with the ramdisk. Hence why I split the device tree area, but I checked everything would fit.

Default uboot size: 512KB : 0x80000
BBB devicetree: 57KB
SPI Overaly: 1.5KB

So there was clearly room in the device tree area, and hence why I split that.

Now you resize by 0x60000, isn't that 384KB - I can't see why we would need anything that big for an overlay.

You said you had FDT_ERR_NOSPACE, was this with the 0x60000 option? With my option which adds 4KB (or is it taken to next 4KB boundary, not clear), should be able to apply twice without problems.

But good that you checked that we don't need the second "fdt reise".

Good find on changing the default device tree, yes you'll need to specify in the boot.txt - by defualt uboot reads the eeprom, and sets up a device tree depending on the signature there. So a BBB by default will always use the default device tree, unless you update. I never dug into what the other device trees did, I'm usually only happy decompiling them to source, and see what the differences are - whereas modifying a device tree, you can see what differences you make. Yes modification is more work, but also more transparent. So I'm myself quite neutral on that.

Anyway keep up the good work.
summers
 
Posts: 984
Joined: Sat Sep 06, 2014 12:56 pm

Next

Return to U-Boot/Kernel

Who is online

Users browsing this forum: No registered users and 7 guests