**** BEGIN LOGGING AT Sat Sep 12 02:59:57 2020 Sep 12 02:59:58 now Sep 12 03:00:01 fun isn't it :P ugh, I hate it when getting stuff right is made a giant pain in the ass because people didn't think about the interfaces they put on products Sep 12 03:11:07 so something like this on the servo rail? https://www.ebay.com/itm/223195849396 Sep 12 03:11:43 to power them from the beaglebone and they would shut off Sep 12 03:14:20 that would be an alternative to switching the 5V using a mosfet controlled by a gpio (with default pull-down) Sep 12 03:14:43 (though actually using a mosfet for that purpose wouldn't work anyhow) Sep 12 03:17:00 i didnt study electrical stuff, just what i have picked up along the way. why would that not work tho Sep 12 03:17:24 not meant to be on constantly? Sep 12 03:17:55 ive used them to make vape before with a button Sep 12 03:18:58 that is intermittent use of a few seconds Sep 12 03:20:11 because the gate voltage required to switch the mosfet is relative to the voltage you're switching, i.e. 5V in this case Sep 12 03:21:22 ah Sep 12 03:23:16 you know im thinking it Sep 12 03:23:39 to use a mosfet to have a gpio switch a load you'd use an n-channel mosfet on the low side (5V -> load -> mosfet -> GND) so the gate voltage is relative to 0V, but switching the GND to the module is absolutely forbidden in this case Sep 12 03:27:08 note that if you have a level shifter then you don't need to switch power to the module.... if you have a level shifter / buffer that's tolerant to having 3.3V on its input even when unpowered then using that on the gps module's serial output would protect the beaglebone Sep 12 03:28:05 i need to switch power the module cause it doesnt turn off Sep 12 03:28:12 if the battery is plugged in Sep 12 03:28:28 ah right, it's not just about protecting the beaglebone Sep 12 03:28:52 i dont want to unplug replug the lipo all the time Sep 12 03:28:55 ughhh why oh why did they expose an always-on 5V supply Sep 12 03:28:59 just the barrel jack to charge Sep 12 03:29:01 it seems like a terrible decision Sep 12 03:30:50 other micros are same way i guess you just dont notice it bacause they dont usually turn off unless you unplug them Sep 12 03:31:18 other micros generally only have one supply Sep 12 03:31:34 with the micro being on if and only if the supply is present Sep 12 03:33:39 oh i forgot it is seperate not on if powered by usb Sep 12 03:35:20 wait, the "always-on" 5V is not on when powered from usb?! Sep 12 03:35:33 correct Sep 12 03:35:43 you're right.. my own diagram ( https://photos.app.goo.gl/6SyBtF3oUzcwn5G98 ) actually clearly shows that, lol Sep 12 03:37:04 note that in this diagram the stuff in blue (i.e. just SYS_5V and everything powered from it directly or indirectly) is what's switched off when you use the poweroff command (or power button) Sep 12 03:37:54 I guess I should have drawn the servo supply output in blue since it's enabled by a gpio Sep 12 03:38:24 but i think it also is not working with usb only Sep 12 03:38:35 ive not tried but i think i read that Sep 12 03:39:00 what? the 6V supply? correct, that should be evident from the diagram Sep 12 03:40:27 I think it might not even work if you're powering from 12V with no battery connected, though I'm not sure... maybe the charger would directly feed the 6V regulator in that case Sep 12 03:41:10 the pwr header is powered with barrel jack and no battery Sep 12 03:41:51 yeah but that's definitely expected since the 12V has a direct path to the 5V regulator Sep 12 03:42:28 oh you mean the servo supply Sep 12 03:42:54 I suspect that motor drivers and 6V servo supply both require the presence of a battery, having just 12V won't suffice... that's my guess anyway, I'm not sure Sep 12 03:43:58 ok. sorry if im being dense Sep 12 03:44:48 im like 40 years old learning this as hobby. Sep 12 03:46:09 programming for years only the last few messing with micros and stuff Sep 12 03:46:49 i do appreciate your time Sep 12 03:47:53 actually I'm pretty sure the 12V can't supply the motor drivers and servo supply directly without battery present.. I really don't think the battery protection IC would allow it Sep 12 03:48:48 actually never mind Sep 12 03:49:13 one of the things that sold me on it was tertiary power supplies.... Sep 12 03:49:24 hm? Sep 12 03:49:53 usb or barrel jack or lipo Sep 12 03:50:14 but everything does not work in all modes Sep 12 03:50:23 kinda sucks Sep 12 03:50:46 thing is that motors require high peak current which are typically very problematic to deliver except from a battery Sep 12 03:50:49 i mean i understand usb cannot handle the motors and stuff Sep 12 03:51:47 yeah they really really should have made sys_5v available, and in particular used it on the GPS header Sep 12 03:52:02 I do wonder if TP1 (which connects to SYS_5V) is accessible to solder onto Sep 12 03:56:07 found it, it's a round pad on the bottom side (kinda between the lipo header and the servo headers) Sep 12 03:56:51 that would suck though, and would probably not be trustworthy in the presence of vibrations Sep 12 03:57:24 i see it Sep 12 03:57:44 but yeah, that's the 5V supply that's on if and only if the processor is on Sep 12 03:58:25 does anyone know how I can get can0 and or can1 up and running on the beaglebone wireless, it doesn't seem to be up with the latest image Sep 12 03:59:20 kip77: hmm? I don't think anyone should be significantly different than before, and both can interfaces seem to be present Sep 12 04:00:07 AM3358 Debian 10.3 2020-04-06 4GB SD IoT Sep 12 04:00:14 This is the image i am running Sep 12 04:00:21 obviously not up by default since you need to switch the pins to can mode (or alternatively enable a can overlay to configure the pins by default) and configure the interface settings before you can bring it up Sep 12 04:00:29 I don't see can0 in dmesg or when I try to do ip set link can0 up Sep 12 04:00:32 but that's how it's always worked afaik Sep 12 04:00:40 ehh, then something is wrong Sep 12 04:00:45 I do see them Sep 12 04:00:59 you're booting from sd card rather than from eMMC ? Sep 12 04:01:37 if there's an old system (or more specifically an old bootloader) on eMMC then booting from sd card can result in myserious problems, including stuff like this Sep 12 04:01:44 I get in dmesg when I try to do link up, bit-timing not yet defined Sep 12 04:01:48 I guess I missed that step Sep 12 04:02:09 oh so you *do* have the can0 interface? Sep 12 04:02:14 you're being a bit confusing Sep 12 04:02:26 and there's nothing new about having to setup bit timing Sep 12 04:03:08 (I think anyway... I've done very little with can on the BBB and that was also a very long time ago) Sep 12 04:04:32 yea seems to be good, sorry. I was working with a different kernel version and didn't see it up and then went back to the regular image and forgot to set the bitrate, looks like it's working as intended. Sorry for the confusion Sep 12 04:05:37 you should probably stick to the default (4.19-ti) kernel series unless you have a very good reason not to **** BEGIN LOGGING AT Sat Sep 12 04:22:01 2020 Sep 12 05:34:22 if i wanted to read about how to make my own bootloader down to bare metal where are some good places to start Sep 12 05:35:39 I'm not sure there's a good answer to that... a bootloader requires a substantial variety of very specific bits of knowledge Sep 12 05:37:04 though obviously one of the more important things is knowing the hardware on which it needs to run very well Sep 12 05:40:17 beaglebone seems like a good target--relatively very open, arm, nice variety of hardware Sep 12 05:40:43 yeah and bootrom takes care of the some of the SoC initialization for you Sep 12 05:41:01 so if you're okay with running at 500 MHz initially (instead of 1 GHz) then you don't need to fuck with the PLLs Sep 12 05:43:16 I've fiddled a bit with baremetal code on the BBB... you really don't need much initialization. I had one small start file written in assembly for basic cpu setup and for the exception handler wrappers ( https://liktaanjeneus.nl/start.S.html ) and the rest I could do in plain C++ with small bits of inline asm Sep 12 05:44:21 i think i just don't know where to start. most things i find assume linux Sep 12 05:45:44 unfortunately I don't have any public baremetal C++ project for the BBB, which I did once make a tiny baremetal application in assembly (because someone asked): https://github.com/mvduin/bbb-asm-demo Sep 12 05:46:25 which is something I don't actually recommend, there's absolutely no reason for most of this to be written in assembly, but at least it shows how one might setup the makefile and build something that is able to run directly on the BBB Sep 12 05:49:16 i'll poke around. i see a lot of magic numbers in the makefile Sep 12 05:49:36 well ok just one in the Makefile 0x402f0400 Sep 12 05:51:28 so, the "MLO" file is basically just a raw binary (with entrypoint at the start in ARM mode) with a 2-word header in front of it containing the address where the binary should be loaded and the length of the binary Sep 12 05:51:49 which bootrom uses to load the binary (e.g. from SD card) to ram Sep 12 05:52:22 the same address is also in the linker script: https://github.com/mvduin/bbb-asm-demo/blob/master/demo.ld#L26-L28 Sep 12 05:53:22 some boot methods do not have this header and therefore do not have any freedom in where to load the code, bootrom uses the fixed address 0x402f0400 for those Sep 12 05:53:51 though even if you could there's really no reason to use a different address Sep 12 05:54:17 it's the start of the accessible part of the internal SRAM (0x402f0400 - 0x4030ffff) Sep 12 05:54:25 so where did you find that kind of information Sep 12 05:55:54 the AM335x Technical Reference Manual is absolutely essential for anyone who wants to write baremetal code for it... https://www.ti.com/product/AM3358#tech-docs Sep 12 05:56:56 generally speaking whenever I learn about a new chip I'd definitely also check out the errata to see if there's anything important to beware of Sep 12 05:57:15 you probably won't need the datasheet, that's more for hardware designers Sep 12 06:01:22 obviously the TRM isn't something you'd casually read cover to cover, but you'll want to read the Introduction chapter and perhaps take a quick glance at the introductions of other chapters to try to have some idea of what's in there in case you have a need for it at a later point Sep 12 06:01:36 yeah this is helpful Sep 12 06:01:50 chapter 26 (Initialization) is especially important for a bootloader or any other code that's loaded directly by bootrom Sep 12 06:03:10 SRAM_Internal 0x402f_0400 Sep 12 06:03:56 since you'd be doing initialization of the cortex-a8 you'll also care about Chapter 3, as well as (from ARM) the ARM Cortex-A8 Technical Reference Manual and the ARMv7-A/R Architecture Reference Manual Sep 12 06:04:55 getting *anything( working on the AM335x beyond just the cpu will also involve the Power, Reset, and Clock Manager so chapter 8 is a must-read as well Sep 12 06:08:45 yeah this is very helpful. i'll look through these all Sep 12 06:09:27 you'll also need the Control Module (ch 9), which is just a grab bag of miscellaneous chip config, notably pin configuration Sep 12 06:10:37 wow just found this too https://github.com/allexoll/BBB-BareMetal Sep 12 06:10:45 you can find C++ headers for prcm, the control module, and the gpio controllers in include/ti/subarctic/ here: https://github.com/dutchanddutch/jbang Sep 12 06:11:04 interesting, never seen that before Sep 12 06:11:58 im kinda ideating about a project to learn some of this hardware stuff as well as Rust, which I think is exciting as a potential C replacement Sep 12 06:12:07 rust is neat Sep 12 06:12:29 rust keeps getting stuck on my "I really ought to play with this some more" list Sep 12 06:12:52 heh, this guy couldn't get any boot method other than tftp/bootp working Sep 12 06:12:58 I guess he probably overlooked the MLO header Sep 12 06:13:19 I am inspired by some of this work https://os.phil-opp.com/ Sep 12 06:13:22 having said that, tftp/bootp is definitely the most convenient boot method for doing baremetal development Sep 12 06:15:45 you'd run a bootp and tftp server on your computer (my asm demo includes an example config file for dnsmasq, which can do both bootp and tftp) which can serve the binary straight from your project directory, so after running "make" you'd reset the BBB and it'll download the new binary directly from your computer over the network Sep 12 06:16:41 i need to do some reading and i will have better questions i think Sep 12 06:17:05 yeah, and try compiling my asm demo and running it on the bbb Sep 12 06:17:09 sd card method is easiest Sep 12 06:21:22 should you be inclined to try the bootp/tftp method, it can do it either via the usb device port (with bbb showing up as RNDIS network interface) or via ethernet. normally the boot order is { eMMC, μSD, uart, usb } so you could wipe eMMC and have no sd card inserted to get it to usb boot, though you can avoid wiping eMMC by pulling sysboot2 (P8.43) to ground with a wire which changes the boot order ... Sep 12 06:21:28 ...to { spi, μSD, usb, uart } Sep 12 06:22:09 additionally pulling sysboot0 (P8.45) up to 3.3V changes the boot order to { spi, μSD, ethernet, uart } Sep 12 06:23:15 (the sysboot pins, P8.31-46, are sampled at power-on to determine the various configuration for bootrom. note that these pins are not sampled again at warm reset, so to change the boot config you need to power-cycle) Sep 12 06:28:29 thank you **** ENDING LOGGING AT Sun Sep 13 21:09:00 2020