**** BEGIN LOGGING AT Thu Jun 13 02:59:59 2013 Jun 13 04:07:53 hey, did I miss something? I thought there would be a weekly meeting for now Jun 13 04:09:01 As I received Jason's invitation and the time table says, it's 12:00-1:00 for Beijing Time. Jun 13 04:11:34 oh... Sorry, find it AM. that would be too late for Beijing, Jun 13 04:11:36 quit Jun 13 07:34:28 av500: ping Jun 13 07:46:04 av500: i was wondering if there can be multiple types of rndis messages sent by the board. like some sort of init when it is connected to the host *for my linux the kernel takes it and i can`t check at the same moment what data is sent on the usb* Jun 13 07:46:06 +1 Jun 13 07:46:21 vvu: I dont know Jun 13 07:46:32 vvu: but you see what the board sends you, no? Jun 13 07:46:47 i see after i start my usb *sniffer* Jun 13 07:47:01 ah Jun 13 07:47:02 but i was thinking at the very same moment when i connect it to the PC what happens Jun 13 07:47:42 understand Jun 13 07:48:21 tried to search last night for some diagram showing how rndis works*the flow of operations* but got only the documentation and windows driver issues with google :) Jun 13 07:49:43 I would not worry for now Jun 13 07:50:02 did you ever get any data via the java api? Jun 13 07:50:15 got some data but after it stalled Jun 13 07:50:52 maybe i should try to do a hexdump there Jun 13 07:51:00 and see what i receive Jun 13 07:53:59 * vvu needs to charge his nexus7. the BBB is very hungry for power when connected. Jun 13 07:54:53 yes Jun 13 07:55:03 hexdump Jun 13 07:58:32 i kinda finished the encapsulations until Ethernet 2. when you have time look at it a bit https://github.com/ungureanuvladvictor/BBBabb . Jun 13 07:59:46 spoke with Tartarus about u-boot and thing are covered nicely there. there is usb support in u-boot for am335x. Jun 13 08:13:42 vvu: what is the current plan? to upload a dfu enabled u-boot? Jun 13 08:14:11 a MLO with usb support Jun 13 08:14:27 (or fastmboot because it is more Android like) Jun 13 08:15:23 but what is the usb support going to do ? Jun 13 08:16:19 i wanted to use the same workflow as for the ROM Boot Jun 13 08:16:26 to tftp things to the board Jun 13 08:16:29 all over the way Jun 13 08:18:06 I am currently using that approach to flash images on our test setup. Jun 13 08:18:57 i don`t have any other idea how to send things there. Jun 13 08:19:14 in our setup it is a bit messy because the sd image size is bigger than the ram Jun 13 08:19:41 so we need to tranfser the images in a few times and write them. Jun 13 08:20:15 fastboot or dfu gives more control over to the host Jun 13 08:20:43 don`t really have experience with fastboot or dfu but i can read about them and see what is happening Jun 13 08:24:23 http://en.wikipedia.org/wiki/Fastboot#Fastboot Jun 13 08:25:53 I don't know the details on u-boot side Jun 13 08:28:04 found this link http://e2e.ti.com/support/arm/sitara_arm/f/791/t/161948.aspx Jun 13 08:28:21 there is some fastboot in uboot Jun 13 08:28:24 I tried to use it Jun 13 08:28:44 but in uboot a lot of stuff depends on the actual SoC Jun 13 08:30:19 that is alway true. av500 did you also try DFU (that's mainline I think) Jun 13 08:30:48 don`t really feel confident getting into u-boot sources, lots of things are happening there Jun 13 08:30:49 no Jun 13 08:32:40 I might have a look this week-end Jun 13 08:52:32 av500: only RNDIS_REMOTE_MSG packet, no extra one Jun 13 08:52:47 same hexdump as libusb http://pastebin.com/f3DjRjgZ Jun 13 08:52:59 kernel does not have rndis support in it. Jun 13 08:53:59 ok Jun 13 08:54:01 so Jun 13 08:54:02 its fine Jun 13 08:54:18 vvu: you should patch MLO to blink the LEDS Jun 13 08:54:31 then you can just upload MLO and have a result :) Jun 13 08:54:39 good idea ! Jun 13 08:54:56 but in a day or 2 need to finish up bootp encapsulation then switch to tftp stuff Jun 13 08:58:29 ok Jun 13 09:33:17 av500: in the hexdump i get from libusb/android the last FF byte is the end of the vendor field but after that there are several paddings with 00. looked into REMOTE_NDIS_PACKET_MSG structure and after the data field there is this padding which has size variable and it is for some allignment of data Jun 13 09:33:52 yes, but the header says no padding Jun 13 09:34:04 also, the UDP size already has that extra data Jun 13 09:34:10 so its not RNDIS padding Jun 13 09:35:03 from where is that padding? don`t kinda get it. udp does not put thing after the data Jun 13 09:35:54 tghe bootp paket Jun 13 09:36:11 since the UDP already says the packet is larger than 300 byte Jun 13 09:36:56 btw, did you ever try bootp with using the OS? Jun 13 09:37:05 so, bootp and tftp with linux, not libusb Jun 13 09:37:36 aaa Jun 13 09:37:36 got it Jun 13 09:37:36 until 64 bytes Jun 13 09:37:36 for the vendor Jun 13 09:38:10 nop, no debugging yet Jun 13 09:38:28 wanted to finish rndis and after that take them step by step Jun 13 09:38:39 no, I mean to just use std linux Jun 13 09:38:46 to make sure this usb boot works at all :) Jun 13 09:39:04 tested with a normal MLO Jun 13 09:39:15 and it worked? Jun 13 09:39:16 and the file was sent to the ROM Jun 13 09:39:24 seen sent packets in wireshark Jun 13 09:39:33 got a capture? Jun 13 09:39:44 nop, was 1 month ago when i was writing the proposal Jun 13 09:39:57 well, you could capture that again Jun 13 09:39:59 as a reference Jun 13 09:40:04 i will try today to build uboot for usb boot Jun 13 09:40:09 and bootp that file Jun 13 09:40:16 have serial cable to see if it works Jun 13 09:40:20 yes Jun 13 09:40:40 but 1st want to finish writing the rndis struct and the functions for it Jun 13 09:41:36 ok Jun 13 10:26:42 av500: when you have time check on the repo rndis.h if seems ok by you Jun 13 10:36:23 vvu|Mobile: you cannot define the header like that Jun 13 10:36:31 if you want to memcpy it out Jun 13 10:36:45 compiler is not obliged to honour your aligment ideas Jun 13 10:37:05 split the 64 bit into 2x 32 Jun 13 10:37:21 the reserved one ? Jun 13 10:37:55 yes Jun 13 10:38:25 okok done Jun 13 10:39:11 can you look at upd.h and bootp.h also? Jun 13 11:27:27 av500: debugged my code with the packet that i receive from the board. http://pastebin.com/KUBdb6WP Jun 13 11:27:44 need to see smth at udp struct and vendor field for bootp. the rest seems ok to me Jun 13 11:32:28 IP Total Length: 34817 Jun 13 11:32:44 Length: 29697 Jun 13 11:33:14 LE vs BE :) Jun 13 11:34:02 LE on the BBB ? Jun 13 11:34:07 ? Jun 13 11:34:12 you values are wrong Jun 13 11:35:34 i used this header http://pastebin.com/jTTrrNPT Jun 13 11:35:44 yes Jun 13 11:35:47 the header is ok Jun 13 11:35:50 your printf is not Jun 13 11:35:58 or is the packet 29697 bytes long? Jun 13 11:36:08 or mabe 372 Jun 13 11:40:33 29697 is udp+data Jun 13 11:40:35 think so Jun 13 11:41:42 no Jun 13 11:41:55 29697 is 0x417 Jun 13 11:42:02 but the real value is 0x174 Jun 13 11:42:07 LE vs BE Jun 13 11:46:03 i receive stuff in LE format and try to interpret it as BE ? Jun 13 11:53:20 fixed and now is same as wireshark says Jun 13 11:56:00 I see no commit :) Jun 13 11:56:40 locally, commit now Jun 13 12:03:03 ok now is up Jun 13 12:12:53 about the ip header length, wireshark says 20 but i find 5 for that value Jun 13 12:14:24 yes Jun 13 12:14:32 but you did not read carefully enough :) Jun 13 12:14:40 it is a 4 bit value, how do you encode 20? Jun 13 12:15:18 can`t in 4 bit Jun 13 12:16:09 this is why it encodes the number of 32 bit words Jun 13 12:18:30 now lemme see udp src and dst port Jun 13 12:18:34 get awkward values there Jun 13 12:31:54 av500: i tried printing with PRIu16 in printf but still same value instead of regular ports. Jun 13 12:32:56 PRIu16 does not byteswap Jun 13 12:33:40 i`m lost now Jun 13 12:34:56 figured it out Jun 13 16:36:15 jkridner|work ping Jun 13 16:36:30 pong Jun 13 16:38:10 how do we make a beagleboard.org registered project to be registered under a blog/website? Jun 13 16:38:19 instead of an email id? Jun 13 16:39:22 openid Jun 13 16:39:30 ahh ohk... thanks :) Jun 13 16:40:49 https://www.myopenid.com/help Jun 13 16:42:07 nice... Jun 13 17:56:35 morning vvu|Mobile Jun 13 17:56:46 hello ka6sox Jun 13 17:58:07 how are things going today ? Jun 13 17:58:23 the kernel rebuild is necessary because you need something for USB? Jun 13 17:58:29 (on the android device) Jun 13 17:58:46 i need to get rid of the OTG stuff Jun 13 17:59:08 what method are you planning on using to replace the kernel? Jun 13 17:59:09 the ROM enumerates differently, _av500_ told me Jun 13 17:59:45 method mainly giving out instructions to the user how to compile and replace the kernel...don`t really thought of this hard enough Jun 13 18:00:10 what if the bootloader expects a signed kernel? Jun 13 18:00:31 like a lot of locked bootloaders Jun 13 18:00:36 signed kernel being only from manufacturer right? Jun 13 18:01:04 as i said, don`t really know what to do here. Jun 13 18:01:18 a lot of phone vendors lock down their devices with signed bootloaders that expect the kernel to be a certain thing. Jun 13 18:01:31 or are you targetting tablets. Jun 13 18:01:56 the issue with the OTG is fixed in the 3.4 i think so Jun 13 18:02:43 with the release of the new android maybe this will be fixed but until now i tested devices until samsung galaxy s3 and still 3.1.10 kernel they have Jun 13 18:02:53 and nexus 4 same thing Jun 13 18:03:35 the N7 is unlocked and works well Jun 13 18:03:49 yep i have n7 Jun 13 18:03:54 I've been shoving new kernels in that for a while Jun 13 18:04:09 for the n7 i just recompiled the kernel removing otg Jun 13 18:04:16 good Jun 13 18:04:55 vvu|Mobile, I have that optware running on my N7 too Jun 13 18:06:16 that is a nice thingie but i also want to keep user as little as possible out of hacking their phones/tablets and the kernel is from the start a hard bump Jun 13 18:06:22 <_av500_> ka6sox: we have to accept that it wont work on all android devices Jun 13 18:06:29 <_av500_> but this is the way we chose to go Jun 13 18:06:49 understood Jun 13 18:07:25 vvu|Mobile, ya, pretty radical step, but understand why Jun 13 18:18:54 _av500_: when i construct the ip packet to reply the board with the BOOTP RESPONSE what do i need to fill in for src and dst address. src = 0.0.0.0 and dst=255.255.255.255 ? Jun 13 18:19:46 thats interesting Jun 13 18:20:07 from: the world, to: the world. Jun 13 18:20:12 board does not have ip address so that would be a logical step Jun 13 18:20:29 from the board i receive BOOTP request with ipv4 src=0.0.0.0 and dst=255.255.255.255 Jun 13 18:32:18 ka6sox: any idea if it`s good to do that way? Jun 13 18:51:19 <_av500_> vvu|Mobile: you reply with the ip of the board Jun 13 18:51:24 <_av500_> and with the server ip Jun 13 18:51:36 with the ip i will assign Jun 13 18:51:40 <_av500_> yes Jun 13 18:51:44 okok Jun 13 18:51:52 <_av500_> I guess it does not matter much Jun 13 19:12:32 identification for the packet, is really necessary to be in some order or i can assign a random number there? Jun 13 19:39:31 <_av500_> vvu|Mobile: repeat the ID you get Jun 13 19:39:35 <_av500_> its in the RFC :) Jun 13 19:47:36 _av500_: the rndis packet that i send back should have the same size as the one received with the bootp request, right ? Jun 13 19:47:46 the data should be same length Jun 13 19:47:50 <_av500_> I guess so Jun 13 19:48:06 something is fishy in my code, don`t get same at the end Jun 13 19:48:28 i receive 406 bytes data in length and the packet that i construct has 342 Jun 13 19:49:07 64 bytes M.I.A Jun 13 19:50:13 <_av500_> well, compare and you will find out Jun 13 19:50:26 doing now hexdumps Jun 13 19:52:03 since you are screwing with the kernel, I wonder if it is easier to get the CDC driver working Jun 13 19:53:17 will the ROM accept this? Jun 13 19:55:42 modify the host side to accept what the ROM sends Jun 13 19:56:04 IIRC, RNDIS is a slight variant on the stock CDC stuff Jun 13 19:56:28 then usb0 is all that needs to be muck with but then this requires root Jun 13 20:05:40 _av500_: my lenghts are same everywhere maybe at some allocation i`m doing wrong Jun 13 20:06:29 ds2, we would have to see if uboot works with cdc Jun 13 20:06:37 and ask tartarus Jun 13 20:14:00 _av500_: the frame i`m receiving from BBB has some padding Jun 13 20:28:24 _av500_: wireshark tells me that magic cookie has 4 bytes, vendor class identifier 12 bytes, client identifier 83 bytes, end option 1 byte and 28 bytes of padding inside bootp Jun 13 20:29:56 the bootp i receive from the board is 364 and mine 300, exactly 64 that i have missing Jun 13 20:59:18 think i solved it a bit. bootp but with dhcp structure Jun 13 21:10:15 nno no Jun 13 21:10:19 not saying use CDC protocol Jun 13 21:10:31 use the RNDIS stuff but modify the CDC driver to understand RNDIS Jun 13 21:10:42 AFAIK, RNDIS exists to keep windows folks fromyelling too much Jun 13 21:11:26 that way most of the framing stuff is done already Jun 13 21:19:33 I think there is an existing RNDIS ethernet gadget Jun 13 21:19:48 gadget yes, host, no Jun 13 21:20:01 the RNDIS gadget shares code with the CDC, it is a build option Jun 13 21:22:08 seems like a lot of what vvu is looking into might be easier if we just mod the CDC host driver Jun 13 21:28:18 <_av500_> ds2: linux has no rndis host? Jun 13 21:28:21 <_av500_> I am sure it has Jun 13 21:28:29 <_av500_> I think I saw the source code file Jun 13 21:28:42 <_av500_> vvu|Mobile: yes, we knoe that the BBB sends 364 bytes Jun 13 21:28:53 <_av500_> we saw that in the first hexdump Jun 13 21:29:09 can i send it normal bootp packet size 300 bytes ? Jun 13 21:29:56 <_av500_> I have no idrea Jun 13 21:30:00 <_av500_> you can just try Jun 13 21:30:09 AFAIK, linux uses just CDC mode...but I could be out dated Jun 13 21:30:30 let me look since I am waiting for a damn compile Jun 13 21:30:30 <_av500_> or you can just wireshark a boot via bootp and tftp server Jun 13 21:30:38 <_av500_> and use asa referecne Jun 13 21:30:54 _av500_: trying now to put all structs in one big char buffer and send it Jun 13 21:31:01 you are right Jun 13 21:31:12 there is a rndis host side support Jun 13 21:31:37 so if that works then we can avoid reimplementing the wheel (assuming the requirement of room is ok) Jun 13 21:32:30 <_av500_> ds2: the idea is still to not root Jun 13 21:32:37 <_av500_> on devices where usb host works Jun 13 21:32:42 ah okay Jun 13 21:32:47 nevermind Jun 13 21:33:34 _av500_: do you still see a lot of modern devices wehre usb root does not work? Jun 13 21:33:48 most of what i coming through for me seems to work fine as host Jun 13 21:33:50 usb host I mean Jun 13 21:39:05 but I don't expect any of them to provide a proper amount of power to the devices Jun 13 21:50:01 powered hubs can solve that Jun 13 21:50:37 given the nasty hack in the BBB/BBW u-boots to enable >500mA draw on USB, any strict USB port won't work well anyways Jun 13 21:59:59 _av500_: tried to send it like that 300 bytes packet, did not start tftp procedure. Jun 13 22:02:22 here is my hexdump of what i am sending http://pastebin.com/3HtbqJZ1 Jun 13 22:11:14 <_av500_> as said before Jun 13 22:11:31 <_av500_> compare to wireshark capture of successful Jun 13 22:11:42 <_av500_> using bootp and tftp Jun 13 22:11:53 yup going to set up things now Jun 13 22:29:14 my packet has something wrong. 300bytes bootp with bootpd makes BBB to send ARP request for the gateway Jun 13 22:31:12 you probally spec'ed a tftp server off the network or your netmask is wrong Jun 13 22:32:32 192.168.1.3 and mask 255.255.255.0 Jun 13 22:35:06 wjat os ir tftp server speced in the packet as? Jun 13 22:35:08 what Jun 13 22:35:12 what is your Jun 13 22:37:21 a second trying to figure things out here Jun 13 22:44:34 got tftp request Jun 13 22:57:11 got thing sent to board with bootpd+tftpd Jun 13 22:57:17 but again bad MLO Jun 14 00:45:11 _av500_: now my code outputs the same hexdump of what i`m sending as wireshark for a good bootp reply. the only thingie to check is the rndis stuff...maybe something is messy there **** ENDING LOGGING AT Fri Jun 14 02:59:58 2013