**** BEGIN LOGGING AT Sun Feb 24 02:59:56 2019 Feb 24 16:25:36 this should be used on the next beaglebone: https://www.st.com/resource/en/data_brief/stm32mp157a-dk1.pdf Feb 24 16:26:30 a dual-core A7 with an embedded M4 mcu Feb 24 16:31:56 why wait ? Make the first labrador-bone Feb 24 16:32:52 I'm not good enough Feb 24 16:33:00 I can make the software, not much the hardware Feb 24 16:33:25 well I can, with a lot of money Feb 24 16:33:35 but if I had to get it right on the first try it's a lost hope Feb 24 16:33:43 m4 sounds like a power-saving mode though. I like the PRU (fast, deterministic) better. don't know if an M4 would match up. Feb 24 16:34:03 what do you mean by power-saving mode ? Feb 24 16:34:28 like it's low-power ? Feb 24 16:34:39 a mode where the a7s are put to sleep and the m4 deals with maintenance things like reading a touch screen Feb 24 16:34:55 ah Feb 24 16:34:58 where do you see that ? Feb 24 16:35:27 i think a few arm devices do it. don't know the details. maybe some of Apple's ? Feb 24 16:38:08 ah, like in x86 also Feb 24 16:38:14 yeah I think it's a real co-processor here Feb 24 16:38:25 it's a stm32f4 mcu like any other Feb 24 16:45:06 you talk to it with remoteproc and all Feb 24 16:47:12 it's around 200MHz Feb 24 16:58:05 sure, it's a separate processor, and I guess at 200MHz might compare with a PRU. But has more complicated instruction and memory addressing etc. which makes it less predictable so you can't do things as precisely as the super-simple PRUs Feb 24 16:59:55 back in the day, there were some motorola devices with a TPU (time processing unit) which was a very fancy timer module where you could have chains of activations and reloadable registers. was mainly aimed at injector timing for engines Feb 24 17:13:20 note that the beaglebone actually also has a cortex-m3 (used for power-management tasks and low-power modes) Feb 24 17:13:38 s/beaglebone/am335x Feb 24 17:20:18 i didn't know that, ta Feb 24 19:11:27 mawk: I mean, at first glance it looks like an okay SoC, but (ignoring for a moment that beagleboard.org is specifically all about TI SoCs), I don't see any clear advantage of it over the am335x Feb 24 19:13:51 mostly minor pros and cons that leave no clear winner Feb 24 19:14:23 (e.g. the cortex-m4f is absolutely no substitute for PRUSS, but the converse is true as well) Feb 24 19:24:56 also, I don't think ST has much experience with Cortex-A SoCs, and this stm32mp15x, so I'd be inclined to wait a bit and see what errata are discovered :) Feb 24 19:25:08 *this stm32mp15x series is newly released Feb 24 19:44:24 Hi all, I have been working on developing a Makecode target for Beaglebone boards and could get a basic version ready at : https://vaishnav98.github.io/pxt-beaglebone/ ( the project is at a very initial stage and requires a lot of improvements/bug-fixes) It would be great if you could help test the project and provide some feedback. Feb 24 19:44:25 artag: M-cores are quite common on cortex-A SoCs as licensing says they are 'free' with the A core. Often used for housekeeping and such. Feb 24 19:45:07 artag: I don't remember exactly, but I think we counted 6 or 8 ARM cores on the OMAP4 SoC that were *documented* Feb 24 19:45:44 I have also made an introduction/testing video for the simulator/editor at : https://youtu.be/niSkdlEI5UE Feb 24 19:46:55 making those M-cores available for general purpose started showing up after the PRUs. I think the iMX was the first one with M4 cores for "microcontroller/real-timey-stuff" Feb 24 19:48:43 omap4 ? lemme think... two cortex-m3 (Ducati), two arm9 in IVA-HD ... ehm ... Feb 24 19:49:34 I actually don't think it has a low-power/housekeeping arm core? Feb 24 19:50:04 in fact the am335x is the first TI SoC where I've seen that Feb 24 21:00:45 omap4 had the classic, broken prcm thing Feb 24 21:15:28 "broken" ? I know it had bugs due to its complexity (the result of trying to have it hardware-managed to a very high degree), didn't know it was bad enough to be called "broken" Feb 24 21:24:10 yeah it's one of their first steps into cortex As zmatt Feb 24 21:25:31 but ST is half-french so I must like them Feb 24 21:25:48 I tried to get into it but they have no offices in dutchlandia Feb 24 21:28:43 they previously had a cortex-a9 device, SPEAr13xx Feb 24 21:29:04 but it quickly ended up NRND and has disappeared Feb 24 21:30:46 I've had some experience with certain smaller stm32 devices... was not really a fan, it had very annoying limitations due to errata and limited pinmux Feb 24 21:32:22 and the st-link/v2 debugger sucks, I ended up using TI's xds100v2 instead for debugging my stm target :P Feb 24 21:35:42 why did it suck ? Feb 24 21:36:01 people say the ST HAL is badly written but apart from being badly documented I didn't find anything bad Feb 24 21:36:17 I was a total novice, and only from the reference manual and the cube mx software I was able to use timers, DMA, USB, and so on Feb 24 21:36:24 it's pretty well made Feb 24 21:38:22 why the stlink sucks? electrically it is very annoying. the debugger hardware does not tolerate being connected to a live target while the debugger is unplugged (so you can't pull it out of your usb port while leaving jtag connected), and hotplugging the jtag connection to a live target tended to glitch the reset line for some reason Feb 24 21:38:50 the xds100v2 handles these situations flawlesslyl Feb 24 21:39:14 maybe you can connect the nrst line and force it down when you start debug Feb 24 21:39:32 as a workaround Feb 24 21:40:18 ??? I'm not sure you read what i said correctly, because your suggestion makes no sense in reply to it Feb 24 21:41:07 the problem was that it was causing spurious resets when none was desired Feb 24 21:41:11 ah Feb 24 21:41:14 right Feb 24 21:41:27 so you were using JTAG, not SWD Feb 24 21:41:33 and I had a great workaround, I used a debugger that doesn't suck :D Feb 24 21:41:37 lol Feb 24 21:41:43 yes, jtag Feb 24 21:41:43 yeah Feb 24 21:41:55 at least it's cheaper than segger stuff Feb 24 21:41:59 but still 15× the price of stlink Feb 24 21:44:27 I'm invited to a ST workshop somewhere in france, can't remember where Feb 24 21:44:36 they'll give me for free their new wireless board Feb 24 21:44:53 with bluetooth/802.15.4 Feb 24 21:45:11 but I have to stand other people for 11 hours Feb 24 21:46:16 15x? xds100v2 was iirc less than $100 (it seems it's discontinued now so hard to check), st-link/v2 is listed as $21 now but I think it used to be more expensive Feb 24 21:46:27 yeah I found it for $25 on ali Feb 24 21:46:32 and stlink for $1.25 Feb 24 21:46:42 both as counterfeits Feb 24 21:46:49 but they should work as good as the original Feb 24 21:48:08 when you need a device this cheap for professional use, you're not going to take the risk of buying some chinese knock-off Feb 24 21:49:05 also I think we had our xds100v2 for free with an eval board Feb 24 21:49:38 or at least one of them. we have at least two Feb 24 21:52:38 yeah I wouldn't trust the chinese copy for fusing the flash protection bytes or something Feb 24 21:52:59 I think I had an invitation to that ST workshop. But it sounded similar to the nordic nrf52832, ans a friend who'd been to it last year said it was all vaporware and errata Feb 24 21:53:29 maybe better now, but the 52832 is pretty stable Feb 24 21:53:34 but it's a new product Feb 24 21:53:34 no ? Feb 24 21:53:40 I have some nordic nrf too Feb 24 21:53:47 but I find the docs more lacking than from the ST side Feb 24 21:54:05 well, not if it was around last year. maybe it's a newly_working_ product Feb 24 21:54:54 they say it's a workshop for the product pre-launch Feb 24 21:56:22 https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/stm32-nucleo-expansion-boards/p-nucleo-wb55.html?icmp=tt10667_gl_lnkon_feb2019 Feb 24 21:56:24 this thing Feb 24 21:58:17 yeah, that's the same one I saw. But I don't know for sure that my friend was correct in thinking it's what he went to before Feb 24 21:58:24 I wonder if secure boot on the stm32mp will be freely usable, or obnoxiously restricted like with TI Feb 24 21:58:48 they say it's an open firmware that's managing it zmatt Feb 24 21:58:51 I just commented to him that it sounded like the nrf53 and he came up with the warnings about vaporware Feb 24 21:58:51 flashed to the arm trustzone Feb 24 21:58:57 so open means it could be changed I hope Feb 24 21:59:24 mawk: uhh, there's nothing to be flashed, and trustzone doesn't really have anything to do with secure boot Feb 24 21:59:32 ah Feb 24 21:59:40 I thought they'd be related as security features Feb 24 22:00:13 personally I'm a sucker for free lunches and dev boards so I often go, but had too much on at that time Feb 24 22:00:23 not really. I am wondering about trustzone too, or the boot process in general Feb 24 22:01:38 haven't found any docs on the stm32mp15x boot process yet Feb 24 22:01:39 https://wiki.st.com/stm32mpu/index.php/OP-TEE_overview Feb 24 22:01:52 they run this in the trustzone Feb 24 22:01:54 oh right they have a wiki, haven't looked there yet Feb 24 22:02:47 and the secure boot thingie is described here: https://wiki.st.com/stm32mpu/index.php/STM32MP15_secure_boot Feb 24 22:02:49 looks like there's useful info there Feb 24 22:02:51 it seems available to burn from users Feb 24 22:03:46 I was wondering mainly because they currently don't list any option to buy the stm32mp157c or its discovery/eval boards, only the stm32mp157a Feb 24 22:04:26 weird that this info is on a wiki and not in the reference manual Feb 24 22:04:55 yeah Feb 24 22:06:18 however, the fact that this info is public is encouraging Feb 24 22:06:40 the other stm32mp15x models aren't available yet either, so maybe it's just too early Feb 24 22:07:52 also why the bleep do their flow-charts flow from bottom to top instead of top to bottom Feb 24 22:08:01 lol Feb 24 22:08:10 low level to high level I guess Feb 24 22:08:25 no Feb 24 22:08:29 I mean Feb 24 22:08:40 I guess in some cases Feb 24 22:09:07 but I don't feel that argument applies to https://wiki.st.com/stm32mpu/nsfr_img_auth.php/1/17/ROMCodeOverview.png Feb 24 22:13:27 also unfortunate they still implement secure boot by doing public-key authentication in ROM, thus putting an unnecessary amount of complexity in a place where security is critical and bugs can't be fixed, and rendering devices unusuable if you don't have the private key (and at the same time render them unrecoverable from a security point of view if that key is compromised) Feb 24 22:13:55 how would you implement it apart from public-key crypto ? Feb 24 22:14:10 even though you really don't need much at all to bootstrap a dynamic root of trust (to borrow TCG terminology) Feb 24 22:17:26 basically all you need is to have a mechanism that loads code into an isolated environment (e.g. secure world) and provides it with a key that's unique for that device and piece of code (e.g. the HMAC-SHA256 of the code keyed under a secret per-device key) Feb 24 22:17:58 with a hardware SHA256 implementation available (which these devices do) that requires almost no rom code whatsoever Feb 24 22:18:21 and very little additional hardware support Feb 24 22:19:45 the code that's loaded (which will generally just be a bootstrapping stage) can then use that key to derive other keys or decrypt/authenticate other information Feb 24 22:20:22 and if you want to use public-key authentication, you can implement that (using any algorithm you wish) in that stage Feb 24 22:22:44 this doesn't lock the device to anything, in fact this secure bootstrapping can be (and typically would be) after initial non-secure boot stages, but if you don't load that specific piece of code (which enforces the security scheme you want) you won't be able to do anything with encrypted information on the device Feb 24 22:23:20 (which could be the entire rest of the firmware) Feb 24 22:24:01 so you'd erase everything if you lose the key ? Feb 24 22:26:33 the only key I've mentioned so far can't be lost since it's part of the device (random key efused during production, accessible only to the secure bootstrapping loader) Feb 24 22:27:08 anything after that depends on the logic/policy in the first stage code loaded by that Feb 24 22:27:46 but the code after that will eventually need some kind of shared key to authenticate new code updates Feb 24 22:28:49 probably yes, but the logic for that wouldn't be baked into ROM but would depend on that first stage Feb 24 22:29:15 yeah Feb 24 22:29:47 e.g. it could authenticate an image using a public-key and pass it the symmetric key used for user data if and only if it passes public-key authentication Feb 24 22:29:55 it could also implement more complicated schemes Feb 24 22:30:14 different users could use different trade-offs between security and recoverability Feb 24 22:32:30 I see Feb 24 22:32:40 is that scheme implemented somewhere ? Feb 24 22:33:33 TCG uses it.. kinda, except messier and more complicated Feb 24 22:35:29 you should be able to find stuff if you google "dynamic root of trust" Feb 24 22:36:27 indeed Feb 24 22:36:38 Hi Feb 24 22:36:56 actually I suppose the older static root of trust also meets my description, kind of, except performed once at boot instead of at a later time Feb 24 22:37:07 which sucks because it means all your bootloading code will fall under it Feb 24 22:37:26 which is really really not what you want Feb 24 22:37:45 I got a question about beagle bone blue Feb 24 22:38:26 where can I find cooling cases for beagle bone blue? Feb 25 02:35:06 what's a cooling case? Feb 25 02:41:00 I presume some sort of enclosure with an active cooling solution? Feb 25 02:41:21 didn't realize the blue got warm, but I guess it makes sense if you've got motor drivers and such going on Feb 25 02:43:32 Having trouble with flashing On my first BeagleboneBlack. I've got a SD card for the Debian 9.5 2018-10-07 4GB SD IoT and another for the Debian 9.5 2018-10-07 4GB SD LXQT . I've modified the uEnv.txt file to un-comment out the flashing command at the end of the file. The LXTQ version will flash but the IoT version will not. /HELP Feb 25 02:49:25 The reason I'm trying to get the IoT version running is because when installing python 3.6 I ran out of space. Is Python 3.6 so big that it won't fit? Feb 25 02:51:11 Fit in the LXQT version, that is. Feb 25 02:57:43 do you have a serial to usb adapter dpe ? Feb 25 02:57:48 so you can waztch what's happening at boot **** ENDING LOGGING AT Mon Feb 25 02:59:57 2019