**** BEGIN LOGGING AT Thu Mar 10 02:59:58 2016 Mar 10 05:39:10 hello everyone Mar 10 05:40:17 was wondering if there is a workaround to a problem with apt-get update on my beagleboard Mar 10 05:40:34 Cornelius: what problem is that? Mar 10 05:40:47 Err http://repos.rcn-ee.com wheezy Release.gpg Cannot initiate the connection to repos.rcn-ee.com:80 (2600:3c00::f03c:91ff:fe37:6ad5). - connect (101: Network is unreachable) [IP: 2600:3c00::f03c:91ff:fe37:6ad5 80] Mar 10 05:40:58 i encounter this error Mar 10 05:41:02 which i find quite strange Mar 10 05:42:38 i can ping that website from the BBB though Mar 10 05:43:53 any suggestions, please? Mar 10 05:52:25 hi everyone,..i am new to beaglebone black Mar 10 05:52:51 i have tried to apt-get update but encountered the following error message Mar 10 05:53:02 Err http://repos.rcn-ee.com wheezy Release.gpg Cannot initiate the connection to repos.rcn-ee.com:80 (2600:3c00::f03c:91ff:fe37:6ad5). - connect (101: Network is unreachable) [IP: 2600:3c00::f03c:91ff:fe37:6ad5 80] Mar 10 05:53:14 was wondering if anyone could help me, please? Mar 10 06:08:42 ... not if you don't stick around :P Mar 10 13:09:59 I'm having some problems with my bbb rev.b6: Powering it up by usb with or without the sd-card makes only the power light glow and nothing else. It's booted fine earlier by these means but all of a sudden no such cigar. Tips? I'll test with a 5v dc later, but I've got none available right now Mar 10 13:12:09 m0b: do you have access to the debug UART? Mar 10 13:12:30 m0b: what was attached to the BBB when it was still working? Mar 10 13:17:26 No I don't have a usb-serial cable available either :/ The bbb was working with sd-card and network cable and it booted with blinking lights with and without the sd and network attached. I do however get events in dmesg when I plug it in Mar 10 13:17:40 https://www.irccloud.com/pastebin/Dg4b94Fk/ Mar 10 13:19:46 ok, then it's probably not dead Mar 10 13:20:01 it probably can't find a boot-loader Mar 10 13:20:33 try inserting a bootable microsd, holding down the S2 button next to the sd slot and powering it up Mar 10 13:22:31 Okay, I'll write a new image to the sd and try booting it again. If the problem is that is cannot find bootloader and will not boot from the sd card afterwards, i'm guessing I probably need to connect with serial and fix it myself? Mar 10 13:34:45 did you have to push a button to make it boot from SD? Mar 10 13:35:01 I mean when it still worked Mar 10 13:39:18 It actually booted from the sd without pushing the button near the sd card slot Mar 10 13:40:28 yeah, then it was using MLO on the eMMC Mar 10 13:40:40 you shouldn't need to reflash the SD card, probably Mar 10 13:40:51 just hold down S2 before you power up the board Mar 10 13:41:59 With a new image on the card, it boots now. Or at least, the other lights are flashing in random order Mar 10 13:42:01 Nice Mar 10 13:42:42 I might have corrupted the data on the card earlier with a unclean shutdown or something? Mar 10 13:43:07 no idea what happened but it seems you've lost the bootloader on the eMMC Mar 10 13:52:12 Okay, thanks for the input! :) I wrote this image to the sd-card: bone-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img - the rev6b only got 2 gigs available on the emmc: I need to go for a smaller/older 2GB image, or is running it off the sd card just fine? Mar 10 13:54:43 that image isn't a flasher anyhow, so it'll just run off the sd card Mar 10 13:56:03 indeed if you want to flash eMMC you'd need a 2gb version of a flasher... I think the main thing missing from it is the Chromium web browser Mar 10 14:07:20 SD seems faster anyways. At least with a rudimentary dd test. Also, it's quite bigger with the size of 64gig. Main idea was to run the operating system from emmc and mount the sd card. But yes, I'll just run it all from the sd card. IO/queue wont be too much of an issue Mar 10 14:20:15 I'd have thought emmc is faster than sd, because higher clock and more data lanes? Mar 10 14:28:06 depends on the emmc Mar 10 14:34:35 Well, here's my "performance test": Mar 10 14:34:38 https://www.irccloud.com/pastebin/SrqBEjNu/ Mar 10 14:46:32 eMMC could have been faster, if they didn't use the cheapest they could find :P Mar 10 14:47:15 I noticed the kingston is considerably faster than the micron... it's basically random which of the two you get on a rev C Mar 10 14:47:28 the 2g prior to rev C was all micron I think Mar 10 14:47:42 of course with SD card it'll depend heavily on the card Mar 10 14:47:53 its like a box of chocolates Mar 10 15:45:01 zmatt: are you Matthijs van Duin from the ti e2e forum? Mar 10 15:45:43 yup Mar 10 15:47:11 zmatt: you've been in a few discussions there related to LCDC, so in case you're interested: the tilcdc improvements should be in the mainline v4.6. also, I recently found a way to make the underflows/synclosts disappear (which seem to cause all kinds of interesting issues), at least for me Mar 10 15:47:41 there's a REG_PR_OLD_COUNT field in an EMIF register, tuning that seems to make the problem go away Mar 10 15:47:41 tomba: filt3r here is also actively investigating LCDC issues Mar 10 15:48:09 apparently LCDC can and does underflow without reporting it as such Mar 10 15:48:13 for example, doing "mw 0x4C000054 0x00ffff07" in u-boot, and all the underflows went away Mar 10 15:49:09 right, although setting PR_OLD_COUNT that low obliterates any kind of prioritization within EMIF, so that's not going to be good for overall performance I'd imagine Mar 10 15:49:46 yes, I guessed that much, but I don't know much about EMIF. I've still to find someone who does. Mar 10 15:50:15 a bit higher values worked fine too. Mar 10 15:50:20 I'm also wondering about MReqPrio, since you can configure it via control module for several initiators, but e.g. not LCDC Mar 10 15:50:36 so I assumed the dma priority register in LCDC itself would control that, but according to the wiki it has no effect Mar 10 15:50:59 but apparently there's some kind of LCDC hw issue, where the IP can go into some kind of bad state, flooding sync losts. things like display shifted a bit can happen in those cases. Mar 10 15:51:37 yes, it looks like the async fifo may be buggy (which, I hate to say, doesn't entirely surprise me) Mar 10 15:52:44 EMIF also has this class-of-service prioritization stuff, which, afaics, should help to make LCDC prioritized. but I haven't gotten that to work either. Mar 10 15:53:29 I'm actually experiencing yet another lcdc issue which is even more bizarre, although it again involves a 32-pixel delta so it may in fact also be originating in the fifo (I sure have no idea where else it might come from) Mar 10 15:54:51 on this system, which has CONFIG_VT disabled and a graphical app on the framebuffer, pixel(x,y) of the screen actually displays pixel( x == WIDTH-1 ? x - 32 : x, y ) of the framebuffer Mar 10 15:55:37 it's not the app's fault, /dev/fb0 has correct content and the phenomenon is also exhibited if I just write an image directly to /dev/fb0 Mar 10 15:55:51 and it's perfectly stable and consistent Mar 10 15:56:08 how's that for weird :) Mar 10 15:58:25 hrm... well, all the shift problems I've seen have been related to sync lost, and temporary (although they may stay for a long time). so that's maybe something else. when you say it's shiften, you mean you've verified that from the video signal? Mar 10 15:59:19 so there's no shift as such but pixel 1023-32 of every line is copied to pixel 1023 Mar 10 15:59:35 this does not happen under x11 Mar 10 16:00:13 and when I still had a framebuffer console I did get the well-known 32-pixel shifting phenomenon Mar 10 16:01:05 ah right, I see Mar 10 16:01:24 I haven't verified yet whether disabling CONFIG_VT was indeed responsible for making the 32-pixel shifting phenomenon disappear and replacing it by the copied-column symptom Mar 10 16:02:12 same kernel with a very small hdmi screen (instead of the 1024x768 lvds panel) did not show any symptom Mar 10 16:02:57 have you tried tuning the PR_OLD_COUNT? I think that's a good test to pinpoint the possible cause of the issue, even if it may not be viable in the product. Mar 10 16:03:36 no, I haven't yet had time since I learned about this Mar 10 16:04:40 at least now the weird SYNC_LOST issues in that long e2e thread make a lot more sense.... lcdc underflowing but misreporting this as a sync lost seems a _lot_ more plausible than hitting a several nanosecond race condition window many times in a row Mar 10 16:05:37 yes, I also find it rather unbelievable that the driver would change the two registers _just_ at the vblank (or whatever is the exact time when the HW gets the new base addresses) Mar 10 16:06:23 then again, that's still the only explanation I know to the show-all-memory-problem, where LCDC apparently goes on showing all of the RAM Mar 10 16:06:33 so I don't remember if the changes ultimately solved his problem, but if so it probably did it by changing the timing in such a way to move heavy cpu/gpu activity to a less critical time Mar 10 16:07:07 hmm Mar 10 16:07:52 hmm then again, sync lost flood causes lots of irqs, which could slow down the thread that updates the base registers... Mar 10 16:09:22 anyway, I need to go. just wanted to inform you about my findings. and I hope we find an EMIF guy who can give us good values for the priorities to make the underflows go away, and thus, hopefully, removeing most of the odd issues. Mar 10 16:09:41 it would also be nice if someone with access to the lcdc design would take a good look at it and produced some notes on how it works *exactly*... but that's probably too much to ask for :/ Mar 10 16:09:57 especially around sync lost and its recovery there's so much vagueness Mar 10 16:10:31 yeah, that's another thing I hope for. but it's such an old IP, all the guys have left TI long ago, etc... =) but I'll keep pinging. Mar 10 16:10:40 well it was updated for am335x Mar 10 16:11:03 (relative to omap-L13x) Mar 10 16:11:29 so someone at least tinkered with it Mar 10 16:12:08 unfortunately, it seems that whenever the word "async" shows up, chip errata seem to show up alongside :P Mar 10 16:13:04 I also discovered that the uart fifo pointers get corrupted if you write more than 8 bytes with consecutive writes (even if the fifo has plenty of space) Mar 10 16:13:19 "fortunately" every uart driver seems to be too inefficient to ever trigger this **** ENDING LOGGING AT Thu Mar 10 17:12:40 2016 **** BEGIN LOGGING AT Thu Mar 10 17:14:17 2016 Mar 10 18:57:15 hi all Mar 10 18:58:51 question "has anyone faced any issues regarding nodejs update on BBB debian installed" Mar 10 20:11:47 Does anyone have any sending a shutdown command to the PHY from the MDIO_DAT and MDIO_CLK lines? Mar 10 20:24:35 hey ! I was experimenting and I disabled some imp dt in /boot/uboot/uEnv.txt. the BBB now wont boot. the heartbeat led is blinking though. but no other led lights up. Mar 10 21:12:15 Hi, I have an early BBB with the 2 gig emmc. I like the latest rcn debian build with the lxqt window manager but it's too big to flash. Should I find a 2 gig os to flash or just forget about it? Mar 10 21:18:49 you can still load what u want from a sd card Mar 10 21:19:03 yup, I can Mar 10 21:19:08 without using emmc Mar 10 21:19:31 if you want to flash emmc you need to find a 2G flasher Mar 10 21:19:39 whatever it is Mar 10 21:19:48 what about mounting my emmc and using it for a sort of retained heap? Mar 10 21:20:16 you vsn do it easy after u boot from sd Mar 10 21:20:24 is just a linux Mar 10 21:21:05 pay much more attenction when you turn off power Mar 10 21:21:09 is you boot from sd Mar 10 21:21:28 always use halr reboot or the provided buttons Mar 10 21:21:47 I always do Mar 10 21:21:49 sorry im typing in the dark Mar 10 21:21:58 full of typos Mar 10 21:22:16 I though you cyrillic Mar 10 21:22:22 were Mar 10 21:22:42 there Mar 10 21:23:07 its starting to get funny Mar 10 21:24:05 dark typer mimics an accent and hilarious misunderstandings ensue Mar 10 21:25:50 snd they stab you in the back easyly since they can type in the dark :) Mar 10 21:27:03 always a sinister motive Mar 10 21:27:40 like a emmc not flashing correctly for example :) Mar 10 21:28:26 twoten: there are both 4g and 2g images here elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_lxqt Mar 10 21:29:27 rcn-ee: btw, why is the iot image 4g even though it should obviously fit just fine in 2g ? Mar 10 21:32:55 thanks! Mar 10 21:34:57 zmatt, there's a decent sized 3rd party application incoming, after it lands we will re-adjust the size. Mar 10 21:36:09 ok Mar 10 21:36:36 but yeah, it should fit in 2gb. ;) Mar 10 21:36:59 my impression was that it was like the lxqt image, except without the GUI? that would finally have filled the vacuum between the extremely minimal console image and the full-blown GUI Mar 10 21:37:24 plenty of people have no use for the GUI Mar 10 21:37:49 and this should make them happy. ;) Mar 10 21:37:59 and having more free space is useful... at least one person here recently had a system hosed due to running out of space while installing updates Mar 10 21:38:19 as long as they us bmap to write it to the microSD, the 2gb vs 4gb doesn't matter too much, it's just dd that it's twice as slow then.. Mar 10 21:38:48 the 4g won't install on a 2g eMMC Mar 10 21:39:16 true Mar 10 21:39:18 I still don't understand why you don't just minimize the filesystem images and expand-to-fit afterward Mar 10 21:39:25 that's what I always do Mar 10 21:41:01 just haven't looked into it since wheezy, back then it was buggys, that's when we put in the "./grow_partion.sh" script.. Mar 10 21:41:37 and with one partition it should be way easier. ;) Mar 10 21:41:44 oh btw, I've been able to identify the tps65217 driver crash some people with a BBW have on RT kernels. CircuitCo started making BBWs with am335x rev 2.0 but neglected to fix the polarity of the tps irq signal (the pcb was already designed to allow this, it's a matter of moving one 0-ohm resistor) Mar 10 21:42:06 so on those boards, the tps irq gets persistently asserted Mar 10 21:42:20 oh great, did they bump the eeprom value? Mar 10 21:42:21 am335x rev 2.1 I mean Mar 10 21:42:31 no idea Mar 10 21:43:08 on non-RT apparently linux switches to irqpoll or something, but that's of course not really a solution since it'll continuously burn cpu time Mar 10 21:43:14 next time bing me, have them run: https://github.com/RobertCNelson/boot-scripts/blob/master/device/bone/tester/show-eeprom.sh Mar 10 21:43:27 disabling the irq in DT is a workaround Mar 10 21:43:34 you just lose the power button... which the BBW doesn't have anyway Mar 10 21:43:34 i pray CircuitCo bumped the revision field.. Mar 10 21:44:00 well even if they didn't it's still easy to detect this Mar 10 21:44:38 but I think they bumped the revision Mar 10 21:44:49 at least in name, so I'm assuming also in eeprom Mar 10 21:46:56 zmatt, i thought this was funny today: http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=commit;h=17d192b999ee904ced223c16cef76111a51c461b Mar 10 21:47:04 in any case, clearing the tps irq (by reading register 0x02 of the pmic) and then checking whether bit 7 of the register at 0x48200080 (iirc) is set will identify such boards Mar 10 21:47:28 "if" only "if", we had wired the phy reset lin on the am335x... then we'd sove that random "phy" id on bootup problem for good . ;) Mar 10 21:47:39 yes Mar 10 21:47:46 and the pmic irq should never have been connected to this pin Mar 10 21:47:53 but to some gpio0 pin Mar 10 21:48:29 I don't understand the irq pin used... it has no benefits, only downsides... including that it can only be received by the cortex-a8 Mar 10 21:48:54 in particular, it can't be received by the wakeup-m3, so hilarously you can't wake up a BBB from suspend using the power button thanks to that Mar 10 21:49:07 any gpio0 pin can be used as a wakeup source, but not the power button Mar 10 21:49:22 nicely done Mar 10 21:50:46 and yes the phy should have had manual reset, especially since the processor reset signal is not really asserted long enough for the PHY Mar 10 21:51:48 (it's extended in a ugly way using the fat RC, but that's quite gross and it's still only marginal, and possibly the cause of the phy address issue) Mar 10 21:54:42 in other news: there's been process in hunting down lcdc issues... apparently activity from the cortex-a8 (or probably other masters) can stall lcdc reads long enough to cause its fifo to underflow... that's something lcdc should report via irq but apparently it doesn't and just causes display shifting (if it only underflows initially) or heavy glitching (if it underflows repeatedly/heavily) Mar 10 21:54:51 s/process/progress/ Mar 10 21:56:12 it should be fixable by meddling with priorization, except noone really seems to know for sure how those poorly-documented mechanisms actually work :P Mar 10 21:56:34 maybe a bus stall? Mar 10 21:56:54 prioritization in EMIF's command queue seems to be the culprit Mar 10 21:58:04 so far the only reliable fix found is setting PR_OLD_COUNT to a very low value, but that effectively prevents almost all prioritization/reordering and will probably be detrimental to overall performance Mar 10 21:59:27 filt3r and collegues have been trying to get LCDC prioritized specifically but so far it hasn't worked Mar 10 21:59:34 tomba has been digging into this too Mar 10 22:02:02 the fact that lcdc doesn't properly terminate with an error on underflow but instead just spews garbage to the lcd output also seems like a hw erratum to me :P Mar 10 22:07:56 maybe I'll try to finally finish the emif init code in my baremetal codebase, then I can relatively easily perform some tests to fill the gaps in our collective knowledge of prioritization Mar 10 22:08:43 getting the L3 statistics collectors to work would probably also be quite useful, but that will probably still take more time than I have available right now Mar 10 22:10:05 (they can used e.g. to produce a request latency histogram for some initiator) **** BEGIN LOGGING AT Thu Mar 10 22:35:18 2016 Mar 11 02:07:03 this is Annamalai here, have a query on beagle board /Sitara Mar 11 02:07:40 where to get BIOS/Linux Android environment? Mar 11 02:08:03 also need to have Audio Bring Up Guide on Sitara using external Cape/Codec **** ENDING LOGGING AT Fri Mar 11 02:59:58 2016