**** BEGIN LOGGING AT Thu Nov 12 02:59:56 2020 Nov 12 03:00:31 ok.... I guess my confusion is based on how these are being placed in memory so that there is no overlap in structs Nov 12 03:00:38 I need to stare at this a bit more i guess Nov 12 03:00:45 what are "these" ? Nov 12 03:00:49 I get most of the other stuff Nov 12 03:00:57 message struct Nov 12 03:01:00 the ringbuffer is an array of struct Message, so they are inherently non-overlapping Nov 12 03:01:16 ok I do not see the array declaration Nov 12 03:01:49 in the c code where is the array defined Nov 12 03:01:53 that is what I am missing Nov 12 03:02:46 it's not defined as an array in C since it's not allocated there, it is allocated (in the shared ddr memory region) by python, which passes a pointer to the array to PRU via "msgbuf" in DDRLayout Nov 12 03:03:23 so python really does all the memory management. C just gives the mapping to shared space for the PRU Nov 12 03:03:35 python does the memory management for the shared ddr memory region Nov 12 03:03:38 and python drops an array of message in there and moves the pointers accordingly? Nov 12 03:03:50 ? Nov 12 03:04:37 the array is allocated once during initialization, PRU writes its messages into that array (and updates widx to indicate where it's at), python reads the message from that array (and updates ridx to indicate where it's at) Nov 12 03:04:38 python manages the read pointer and write pointer for the array. C doesn't care about the array it just needs the index Nov 12 03:04:52 python manages teh read-pointer, PRU manages the write-pointer Nov 12 03:05:20 ok Nov 12 03:05:20 I have not the slightest idea what you mean by "C doesn't care about the array it just needs the index" Nov 12 03:05:34 probably better you dont lol Nov 12 03:05:41 what you just wrote makes things clear Nov 12 03:05:47 forget what I said Nov 12 03:05:57 in send_message() you can see PRU accessing the array (ddr.msgbuf[widx]) Nov 12 03:07:01 since I assume that in a real-world application your message has a bunch of stuff you want to fill out I create a pointer (msg) to the message for convenience Nov 12 03:07:30 right Nov 12 03:07:38 to avoid having to write ddr.msgbuf[ widx ].id = id; and repeat that verbiage for each field you need to set Nov 12 03:07:58 this is an array declaration 0x80000000 <= (uint32_t)ddr.msgbuf Nov 12 03:08:13 ??????!??!? Nov 12 03:08:18 what does the comment right above it say? Nov 12 03:08:24 sanity check Nov 12 03:08:36 does that sound like anything is being declared? Nov 12 03:08:42 but you also said you initialize the array Nov 12 03:08:43 once Nov 12 03:08:50 no I didn't Nov 12 03:08:50 there is nothing else in there Nov 12 03:09:14 I said it is allocated during initialization... by python Nov 12 03:09:40 correct, the pru side here has nothing to do but sanity-check Nov 12 03:10:52 ok let me play with it. I get most of the C code still wading through the python Nov 12 03:10:57 it will seep in eventually Nov 12 03:11:10 last question for the night Nov 12 03:12:46 .. yes? Nov 12 03:13:17 (I've earlier also done my last push for the night) Nov 12 03:13:53 was looking at assembly version of stream.py instead of stream-c.py Nov 12 03:14:12 let me sit with this and not tax your sanity any more tonight Nov 12 03:14:22 i will have a less dumb question for you with more time Nov 12 03:14:44 right now I need to work through it myself so I can have a more productive dialog Nov 12 03:14:50 don't mix the two, they work differently Nov 12 03:15:01 yeah I think I was getting screwed up because of it Nov 12 03:16:09 the pointers in the assembly version are offsets from the start of the ringbuffer rather than indices into the array Nov 12 03:16:27 i.e. they are index * sizeof(Message) Nov 12 04:35:49 i'm back Nov 12 04:52:12 i'm gone Nov 12 06:25:42 hello Nov 12 08:37:18 hi i try to run demo script led blink on my new beaglebone its giving me error type error require is not a function Nov 12 08:41:32 odd Nov 12 08:42:37 unfortunately I never use bonescript or cloud9 myself so it'll be difficult for me to give useful advice Nov 12 08:42:55 ok Nov 12 08:43:12 i just started with beaglebone Nov 12 08:45:01 I just opened up cloud9 and ran the example I assume you mean (cloud9/BeagleBone/blinkLED.js) it seems to run fine Nov 12 08:49:07 ya thanks working with cloud9 Nov 12 08:59:07 hmm, it seems to sort of work when run directly ( node /var/lib/cloud9/BeagleBone/Black/blinkLED.js ) but it's somehow super slow and using 100% cpu load for most of the time, wtf is it doing Nov 12 08:59:12 oh he left Nov 12 10:15:42 this cloud stuff is freaking me out. if we stopped all that bs, global warming would be a non-issue :/ Nov 12 10:31:18 I mean, there's no cloud involved here, it's just web-based IDE running on the BBB Nov 12 10:31:27 called "cloud9" for some reason Nov 12 10:32:03 also, unfortunately global warming is not that easy to fix :P Nov 12 10:32:44 (and clouds may overall actually reduce energy consumption if they replace lots of individual servers) Nov 12 11:04:16 hi folks, Nov 12 11:04:44 recently i had an issue where my board was not powering up.. and got another board.. Nov 12 11:05:12 I am yet to open the package.. so if I just connect the USB to my Windows laptop, and login via Putty, this should work right? Nov 12 11:05:44 well wasn't your initial problem that your usb port couldn't provide enough power? Nov 12 11:06:26 also, I read that the user is supposed to poweroff the board in the right way instead of just pulling out the USB cable.. so what is the correct procedure to poweroff the BBB? Nov 12 11:06:26 unless of course the board was already damaged in a way that caused a short-circuit or something Nov 12 11:06:48 I mean, that's technically recommended yes. I never do it, but it is technically recommended :P Nov 12 11:07:33 you can press the power button (briefly) or use the command "sudo poweroff" in a terminal, either of these will trigger a shutdown (which can take a few moments) Nov 12 11:07:44 anyway, normally you just connect it via usb to a computer yeah Nov 12 11:07:48 zmatt yes, but later we discussed that since the power LED was OFF despite using a 5V power supply and the board was getting too hot with a burning smell, I concluded that the board is damaged.. Nov 12 11:08:22 well yeah but we didn't establish whether it was damaged prior to connecting the supply or damaged _by_ the supply Nov 12 11:09:46 well, I had no way to establish that.. Nov 12 11:10:12 right, so the 5V supply is still suspect Nov 12 11:11:22 i tried connecting the board to my other laptops. and still the same issue.. It was not detected.. getting too hot.. Nov 12 11:11:49 "same issue" as in powering on briefly repeatedly? Nov 12 11:12:15 which iirc was the original behaviour you reported Nov 12 11:12:37 together with a message from the OS about port power surge or something Nov 12 11:12:48 yes and no.. the LED is ON briefly but no light after few seconds Nov 12 11:13:40 was it getting warm the first time too, before you had tried the 5V supply? Nov 12 11:14:03 like, getting warm while no leds are on implies a short-circuit in or before the PMIC Nov 12 11:14:39 since all leds being off implies the rest of the board is unpowered Nov 12 11:15:08 agreed.. so you mean to say that my board is not damaged? I can try other means to power it ON? Nov 12 11:15:20 no I mean to say that sounds like it's severely damaged Nov 12 11:15:37 in a weird place Nov 12 11:16:10 well, then I did the right thing to get another board.. Nov 12 11:17:17 like, normally if people fry a beaglebone it's almost always the processor that got damaged, which typically results in a very very brief flash of the power led when power is applied and nothing more, it just immediately shuts off and consumed no power nor produces any heat Nov 12 11:18:34 anyway, as for your original question, yes normally you should be able to plug a beaglebone into an USB port with the supplied cable and it should boot normally Nov 12 11:19:32 and once booted it _should_ show up as network device allowing access via an SSH client (e.g. PuTTY) and the web interface Nov 12 11:22:12 though if the beaglebone is running old firmware it might not show up in Windows since USB is a mess on Windows. That's one of the reasons it's a good idea to always reflash a new beaglebone to the latest firmware, since you never know how old the firmware it ships with it (since it may have been sitting on a shelf in a warehouse for a long time) Nov 12 11:23:18 ok got it.. I will try connecting to an Ubuntu laptop instead of my Windows Nov 12 11:23:22 it *is* possible for a USB port of a computer (especially an older laptop) to be unable to power the beaglebone (resulting in the port power being shut off), though it is uncommon Nov 12 11:23:36 well the OS you use won't affect whether it powers on obviously Nov 12 11:24:09 it's just about whether it recognizes the device as a network interface Nov 12 11:25:39 yea.. agreed.. Nov 12 11:25:42 which always works on linux, if the firmware on the BBB is new enough it will work on any OS that support the standard USB class for Ethernet devices ("CDC-ECM") including Mac and Linux Nov 12 11:27:23 meanwhile Microsoft doesn't give a fuck about standards, requiring you to instead use its own proprietary "RNDIS" protocol (that performs a similar function, but in an incompatible way), and even then it's proven to be obnoxiously hard to convince Windows to use its own fucking driver for its own fucking protocol :P Nov 12 11:28:02 i presume flashing the latest firmware is the next step.. it involves using a microSD card right? does it really takes 45 mins to flash the new image from the SD card to the board? Nov 12 11:28:15 nah that's a serious overestimate I think Nov 12 11:29:29 I think 5-15 min is more realistic Nov 12 11:29:54 but haven't tested recently, I generally flash smaller images than the recommended IoT image Nov 12 11:31:52 now, I connected the new BBB to the Ubuntu laptop, the POWER LED is ON, all the 4 user LEDs were ON briefly and now 1 and 3rd LEDs are blinking.. Nov 12 11:32:06 i can see that the board is detected in ls /dev/ttyACM0 Nov 12 11:32:12 that sounds like it's booting yeah Nov 12 11:32:59 thanks a million zmatt.. now I m going to power off technically and reboot the board again Nov 12 11:33:31 yes it will (or should anyway) appear as a composite device of 4 functions: 1. mass storage (a read-only "disk" which is just a small image containing a README and some useless drivers I think) Nov 12 11:34:34 2. usb serial (CDC-ACM), which is kinda like a serial console and can be useful for certain recovery tasks if you manage to break networking Nov 12 11:34:50 3. a CDC-ECM network interface for operating systems that implement the USB standard Nov 12 11:34:57 4. an RNDIS network interface, for Windows Nov 12 11:35:04 but this time i did not see any CDC-ACM message in the dmesg console Nov 12 11:35:29 ? Nov 12 11:35:53 "this time" ? what did you do different? has it finished starting up yet? Nov 12 11:36:27 no no.. i did not power off the board yet.. just opened it from the package, connected to my Ubuntu laptop.. then ls /dev/ttyACM0 Nov 12 11:37:23 I'm not sure what you're trying to communicate currently Nov 12 11:38:21 btw note that some laptops may have on-board USB serial devices (e.g. for a modem) so the existence of /dev/ttyACM0 is only useful information if you're sure it didn't already exist prior to connecting the bbb ;) Nov 12 11:39:26 the usb device showing up should also be reported in kernel log (monitor with "dmesg -w" or "journalctl -k -f") Nov 12 11:39:40 ttyACM0 did not exist in the past.. I thought I will poweroff the board by logging into it.. before that I thought of chekcing the kernel logs to see the CDC-ACM message which was missing.. Nov 12 11:40:47 that doesn't make much sense, a usb device showing up should result in a few number of messages in the kernel log, especially so for the complicated 4-function composite device that the BBB presents Nov 12 11:40:57 *a fair number of messages Nov 12 11:41:56 some GSGs mentioned that.. so i was looking for that Nov 12 11:44:42 https://pastebin.com/raw/ngawZhmk Nov 12 11:45:03 that's what I get in my kernel log after connecting a BBB (once it has started up) Nov 12 11:45:21 ok thanks.. Nov 12 11:45:41 i am trying to ssh into the board.. sudo ssh root@192.168.7.2 what is the password here? Nov 12 11:46:57 why are you putting "sudo" in front of ssh? don't do that Nov 12 11:47:08 ssh debian@192.168.7.2 Nov 12 11:47:25 it should actually tell you the password is "temppwd" :P Nov 12 11:48:44 yup.. debian not root.. thanks a million once again.. Nov 12 11:48:49 have a nice day Nov 12 11:52:21 huh the BBB shows up as CDC-NCM rather than CDC-ECM ... interesting Nov 12 11:52:50 i am signing off now.. bye Nov 12 11:53:32 bye Nov 12 11:55:29 Hello guys, I'm searching for a cross-toolchain for beagle bone black, debian 10 (buster) with gcc 8.3 Nov 12 11:56:13 I looked in the chat logs, linaro toolchain is mentioned and I used it for previous debian versions, it worked ok Nov 12 11:56:54 but currently for gcc 8 linaro redirects to an ARM toolchain that's missing some stuff Nov 12 11:57:35 can you recommend a compatible cross-toolchain? Nov 12 11:58:54 cross-toolchain for what host OS ? if you're using debian or ubuntu just install its toolchain (apt-get install g++-arm-linux-gnueabihf) Nov 12 12:02:07 The host is ubuntu 20.04, I did install g++-arm-linux-gnueabihf, no luck Nov 12 12:02:14 "no luck" ? Nov 12 12:02:24 but... let me try something, brb Nov 12 12:12:34 ok, sorry, a more detailed description Nov 12 12:15:40 the linaro/arm toolchain with gcc 8.3 on build complains about: ... /ld ... libboost ... undefined reference to .... const@GLIBCXX_3.4... Nov 12 12:15:48 the ubuntu toolchains complains about: ... ld ... undefined reference to `i2c_smbus_read_i2c_block_data... Nov 12 12:16:14 the latter sounds like you're missing a library Nov 12 12:16:56 also please don't try to summarize errors, copy-paste them verbatim into a paste service like pastebin.com and share the url here Nov 12 12:17:30 copy-paste-pastebin.com -> ok Nov 12 12:18:53 I tried to install the armhf library libi2c-dev libi2c0 for ubuntu toolchain, unfortunately apt doesn't find it, I do have multiarch enabled and armfh added Nov 12 12:19:03 also, if you're rebuilding some project with a new toolchain, be sure to "make clean" first, having the project files compiled with one toolchain and then trying to link the project with another toolchain is a recipe for disaster Nov 12 12:19:50 yes, I always do a make clean before a new build Nov 12 12:20:04 libi2c-dev:armhf definitely exists in ubuntu 20.04 Nov 12 12:20:42 (as shown by https://packages.ubuntu.com/focal/libi2c-dev ) Nov 12 12:21:05 yep, I did search for it at packages.ubuntu.com and it exist Nov 12 12:21:45 so if apt can't find it you must have made some mistake in the apt source or something, dunno Nov 12 12:21:47 I'll double my multiarch and armhf Nov 12 12:21:51 apt sources Nov 12 12:22:03 double check *** Nov 12 19:26:34 Sorry for delay, apparently the issue I have with undefined reference to i2c_smbus_... (https://pastebin.pl/view/26d45b1e) was always present, I just missed it, I'll try and fixed it, after that I cross-compile with ubuntu toolchain and see what I get Nov 13 00:36:15 isnt boolean a standard type Nov 13 00:36:16 identifier "bool" is undefined Nov 13 00:39:38 switched to _Bool Nov 13 01:18:49 mostly that fits under "depends" which language variant. Nov 13 01:26:29 C Nov 13 01:26:44 i am surprised not consistent Nov 13 01:59:56 when is it ok to use a global variable Nov 13 02:00:07 I have four and I feel dirty lol **** ENDING LOGGING AT Fri Nov 13 02:59:57 2020