**** BEGIN LOGGING AT Sat Oct 22 02:59:57 2022 Oct 22 20:33:30 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 Oct 22 20:33:31 emmc. Should/Can I program these pins in a different way (e.g. GPIO) keeping the device bootable from emmc? Thank you in advance Oct 22 20:35:51 no, they need to be configured like that to be able to use emmc Oct 22 20:37:08 and the cape should not connect anything to those pins Oct 22 20:39:10 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 Oct 22 20:40:00 you could try physically cutting those pins (P8.03-06 and P8.20-25) on the cape's connector Oct 22 20:43:34 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 Oct 22 20:43:34 off function enabled by a GPIO pin on the expansion header." Oct 22 20:43:35 In your opinion can I "protect" the emmc in some (software) way? Oct 22 20:44:46 zmatt: in fact I tried to phisically cut the p8 pins and the corruption problem disappears Oct 22 20:46:54 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) Oct 22 20:48:18 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? Oct 22 20:50:15 alfatau: and no, there's nothing you can do about this in software Oct 22 20:52:19 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 Oct 22 20:52:33 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. Oct 22 20:52:57 alfatau: merely connecting them to an FPGA or anything else is the problem Oct 22 20:56:15 @@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... Oct 22 20:56:49 alfatau: the cape developers should have left these P8 pins not-connected Oct 22 20:57:39 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 Oct 22 20:57:49 sure, but they decided to have these pins connected in order to be able to sw program the cape if needed in the future Oct 22 21:00:02 however, I understand what you say, thank you very much Oct 22 21:00:03 even having dead-end pcb traces (of sufficient length) attached to these pins would already be sufficient to cause problems Oct 22 21:00:07 having said that... Oct 22 21:00:57 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 Oct 22 21:01:46 (or conversely, if they're configured with pull-up or pull-down, make them high-Z instead) Oct 22 21:01:56 (they definitely shouldn't have pull-down) Oct 22 21:02:35 other than redesigning the cape, you may have no option but to physically cut the pins Oct 22 21:05:06 unfortunately it was exactly what I was worried... Oct 22 21:05:20 yeah, I'm sorry I don't have better news Oct 22 21:06:41 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 Oct 22 21:08:48 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? Oct 22 21:09:30 correct, the kernel wouldn't be able to detect the eMMC Oct 22 21:10:00 or well, you don't need to reflash it per se, just boot from sd card then mount the emmc and undo your mistake :) Oct 22 21:11:09 ahah, thank you, i forgot that simpler way :) Oct 22 21:12:33 those P8 pins are simply connected in parallel to the eMMC to the AM335x pins... https://photos.app.goo.gl/a9JYULdYmwgu3Qk89 Oct 22 21:14:19 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 Oct 22 21:16:35 (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) Oct 22 21:30:17 thank you for your help Oct 22 21:40:35 alfatau: good luck! **** ENDING LOGGING AT Sun Oct 23 02:59:56 2022