**** BEGIN LOGGING AT Tue Jan 26 02:59:58 2016
Jan 26 03:31:29 <yates> ayjay: where's rick?
Jan 26 03:36:24 <ayjay> prob with morty
Jan 26 04:18:15 <yates> if a device, say, i2c0, is not in the device tree, will it show up in the device filesystem?
Jan 26 04:18:31 <veremit> unlikely
Jan 26 04:18:34 <yates> i would think not, but just checking my understanding
Jan 26 04:18:44 <veremit> how would the kernel know about it?!
Jan 26 04:19:17 <veremit> since it is kernel drivers that populate sysfs/etc
Jan 26 04:20:52 <yates> what is the meaning of the leading "&" syntax in a device node name, e.g., "&i2c0"?
Jan 26 04:23:23 <yates> e.g., this, which is in am335x-boneblack.dts: http://ur1.ca/ogagm -> http://paste.fedoraproject.org/314739/45378218
Jan 26 04:27:10 <veremit> standard pointer syntax :P go to C school :XD
Jan 26 04:27:23 <yates> this isn't C
Jan 26 04:27:26 <veremit> or worse still .. standard syntax of something else
Jan 26 04:27:35 <veremit> I suspect its related though
Jan 26 04:28:04 <yates> why must we base our understanding in suspicion? isn't it explicitly defined?
Jan 26 04:28:38 <veremit> Definition?! Documentation?! what are these things you talk about ..
Jan 26 04:28:41 <veremit> lol ,, maybe :p
Jan 26 04:28:49 <yates> lol
Jan 26 04:29:53 <yates> i've been trying to find it here, but this site seems pretty skimpy: http://www.devicetree.org/Main_Page
Jan 26 04:29:57 <yates> at least it's a start.
Jan 26 04:32:44 <veremit> close .. http://devicetree.org/Device_Tree_Usage
Jan 26 04:33:45 <yates> yeah, i saw that.
Jan 26 04:33:50 <yates> it is there - i missed it.
Jan 26 04:34:44 <yates> well, no, it's not.
Jan 26 04:35:04 <yates> define define it in the context of aliases
Jan 26 04:36:45 <yates> s/define define/they define/
Jan 26 04:41:08 <yates> oh, it is an alias. albeit a stupid one: "i2c0 = &i2c0;" how does that save typing?
Jan 26 04:41:44 <veremit> I should imagine the difference is subtle but crucial
Jan 26 04:44:42 <yates> how so?
Jan 26 04:45:32 <yates> this seems to say that the purpose is brevity: http://www.devicetree.org/Device_Tree_Usage#aliases_Node
Jan 26 04:57:41 <yates> what is meant by a "flattened" device tree?
Jan 26 04:57:55 <veremit> its not a 'tree' any more .. that implies several levels
Jan 26 04:58:00 <veremit> and its all on one level
Jan 26 04:59:19 <yates> so all node/subnode/... are converted to one flat bunch of properties?
Jan 26 05:00:03 <yates> is that what the dtc does?
Jan 26 05:00:29 <yates> yes.
Jan 26 05:01:24 <yates> http://paste.fedoraproject.org/314742/53784458
Jan 26 05:08:59 <yates> is a single leading "/" a comment character in .dtsi files?
Jan 26 05:09:06 <yates>  /include/ "tps65217.dtsi"
Jan 26 05:10:12 <yates> doh.
Jan 26 05:10:14 <yates> nope.
Jan 26 05:10:38 <yates> well, i dunno really. help?
Jan 26 05:10:50 <yates> what does that line do? ^^^
Jan 26 05:19:26 <yates>  /include/ "tps65217.dtsi"
Jan 26 05:19:31 <yates> what is THAT?!?
Jan 26 05:19:56 <yates> seems like a normal include is like this: #include "skeleton.dtsi"
Jan 26 05:21:48 <yates> veremit: no clue?
Jan 26 05:23:10 <veremit> its a hybrid syntax
Jan 26 05:23:19 <veremit> I can't comment, since I've never written nor used D-T yet
Jan 26 05:25:14 <yates> ok. thanks anyway.
Jan 26 05:26:18 <yates> oh!!! http://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
Jan 26 05:26:33 <yates> documentation! yippee!
Jan 26 05:30:33 <yates> good night, lads.
Jan 26 06:30:23 <LordSAK> Hey guys. i am back again. well we used latest image of debian as suggested to me yesterday and flashed it in my BBB. After booting it behaved same way as expected. then LEDs started to blink in pattern like USR 0123 3210 and so on. it remained in this state like 15-20mins and then all LEDs went off. even the Power LED too. we removed SD card and connected the power. it USR0 started flashing in heartbeat, and eMMC also blinked.
Jan 26 06:31:05 <LordSAK> we tried to ssh from terminal it never asked for user name and password to logi in debian. although i can see Wired Connection in my Ubuntu
Jan 26 06:31:18 <LordSAK> how can i connect it back to ssh??
Jan 26 06:33:46 <tbr> LordSAK: first boot usually takes a while
Jan 26 06:35:27 <LordSAK> i got a time out error
Jan 26 06:37:04 <veremit> yeah ssh via usb you gotta wait a good 2min before attempting .. you should see /dev/ttyACM0 come up
Jan 26 06:38:38 <veremit> as well as usb0 networking (or en23049283049823) and /dev/<something>
Jan 26 06:46:51 <LordSAK> what i have noticed right now is it tried to create a  wired connection but never establish one. hene ssh should fail. BBB is connected to machine via USB for 15 mins. and this is happening continuously.
Jan 26 06:47:16 <tbr> did you interrupt first boot by powering down the device?
Jan 26 06:47:23 <LordSAK> nope
Jan 26 06:47:38 <tbr> what are the LEDs doing?
Jan 26 06:48:05 <LordSAK> USR0 heartbeat. USR1 and USR2 blinks time 2 time
Jan 26 06:48:11 <tbr> ok
Jan 26 06:48:23 <LordSAK> sorry USR2 and USR3 are blinking
Jan 26 06:48:31 <LordSAK> i ahve removed sd card so USR1 is off
Jan 26 06:49:24 <tbr> does dmesg say anything about usb devices coming online? storage, serial, network?
Jan 26 06:50:41 <veremit> sounds like the board is alive
Jan 26 06:50:46 <veremit> do you have a serial debug cable!?
Jan 26 06:52:18 <LordSAK> i got this message in last: Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Jan 26 06:52:28 <LordSAK> so either installation was interrupted
Jan 26 06:52:50 <LordSAK> but i cant understand why BB turned off dureing installation
Jan 26 06:53:12 <LordSAK> no. but i can arrange a serial debug cable
Jan 26 06:56:31 <veremit> LordSAK: very handy to troubleshoot "boot" problems .. could be somethiing quite innocent :)
Jan 26 06:56:44 <ds2> how are you powering?
Jan 26 06:56:49 <ds2> USB port?
Jan 26 06:57:05 <ds2> poor quality power cube?
Jan 26 06:57:08 <LordSAK> yes USB port
Jan 26 06:57:19 <ds2> USB power for flashing does not work reliably
Jan 26 06:57:27 <ds2> it pulls more power then is available
Jan 26 06:57:43 <ultra_> fatload mmc 0:1 0x80000000 uImage setenv bootargs rw vram=32M fixrtc mem=1G@0x80000000 root=/dev/mmcblk0p2 console=ttyO2,115200n8 rootwait bootm 0x80000000
Jan 26 06:58:01 <LordSAK> USB port was provided with BBB and we used same procedure last time too i.e flash from USB
Jan 26 06:58:09 <ultra_> what is the use of  vram=32M
Jan 26 06:58:31 <veremit> ultra_: where the hell you got that from!?
Jan 26 06:58:44 <ultra_> boot.script
Jan 26 06:58:47 <veremit> sounds like an old boot config .
Jan 26 06:58:51 <ds2> LordSAK: USB only guarantees 100mA; 500mA if the host negotiates and agrees
Jan 26 06:58:54 <veremit> *very
Jan 26 06:59:06 <ds2> an active Beagle can pull more then that
Jan 26 06:59:24 <ultra_> what is vram stands for
Jan 26 06:59:45 <veremit> videoram
Jan 26 06:59:51 <ds2> see the USB specs if you disagree.
Jan 26 07:00:26 <LordSAK> so we should flash from adaptor when it is done than we connect with USB. right??
Jan 26 07:01:05 <ds2> that should be fine
Jan 26 07:01:14 <ds2> assuming your USB port can provide the power for normal use
Jan 26 07:02:05 <ultra_> fatload mmc 0:1 0x80000000 uImage setenv bootargs rw vram=32M fixrtc mem=1G@0x80000000 root=/dev/mmcblk0p2 console=ttyO2,115200n8 rootwait bootm 0x80000000
Jan 26 07:02:18 <ultra_> in this What is vram stands for
Jan 26 07:02:36 <LordSAK> ok. we are skipping USB right now and flashing directly from adaptor
Jan 26 07:03:03 <LordSAK> seems like USB is unable to fetch required power and even power led went off during flashing
Jan 26 07:03:18 <ds2> some PCs have a soft limit on the 500mA
Jan 26 07:03:24 <veremit> LordSAK: yikes
Jan 26 07:03:33 <ds2> they will allow bursts over 500mA but sustained pulls will result in a power cut
Jan 26 07:04:01 <ds2> even during normal use, the firmware (against best recommendations) configure the BBB to pull more power hten 500mA
Jan 26 07:04:29 <LordSAK> well thanks guys. i will update you after the process is done.
Jan 26 07:04:46 <ds2> if you are really really tight, you might try powering it from a USB dedicated charger to see if it helps
Jan 26 07:05:40 <LordSAK> thanks we are using adaptor now
Jan 26 07:28:41 <karsun> hello. i wanted to know where i can find the best lengthy tutorials for using beaglebone black
Jan 26 07:30:01 <karsun> i want to use all features of GPIO pins (I2C, SPI, ADC, I/O, USART etc)
Jan 26 07:30:14 <tbr> there are a few books on the BBB
Jan 26 07:31:17 <karsun> can u please name the author
Jan 26 07:31:36 <tbr> no, because I don't remember any specific
Jan 26 07:31:49 <karsun> oh, okae
Jan 26 07:32:27 <karsun> thanks btw
Jan 26 07:32:38 <tbr> np
Jan 26 07:32:53 <tbr> you should just query your favourite web search engine with "beaglebone book"
Jan 26 07:33:12 <tbr> that yields results and then go through those and chose one that fits your needs
Jan 26 07:33:51 <LordSAK> hi again. we flashed the our BBB from adaptor. no USB cable was used. same status. i.e USR0 is in hearbeat pattern and USR3 blinks occasionally. ubuntu tries to establish a connection but fails. and ssh is timing out. it has been 10-15mins since we have booted after flashing and removing SD card
Jan 26 07:35:46 <veremit> you did hold the Boot button with the uSD card in, when you powered up, so it HAS actually flashed, yes?
Jan 26 07:36:32 <LordSAK> yes sir
Jan 26 07:36:56 <LordSAK> we holded it till all 4 LEDs lit up
Jan 26 07:37:01 <LordSAK> than we released it
Jan 26 07:42:33 <tbr> what was the pattern when it finished flashing?
Jan 26 07:42:42 <tbr> what's the size of the microsd you used?
Jan 26 07:43:19 <LordSAK> all 4 LEDs were solid on as it said in getting started tutorial of Beagleboard(dot)org
Jan 26 07:43:26 <LordSAK> SD card is 8GB
Jan 26 07:45:21 <tbr> ok
Jan 26 07:45:37 <tbr> what's the name of the image you used?
Jan 26 07:46:43 <LordSAK> this one https://rcn-ee.com/rootfs/bb.org/testing/2016-01-24/lxqt-4gb/BBB-eMMC-flasher-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img.xz
Jan 26 07:46:57 <tbr> ok
Jan 26 07:47:34 <LordSAK> we downloaded it from here
Jan 26 07:47:34 <LordSAK> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt
Jan 26 07:47:36 <tbr> please use a pastebin and paste the last 20-30 lines of dmesg output
Jan 26 07:52:11 <LordSAK> http://pastebin.com/56h3wEec here is the output
Jan 26 07:53:28 <tbr> all three are there as expected:
Jan 26 07:53:29 <tbr> [93154.038567] rndis_host 3-1.1:1.0 eth1: register 'rndis_host' at usb-0000:00:1a.0-1.1, RNDIS device, 6c:ec:eb:a4:c6:50
Jan 26 07:53:32 <tbr> [93154.039114] cdc_acm 3-1.1:1.2: ttyACM0: USB ACM device
Jan 26 07:53:35 <tbr> [93154.039791] usb-storage 3-1.1:1.4: USB Mass Storage device detected
Jan 26 07:53:59 <tbr> network as eth1, serial as ttyACM0, mass storage as sdg
Jan 26 07:56:29 <LordSAK> so any guess what is wrong??
Jan 26 07:56:43 <tbr> you can also log in to the device using e.g. "screen /dev/ttyACM0 115200"
Jan 26 08:07:23 <LordSAK> running screen commands show black screen in terminal
Jan 26 08:15:26 <tbr> you might need to throw in a sudo if your user doesn't have permissions for that device
Jan 26 08:15:52 <LordSAK> well with normal it said screen terminating
Jan 26 08:15:58 <LordSAK> and with sudo screen is blank
Jan 26 08:16:02 <LordSAK> nothing shows up
Jan 26 08:37:21 <tbr> no idea, connection to the debug UART would now be really helpful
Jan 26 08:44:51 <snowstaff> One question about pasm: how to work with registers? I mean how to know the address of each register? For example: "to enable OCP master port" needs: #define CONST_PRUCFG   C4
Jan 26 08:44:59 <snowstaff> LBCO r0, C4, 4, 4; CLR r0, r0, 4; SBCO r0, C4, 4, 4;
Jan 26 08:46:03 <snowstaff> Why r0 and C4? I can't find the address these registers in reference book.
Jan 26 08:47:12 <LordSAK> ok. here is what i have found. i connected BBB with my Windows 8 machine. it perfectly worked. on first attempt it was bad file number on ssh. but on second attempt of ssh i was able to login in my BBB
Jan 26 08:47:35 <LordSAK> right now we are having issue with our ubuntu 14.04  where it is not connecting
Jan 26 08:48:11 <LordSAK> it might be network error. We are looking into it. if you guys have any valuable suggestion then do let me know
Jan 26 08:56:41 <snowstaff> Is it right: i can use any constant register, because his adress starts from 0x00000000, and write C4+4, then I turn to SYSCFG?
Jan 26 09:00:57 <snowstaff> Oh, i'm stupid..What value have the registers Cn if they are not define in advance?
Jan 26 09:03:02 <tbr> LordSAK: you can always configure the network interface manually on ubuntu
Jan 26 09:08:09 <zmatt> snowstaff: r0 is just being used as an arbitrary temp register, the constant registers however have predefined values that are documented
Jan 26 09:09:16 <zmatt> for example C4 contains the address of the local CFG module (0x26000)
Jan 26 09:10:15 <zmatt> see section 4.4.1.1 ("Constants Table") of the TRM
Jan 26 09:12:17 <snowstaff> zmatt, i just found it. Anyway thank you very much!
Jan 26 09:14:02 <zmatt> effectively that three-instruction sequence does  *(u32 *)( constants[4] + 4) &= ~(1 << 4);
Jan 26 09:17:49 <zmatt> not sure why anyone would want to do that using a PRU core though, I would do that from the cortex-a8 as part of setting up the PRU subsystem for execution
Jan 26 09:19:59 <zmatt> (I don't even understand why that bit exists at all, but I'm sure there's some deep reason that eludes me at the moment :P )
Jan 26 09:23:26 <snowstaff> I just started using it) One moment: http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#Constats_Table - it's old table?
Jan 26 09:23:49 <zmatt> 10:10 < zmatt> see section 4.4.1.1 ("Constants Table") of the TRM
Jan 26 09:24:04 <zmatt> the table is processor-dependent
Jan 26 09:24:47 <zmatt> the one on the wiki seems to be for the OMAP-L13x
Jan 26 09:28:00 <snowstaff> Yep, it's right
Jan 26 09:31:08 <snowstaff> Waaah, it's really interesting)
Jan 26 09:31:20 <zmatt> note that the constants table contains addresses regarded as "potentially useful"... and since different processors have different address maps, the constants table will vary as well.  The OMAP-L1xx processors (aka Freon/Primus) were the first with PRU, hence there's a fair bit of PRU documentation out there that implicitly assumes that processor series
Jan 26 09:32:37 <zmatt> the Freon/Primus memory map however does not resemble the AM335x at all
Jan 26 09:34:00 <snowstaff> Of course, it's clear for me.
Jan 26 11:07:57 <ultra__> in beaglebone  where i can find UART configuration pointing to ttyO2
Jan 26 11:22:21 <snowstaff> How to fill the RAM in PRUSS?
Jan 26 11:25:22 <snowstaff> Or, how filled in constant register 24(C24)?
Jan 26 15:00:23 <yates> what does this include syntax mean: /include/ "xyz.dtsi"? seems like a normal include is like this: #include "xyz.dtsi".
Jan 26 15:00:29 <yates> in a dts, that is.
Jan 26 15:00:34 <yates> or dtsi
Jan 26 15:01:47 <yates> you see it in, e.g., am335x-bone-common-no-capemgr.dtsi
Jan 26 15:02:11 <yates> http://paste.fedoraproject.org/314899/45382052
Jan 26 15:02:27 <yates> line 231
Jan 26 15:08:44 <yates> veremit: hey!
Jan 26 15:50:57 <zmatt> yates: // is the syntax of dts itself, #include works because it's being run through cpp before being passed to dtc.  generally #include is preferred since files included with /include/ won't be preprocessed and therefore can't use constant/macro definitions
Jan 26 15:51:58 <yates> i see.
Jan 26 15:52:27 <yates> is this syntax defined in a device tree compiler document or somesuch somewhere?
Jan 26 15:52:40 <yates> i installed dtc on fedora and i don't even get a manpage
Jan 26 15:53:05 <yates> thanks for the clarification.
Jan 26 15:53:10 <zmatt> the dtc sources are included with the kernel
Jan 26 15:53:16 <zmatt> there might be docs there too
Jan 26 15:53:27 <yates> "Read the source, Luke!"
Jan 26 15:53:41 <zmatt> or at least a yacc/bison file :P
Jan 26 15:53:53 <yates> ewe, bison
Jan 26 15:54:40 <zmatt> ... "pew! ... BOOM"  https://www.spacetelescope.org/images/potw1551a/
Jan 26 15:54:59 <stt_michael> pong
Jan 26 15:56:18 <yates> cool
Jan 26 16:11:10 <yates> stt_michael: ancient computer game?
Jan 26 16:12:35 <stt_michael> yates, or a common reply to the 'ping' command :D
Jan 26 16:17:58 * yates stirs inquisitively
Jan 26 16:23:19 <yates> if you're in need of a break from device trees, pru code, kernel modules, try a derivation of the Shannon limit: http://www.digitalsignallabs.com/shannonlimit.pdf
Jan 26 16:23:27 * yates shamelessly self-promotes
Jan 26 16:35:24 <stt_michael> I'm doin spreadsheets for power consumption of electronics .. and then switching convert power supply designs after some testing
Jan 26 16:36:34 <yates> oh, you mean a pulse-width-modulated feedback control system?
Jan 26 16:37:46 <yates> very cool stuff.
Jan 26 16:38:29 <yates> i was going to design my own class-d power amp, but why bother when you can buy an excellent one from Crown for US$180?!?
Jan 26 16:38:37 <yates> so i did.
Jan 26 16:40:09 <yates> http://www.crownaudio.com/en-US/products/xls-1000
Jan 26 16:43:58 <stt_michael> wow .. $180
Jan 26 16:44:07 <stt_michael> google 'sure electronics'
Jan 26 16:44:18 <stt_michael> Much cheaper
Jan 26 16:48:25 <yates> apples/oranges
Jan 26 16:48:31 <stt_michael> indeed
Jan 26 19:16:33 <istvan> if I run /sbin/modprobe uio_pruss extram_pool_sz=MYSIZE then what address do I use from the PRU to write to that allocated memory?
Jan 26 19:26:53 <citylight2> I want to use the on-board button so I need to use the universal cape. I then want to use the ADC. After updating /opt/scripts the universal cape is not loaded.
Jan 26 19:27:02 <citylight2> hi bengi
Jan 26 19:46:45 <yates> can anyone make sense of this initialization log entry? [    4.883426] mmc1: MAN_BKOPS_EN bit is not set
Jan 26 19:46:58 <yates> it is on my breadboard boot but not on the bbb boot
Jan 26 19:47:04 <yates> exact same image on both
Jan 26 19:47:23 <veremit> hardware difference
Jan 26 19:47:47 <yates> veremit: you mean a different mmc1?
Jan 26 19:47:53 <veremit> no
Jan 26 19:48:24 <veremit> I mean one lump of hardware is different to the other, and its causing a driver to explain a setting it's applied/omitted
Jan 26 19:49:18 <yates> actually i was wrong. that line is being emitted on both, just in a different order
Jan 26 19:49:24 <yates> veremit: ok, so that seems just fine.
Jan 26 19:51:00 <yates> if anyone would care to have a look, here's the bbb boot log: http://ur1.ca/ogc40 -> http://paste.fedoraproject.org/315016/53837838
Jan 26 19:51:22 <yates> and here's our breadboard boot log: http://ur1.ca/ogc41 -> http://paste.fedoraproject.org/315017/53837875
Jan 26 19:51:24 <veremit> most non-fatal messages are innocuous
Jan 26 19:51:47 <yates> yeah, well there are some that look serious later on, i was just trying to find out where they diverge
Jan 26 19:56:19 <yates> i see this line in the bbb boot but NOT in my bb boot:          Starting Various fixups to make systemd work better on Debian...
Jan 26 19:58:29 <veremit> lol nie
Jan 26 19:58:35 <veremit> and NiCe too
Jan 26 20:00:43 <yates> nice?
Jan 26 20:01:05 <filt3r> yates: you can remove the tda998x i2c0 node and the ti,lcdc,slave node, thats causing the kernel warning with the stackdump on boot, and if i remember correctly yuo dont have the tda1988 chip on board
Jan 26 20:01:37 <yates> filt3r: thanks you. i thought i did this. let me double-check..
Jan 26 20:01:41 <yates> thank you
Jan 26 20:03:08 <filt3r> also you still have the eeprom nodes in your devicetree, if you care about that
Jan 26 20:04:09 <yates> ack.
Jan 26 20:04:14 <yates> i do.
Jan 26 20:04:36 <filt3r> and while you're at it you can also remove the bone_capemgr it seems to be not working at all with the baseboard eeprom: bone_capemgr bone_capemgr: Failed to scan baseboard eeprom
Jan 26 20:04:55 <filt3r> or, lets say, you have to remove it, because it references the eeprom nodes
Jan 26 20:05:26 <yates> i thought i had done that, too.
Jan 26 20:05:50 <yates> perhaps the rebuild overwrote my changes. my build system is lacking right now
Jan 26 20:07:15 <citylight2> I wish rcn-ee will appear
Jan 26 20:10:22 <yates> yeah, my dts changes are gone.
Jan 26 20:10:42 <veremit> citylight2: he's never around when you want him .. but he does respond to email
Jan 26 20:10:58 <yates> zmatt: btw, the problem with the network was hardware: our board assemblers installed 3 DNI resistors in that circuit.
Jan 26 20:11:11 <veremit> yates: woops!
Jan 26 20:11:21 <citylight2> but I was told that emailing a developer is a wrong way to life
Jan 26 20:11:38 <yates> citylight2: ahh, grasshopper, you learned well!
Jan 26 20:11:49 <veremit> -shrug- life's too damn short lol
Jan 26 20:11:54 <yates> lol
Jan 26 20:12:15 <citylight2> I am seeking the web for more info on this universal cape
Jan 26 20:12:23 <citylight2> how to activate it
Jan 26 20:12:29 <filt3r> which universal cape?
Jan 26 20:12:35 <filt3r> just out of curiosity
Jan 26 20:12:58 <citylight2> last night rcn-ee said: you can, if you disable the adc pins in cape universal, or load cape universal and then use config-pin for the
Jan 26 20:13:12 <citylight2> and I, I do not understand
Jan 26 20:14:13 <filt3r> ahh ok, probably he meant something regarding devicetree overlays
Jan 26 20:14:32 <citylight2> yes, that is it
Jan 26 20:16:13 <yates> filt3r: is a good way to remove the capemgr to modify am335x-boneblack.dts to substitute #include "am335x-bone-common-no-capemgr.dtsi" for #include "am335x-bone-common.dtsi" ?
Jan 26 20:17:49 <yates> i also removed the &lcdc and &i2c0/tda19988  nodes from am335x-boneblack.dts. is that correct?
Jan 26 20:18:51 <yates> those are at bb-kernel/KERNEL/arch/arm/boot/dts/
Jan 26 20:32:01 <filt3r> yates: i actually have never used the cape manager, because i use the mainline kernel and there is currently no cape manager so i cant answer that
Jan 26 20:32:38 <filt3r> regarding the lcdc and tda19988 nodes should be fine
Jan 26 20:38:49 <filt3r> yates: but by taking a quick look on the BBB kernel you probably should be fine replacing "am335x-bone-common.dtsi" with "am335x-bone-common-no-capemgr.dtsi"
Jan 26 21:27:34 <ZeekHuge> Hey ! I would like contribute to the community. How can I start ? I have already subscribed to the mailing list.
Jan 26 22:35:14 <yates> is there anything in the kernel that depends on the dts/dtb at kernel build time?
Jan 26 22:36:03 <yates> it looks like from the scripts that rcn's build.sh just compiles the dts's and then packages them up for copying into the rootfs.
Jan 26 22:37:07 <filt3r> no you can build the kernel without the DT files
Jan 26 22:37:09 <yates> i'm having a maintenance issue where the kernel build overwrites my changes. i'm thinking of just recompiling my .dts's after thekernel is build and rebuild the dtb package
Jan 26 22:37:30 <filt3r> are you building it with a script
Jan 26 22:37:36 <yates> yes
Jan 26 22:37:40 <yates> with a makefile
Jan 26 22:38:07 <yates> you mean the kernel?
Jan 26 22:38:11 <yates> it == kernel?
Jan 26 22:38:20 <filt3r> usually on the mainline kernel you have to build the dtbs explicitly with make dtbs
Jan 26 22:38:38 <yates> for that i'm using rcn's build.sh
Jan 26 22:39:01 <yates> and children...
Jan 26 22:40:29 <filt3r> you can just comment out the buildig and copying of the devicetree files out of your buildscripts or just rebuild and copy your own DTs to the rootfs after the kernel build is done
Jan 26 22:40:39 <yates> in fact that's the maintenance problem. to get my dts changes in i'd have to change rcn's build.sh (or the dtbs makefile), which are both "independent" of my project changes. it would be ugly to hack them, as far as i can see
Jan 26 22:41:07 <yates> true.
Jan 26 22:42:42 <yates> his build scripts are complicated.
Jan 26 22:42:50 <filt3r> can you post a link to them?
Jan 26 22:43:41 <yates> https://eewiki.net/display/linuxonarm/BeagleBone+Black
Jan 26 22:44:33 <yates> i'm usin gthe longterm 4.4.x (non-realtime)
Jan 26 22:44:59 <yates> then that top-level build, bb-kernel/build_kernel.sh
Jan 26 22:46:09 <yates> plus i'm weak on bash shell scripts.
Jan 26 22:49:26 <yates> i can pick through it, but it's tedious. probably would be for anybody...
Jan 26 22:51:45 <filt3r> ok so you have three options, either remove the making and instlling of the dtbs from the build_kernel.sh script, or just rebuild and copy your dtb file after the kernel build was done, or just copy your modified devicetree files into the kernel and replace the existing ones and check them into your local copy of the tree, depending on your situation, any option is valid :D
Jan 26 22:54:09 <yates> it doesn't look you can do that last option because there are patches applied to the .dts files
Jan 26 22:54:23 <yates> i.e., before they get dtc'ed.
Jan 26 22:54:36 <filt3r> ohh ok, in that case it wont work that easy
Jan 26 22:55:03 <yates> i'm leaning toward the second.
Jan 26 22:55:07 <yates> second option
Jan 26 22:59:02 <filt3r> hmm strange, the build_kernel.sh script just creates a different archive for the dtbs files and in this guide which you posted it instructs you to extract it manually
Jan 26 22:59:02 <filt3r> sudo tar xfv ./bb-kernel/deploy/${kernel_version}-dtbs.tar.gz -C /media/rootfs/boot/dtbs/${kernel_version}/
Jan 26 22:59:28 <filt3r> so unless you have this somewhere in your own script it should not extract it to the rootfs
Jan 26 23:03:13 <yates> i do have it in my own script, of course
Jan 26 23:04:25 <filt3r> well then it is writing the dtbs from the kernel source tree everytime to the rootfs again and overwriting any dtbs you placed before
Jan 26 23:07:03 <yates> you have to generate those dtbs as well
Jan 26 23:07:17 <yates> that's been troublesome (for me)
Jan 26 23:07:41 <yates> i just discovered in like the past 60 seconds that the kernel apparently buidls and uses its own dtc!
Jan 26 23:08:00 <yates> bb-kernel/KERNEL/scripts/dtc
Jan 26 23:08:22 <filt3r> yes, if you run make dtbs in a kernel source tree it will call this dt-compiler
Jan 26 23:09:02 <yates> where in the kernel source tree?
Jan 26 23:09:10 <yates> there are Makefiles all over creation
Jan 26 23:09:47 <yates> and there aren't command-line options (variable definitions, e.g.) necessary?
Jan 26 23:09:52 <filt3r> achr/arm/Makefile or somewhere there
Jan 26 23:10:21 <filt3r> and in arch/arm/boot/dts/Makefile
Jan 26 23:10:22 <yates> make: *** No rule to make target 'prepare', needed by 'dtbs'.  Stop.
Jan 26 23:10:34 <filt3r> is the list of dtbs whcih gets build
Jan 26 23:10:50 <yates> http://ur1.ca/ogck7 -> http://paste.fedoraproject.org/315101/53849847
Jan 26 23:11:00 <filt3r> yes
Jan 26 23:11:13 <yates> that doesn't work.
Jan 26 23:11:53 <filt3r> you need to specify arm and your crosscompiler
Jan 26 23:11:56 <yates> i saw that already, but it's squirrelled so many levels down and with so many contigent parameters (variables, options, etc) it's freakin' impossible to decode
Jan 26 23:12:07 <yates> contingent
Jan 26 23:12:13 <filt3r> like ARCH=arm CROSS_COMPILE=... make dtbs
Jan 26 23:12:31 <filt3r> but the build_kernel.sh script does all this for you
Jan 26 23:13:02 <filt3r> it literally calls make dtbs on line 80
Jan 26 23:13:07 <yates> yeah, but it does that AFTER it checks out and patches the standard dtbs
Jan 26 23:13:14 <filt3r> yes thats true
Jan 26 23:13:31 <yates> dts's, rather
Jan 26 23:13:53 <yates> are you talking about this: http://ur1.ca/ogcka -> http://paste.fedoraproject.org/315102/45384996
Jan 26 23:14:48 <yates> which is in bb-kernel/KERNEL/arch/arm/
Jan 26 23:14:52 <yates> which is in bb-kernel/KERNEL/arch/arm/Makefile
Jan 26 23:15:12 <yates> tell me again how simple this is?
Jan 26 23:15:20 <yates> :)
Jan 26 23:15:25 <filt3r> ye never said kernel makefiles are simple
Jan 26 23:15:41 <filt3r> but here the script calls this make dtbs for the kernel tree https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.4/build_kernel.sh#L80
Jan 26 23:16:22 <filt3r> and the script should create an archive which is called ${kernel_version}-dtbs.tar.gz
Jan 26 23:16:23 <yates> true.
Jan 26 23:16:29 <filt3r> this archive only contains the dtbs
Jan 26 23:16:44 <yates> yes, i see all that.
Jan 26 23:16:58 <filt3r> and since you are building your dtbs outside of the kernel tree there should be no need to extract that archive to the rootfs
Jan 26 23:17:25 <yates> huh?
Jan 26 23:17:26 <filt3r> you just need to copy your out of tree dtbs to the right place on the rootfs
Jan 26 23:17:47 <yates> oh, well sure, right.
Jan 26 23:17:48 <filt3r> arent you building your dtbs outside of the kernel tree?
Jan 26 23:18:22 <filt3r> you actually need to copy am335x-boneblack.dtb to
Jan 26 23:18:30 <filt3r> to /media/rootfs/boot/dtbs/${kernel_version}/
Jan 26 23:18:34 <filt3r> that should do the trick
Jan 26 23:18:38 <yates> nope
Jan 26 23:18:42 <yates> well, that's another thing. there are so many dependencies between dts/dtsi files, i don't think that's feasible.
Jan 26 23:19:05 <filt3r> well if its already compiled there should be no dependencies
Jan 26 23:19:13 <yates> huh?
Jan 26 23:19:44 <yates> it ISN'T getting compiled there.
Jan 26 23:19:53 <yates> BECAUSE it has dependencies
Jan 26 23:20:03 <yates> back to a bunch of stuff in the tree.
Jan 26 23:20:11 <filt3r> im talking about the dtb files which are already compiled
Jan 26 23:20:25 <filt3r> ok, so how are you building your own dtbs?
Jan 26 23:21:20 <yates> well i was using the x86 dtc to begin with, which may have been a mistake
Jan 26 23:21:52 <yates> but i copied over am335x_beaglebone.dts and the common dtsi into my own folder and ran dtc on the .dts
Jan 26 23:21:58 <yates> and got parse error
Jan 26 23:22:10 <yates> and if you trace the includes, you see they grow like a mother.
Jan 26 23:22:51 <yates> i think it would be more reasonable to copy my changed files back into the tree and rerun the dtb package build.
Jan 26 23:23:30 <yates> after the kernel has been built
Jan 26 23:23:34 <yates> yeah.
Jan 26 23:23:38 <yates> that sounds like a plan.
Jan 26 23:24:02 <yates> probably makes the hardcore developers here puke, but what the hay, if it works..
Jan 26 23:29:09 <filt3r> yes if you dont specify FULL_REBUILD the build_kernel.sh script should not try to apply the patches
Jan 26 23:29:22 <filt3r> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.4/build_kernel.sh#L214
Jan 26 23:29:32 <filt3r> otherwise it will try to apply the patches and fail
Jan 26 23:31:31 <filt3r> another i think decent solution would really be to rename the dts and dtsi file which you have to your boardname or something else, and add it to ther arch/arm/boot/dts/Makefile list, also don't forget to instruct u-boot to load your dtb
Jan 26 23:34:32 <filt3r> but just out of curiosity, how were you creating your dtb before?
Jan 26 23:34:58 <yates> there was no before
Jan 26 23:35:11 <yates> before = standard 4.4-bone2 kernel from rcn
Jan 26 23:35:40 <filt3r> hmm ok
Jan 26 23:35:58 <yates> i am in midst of my attempt to customize for my board the first time.
Jan 26 23:36:20 <yates> does that make sense?
Jan 26 23:36:43 <filt3r> yes but werent you already making changes to the dts yesterday or something like that?
Jan 26 23:36:50 <yates> ha ha.
Jan 26 23:36:55 <yates> it is THESE changes!
Jan 26 23:36:58 <yates> i am SLOWWWWW....
Jan 26 23:37:22 <yates> i spent some time coming up to speed on the dt thing (again).
Jan 26 23:38:02 <yates> "that was yesterday" (old Foreigner song)
Jan 26 23:38:27 <filt3r> hmm ye, my recommendation is really to create a differently named dts file, etc. which the patches won't touch and won't complain about
Jan 26 23:39:03 <yates> yes, i heard you the first time.
Jan 26 23:39:14 <yates> :)
Jan 26 23:39:28 <filt3r> :)
Jan 26 23:54:33 <yates> filt3r: i understand what you are getting at. it's a different board, and that's the whole idea of device trees. but i'm just taking a baby step right now, especially since i'm the long pole in the tent
Jan 26 23:54:42 <yates> in the future, yet
Jan 26 23:54:52 <yates> yes
Jan 27 02:04:00 <Micro|MTW> << newbie.  Been messing with my new BBB for a couple days trying to get it to take a SD card flash upgrade. I hold the boot button until i get the 4 leds all on then there are some flashing leds. I wait an hour and it never turns on the leds again as the instructions say.  I am using an external 5 volt power supply.  The image that shipped on my unit is close to a year old so i am guessing it could use the update but I am a bit lost.
**** ENDING LOGGING AT Wed Jan 27 02:59:59 2016