**** BEGIN LOGGING AT Tue Jan 19 02:59:58 2016 Jan 19 03:37:52 Hi, Does anyone here have any experience modifying PCB layout for BBB ? Jan 19 03:59:50 The Beaglebone green has 4 different BB-BONE-PRU-* device tree overlay files. What's the difference between them? Jan 19 04:32:45 veremit: you have no dt? how did you manage that? are you running the debian build, or some mod of it? Jan 19 04:34:32 yates: probably a kernel that predates DT Jan 19 04:37:14 (or at least predates support for board files being dropped) Jan 19 04:52:31 apart from managing capes, what do i need dt for? Jan 19 04:52:38 we have no capes.. Jan 19 04:52:54 (at the risk of asking a stupid question...) Jan 19 04:54:46 yates: The kernel uses the dt to define what hardware it runs on. You need dt overlays for capes (changes in the default hardware). Jan 19 04:56:32 is there a good doc on the dt? (and hopefully up-to-date?) Jan 19 04:57:12 is a dt used in all linux distros these days? e.g., in something like ubuntu? Jan 19 04:57:49 it is not distro-dependent but architecture-dependent Jan 19 04:58:13 so if i'm running ubuntu on an x86_64, there is a dt? Jan 19 04:58:24 x86 doesn't use DT but gets data structures with a similar purpose from BIOS Jan 19 04:58:43 DT originally comes from PowerPC Jan 19 04:59:31 specifically, it originally represented the Device Tree from Open Firmware Jan 19 04:59:57 so does the dt define things like how much dram is on-board and where it is mapped? Jan 19 05:00:17 linux imported these by running a tiny tool that scraped the Open Firmware device tree and turned it into a "flattened device tree" data structure that was then passed to the kernel Jan 19 05:00:57 ARM systems usually don't use OpenFirmware (the OPLC laptop being an exception) but the same data structure stuck into a file is now known as the dtb Jan 19 05:01:08 yes Jan 19 05:01:32 there's a dummy entry in most DTs for RAM but it's overwritten by u-boot (or even added if missing) Jan 19 05:02:08 in most DTBs I mean Jan 19 05:03:22 wait I'm misrepresenting the history... it comes from Sun (Open Boot) so I presume it was originally for SPARC Jan 19 05:06:00 before there was a dt, how was the information in the dt incorporated into a build? Jan 19 05:06:12 board files Jan 19 05:06:15 board support files? Jan 19 05:06:25 (bsp's) Jan 19 05:08:14 so the dt mechanism provides a way to use the same kernel with different board variations without having to rebuild the kernel? Jan 19 05:08:43 yes Jan 19 05:09:58 for an old-style kernel example for the beaglebone you could dig up a 3.2 kernel, I think that was per-DT Jan 19 05:10:10 pre-DT Jan 19 05:10:12 that Jan 19 05:10:30 does angstrom use dt's? Jan 19 05:10:48 I have no idea, I'm not that deeply into archeology Jan 19 05:10:48 current angstrom Jan 19 05:10:59 huh? :) Jan 19 05:11:01 if they use a current kernel, then no Jan 19 05:11:08 eh Jan 19 05:11:09 then yes Jan 19 05:11:35 are you implying angstrom is a relic? :) Jan 19 05:13:56 I have no idea really, often people using angstrom on the BBB run something ancient. non-DT is also a relic, so if the kernel is recent the answer to your question is not dependent on distro Jan 19 05:14:16 i see Jan 19 05:14:31 the 1000-question interrogation ends... Jan 19 05:14:36 sorry. Jan 19 05:14:51 some people still maintain things were better in Ye Olde Days Jan 19 05:14:59 verily Jan 19 05:15:47 i'm wondering what, if anything, i might need to change in the dt from that provided with the rcn bbb build Jan 19 05:15:51 for our board Jan 19 05:16:37 can i just remove the dto's? we don't use capes. Jan 19 05:17:07 we took out the hdmi framer Jan 19 05:17:24 the board id eeprom Jan 19 05:17:24 dtbos, yes I actually never include bone_capemgr in my kernel builds (I do enable support for overlays but normally never use them) Jan 19 05:17:44 then you should at least remove those from DT Jan 19 05:18:14 does u-boot share this with the kernal somehow? Jan 19 05:18:17 kernel Jan 19 05:18:45 ok, thanks Jan 19 05:19:15 u-boot loads the DTB, makes a few modifications (RAM size is the only one I can think of right now) and passes the final result to the kernel, somewhat similar to an initramfs Jan 19 05:19:59 no idea why RAM size is special-cased in this way, I see no real reason for it Jan 19 05:20:08 it's not like u-boot can auto-detect it Jan 19 05:20:21 can't autodetect? Jan 19 05:20:25 (well I suppose in theory it might be able so) Jan 19 05:20:33 I doubt it does that though Jan 19 05:20:40 but maybe I'm wrong Jan 19 05:21:24 maybe it saves time Jan 19 05:21:27 but like everything else that's soldered onto the board, there's not really any good reason to try to detect it at runtime Jan 19 05:21:28 boot time Jan 19 05:22:13 no, fixing the correct value in the DTB will always be faster (though the difference will be negligible either way) Jan 19 05:22:19 btw, i noticed my dram test code runs through about 4Mb/s. does that sound really slow or is it reasonable? Jan 19 05:22:23 not having to do fixups would also save code Jan 19 05:22:30 zmatt: yeah, that's what i mean. Jan 19 05:22:43 having the ram size will improve (decrease) boot time. Jan 19 05:23:30 no, wait. it's more like 8 MB/s (above was a typo: meant 4 MB/s) Jan 19 05:24:24 it does a write to all 512MB, then a read from all 512MB in about 2 minute Jan 19 05:25:18 what is the peak data rate of a ddr3 running at 800 MHz (400 MHz PLL) anyway? Jan 19 05:25:53 800M transfers/second? Jan 19 05:25:55 theoretical peak bandwidth for DDR3-800 is 1.49 GB/s and I'd kinda expect sequential writes or reads to come within a reasonable factor thereof Jan 19 05:26:04 especially writes Jan 19 05:26:23 zmatt: The privileged writes to the pad control I/O don't work for me; I get kernel errors. Now I'm trying to let the PRU write for me, but it doesn't seem to have any effect. Should I check my PRU program, or is it not supposed to work? Jan 19 05:27:12 shevek: huh, that's odd Jan 19 05:27:19 how would you get this srot of performance? via dma's? Jan 19 05:27:23 sort Jan 19 05:27:43 i noticed that's what the TI dram test gel file functions do (edma's) Jan 19 05:27:51 yates: do you have the MMU enabled yet? Jan 19 05:27:54 no Jan 19 05:28:16 yeah but that's because doing RAM access directly from GEL would be _really_ excruciatingly slow Jan 19 05:28:30 zmatt: The errors? Yes, I had not expected them either. Especially because they're from the kernel, which I didn't touch. It was saying something about THUMB2 and dumping a lot of numbers. Jan 19 05:29:07 i noticed doing a memory fill, via the normal CCS memory command, is really, REALLY slow... it would have taken hours to complete Jan 19 05:29:53 shevek: well the kernel does report bus errors Jan 19 05:29:58 shevek: do you have a log? Jan 19 05:30:13 yates: last I benched it it was less than 10 KB/s Jan 19 05:30:19 to perform a JTAG upload Jan 19 05:30:50 zmatt: No, it was this afternoon, I closed all the windows already. And changed to code to use the PRU instead, so it's not very easy to reproduce. Jan 19 05:31:14 shevek: PRU probably generates unprivileged accesses Jan 19 05:31:17 control module ignores those Jan 19 05:31:25 Yes, that's what it looks like. Jan 19 05:31:30 or well, ignores unprivileged writes Jan 19 05:32:48 yates: even on theoretical grounds the max speed is less than 4 MB/s, or less than 2 MB/s if using an FT2232H (like most cheap jtag adapters), or less than 1 MB/s if you also don't want to exceed the max jtag clock speed stated in the datasheet Jan 19 05:33:24 zmatt: But earlier I got bus errors as well; they just happen as a signal to the process. This was broadcast to all terminals, similar to an Oops. Jan 19 05:33:31 shevek: odd Jan 19 05:35:27 But well, it's time for bed. I'll think more about it tomorrow. Jan 19 05:36:36 I'll also do a quick test to see if recent kernels broke it somehow Jan 19 07:39:22 PCB layouts for the beagle are easy to change :D Jan 19 10:24:13 yates: edma should have an easy time flooding EMIF, though it always needs a source and a destination hence to perform sustained sequential writes (or sustained sequential reads) you'd need another L3 target to serve as source (resp destination). OCMC RAM would be an obvious choice Jan 19 10:26:29 yates: I'd expect the cortex-a8 can also sustain writes provided the memory type is normal, reads may be trickier though enabling L2 cache and using Neon or the PLE ought to work I think Jan 19 12:58:21 zmatt: where did you get the 1.49GB/s figure? Jan 19 13:00:25 also, if you're in a loop that requires, say, 20 cycles per loop, how would you get close to this with sequential r/w's at 960 MHz? 960/20 = 48 MB/s. Jan 19 13:00:57 800e6 * 2 B / 1024^3 Jan 19 13:01:44 of course for sequential access some time is lost due to row switching Jan 19 13:02:28 where did 1024^3 come from? Jan 19 13:02:34 converting from bytes to GB Jan 19 13:03:03 i see Jan 19 13:03:10 makes sense. Jan 19 13:03:20 and the cortex-a8 can haul 16 bytes per cycle afaik Jan 19 13:03:42 so we'd be up to 96 MB/s in that loop. Jan 19 13:03:50 no,wait. Jan 19 13:03:55 16 BYTES... Jan 19 13:04:02 also, why is that loop taking so many cycles? Jan 19 13:04:21 let's not go there right now. Jan 19 13:04:37 how would you get 16 bytes per transfer just using register reads/writes? Jan 19 13:04:43 neon Jan 19 13:05:16 the integer unit can only transfer 8 bytes per cycle Jan 19 13:05:38 though not sustained Jan 19 13:06:59 however if you just want to stress RAM you can play foul by enabling L2 cache and performing the RAM test with a stride between each access that causes each one to touch a different cache line Jan 19 13:07:03 8 bytes using, e.g., ldrd? Jan 19 13:07:56 I'm not sure about ldrd, ldm/stm however does use it for all but the first one or two transfers Jan 19 13:09:24 (due to static scheduling the cpu assumes the address is misaligned) Jan 19 13:10:09 are the neon instructions part of main cpu? or is neon a coprocessor of some sort? i.e., can i just put neon instructions along with thumb/arm and get a speedup? Jan 19 13:10:13 when using the cacheline trick however I'd just use ldr/str Jan 19 13:11:42 neon code can be freely intermixed with arm/thumb code, it executes on a coprocessor hence requires register transfers if you want to do your computation in the integer unit Jan 19 13:12:15 transferring from arm regs to neon regs is nearly free, the opposite direction incurs the worst pipeline bubble the cortex-a8 has Jan 19 13:14:07 for more insight into cortex-a8 performance I suggest this paper -> https://web.archive.org/web/20150101062932/http://www.arm.com/files/pdf/A8_Paper.pdf Jan 19 13:16:40 is neon on the am3352? Jan 19 13:16:51 (we're not using the am3358/9) Jan 19 13:17:15 afaik the cortex-a8 subsystem is the same on all am335x versions Jan 19 13:18:28 you can check the datasheet to be sure of course Jan 19 13:23:19 so you're saying you should be able to get 960M/20 transfers/s * 16 B/transfer = 768 MB/s just using assembly with the mmu/cache off? Jan 19 13:23:39 (not using neon) Jan 19 13:23:47 no Jan 19 13:24:09 you will not get any sort of performance with mmu off, with or without neon Jan 19 13:26:18 does that have to do with the procesing treating SRAM as "strongly ordered" type with mmu off? Jan 19 13:26:25 processor Jan 19 13:26:44 treating all data access as strongly-ordered, yes Jan 19 13:26:58 you mean SRAM and DRAM? Jan 19 13:27:12 the cpu can't tell the difference Jan 19 13:29:22 sram, dram, peripherals... to the cpu it's just one big 4 GB address space Jan 19 13:32:13 do you suggest i read about these concepts (e.g., strongly ordered) in the a8 trm chapter 3, "System Control Processor"? or is there a better source? Jan 19 13:32:28 or better place Jan 19 13:33:34 let me re-ask this question: so you're saying you should be able to get 960M/20 transfers/s * 16 B/transfer = 768 MB/s just using assembly with the mmu/cache ON? Jan 19 13:37:49 if you write 16 bytes per 20 cycles then yes (with or without cache), though I don't see why you're assuming those particular numbers. reading is a bit more complicated due to potential for cpu stalls Jan 19 13:40:44 reading 16 bytes per iteration sequentially with cache enabled would cause the cpu to stall on a linefill once per 4 iterations, though you may be able to prevent it using the preload instructon (PLD) Jan 19 13:42:13 the authoritive source for info about memory types is the chapter "Memory types and attributes and the memory order model" in the ARM architecture reference manual Jan 19 13:44:29 I wouldn't spend too much time reading about the memory order model though, but understanding the restrictions imposed on the cpu by Device and Strongly-ordered memory types is useful Jan 19 13:45:24 (you can skip all yada about coherency or shareability, it's not important for the cortex-a8) Jan 19 14:46:05 960MHz = arm core operating frequency Jan 19 14:46:15 20 cycles per loop = wild ass guess Jan 19 14:46:41 arm meaning am335x in this case Jan 19 14:47:26 whatever the instruction cycles are Jan 19 14:48:35 16B/transfer = transfers using STM/LDM Jan 19 14:51:47 by cpu "stall" do you mean (esentially) "wait states"? Jan 19 14:52:11 why would there be potential for stalls with reads but not writes? Jan 19 15:29:22 G'day is it feasible to do video playback on the BeagleBone Black? from a streamed source? Jan 19 15:43:57 Whoops cloosed the tab by accident Jan 19 16:02:15 kieran491: depends™. it will need to be done by the CPU as there is no hardware acceleration Jan 19 16:05:13 So then it comes down to the encoding of the video Jan 19 16:05:54 get a pi .. lol Jan 19 16:06:01 its got a video core Jan 19 16:07:50 multimedia, that's about the only sensible use case for that thing Jan 19 16:08:24 given that most of the silicon is the VC4 and the ARM11 is just a tiny speck Jan 19 16:09:16 kieran491: i'm sure you could do something, e.g., postage stamp size. i'm sure you couldn't do blue-ray resolution and frame rates. where in beteween here are you? Jan 19 16:09:30 tbr: precisely Jan 19 16:09:43 can't do h264 or hd I don't suppose Jan 19 16:09:54 its only 800mhz Jan 19 16:10:01 unless you clock it Jan 19 16:10:25 SD might work Jan 19 16:10:34 I was looking at getting a riotboard as it seems to have a soc designed for multimedia but was just wondering if i can coble up something with the beagle Jan 19 16:11:11 if your usecase is xbmc-ish, then don't bother Jan 19 16:11:28 if it's something else, tell us and we'll see Jan 19 16:12:23 tbr I was looking at streaming with VLC but i still need to look into weather or not that is the best choice Jan 19 16:13:31 yes but streaming what and for what purpose? what resolution? Jan 19 16:16:36 you don't really wanna be doing serious "video" on the beagle .. its not designed for it Jan 19 16:22:20 Yeah i am getting that vibe about the beaglebone its all about raw data crunching from it's peripherals and connectivity Jan 19 16:26:35 this sort of 50,000-foot question is essentially meaningless. determine your requirements, then evaluate solutions. Jan 19 16:31:02 its a connectivity and io board.. no a desktop board Jan 19 17:25:21 zmatt: i see now, after looking over chapter 16 in the a8 trm, that a small loop should take a lot less than 20 cycles. most instructions are one cycle, plus those that are dual-issue are essentially 0 cycles. Jan 19 18:55:20 yates: yup, as long as the compiler (if still using asm that means you) can properly schedule the code Jan 19 18:55:44 but the constraints are quite mild Jan 19 18:57:15 for reads the loop will easily be dominated by memory stalls because the cpu performs no speculative access or readahead (other then instruction fetching) and is strictly in-order, hence it needs to sit and wait for the data Jan 19 18:58:37 neon has the benefit that multiple reads can be outstanding and there's significant time between the address being known (in the ARM pipeline) and the data being needed (in the Neon pipeline) Jan 19 18:59:08 the cpu otoh doesn't need to wait for writes to complete, unless the memory type is strongly ordered Jan 19 19:01:22 if the memory type is normal (rather than device or s-o) then additionally small sequential writes will automatically be coalesced to aligned 16-byte writes Jan 19 19:07:54 btw, you mentioned 960 MHz ? where did that odd speed come from ? the cpu by default runs at 500 MHz (since pmic involvement is needed before it can be raised higher) Jan 19 19:08:52 s/can/is allowed to/ Jan 19 19:12:13 Is there a way I can diagnose why my eth0 link went down on a BBW? The activity led is blinking, but I can't ping into or out of the BB. It has been working fine for days and I noticed a kernel message "Link is Down" indicating it went down sometime overnight. Jan 19 19:14:08 gferencz: hmm, I've seen the same phenomenon, though only at power up Jan 19 19:14:16 gferencz: what happens if you unplug the cable Jan 19 19:14:17 ? Jan 19 19:14:42 (and replug it) Jan 19 19:14:49 I unplugged and replugged and didn't notice a difference Jan 19 19:15:19 specifically the behaviour of the ethernet leds while doing so Jan 19 19:15:51 Green and amber are solid after disconnecting Jan 19 19:16:06 Green blinks again after reconnecting Jan 19 19:16:50 yeap, that's one very confused ethernet phy Jan 19 19:18:12 now that I think of it I've also had it once after power up, but that was while handling it Jan 19 19:18:42 my main suspect was esd, but if yours went overnight while untouched that explanation seems unlikely Jan 19 19:19:08 I wish I had my webcam going to see if that's when the overnight cleaning crew were in the office Jan 19 19:19:20 ahh Jan 19 19:19:28 It's a possibility Jan 19 19:20:08 I hope your cleaner know not to come near electronics with something like a duster Jan 19 19:20:43 Heh...no worries there. They certainly haven't dusted my desk. Jan 19 19:22:44 good, I've already once stopped one just in time who was wielding a duster-o-doom Jan 19 19:27:02 in any case, I tried to diagnose it when it happened but it seemed too confused to do anything again and just reset the board Jan 19 19:32:06 Thanks zmatt. I was going to just reboot, but thought I'd check here first. Jan 19 19:32:56 plain reboot may not fix it since the phy isn't hard-reset in that case. since resetting without clean shutdown is not recommended, I suggest powering down and up again Jan 19 19:34:56 Power cycling fixed it. I just saw 'Link is Up' scroll by. Jan 19 19:36:06 I did see some wierd ping behavior while it was in that state Jan 19 19:37:15 well, not coming from the bbb since it won't be responding to anything while link is down (I also never saw link up on the peer's side while it was in that state, so it wasn't simple misreporting on the bbb) Jan 19 19:37:58 It had 'Vr HL TOS' etc columns. I hadn't seen that before, but I'm fairly new at this. Jan 19 19:38:22 It was only after attempting to 'ifup eth0' Jan 19 19:57:06 it was probably just displaying the unreachability error Jan 19 20:02:08 zmatt, I see. "Destination Host Unreachable". I guess I hadn't come across the unreachability error before (or didn't pay attention to the output..). Thanks again! Jan 19 22:27:11 re: 960 MHz: huh. you're right. i guess i accidently looked at the USB in table 26-6 of the am335x trm. Jan 19 22:33:37 zmatt: this statement is only when mmu/cache is off, right? the cache should fill if it's on, right? "for reads the loop will easily be dominated by memory stalls because the cpu performs no speculative access or readahead (other then instruction fetching) and is strictly in-order, hence it needs to sit and wait for the data" Jan 19 22:39:14 for cacheable reads it's still true for the first access to each (64-byte) cacheline Jan 19 22:39:38 you can mitigate it with preloads Jan 19 22:40:14 (using pld instructions or the preload engine to fill L2 cache ahead of the processor's needs) Jan 19 22:41:34 yes, of course the first cacheline will take a hit. Jan 19 22:42:05 but generally the process should be much quicker. Jan 19 22:42:12 "on average" Jan 19 22:42:58 of course it will be, but especially for an efficienty written loop it can still easily dominate overall time Jan 19 22:44:06 you mean if you use LDM (e.g.)? Jan 19 22:44:32 vld1 Jan 19 22:45:12 meh - i'm not goign to mess with the neon stuff - just looking for standard arm/thum speedups right now. Jan 19 22:45:20 actually just contemplating... Jan 19 22:46:16 if i can get a speedup of x100, i'd be very happy. Jan 19 22:46:52 just so you don't have to wait 10 frickin' minutes for the tests to complete.. Jan 19 22:48:05 and just going forward to u-boot? (which handles the MMU for you and I'm fairly certain also includes memory tests) Jan 19 22:48:46 do you mean u-boot only? i.e., not loading linux afterwards? Jan 19 22:48:58 well one step at a time Jan 19 22:50:40 that would be the quickest. i suppose i am looking to get some knowledge along the way. Jan 19 22:52:23 what kind of "operating system" does uboot have if you don't load linux? Jan 19 22:53:06 is there an example of getting uboot to initializae and just light some leds, or something similarly simple? Jan 19 22:53:56 i haven't even thought about "peering into" uboot, but i suppose i should at least think about it. Jan 19 22:55:10 and..., i love the CONTROL i have under assembly, of which knowing what's happening "under the hood" (e.g., mmu) is a significant part. Jan 19 22:56:36 but i'm perhaps a megalomaniac.. Jan 19 23:23:43 hehe Jan 19 23:25:33 I can understand, but it takes a lot of time Jan 19 23:25:39 yah. Jan 19 23:26:04 and u-boot will get you a serial console with a simple shell Jan 19 23:26:26 if you've never played around with it, I suggest exploring it on a bbb first Jan 19 23:26:31 ah, right. Jan 19 23:26:42 yeah, that's usually my approach. bbb first, then our board. Jan 19 23:27:24 i'm have a hard time grokking this still.. : https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard Jan 19 23:27:36 namely, the 2nd and 3rd sudo dd's there. Jan 19 23:27:53 yates, 'raw boot' .. ;) Jan 19 23:28:15 it looks like he's copying some files there, THEN doing a format. Jan 19 23:28:21 what the.. ? Jan 19 23:28:32 they are before the partition table.... ;) Jan 19 23:28:33 rcn-ee: bs=384k .. that's really gross btw :P Jan 19 23:28:40 (i.e., a little further, with the mkfs) Jan 19 23:28:52 that's what the fedora guys setup it with. ;) Jan 19 23:28:54 won't the format hose up any file data written there? Jan 19 23:29:04 nope... it's in master boot record... Jan 19 23:29:19 yates: the partition table is in section 0, the first partition starts at 1 MB from the start Jan 19 23:29:20 it won't boot on an x86. ;) Jan 19 23:29:34 yates: the stuff inbetween won't be touched Jan 19 23:29:57 most versions of sfdisk/fdisk default to starting 1Mb for "msdos" now days, i'm just forcing it by default.. Jan 19 23:30:06 it uses to be sector 63.. Jan 19 23:30:13 rcn-ee: it should actually be 4 MB for eMMC Jan 19 23:30:21 allocation group size Jan 19 23:30:50 doesn't sfdisk rewrite the partition table? Jan 19 23:30:58 yates: yes Jan 19 23:31:07 it does, but it's not anywhere near where we dd'ed.. Jan 19 23:31:30 a lot of space in 1MB ;) Jan 19 23:32:11 https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout Jan 19 23:32:14 i need to draw me a pciture. Jan 19 23:32:44 rcn-ee: btw, why on earth does u-boot produce a file named "MLO" that in fact consists of a raw mmc header (padded to 512 bytes) followed by the actual MLO ? Jan 19 23:33:30 which also means the file isn't usable for any other boot method that needs an MLO (unless you know about this and strip off the first 512 bytes) Jan 19 23:33:56 zmatt, i blame x-loader and all the tools.. ;) Jan 19 23:37:23 this seems like great hints. i'm too ignorant to really understand at this point.. saving this conversation to a file and doing some reading... Jan 19 23:37:52 also someone reported boot failure on the BBW with the -rt kernel on the new images... I had him install the non-rt kernel (using a bbb) and that fixed the boot issue Jan 19 23:38:01 it went sour somewhere in ths tps65217 driver Jan 19 23:38:26 yates on the "am335x" you can still do the omap3 "classic" fat boot.. https://eewiki.net/display/linuxonarm/BeagleBoard#BeagleBoard-SetupmicroSDcard Jan 19 23:39:07 is the "classic" fat boot only good for sdcard boots? Jan 19 23:39:08 the bootrom supports the old method.. we moved to raw mode for a bunch of reasons.. ( users deleting MLO/u-boot.img ) Jan 19 23:39:32 or is it also good for emmc? Jan 19 23:39:33 sdcard/eMMC... aka thru the MMC drive in u-boot.. Jan 19 23:39:36 yates: also see again the README of my asm demo, it explains both mmc boot methods Jan 19 23:40:05 firehose.. drinking... too fast... Jan 19 23:40:21 ok, lemme read.. Jan 19 23:40:58 thanks guys. Jan 19 23:41:01 zmatt, i saw that one, need to fire up the bbw.. was tracking down a broken /dev/random, turns out preempt_rt brakes that.. Jan 19 23:41:03 the caution about destroying existing content is a bit too harsh btw for the first one Jan 19 23:43:05 writing the raw boot stuff doesn't hurt existing data (nor is it hurt by (re)partitioning) provided there's enough free space before the first partition Jan 19 23:44:07 rcn-ee: -rt is probably good at breaking stuff (arguably that stuff then also deserved to be broken, but users won't care much for that argument) Jan 19 23:44:18 yeah, then depending on your 'fat' driver, the order of "updating" MLO & u-boot.img on the fat partition is tricky... Jan 19 23:45:15 updating raw mmc can be done atomically in principle, though that probably won't be true due to the two-stage loading Jan 19 23:45:36 now that i proved it was preempt_rt switch, i kinda makes sense... dev/random grabs entropy from process/etc... well preempt_rt makes that all uniform. ;) Jan 19 23:46:14 why doesn't it grab entropy from the hw rng? that's what the thing is for Jan 19 23:48:05 it's a generic tester... https://www.cryptopp.com/ Jan 19 23:49:52 I mean the kernel Jan 19 23:50:07 there's no reason for /dev/random to ever stall on a platform that has a hw rng Jan 19 23:51:18 and i think that's the actuall preempt bug.. (the hw rng isn't being used).. with preempt disabled, it gets random bytes instantly.. Jan 19 23:51:59 on non-rt I've also seen warning messages along the lines of random() being called with only of entropy in pool Jan 19 23:52:46 getrandom() I mean Jan 20 00:01:17 oh bugger .. missed him Jan 20 00:01:41 lol @ the name of this mailing list ... https://www.ietf.org/mailman/listinfo/dsfjdssdfsd Jan 20 00:11:47 I do wonder why rcn-ee has a tendency to vanish like this Jan 20 00:12:03 why he doesn't get have a bouncer... Jan 20 00:12:12 * vagrantc suspects it has something to do with work hours Jan 20 00:12:26 yes thats quite obvious, and cutting himself off Jan 20 00:15:12 wb rcn-ee Jan 20 00:16:39 ooo Jan 20 00:17:00 lives close to work :D lol Jan 20 00:17:46 bloooock.... lol, sorry, djb's fault Jan 20 00:18:48 (http://cr.yp.to/talks/2016.01.15/slides-djb-20160115-a4.pdf search for "Tor") Jan 20 00:28:29 Is there any way to disable a cape? I need ttyO4 most of the time, but I also need to be able to switch it off. Jan 20 00:28:54 peripherals aren't really designed to be dynamically turned on and off Jan 20 00:29:02 sure they are Jan 20 00:29:13 zmatt; well perhaps you can advise Jan 20 00:29:21 I don't need to switch the port off, but I need to be able to use the pins as GPIO. Jan 20 00:29:24 drivers might not be, that's not the same as peripherals not being :P Jan 20 00:29:35 zmatt: this ain't a micro :P~ that's very easy Jan 20 00:29:46 though using an overlay and unloading it should work Jan 20 00:29:57 (unless it doesn't and results in a kernel panic instead) Jan 20 00:29:58 How do I unload an overlay? Jan 20 00:30:35 if you're using bone_capemgr then no idea, I only know the new configfs mechanism Jan 20 00:31:09 Hmm, too bad. And if I write my own overlay, is it possible to do it in a way that it can switch between them somehow? Jan 20 00:31:32 unload one, load the other Jan 20 00:31:46 I mean switch between pin functions. Jan 20 00:32:12 yes Jan 20 00:32:13 echo > capemgr.slots Jan 20 00:32:45 veremit: you can't load two overlays with conflicting pins though, so you first need to unload the previous one Jan 20 00:33:10 I'm sure the cape_mgr will balk :p Jan 20 00:33:26 and there is a load/unload interface on capemgr Jan 20 00:33:37 Yes, it does. And I have not found a way to unload a cape, except by rebooting. Jan 20 00:33:48 There is? How does it work? Jan 20 00:34:05 well .. it must be similar syntax Jan 20 00:35:01 I vaguely recall there is, but don't remember the details Jan 20 00:35:42 Hey folks, have a question. In the book "Exploring BeagleBone", the author suggests that you can "destroy" your beaglebone by removing power without shutting down. That sounds like hyperbole to me. Jan 20 00:36:03 Can you actually do physical damage, or is it just the possibility to corrupt the image? Jan 20 00:38:15 there is some minor concern of damage since it drops the supply rails to the cpu too fast and without regard to proper sequencing Jan 20 00:39:15 I mostly try to do clean shutdowns out of concern of the image though (I have seen fs corruption due to casual use of the reset button) Jan 20 00:39:57 So unlikely that there would be hardware damage, but not impossible Jan 20 00:40:38 https://github.com/jadonk/validation-scripts/tree/master/test-capemgr Jan 20 00:40:43 second half of that page Jan 20 00:40:53 right, and a clean shutdown isn't that clean either since the braindead tps65217 switches to battery power at the start of the powerdown sequence, regardless of whether a battery is present, leaving the system to run on caps during powerdown Jan 20 00:41:54 kk Jan 20 00:42:24 shevek ^^ that page .. echo "-X" > slots Jan 20 00:42:25 And I assume the system is not smart enough to detect the loss of power and start shutdown automatically Jan 20 00:43:06 tps will initiate powerdown on detecting undervoltage, but it doesn't have time to do so Jan 20 00:43:32 veremit: Thanks! Jan 20 00:43:41 for reference, this shows a shutdown: http://elinux.org/File:Bbb-c-3v3u-shutdown-dc5v-hdmi.png Jan 20 00:43:44 How long do the caps keep it active after power loss? Jan 20 00:43:45 not sure whether that really works .. but hey Jan 20 00:43:46 vs cutting power: http://elinux.org/File:Bbb-c-3v3u-powercut-hdmi.png Jan 20 00:44:06 thx zmatt Jan 20 00:45:26 (this is actually a slightly patched bbb, but I'm not sure whether I have any useful pics of an unpatched one... I don't expect a big difference) Jan 20 00:45:58 Hmm yes. The kernel doesn't like it, as predicted. Jan 20 00:47:00 mind that if you have multiple overlays loaded, you can only unload them in reverse order... you can't remove one from the middle of the stack Jan 20 00:47:55 Ok, that's good to know. Jan 20 00:54:16 Hmm, it doesn't seem like I can unload the top of the stack either; the board just crashes. :-( Jan 20 00:55:38 yeah not all drivers are too fond of runtime changes to the device tree Jan 20 00:56:09 what kernel version are you running? Jan 20 00:58:10 3.8.13-bone71.1 Jan 20 00:58:41 ah, an ancient kernel, that probably also doesn't help Jan 20 00:59:28 I suppose it doesn't. I would like to avoid upgrading though, but I can if I have to. Jan 20 01:00:16 (The reason is I want to put this on many boards, and upgrading all of them would take a lot of time.) Jan 20 02:09:57 hi -- does anyone know where the official device tree compiler source is? everything on github seems to be a fork Jan 20 02:36:49 kremlin: git clone git://git.kernel.org/pub/scm/utils/dtc/dtc.git Jan 20 02:37:18 kremlin: http://www.devicetree.org/Device_Tree_Compiler Jan 20 02:37:34 wmat: thanks! Jan 20 02:39:06 wmat: does that one work, I had a feeling there was a patch needed .. and hence rcn-ee's version ? Jan 20 02:40:24 veremit: no idea, just providing the official dtc source as asked Jan 20 02:40:32 wmat: okies :D Jan 20 02:44:07 it ended up being installed as part of the bb.org-overlays repo Jan 20 02:47:26 yea mighta found its way to /opt possibly Jan 20 02:47:42 that is where it *usually* is but im using the minimal debian image Jan 20 02:47:56 and it seems to lack it + some other things it probably shouldn't lack Jan 20 02:48:08 ah rn's eewiki site? or another? Jan 20 02:48:26 the console image is pretty bare Jan 20 02:48:55 rcn-ee one Jan 20 02:49:01 unfortunately there isn't a lot of 'middle ground' its everything or nawt. Although he did say where his build script was once ... Jan 20 02:49:08 it comes with curl and wget but not file or make.. Jan 20 02:49:11 you could tweak that and rebuild one Jan 20 02:49:24 apt-get install file make Jan 20 02:49:30 i know that :P Jan 20 02:49:34 hehehe Jan 20 02:49:47 it just seems odd to include wget/curl but not `file` Jan 20 02:50:47 oh wow .. nailed it .. https://github.com/RobertCNelson/omap-image-builder Jan 20 02:51:27 I guess it depends what you use regularly Jan 20 02:53:06 `file` is pretty up there in usage :) Jan 20 02:53:20 can't say I've used it .. but I'm no guru/hacker :P lol **** ENDING LOGGING AT Wed Jan 20 02:59:59 2016