00:01 <set_> I wish it was the Yocto one or the Driver one but it is not, sadly.

00:06 <set_> Oh and if you use Pickle in python3, please do not. Skilled "attackers" can sadly get into your muck w/ arbitrary code.

00:24 <zmatt> pickle is fine, you just shouldn't unpickle data from an untrusted source

00:24 <set_> oh.

00:24 <zmatt> but e.g. using pickle for locally stored data is fine

00:24 <set_> I need to be more careful.

00:24 <set_> Right!

00:26 <set_> it is like a zip file or any other tar basically. It is really hard to be trusted these days.

00:27 <set_> Not now, sort of, but security is really important. I am starting to realize it slowly.

00:30 <set_> Does anyone remember that security guy that ended up in jail, then died in the jail, and owned/started Mcaffey or whatever?

00:30 <set_> I remember people in general being so overboard about the security and now they call it "darkweb" or something.

00:31 <set_> Too many labels for things these days.

00:32 <set_> Anyway, as creepy as the bad people doing bad things is currently (for whatever reason), sometimes some good Sunshine will help.

00:32 <set_> Breathe freely!

19:33 <alfatau> hello everybody. I've a custom cape connected to the BBB. The BBB boots from emmc. My problem is that sometimes the emmc become corrupted, when the BBB is connected to the cape. If not conneted, no corruption happens. I've left P8 pins (sw id) 0-7, programmed as "default" MODE1 and pins (sw id) 32,33 programmed as "default" MODE2 - assigned to

19:33 <alfatau> emmc. Should/Can I program these pins in a different way (e.g. GPIO) keeping the device bootable from emmc? Thank you in advance

19:35 <zmatt> no, they need to be configured like that to be able to use emmc

19:37 <zmatt> and the cape should not connect anything to those pins

19:39 <zmatt> the only way I can think of how a cape might be able to cause emmc corruption is by having stuff connected to those pins.. even stub traces may affect signal integrity. although it's still a bit strange since eMMC communication is all CRC-protected

19:40 <zmatt> you could try physically cutting those pins (P8.03-06 and P8.20-25) on the cape's connector

19:43 <alfatau> thank you for you help. I also found a similar answer on the SRM (see pag. 96 "emmc conflict pins") but it mentions this: "DO NOT drive the eMMC pins until the eMMC has been put into reset. This means that if you choose to use these pins, they must not drive any signal until enabled via Software. This requires a buffer or some other form of hold

19:43 <alfatau> off function enabled by a GPIO pin on the expansion header."

19:43 <alfatau> In your opinion can I "protect" the emmc in some (software) way?

19:44 <alfatau> zmatt: in fact I tried to phisically cut the p8 pins and the corruption problem disappears

19:46 <zmatt> alfatau: that's talking about keeping the eMMC in reset to be able to use those lines for other purposes (something that was actually only possible with the old micron eMMC, not with current eMMC devices whose reset is merely edge-triggered)

19:48 <zmatt> alfatau: if cutting the cape pins fixes the problem then that confirms your cape is negatively affecting the signal integrity of those lines... does your cape have any components or traces connected to these pins?

19:50 <zmatt> alfatau: and no, there's nothing you can do about this in software

19:52 <zmatt> well, like I said the eMMC communication is CRC-protected so normally I'd expect sporadic errors to be detected and the transfer retried... but there's probably some limit on how many times the kernel retries a transfer, which I'm guessing must be happening to actually cause corruption. perhaps that retry limit could be increased as a partial workaround

19:52 <alfatau> well, I'm going to cross-check but as far as I can remember all pins are connected to the BBB; the cape is based on an FPGA handling these pins but they should not actually be driven since they have been kept for future use. I don't remeber if they are left in tristate or pullup/down.

19:52 <zmatt> alfatau: merely connecting them to an FPGA or anything else is the problem

19:56 <alfatau> @@zmatt sure, but for me is not an elegant solution to phisically cut pins, maybe the solution could be to ask the cape developers to put pins on the cape side to pull-up or pull-down? I would like to understand how to electrically obtain the same condition of not having the cape connected...

19:56 <zmatt> alfatau: the cape developers should have left these P8 pins not-connected

19:57 <zmatt> having a stub trace attached to a high-speed communication line degrades the signal integrity of that line, and the longer that stub the worse this gets

19:57 <alfatau> sure, but they decided to have these pins connected in order to be able to sw program the cape if needed in the future

20:00 <alfatau> however, I understand what you say, thank you very much

20:00 <zmatt> even having dead-end pcb traces (of sufficient length) attached to these pins would already be sufficient to cause problems

20:00 <zmatt> having said that...

20:00 <zmatt> if they're currently tristated on the FPGA, it's worth trying to make them pull-up instead, effectively weakly terminating the lines... but it will almost certainly not fix the problem

20:01 <zmatt> (or conversely, if they're configured with pull-up or pull-down, make them high-Z instead)

20:01 <zmatt> (they definitely shouldn't have pull-down)

20:02 <zmatt> other than redesigning the cape, you may have no option but to physically cut the pins

20:05 <alfatau> unfortunately it was exactly what I was worried...

20:05 <zmatt> yeah, I'm sorry I don't have better news

20:06 <zmatt> like I mentioned it might be possible to sort of work around this in software by just retrying more on CRC error or command timeout, but I'm not sure where in the kernel source you'd need to patch that, and of course it would just be an ugly workaround

20:08 <alfatau> another confirmation, in order to avoid to waste other time: if I change the dts trying to program the emmc p8-pins as GPIO (in) the device will no longer boot from emmc. Then I should be able to only boot from microsd and I'll need to re-flash the firmware image to restore the boot from emmc capability. correct?

20:09 <zmatt> correct, the kernel wouldn't be able to detect the eMMC

20:10 <zmatt> or well, you don't need to reflash it per se, just boot from sd card then mount the emmc and undo your mistake :)

20:11 <alfatau> ahah, thank you, i forgot that simpler way :)

20:12 <zmatt> those P8 pins are simply connected in parallel to the eMMC to the AM335x pins... https://photos.app.goo.gl/a9JYULdYmwgu3Qk89

20:14 <zmatt> so the AM335x pins need to be configured for communication with the eMMC, and the P8 pins are essentially just snooping on the AM335x <-> eMMC communications

20:16 <zmatt> (this was done for backwards compatibility with the original beaglebone white which had no eMMC... the idea being that you can still use these pins for gpio like you could on the beaglebone white as long as you keep the eMMC disabled)

20:30 <alfatau> thank you for your help

20:40 <zmatt> alfatau: good luck!