**** BEGIN LOGGING AT Sun Jun 05 02:59:58 2016 Jun 05 03:20:19 Flashing my Beaglebone black rev c with the latest Debian 8.4. It does the cylon pattern for a while but then goes into blinking all 4 LEDs in a double pattern, http://i.imgur.com/FydXUNW.gif - Even when keeping it in this state for while, it never goes to a solid state to indicate it successfully flashed. If I power it off, remove the SD card, it just Jun 05 03:20:19 blinks the first LED which is the mmc scan? I have tried flashing the eMMC twice now but both times it has gone into double blink of all 4 LEDs. What does this mean? Jun 05 03:21:48 some sort of failure while flashing Jun 05 03:22:21 are you sure you have a rev C beaglebone? (4GB of eMMC rather than 2GB) Jun 05 03:24:25 did they implement a led-flash fault sequence ever?! Jun 05 03:24:56 the obvious statement is to serial in and someone monitor/manually execute the flasher .. which -should- be possible .. Jun 05 03:25:12 iirc you can disable the flasher at init .. then you can run manually .. I -think0 Jun 05 03:25:26 the flasher should normally work fine though Jun 05 03:25:36 zmatt: -should- being the operative word ;) Jun 05 03:25:59 well I don't use it myself, but I've only ever heard of 4-leds-flashing failure by people who tried to flash a 4G image onto a 2G eMMC Jun 05 03:26:30 (I really think the flasher ought to check for this right at the start) Jun 05 03:26:32 yes I could imagine that being a problem lol Jun 05 03:26:41 zmatt: and inform you how?! Jun 05 03:26:50 knight-rider leds?! lol Jun 05 03:27:25 yes, except right away instead of having it overwrite the whole eMMC and only then give an error Jun 05 03:27:30 usin the LEDs as a 4bit char array would be cool .. haha Jun 05 03:27:44 I have a rev. B and rev. C so I am just double-checking to make sure. The best way is to just check the storage capacity once booted? Jun 05 03:28:14 the label on Px should say .. Jun 05 03:28:24 serial Jun 05 03:28:26 serial Jun 05 03:28:28 ohffs Jun 05 03:28:35 serial label on P8 on mine has a 'C' Jun 05 03:29:36 the brand or part number of the eMMC can clarify it too Jun 05 03:30:00 if checking size, be sure the check the size of the whole thing and now the size of the partition Jun 05 03:30:11 It looks like I was mistaken on which one I was using. So I was using the rev. B. I'll go google but what is the latest image for the rev B? Jun 05 03:30:39 they're still being made with some frequency Jun 05 03:30:46 zmatt: Thank you for the help :) Jun 05 03:31:14 for some annoying reason the IoT images, even though they ought to fit on much smaller, have been sized at 4G Jun 05 03:31:35 that's fixable by shrinking the fs before flashing though Jun 05 03:31:57 (I don't understand why rcn doesn't just ship images shrink to minimal size and auto-expand them after flashing) Jun 05 03:32:03 *shrunk Jun 05 03:32:33 chromiumµostly Jun 05 03:33:03 why the desktop image is a driving force I dunno Jun 05 03:33:08 I tjhink office was the other Jun 05 03:33:18 should have a separate 'desktop' image imho Jun 05 03:33:33 chromium is the diff from lxqt-2g to lxqt-4g Jun 05 03:33:46 the iot images have no gui at all Jun 05 03:33:54 just the web stuff and such Jun 05 03:34:19 there's no reason for them to be 4gb then .. surely?! wtf is _ON_ there!? Jun 05 03:36:35 last time I checked, empty space. that's why I said you can simply shrink the fs before flashing and it'll fit just fine Jun 05 03:37:01 well that s... daft .. Jun 05 03:38:12 the whole notion of writing a "full" eMMC image is daft (never mind that the Kingston 4G eMMC and the Micron one aren't exactly the same size) Jun 05 03:39:21 I always create a partition at 4 MB till end of eMMC, copy over the image (shrunk to min size in advance), and then expand to fit using resize2fs /dev/whatever1 Jun 05 03:39:43 you should submit patches to the script, zmatt :P Jun 05 03:41:08 it's not really a patch, I use a wholly different procedure :P I've never made a flasher SD card, I've always used usb Jun 05 03:42:27 bbblfs needs fixing too Jun 05 03:43:21 I've already successfully used dnsmasq instead. I still want to rebuild the image itself though since it has some iffy things Jun 05 03:48:04 well the buildroot(?) scripts are all in RN's github ofc :) Jun 05 03:48:09 or the bb one .. Jun 05 03:50:08 i like the looks of netinstall.... Jun 05 03:50:29 not really Jun 05 03:51:03 once linux boots it fetches nothing further (in fact it has no network to fetch anything from) Jun 05 03:52:24 heh Jun 05 03:52:34 wait are you talking to me Jun 05 03:52:51 zmatt: what's the barest image you've seen around .. how small is the console one? Jun 05 03:53:15 I think I was badgering RN for a package list .. maybe its around in the GH repo Jun 05 03:53:26 ok .. gonna head to office for a bit .. BBL on the alter ego Jun 05 03:53:41 the console images are not bare enough in any case... so far I've always been able to remove some crap from them ;) Jun 05 03:53:54 just download an image and to dpkg --get-selections Jun 05 03:54:09 or --get-selection, can't remember Jun 05 04:11:24 Trying to flash the `bone-debian-8.2-osd3358-2015-12-07-2gb.img.xz` image on a rev. B but doesn't give any activity when pushing the user boot button (this is after uncommenting the uEnv.txt line to enable the flasher). Is there something special about the "osd" image? Seems unique in this list https://debian.beagleboard.org/images/ Jun 05 04:12:17 note that the S2 button only has effect if it's held down while power is applied Jun 05 04:12:46 (the cpu samples it as soon as the hardware power-on-reset line is released) Jun 05 04:13:50 I have attempted multiple times with the S2 button down, then applying power but only the power LED is on. If I don't push it, it boots off of the SD card just fine Jun 05 04:14:08 then the card lacks a bootloader Jun 05 04:15:07 what happens if that you initially boot from eMMC, but its bootloader then gives precedence to booting linux from SD card rather than eMMC Jun 05 04:15:13 also, that images has a really really weird name Jun 05 04:15:26 osd3358 is a module not used on a beaglebone black Jun 05 04:16:31 Just applied power without S2 held and now it is doing the cylon pattern. Guess the flashing process is slightly different with this one. I mentioned it working off the SD card fine because that is how I was able to uncomment the line Jun 05 04:17:26 the osd image is definitely the wrong one though Jun 05 04:18:02 hmm, guess I'll fallback to the Debian 7.5 ones listed there. Thanks for the info Jun 05 04:18:36 just use an lxqt-2g image http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#microSD.2FStandalone:_.28lxqt-2gb.29_.28BeagleBone.2FBeagleBone_Black.2FBeagleBone_Green.29 Jun 05 04:18:42 yuck that url Jun 05 04:19:22 of course the console image is an option too, but it's extremely minimal and meant for people who prefer to start fresh and then just install what they want (rather than trying to free disk space by getting rid of crap) Jun 05 04:20:24 Thanks for the shout though, wasn't quite aware of that list of images. That looks perfect Jun 05 04:20:30 the iot image is inbetween the two, but can't be flashed directly due to the technicality discussed earlier: for some reason it's been built as a 4gig image Jun 05 04:20:59 resizing it shouldn't be hard though, and it ought to fit comfortably on 2g I think Jun 05 04:21:20 (they're 430M compressed) Jun 05 04:22:01 The iot images you are referring to are signified by what? Jun 05 04:23:27 the iot images are afaik supposed to be somewhere inbetween the very spartan "console" image and the everything-and-the-kitchensink lxqt images. afaik they don't have any X11 but still include the webserver and bonescript and such Jun 05 04:23:44 oddly though the images seem only barely smaller than lxqt-2g Jun 05 04:23:51 no idea what's on them Jun 05 05:25:18 error: Error enabling PWM controls: Error: ENOENT, no such file or directory '/sys/devices/ocp.3/bs_pwm_test_P8_19.15/polarity' why this error happens? Jun 05 05:31:54 it's presumably named differently Jun 05 05:32:05 sysfs paths are not stable, never meant to be either Jun 05 07:17:45 jeeze my new bbb is so finicky about giving me an ip over usb... reset reset reset reset Jun 05 08:30:51 Hey ! Jun 05 08:31:23 I am using BBlfs by vvu .. and its probably stuck with the message "Putting the BeagleBone Black into flashing mode!" Jun 05 08:32:14 It was GSoC2103 project and as things here at BB.org change very fast, I doubt if BBlfs still works. Jun 05 08:33:24 ZeekHuge: it does work, but there are some bodges you have to make .. I can't recall exactly what .. someone might have documented it though Jun 05 08:33:31 I used it successfully one one of my boards Jun 05 08:34:06 one on** Jun 05 08:36:03 veremit: okay, but there is no error or something, its just stuck Jun 05 08:36:23 and i think its getting detected as rndis Jun 05 08:36:38 http://paste.ubuntu.com/17023005/ Jun 05 08:37:33 ah you should get mass storage ... Jun 05 08:38:28 but .. I don't remember exactly how it works .. I think it boots via bootp from your PC .. downloads an image .. runs it .. which maps the emmc as mass storage Jun 05 08:38:33 and the command i used was Jun 05 08:38:35 sudo ./flash_script.sh /home/zeekhuge/BBB-blank-debian-8.4-iot-armhf-2016-05-31-4gb.img.xz Jun 05 08:39:08 the Readme says that it exposes as a RNDIS interface Jun 05 08:39:16 https://github.com/ungureanuvladvictor/BBBlfs Jun 05 08:39:20 yeah you'd be better to 'sudo su' firs .. and then run flash as root from there. .. weirdness happens sudo'ing scripts .. they don't always work Jun 05 08:39:28 first* Jun 05 08:40:43 okay, so that actually produced an error. Jun 05 08:41:02 yeah the board is stuck in boot mode waiting for its image .. I think you may have to run bits of the script manually iirc ... Jun 05 08:42:04 hopefully that's got you nearer .. :) Jun 05 08:46:15 veremit, this is the output Jun 05 08:46:17 http://paste.ubuntu.com/17023230/ Jun 05 08:50:21 ZeekHuge: wow, that's awesome .. :/ Jun 05 08:53:10 ZeekHuge: how did you build that .. did you do it as a normal user, or as root? Jun 05 08:53:33 normal user probably .. trying sudo now Jun 05 08:53:36 I -think- you have to build it .. cant just run the script iirc... Jun 05 08:56:56 veremit: even after building it as sudo, same error, only that some values have changes Jun 05 08:57:17 ZeekHuge: yikes .. some part of that build process is borked Jun 05 08:59:04 so raise a github issue ? I dont have the serial o/p Jun 05 08:59:32 ZeekHuge: let me see if it still builds on here .. assuming I don't have a copy Jun 05 09:01:06 aha I -do- have a copy .. hrm Jun 05 09:05:15 ok that doesn't tell me nowt .. Jun 05 09:10:47 veremit: did that work ? Jun 05 09:11:26 I dunno why .. but you seem to have a problem with the usb_flasher binary that gets built .. did you do a full make distclean before you re-run configure/make/etc ? Jun 05 09:12:02 yes i did . Jun 05 09:12:07 let me try again Jun 05 09:12:15 hmm .. do you have valgrind installed? Jun 05 09:12:31 it probably is due to either a library or gcc update :/ Jun 05 09:14:51 trying another system ... Jun 05 09:15:01 nope valgrid is not installed. Jun 05 09:15:42 To test bblfs again... i need 10-16 minutes, some USB I/O is going on and cant interrupt that. Jun 05 09:17:05 ZeekHuge: still no problem here yet :/ Jun 05 09:17:27 you did install the pre-reqs? Jun 05 09:20:19 problem is .. because the program doesn't output much data .. its just 'sitting' there for me .. but it doesn't epic-crash like that .. :\ Jun 05 09:21:17 pre-reqs = libusb-1.0-0-dev ? yes did that. Jun 05 09:21:36 ok I'm about out of ideas .. :( Jun 05 09:21:49 that was the case with when, and then, i built it as sudo, it then began to crash Jun 05 09:23:54 btw 16.04 is not as good, as expected, I am going back to 14 Jun 05 09:28:26 still the same crash message Jun 05 09:29:11 will use sdcard to flash it. USB could have been handy Jun 05 09:31:51 yeah .. maybe figure it out another time Jun 05 09:47:17 http://pastebin.com/x5QzB18E explains how to use BBBlfs to mount a BBB in mass storage mode, and also explains how it works Jun 05 09:48:19 it also turned out quite easy to replace the brittle "usb_flasher" utility by a small dnsmasq config that acts as BOOTP server and TFTP server for the three files Jun 05 09:49:04 zmatt: do you still have wiki edit on elinux - could you write that up there?! Jun 05 09:49:21 afaik everybody can edit there Jun 05 09:49:34 h k Jun 05 09:50:54 so feel free to make a nice writeup :) Jun 05 09:53:41 I was jsut out the door to go fetch something I left behind .. and get some food .. :/ Jun 05 09:53:46 so I'll bbl :p Jun 05 13:52:16 Hi there. I'm pretty new to yocto and trying to build an image for my beagleboard BB-MB-000 Rev.C4. I am using poky and the meta-ti-layer but i cannot get the rootfs from mmcblk0p2. Jun 05 13:53:41 try blk1 ? Jun 05 13:53:53 should be blk0 for boot blk1 for rootfs surely? Jun 05 13:55:26 i think the device is /dev/mmcblk0p2 Jun 05 13:56:03 checked with fdisk/parted? it could be .. never done it with yocto/angvstrom /etc .. only debian Jun 05 13:57:15 yes i used fdisk on debian Jun 05 13:58:16 ok .. just checkin :) Jun 05 14:03:05 ok, i will do a fs-check, but i think that's not the problem, because i got the following error: Jun 05 14:03:09 [ 2.092681] No soundcards found. Jun 05 14:03:09 [ 2.098449] VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0): error -6 Jun 05 14:03:09 [ 2.106262] Please append a correct "root=" boot option; here are the available partitions: Jun 05 14:03:09 [ 2.114959] 0100 8096 ram0 (driver?) Jun 05 14:03:09 [ 2.119750] 0101 8096 ram1 (driver?) Jun 05 14:03:10 [ 2.124389] 0102 8096 ram2 (driver?) Jun 05 14:03:12 [ 2.129180] 0103 8096 ram3 (driver?) Jun 05 14:03:14 [ 2.133819] 0104 8096 ram4 (driver?) Jun 05 14:03:16 [ 2.138580] 0105 8096 ram5 (driver?) Jun 05 14:03:18 [ 2.143249] 0106 8096 ram6 (driver?) Jun 05 14:03:20 [ 2.147949] 0107 8096 ram7 (driver?) Jun 05 14:03:22 [ 2.152587] 0108 8096 ram8 (driver?) Jun 05 14:03:24 [ 2.157318] 0109 8096 ram9 (driver?) Jun 05 14:03:26 [ 2.161956] 010a 8096 ram10 (driver?) Jun 05 14:03:28 [ 2.166748] 010b 8096 ram11 (driver?) Jun 05 14:03:30 [ 2.171508] 010c 8096 ram12 (driver?) Jun 05 14:03:32 [ 2.176239] 010d 8096 ram13 (driver?) Jun 05 14:03:34 [ 2.181030] 010e 8096 ram14 (driver?) Jun 05 14:03:36 [ 2.185791] 010f 8096 ram15 (driver?) Jun 05 14:03:40 [ 2.190582] 1f00 512 mtdblock0 (driver?) Jun 05 14:03:42 [ 2.195678] 1f01 1920 mtdblock1 (driver?) Jun 05 14:03:44 [ 2.200836] 1f02 128 mtdblock2 (driver?) Jun 05 14:03:46 [ 2.205932] 1f03 4096 mtdblock3 (driver?) Jun 05 14:03:48 [ 2.211059] 1f04 255488 mtdblock4 (driver?) Jun 05 14:03:50 [ 2.216156] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Jun 05 14:03:50 hochl: stop it Jun 05 14:03:52 [ 2.224487] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Jun 05 14:04:00 the kernel did not found the mmcblk-device Jun 05 14:04:03 hochl: use a pastebin FFS! Jun 05 14:04:06 pastebin PLEASE Jun 05 14:04:14 no flood bot here :( Jun 05 14:05:09 ok that was all ... i will not paste more errors ;-) Jun 05 14:05:40 or bpaste/dpaste/ .. so many choices .. wgetpaste is a handy util .. but that may be gentoo only .. Jun 05 14:09:26 as i mentioned: the fs is clean Jun 05 14:12:19 veremit: in most linux kernels, mmcblk0 is the first *detected* mmc controller, regardless of whether that's mmc0, mmc1, mmc2, or some usb sd card reader Jun 05 14:13:26 zmatt: yes yes, this I was attemptipng to explain before .. >,< Jun 05 14:14:02 wait what, mtdblock? Jun 05 14:14:21 ohh, beagleboard, not beaglebone Jun 05 14:15:02 zmatt: well .. the partitions are still labelled from blk0+ Jun 05 14:25:14 ok I tryed mmcblk1p2 and mmcblk2p2 with the same result. Jun 05 14:26:16 i think the problem is, that no mmc-device is listed as available partitions Jun 05 14:31:08 what FS support do you have compiled in? and do you have support for MMC block devices?? Jun 05 14:31:21 erm .. you should have at least one of those to have mmc**** lol .. d'oh Jun 05 14:32:24 CONFIG_MMC_BLOCK=y Jun 05 14:33:14 that is the default used by the meta-ti-layer Jun 05 14:33:49 and CONFIG_MMC=y Jun 05 14:40:44 which board are you using exactly? Jun 05 14:41:02 BB-MB-000 Rev.C4 Jun 05 14:41:50 I don't speak serialnumber that well... beaglebwhat? Jun 05 14:43:05 ok it's a classic omap3530-based beagleboard, thanks Jun 05 14:45:39 so for storage there's one mmc/sd/sdio card slot, and 256 MB on-board raw NAND Jun 05 14:46:32 right Jun 05 14:46:47 you're trying to boot from card? Jun 05 14:49:40 yes Jun 05 14:51:07 what kernel version are you using? Jun 05 14:52:09 4.1.18 Jun 05 14:52:39 btw, also be careful if there's also still a system on internal nand flash, since some bootloader versions can make counterintuitive moves when there's more than one linux system accessible Jun 05 14:52:40 i also tryed 4.4.7, 4.4.9, 4.4.11 Jun 05 14:52:53 even to the point of booting the kernel from one system with the rootfs of the other Jun 05 14:53:50 ^ this Jun 05 14:54:11 that's been reasonably solved on recent images on the BBB, but it does require a sufficiently recent bootloader *and* userspace taking advantage of it by using UUIDs Jun 05 14:54:31 did RN update older b* images to match? Jun 05 14:54:42 a mixed system is probably not very likely on a beagleboard though Jun 05 14:55:00 since raw NAND and sd-card will not get confused with each other Jun 05 14:56:36 hochl: so, in any case that's all devicetree-era, while I'm guessing the height of the classic beagleboard's popularity will have been prior to the introduction of DTs (I don't know for sure, I wasn't in this community back then yet) Jun 05 14:57:01 the kernel not seeing the block device at all can mean one of a few things Jun 05 14:57:23 1. the driver is missing (check CONFIG_MMC_OMAP_HS ... at least I think that's also the right one on omap3) Jun 05 14:58:31 2. the driver is compiled as module but didn't end up included on the initramfs, or the bootloader failed to load the right (or any) initramfs. easiest solution is to include it in the kernel and not build it as module Jun 05 14:59:39 3. the device never got defined or remained disabled due to absent or incorrect device tree Jun 05 15:03:07 incorrectly written pinmux in the DT can also cause a device to "vanish": if it references an incorrect node, not a child of the pinmux controller, then the device framework will assume the pinmux driver simply hasn't loaded yet and therefore defers loading the driver for the original device. of course it'll then remain deferred forever since that non-existent pinmux controller isn't going to show up Jun 05 15:04:54 also try including "rootwait" in the kernel cmdline args if the bootloader doesn't already insert that implicitly... probing mmc takes some time hence it done asynchronously, so the kernel needs to be told to have some patience and wait around for a bit before concluding the rootfs device is missing Jun 05 15:05:15 CONFIG_MMC_OMAP_HS=y Jun 05 15:06:27 capturing the debug port from boot on would also be helpful (be sure to use pastebin or such, and also do not put "quiet" in the kernel cmdline since the kernel's chatter might include useful clues) Jun 05 15:06:37 the console output that is Jun 05 15:07:10 rootwait has no positiv effect Jun 05 15:08:44 well I've given a list of guesses... being more precise will require more details. like I said, a log of the kernel output would probably be more valuable Jun 05 15:13:09 ok, tthanks for the hints, but how can i capture the debug port? Jun 05 15:14:45 \ Jun 05 15:18:29 for clarity, I just mean the serial console, not jtag or anything Jun 05 15:18:44 most serial comms programs have logging functionality integrated Jun 05 15:21:47 e.g. screen -L /dev/$TTY 115200,$OPTIONS Jun 05 15:22:15 i found also some items in boot-messages: VMMC1: disabling and pbias_mmc_omap2430: disabling Jun 05 15:22:41 well that sure sounds like a good candidate Jun 05 15:24:15 but again, having the whole log of messages to inspect would probably make it easier to get an overview of what's going on.... especially since I've never used one of these boards or even seen one in real life Jun 05 15:24:39 so I'm just working off general knowledge of TI SoCs and linux here Jun 05 15:25:57 the boot messages could be found at: http://pastebin.com/z0bynJBV Jun 05 15:26:48 thanks Jun 05 15:28:57 huh, why it is compiled for SMP ? the cortex-a8 is not multicore. (that's just an aside... it makes the kernel somewhat larger and slower but otherwise no problem) Jun 05 15:30:03 _lot_ of warnings about stuff being missing Jun 05 15:30:37 though some might just be deferrals possibly Jun 05 15:31:28 [ 1.879669] omap_hsmmc 4809c000.mmc: failed to set clock to 52000000 Jun 05 15:31:30 [ 1.886352] omap_hsmmc: probe of 4809c000.mmc failed with error -22 Jun 05 15:31:39 that's where it really starts to go wrong Jun 05 15:32:07 all the "disabling"s are not errors Jun 05 15:32:16 they're just the kernel disabling things that aren't in use Jun 05 15:36:17 my impression is that this particular kernel has a lot of issues on the omap3, or perhaps noone kept the omap3 device tree data in sync Jun 05 15:37:31 stuff like "omap_hwmod: mpu: _wait_target_ready failed" + "omap_hwmod: mpu: cannot be enabled for reset" seems quite absurd to me Jun 05 15:38:19 maybe look for a tested / known-good kernel + DT combination for the beagleboard (or at least the omap34xx/35xx) and gently take it from there Jun 05 15:53:31 ok, thanks. Jun 05 16:20:13 hello Jun 05 16:21:16 hello Jun 05 18:23:57 lol, the device tree bindings require that you "connect" an lcd panel to the lcd controller using a particular "port" construction for bidirectional relations between devices. if you neglect this then compat code makes sure it'll still work anyway (as long as you have only one panel and one lcd controller anyway), but warnings loudly about it in the kernel log Jun 05 18:24:24 one minor details, if i actually *add* those ports then the tilcdc driver doesn't work anymore at all, no /dev/fb0 ever appears Jun 05 18:25:57 ~fail~ Jun 05 18:32:42 zmatt: are you saying the non-compat bindings don't work, or what? Jun 05 18:33:35 tomba: correct, I can check what it says in the logs if you have a moment Jun 05 18:34:31 zmatt: please pastebin what you tried Jun 05 18:34:56 I mean, the .dts parts Jun 05 18:41:27 http://pastebin.com/xKFVUya4 showing the ports, but commented out (note: since I maintain my own dts some external label refs may differ slightly from the standard am33xx.dtsi) Jun 05 18:43:59 hello, i have a question concerning a new kernel Jun 05 18:44:38 i need a slight updated driver for eqep module and i have already added my code Jun 05 18:45:17 i have also built a new kernel an all other points Jun 05 18:45:49 zmatt: ok, thanks. I need to check, it may be that we support the new bindings only for tda998x. the panel driver is a tilcdc specific hack. Jun 05 18:46:06 http://pastebin.com/WQZCHFbL Jun 05 18:46:10 that's what I get without ports Jun 05 18:46:17 but it does work Jun 05 18:46:29 if I add the ports, then only the first two of those messages appear Jun 05 18:46:38 i used for that robert nelsonss Jun 05 18:46:41 the rest never does, no /dev/fb0 nor /dev/dri/* ever appears Jun 05 18:46:45 https://eewiki.net/display/linuxonarm/BeagleBone Jun 05 18:47:38 is there a possibility to get the same image as availabe here on site with all basic features Jun 05 18:48:06 only with my slight updated driver Jun 05 18:48:12 tomba: I stumbled across drivers/drm/imx/parallel-display.c ... I've only glanced at it very very briefly but it seems similar in intention yet noticably different in implementation Jun 05 18:48:27 daniel__: sure Jun 05 18:48:32 zmatt: yep. we're working on getting the remaining tilcdc specific hacks removed (the panel driver and tfp410). but at least the docs should be clear that the old bindings need to be used for those (if that's the case) Jun 05 18:49:17 tomba: or reality needs to be altered to follow the docs ;) Jun 05 18:49:53 daniel__: for example I keep a tree that closely follows rcn-ee's but with a few patches (and a rather different kernel config) -> https://github.com/dutchanddutch/bb-kernel Jun 05 18:50:06 I think it may be at least a few months until the reality is there, so better fix the docs =) Jun 05 18:51:24 tomba: kinda weird that it's so complicated to make a driver that essentially does nothing other than tell lcdc what timings to use (and actually just relayed those verbatim from the programmer) Jun 05 18:52:20 then again I ran into the same issue with ALSA... it took me quite a while just to figure out how to get McASP enabled with prescribed settings Jun 05 18:53:11 zmatt: you're describing the fbdev driver. the DRM driver does much more. well, in some particular cases that's all the DRM driver does too. Jun 05 18:53:24 tomba: well I'm referring to just the panel driver Jun 05 18:53:31 considering it doesn't actually... drive... anything Jun 05 18:53:41 well, one enable-gpio :P Jun 05 18:54:40 true, but then, the same framework supports much more complex display pipelines Jun 05 18:55:55 in am3's lcdc case, the problem is the legacy stuff. the driver was designed in (I think) a bit bad way, and it's not trivial to fix it without breaking everything Jun 05 18:57:12 I can't get myself to care... if you do a major kernel update, having to make a few DT tweaks seems hardly a hassle Jun 05 18:57:27 noone's forcing you to upgrade Jun 05 18:58:08 sorry im quite new in this field can you explan me that a little bit more in detail Jun 05 18:58:26 or is ther somewhere a good instruction set Jun 05 18:58:46 daniel__: are you somewhat familiar with git? Jun 05 18:58:58 yes Jun 05 18:59:23 i have already a running new image Jun 05 18:59:43 but all basic functios are away with my new image Jun 05 18:59:58 daniel__: then give this a spin first: clone https://github.com/RobertCNelson/bb-kernel switch to the branch representing the kernel series of interest (e.g. am33x-v4.6 corresponds to the 4.6-bone series of kernels) Jun 05 19:00:10 check the readme for important notes Jun 05 19:00:17 do ./build_deb.sh Jun 05 19:00:31 so no leds are blinking and i can't conect my bbb over usb Jun 05 19:00:39 (on a fast machine) Jun 05 19:01:07 if leds aren't even blinking that sounds very much like it never booted (or crashed during boot) Jun 05 19:01:54 over my usb to serial conector im able to log in and browse trough the filesystem Jun 05 19:01:59 oh ok Jun 05 19:02:12 yet no leds blinking at all? Jun 05 19:02:34 (cpu activity, emmc activity) Jun 05 19:02:42 Hello Jun 05 19:02:56 no leds blinking at all and the user is not beaglebone its ARM Jun 05 19:03:31 I have a question. Does anyone know the max switching frequency of the current on the am3358? Jun 05 19:03:45 the what... Jun 05 19:04:21 ok, first practice on simply rebuilding a beaglebone kernel (without changes). flash a beaglebone with a recent image, preferably something minimalistic like the 'console' image to keep things simple initially Jun 05 19:04:41 follow the steps I just mentioned above Jun 05 19:04:51 that git repo contains his build scripts and patches Jun 05 19:05:23 so ./build_deb.sh should take care of the whole process of building the kernel and wrapping it up into a debian package Jun 05 19:06:08 you do get presented with a 'menuconfig' at some point to be able to change kernel config settings, but just exit it Jun 05 19:06:19 I am designing my own board and i want to choose the decoupling capacitor in order to have less impedance in a wide range of frequency but what is the max frequency Jun 05 19:07:26 when it's done you find a subdir 'deploy' containing, among other stuff, linux-image-...yadayada_armhf.deb Jun 05 19:08:05 Ljo: you need to do your research into the PMICs, layout guidelines and techniques and EMC/EMI basics Jun 05 19:08:15 you can copy that over to a beaglebone, do dpkg -i linux-image-.....armhf.deb and it'll get installed, reboot, and you should now be running on your freshly built kernel Jun 05 19:08:34 Ljo: nobody here is going to be able to tell you how to do that .. or how to apply it to your design. Jun 05 19:09:19 Ljo: do however carefully read the datasheet, there are often specific guidelines for various aspects in there Jun 05 19:09:44 ditto supporting appnotes Jun 05 19:10:20 There is not this information in guidelines and datasheet. The datasheet specifies just the decoupling cap values. Jun 05 19:10:50 tomba: "legacy" can be so annoying... I still want to submit this two-line patch (-2+0) that fixes the spi bus numbering by leaving it to the (correct) logic in the spi core Jun 05 19:11:33 tomba: but I already see it coming that the patch probably wouldn't be accepted as-is since it might break someone's legacy assumptions that spi devices get enumerated from 1 Jun 05 19:12:47 tomba: https://github.com/dutchanddutch/bb-kernel/commit/6c7c3885b16ba06e686e1a5a40a824e5789b6e06 Jun 05 19:12:58 static int... blegh Jun 05 19:14:47 so i have to copy the file to the beaglebone first and afterward use the dpkg command on the beaglebone Jun 05 19:15:04 right Jun 05 19:15:15 daniel__: yeah "dpkg -i" is the "manual" version of apt-get install Jun 05 19:15:27 where you just hand it a package instead of downloading it from a repository Jun 05 19:15:43 thanks zmatt i will try this imedatly Jun 05 19:15:51 Thnaks Jun 05 19:25:57 tomba: on the bright side, it seems it may still be a bit more time before I'll be forced to dig deeper into lcdc again... prototypes of the hardware side of that project are really not working, at all ;) Jun 05 19:26:24 the board is mostly successful at producing heat Jun 05 19:29:44 I see the assembly process is on hold, according to http://elinux.org/Beagleboard:BeagleBoard-X15#BeagleBoard-X15_Description Jun 05 19:29:59 Were there problems found with the prototypes? Jun 05 19:38:09 haven't heard anything yet Jun 05 19:48:13 bbl Jun 05 20:40:37 hi zmatt one more question Jun 05 20:43:04 do i need all files from the deploy folder or only the linux-image... Jun 05 20:45:15 daniel__: linux-image is often sufficient and includes the modules and dtbs. there's also the firmware package which I've never had any need for but may be required for some devices Jun 05 20:46:07 the headers are useful for development, especially when using low-level and/or cutting-edge APIs which have no nice glue but require e.g. direct use of ioctl()s Jun 05 20:47:18 oh I see no firmware package gets built, that must be included then in image already Jun 05 20:47:45 so there's basically just image, headers, and the (oddly) unversioned linux-libc-dev Jun 05 20:48:03 and the upstream.orig.tar.gz which I think you can ignore Jun 05 20:49:56 ahh, headers is for when you want to build kernel modules outside the linux tree Jun 05 20:50:06 while linux-libc-dev is just for userspace programmers Jun 05 20:50:28 you can get info on each dpkg using: dpkg-deb --info file.deb Jun 05 20:50:43 or use --contents to list all files in it Jun 05 20:51:29 thanks Jun 05 20:54:13 if you want to try doing a patch, there's tools/rebuild_deb.sh Jun 05 20:55:06 which doesn't clean and regenerate the three, unlike ./build_deb.sh Jun 05 20:55:09 *tree Jun 05 20:55:24 the unpacked sources are in KERNEL/ in case you hadn't noticed yet Jun 05 20:57:04 I *think* rcn also has handy tools for turning such changes into a patch file kept somewhere in the 'patches' dir, but I haven't really tried to fully understand the logic of his pile of scripts :) Jun 05 20:58:09 if you're tired of getting menuconfig again every time, set AUTO_BUILD=1 in ./system.sh Jun 05 20:59:25 if you merely reconfig the kernel then there's not much you need to do besides occasionally saving your config... it's automatically copied to patches/defconfig which is git-versioned so you can commit it there Jun 05 21:01:23 if you change a lot of config, like me, then rebasing that on top of a new version from rcn-ee generally produces tons of conflicts, but that's mostly just bogus so I "resolve" the conflict by using my version, maybe quickly use git log or git diff to see if he's changed anything that looks important to me, then rebuild and test the kernel and declare the conflict "resolved" :) Jun 05 21:02:24 Are there plans to manufacture a pci express daughter board for the x15? looks like lots of potential as long as the pci-e could be made to work. Jun 05 21:02:57 would be nice for the X15 to be come available first Jun 05 21:03:07 actual patches are not much harder once you get the hang of it: I just edit and, after testing, commit in the unpacked kernel repo. unless it's just a little test I try to make it a "good" commit, preferably something that could be submitted upstream as-is Jun 05 21:03:40 then use git format-patch to turn the commit into a patch that I add to the existing big pile of patches Jun 05 21:04:46 in rcn's tree for some reason it's necessary to add each individual patch to ./patch.sh ... I changed that to make it able to scan whole dirs of patches instead: https://github.com/dutchanddutch/bb-kernel/commit/0fb8bf645a85010f0663bccd4930b516e0a3d8ba Jun 05 21:06:22 brb Jun 05 21:09:28 thanks a lot i have the files now on bbb and i will try install them Jun 05 21:27:55 @ zmatt I have now my kernel running on the BBB!! Thanks a Lot!!!! :) (beer) Jun 05 21:56:29 Hi People **** ENDING LOGGING AT Mon Jun 06 02:59:58 2016