**** BEGIN LOGGING AT Sun Mar 08 03:01:09 2020 Mar 08 03:36:31 Hi jkridner: I am interested in working on 'mikroBus driver' project, i had some doubts and they were clarified by Abhishek_ . Mar 08 03:36:42 Here is what i understood about the project: Mar 08 03:37:03 There can be a lot of MikroBus sockets on the mainboard, we can test an add-on board(clickboard), Mar 08 03:37:03 remove it and test another. Mar 08 03:37:32 This makes the sockets highly configurable. Rebooting the main board each time when we change add-on board so that newly added add-on board will get picket up by the kernel defeats the purpose of the board being highly configurable. Mar 08 03:37:41 So, instead of getting the information about the board from the device tree, we want to get the information out of the tree via I2C. Mar 08 03:37:56 The goal of the project is to implement the driver which does the above. Mar 08 03:38:00 Is my understanding of the project correct (or) am i missing something? Mar 08 03:39:38 I have completed the cross-compilation task mentioned on the website. I have background in kernel development and device drivers and i have sent few trivial patches to linux kernel. Mar 08 03:40:08 What should be my next step of action? can you please point me what i can do further? Mar 08 14:58:29 ymdatta: I don't disagree there can be many mikrobus slots per dev board, Implementation should start with one. Mar 08 14:59:21 addition and removal isn't the point of the mikrobus project itself, it is avoiding needing to add device tree entries for click boards. Mar 08 14:59:58 if there is a mikrobus defined, then platform data can be provided by the bus driver. Mar 08 15:00:28 so, a while a mikrobus slot will need to still be defined by device tree.... Mar 08 15:00:36 no entries specific to the click boards would be required in the device tree. Mar 08 15:00:58 we'd add a probing method similar to what was done for BeagleBone Capes. Mar 08 15:01:17 an identifier would be read over I2C. Mar 08 15:01:51 unlike "Cape Bus", which never landed upstream, this would not result in loading a device tree overlay.... Mar 08 15:02:13 instead, platform data structures could be directly completed by the mikrobus bus driver. Mar 08 15:52:25 Hello everyone, My name is Deepak Khatri and I am interested in doing the Cape compatibility layer for BeagleBone Black and BeagleBone AI project over this summer. Mar 08 15:53:21 The main Goal of the project is to use same references to drivers for peripherals assigned to the same pins between Black and AI. Mar 08 15:56:01 I wanted to ask everyone If the project is successfully completed, how will it affect your projects and what will be its impact be on the BeagleBoard.org community? Mar 08 16:41:53 jkridner: Thanks for the reply. I am getting more clarity on the project. Mar 08 16:43:19 I didn't understand what you meant by this: but seeing this https://octavosystems.com/2018/06/20/rapidly-prototype-with-the-osd3358/ , helped me in understanding what you mean. We want to avoid the hassle of adding device tree overlays to device tree and rebooting each time we want to test out a clickboard Mar 08 16:43:41 right! Mar 08 16:50:08 So our mikroBus driver becomes a middle man between the hardware drivers and the hardware by providing the information about hardware to drivers which interact with it? Mar 08 16:59:26 jkridner: Can you expand on this part a bit more? Mar 08 16:59:57 I'll give an example for "Cape Bus" Mar 08 17:02:15 old info.... https://elinux.org/BeagleBone_and_the_3.8_Kernel#Cape_Manager_requirements Mar 08 17:03:40 hmmm.... https://github.com/beagleboard/linux/commit/eb03ceb4e7ae02dd733c02e442d9e44756561727 isn't as informative as I'd like. Mar 08 17:05:45 This is where the EEPROM scan happens https://github.com/beagleboard/linux/commit/eb03ceb4e7ae02dd733c02e442d9e44756561727#diff-0bedad44589170e90ac0ceb766175e9cR447-R522 Mar 08 17:06:16 for mikroBus, something like this would still happen, but you wouldn't load a dt file as a result. Mar 08 17:06:35 * jkridner[m] has to run. please queue up some more Qs here and the mailing list. :-/ **** ENDING LOGGING AT Mon Mar 09 02:59:57 2020