**** BEGIN LOGGING AT Wed Jan 20 02:59:59 2016 Jan 20 03:00:08 `man` is missing too Jan 20 03:03:05 nooo .. I won't have it .. Jan 20 03:03:16 thats daft! Jan 20 03:03:44 althouguh .. trimming out the man pages too .. thats gonna be a small image .. lol ..even if they're bzipped Jan 20 03:07:14 not really Jan 20 03:07:17 # du -sh /usr/share/man Jan 20 03:07:19 16M /usr/share/man Jan 20 03:21:27 crikey lol Jan 20 04:48:11 hey ! Just a simple question. BeagleBoard is planning to participate in GSoC 2016, right ? Jan 20 04:51:55 ZeekHuge: probably Jan 20 04:54:19 kremlin : then why are the places like #beagle-gsoc and "beagleBoard Gsoc Google-Group" silent ? Jan 20 04:54:29 Trying to learn about BBB and device trees. It seems that the Bonescript function pinmode keeps me from having to use a device tree overlay. Is this true? Jan 20 04:55:07 adugenske: bonescript? Jan 20 04:55:10 care to link it Jan 20 04:55:31 http://beagleboard.org/Support/BoneScript/pinMode Jan 20 04:57:52 i think the pins already have to be muxxed to GPIO/whatever functions Jan 20 04:58:06 because this probably just interacts with the sysfs files Jan 20 04:59:41 Are you sure. I believe pinmode can actual set the pin mux. Jan 20 05:01:22 let's look at the source Jan 20 05:01:29 would you mind linking it? Jan 20 05:02:43 i found it: https://github.com/jadonk/bonescript Jan 20 05:02:49 https://github.com/jadonk/bonescript Jan 20 05:04:25 here's the function def: https://github.com/jadonk/bonescript/blob/915315ee796d13a03617f6f7a445b25c2f9d9f49/src/index.js#L78 Jan 20 05:04:50 ok, so Jan 20 05:05:25 this is setting pulll-up/down transistors, and input directions Jan 20 05:05:43 iirc, that is what you do when you write to the files in /sys/class/gpio/gpio1/ Jan 20 05:05:46 or whatever the path is Jan 20 05:06:08 your device tree will already have to have the actual pin locations set to GPIO (which they are by default) for those files to even show up Jan 20 05:06:56 Great. So it seems I don't have to fuss with device trees unless I do something escoteric. Jan 20 05:07:06 it seems so Jan 20 05:07:24 the *worst* you'd have to do would be something like adding the following line to /etc/rc.local: Jan 20 05:07:48 Nice. Interestingly, there doesn't seem to many folks using Javascript on their BBBs. I wonder why? Jan 20 05:08:04 echo BB-FOO-GPIO > /sys/class/devices/bone_capemgr.9/slots Jan 20 05:08:09 that path is wrong but you get the idea Jan 20 05:08:26 basically on boot you just export a simple overlay Jan 20 05:08:35 but you shouldnt have to do that because the default is to set most pins to GPIO Jan 20 05:09:49 kremlin Thanks Jan 20 05:09:56 no problem, good luck Jan 20 05:10:17 What do you use to program you BBB? Jan 20 05:10:30 what do you mean? Jan 20 05:10:43 Do you use Javascript, C++, python? Jan 20 05:10:43 i just export whatever overlay i need and write a c program to do everything from there Jan 20 05:10:46 ahh Jan 20 05:10:53 well right now, i'm working with the realtime chip Jan 20 05:10:59 so i can only write assembly :) Jan 20 05:11:02 my favorite Jan 20 05:11:08 Blah Jan 20 05:11:29 Have a good evening. Jan 20 05:24:06 you too Jan 20 05:37:29 kremlin: it's still a good idea to set the pinmux explicitly (although it would be nicer if linux knew the actual gpio -> pin mapping and configured it on exporting, though that wouldn't really be portable since some TI SoCs can map a gpio to more than one pin) Jan 20 05:40:07 and I think there's a C compiler for PRU, although that's obviously not usable if you need to rely on instruction counts for timing purposes Jan 20 05:50:54 zmatt: well, i feel like the cases where someone is using an am335x or OMAP or whatever TI chip and it's not a BBB are pretty slim Jan 20 05:51:09 i guess you also have to assume they are running the provided debian/angstrom images Jan 20 05:51:53 and unfortunately yeah, i have some pretty tight timing constraints here Jan 20 05:52:25 why unfortunate? it gives you the opportunity to have fun with PRU assembly! Jan 20 05:52:27 :D Jan 20 05:52:30 i'm trying to shoehorn this beagle into a prototype that will eventually nessecitate an FPGA Jan 20 05:52:40 oh pffft i love asm Jan 20 05:53:05 i'm just worried the PRU won't work properly for some reason or another Jan 20 05:53:19 well at least PRU asm is fairly decent Jan 20 05:53:24 and that sweet sweet 200MHz frequency will functionally end up like 50MHz Jan 20 05:53:28 yeah it's really not bad Jan 20 05:53:34 it's kind of a nice escape from ARM/x86 Jan 20 05:54:00 it's kind of insulting to ARM though to bin those two together like that Jan 20 05:54:03 reminds me of programming on my calculator in school Jan 20 05:54:09 err Jan 20 05:54:16 * zmatt does not touch x86 with a 10-foot pole Jan 20 05:54:27 hahaha Jan 20 05:54:35 i'll give you that, i'll take ARM over x86 any day ever Jan 20 05:55:18 and the PRU should not disappoint you as long as you keep in mind that loads and stores take more than one cycle Jan 20 05:55:36 (and loads/stores outside the subsystem take unpredictable time) Jan 20 05:56:04 yeah, i am really hoping there is an L1 cache Jan 20 05:56:41 or cache large enough to do more than just prefetch instrs. Jan 20 05:57:23 otherwise i am b o n e d since this stuff is super memory/IO heavy Jan 20 05:58:05 there's no cache whatsoever, since caches result in unpredictable timing Jan 20 05:58:47 (no instruction prefetch either, nor any need for it since it executes code only from a dedicated instruction SRAM) Jan 20 05:59:13 hi all; just trying to get off the ground and I am stuck. I updated the image to Debian 2015-11-12, and now bonescript says "permission denied" on various /sys/kernel/debug/omap_mux/* paths. There's nothing there but an empty "board" folder. I've tried triggering some external LEDs via shell, but nothing seems to be working. What am I missing? Jan 20 05:59:33 writes are posted at the subsystem boundary though Jan 20 05:59:41 zmatt: i am pretty sure you can run realtime kernels on any hardware Jan 20 05:59:54 for reads you'll want to team up with EDMA Jan 20 06:00:06 unless when someone said you can run QNX on x86 they meant that QNX can somehow bypass the cache or whatever Jan 20 06:00:09 kremlin: "realtime" typically does not mean 5ns-precision timing Jan 20 06:00:15 uhh Jan 20 06:00:24 to me realtime is like a kernel scheduling/realtime thing Jan 20 06:00:41 for stuff that absolutely cannot crash like airline autopilot software Jan 20 06:00:47 i could be dead wrong tho Jan 20 06:00:56 right, that still typically does not require 5ns-precision timing Jan 20 06:01:07 oh, yeah, it could be anything Jan 20 06:01:12 PRU *is* designed to give that Jan 20 06:01:32 i might be in luck after all Jan 20 06:01:34 then Jan 20 06:01:52 i gotta say Jan 20 06:01:56 that's however conditional on not making access outside the subsystem, since then all bets are off Jan 20 06:02:19 can't you just report every resource you might possibly need up front? Jan 20 06:02:48 so the scheduler can figure everything out before it runs anything and you don't have any heuristic stuff going on Jan 20 06:03:03 no. you can give PRU priority on the L3 interconnect and with EMIF but that still doesn't give predictable timing Jan 20 06:03:22 and in particular, reads will still take a "ping time" to the peripheral Jan 20 06:03:34 which is often about 150 ns Jan 20 06:03:50 (roughly) Jan 20 06:04:25 ah! gotcha Jan 20 06:04:53 i forgot that this PRU is secondary to an actual computer that is not realtime Jan 20 06:06:02 that is interesting about the cache. i totally did not know that a cache between memory/cpu would unravel realtime systems Jan 20 06:06:05 it's not "secondary" really, it's just the time it takes to access something distant Jan 20 06:06:07 but i can totally see how that makes sense Jan 20 06:06:33 yeah it's why for example IVA uses arm9 with tightly-coupled memory but no cache Jan 20 06:06:41 it's not like a coprocessor but it's pretty tightly coupled to the am3358 Jan 20 06:06:51 IVA? Jan 20 06:06:57 arm *9*? Jan 20 06:07:09 arm928e-s iirc Jan 20 06:07:39 oh waht Jan 20 06:07:42 these are older chips Jan 20 06:07:54 IVA-HD is the video en-/decoding accelerator on various TI chips (but not the am335x) Jan 20 06:07:55 that's not how numbers work. Jan 20 06:08:14 no it's ARM architecture v5, before the Cortex series Jan 20 06:08:17 ARM8 is the brand spankin new 64 bit arm chips you can't even get a breakboard for (as a hobbyist) Jan 20 06:08:29 that's ARM architecture v8 Jan 20 06:08:30 so it isn't armv9 Jan 20 06:08:32 not ARM8 Jan 20 06:08:34 gotcha Jan 20 06:09:01 (the ARM8 is a pretty obscure cpu series inbetween the classic ARM7 and ARM9 series) Jan 20 06:09:41 ARM10 was also obscure... I guess even numbers were bad luck Jan 20 06:10:11 ARM11 is e.g. in the omap2 and rpi1, then came the Cortex-A series Jan 20 06:10:20 i sometimes forget how old of a company acorn is Jan 20 06:11:06 uhuh, I have a datasheet from 1990, it's funny to read :D Jan 20 06:12:42 anyhow, PRU isn't really coupled to the rest of the am335x any tighter or looser (a rare occasion for this to be correct spelling) than the rest of the am335x Jan 20 06:12:45 i'm no expert or anything but it seems like ARM has some really good ideas over x86 Jan 20 06:12:56 things x86 could never do since they are saddled with the burden of backwards-compat Jan 20 06:13:15 hmm, ok. Jan 20 06:13:32 yes, ARM does in fact clean up now and then... in general, deprecated in some architecture version means it may actually be removed in the next one Jan 20 06:16:01 it is good that there are two companies that have two opposing philosophies w/r/t backward compat Jan 20 06:16:20 like, jesus, i do *not* want to have to buy a new CPU/motherboard every 2 years so i can keep up to date with software Jan 20 06:17:04 we can barely manage catering to both a 32 bit & 64 bit version of the same instruction set, like Jan 20 06:17:29 imagine if we had now 9 significantly used ones, bleh Jan 20 06:17:38 but ARM allows for actual innovation Jan 20 06:18:00 and not still having to support 26-bit addressing :P Jan 20 06:18:09 they don't have the billion dollar fabs that can print circuits down to the planck length but at least their business model is cool Jan 20 06:18:16 uh oh Jan 20 06:18:26 what on earth was 26 bit Jan 20 06:18:28 lisp machine? Jan 20 06:18:29 arm Jan 20 06:18:34 oh, hah Jan 20 06:18:37 CPSR and PC were the same register Jan 20 06:18:46 that's really interesting Jan 20 06:18:53 they dodged a bullet there, not keeping that trend Jan 20 06:18:54 bottom two bits cpu mode, top 6 bits flags and I/F Jan 20 06:19:23 iirc that is sort of the same sequence used now Jan 20 06:19:33 yes the bit positions are still the same Jan 20 06:19:46 i know one end of the register had bits that set supervisor/protected/whatever mode Jan 20 06:20:15 the fault modes also all have the bottom two bits set (faults were previously taken in supervisor mode) Jan 20 06:20:35 i am very familiar with reading the fault bits :( Jan 20 06:22:11 my forth (that I still need to port to the am335x, sigh) gives pretty nice fault decoding Jan 20 06:23:26 ( http://gerbil.xs4all.nl/fault.png ) Jan 20 06:29:04 hoo boy Jan 20 06:29:10 i could have used that Jan 20 06:29:43 my debug method for my last project was to load one or two values that indicated what was going on in the code into R1/R2 and then immediately send a breakpoint instruction Jan 20 06:29:57 and then read the firmware register dump over serial Jan 20 06:30:03 fun Jan 20 06:30:13 aye Jan 20 06:30:18 i learned a whole whole lot doing that Jan 20 06:30:20 I also like how u-boot traps fault and... reboots Jan 20 06:30:22 -.- Jan 20 06:30:30 hah yeah Jan 20 06:30:31 very convenient when poking around Jan 20 06:31:26 it'd be nice if there was a firmware debugger that launched on kernel panic a la ddb(1) on openbsd Jan 20 06:32:15 there's kdb but I don't really know anything about it Jan 20 06:32:39 kdb would be awesome, but it's purposefully left broken here :( Jan 20 06:32:50 ?? Jan 20 06:33:05 kdb is like the version of gdb that runs on panic, right? Jan 20 06:33:23 see "but I don't really know anything about it" Jan 20 06:33:36 oh right whoops Jan 20 06:33:46 i am almost certain that is what it is Jan 20 06:33:54 and lots of devs here do not really like gdb Jan 20 06:34:25 they would rather people tend to use their own genuinely good debugger that was written targetting this specific os Jan 20 06:34:27 my forth also didn't have a debugger, though at least it trapped faults and after reporting them returned to the interpreter Jan 20 06:34:35 which i guess is fair Jan 20 06:34:47 aye yeah, at least the reboot times on these things are pretty small Jan 20 06:35:14 ("interpreter" ... it actually compiled to a temp buffer and executed it, but details) Jan 20 06:35:16 with the env vars you can save on the EEPROM or whatever, you just learn to type run $bsd or whatever at u-boot and can get away with just a reg dump on panic Jan 20 06:35:27 oooh Jan 20 06:35:34 that is a pretty clever way of doing it Jan 20 06:35:50 yeah, most forths don't allow you do use control statement on the interpreter, mine does Jan 20 06:35:55 *statements Jan 20 06:36:03 i'm not familiar with forth except for this PROM bootloader thing my powerpc apple server uses Jan 20 06:36:10 open firmware Jan 20 06:36:13 yep Jan 20 06:36:22 \o/ Jan 20 06:36:30 it is pretty slick Jan 20 06:37:02 i thought it was just going to be like a cut-down BIOS equivalent & the forth usage message scared me away Jan 20 06:37:06 but i should take a look at it sometime Jan 20 06:37:10 forth is a neat language Jan 20 06:39:39 yeah, even though our dm814x-based board has been shelved as an expensive mistake, I still use it whenever I want to examine the behaviour of the interconnects or some peripheral in more detail (the am335x is a very close relative of the dm814x) Jan 20 06:39:53 forth on the bare metal is quite convenient for that Jan 20 06:41:42 there is no doubt that a lot of room for innovation lies in places like that Jan 20 06:42:32 low level debugging can be like building a sandcastle with buckets or it can be like building a snadcastle with tweezers Jan 20 06:42:49 depending on stuff like that Jan 20 06:43:15 well, innovation... more like filling the gaps in the TRM :P (or discover when it's talking out of its ass) Jan 20 06:44:02 you certainly need to be really good at what you are doing to implement a system like that, though Jan 20 06:44:18 it is probably work nobody wants and manufacturers can get away with by skimping or taking the u-boot route Jan 20 06:45:16 I liked doing baremetal coding in Forth Jan 20 06:46:10 I still like the amount of functionality I had working while running out of SRAM... I had DDR3 init code, just didn't have any use really for all that RAM Jan 20 06:47:18 otoh u-boot doesn't manage to fit itself in 109 KB and therefore uses an intermediate loader... -.- Jan 20 06:49:12 having linux is a lot friendlier to coworkers though Jan 20 06:50:35 hahaha, yesss Jan 20 06:50:48 stuff like that makes me think 1ms DRAM is slow Jan 20 06:51:09 that you don't have to haphazardly access a whole row when you only need one byte or whatever Jan 20 06:51:32 and yeah, u-boot is huge Jan 20 06:51:36 kind of obnoxiously so Jan 20 06:52:07 but i'm not sure what the alternative to it is, i mean, open source people cannot write a PROM for every flavor-of-the-month SoC Jan 20 06:52:48 I'm still working on a replacement bootloader, but it's not a high priority and I don't have much time for it so progress is slow Jan 20 06:54:45 is it specific to anything or are you trying to make it one that'd be easy to bootstrap new chips with Jan 20 06:56:43 I'm specifically targeting the BBB currently though porting it to other boards based on am335x-or-sufficiently-similar shouldn't be hard Jan 20 06:57:12 hmm, good choice Jan 20 06:57:27 it would also be pretty easy to go from am335x -> OMAP3/4 Jan 20 06:58:47 well there are still significant differences... not that it matters much since the omaps are fairly dead (except for their reincarnation in the monster Vayu, aka dra7xx/am57xx) Jan 20 06:59:02 Long live OMAP! Jan 20 06:59:04 shucks, i didn't know that Jan 20 06:59:23 long live TI's reference manual quality Jan 20 07:00:17 yeah although I can complain plenty about their docs, they're still much better than what's publicly available for most other SoCs Jan 20 07:00:29 morning ds2 Jan 20 07:01:50 I still want a copy of the real omap5 TRM though (that TI accidently put on their site, briefly but long enough for at least some people to notice and download) Jan 20 07:01:51 there is at least some effort to truly try and help you there Jan 20 07:01:57 zmatt: morning Jan 20 07:02:02 but i agree some of the L3/L4 interconnect stuff confuses the hell out of me Jan 20 07:02:14 zmatt: I rather have the omap5 silicon ;) Jan 20 07:02:53 ds2: I'd rather have the TRM, since it includes full IVA-HD docs, which is useful for many more SoCs than just omap5 Jan 20 07:03:14 is the IVA-HD new to the 5? Jan 20 07:03:17 nope Jan 20 07:03:26 then why not look for it in old docs? Jan 20 07:03:28 omap4 / omap5 / dm81xx / vayu Jan 20 07:03:33 because it's not in any public docs Jan 20 07:04:21 little birdies fly around all the time :D Jan 20 07:05:44 I often collect them Jan 20 07:05:47 $ find ~/docs/ti -name '*.pdf' | wc -l Jan 20 07:05:47 1229 Jan 20 07:06:44 I'd be more interested in a detail doc for the SGX stuff Jan 20 07:06:55 amen Jan 20 07:07:13 no idea how much is included in that "full" TRM Jan 20 07:07:18 I want it. Jan 20 07:07:19 :P Jan 20 07:07:23 it is such a nice little super computer Jan 20 07:08:06 off topic complaint - @#$$!$#!$!%#!$#!@#!@#!@#!@#!@#! android apps that depend on checked in generated files that gets nuked by clean but not rebuilt Jan 20 07:08:18 I hate userland stuff so very very much Jan 20 07:09:18 oof, bedtime. goodnight Jan 20 07:09:50 ds2: lol, nicely done Jan 20 07:10:31 I don't really.. understand.. checking in generated files Jan 20 07:12:25 nite kremlin Jan 20 07:18:51 zmatt: took me a while to figure out why ant clean breaks things but git reset --hard fixes stuff :( Jan 20 07:21:25 next time don't use make clean but git clean -dqfx Jan 20 07:21:43 removes all non-versioned files Jan 20 11:08:03 hello, anyone had trouble with powering BBB from powerbank through DC jack? Jan 20 11:08:47 I can power it w/o problem through miniUSB, but through jack it does not boot Jan 20 11:08:48 maciejjo: someone recently tried powering it (not sure which connector) and failed as the battery pack sensing was fighting with the TPM Jan 20 11:09:37 maciejjo: you need to make sure it can provide the peak surge current and stays on Jan 20 11:10:12 adding a sizeable capacitor might help to smooth things out Jan 20 11:11:00 ok, worth trying, thanks Jan 20 11:12:36 what suprises me is when I use USB<->miniUSB it works, but USB<->DC jack does no Jan 20 11:13:07 checked voltage and polarity? Jan 20 11:13:50 maciejjo: what exactly happens? Jan 20 11:16:34 polarity is OK, I check voltage on USB voltometer and it indicates 5.02V Jan 20 11:17:15 port is rated 2.1A so it should not be a problem Jan 20 11:17:21 "should" Jan 20 11:17:41 if it's any like the cheap chinese crap I've seen, I wouldn't trust this further than I can throw it Jan 20 11:17:52 ah yes .. power banks need a consistent load Jan 20 11:17:58 bbb ain't gonna be any good for that Jan 20 11:18:07 at least not during boot Jan 20 11:18:19 wonder if it would work to jump start it Jan 20 11:18:34 you could plug -both- then pull the usbout lol Jan 20 11:18:44 yes Jan 20 11:18:52 once booted it should provide a reasonably stable load Jan 20 11:18:53 usb and dc charging are very different 'loads' for a brick Jan 20 11:19:29 usb is supposed to be limited to 500mA Jan 20 11:19:30 also the BBB limits cpu scaling during USB boot mode Jan 20 11:20:13 tbr.. is it able to 'tell' through the pmic i2c? Jan 20 11:20:16 if the voltage drops significantly with higher load, that will most likely make the TPM go "hell nope!" and shut things off Jan 20 11:20:50 veremit: not sure where the info comes from, but booting powered by usb will limit max cpu freq Jan 20 11:21:15 tbr.. so I've heard .. uboot must be querying it Jan 20 11:21:51 there are a few moving parts, hence why I asked maciejjo to provide details about what happens Jan 20 11:22:03 tbr: oh very definitely :) Jan 20 11:22:12 as "doesn't boot" really tell enough Jan 20 11:22:38 serial is dead on DC jack powering Jan 20 11:22:47 PWR led is on Jan 20 11:22:49 usb or debug port? Jan 20 11:22:54 usb won't come up for at least 2min Jan 20 11:22:55 debug Jan 20 11:22:59 ah Jan 20 11:23:26 yeah its latching up on start .. if none of the other leds are blinking Jan 20 11:23:39 yes, no activity on other leds Jan 20 11:23:57 my guess is that the USB battery thing doesn't provide stable supply in "sleep mode" and thus the TPM doesn't like it and doesn't boot Jan 20 11:24:15 maciejjo: if the battery has a button, try waking it up before attaching the BBB Jan 20 11:24:28 but it does provide stable supply over USB? Jan 20 11:24:44 usb is a limited supply Jan 20 11:25:23 battery has one button to turn it on, I think I tried plugging before and after turining on Jan 20 11:25:49 I can verify later, I do not have the hw on me right now Jan 20 11:26:48 >,< Jan 20 11:26:59 … Jan 20 11:27:42 sorry, I am at work, just wanted to know if maybe I am doing something obviously wrong Jan 20 12:33:09 tbr: if the pmic dislikes the situation it would shut off Jan 20 12:33:34 power led on means the pmic has no issue with things Jan 20 12:34:10 zmatt: then you should see uboot at the very least on the console? Jan 20 12:34:49 tbr: also the cpu freq scaling applies only to the bbw, on the bbb it just raises the max usb current and goes ahead anyway Jan 20 12:35:09 veremit: I would expect at least some kind of output yes Jan 20 12:35:51 mkay Jan 20 12:36:22 it might also be informative to try powering up with S2-button held (but no sd card present), that should give periodic CCC on the serial console Jan 20 12:36:47 possibly flow control on the serial terminal app .. lol. Jan 20 12:37:03 verifying the console works is a good idea obviously Jan 20 12:37:19 yup Jan 20 12:38:23 but it's odd for powering through usb to work but through dc plug to fail Jan 20 12:39:37 those circuit are virtually identical Jan 20 12:39:42 *circuits Jan 20 12:41:06 anyhow, got to kick myself to work Jan 20 12:42:49 hehe Jan 20 13:21:42 Hey fellas! Jan 20 13:22:09 Hey fellas! Jan 20 13:22:42 Any working on mSATA here? Jan 20 13:22:49 *anyone Jan 20 13:25:30 with what? Jan 20 13:28:40 I work on adding SATA to my rpi headers Jan 20 13:30:47 av500 .. oo what interface? Jan 20 13:30:54 h/w Jan 20 13:31:04 not usb .. Please... :/ Jan 20 13:31:18 bitbang Jan 20 13:31:27 no way! awesome! Jan 20 13:31:37 it's called vSATA Jan 20 13:31:42 very SLOW ATA Jan 20 13:31:45 how fast can it manage? Jan 20 13:31:48 hahaha Jan 20 13:31:50 right Jan 20 13:32:11 you can always bitbang ATA and run that via an ATA/SATA converter Jan 20 13:32:33 are there enough ios for a 16 bit bus?! Jan 20 13:32:46 I2C GPIO expander? Jan 20 13:32:53 ick lol ook Jan 20 13:33:00 then you only need to bitbang I2C Jan 20 13:33:15 spi might be slightly better .. i2c is fairly slow Jan 20 13:33:38 SPI is used to run the LED pixel chain, sorry, priorities.... Jan 20 13:33:45 damn .. ofc . Jan 20 13:34:08 you can't push the pixel chain onto i2c .. no scratch that .. too critical ;D Jan 20 13:40:43 banged bits are best bits Jan 20 14:39:35 hi guys, after a while of abstinence from my BBB.. we have done now some test with an indusrty grade mikrosd. the problem is that my beagle does not boot now after 600 testruns. Jan 20 14:40:51 i've written a onl liner which writes an 1GB file to the disk. during the writing of this file i start my normal software an set an output to high. this is detected from an PC software which switches of the power Jan 20 14:42:29 normal sdcards are dead if this happens, the industry card is made to survive this. Now after 600 cycles the bealge dos not boot. Jan 20 14:43:25 I've analyzed the card but cannot find the problem, all files seem to be ok, (I did a binary compare of all files, only logfiles differ and of course the testfile i write Jan 20 14:44:13 so log talk, one question. can anybody explain me how the bbb boots from sd? how dowes it work? Jan 20 14:46:10 the console stops after writing this: "Uncompressing Linux... done, booting the kernel." Jan 20 14:47:20 nothing happens. but if i put in a working card the console output is the same (booting continues, with no output ) I've set optargs to quiet Jan 20 14:48:05 so is it detected from bbb that it should boot from sd? hast the emmc anything to do with it? Jan 20 14:49:41 if you don't have S2 shorted, then it will try to boot eMMC first and then try SD Jan 20 14:53:16 what do you mean by s2? the boot switch? it is not triggered but normally successfully boots from sd Jan 20 14:53:45 is the boot switch available on expansion header? Jan 20 14:54:13 did you wipe eMMC or how are you forcing SD boot? Jan 20 14:54:47 no emmc is in "manufacturer state". i did not change anything on emmc Jan 20 14:55:36 then you are probably abusing the original u-boot and mlo Jan 20 14:56:00 did you change kernel version or something like that recently? Jan 20 14:56:05 this could be, but it works in 99+ % of the times Jan 20 14:56:54 no I have build 3.8.13 kernel, this runs on sd. I didn't touch the emmc. plug in sd and apply power, thats it Jan 20 14:57:06 I'd recommend removing MLO from eMMC and migrating to an up to date MLO/U-Boot on SD Jan 20 14:57:22 or tie the S2 Jan 20 14:57:27 to force SD boot Jan 20 14:57:41 the pins might be on the expansion header, not sure Jan 20 14:57:45 to repeat my question: is the s2 on expansion header? Jan 20 14:58:32 I. do. not. know. Jan 20 14:58:33 to can I short it in hardware all time? Jan 20 14:58:39 consult the SRM or the schematics Jan 20 14:58:58 searching in the srm... Jan 20 15:02:21 I've read "if the emmc is amty it continues to boot from sd, followed by serial..." so is it possible to wipe emmc, or delete the MLO from it? Jan 20 15:02:37 sorry: ...if the emmc is empty... Jan 20 15:03:05 BennyB_: you can hardwire the SYSBOOT pins with some pull up/down resistors to force the boot order behaviour that you want Jan 20 15:04:38 BennyB_: the various meanings of the sysboot pin config are listed in the am3xxx TRM for sure, and maybe in the SRM too. Jan 20 15:05:10 ok. will it work if the pin is all the time high to boot from sd? Jan 20 15:05:36 if 'the pin' correspond to the proper sysboot config, then yes. Jan 20 15:06:44 i'll hav e a look into the TRM. do you have an URL of it or do I have to ask big G? Jan 20 15:07:00 you can pay me to ask big g for you? Jan 20 15:08:10 i have here the longest "praline in the world" (duplo) right on my desk, but it is hard to send it by wire ;-) Jan 20 15:08:21 'no deal' Jan 20 15:08:46 Hi guys, could anyone tell me if this is correct syntax for creating a multi LUN mass storage device? I'm trying to build a FIT image that exports on-board storage, eeprom, and my lcd's display memory. Jan 20 15:08:47 modprobe g_mass_storage file=/dev/mmcblk0,/sys/bus/i2c/devices/0-0050/eeprom,/sys/class/hd44780/lcd/ddram iSerialNumber=42 iManufacturer=Circuitco iProduct=BeagleBone-Black Jan 20 15:10:45 here is the TRM, for completness of log files: http://www.ti.com/lit/pdf/spruh73 Jan 20 15:11:18 BennyB_: TY Jan 20 15:11:31 ? Jan 20 15:12:05 'thank you' Jan 20 15:12:17 ok Jan 20 15:15:54 TRM is some kind of hard stuff, I do not understand anything.. Jan 20 15:17:34 but i found out that in SMR is part of it included, but this I also do not understand. forgive me my nescience Jan 20 15:27:01 LetoThe2nd: I simply don't get it. where is SYSBOOT located? on P8/P9 expansion header I cannot find it Jan 20 15:29:59 ah, it seems it is some combination of the pins LCD_dataXXX Jan 20 15:32:01 but I don not get the clue from SRM which combination, and what does this mean? "" Jan 20 15:32:02 If you choose to override these settings, it is strongly recommended that you Jan 20 15:32:04 gate these signals with the SYS_RESETn signal. Jan 20 15:35:58 BennyB_: If you use those pins for something other than boot control, use a tristate buffer between the pin and the outside device(s) and tie the enable pin of the buffer to the SYS_RESETn signal so that the device(s) are disconnected from the pins during boot. Jan 20 15:36:08 Otherwise, you will cause all manner of boot issues. Jan 20 15:36:54 i use hdmi, seems this pins are also used for it. Jan 20 15:37:03 Well, yeah. Jan 20 15:37:15 wouldn't it be easier to kill emmc? Jan 20 15:37:46 How do you mean? Jan 20 15:38:25 the srm says if emmc is empty it boots from sd. so i could just clear emmc and everything should work? Jan 20 15:39:32 Why do you not try it and report back with your findings? Jan 20 16:12:17 sorry, I was away.. I think it is a little bit complicated and the cirurit board is already done so a softwre only solution would be better. single pin it would be possible to solder it, but drive many pins maybee even with some additional resistors and so on is too much Jan 20 16:13:18 I will try it maybee but cannot promise it. Jan 20 16:13:41 I'll have to leave now. bye Jan 20 16:41:52 which part of "nuke mlo" did he fail to understand? Jan 20 16:43:38 dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=2 .. should do it Jan 20 16:44:45 clearing 64 bytes at offset 128k should do it Jan 20 16:47:24 zmatt: well ain't that precise :p Jan 20 18:07:54 i am really loving the PRU cores on the bbb Jan 20 18:08:11 it would be a great tool for teaching people assembly Jan 20 18:08:43 the ISA is easier to deal with than MIPS, and you get *90* registers Jan 20 18:09:12 and no pipelining/delay slots/etc to confuse people Jan 20 20:02:14 got questions regarding power supply... I need to power the BBB rev 3 and a 7200rpm 2.5" hard drive that lists a power requirement of 800mah at 5v Jan 20 20:02:47 i was using a 1 amp 5v adapter that came with a cell phone, but I assume it won't be enough with the hard drive, so I tried out a 2 amp Jan 20 20:03:19 the 2 amp dc adapter reads out a voltage of about 5.4v, but I think the frequency is wrecked on it. I don't think it works and the BBB won't start up Jan 20 20:04:16 I checked the voltage on the 1amp DC power supply (works with BBB), and it actually came up as 6.8v Jan 20 20:04:30 SOunds like an unregulated supply. Jan 20 20:04:41 Probably a bad idea to continue using i. Jan 20 20:04:51 k Jan 20 20:05:36 A *DC* supply should have no "frequency", so I am not sure what you mean about your 2A supply. Jan 20 20:06:09 agmlego, there is an LED on the 2A supply and it flickers, which should not happen Jan 20 20:06:48 Are you sure? Maybe that LED is supposed to flicker? Jan 20 20:07:22 well the BBB won't start up with it, and it reads 5.4V, so... something is wrong with it. Jan 20 20:08:01 What does it measure when you have it attached to the bone? Did you check the barrel plug's polarity? Jan 20 20:08:17 inside of the barrel is positive Jan 20 20:08:25 i'll connect it to the bone and measure it Jan 20 20:11:30 5.8 to 6.2 connected to the BBB Jan 20 20:11:47 it's not consistent. just jumps in that range of 5.8 to 6.2 Jan 20 20:11:59 Yeah throw that one away too. Jan 20 20:12:07 The bone will break if you give it more than 5V. Jan 20 20:13:41 alright. is there a way to do a health check via USB or should I assume it is alright since I can still SSH into it? Jan 20 20:14:00 i'll have to order a regulated 5v of 2A Jan 20 20:15:12 ...if you can SSH into it, it is botted and running. Jan 20 20:15:16 *booted Jan 20 20:15:32 I recommend one of the power adapters from Adafruit or Sparkfun. Jan 20 20:15:32 yeah i'm just thinking individual component damage. anyway, nevermind Jan 20 20:15:37 ok Jan 20 20:55:18 is the "raw mmc boot header" 512 bytes or less? Jan 20 21:06:46 yates: partition table is usually 512 bytes iirc Jan 20 21:09:17 Anyone have a good way to extract files from a uboot fit image? Jan 20 21:09:36 mkimage? Jan 20 21:09:59 I'm not seeing an extract option, just a list... Jan 20 21:12:16 ah, dumpimage... Jan 20 21:12:21 but did it go mainline.. Jan 20 21:12:39 ./dumpimage -T flat_dt -i CONTAINER.ITB -p INDEX FILE Jan 20 21:13:58 hmm, I was just trying to use tools in the u-boot-tools debian package, but it looks like that hasn't made it in there yet. Jan 20 21:15:00 it is built by default... http://git.denx.de/?p=u-boot.git;a=blob;f=tools/Makefile;h=1382b0562e569950f994a1e9e83f2d0652218804;hb=HEAD#l55 Jan 20 21:15:26 rcn-ee.. do you know much about the ti adc/tsc driver? Jan 20 21:15:43 i know people like the version in 3.8. .;) Jan 20 21:15:59 heh .. is it broken in 4.x ? Jan 20 21:16:10 veremit: what about it? Jan 20 21:16:21 abferm, it should be there: https://anonscm.debian.org/cgit/collab-maint/u-boot.git/tree/debian/u-boot-tools.install#n4 Jan 20 21:16:23 wmat: someone was asking me about it Jan 20 21:16:30 http://processors.wiki.ti.com/index.php/Sitara_TSC_ADC_Driver_Overview?keyMatch=adc%20tsc%20driver&tisearch=Search-EN Jan 20 21:16:46 veremit, i think it's "touchy" at the moment in 4.1... Jan 20 21:16:48 specifically in teh 4.x series Jan 20 21:16:54 it is Jan 20 21:17:05 rcn-ee: *groan* Jan 20 21:17:15 might just be a bad touchscreen silkscreen...... Jan 20 21:17:17 rcn-ee: did you get your oPi yet? Jan 20 21:17:45 the other dot-i cross-t question was whether bb-view drivers were in the default debian image these days ... Jan 20 21:17:49 veremit, u-boot works, waiting for the kernel's 4.5-rc1 for arm.. Jan 20 21:18:16 rcn-ee: for o-pi or other fun stuff? Jan 20 21:18:18 veremit: they could try http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide for the 4 series Jan 20 21:18:20 veremit, i need to look at those too.. Jan 20 21:18:40 wmat: I think I looked at one of the TI sites Jan 20 21:18:49 * wmat needs to get back to this stuff Jan 20 21:18:50 thanks ^^ Jan 20 21:20:26 hai Amynka :) hehe Jan 20 21:20:37 veremit: hai Jan 20 21:37:15 hmm, has anyone compared the I/O speeds of the bbb's emmc nand chip vs. external SD? Jan 20 21:37:37 assuming one of those fancy SDXC UH2 cards Jan 20 21:38:02 rcn-ee: I'm gettin the 'connection is untrusted' on your eewiki site currently .. Jan 20 21:38:19 sdxc is a card size, not a speed Jan 20 21:38:49 uhs is not supported by the am335x Jan 20 21:38:53 yeah, but only SDXC cards go up t- Jan 20 21:38:56 oh Jan 20 21:38:58 :( Jan 20 21:39:17 you'd think the on-PCB one would be better, i guess i should run some tests Jan 20 21:39:20 "The Ultra High Speed (UHS) bus is available on some SDHC and SDXC cards." Jan 20 21:39:26 eMMC has an 8-bit data bus Jan 20 21:39:28 SD 4-bit Jan 20 21:40:14 note however there are two different eMMC chips in circulation for BBB rev C, kingston and micron... the micron is noticably slower, especially writes Jan 20 21:40:54 afaik eMMC writes are bottlenecked by the chip, hence a high-quality SD card might still beat them. reads are bottlenecked by the bus Jan 20 21:41:47 i'm aware of the kingston/micron things :) http://marc.info/?l=openbsd-cvs&m=144698470923298&w=2 Jan 20 21:41:52 my first commit that got into kernel Jan 20 21:42:11 (i'm ian) Jan 20 21:42:23 fixing that was a p a i n Jan 20 21:43:32 I also still want to do some eMMC tests... in my copious spare time :P Jan 20 21:44:31 kremlin, sdxc vs onboard: https://paste.debian.net/366867/ Jan 20 21:44:41 i really do not like how the NAND chips in pretty much every phone are eMMC Jan 20 21:44:53 kremlin: it is understandable though Jan 20 21:44:53 we could have been completely done with MMC and moved on to just SD if not for that Jan 20 21:45:03 oh that Jan 20 21:45:10 I think eMMC and SD have diverged considerably Jan 20 21:45:49 my main gripe with eMMC is the ton of one-time-programmable settings... very developer-unfriendly Jan 20 21:45:56 MMC stuff is really good at consistently diverging Jan 20 21:46:10 oh like stuff they flash on at the fab? Jan 20 21:46:12 well SD is an incompatible branch of MMC, not other way around Jan 20 21:46:21 no, it's left unprogrammed Jan 20 21:46:33 oh Jan 20 21:47:18 but the combination of "OTP" and "soldered-on BGA" is not exactly inviting for experimentation Jan 20 21:47:46 aye Jan 20 21:47:51 im knee deep in BGA hell right now Jan 20 21:48:20 I also sorely miss a "disallow any OTP programming until next power cycle" bit Jan 20 21:49:02 for most OTP settings the only way to prevent programming is by programming them Jan 20 21:49:29 I know its the wrong answer for what you're trying to do, zmatt, but .. wrong technology lol. otp is just that .. you just live with it. if you dont' like it .. pick another part. Jan 20 21:49:50 why bother typing that Jan 20 21:49:54 veremit: except it's not actually OTP, it's just stored on flash and made OTP by the firmware's refusal to reprogram it Jan 20 21:50:08 rcn-ee: ever get eSATA on the bb-x15 working with mainline? Jan 20 21:50:23 veremit: (afaik) Jan 20 21:50:28 zmatt: then its immaterial .. since it's effectively otp regardless .. unless you ahve some ability to alter firmware or efuses.... Jan 20 21:51:16 veremit: doesn't mean it's annoying as hell that it's specified like this Jan 20 21:51:20 *it isn't Jan 20 21:51:27 double negation, blah :P Jan 20 21:51:31 rcn-ee: the next 4.4 uploaded to debian should have usb working, so we're making progress ... esata is the main thing i'm lacking now Jan 20 21:51:43 zmatt: design your own parts lol. Just sayin .. gotta work with what you got ;) Jan 20 21:51:46 i can get by on a usb-sata adapter, for a while, at least. Jan 20 22:11:48 rcn-ee: hey, were you the guy that made the BBB debian minimal install images? Jan 20 22:12:12 minimal, maximal, all shapes and sizes Jan 20 22:12:32 i have to ask Jan 20 22:13:26 why he elected to remove posix utilities like file, man, make Jan 20 22:13:47 but kept wget and locate and json parsing tools are left untouched Jan 20 22:14:29 I think I linked you the build scripts kremlin .. but maybe rcn-ee can shed light on the lack of 'man' lol Jan 20 22:14:44 i must have missed them Jan 20 22:15:44 hold up .. I'll dig the git out again. . Jan 20 22:15:51 i can scroll up, no worries Jan 20 22:16:23 kremlin: https://github.com/RobertCNelson/omap-image-builder Jan 20 22:16:51 might need to dig into those a bit Jan 20 22:17:10 but I'm lead to believe there's some list(s) of packages there Jan 20 22:17:49 im going to dig Jan 20 22:18:17 but i am praying that i somehow made a egregarious mistake somewhere Jan 20 22:21:09 kremlin, mimimal <-> gigantic.. ;) all sizes.. Jan 20 22:21:42 rcn-ee: i've very curious. why did you sack the mandb and a bunch of POSIX utilities? Jan 20 22:22:02 also: please tell me you didn't do that & somehow i screwed my image up horrifically Jan 20 22:22:19 vagrantc, sata is broken on mainline too.. pipe3 has to be a module otherwise it doesn't boot.. Jan 20 22:23:03 kremlin, the "bare" had a 128Mb nand target. ;) Jan 20 22:23:16 so man got sacked. ;) Jan 20 22:23:28 but not locate or json tools or dbus? Jan 20 22:24:22 kremlin, locate shouldn't be there either... Jan 20 22:24:30 it was basicly perl/dpkg/apt... Jan 20 22:24:34 i might have pulled it from a package Jan 20 22:24:42 i am about to install it again, ill let you know Jan 20 22:24:53 by the way, thanks! Jan 20 22:26:12 Sorry guys, but I'm not a huge fan of your image builder. I need to strip all the proprietary information out of the one we use here at work and publish it. Jan 20 22:26:44 abferm: have you seen rcn's own site at eewiki.net ? Jan 20 22:26:46 what are you doing using a beaglebone in a professional setting? Jan 20 22:26:53 kremlin: it happens lol Jan 20 22:27:12 kremlin: telemetry devices Jan 20 22:27:16 abferm, i did the same thign to rootstock. ;) fork away! ;) Jan 20 22:27:23 more so with Pi's too Jan 20 22:28:10 abferm, it initial started as a script to remember, what commands i called debootstrap with. ;) Jan 20 22:28:46 rcn-ee: mine uses an ansible playbook with the chroot connection method Jan 20 22:29:03 could be worse .. coule be buildroot lol :D Jan 20 22:29:46 not beaglebone specific, it can be used to produce viable root filesystems for any architecture you have qemu support for. Jan 20 22:30:11 qemu-debootstrap ;) Jan 20 22:30:21 rcn-ee: you mean pipe3 can't be built as a module? Jan 20 22:31:04 vagrantc, no it it needs to be a module in 4.4.0, otherwise the x15 locksup on bootup (before serial even comes alive).. pain int eh but to debug.. Jan 20 22:32:06 Hi, does anyone know what software the brd/dsn hardware design files is compatible with? Trying to verify connector layout and pinout for a baseboard... Jan 20 22:32:11 anyone have any idea why I get this error with a fit image based on the mainline 4.1.15 kernel? modprobe: 'kernel/drivers/usb/gadget/legacy/g_mass_storage.ko': No such device Jan 20 22:33:25 rcn-ee: in the debian packages, it was definitely compiled as a module, and it eSATA still didn't work Jan 20 22:33:53 or should i say Debian packages. :) Jan 20 22:34:04 vagrantc, yeap... i see that too... esata is broken on 4.4.0 Jan 20 22:34:13 (mainline with now patches.. omap2plus) Jan 20 22:35:44 not sure what kernel version the debian kernel team plans to ship, but hopefully it will get mainline support soon enough to at least backport Jan 20 22:36:10 * vagrantc still hasn't gotten a fan set up, so still hasn't set it up as a build daemon yet Jan 20 22:36:43 Oh, sorry, forgot to mention i was referring to the X15 hardware design format Jan 20 22:37:02 kjetilh, i'd wait another 2 months, till rev b comes out.. ;) Jan 20 22:37:18 (or contact those workign on it directly, if you have those contacts).. Jan 20 22:37:24 rev a failed fcc... Jan 20 22:37:33 wow Jan 20 22:37:45 "spread spectrum" Jan 20 22:37:52 Yes, but the connector placement will probably stay the same or close to it. I'm just trying to get a head start on a preliminary baseboard layout Jan 20 22:38:03 kjetilh, baseboard is the same... Jan 20 22:38:27 the current measurement circuit looped over the hdmi has been ripped out.. (#1 cause of fcc failure) Jan 20 22:39:48 why does the fcc care about that? if you don't mind my pestering Jan 20 22:39:57 ok, but no clue as to what software is used for hardware design? Jan 20 22:40:35 I've seen OrCAD used in the past, but my OrCAD doesn't like the DSN file. Jan 20 22:41:05 in past beagles, that is... Jan 20 22:41:48 or if gerber files exist, they would do the trick for me Jan 20 22:46:00 kremlin, bb.org's boards have always passed fcc, it's part of the marketting.. and it's useful for anyone who builds off oit.. Jan 20 22:46:48 right, but what do RF regulations have to do with SoC boards Jan 20 22:47:08 i can't imagine the messed-up HDMI thing would like, blast static on emergency frequencies or something Jan 20 22:49:17 kremlin, like a big antenna... noise moved from the current circuit, into the hdmi lines, which ran down the hdmi cable, violating fcc emmissions... Jan 20 22:50:04 until you've done emissions testing .. you really don't know what kinds of things happen .. cables are always an aerial Jan 20 22:50:19 so nothing ever works completely in isolation Jan 20 22:51:12 unless you're lucky and encase it in a good shielded metal box and have no wires ... XD Jan 20 22:51:57 but with the currents we are dealing with here that would absolutely never pose a threat to anything Jan 20 22:52:10 not that it isn't shoddy engineering, but i didn't know the FCC was looking out for that Jan 20 22:52:16 you'd be surprised. Jan 20 22:55:56 i don't doubt it Jan 20 22:57:03 rcn-ee.. is there any eta for rev B then on the x15? Jan 20 22:57:13 to log for those who are always asking ... Jan 20 22:58:21 no firm date... the manufacture of the pcb's made some changes behind their back to run on the test line.. Jan 20 22:58:38 anythinig ball-park even? Jan 20 22:58:44 2018 .. 2026? Jan 20 22:58:52 lol Jan 20 22:59:01 hoping before spring.. Jan 20 22:59:32 okies. Jan 20 23:00:54 this is the second winter i've had an x15 on my desk for development.. ;) (to be fair the first one had a very nasty silicon bug and only half* the ram working (half bank on each chip))... Jan 20 23:02:01 i know jasonk is looking for more software hackers.. specially people with gstream/video backgrounds.. Jan 20 23:03:36 Amazing choice of SoC, I can't wait :) Jan 20 23:03:38 well .. I might know one .. Jan 20 23:03:50 how many cores has the x15 proc got? Jan 20 23:03:58 will it render >1 hd stream? Jan 20 23:04:01 2xA15 @ 1.5GHz Jan 20 23:04:19 veremit, 2 a15's, 4 m4's, 2 dsp c6000, 4 pru's Jan 20 23:04:22 plus a bunch of M4/PRU/graphics and 2xC66x DSP Jan 20 23:04:40 one of the m4 is dedicated to video decoding/encoding... Jan 20 23:05:05 dedicated to video, really? Jan 20 23:05:11 its got Gig-E hasn't it .. Jan 20 23:05:17 or two Jan 20 23:05:18 2 gige ports.. Jan 20 23:05:43 kjetilh, it has a blob from ti dedicated for h264/265/etc decoding/encoding.. Jan 20 23:05:43 So there is just 1 GP M4? Jan 20 23:05:57 hmm .. maybe I'll drop jk a msg sometime .. we're using an i7 for a hd camera mux system Jan 20 23:06:07 but currently its only running a couple of streams .. so .. Jan 20 23:06:26 kjetilh, well you can use it for soemthing else... just one that works with the codec blob.. Jan 20 23:06:27 could be a good test of hardware if it compiles on arm :D Jan 20 23:07:18 aha, that's ok. Jan 20 23:07:20 rcn-ee: what's the application process, and would it be possible to get a couple to do co-development ? Jan 20 23:07:45 is the following interpretation correct of this guide: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard Jan 20 23:07:53 veremit, there's a thread on beagleboard-x15, just do a quick writeup.. (there lots of rev a boards) Jan 20 23:07:59 that this line: sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 bs=384k Jan 20 23:08:32 kjetilh: one dual-M4 subsystem Jan 20 23:08:42 will not spill into the first partition which starts at 1024k by this line: sudo sfdisk ${DISK} <<-__EOF__ 1M,,L,* __EOF__ Jan 20 23:09:06 kjetilh: or two, if you have no use for the video thingy Jan 20 23:09:06 because u-boot.img is less than 768k? Jan 20 23:09:54 i..e, it is equal to or less than 640k? Jan 20 23:10:18 How flexible is the use of the peripherals? can the M4, A15 or DSP all use eg I2C/SPI/UART/CAN? (not at the same time) Jan 20 23:10:41 rcn-ee: s/c6000/c66x/ Jan 20 23:10:58 yates, u-boot.img = 324K Jan 20 23:11:36 Or are they dedicated to the A15s? Jan 20 23:11:38 kjetilh: any of them can use any peripheral, though one peripheral can typically not be used by two cores at the same time obviously (unless two drivers are specially designed to cooperate in some way) Jan 20 23:11:38 ok, right. Jan 20 23:11:56 cool Jan 20 23:13:47 rcn-ee: but if u-boot.img ever grew beyond 640k this technique would no longer work, right? Jan 20 23:13:57 cause the first partition would cut it off. Jan 20 23:14:21 i'm not worried, the question is just to confirm my understanding. Jan 20 23:14:27 the first partition ought to start at 4 MB anyhow :P Jan 20 23:16:01 the "count=2 ... bs-384k} allows the u-boot.img size to be up to 2*384k without dd complaining, i'm presuming Jan 20 23:16:04 that's why i always set the fat partition to end at 96.. /4 /8 /12 ... Jan 20 23:16:23 s/}/"/ Jan 20 23:16:57 the count=2 is redundant. you're relying on EOF anyway Jan 20 23:17:06 s/bs-/bs=/ Jan 20 23:18:19 it's not redundant if the input file is over 2*384k, is it? Jan 20 23:18:31 count=N: copy only N input blocks Jan 20 23:18:39 if the input file is over 640k you'd already have a problem, and count=2 would not prevent that Jan 20 23:18:46 copying a partial u-boot would also be a problem Jan 20 23:19:07 if you want to verify the size before copying, verify the size before copying :P Jan 20 23:19:33 this is not about verifying. it's about grokking the purpose for these particular parameters in the procedure. Jan 20 23:19:39 it serves none Jan 20 23:20:48 yates, mmc raw boot looks at: 0, 128Kb, 256kb, 384Kb for MLO Jan 20 23:21:15 no, for the raw mmc header Jan 20 23:21:30 (well the mlo file dd'ed to that location) Jan 20 23:21:33 well (and i should try this) if u-boot.img is > 384k and > 640k, then at least a "count=1" would cause dd to complain (i think), which would serve a purpose to tell you "hey dude, something's wrong" Jan 20 23:21:41 which is to be followed by the MLO (not to be confused with the file misnamed "MLO" by u-boot) Jan 20 23:22:01 yates, so the question... what does u-boot look for.. the first dd'ed u-boot.img or the second.. Jan 20 23:22:05 or "something could be wrong" Jan 20 23:22:11 yates: no it won't Jan 20 23:22:30 dd is quite dumb Jan 20 23:22:36 oh, yea, that's right. it just silently ignores the rest of th efile. Jan 20 23:23:06 veremit, bmaptools for ever! Jan 20 23:23:23 rcn-ee: only if they're in the image :P lol Jan 20 23:24:08 I still don't really get the point of bmaptools... just use resize2fs to shrink to fs to min size and expand it again after flashing Jan 20 23:24:24 it's faster then dd'... that's the ponit. ;) Jan 20 23:24:30 zmatt: by the second, you mean this line: sudo cp -v ./u-boot/u-boot.img /media/rootfs/opt/backup/uboot/ Jan 20 23:24:42 rcn-ee: dcfldd is my preference :p Jan 20 23:24:44 yates: ? Jan 20 23:25:11 yates, that's jsut there for anyone who runs the "eMMC-flasher" bash script on eewiki.net... Jan 20 23:25:13 woops. Jan 20 23:25:22 i mean rcn-ee Jan 20 23:25:29 rcn-ee: by the second, you mean this line: sudo cp -v ./u-boot/u-boot.img /media/rootfs/opt/backup/uboot/ Jan 20 23:25:44 yates, no i mean back to count=2... Jan 20 23:26:16 yates, i'm wondering if u-boot-spl reads the first version u-boot.img or the 2nd version of u-boot.img dd'ed to the MBR.. Jan 20 23:26:55 (remember i stole those numbers from the fedora guys 2 years ago... they worked so i didn't look to much into them) Jan 20 23:27:24 where is the "first version" of u-boot.img? is it embedded in the MLO file? Jan 20 23:28:21 i thought the combination of the "count=2" and "bs=384k" means that dd will only copy up to 2*384k bytes of the input file Jan 20 23:28:22 yates, then what's the question... with dd we are dumping u-boot.img after 384K ;) Jan 20 23:29:45 the question is this: if u-boot.img ever grew beyond 640k this technique would no longer work, right? because that would place part of it after the beginning of the first partition, which is at 1024k Jan 20 23:30:23 it would also clash with the msdos partition table.. Jan 20 23:30:23 because 384k + 640k = 1024k Jan 20 23:30:46 i thought that ended at 128k? Jan 20 23:30:52 (but we could switch to gpt) Jan 20 23:31:39 correction: after 0.5k (ie, 512 bytes) Jan 20 23:32:04 yeah, 0 -> 512... Jan 20 23:32:06 or is "msdos partition table" != "master boot record" Jan 20 23:32:11 ? Jan 20 23:32:35 so why would u-boot.img clash with that? it starts way out at 384k, right? Jan 20 23:32:58 rcn-ee: note that raw mmc header and partition table can peacefully coincide (so the MLO could start at sector 1) Jan 20 23:32:59 having a brain fart moment where i thought it was right under the 1MB.. Jan 20 23:33:18 ha ha. i never have those.... Jan 20 23:33:28 anyhow, afk, got train to catch Jan 20 23:33:39 zmatt: or a falling star? Jan 20 23:33:47 :) Jan 20 23:34:38 https://www.youtube.com/watch?v=FRm6lXCG1kw Jan 20 23:35:13 ok, yeah, i'm old... Jan 20 23:37:11 yates, we had a version of u-boot.img that was over 400Kb.. Jan 20 23:37:40 ah. Jan 20 23:37:47 http://repos.rcn-ee.com/bootloader/am335x_evm/u-boot-am335x_evm-v2015.07-r6.img Jan 20 23:37:49 it's all starting to make sense. Jan 20 23:38:00 http://repos.rcn-ee.com/bootloader/am335x_evm/MLO-am335x_evm-v2015.07-r6 Jan 20 23:38:09 and matching MLO.. those work. ;) Jan 20 23:38:11 just old.. Jan 20 23:39:02 i had switched from gcc 4.x to gcc 5.x in that time frame: 400K -> 325K... Jan 20 23:39:11 If anyone involved in hardware design show up, could you ask them about the file format of x15 design files and log it? Jan 20 23:39:22 (oh and thumb2 got enabled.. it was mostly that..) Jan 20 23:39:31 ah. Jan 20 23:41:39 thanks for bouncing it around. it had me going for awhile. i had to draw myself a picture, etc... Jan 20 23:56:47 does sfdisk make a msdos type partition table, by default? Jan 20 23:58:04 nm, i see Jan 20 23:58:26 the "L" in the option field implies 83, mbr/dos Jan 20 23:58:45 no, wait.. **** ENDING LOGGING AT Thu Jan 21 02:59:58 2016