**** BEGIN LOGGING AT Wed Apr 10 02:59:57 2019 Apr 10 03:31:56 (success) **** BEGIN LOGGING AT Wed Apr 10 06:45:24 2019 Apr 10 14:18:39 Hi all, does the Beaglebone Black support full duplex SPI? Apr 10 14:21:32 yes Apr 10 14:21:42 standard 4-wire spi is full-duplex Apr 10 14:22:49 Do I need to enable full duplex? I get the "SPI error: full duplex unsupported" when communicating with SPI in Barebox Apr 10 14:24:18 you normally don't need to enable it Apr 10 14:24:22 full duplex is just part of SPI Apr 10 14:24:26 that's how it works Apr 10 14:24:35 make sure you're in standard SPI, not quadSPI or other stuff Apr 10 14:25:27 it's called 4-SPI or 4-wire SPI, because you have clock, chip-select, master in slave out, master out slave in Apr 10 14:25:53 data is clocked in and out in parallel on MISO and MOSI Apr 10 14:27:39 ok thanks, I'll check if I'm in standrad SPI Apr 10 14:39:43 what a strange error Apr 10 14:41:32 why do you need spi communication in the bootloader anyway? you're trying to use an external SPI flash or something? Apr 10 14:42:20 I'm trying to implement a secure boot concept with a Trusted Platform Module Apr 10 14:43:30 some googling shows that this error is from some ancient version (2012) of the McSPI driver in barebox Apr 10 14:43:48 maybe noone has improved the barebox driver since then. Apr 10 14:44:16 "secure" boot :D Apr 10 14:44:50 I don't get this error either, it jumps into omap3_spi.c in barebox even though the beaglebone does not use the omap3 Apr 10 14:45:04 same spi peripheral Apr 10 14:45:07 And there is the line: else if ((t->tx_buf != NULL) && (t->rx_buf != NULL)) { printf("SPI error: full duplex unsupported\n"); ret = -EINVAL; Apr 10 14:45:11 es Apr 10 14:45:12 yes Apr 10 14:45:34 i.e. whoever wrote the driver didn't bother implementing it properly Apr 10 14:46:25 puh ok, this is not what I was hoping for Apr 10 14:47:45 I'm pondering whether an external TPM on a beaglebone is able to offer any security benefits at all... certainly not many. Apr 10 14:47:59 Is SPI GPIO Bitbang possible on the Beaglebone black? Apr 10 14:48:28 a dynamic root of trust is impossible with or without TPM. a static root of trust is possible with or without TPM. protection against physical attacks would require gooping up the whole thing in epoxy (with or without TPM) Apr 10 14:48:43 you can bitbang SPI on any device Apr 10 14:48:45 The Beaglebone is more like a proof of concept Apr 10 14:49:08 I already implemented it for the Raspberry Pi Apr 10 14:49:30 it probably also wouldn't be hard to fix the driver Apr 10 14:49:58 e.g. based on the u-boot one Apr 10 14:52:21 Good point, I'll check out the U-Boot omap3_spi.c Apr 10 14:57:59 Is there an example for the am33xx.dtsi device tree for a SPI GPIO Bitbang node? Apr 10 14:58:25 why would there be? am33xx.dtsi is the SoC description Apr 10 14:58:42 gpio-bitbang is an architecture-independent use of gpio Apr 10 14:58:48 *spi-bitbang Apr 10 14:59:53 I don't really get how to set the gpio-mosi etc. I can only find examples for the Raspberry Pi and there it's always gpio-mosi = <&gpio 5 0>; Apr 10 15:00:54 but how are configured for the Beaglebone? What are the Pin numbers? Apr 10 15:01:12 I mean, same as any other gpio. <&gpioX Y Z> where X is the gpio controller (0-3), Y is the gpio number (0-31), Z is the polarity (0=active-high, 1=active-low) Apr 10 15:01:13 e.g. looking at this site: http://www.sciencegizmo.com.au/?p=105 Apr 10 15:01:56 oh yes I get that, but how do I find the Pin number for e.g. GPIO 49 on the Beaglebone? Is it just gpio-mosi = <&gpio 49 0>;? Apr 10 15:02:08 if you want a concise overview of the BBB expansion header pins, including GPIO numbers, see the P9 and P8 tabs of my pins spreadsheet: https://goo.gl/Jkcg0w Apr 10 15:03:10 I also have gpio numbers in the comments of this header: https://github.com/mvduin/overlay-utils/blob/master/include/bone/pins.h Apr 10 15:03:25 and no doubt there are tons of other places you can find this information Apr 10 15:08:27 Ah ok, thanks! I didn't know where to look for. Apr 10 15:49:20 Hello, I can't seem to figure out what to put in the gpio-mosi. If the Bitbang SPI is supposed to take the GPIOs for the normal SPI0, would the line not be gpio-mosi = <&gpio0 3 0>;? Apr 10 15:57:33 <&gpio0 4 0> Apr 10 15:57:38 gpio 0.3 is miso Apr 10 15:58:07 (normally) Apr 10 15:59:14 0.02 clk (P9.22), 0.03 miso (P9.21), 0.04 mosi (P9.18), 0.05 cs0 (P9.17) Apr 10 16:01:25 ok, I set compatible = "spi-gpio"; and gpio-mosi = <&gpio0 4 0>; gpio-miso = <&gpio0 3 0>; gpio-sck = <&gpio0 2 0>; cs-gpios = <&gpio0 5 1>; num-chipselects = <1>; but now I can't communicate on the SPI at all anymore Apr 10 16:02:14 it says "spi bus 0 not found spi: No such device" but it shows up at devinfo as 48030000.spi@48030000.of Apr 10 16:02:15 and of course make sure the pins are configured to GPIO mode rather than SPI mode Apr 10 16:02:37 that sounds like the wrong device Apr 10 16:02:38 ? Apr 10 16:03:02 I replaced the spi0 in the device tree with the spi-gpio Apr 10 16:03:10 or does this not work? Apr 10 16:03:11 that's really rude and gross Apr 10 16:03:42 ok sorry, it was the fastest way to se if it works Apr 10 16:03:58 you should just leave the spi0 node disabled and create a new node (e.g. in the root, since it's a virtual device) Apr 10 16:05:29 anyway, as for how to find/use your new spi device, and if you have any problems with it, those would be barebox questions and I don't know anything about it Apr 10 16:06:25 alright, thanks a lot for your help Apr 10 16:09:38 btw, if your goal is to actually increase security by even the smallest amount, and not merely "communicate with a TPM", you should probably look into eMMC security features. in particular making sure that the "secure bootloader" in eMMC is write-protected until next power-on before execution leaves the secure bootloader (to ensure later software can't simply replace the bootloader by a malicious one) Apr 10 16:11:56 (though be careful not to accidently enable permanent write protection ;) Apr 10 16:13:06 you'll also want to disable the eMMC reset pin (this is an OTP setting), to ensure software can't make the eMMC think the system has reset Apr 10 16:14:31 it really sucks that TI doesn't prove basic boot security (with a dynamic root of trust) on all their SoCs, even though it would be pretty easy to do Apr 11 02:46:36 so sfdisk has a --move-data feature ... so to move the start of the first partition: echo 4m, | sfdisk --move-data -N 1 /dev/mmcblk1 Apr 11 02:46:42 will see if this works... Apr 11 02:47:26 one downside is that it won't know what is empty space and move that too Apr 11 02:48:06 slightly nicer would be to first shrink the filesystem and partition to minimum size, then move, then expand again Apr 11 02:49:04 right Apr 11 02:49:45 given the tight constraints on this 2GB eMMC ... there isn't much empty space overall Apr 11 02:50:55 also, moving the partition further ahead means you currently need to have some free space after the partition Apr 11 02:51:12 if you don't have any, you'll need to shrink the filesystem and partitoin first anyway Apr 11 02:52:14 i didn't feel bold enough to try the move on the live mounted filesystem ... e.g. i did an install to microSD and am running from that Apr 11 02:52:35 actually having more space available on the microSD is kind of a relief anyways Apr 11 02:52:50 you definitely can't move a partition while mounted Apr 11 02:52:55 you can only expand it while mounted Apr 11 02:53:12 that was my hunch Apr 11 02:53:48 so.. what are you doing exactly that makes this necessary? why not create the card correctly in the first place? or, if flashing to eMMC, why not create the partitions correctly there? Apr 11 02:54:22 i want to see if i can resurrect the install i had already done Apr 11 02:54:45 remarkably, fsck didn't seem to think there was anything wrong with it ... but u-boot could not boot from it any longer Apr 11 02:55:08 ? what did you do to it? Apr 11 02:55:28 i tried installing u-boot 2019.04 ... which was a little too large. Apr 11 02:56:30 if fsck didn't complain that suggests no ext4 structures have been overwritten Apr 11 02:56:36 or rather, my trimmed down am335x-evm build that only included the beaglebone device-trees Apr 11 02:57:17 how it would be big enough to make u-boot not see the partition, but not enough to corrupt the filesystem seems ... a little surprising Apr 11 02:57:45 unless there's a backup partition table and u-boot doesnt' know how to read it? Apr 11 02:57:53 anyway, I'd just wipe and repartition the card or eMMC, and either dd the filesystem image (shrunk to min size) onto the partition (and expand it) or just copy all files Apr 11 02:58:28 "backup partition table" ? what? why would there be anything wrong with the partition table? Apr 11 02:58:32 sure, that would be my inclination, but then i found this sfdisk feature Apr 11 02:58:56 u-boot is located in between the partition table and root filesystem Apr 11 02:59:56 that assumes it fits **** ENDING LOGGING AT Thu Apr 11 02:59:58 2019