**** BEGIN LOGGING AT Mon Apr 25 02:59:58 2016
Apr 25 04:03:13 <trelane> have we gotten the systemd/connman/wifi never gets unblocked issue yet with the Debian Jessie images?
Apr 25 04:03:20 <trelane> I still haven't seen rcn-ee around to ask hi
Apr 25 04:03:21 <trelane> m
Apr 25 04:17:02 <Abbas_> Hey, is anyone present? I just flashed Debian 8 onto my beaglebone black and am having problems using sudo. it keeps asking for a password, but never asked me to input one so i dont quite know what it is
Apr 25 04:25:18 <Abbas_> Anyone? =\
Apr 25 04:45:13 <veremit> debian/temppwd are the defaults
Apr 25 04:45:55 <veremit> rtfm is your friend, lmgtfy is the next stage
Apr 25 08:42:14 <banana_> this link http://ahsoftware.de/Beaglebone_Black_Boot_explained.svg
Apr 25 08:42:24 <banana_> why does it not say anythin about sd Card? is this the same as serial?
Apr 25 08:44:19 <KotH> mmc = sdcard
Apr 25 08:44:49 <KotH> or rather, mmc0
Apr 25 08:45:55 <banana_> oh i thought mmc was the on chip extra flash memory ..
Apr 25 08:49:04 <banana_> is the ddr2 sdram then mmc1 ?
Apr 25 08:49:25 <banana_> its the eeprom?
Apr 25 09:03:07 <zmatt> the diagram is wrong and confusing
Apr 25 09:03:18 <zmatt> mmc0 = μUS, mmc1 = eMMC
Apr 25 09:03:39 <zmatt> eeprom is connected to i2c0 and is not a boot device
Apr 25 09:04:00 <zmatt> it uses ddr3 ram, which has nothing to do with mmc interfaces
Apr 25 09:04:36 <zmatt> (it *can* boot from spi flash, but this is not present on the bbb and would have to be connected via the expansion headers)
Apr 25 09:05:39 <zmatt> typo, mmc0 = μSD
Apr 25 09:10:42 <banana_> ok thank u both
Apr 25 09:11:06 <banana_> would be nice if that was included in the picture and i have some paint skills but..
Apr 25 09:11:57 <zmatt> I don't think a diagram makes things clearer since you have two "subroutines" (two mmc boot devices) and many exit paths
Apr 25 09:21:02 <KotH> zmatt: well, it makes things clearer if you know them already and need a refresher
Apr 25 09:21:15 <KotH> zmatt: but it can confuse the hell out of n00bs
Apr 25 09:21:33 <KotH> but then, this whole embedded thing confuses the hell out of n00bs
Apr 25 09:32:29 <banana_> it is indeed confusing for me
Apr 25 09:32:39 <zmatt> http://pastebin.com/PEZwrNui
Apr 25 09:32:41 <banana_> but i am trying to learn
Apr 25 09:32:53 <zmatt> summary of am335x boot, for reference
Apr 25 09:33:25 <zmatt> this is just the first stage of booting, i.e. when using u-boot this is about loading its "SPL" into internal SRAM and execute it
Apr 25 09:34:03 <zmatt> SPL then loads the full u-boot (afaik it prefers to load it from the same device it came from itself, but I'm not 100% sure)
Apr 25 09:34:11 <banana_> yes i found somethin similar to this and TI also documents the SPL and sometimes called MLO
Apr 25 09:34:33 <zmatt> MLO is a specific format
Apr 25 09:34:40 <banana_> so this uboot has jedec or SPI interface protocols internaly to communicate with these difference devices?
Apr 25 09:34:53 <zmatt> "jedec" ?
Apr 25 09:35:00 <zmatt> there's nothing on spi by default
Apr 25 09:35:15 <banana_> i think jedec is the protocol interface to the eMMC
Apr 25 09:35:23 <zmatt> jedec is a standards organisation
Apr 25 09:35:39 <banana_> i am a n00b
Apr 25 09:35:45 <banana_> but i am searching
Apr 25 09:35:51 <zmatt> eMMC is the protocol to eMMC
Apr 25 09:36:13 <banana_> and uboot already has this so it can check the mmc0 or mmc1 of the bbb?
Apr 25 09:36:50 <zmatt> if you read my pastebin you see that in fact even the ROM bootloader can already access all of those devices
Apr 25 09:37:01 <zmatt> SPL (which is a stripped-down) u-boot can also
Apr 25 09:37:15 <zmatt> eh, parenthesis error
Apr 25 09:37:22 <zmatt> SPL (which is a stripped-down u-boot) can also
Apr 25 09:37:36 <zmatt> the full u-boot supports even more devices
Apr 25 09:38:02 <banana_> oh thats quite usefull
Apr 25 09:38:10 <banana_> thank u for ur info kind sir
Apr 25 09:38:16 <zmatt> or bloated, depends on your point of view :P
Apr 25 09:38:44 <banana_> do u know perhaps some general pdfs or sources where i can gain some knowledge of this embedded platform
Apr 25 09:39:07 <banana_> not programming
Apr 25 09:39:16 <KotH> Tartarus: zmatt called u-boot bloated!
Apr 25 09:39:40 <banana_> languages, but like setting up linux on an ARM chip ..
Apr 25 09:39:59 <KotH> banana_: 1) get a _good_ understanding of linux, how it works, how it boots
Apr 25 09:40:08 <KotH> banana_: 2) get the "embedded linux primer"
Apr 25 09:40:13 <zmatt> KotH: not at all... http://warnet.ws/img2/208/body/14.jpg
Apr 25 09:40:42 <zmatt> :)
Apr 25 09:41:17 <KotH> zmatt: i dont know how it is where you live, but where i live, a body like this would be a serious health condition which requires treatment
Apr 25 09:41:54 <KotH> zmatt: also, it's not nice to call Tartarus fat
Apr 25 09:42:04 <banana_> oh thank u for this amazing tip, this book is exactly what i need !
Apr 25 09:42:07 <zmatt> I was referring to u-boot
Apr 25 09:42:21 <zmatt> (and grabbed the first image google gave me for reference :P )
Apr 25 09:42:23 <KotH> banana_: the book is not that great
Apr 25 09:42:37 <KotH> banana_: it's good, but lacks a lot of the details that confuse n00bs
Apr 25 09:43:14 <KotH> banana_: embedded linux is still a lot of black magic and craftmanship
Apr 25 09:43:20 <KotH> banana_: best learned by doing
Apr 25 09:43:23 <banana_> its a starting point
Apr 25 09:43:38 <KotH> also, a moving target
Apr 25 09:44:05 <banana_> i appriciate the help never the less
Apr 25 09:45:07 <KotH> banana_: btw: a good way to learn how linux works internally is to do a linux from scratch installation
Apr 25 09:45:21 <zmatt> banana_: setting up linux on an embedded system often also requires at least *some* programming.  for example some knowledge of the hardware (e.g. RAM size) is hardcoded into u-boot
Apr 25 09:45:34 <KotH> banana_: it's a damn lot of work, but after that you know all the components of a linux system in detail
Apr 25 09:46:05 <KotH> banana_: http://www.linuxfromscratch.org/
Apr 25 09:47:02 <zmatt> it doesn't use systemd yet?
Apr 25 09:47:23 <KotH> setting up systemd from scratch would need a book of its own
Apr 25 09:47:41 <zmatt> it's at the heart of most modern linux systems though
Apr 25 09:48:09 <KotH> yes, the heart with serious conditions
Apr 25 09:48:27 <zmatt> and i don't see why it would add any complexity
Apr 25 09:48:28 <KotH> unfortunately, it gets harder every day to run a system without systemd
Apr 25 09:48:52 <KotH> oh.. have you looked at all the components of systemd?
Apr 25 09:49:27 <zmatt> are you referring to dependencies?
Apr 25 09:49:30 <KotH> while sysv init is just a collection of loosely couple scripts, systemd is a mess of tons of different tools that all have weird dependences
Apr 25 09:50:51 <zmatt> that's one viewpoint... you can also call it a mess of scripts versus an integrated set of tools.  see how using some subjective adjectives can make all the difference :P
Apr 25 09:51:00 <KotH> :-)
Apr 25 09:51:26 <KotH> but that doesnt change the fact that i'm right and you are not! :-P
Apr 25 09:51:33 <zmatt> lol
Apr 25 09:53:01 <Spidler> Meh
Apr 25 09:53:22 <Spidler> Setting up an initrd might be the book on it's own ;P
Apr 25 09:53:29 <Spidler> The rest is fairly simple stuff
Apr 25 09:53:40 <Spidler> ( Oh, initramfs-tools? DIE! )
Apr 25 09:53:40 <zmatt> you can do without an initrd
Apr 25 09:53:51 <zmatt> in principle
Apr 25 09:53:53 <Spidler> Mmm
Apr 25 09:54:00 <KotH> yes... use knl and put everything onto a floppy
Apr 25 09:54:22 <Spidler> I'm still amazed that LFS is around.
Apr 25 09:54:40 <Spidler> I used to write for BLFS back in the early 2k's.
Apr 25 09:54:52 <zmatt> KotH: what's knl?
Apr 25 09:55:04 <zmatt> and why on earth would a floppy be involved?
Apr 25 09:55:56 <KotH> zmatt: a tool to set the boot parameters of a kernel in the binary
Apr 25 09:56:12 <zmatt> as long as the drivers for your root filesystem and its block device are compiled into the kernel you don't need an initrd
Apr 25 09:56:13 <KotH> zmatt: actually, it's the newfangled tool for that... i cannot remember how the original tool was called
Apr 25 09:56:22 <zmatt> boot parameters are passed by the bootloader to the kernel
Apr 25 09:56:26 <zmatt> initrd isn't involved in that
Apr 25 09:56:35 <Spidler> zmatt: on floppies there was no bootloader :)
Apr 25 09:57:08 <zmatt> you have an ARM system that boots from floppies?
Apr 25 09:57:09 <KotH> Spidler: there were people who used lilo on floppies
Apr 25 09:57:24 <zmatt> since that's still what this was all about in the end :P
Apr 25 09:57:38 <Spidler> KotH: I know, you _could_ run it, but by default you didn't need one as the system would just read to the end.
Apr 25 09:57:48 <Spidler> zmatt: That would be an awesome hack.
Apr 25 10:00:11 <zmatt> sure, I can appreciate some retro stuff... I actually recently programmed an EPROM for someone :P
Apr 25 10:01:37 <Spidler> zmatt: Haha.
Apr 25 10:01:49 <zmatt> couldn't find any working sw for the ancient programmer someone dug up so I wrote a little perl script to write the data
Apr 25 10:03:46 <Spidler> Ah
Apr 25 10:05:07 <zmatt> "I can configure the program time from 3 ms to <lots> ms, how much does your EPROM require?" "0.1ms" "okay, 3ms it is."
Apr 25 10:05:22 <zmatt> or us
Apr 25 10:05:24 <zmatt> can't remember
Apr 25 10:05:35 <Spidler> Heh
Apr 25 10:05:36 <zmatt> us of course
Apr 25 10:05:42 <zmatt> right?
Apr 25 10:05:45 <Spidler> should be?
Apr 25 10:05:59 <Spidler> EPROM was pretty fast. Just the software around it that was slow.
Apr 25 10:06:16 <Spidler> I still have nightmares about LOGIC/4 on Windows NT
Apr 25 10:06:26 <zmatt> well EPROM apparently was a lot slower than modern ones are :P
Apr 25 10:07:30 <zmatt> ms
Apr 25 10:07:35 <zmatt> Programming time: 100µs/Word
Apr 25 10:07:54 <zmatt> ick where'd that garbage char come from
Apr 25 10:08:24 <zmatt> still, the 1200 baud serial port of the programming was the limiting factor in the end
Apr 25 10:08:29 <zmatt> *programmer
Apr 25 10:13:00 <zmatt> it also used the lowest voltage supported by the programmer (12.5V)... apparently 25V used to be a common programming voltage... jeez you really needed to bang those electrons in with a hammer ;)
Apr 25 10:13:10 <Spidler> The thing I love most about checking out some code: README file is in Japanese
Apr 25 10:13:33 <zmatt> just google translate it and it'll be fine ;)
Apr 25 10:13:41 <Spidler> Mmmmm
Apr 25 10:14:25 <Spidler> Meh, my todolist for next week is annoying. Bundling kernel + initramfs + devicetree and try to get them onto partitions.
Apr 25 10:14:37 <Spidler> Joy.
Apr 25 10:14:49 <zmatt> "get them onto partitions" ?
Apr 25 10:15:13 <Spidler> Mmmmm
Apr 25 10:15:53 <Spidler> emulae mmcload
Apr 25 10:15:58 <Spidler> emulate, even
Apr 25 10:16:21 <Spidler> I personally think it's a bit of a step backwards.
Apr 25 10:46:08 <KotH> Spidler: what kind of software are you looking at?
Apr 25 11:02:10 <Spidler> KotH: Right now? Reviwing DB monitoring tools and finding SQL injections.
Apr 25 11:45:34 <KotH> Spidler: nah.. the japanese readme one
Apr 25 11:46:19 <Spidler> KotH: See above.  DB monitoring tool
Apr 25 11:46:44 <Spidler> Much of the PostgreSQL community is based in Japan, so a ton of the tools will be in japanese first
Apr 25 11:59:30 <KotH> Spidler: interesting.. didnt know that
Apr 25 12:01:36 <Guest17033> Compared to kernel 3.8.x,  the 4.1.x kernel boot time is increased a lot. After logging i considered "Starting kernel ..." line (just after uboot finishes) takes much longer to finish  compared to 3.8.x. any solution to reduce delay?
Apr 25 12:02:08 <KotH> Guest17033: figure out what's taking time and fix that
Apr 25 12:03:30 <Guest17033> i mentioned, "Starting kernel ..." line takes about 2 sec . i don't know whats going in background.
Apr 25 12:03:58 <KotH> remove the "-quite" from the kernel parameters
Apr 25 12:04:13 <Guest17033> already did
Apr 25 12:04:14 <KotH> it's most likely probing stuff that isnt there
Apr 25 12:04:29 <KotH> there are also some options to make kernel startup more verbose
Apr 25 12:05:32 <Guest17033> can it be related to bootloader?
Apr 25 12:08:09 <Guest17033> i wonder why no one complains about this huge startup delay after 3.8.x kernels
Apr 25 12:15:29 <Spidler> Guest17033: what does `systemd-analyze time` give you?
Apr 25 12:19:11 <Guest17033> Spidler: i'm talking about time when userspace has not been started.
Apr 25 12:19:49 <Guest17033> just after bootloader starts kernel
Apr 25 12:19:50 <Spidler> That's why I said `time` not `blame`
Apr 25 12:20:09 <Spidler> It can tell you how long was spent inside kernel, and in firmware.
Apr 25 12:20:23 <Spidler> And if it's the initrd or the kernel
Apr 25 12:20:52 <Guest17033> i got it . let me run it
Apr 25 12:23:07 <Spidler> Mine is not stellar: Startup finished in 5.643s (kernel) + 3.816s (initrd)  ,  but it gives an idea
Apr 25 12:23:42 <KotH> getting an embedded system to boot in <10s should be easy
Apr 25 12:23:59 <Spidler> Should be
Apr 25 12:24:01 <KotH> i know of people who got their system booting and running a qt application in less than a second
Apr 25 12:24:04 <Spidler> zmatt got it
Apr 25 12:24:09 <Spidler> Personally, I'm not giving a fuck ;P
Apr 25 12:24:17 <Spidler> It's not worth the dev time to optimize for it.
Apr 25 12:24:31 <KotH> depends on your application ;)
Apr 25 12:24:41 <Spidler> Industrial control systems.
Apr 25 12:24:43 * KotH knows a system where 1s was too long
Apr 25 12:24:55 <Spidler> "Eh, it'll come up this afternoon, that's fast enough"
Apr 25 12:25:04 <Guest17033> Startup finished in 9.623s (kernel) + 14.659s (userspace) = 24.282s
Apr 25 12:25:17 <Spidler> That's quite slow yeah
Apr 25 12:25:21 <Spidler> No initrd?
Apr 25 12:25:23 <Guest17033> 4.1.18-ti-r56
Apr 25 12:25:29 <Spidler> Mine is in 4.4 kernels
Apr 25 12:25:37 <Spidler> So it could be a regression that's been fixed.
Apr 25 12:25:46 <Spidler> How was 3.8 for you?
Apr 25 12:25:53 <Guest17033> so fast
Apr 25 12:25:57 <Guest17033> below 10 sec
Apr 25 12:26:34 <Spidler> My total boot chain is > 1.2 minutes :)
Apr 25 12:26:41 <Spidler> It does a complete roundtrip across the internet
Apr 25 12:26:42 <Guest17033> if you get a realtime log with serial kernel you will consider that even in 4.4 it will take much longer than 3.8
Apr 25 12:27:03 <Guest17033> serial cable :)
Apr 25 12:28:13 <Guest17033> Spidler: is your kernel "ti"s ?
Apr 25 12:28:34 <Spidler> Nop!
Apr 25 12:28:44 <Spidler> So we're comparing apples and bulldozers
Apr 25 12:29:25 <Guest17033> by the way is your device BBB !?
Apr 25 12:29:39 <Spidler> Yes
Apr 25 12:31:08 <Guest17033> ok, i'm a bit confused in selecting proper kernel for bbb. 3.8, 3.14, 4.1, 4.4 and *-ti . i went for 4.1 cause i read some where its stable for bbb.
Apr 25 12:31:50 <Guest17033> i mean 4.1.x-ti but when i saw boot time ...
Apr 25 12:32:39 <Spidler> My usual rule is "Stick to as close to mainline upstream as you can"
Apr 25 12:33:27 <Guest17033> and about choosing ti and none ti ?
Apr 25 12:35:39 <Spidler> ti contains more patches from the ti upstream, lags behind mainline, has some funky features if you need them
Apr 25 12:39:28 <KotH> Guest17033: why not the rcn kernel?
Apr 25 12:39:37 <KotH> Guest17033: this is usually the recommended one for the BBB
Apr 25 12:46:01 <Guest17033> KotH: i actually downloaded from official debian page for beaglebone black 'https://rcn-ee.com/rootfs/bb.org/testing/2016-04-10/console/BBB-eMMC-flasher-debian-8.4-console-armhf-2016-04-10-2gb.img.xz'
Apr 25 12:46:28 <Guest17033> i don't know why its ti's kernel
Apr 25 12:46:50 <Guest17033> i actually need a console image to rapidly boot to a qt program
Apr 25 12:47:16 <Guest17033> with opengl es2 support
Apr 25 13:11:42 <dje> I would like to know if i can connect 2 beaglebone (1 master and 1 slave) with i2c buses
Apr 25 13:20:54 <dje> somebody ?
Apr 25 13:37:31 <dje> Hello everybody. I would like to know if it's possible to link 2 BBB with I2C. Thanks
Apr 25 13:45:28 <emeb> blärgh
Apr 25 13:56:33 <dje> somebody ?
Apr 25 14:11:10 <tbr> dje: probably, although there probably are better ways to interconnect them
Apr 25 14:19:58 <dje> tbr: thanks for your response, the probleme is i need to use this 2 BBB links with this protocole so i would like to know if i can (even if it's complicate) or if it's impossible
Apr 25 14:22:22 <tbr> the tricky bit is probably running a BBB as I2C slave, but I think I've heard that it's possible
Apr 25 14:27:21 <dje> ok thanks, I check on web if there are some exemples of this utilisation
Apr 25 14:27:37 <tbr> you'll want to run a 4.x kernel
Apr 25 14:27:53 <tbr> as earlier kernels probably don't support i2c slave mode
Apr 25 14:34:43 <dje> what the probleme ?I think the AM3358ZCZ100 could works in i2c slave mode
Apr 25 14:40:17 <tbr> > as earlier kernels probably don't support i2c slave mode
Apr 25 14:43:47 <dje> ok I need to check that
Apr 25 14:53:43 <zmatt> I wouldn't recommend it
Apr 25 14:54:53 <Ragnorok> I would think a PRU would make any I2C mechanism pretty simple.  It's not like I2c is complicated as a protocol.
Apr 25 15:01:36 <dje> zmatt: why you don't recommend it ?
Apr 25 15:08:35 <as_> how can I know which beagle bone I have
Apr 25 15:18:40 <tbr> as_: look at the board, is it black, blue, green or white? → bbb, blue steel, bbg, bbw
Apr 25 17:04:26 <bradfa> tbr: do many people actually have blue steel borads?
Apr 25 17:04:48 <tbr> bradfa: I doubt it, cco, availability, supply, etc. :)
Apr 25 18:01:08 <sam__> Hi all
Apr 25 18:34:57 <new2bbb> Hello, I am trying to follow https://github.com/abhishek-kakkar/BeagleLogic/wiki/Build-BeagleLogic for beaglelogic . But can you please help me out how can I find <path-to-clpru> in that steps ?
Apr 25 18:37:03 <new2bbb> av500: Can you please help if possible ?
Apr 25 18:37:41 <ljtech> help
Apr 25 18:37:52 <Ragnorok> Afaik BeagleLogic requires a kernel with uio_pruss, which none of the TI kernels support otb.  Simplest is the older 3.8 it probably shipped with, or a rcn build.  Also iirc you must download and install clpru; it's not "just there".  Instructions should be on the BeagleLogic site.
Apr 25 18:40:00 <new2bbb> Ragnorok: Thanks. clpru is already installed on my bbb but I wouldn't be able to find the path where it is installed .
Apr 25 18:40:20 <Ragnorok> Use "which"?
Apr 25 18:41:09 <new2bbb> ok Thanks. I got :)
Apr 25 18:41:22 <Ragnorok> \o/
Apr 25 20:53:09 <zmatt> Ragnorok: 4.1-bone has uio_pruss afaik
Apr 25 20:53:24 <zmatt> no need for ancient kernels
Apr 25 20:53:51 <Ragnorok> zmatt: Yup.  That's "a rcn build", is it not?
Apr 25 20:54:36 <zmatt> the "-ti" kernels are also rcn builds (but derived from TI's kernel tree)
Apr 25 20:55:03 <zmatt> I wonder how hard it would be to fix that code to use uio_pdrv_genirq instead of uio_pruss
Apr 25 20:55:09 <zmatt> then it would work on any kernel
Apr 25 20:55:31 <Ragnorok> zmatt: Ah.  Roit.
Apr 25 20:59:19 <zmatt> looks like the main deficiency of uio_pdrv_genirq would be that it doesn't offer an easy way to reserve a chunk of DDR
Apr 25 21:03:29 <zmatt> I've been looking (though not very actively) for a good mechanism to do that, since I also use DMA from userspace
Apr 25 21:03:43 <zmatt> for now on-chip SRAM has been sufficient though
Apr 25 21:16:09 <Ragnorok> I currently have a LKM to read, but will likely change to user space code and ditch it.  That Mythical Some Day.
Apr 25 21:16:41 <zmatt> maybe I could just use a memreserve in DT
Apr 25 21:17:08 <zmatt> not very elegant or flexible though
Apr 25 21:19:28 <zmatt> I know there are many drivers that in some way or fashion allocate DMA memory and allow userspace mapping, e.g. in DRI and stuff... I still have hope there's already something in mainline linux that can be used to allocate DMA memory for private use
Apr 25 21:20:11 <zmatt> but haven't had any urgent need for it, so haven't really investigated
**** ENDING LOGGING AT Tue Apr 26 02:59:58 2016