**** BEGIN LOGGING AT Thu Mar 08 03:00:04 2018
Mar 08 03:08:52 <ravikp7> jkridner: it seems, all's timing issue, if I put time before device is detected and is opened and claimed to below 50ms, the device gets opened easily
Mar 08 03:09:07 <ravikp7> but then getting
Mar 08 03:09:08 <ravikp7> RNDIS ready
Mar 08 03:09:08 <ravikp7> high speed config #2: 2 mA, Ethernet Gadget, using RNDIS
Mar 08 03:09:09 <ravikp7> The remote end did not respond in time.cpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !
Mar 08 03:11:06 <ravikp7> serverip not found issue occurs when device shows up for a very short time and isn't opened within that time and server script crashes
Mar 08 03:16:17 <ravikp7> Abhishek_, ds2: any idea what this time is in "The remote end did not respond in time.cpsw" ?
Mar 08 03:16:48 <Abhishek_> cpsw: Means that the Ethernet driver is getting invoked!
Mar 08 03:16:49 <ds2> there is probally nothing on the remote side responding
Mar 08 03:17:00 <ds2> good point, Abhishek
Mar 08 03:17:35 <ds2> wonder if it is confused as to which interface to use
Mar 08 03:20:01 <Abhishek_> I have seen this before, but after I switched configs, it worked
Mar 08 03:20:18 <Abhishek_> ravikp7: Try building an SPL this way:
Mar 08 03:20:37 <Abhishek_> checkout v2018.03-rc4 on a fresh branch
Mar 08 03:20:57 <ravikp7> hmm, let's check interface..
Mar 08 03:21:01 <Abhishek_> Apply rcn-ee's patches:- https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.03-rc4/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
Mar 08 03:21:17 <Abhishek_> https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.03-rc4/0002-U-Boot-BeagleBone-Cape-Manager.patch
Mar 08 03:21:40 <Abhishek_> Then edit am335x_evm_defconfig:
Mar 08 03:22:09 <Abhishek_> Add these lines:
Mar 08 03:22:21 <Abhishek_> CONFIG_SPL_NET_SUPPORT=y
Mar 08 03:22:21 <Abhishek_> CONFIG_SPL_NET_VCI_STRING="AM335x U-Boot SPL"
Mar 08 03:22:21 <Abhishek_> CONFIG_SPL_USB_GADGET_SUPPORT=y
Mar 08 03:22:21 <Abhishek_> CONFIG_SPL_USB_ETHER=y
Mar 08 03:23:05 <Abhishek_> Comment out the following lines by adding a "#" in front of them:
Mar 08 03:24:03 <Abhishek_> CONFIG_ENV_IS_IN_EXT4=y
Mar 08 03:24:03 <Abhishek_> CONFIG_ENV_EXT4_INTERFACE="mmc"
Mar 08 03:24:03 <Abhishek_> CONFIG_ENV_EXT4_DEVICE_AND_PART="0:1"
Mar 08 03:24:03 <Abhishek_> CONFIG_ENV_EXT4_FILE="/boot/uboot.env"
Mar 08 03:24:49 <Abhishek_> Add this line:
Mar 08 03:24:56 <Abhishek_> CONFIG_ENV_IS_NOWHERE=y
Mar 08 03:25:22 <Abhishek_> Then build u-boot with am335x_evm_defconfig
Mar 08 03:28:29 <ds2> doesn't that ignore any NVRAM config?
Mar 08 03:29:35 <Abhishek_> It does, however USB gadget support will not fit SPL otherwise.
Mar 08 03:29:43 <ravikp7> ds2: interface doesn't seem to be a issue
Mar 08 03:29:48 <ravikp7> Abhishek_: trying that
Mar 08 03:30:01 <Abhishek_> ds2: It overflows by some 7K bytes
Mar 08 03:37:08 <ds2> doh
Mar 08 03:48:21 <ravikp7> Abhishek_: the lines you are asking to comment out are already not present there
Mar 08 03:56:27 <ravikp7> this isn't working for me
Mar 08 03:56:33 * ravikp7 sent a long message: ravikp7_2018-03-08_03:56:32.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/xHyDmdwTuOAeAXfJptbszQMQ>
Mar 08 04:12:12 <Abhishek_> Did you apply rcn-ee's patches first?
Mar 08 04:12:24 <Abhishek_> ravikp7: ^
Mar 08 04:16:04 <ravikp7> I made sure no changes were there before applying patches, still during applying the patch got warnings about previous patches
Mar 08 04:16:08 <ravikp7> https://pastebin.com/90x1g4rJ
Mar 08 04:17:24 <ravikp7> not sure from logs if it was successful
Mar 08 04:21:54 <ravikp7> Abhishek_: seems good to you? or should start with fresh clone from upstream?
Mar 08 04:47:22 <Abhishek_> ravikp7: Start with a fresh checkout of the v2018.03-rc4 tag to a temp branch
Mar 08 04:48:09 <Abhishek_> Do "git checkout -b tmp1 v2018.03-rc4"
Mar 08 04:48:21 <Abhishek_> Then apply rcn-ee's patches first
Mar 08 04:48:55 <ravikp7> Abhishek_: did that, still got warnings of previous patches :(
Mar 08 04:49:24 <Abhishek_> Strange. I used git am
Mar 08 04:50:42 <Abhishek_> To apply the patches
Mar 08 04:51:04 <Abhishek_> e.g. git am 0001-###.patch
Mar 08 04:54:26 <ravikp7> Abhishek_: I used patch -p1 < 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
Mar 08 04:58:21 <Abhishek_> ravikp7: Try git am from a fresh checkout on a new branch
Mar 08 05:00:26 <ravikp7> Abhishek_ : with git am 0000x.patch getting this
Mar 08 05:00:27 * ravikp7 sent a long message: ravikp7_2018-03-08_05:00:25.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/smQsECcltyYRwOuyvUDYJCwc>
Mar 08 05:01:15 <Abhishek_> Replace that with the full name of the patch :)
Mar 08 05:03:19 <ravikp7> Abhishek_: haha, not using that, using the full name :)
Mar 08 05:04:14 <Abhishek_> Strange.
Mar 08 05:04:24 <Abhishek_> How did you download the patch?
Mar 08 05:05:01 <ravikp7> wget -c github-link
Mar 08 05:05:40 <Abhishek_> Hmm that may not be the best way. Use "raw" button and save link as on right click
Mar 08 05:08:13 <ravikp7> wonder what's wrong with wget
Mar 08 05:09:14 <Abhishek_> Hmm, maybe open the downloaded file and check once.
Mar 08 05:12:33 <ravikp7> Abhishek_: opening the flie does the job
Mar 08 05:12:40 <ravikp7> what's with opening ?
Mar 08 05:17:36 <Abhishek_> Open just to check if the contents is a valid patch. The GitHub URL that I gave you will lead to a web page and not the actual raw patch.
Mar 08 05:22:02 <Abhishek_> ravikp7: ^
Mar 08 05:22:11 <ravikp7> Abhishek_: got it, it's working
Mar 08 05:22:45 <ravikp7> not times out anymore on ping
Mar 08 05:22:53 <ravikp7> now on ping device sends an arp request, and after arp reply sent fro server
Mar 08 05:23:10 <ravikp7> from server, the ping fails
Mar 08 05:23:26 <Abhishek_> For ping, need to implement ICMP
Mar 08 05:24:28 <ravikp7> oh, i see
Mar 08 05:24:47 <Abhishek_> Ping is ICMP ECHO packet
Mar 08 05:26:02 <ravikp7> not sure what jkridner plans to do further
Mar 08 05:26:59 <ravikp7> with netconsole
Mar 08 05:31:20 <ravikp7> Abhishek_: am335x_evm_usbspl_defconfig also works now, I think the patch was making the difference
Mar 08 05:34:12 <Abhishek_> Cool
Mar 08 05:59:16 <ds2> implement ICMP?
Mar 08 05:59:26 <ds2> is the stack on UB that stripped?
Mar 08 05:59:29 <ravikp7> Abhishek_: thanks a lot for helping out :)
Mar 08 06:00:20 <Abhishek_> ds2: implement ICMP in node-beagle-boot
Mar 08 06:00:30 <Abhishek_> ravikp7: no problem :)
Mar 08 06:02:37 <ds2> oh the fake IP stack :D
Mar 08 06:02:57 <ds2> wonder if you can borrow stuff from slirp
Mar 08 12:13:50 <illustris> I was going over the beaglelogic code, and I didn't understand the purpose of this software breakpoint: https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru1-core.asm#L52
Mar 08 12:14:02 <illustris> The comment suggests that it is waiting for an interrupt from PRU0, but that would be done with "WBS	R31, 30", right?
Mar 08 12:35:58 <zeekhuge> illustris: the `HALT` instruction basically disables the PRU, and kind of makes it freeze at that position, until re-enabled using the CONTROL registers.
Mar 08 12:36:02 <zeekhuge> As far as I remember ..
Mar 08 12:37:21 <zeekhuge> so its not really waiting for the interrupt from PRU0. PRU0 would enable it back.
Mar 08 12:37:26 <Abhishek_> Yep.
Mar 08 12:38:39 <illustris> Can you point me to the part of the PRU0 code that re-enables PRU1 after that breakpoint?
Mar 08 12:39:01 <zeekhuge> in fact, in case of PRUs, the interrupts are not like the usual ones. The PRU-interrupts dont "interrupt" the PRUs, they just set then associated PRU-interrupt-flag, and PRU code expects to be interrupted, then it need to go and check that interrupt-status-flag.
Mar 08 12:41:52 <illustris> Yes, I get that the PRU interrupts are basically busy waits that check a register bit (like https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru0-core.asm#L32), but I'm just not clear on what resumes PRU1 after the halt at https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru1-core.asm#L52
Mar 08 12:49:35 <zeekhuge> illustris: Isnt it this - https://github.com/abhishek-kakkar/BeagleLogic/blob/master/firmware/beaglelogic-pru0.c#L67 ?
Mar 08 12:52:55 <illustris> I see. Thanks!
Mar 08 13:38:07 <_stardust_> nerdboy: I did look at the 2015 project stuff, but the only thing I saw that describes the project parts is a youtube video.
Mar 08 15:55:34 <_stardust_> nerdboy: From what I can understand, this next phase of the BeagleSat project consists of three parts. 1 - Integrate BeagleSat (including GSoC BeagleSat magnetometer application) with MAVLink/Autopilot framework. 2 - Determine best autopilot for BeagleBone based on experiment needs (use BeagleSat magnetic field as example. Required to use 2 independent IMU magnetometers). 3 - Integrate navigation model with autopilot firmware and selected
Mar 08 15:55:35 <_stardust_> beaglebone hardware and data acquisition sample
Mar 08 15:56:57 <stardust> Is that right?
Mar 08 15:59:54 <stardust> From what I understand, the integration with MAVLink is to add support to communication between the satellite and the ground station? Is that right?
Mar 08 16:00:37 <stardust> And the autopilot/ardupilot is to provide a framework to do GPS processing?
Mar 08 17:11:53 <nerdboy> sounds about right
Mar 08 17:20:52 <stardust> Ok. I did not find any reference for GPS and Comms hardware that will be used in the project. Is this defined already?
Mar 08 18:16:21 <nerdboy> not really, except in the mavlink drone arena
Mar 08 18:20:39 <nerdboy> small/generic uart gps should be fine, mavlink doesn't care if it's wifi/other rf
**** ENDING LOGGING AT Fri Mar 09 03:00:00 2018