**** BEGIN LOGGING AT Tue Feb 07 03:00:01 2017 Feb 07 07:17:31 hi folks :) Feb 07 07:25:02 brb reboot Feb 07 09:25:13 UART pins in Beagleboard x15 Feb 07 09:26:33 Need help for UART pin Beagleboard x15 Feb 07 09:41:30 jay_Ganatra: https://github.com/beagleboard/beagleboard-x15/blob/B1/BeagleBoard-X15_SRM.pdf?raw=true Feb 07 09:53:33 Hello. I think I managed to read from my i2c eeprom chip using the BBB. I did so using open/read Feb 07 09:54:26 though I'm puzzled, why the read pointer stays at its last location even if I close the device file Feb 07 10:50:19 gquere: the read pointer is tracked by the eeprom rather than by the kernel, and the eeprom doesn't know anything about "device files" Feb 07 10:53:12 zmatt: yeah but userspace does Feb 07 10:53:29 and there's got to be a driver underneath the device Feb 07 10:55:50 what file did you read exactly, the "nvmem" attribute in sysfs? Feb 07 10:57:04 /dev/i2c-2, address 0x50 Feb 07 10:57:10 got these from i2cdetect Feb 07 10:57:45 ok raw i2c transactions, not actual seek()/read() Feb 07 10:58:18 read() works fine, didn't test seek() Feb 07 11:00:05 it won't work, and yeah I suppose the kernel might support the use of read(), though I would prefer to avoid it due to the inherent race condition Feb 07 11:01:08 when I get to the end of the eeprom it just loops back to the start Feb 07 11:01:17 what race condition? Feb 07 11:01:40 if there's another reader/writer you mean? Feb 07 11:01:45 if something else accesses the eeprom at the same time, the read pointer can change Feb 07 11:01:48 yes Feb 07 11:02:12 ah I completely isolated the eeprom (desoldered from host PCB) Feb 07 11:02:32 so I'd prefer to perform { seek to position; read data } as one i2c transfer Feb 07 11:04:03 I didn't say the race condition was always a concern, but since it's easy in this case to write code that works correctly regardless of concurrent accesses it seems silly to do it in an insafe way... you never know where that code might end up getting reused in the future :) Feb 07 11:05:18 it'll probably stay as is, but what other method than /dev/i2c would you have used? Feb 07 11:07:08 use /dev/i2c, but perform { seek to position; read data } as a single i2c transfer Feb 07 11:07:38 or make a DT entry for the eeprom so you can use the kernel's driver for it (and make the eeprom appear as nvmem file) Feb 07 11:08:30 ah ok, will think about it, thanks Feb 07 11:08:51 hmm, I think you can also dynamically tell the kernel about i2c devices via sysfs, never tried that Feb 07 11:25:05 yep, that works too: https://hastebin.com/raw/ezosayifab Feb 07 11:26:21 (the eeprom driver doesn't perform any transfers when it is probed, so it doesn't even notice that there's nothing actually there at that address) Feb 07 11:27:35 oh sorry two lines I copy/pasted are the wrong ones, I meant to do ls 0-0051 after creating the device of course Feb 07 11:28:53 (looks the same anyhow, except no of_node link since it wasn't declared via DT) Feb 07 13:07:57 hi folks Feb 07 13:46:10 support for beagleboard x15 in yocto Feb 07 13:46:23 help support for beagleboard x15 in yocto Feb 07 14:33:26 help support for beagleboard x15 in yocto Feb 07 21:08:53 Suppose that I am building a linux based distro, what kernel config file should I use to match most of the devices out there ? How do other distros do this ? Feb 07 21:09:07 Ofc, not a beagle question, but still .. Feb 07 21:09:26 use a multi-platform kernel that supports device trees Feb 07 21:09:35 and modularize most of the features Feb 07 21:25:48 vagrantc: Uhm ... device trees is for embedded systems na ? Feb 07 21:26:26 I mean .. in Laptops, the BIOS does that part. isnt it ? Feb 07 21:26:43 I think I read that somewhere .. Feb 07 21:55:01 zeekhuge: same principle applies, i guess. i assumed you were talking about non-beagleboard arm boards, given the channel... Feb 07 22:19:18 zeekhuge: eh, bios is a piece of software, DT is a piece of information Feb 07 22:20:51 zeekhuge: but yeah the bios provides the kernel with ACPI tables, which are like DT except much more complicated Feb 07 22:37:33 zmatt: yeah .. so, uhm .. like .. assume that there 7 different USB drivers, and my system need only 1 of them, so is the distro kernel compiled with all those 7 drivers ? does that mean I have all those 7 drivers loaded in my RAM right now, even though I need only one of them ? or are almost all of the drivers compiled as modules ? Feb 07 22:38:46 modules Feb 07 22:39:51 even the most basic ones ? like hard disk drivers ? or ethernet ? Feb 07 22:41:01 yes Feb 07 22:41:29 on my laptop there are 131 kernel modules loaded right now Feb 07 22:42:02 * vagrantc has 157 loaded Feb 07 22:43:27 including 'e1000e' for my ethernet, 'iwlwifi' for my wifi, hard disk uses 'ahci' and 'sd', usb is 'ehci_pci', etc Feb 07 22:44:00 that's why initramfs is absolutely necessary nowadays on most linux machines Feb 07 22:44:26 (I don't use initramfs on beaglebones though) Feb 07 22:44:33 vagrantc: exactly the same number here. that is on the hypervisor/host system. Feb 07 22:44:57 70 on guests. Feb 07 22:45:44 to be fair, the kernel sometimes really loads some nonsense :P Feb 07 22:46:05 initramfs ! oh yes ! Got it ! Feb 07 22:47:02 (I caught these on my laptop at least -> https://hastebin.com/namiseciku.sh ) Feb 07 22:48:25 So the so called "installation" of a distro actually refers to the process where everything is normally set up ( nothing fancy ), and in the end (and probably the most imp part) it generates the initramfs according to the current system ? is it so ? Feb 07 22:49:34 depends on your distro Feb 07 22:49:42 some just include modules appropriate for arbitrary systems Feb 07 22:50:06 so that you can yank the hard drive out of one system and still boot it on another Feb 07 22:56:00 Ohkay ! Got it ! Thanks :) Feb 07 22:56:18 update-initramfs has a config file for that Feb 07 22:57:43 including a ton of modules in your initramfs just makes the boot process a bit slower but at least you know the drivers the kernel needs to actually boot are all there Feb 07 23:05:42 I have an old RevA BBB that I have been running a project on using UART-4 on P9. I just purchased a new BBB-Wireless, flashed my image from RevA to the eMMC on the new BBB-Wireless and all was good. I connected the UART wires (correctly) and powered on. Now I can get no power to the board? Plugging into USB, 5V wall adaptor will just case the pwr LED to blink quickly. Did I fry something? Feb 07 23:07:11 bbl Feb 07 23:20:15 howdy...wondering if someone can help me. Just got the new BeagleBone Black Wifi and when I turn it on it appears to be in Acces Mode only....what is the darn password? Feb 07 23:37:40 x0veN: tried leaving it blank ? Feb 07 23:41:32 ok let me try that Feb 07 23:56:57 No that didn't work. It required a Wifi Password. I tried "beaglebone" "BeagleBone" and still won't get an IP Feb 08 00:01:37 I just want to connect to my normal Wifi with the thing....any thoughts? Feb 08 00:01:54 The Connman keeps popping a DBus error Feb 08 00:06:01 Figured it out. Password was "BeagleBone" Feb 08 00:06:16 still can get the device to connect to my Wifi....thoughts? **** ENDING LOGGING AT Wed Feb 08 03:00:02 2017