**** BEGIN LOGGING AT Thu Mar 11 02:59:57 2021 Mar 11 09:16:09 hello Mar 11 09:16:22 what is the operating temperature of beaglebone al? Mar 11 09:51:38 a bit higher than the air around it Mar 11 09:53:44 no Mar 11 09:53:45 minimum operation temperature -40 C or 0 C  ? Mar 11 09:56:35 hmm, the SoC itself goes down to -40, but dunno if there's other components on it that might have a problem with that Mar 11 09:57:29 ok yeah the ram specifies minimum 0 ͏°C Mar 11 09:58:45 AM5729 there are variants of both -40 and 0 Mar 11 10:02:56 the schematic and bom say AM5729BABCXEAR, but like I said it doesn't matter: the ram specified 0 ͏°C as minimum Mar 11 10:03:16 D2516ECMDXGJD     4Gb     96 ball FBGA DDR3/3L     7.5x13.5x1.2     256Mx16     1866 Mbps     1.35V     0°C ~ +95°C Mar 11 10:04:52 You're right, thank you Mar 11 11:26:09 m Mar 11 11:42:08 Anyone with actual experience on the reliability impact of operating below 0°C ? I guess there's a reason the RAM is specified for operation above that temperature, but it may still work well in practice, with failures being very rare. will probably depend a bit on how good the particular RAM silicon is. Probably some binning going on there Mar 11 13:12:40 sjarken: I mean sure, running out of spec doesn't always mean things will fail Mar 11 13:21:45 at the very least it will probably mess with timings, which may or may not be a problem depending on how much margin there is. running things at lower clock speeds and/or tuning memory timings might help Mar 11 13:23:24 if the board is in an enclosure you could also just use the cpu as space-heater until the ram is warm enough to be reliable ;P Mar 11 13:23:56 (the am5729 can do an *excellent* job at being a space heater) Mar 11 13:24:32 that would obviously have to be done in SPL, before ram is initialized Mar 11 13:25:42 some forum post also points out that low temperature can magnify signal integrity problems, "When cold, the drivers current increase and so do reflections due to impedance mismatches and crosstalk." Mar 11 15:04:59 Hi all, Is there a way to get the silicon revision from the linux cli? Mar 11 15:57:41 probably Mar 11 15:58:27 though only the original beaglebone white had silicon revision 1.0, and I think even those switched to 2.x at some point Mar 11 16:00:38 cat /sys/devices/soc0/revision Mar 11 16:00:40 there ya go Mar 11 16:03:36 I have both white and black beaglebones with the XAM3359 chip Mar 11 16:03:58 that doesn't indicate silicon revision though Mar 11 16:06:04 my old BBB rev A5A has an XAM3359AZCZ100, so that's silicon revision 2.0 Mar 11 16:07:21 mine doesn't have the 100 suffix Mar 11 16:09:04 all BBBs support 1 GHz, even the early prototypes Mar 11 16:10:09 the early ones however lack appropriate indication of this in efuse, which is why the DT contains an explicit override: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am335x-boneblack.dts#L26-L35 Mar 11 16:10:09 I'm just reading what's written on the chip Mar 11 16:10:42 what is its full marking then? Mar 11 16:11:39 the letter between the part number (3359) and package identifier (ZCZ) is the silicon revision: blank = 1.0, A = 2.0, B = 2.1 Mar 11 16:12:16 XAM3359AZCZ Mar 11 16:13:02 yeah, 2.0. I guess they weren't automatically speedbinned yet Mar 11 16:13:37 this one is also mislabeled (or misprogrammed, if you prefer), being actually a 3352 Mar 11 16:13:57 ah that batch, lol yeah that sucks Mar 11 16:38:52 Bah, Covid, I don't recommend it. Mar 11 16:39:00 you got it? Mar 11 16:39:11 yup Mar 11 16:39:27 from a co-worker who walked by in the hallway. Mar 11 16:39:34 no other possibility. Mar 11 16:39:59 rapid test came back negative, but just heard that the pcr done at same time was positive. Mar 11 16:41:06 It spreads real easy now , so stay safe all. Mar 11 16:45:12 waiting to hear back from ti about secureboot options for am3358, hopefully it's good news. Apparently a TPM2 has no way of securing your boot if you can't hash the bootloader itself. Mar 11 16:46:09 secure boot? I hope you want half a million devices a year or that order of magnitude Mar 11 16:49:22 and correct there's no way to establish a root of trust on AM335x GP devices (ditto for most other TI SoCs), not unless you extend the security boundary for the root of trust to encompass the SoC and some external hardware (at minimum an spi boot flash, and probably something like a tpm. a tpm isn't technically needed for secure boot but it can be a useful tool) Mar 11 16:51:30 it wouldn't be hard to support a dynamic root of trust without any end-user keys burned into efuse (like they do with HS devices), just a random device key, a tiny bit of ROM code, and some very simple hardware support in the SoC Mar 11 16:51:38 but unfortunately that's not the way it is Mar 11 16:53:57 depending on what you're trying to secure against whom you may be able to use a tamper-evident enclosure or a big goop of epoxy as a substitute ;P Mar 11 17:20:07 yea, that's what i was concerned about. Was trying to think what would be safer to protect against copying, using a tpm2 or spi flash for boot. Thinking as you said both, is the only reasonable option. put everything on spiflash and it can arbitrarily be read out, put keys in tpm2, and anything decrypted can just be copied after decryption. Mar 11 17:37:10 konsgn: "using a tpm2 or spi flash for boot" .. those perform completely different functions so that question makes no sense Mar 11 17:38:36 a tpm by itself is of no use for getting secure boot, using a tpm requires that you already have a form of secure boot to begin with Mar 11 17:39:21 it also requires that the connection between tpm and cpu is secure against attackers Mar 11 17:39:30 otherwise a tpm is essentially useless Mar 11 17:40:36 (except maybe just as a minor hurdle to ward off some low-skill attacks) Mar 11 17:43:08 I was thinking of it primarily from the measured boot functionality. The uboot would be able to do the hash of code it loads just fine, but with nothing hashing the uboot itself, it's not really usefull. Mar 11 17:43:19 without those conditions the only utility a tpm has is that it can act as a crypto token, i.e. hold on to non-exportable private keys so that if the system is compromised the attacker cannot grab a copy of the private key (he can still *use* the private key but only while he has access to the system) Mar 11 17:43:59 exactly, and if the cpu-tpm connection isn't secure you can tell the tpm whatever it wants to hear Mar 11 17:44:10 regardless of what the system is actually doing Mar 11 17:48:41 hmmm, would it be possible to say have uboot leverage the tpm2 to decrypt an luks filesystem into ram and disable sd card access from there? hmm. thinking on it, the steps between decrypt and run would be vulnerable for tampering. Mar 11 17:50:18 just to clarify, you're trying to protect against an attacker with physical access? Mar 11 17:52:31 as much as possible. Mar 11 17:52:53 i do realize that you can just pop off the uboot flash or tpm2 chip. Mar 11 17:52:55 a tamper-evident enclosure is really the main practical way, or potting the pcb or part thereof (encompassing cpu + tpm + spi boot flash + access to the bootmode pins) Mar 11 17:53:28 any software-only solution will merely be a puzzle, not security Mar 11 17:53:30 on a tamper event then, would you erase keys? Mar 11 17:54:05 whether tamper-evident suffices or tamper-proof is needed depends on the situation Mar 11 17:54:29 if the device remains partially in your control or can be audited then tamper-evident + legal reprecussions may suffice Mar 11 17:54:54 otherwise your best protection is not being interesting enough to be worth the effort ;P Mar 11 17:55:40 haha, that would be nice, a warranty sticker over the screws that reads: nothing of interest in here, move along Mar 11 17:56:14 a mechanism with key erasure is of course possible, but that's probably only appropriate in very limited applications Mar 11 17:59:27 of course even if you can't get real security and are limited to making a puzzle, you could make an interesting puzzle (e.g. an fpga/cpld that monitors a bunch of lines to detect if initial bootloading is being messed with) Mar 11 17:59:54 initial bootloading and/or initial measurement Mar 11 18:00:44 it all depends on how much effort it's really worth Mar 11 18:01:43 it's just a bummer that TI SoCs do not offer even the most basic kind of boot security that you'd find on most small microcontrollers Mar 11 18:02:05 (but I'm not sure the situation is better on other SoCs) Mar 11 18:02:19 haha we do have an fpga with aes encryption on its bitstream, so we have that going for us, which is nice Mar 11 18:03:15 their cc2640 line does have example bootloaders that can verify signed firmware streams. and you can lock out the bootloader sections Mar 11 18:03:50 also, I have written a CBC based bootloader to go on top of the signed firmware, and that worked nicely Mar 11 18:04:18 it is an arm and not a soc though ;( Mar 11 18:04:28 most microcontrollers have integrated flash and support read-protection, which also suffices for secure boot Mar 11 18:05:16 integrated flash definitely makes things easier, but it's also definitely not required for supporting a root of trust Mar 11 18:06:42 yup, but if i understand correctly, root of trust in devices implies the manufacturer has a non-expiring certificate they use to sign clients keys, and non-expiring is a bad idea right? Mar 11 18:07:04 you don't need any kind of public-key cryptography for a root of trust Mar 11 18:07:47 you only need a device-unique random key (generated internally during manufacture and burned into efuse) Mar 11 18:10:14 and some sort of service (provided by bootrom) to perform the initial measurement, preferably *after* early bootloading (i.e. a dynamic root of trust) to avoid having to make all the bootloading code (some of which is in rom) part of your root of trust Mar 11 18:11:53 that service will measure the next code to be executed and derive a key from that and the device-random key, and then executes that code with the derived key as argument Mar 11 18:12:46 that code will then be responsible for bootstrapping the rest of your security architecture, which may or may not involve public-key crypto and/or the use of a TPM Mar 11 18:15:18 alright, I think i get it. thank you for the explination! Mar 11 18:16:03 the initial measured code cannot be updated without effectively wiping the device (since modifying the initial measured code results in a different derived key, hence access to cryptographically protected resources is lost) so the smart thing would be to keep it really simple and e.g. load the next stage based on public-key authentication Mar 11 18:16:22 the derived key (or keys derived from that) can hopefully also be used to protect cpu<->tpm communications Mar 11 18:16:37 avoiding the need to physically secure that connection Mar 11 18:17:33 (but I don't have the tpm protocols sufficiently fresh in my head to know what is or isn't possible) Mar 11 18:24:34 you are talking about how secure boot works and not on the beaglebone right? Mar 11 18:25:17 since there are no documented procedures on how to measure code from the rom in the am3358s Mar 11 18:27:17 I'm talking about how secure boot *could* work on a device without any embedded flash or other non-volatile memory (e.g. efuse) that's user-programmable or gets customer-specific programming Mar 11 18:27:47 (and without any public-key crypto in rom) Mar 11 18:28:38 gotcha Mar 11 18:29:03 Hi,  systemctl suspend calls script before sleep. In the script, there is a sleep 1 in bash. But it seems not finishing sleep and O/S is suspended Mar 11 18:29:43 konsgn: but unfortunately TI _does_ use public-key crypto in rom and customer-specific keys in efuse, which is why you end up with a big minimum order quantity Mar 11 18:30:20 tiger: please share your service file using pastebin.com (or other paste-service) Mar 11 18:30:21 bah, so not something that is possible through octavo then... Mar 11 18:30:41 probably not no Mar 11 18:30:54 you'd need to ask octavo Mar 11 18:59:01 zmatt, I finally created a paste with mnu-sleep.sh and mnu-resume.service Mar 11 18:59:05 https://pastebin.com/VsAtDNqx Mar 11 19:02:35 The issue is: echo 1 > gpio51/value after sleep 1, LED is NOT OFF when in sleep. But if that line is above sleep, LED is OFF in sleep Mar 11 19:04:21 your service file is nonsense, you mixed two examples into something that does not do what you want Mar 11 19:04:47 https://pastebin.com/gET0ZFUS Mar 11 19:05:54 you need Before=sleep.target, not After, and you're missing RemainAfterExit=yes in [Service] and StopWhenUnneeded=yes in [Unit] Mar 11 19:11:51 after made change, sudo systemctl daemon-reload is enough to update the service? Mar 11 19:12:07 should be, yes Mar 11 19:12:17 reenable is only needed if you change the [Install] section Mar 11 19:14:16 I think it is working. At least LED is off in sleep, now. Thank you. Mar 11 19:23:19 @zmatt Only thing is ExecStop=/home/debian/mnu/mnu-resume.sh is called before sleep. And that is supposed to be called after wakeup. Mar 11 19:25:14 can you pastebin your service file again just to be sure? Mar 11 19:25:27 when I tested it the ExecStop got called after resume Mar 11 19:26:12 https://pastebin.com/MByQycVF Mar 11 19:27:45 the problem is you not paying attention to the example nor to what I said :P directives won't work if you put them in the wrong section Mar 11 19:28:52 sorry,  placed in wrong section Mar 11 19:29:22 also, like I said before, /dev/shm/ is an inappropriate place to put files Mar 11 19:29:37 use /run/mnu/ or something Mar 11 19:29:54 (for non-persistent state) Mar 11 19:30:55 Ok. I will correct them. Thank you. Mar 11 19:36:35 @zmatt, yesterday we talked about the startup problem of our beaglebone black wireless. after some meassurement with the oscilocope we found out that the beaglebone black and the beaglebone black wireless are somekind different. the 5V_sys on the beaglebone black wireless someteimes (when you remove the power supply and connect it to quickly) will take a long time till the power goes down to zero. Mar 11 19:37:07 architux: yeah like I said, it seems to have more capacitance on it Mar 11 19:37:13 yes Mar 11 19:37:15 due to the wifi supplies Mar 11 19:37:19 yes Mar 11 19:37:54 so a quick solution was to use an resisotr from 5_sys to gnd Mar 11 19:38:11 but we still have no final solution Mar 11 19:38:47 have you been able to capture the fault condition yet? since high capacitance on sys_5v doesn't immediately explain your problems Mar 11 19:38:58 unless your power supply can't deal with the inrush current maybe Mar 11 19:39:16 but then I don't see how discharging sys_5v is of any use Mar 11 19:39:36 well, i am the software guy Mar 11 19:39:50 i talk to the hardware guys Mar 11 19:40:15 if you're the software guy, why are you the one trying to get help with this issue here in this channel? :P Mar 11 19:40:16 and i hope that we both trust each other Mar 11 19:40:25 cause Mar 11 19:40:46 i know what IRC is Mar 11 19:40:52 he is younger Mar 11 19:41:27 no, we work together perfektly Mar 11 19:43:53 the thing is, if I ask a question regarding this hardware-related and get "well, i am the software guy" as reply, that strongly suggests this is not a very efficient use of time (your, and more importantly mine) Mar 11 19:44:01 *this hardware-related issue Mar 11 19:45:07 @zmatt, you are right Mar 11 19:45:34 sys_5v slowly going down is normally not a problem in itself Mar 11 19:45:58 since nothing of importance is powered directly by sys_5v, everything uses 3.3v supplies or lower Mar 11 19:48:17 jkridner: do you think you could maybe reexport the BeagleBone Black Wireless schematic so that its text is actually text (like it is in the BeagleBone Blue schematic) instead of a million tiny line segments? Mar 11 19:49:13 bbl Mar 11 19:50:13 jkridner: I don't open the BBBW schematic frequently, but every time I do I'm reminded of how annoying it is... very slow to load and render, and the affected text (which is not all of it, but a lot of it) can't be selected or searched Mar 11 21:11:11 What is SoftAp0 192.168.8.1 network interface on BBBw ? Is this the AccessPoint for BBBw? Mar 11 21:12:17 yes, there's a config file to disable it if you don't want it Mar 11 21:12:49 in /etc/default/bb-wl18xx Mar 11 21:14:15 Is it ready for iPhone to connect to it? Mar 11 21:16:05 So, BBBw WIFI can be both ways:  1. Connect to an AccessPoint and 2. at the same time, it can be acted as access Point, itself? Mar 11 21:16:49 yes, though I think there may be restrictions or performance implications on using both functions at the same time... usually there's no point in using the access point once the bbbw is connected to a wifi network Mar 12 02:45:28 NoNick: Mar 12 02:45:30 yo **** ENDING LOGGING AT Fri Mar 12 03:00:01 2021