**** BEGIN LOGGING AT Mon Nov 30 03:00:50 2015 Nov 30 03:06:29 are the bbb gpio's supposed to spike briefly right after energizing the board? Nov 30 03:09:25 I tested with two revA5C boards and it occurs even before u-boot outputs any text, so I doubt this is caused by software Nov 30 03:11:24 @Set_ I did go to the wiki through beagleboard.org and the imagine site. Nov 30 03:13:16 But I did just find more information on the debian part of the wiki. I'll play with that and report back. Thanks Nov 30 03:14:13 No issue. Thank you for replying. Nov 30 03:17:05 Guest971: They have new images and there is a specific way to boot the board off SD card to make it run. You have to inset the SD card, turn the power on, add Ethernet, and let the board shutdown by itself to finalize the process. Nov 30 03:18:13 Ok, good to know Nov 30 03:18:36 Ya man...I will be here for a bit if you need additional support. Nov 30 03:19:33 I had all sorts of configuration issues at first. Nov 30 09:48:19 im looking at a inespensive camera to make it easier to drive backwards in a car. that thing saves data to a sd card, probably some microsoft media format. (the producer has not yet answered) is there a chance that a beagle board can read a ms format and reproduce it to a lcd with some resolution or is media conversion out of the question? Nov 30 09:49:38 i dont think you will find a cam that records windows formats Nov 30 09:50:11 most likely you will have h264 in avi Nov 30 09:50:24 you can probably play it back, yes Nov 30 09:50:36 or mp4 Nov 30 09:50:46 ok, i was just guessing at the format. avi would of course be nice Nov 30 09:51:25 i have a bunch of cams here. those that can record do mp4 or avi Nov 30 09:51:34 if the camera got a lower resolution than the display, can i assume that it will work with black borders? Nov 30 09:51:56 ah yes, youre name sounds like you got some experience there Nov 30 09:52:10 or it would be scaled Nov 30 09:52:18 depends on the player software, really Nov 30 09:52:45 ah yes, of course Nov 30 09:53:34 uavcamm, any cameras you would recommend? Nov 30 09:53:44 what do you want to pay? Nov 30 09:54:25 i just need a little view of my behind, dont even need color Nov 30 09:54:25 so, inexpensive. would be nice Nov 30 09:54:52 so connect via usb to the beagle? Nov 30 09:55:11 anything that works really, currently that would be the only application for the board Nov 30 09:56:42 have look at leopard Nov 30 09:57:38 https://www.leopardimaging.com/ Nov 30 09:58:02 yes got it Nov 30 09:58:09 just to get an overview what is out there Nov 30 09:58:18 the low end vga camera is like 79$ Nov 30 09:58:27 mine is from navgear, and is 29€ Nov 30 09:58:33 where are you located? Nov 30 09:58:36 germany Nov 30 10:01:42 see the private chat? Nov 30 10:01:54 oh sry, to many open windows...yes Nov 30 11:46:44 would it be possible to attach something like this:http://www.ebay.de/itm/7-TFT-LCD-Display-Module-RGB-HDMI-VGA-2AV-Driver-Board-for-Raspberry-Pi-12V-CAR-/281561991510?hash=item418e670956:g:z0kAAOSw1ZBUtT3x to the beagle hdmi port? Nov 30 12:04:35 according to this: http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI the beagle board does not support the resolution 1024x600. is that true? Nov 30 12:44:25 julius: it has a pixel clock limit, but if the mode is below that limit then it should work Nov 30 12:44:50 possibly... I guess it also depends on the HDMI encoder used on bbb. Nov 30 12:45:17 any idea where i could ask that question besides here? Nov 30 12:45:24 the official 7" lcds are really expensive Nov 30 12:47:01 julius: umm so are you interested in the HDMI or an LCD? Nov 30 12:47:20 the page you linked is for HDMI Nov 30 12:47:48 im interrested in a cheap 7" display Nov 30 12:48:01 that works with the beagle black Nov 30 12:48:15 touch Nov 30 12:48:32 ok. well that page won't help you with an lcd Nov 30 12:49:01 bbb supports 1024x600. but there are other aspects in whether the an lcd works or not. Nov 30 12:49:08 do you mean DVI instead of HDMI? Nov 30 12:49:27 ok, anything i can check? Nov 30 12:49:47 umm ok, so you are talking about HDMI, then? a 7" HDMI monitor? Nov 30 12:50:14 it will go into my car, thats why the 7" Nov 30 12:50:21 i dont care if its connected via hdmi or dvi Nov 30 12:50:41 there's no DVI, just hdmi and parallel RGB. Nov 30 12:51:06 ah ok, my fault...maybe i saw that on a raspberrian Nov 30 12:51:53 of course, HDMI is more or less DVI + audio... Nov 30 12:53:04 note that the ebay link you posted earlier was not a touch screen Nov 30 12:53:51 Can't touch that ! Nov 30 12:53:58 :) Nov 30 12:54:01 youre right Nov 30 13:11:32 what about this one: http://www.amazon.de/Touch-Screen-Monitor-Raspberry-Driver/dp/B00GZCUNQ8/ref=pd_sim_sbs_147_6?ie=UTF8&dpID=5128fatGXnL&dpSrc=sims&preST=_AC_UL160_SR160%2C160_&refRID=0XTN338MK1KNPS3EQP5D Nov 30 13:11:59 it can do 800x480, which is not listed in the beagle wiki either Nov 30 13:17:05 sounds like that would work Nov 30 13:20:26 lcdc can produce any resolution up to 2048x2048 provided the number of pixels per line is a multiple of 16 Nov 30 13:21:12 ok Nov 30 13:21:53 so why are there only a few resolutions listed on http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI ? Nov 30 13:23:09 most likely because due to a driver bug, about 50% of all possible pixel clock rates led to misconfiguration of the LCDC pixel clock divider, which is fixed in the -ti kernels Nov 30 13:23:38 also, HDMI means the HDMI framer is involved which will have its own restrictions Nov 30 13:23:47 those I do not know Nov 30 13:23:50 ah ok Nov 30 13:24:15 lets see what the retailer support says, maybe they know. otherwise i will just test it Nov 30 13:24:24 isn't it so, that hdmi only standardizes a few resolutions, while dvi and in general many more will just work Nov 30 13:25:35 the displays i found also got a vga connector, so they probalby are very useable with anything that does vga Nov 30 13:26:37 which the bbb doesn't Nov 30 13:26:41 yes Nov 30 13:27:48 best viewed with a monospaced font that has good support for box drawing chars -> http://gerbil.xs4all.nl/lcdc-raster-timing.txt Nov 30 13:27:50 there are adapters for hdmi -> vga+audio. that could work Nov 30 13:28:12 that's insane though, inserting analog video into the chain Nov 30 13:28:24 when both source and destination are digital Nov 30 13:28:45 and both the processor's lcdc and the hdmi framer are highly flexible Nov 30 13:29:08 true Nov 30 13:29:56 may i ask why you guys use beagle instead of raspberrian? is that question allowed? im still new to this, dont own any of them Nov 30 13:30:19 instead of rpi you mean? Nov 30 13:30:35 yes Nov 30 13:31:04 well, the rpi2 that is, since the rpi has an arm11 (armv6) processor so I'm not even going to take that one seriously Nov 30 13:32:22 I/O mostly. the BCM2835 (rpi) / 2836 (rpi2) processor is basically just a GPU with an arm core stuck on the side Nov 30 13:32:31 they fixed the light issue on the pi? Nov 30 13:32:51 while the BBB has powerful I/O capabilities Nov 30 13:33:19 and *real* ethernet (the bcm uses an usb-to-ethernet chip on the board since the processor has no ethernet support) Nov 30 13:33:29 and of course the awesome PRU Nov 30 13:35:01 graphics on the BBB are somewhat its weak point, especially since the GPU is often not usable (though if you do get it running it's not bad; but for example there's no support for it under X11) Nov 30 13:35:55 the processor on the BBB also has _much_ better documentation Nov 30 13:36:04 there's basically zero public docs from broadcom Nov 30 13:36:59 for the bcm2835/2836 there are two pdfs that summarize some info from the datasheet, and a community-maintained wiki of errata Nov 30 13:38:25 for the BBB you can just go to http://www.ti.com/product/am3358 and download the processor datasheet, errata, and technical reference manual right away, you don't even need to register on the site Nov 30 13:39:06 that makes a big difference if you want to do anything that isn't a prefab application Nov 30 13:45:04 Don't forget the crypto acceleration which actually has Linux drivers Nov 30 13:45:50 Omap RNG support (modprobe omap-rng), and while you need to install rngd (rng-tools) to feed your system random with the hardware random, it works. Nov 30 13:45:59 And makes some operations A _lot_ faster. Nov 30 13:46:14 so my summary would be: if you just want a small cheap ARM-based computer with decent graphics, an rpi2 should be fine. if you care less about the graphics but want to hook up a motor controller or some crazy shit, use a BBB Nov 30 13:46:56 Spidler_: the crypto drivers are very incomplete however, and when people did benchmarks they found that the overhead of using the driver often negated the performance benefit Nov 30 13:47:45 For the crypto? Yeah. Random is a different thing Nov 30 13:47:48 otoh I accessed the AES accelerator myself from userspace using uio and it could process data faster than I could get it in/out from the cortex-a Nov 30 13:47:51 a8 Nov 30 13:47:58 I'm regularly running out of entropy Nov 30 13:48:20 zmatt, yes ive read about the open nature of bbb Nov 30 13:48:21 that makes no sense, if you have 128 bits of seed entropy that's fine for all purposes Nov 30 13:49:04 zmatt: I boot from R/O disks. At the point where I want to start, all the boards have the same seed entropy. Nov 30 13:49:21 Before network is up and they can set time properly. "Not a happy place" Nov 30 13:49:54 Spidler_: you can't give them slightly different images, with a different seed key? Nov 30 13:50:03 And even after that there's a lot of TLS sessions going on that chew through. Nov 30 13:50:18 Nope, not initially. After a while they'll have it, but initial state is blank Nov 30 13:50:31 you can't include a seed key in the RO image? Nov 30 13:50:45 and combine that with the factory-unique MAC address Nov 30 13:51:13 Not really good enough to generate a private key with. Nov 30 13:51:20 zmatt, but theres support for debian and gnome on the bbb, so they must have gotten xorg or something to run Nov 30 13:51:30 julius: xorg runs fine Nov 30 13:51:40 but without 3d graphics acceleration Nov 30 13:51:53 dont need that Nov 30 13:52:23 or well, any kind of graphics acceleration at all... the framebuffer is just a piece of RAM Nov 30 13:53:00 Spidler_: as long as the seed key remains secret it is, but yeah if you don't want to rely on that you're very happy to have a hw rng Nov 30 13:53:29 zmatt: Mmm. Also, setting up/rekeying on a lot of TLS sessions eats a fair bit of entropy. Nov 30 13:53:35 no Nov 30 13:53:51 i want to use it as a car pc, for a usb camera that shows whats behind me, and mp3 music Nov 30 13:53:54 once the RNG is seeded with > 128 bits of entropy, as long as your system isn't compromised that's fine Nov 30 13:54:40 it means it would take 2^128 to crack all keys at once instead of 2^128 effort per key, but both are impossible so that's an irrelevant issue Nov 30 13:54:58 a real attacker will just exploit some software vulnerability Nov 30 13:54:58 zmatt: Eh, no? urandom won't be blocking as it's cycling with the reseed, but openssl is still effing stupid and uses it's own rng implementation, polling directly off /dev/random Nov 30 13:55:31 Spidler_: so fix that Nov 30 13:55:43 CBA. Migrating to NSS where I can. Nov 30 13:55:56 Sadly, NSS is retarded in different ways. Nov 30 13:56:05 replace /dev/random by a hardlink to /dev/urandom Nov 30 13:56:06 "Oh, this is a filename, except if you use NSS then it's a handle" Nov 30 13:56:07 problem solved Nov 30 13:56:20 Nah, that's "problem hacked around" :P Nov 30 13:56:23 no, solved Nov 30 13:56:39 /dev/random has no legitimate reason to exist if you have a HW RNG Nov 30 13:57:16 julius: in other words, just a small PC Nov 30 13:57:17 unless you use a rng feeder, _having_ a hwrng isn't enough either. Nov 30 13:57:44 julius: an rpi might actually be a better choice but dunno, haven't actually used one yet Nov 30 13:57:56 Unless policy hs changed, simply loading the hwrng suppport wasn't enough to make it feed into the system entropy pool. Nov 30 13:58:18 Spidler_: I haven't looked at it either, maybe some stuff needs to be fixed in the kernel Nov 30 13:58:37 but really, once the initial entropy is available, /dev/random ought to behave like /dev/urandom Nov 30 13:58:54 and with a hwrng initial entropy can be available in the blink of an eye Nov 30 13:59:04 Sadly, not. For backwards compat reasons, they didn't change behaviour of /dev/random Nov 30 13:59:16 Personally I think /dev/random should go the way of the dodo. Nov 30 13:59:25 then they're moron, replace /dev/random with a hardlink to /dev/urandom Nov 30 13:59:52 or recompile anything that uses /dev/random to use /dev/urandom instead Nov 30 14:00:59 but the link is easier, you can probably make an udev rule that assigns a different name to /dev/random and adds 'random' as an alias to /dev/urandom Nov 30 14:01:25 the kernel side also needs some inspection though Nov 30 14:02:21 since the rng needs to be setup with proper parameters to actually yield true random data, and I don't trust the values in the kernel driver have been selected properly Nov 30 14:03:08 can be worked around by not assuming the bits are perfectly random but just grabbing a large block of data from the hwrng for initial seeding of the entropy pool Nov 30 14:03:19 Also sounds probably true Nov 30 14:03:27 Hello everybody! Can I plug a 7.2v 4600mAh NiMH battery into the beagles battery pins? Nov 30 14:03:41 I don't think the kernel even supports "replace" mode for rng pool, used to only support "mixin" mode, which is just that Nov 30 14:03:51 Spidler_: https://e2e.ti.com/support/arm/sitara_arm/f/791/t/355064#pi316653=2 Nov 30 14:03:56 you should always mix in anyway Nov 30 14:04:50 zmatt, thx for the info Nov 30 14:05:03 for managing the entropy pool the state of the art used to be Schneier's "Fortuna", until this paper: http://eprint.iacr.org/2014/167 Nov 30 14:05:42 theres also a rpi zero for 15€ at my usual retailer, so its a lot cheaper than a bbb Nov 30 14:05:51 (managing the entropy pool includes the bootstrap problem) Nov 30 14:05:57 Hmmm. Yea. Nov 30 14:06:49 julius: keep in mind that (unlike the rpi2) the rpi/rpiz use an arm11 processor, which really sucks Nov 30 14:07:01 it means you can't run armv7 executables Nov 30 14:07:11 so the rpi people had to recompile _everything_ Nov 30 14:07:20 armv6 only. It's a good cpu for what it is, but it's not a modern platform Nov 30 14:07:30 ( not that Armv7 is modern in that sense either ) Nov 30 14:07:42 armv7 is a fine architecture Nov 30 14:07:53 yeah, the price has to come from somwhere Nov 30 14:08:32 the armv6 variant of the arm11 is okayish, but it's almost never supported... if you look at distros you often find it's either armv5 without FPU support, or armv7 with FPU support, and nothing inbetween Nov 30 14:09:15 zmatt, remind me .. why was it you have to use the sys/ direction file instead of 'value' .. Nov 30 14:09:37 I checked the kernel docs this morning .. they seem not to reflect reality .. as usual .. Nov 30 14:09:57 stt_michael: to switch an IO from input to output-high Nov 30 14:09:59 Also don't forget that since the Raspian folks choose to re-use the "armhf" tag, people get loooovely and confusing incompabilities when they mix Debian and Raspbian packages Nov 30 14:10:08 Spidler_: ah yes Nov 30 14:10:22 zmatt, *just* to switch mode .. Nov 30 14:10:34 that decision along has cost them sooo many hours of support :) Nov 30 14:10:49 stt_michael: the problem is you can't set the output value before switching to output mode Nov 30 14:11:04 zmatt,.. no I see that .. Nov 30 14:11:22 stt_michael: except you can, by the poorly documented procedure of writing 'high'/'low' to direction Nov 30 14:11:29 right Nov 30 14:11:35 'out' is equivalent to 'low' Nov 30 14:11:43 and high.. yes. Nov 30 14:11:56 so they shoot themselves in the foot? Nov 30 14:11:57 Spidler_: you could also blame debian for making 'armhf' implicitly armv7 Nov 30 14:12:14 that was ARM Nov 30 14:12:17 not debian Nov 30 14:12:23 ogra_: uhh, what? Nov 30 14:12:36 ogra_: 'armhf' is a debian designator, not an ARM one Nov 30 14:12:49 zmatt: Yea, that too. Nov 30 14:12:50 they asked for the build options Nov 30 14:13:20 it depends then on what exactly the question was they asked ARM Nov 30 14:13:27 * ogra_ was involved in these discussions ... using v6 limits the v7 instructions set Nov 30 14:14:09 ARMv7 is a logical target since the arm11 processors are quite obscure and uncommonly used in any mainstream processor Nov 30 14:14:32 even now on the mixed multi-core SoCs you find v7-a, v7-m, and v5 Nov 30 14:14:34 not v6 Nov 30 14:14:38 right, butu beyond being logical you wouldnt get all the shiny v7 features Nov 30 14:14:58 (not at 100% at least) Nov 30 14:15:06 v6 didn't have thumb2 yet Nov 30 14:15:15 right Nov 30 14:15:31 well, there was a v6t2 but that's not used in the arm1176 in the rpi Nov 30 14:15:40 anyway, the initiative to pick v7 came initially from ARM Nov 30 14:15:54 when the port was started Nov 30 14:16:00 basically you have two branches of extensions of v6 Nov 30 14:16:07 and v7 is the merge of them Nov 30 14:17:15 only with lpae/ve did v7 really begin to change (but mostly from a kernel pov, userspace usually doesn't care) Nov 30 14:17:44 I think as far as the application-level ISA goes, thumb2 is the biggest difference Nov 30 14:18:23 and it *is* a big difference; thanks tot that, compilation to thumb is now usually even the default Nov 30 14:18:49 anyhow, back to topic Nov 30 14:19:12 if we had oen Nov 30 14:25:14 ogra_: the big problem is that debian has no way of indicating the detailed "compiled for / tuned for" of packages... that would really be useful Nov 30 14:25:26 and then have short abbreviations like "armhf" for the most common architectures Nov 30 14:29:36 Spidler_: I still don't really understand why you can't store a random seed key per device... do you have no non-volatile rw storage at all ? Nov 30 14:32:01 zmatt: we had the traditional "not enough entropy at first boot when generating private keys" problem. Nov 30 14:32:42 zmatt: Future boots are all fine and we have a seed then. Just that once they are freshly flashed. Nov 30 14:33:11 simply feeding the entropy pool with a bit from the hwrng at that point fixes it. Nov 30 14:34:37 Spidler_: hmm, I'd also include a seed for the rng at device programming time, just in case the hwrng isn't trustworthy Nov 30 14:34:47 it should be an easy enough problem to fix even without the hwrng Nov 30 14:35:24 The problem is that if you do that, ( seed at programming time) all devices get the same seed => boomp. Nov 30 14:36:48 combine with MAC address, problem solved Nov 30 14:37:06 be sure to overwrite the seed file immediately since it'll have become an "rng init key" Nov 30 14:37:57 or, make the programming procedure a bit less dumb than 'dd' Nov 30 14:38:33 Yea. Nov 30 14:38:51 tftp next I guess :) Nov 30 14:39:10 you need three ingredients to initialize an rng: secret (>= 128 bits of entropy) and fresh Nov 30 14:39:35 "fresh" being any value that's different whenever the secret is reused (across different points in time or across different devices) Nov 30 14:39:43 sorry, two ingredients Nov 30 14:40:00 (was originally going to split into "device-unique" and "fresh per boot") Nov 30 14:40:31 I'm well aware, the problem as said is that there's only shared state. No network, no timekeeping, nothing that separates the devices except for maybe serial numbers, mac address and so on. Nov 30 14:42:46 so many factors to consider, does the bbb output x264 without killing its cpu? Nov 30 14:43:30 hence you have all ingredients: secret (pre-programmed) + device-unique (mac address) + boot unique (you can use current datetime, assuming the mechanism works that uses the fs metadata to ensure in absence of rtc the clock is at least monotone across boots) Nov 30 14:44:12 Spidler_: though I recommend overwriting the secret with a fresh seed value of course, no need to have a long-term secret shared by many devices Nov 30 14:44:21 indeed. Nov 30 14:44:34 but in principle it suffices Nov 30 14:44:57 there are even military-grade RNGs that basically just encrypt a counter Nov 30 14:45:21 An AES stream can be provably enough random. Nov 30 14:45:30 not provably actually, conjecturally Nov 30 14:45:33 Basically how chacha works as an RNG Nov 30 14:45:59 more importantly, it's much easier to verify correct implementation and functioning than a "true RNG" Nov 30 14:46:27 I should just pay a troll to say "nine nine nine" all the time. Nov 30 14:46:29 a hwrng can be really badly broken without noticing Nov 30 14:47:03 Also true. And very hard to discover aftwards. Nov 30 14:48:15 well, the rng on the aes does have an internal monitoring/alarm mechanism, and there are test modes in which you can inspect the raw datastream of each of the 24 internal entropy sources (FROs) Nov 30 14:48:25 see my e2e post Nov 30 14:48:33 Yeah, saw that one. Good reading Nov 30 14:50:22 Basically, my current tooling will read 64 bytes from /dev/hwrng and mix it into the current kernel pool ( writing to /dev/urandom ) Nov 30 14:50:23 would be nice to get a long contiguous trace (at max sample rate) of each FRO instead of separate 64-bit chunks, and then run some analysis on them Nov 30 14:50:47 I'd grab a lot more than 64 bytes Nov 30 14:51:37 Probably a good idea to grab 512 bytes Nov 30 14:52:00 64 bytes means you need at least 0.25 bit of entropy per bit of output Nov 30 14:52:05 since the pool is "full" at 4096 bits Nov 30 14:52:24 Hmm, point. Nov 30 14:52:30 and the hwrng delivers data *fast* Nov 30 14:52:48 like, unless the driver is badly written, reading from /dev/hwrng is probably faster than reading from eMMC Nov 30 14:53:15 (i.e. using a seed file to initialize the RNG is slower than using the hwrng) Nov 30 14:53:49 depends on the config vars of the rng though... checking kernel sources to see what they are currently Nov 30 14:53:57 mmm. right Nov 30 14:54:19 I should just use getrandom() and be happy. Nov 30 14:54:32 that's just /dev/urandom :P Nov 30 14:54:59 ./dev/urandom uninitialized still doesn't block Nov 30 14:55:35 yeah that's kind of a misfeature. same goes for the getrandom() syscall persumably? Nov 30 14:55:50 Nope Nov 30 14:55:58 that blocks until there is random pool available Nov 30 14:56:50 but doesn't require "fresh" entropy? in other words, it behaves saner than both /dev/random and /dev/urandom ? Nov 30 14:56:58 Yeah, it does Nov 30 14:57:19 Basically, if the system _is_ initialized (has entropy) it behaves the same as urandom/random Nov 30 14:57:36 if it's _not_ initialized ( no entropy gathered) it blocks (by default) Nov 30 14:58:01 /dev/random doesn't block after system initialization? I thought that was its problem, but maybe my info on that is outdated, haven't looked into it in a looong time Nov 30 14:58:04 The alternative to blocking, is to return -1 and errno=EAGAIN Nov 30 14:58:22 dev/random blocks after initialization, it always depletes the entropy pool Nov 30 14:58:35 and the getrandom() syscall? Nov 30 14:58:39 dev/urandom mixes the entropy pool into some rounds of (md4 afaik) Nov 30 14:58:54 getrandom either blocks until you have data in the pool, or returns EAGAIN Nov 30 14:59:07 ah wait, it has a flag for it actually Nov 30 14:59:09 http://man7.org/linux/man-pages/man2/getrandom.2.html Nov 30 14:59:13 ( based on if you set the NOBLOCK flag ) Nov 30 15:00:00 man 4 random is weird. Nov 30 15:00:09 not random, getrandom Nov 30 15:00:17 turns out that simply writing data to /dev/urandom isn't enough to increase the entropy count Nov 30 15:00:29 oh you're talking about something else Nov 30 15:00:30 It'll mix it in, but it won't count it towards entropy Nov 30 15:00:35 duh Nov 30 15:00:49 at least increasing entropy estimate should be privileged Nov 30 15:00:51 but if you use the ioctl you can get it to do so. Nov 30 15:00:59 but really, anything relying on entropy estimation is Broken By Design Nov 30 15:01:33 I'm really wondering why you can even write to /dev/urandom as a non-privileged user Nov 30 15:01:46 so anyone can contribute randomness Nov 30 15:01:49 it doesn't do any harm Nov 30 15:03:43 yeah, I'm just never quite ready to grasp that :) Nov 30 15:10:14 ok, min-refill is 33*64 cycles = 21.12 μs Nov 30 15:10:56 that's an max output rate if about 370 KB/s Nov 30 15:10:59 *of Nov 30 15:11:21 For my needs, shouldn't be too bad Nov 30 15:12:47 note that the FROs don't magically produce more entropy if you configure a higher output rate... you just get lower-quality output Nov 30 15:14:28 otoh if you're mixing it into an entropy pool anyway, better to use a high data rate and collect it in the software entropy (large pool, cryptographic hash function) than using the pool built into the hwrng (81-bit linear feedback shift register) Nov 30 15:25:51 the annoying part is that the *correct* parameters to use will be hardware-dependent... presumably the module included docs for the implementor on how to test and calibrate the implementation and determine the correct values, but that doesn't help us much Nov 30 22:49:56 hello, I am setting up my bbb for the first time. I have checked the guide. ifconfig works otherwise but the line under eth0 between "link" and inet6" is missing. How can I determine my IP? **** ENDING LOGGING AT Tue Dec 01 03:00:46 2015