**** BEGIN LOGGING AT Sat Feb 17 03:00:01 2018 Feb 17 03:00:47 arduino uno? doesn't it use 5V i/o ? Feb 17 03:01:05 if so, you're absolutely not allowed to connect it to the beaglebone without using level shifters Feb 17 03:01:34 Oh. Feb 17 03:01:42 Okay. Feb 17 03:01:54 I have one that uses 3.3v too. Feb 17 03:07:01 config-pin rules! Feb 17 03:08:07 But...I did not have it set to a service and now I must start over and set it as a service. Feb 17 03:08:13 I rebooted. Feb 17 03:20:51 Okay...get this: I need to set up uart1, 2, 4, and 5 so it sticks. I found my U-Boot, .dts files I need. Shoot! Feb 17 03:22:01 I am off to read more. Feb 17 03:28:35 If this .dts file runs smooth like this community has been discussing, that is better than awesome. It is nifty! Feb 17 03:37:05 Get this and do not laugh: I just added a uart1 and my other uart capabilities are gone now b/c I enabled one when they were all enabled anyway. Feb 17 03:37:08 Oops! Feb 17 03:37:23 It works! Feb 17 03:55:45 You should be careful when things work! Feb 17 03:59:12 I know. Feb 17 03:59:22 I am already getting pissy. Feb 17 04:02:26 I am about to run this software from this fellow that wrote a book. Feb 17 04:03:13 I have my Rx and Tx connections, an update to the Uno, and the BBG is about to run some software, in Python, that connects my BBG to the Arduino! Feb 17 04:03:14 Boy! Feb 17 04:03:37 I am about to pee. Feb 17 04:04:35 Set pin mode failed for uart channel! Feb 17 04:04:36 ... Feb 17 04:04:37 No! Feb 17 04:06:43 I think I know what happened. I might be in a different pin mode. Rx might just be Tx. Feb 17 04:06:45 Who knows? Feb 17 04:06:49 I will test it! Feb 17 04:13:30 No go. Sheesh. Feb 17 04:53:41 Not sure if im doing this right, is anyone in the channel? Feb 17 04:54:44 hiya, anyone here? Feb 17 06:52:54 tip: just ask your question and wait patiently Feb 17 06:58:25 Hi everyone...want to contribute to Beagleboard.org as a part of GSoC...can somebody help me out from where to get started? Feb 17 06:59:28 there's a separate channel for GSoC, #beagle-gsoc Feb 17 07:00:59 Ok, Thank you Feb 17 07:53:15 zmatt: hey after I copied the etc file from your lib to my etc, I have not been able to use the am335x_pru_package because it returns a segmentation fault Feb 17 07:53:19 How can I undo this? Feb 17 07:53:33 jus remove the etc file and /dev/uio ?? Feb 17 08:00:12 uh what? which file specifically? Feb 17 08:00:30 also lol at that segmentation fault, that sounds like really high-quality error-handling there Feb 17 08:01:47 pch chuck that for now.. :p Feb 17 08:01:57 my udev rules shouldn't have any effect on other stuff really, they just set up some symlinks Feb 17 08:01:57 umm the 09-uio Feb 17 08:02:05 okay cool Feb 17 08:02:06 yeah, that one just sets up some symlinks Feb 17 08:02:30 I've just updated py-uio btw Feb 17 08:02:55 it now includes an example for sending events from pruss Feb 17 08:03:28 alright ill pull Feb 17 08:04:13 (that one also requires etc/udev/rules.d/10-of-symlink.rules and etc/udev/hwdb.d/uio-pruss.hwdb Feb 17 08:04:18 ) Feb 17 08:04:40 so btw how would i access the PRU's ram? with core(x).iram right? but how do I know where to write memory in the ram? Feb 17 08:04:40 (be sure to run systemd-hwdb update whenever adding/removing/changing hwdb files) Feb 17 08:04:58 the new example also includes usage of data ram Feb 17 08:07:04 dram0.map? Feb 17 08:07:07 just pushed two minor changes Feb 17 08:07:12 ok newb question but what does map do Feb 17 08:07:25 :p Feb 17 08:08:56 region.map( type, offset=0 ) will return an instance of the given type (which must be a ctypes type) at the given offset in that memory region Feb 17 08:09:50 so, in this case, at the start of the core's dram there's a structure with parameters Feb 17 08:11:17 which occupies 5 bytes? Feb 17 08:11:44 yes Feb 17 08:12:05 what does this do? irq = Uio( "pruss/irq%d" % IRQ ) Feb 17 08:12:27 opens the device for the interrupt Feb 17 08:12:36 it's basically like prussdrv_pru_event_fd() Feb 17 08:13:01 the name there needs to match the one declared in the hwdb file Feb 17 08:14:12 so if I did a = pruss.dram.map(b), I could modify the values b stored on pru's ram by modifying a? Feb 17 08:14:51 modifying fields of a will directly modify pru memory yes Feb 17 08:15:01 b would be the type Feb 17 08:15:43 so like, pruss.dram0.map(Params) is like using prussdrv_map_prumem() to get a pointer to pru0's data ram and then casting that to (Params *) Feb 17 08:18:09 what does this do pruss.cfg.intc = 0 Feb 17 08:18:33 see ti/icss/cfg.py Feb 17 08:19:31 it's not needed here, but 0 allows pruss to be able receive various system interrupts, while 1 is a useless setting on the beaglebone (yet it's still the default) Feb 17 08:20:48 what is "use mii-rt events" Feb 17 08:21:47 oh sorry, I thought the register was better documented in that file than it actually is Feb 17 08:22:28 ah, the relevant comment I was thinking of is actually here https://github.com/mvduin/py-uio/blob/master/ti/icss/intc.py#L43-L45 Feb 17 08:23:26 so it replaces events 32-55 (which normally come from various peripherals) by events from the mii-rt modules in pruss, which are not usable on the beaglebone Feb 17 08:23:48 wow there was no way i could've figured that one out myself Feb 17 08:25:23 the PRUSS tab of this spreadsheet lists the actual irqs on the am335x: https://goo.gl/7YooOO Feb 17 08:26:44 tbh thats mostly greek to me, and tbemh I have not understood fully the concept of the INTC :( Feb 17 08:28:34 intc receives 64 interrupt/event signals, filters them, prioritizes them, and routes them to 10 irq outputs (2 to the pru cores, 8 to the cortex-a8) Feb 17 08:29:36 have you been able to try the example? Feb 17 08:32:23 the spreadsheet lists which interrupt/event signals connect to the 64 inputs of the pruss intc Feb 17 08:34:40 you know, I just realized that it would probably actually be a lot clearer if I just passed the full path of devices to the Uio and Icss constructors instead of implicitly prepending /dev/uio (and appending /module for Icss) Feb 17 08:35:32 yeah Feb 17 08:36:31 im pulling the repo now Feb 17 08:40:22 if you pull again, the examples now use full paths when calling those constructors Feb 17 10:44:37 hi how to install Qt in beagleboad x15 Feb 17 10:57:34 hi Feb 17 15:45:42 can someone tell me the difference between pru iram and dram? Feb 17 15:49:18 okay this is the blind leading the blind, but I'm looking at this: https://elinux.org/Ti_AM33XX_PRUSSv2 Feb 17 15:50:28 and I'm guessing that the PRU's instruction pointer can only point to locations in IRAM Feb 17 15:51:32 and it looks like for the main CPU to access IRAM it has to go through that OCP thing Feb 17 15:52:01 Just guessing, cuz I'm too lazy to do something like read the TRM :P Feb 17 15:53:26 its too intimidating for me :p Feb 17 15:53:45 ok could you help me with the am335x_pru_package? Feb 17 15:55:03 I want to write a integer value to the RAM of PRU1, can I do this: prussdrv_pru_write_memory(PRUSS0_PRU1_DATARAM, 0, &data, 4)? Feb 17 15:56:35 if I had an array of 4 integers in data, and I sent them as prussdrv_pru_write_memory(PRUSS0_PRU1_DATARAM, 0, &data, 16), firstly is this correct? Feb 17 15:56:37 I have no idea, I just lurk here :D Feb 17 15:56:45 oh lol ok Feb 17 15:57:04 but if you promise to stick around a while (don't just close your browser tab and vanish!), there's a good chance that folks with more clue will appear. Feb 17 15:57:13 ok cool Feb 17 15:57:54 In the meantime, try looking for other PRU projects that do what you want to do. Find a working example and start removing all the parts you don't need, checking at each step that the part you want is still working. Trim it down to nothing and there you go! Feb 17 16:07:48 I've been avoiding it all this time, but what exactly is the PRU_EVTOUT_X??? Feb 17 16:10:35 what does your preliminary research indicate? Feb 17 16:15:18 umm i have no idea, I don't know where to refer to, both this and the INTC have me confused Feb 17 16:15:38 also the mapping of the DATARAM, how do we send data and receive data to and from the PRU Feb 17 16:16:44 i think that EVTOUT_0 maps to /dev/uio0 interrupt Feb 17 16:23:34 Surely there must be some other projects (beaglelogic and prudaq come to mind) that've documented how they move data to/from the PRU Feb 17 16:24:05 I don't know this stuff (like I said, I just lurk here) but if I wanted to build something on the pru, that's where I'd start looking Feb 17 16:26:11 also, http://processors.wiki.ti.com/index.php/PRU_Interrupt_Controller#Interrupt_Mapping Feb 17 16:32:30 zmatt: I have a few questions regarding py-uio, for the pruss: 1) I wrote my program to iram1 and ran pruss.core0 and the program ran, how? Feb 17 16:33:23 2) what do these instructions do? https://pastebin.com/W4J5HkE8 Feb 17 16:40:01 3) when I do pruss.core0.r[x] which RAM am i accessing? Feb 17 17:19:51 sorry i lost connection and i didn't tnotice Feb 17 17:19:59 man this library is fucking amazing Feb 17 17:27:48 brb pizza Feb 17 18:28:23 well I need to work on my asm code a bit more Feb 17 18:41:51 what is the number of clock cycles the pru takes to read the DRAM? Feb 17 18:42:00 if im running LBCO &r0, c24, 0, 32 Feb 17 19:05:18 1. I don't know, maybe there was still a program there from a previous test you did? Feb 17 19:07:43 3. .r[x] are the core's registers. you can only access these while the core is halted Feb 17 19:10:07 lbbo/lbco from the local data ram is 2+n cycles to read n words Feb 17 19:10:25 you're reading 8 words hence 10 cycles Feb 17 19:13:28 the pruss.cfg.intc bit selects whether irq inputs 32-55 of the intc come from: 0 = various peripherals on the SoC, 1 = the pruss mii-rt modules Feb 17 19:13:49 option 1 is default, but the mii-rt modules are not usable on the beaglebone so this default is useless Feb 17 19:14:27 for a list of all interrupt/event signals available to the pruss intc, see the PRUSS tab of this spreadsheet: https://goo.gl/7YooOO Feb 17 19:15:24 idlemode/standbymode are related to power management and 'auto' is their default setting, so you can ignore and omit those two statements Feb 17 19:17:04 if standbyreq is true (default) the pruss cores will hang if they try to use their master port to the L3 interconnect (i.e. try to access anything outside of PRUSS) Feb 17 19:17:17 oh so that is the cop bit Feb 17 19:17:19 ocp* Feb 17 19:18:56 the master port is an ocp port yes, although calling it 'the ocp bit' is a bit confusing since it's not called that in the documentation and pruss.cfg also has an 'ocp' field with one bit per core Feb 17 19:19:49 sorry i meant the part where we enable the ocp port Feb 17 19:19:50 https://pastebin.com/jKqNY3hu Feb 17 19:19:51 anyway, I've often seen pru programs that clear this bit, but it seems a bit useless to let the pru cores do this when you can just as easily enable it in advance before running your program Feb 17 19:20:45 yes that's exactly equivalent to pruss.cfg.standbyreq = False Feb 17 19:22:03 i guess the example has enough to get me started with simple program loading, and read/write data with the PRUs? Feb 17 19:22:12 any tips/tricks you can suggest? Feb 17 19:23:23 the new example I made yesterday also shows how to share some data structure (of parameters in this case) in dram between python and the pru core, and sending events from pru to python Feb 17 19:23:53 alright ill check that out Feb 17 19:24:25 thanks for taking the pain to write this Feb 17 19:24:48 you're welcome Feb 17 19:26:35 please note that further enhancements (e.g. more nice accessors for the various registers) will probably have to come from people other than me, I don't intend to spend much more time on py-uio since I dislike writing in python Feb 17 19:26:53 but hopefully this is enough to get people started out Feb 17 19:27:10 yeah i mean what else is needed? Feb 17 19:27:53 potentially a lot Feb 17 19:28:01 like..? Feb 17 19:28:39 like right now configuring the direct i/o features of the pru core would require writing magic hex values into registers Feb 17 19:29:05 what do you mean by configuring the direct io features???? Feb 17 19:29:26 https://github.com/mvduin/py-uio/blob/master/ti/icss/cfg.py#L29-L47 Feb 17 19:29:35 won't that be done in assembly? Feb 17 19:29:55 im sorry i don't get it, what does that do? Feb 17 19:30:08 oh Feb 17 19:30:11 you could, but it would be a lot nicer to do one-time setup like that in python Feb 17 19:30:35 but more important would probably be some stuff to debug pru programs Feb 17 19:30:46 how would you configure an interrupt in assembly? Feb 17 19:31:21 right now I've made almost no accessors to the pru core control register, e.g. to allow single-stepping Feb 17 19:32:19 uhh, same as you would in python, assuming you're referring to the configuration of the intc Feb 17 19:32:46 no like, to catch a signal edge on the pru_in pins Feb 17 19:32:53 sorry for not being clear Feb 17 19:33:02 you can't get any interrupt on that Feb 17 19:33:40 so id have to keep polling? Feb 17 19:33:43 note that "interrupts" to the pru cores aren't really interrupts... it's just that irq outputs 0 and 1 of the intc are connected to bits 30 and 31 of r31 input of both cores Feb 17 19:34:07 so you can check for those as easily as you can check pru input pins Feb 17 19:34:36 no im saying, like in my assembly code, say a counter needs to start counting when a pin goes high.. Feb 17 19:34:44 yes, poll Feb 17 19:35:53 or enable some bits in core0/1.wake_en use the SLP instruction to have the core sleep until one of those bits is set in r31 Feb 17 19:36:49 okay cool Feb 17 19:44:52 zmatt: if my asm code runs in an infinite loop (i.e i never halt the core), how can i reset the program on the core? with pruss.core0.full_reset() ?? Feb 17 19:45:04 or just by loading a new program onto it? Feb 17 19:45:14 full_reset() yes Feb 17 19:45:15 you Feb 17 19:45:28 ?? Feb 17 19:45:36 you're not allowed to access iram or .r[x] unless the core is halted Feb 17 19:45:47 sorry, accidently pressed enter Feb 17 19:46:23 wait so if i had a code that constantly updates the DRAM with some values, I cannot access them at any random time, unless core is halted? Feb 17 19:46:29 full_reset() is a bit overkill if you just want to reset the core, but it's a good choice if you want to load a fresh program Feb 17 19:46:38 you can't access *iram* unless the core is halted Feb 17 19:46:52 there's no such restriction for dram Feb 17 19:46:57 but won't .r[x] access dram? Feb 17 19:47:00 no Feb 17 19:47:09 those are the core's registers Feb 17 19:47:13 then?? Feb 17 19:47:16 .r[0] is literally r0 Feb 17 19:47:22 oh right tlol Feb 17 19:47:23 sorry Feb 17 19:47:40 it should be pretty obvious you can't access those unless the core is halted Feb 17 19:47:48 so for writing/reading from dram via your code? Feb 17 19:47:55 see the new example Feb 17 19:49:04 ohhh dram.map Feb 17 19:49:34 if i get it right, dram.map(int int) will write to the first two registers of the dram? Feb 17 19:49:58 no Feb 17 19:50:04 whut Feb 17 19:50:06 then? Feb 17 19:50:36 if you just want to write data to dram, use dram.write( data, offset=0 ) similar to iram.write Feb 17 19:50:54 okay cool Feb 17 19:50:57 dram.map( Structure, offset=0 ) returns a directly mapped data structure Feb 17 19:51:09 ohhhh i see Feb 17 19:51:57 like using prussdrv_map_prumem, adding the offset, and casting the result to (Structure *) Feb 17 19:52:37 so in the new example, reading/writing fields of 'params' will directly access the pru's dram Feb 17 19:52:37 yeah understood now :), other than the .rules file, do i need to copy any more? if im not interested in interrupts that is Feb 17 19:53:05 etc/udev/rules.d/09-uio-pruss.rules is the only one required if you don't care about interrupts Feb 17 19:53:56 technically you could even avoid that one if you follow the bad example of prussdrv and just blindly assume that /dev/uio0 belongs to uio_pruss Feb 17 19:54:19 (and have your program break spectacularly if there's ever any other uio device on the system. I personally use uio for all sorts of peripherals) Feb 17 19:54:51 what you mean like for sensors and stuff? Feb 17 19:55:19 for on-chip peripherals like eHRPWM, eQEP, the ADC Feb 17 19:55:21 stuff like that Feb 17 19:55:27 like how? i use newb-level smbus for i2c sensors.. Feb 17 19:55:34 you can't use it for that Feb 17 19:56:00 well, you could use uio to map an entire i2c controller to userspace I guess Feb 17 19:56:06 instead of using the kernel driver Feb 17 19:56:35 but that sounds pointless and annoying to me Feb 17 19:57:19 yeah ahahah Feb 17 19:58:25 note that py-uio originally didn't even support pruss, the initial examples were for eQEP and for routing a gpio irq to userspace (you don't really need uio for the latter, although it has the benefit of working for any sort of irq, not just a gpio irq) Feb 17 19:58:47 I added pruss recently in response to someone having trouble with pypruss Feb 17 19:58:56 oh interesting Feb 17 19:59:04 i didnt even bother with pypruss it looked so ancient Feb 17 19:59:15 jkridner even took out an issue about the sam e:p Feb 17 19:59:18 same :p Feb 17 19:59:52 prussdrv is kinda icky. I've been wanting to make a replacement lib but haven't really gotten around to it yet Feb 17 20:37:18 zmatt: when using dram.write(data, offset=0), it saying the range of data has to be between 0 and 256, how can I pass an array in? Feb 17 20:38:09 write expects raw data, i.e. a bytes object Feb 17 20:38:55 if you want to write e.g. 32-bit integers, you either need to encode them into a bytes object, or map the array with something like dram.map( ctypes.c_uint32 * 32 ) Feb 17 20:38:56 okay so if i have a list ill have to convert it into an array of bytes? Feb 17 20:39:20 and then write your data to that array Feb 17 20:42:06 so for sending an array for say 4 integers, can i run data = dram.map(types.c_uint32 * 32) ; data = array[i] in a for loop? Feb 17 20:42:16 * 4 in that case Feb 17 20:42:26 where array[x] holds the integers Feb 17 20:42:28 yeah sorry Feb 17 20:43:01 so it would be data = array, but not in a for loop? Feb 17 20:43:30 data = array wouldn't work since that doesn't modify the data object, it just assigns the array object to the data variable Feb 17 20:43:38 data[:] = array is fine however Feb 17 20:44:51 and dram.map doesn't have any offset param? Feb 17 20:45:00 it has an optional offset parameter Feb 17 20:45:07 ok Feb 17 20:45:08 defaulting to 0 Feb 17 20:45:16 same for write and read Feb 17 20:48:46 hi Feb 17 20:49:44 zmatt: awesome Feb 17 20:50:20 Is it possible to do sonic boom with this kind of jet https://www.youtube.com/watch?v=ae3ju4rEGgQ Feb 17 20:50:57 I suspect that's a views-spam bot? Feb 17 20:51:10 btw I haven't checked yet whether write/read are even remotely efficient. I am slightly concerned about the possibility it might access each byte individually instead of using a memcpy. using map is recommended for now Feb 17 20:51:10 or someone so hilariously confused even Babbage couldn't express it Feb 17 20:51:13 Ya seems that way Feb 17 20:52:21 zmatt: so .map is fast? I would be updating the dram from my main code at about 400Hz, would it be past enough for that? Feb 17 20:52:41 or maybe using the mmap object directly (like write/read do) was okay, just using a memoryview wasn't Feb 17 20:52:47 I vaguely remember there was something Feb 17 20:53:17 well all of this is python, so "fast" is relative, but 400 Hz is pretty slow Feb 17 20:53:18 zmatt: ?? Feb 17 20:53:31 okay cool Feb 17 20:53:31 zmatt: I am sorry do you have BBB? Feb 17 20:53:46 jamesaxl: lol Feb 17 20:54:04 why do you care what equipment I have? Feb 17 20:55:31 zmatt: I am just curious and i did not force you to answer. Feb 17 20:56:33 most people here will have a BBB or some variant beaglebone. a few might perhaps only have one of the other beagleboard variants Feb 17 20:58:02 zmatt: just to confirm once again, setting cfg.standbyreq to False enables the OCP master port.. Feb 17 20:58:06 yes Feb 17 21:00:50 just out of curiosity, how do you "prussdrv_pru_disable" and "prussdrv_exit" ?? (sorry but I have no idea what those functions do so i don't know if they're needed in py-uio or not) Feb 17 21:02:38 btw I just verified .read()/write() are efficient, so no worried about using those when appropriate Feb 17 21:02:50 alright good to know Feb 17 21:03:56 hmm, memoryview also seems to be efficient... maybe the issue I ran into back then (when I first worked on py-uio) was a bug that has been fixed then Feb 17 21:04:04 lemme see what those functions in prussdrv do, hold on Feb 17 21:04:14 yeap Feb 17 21:07:10 prussdrv_exit just unmaps memory and closes file descriptors. it's not necessary to do this when exiting. py-uio currently has no equivalent other than just getting rid of all references and letting garbage collection do its job. I guess it wouldn't be too hard to add a close() method if desired Feb 17 21:07:45 disable just does pruss.core0/1.control = 1 Feb 17 21:08:35 what i s"garbage collection"? Feb 17 21:09:08 this halts the core, and also disables single-stepping and the cycle counters (that's a bit ugly tbh, it ought not do those things I think) Feb 17 21:09:24 google is your friend Feb 17 21:09:31 oh right sorry Feb 17 21:11:27 most users of py-uio will probably not have any reason to close the uio device anyway Feb 17 21:11:58 yep agreed Feb 17 21:27:19 zmatt: well gn, im dozing off, thanks again for your time Feb 17 21:27:29 you're welcome Feb 17 23:29:13 I have installed Stretch Debian with graphics and want to execute sudo commands but am ask for a password, help Feb 17 23:32:16 so enter the password of the debian account? Feb 17 23:32:21 (temppwd by default) Feb 17 23:33:03 thanks, that seems to work Feb 17 23:35:07 I tried that earlier and no luck, rebooted and tried it again and it's working. thanks Feb 18 01:53:27 * duncan^ has received a pocket beagle. Feb 18 01:53:39 However, I'm having trouble connecting to it via UART. Feb 18 01:54:08 I've connected RX, TX, and GND. Feb 18 01:54:29 try switching RX and TX Feb 18 01:54:37 Done that :p Feb 18 01:54:39 ok Feb 18 01:54:40 :) Feb 18 01:55:03 What should I see when there is no software installed on the SD card. U-boot should output /something/, right? Feb 18 01:55:04 always test the easy things first :) Feb 18 01:56:13 Or do we only have first-stage u-boot installed (which doesn't output anything?) Feb 18 01:56:42 duncan^: it loads u-boot from sd card Feb 18 01:56:51 including the first stage Feb 18 01:57:01 there's no on-board flash Feb 18 01:58:21 Do I need U-boot to be on a specific filesystem? It's on an ext4 partition at the moment. Feb 18 01:58:33 I'm also using upstream - is there support in upstream at the moment? Feb 18 01:58:43 why not use the official image? Feb 18 01:58:52 Because I'm not using Debian. Feb 18 01:59:08 I thought Buildroot would be more straightforward. Feb 18 02:00:04 uh, the official debian image is obviously more straightforward since you just download an image, flash it onto sd, and have a working system :) Feb 18 02:00:49 Right, sure :) Feb 18 02:01:07 spl and u-boot need to be at fixed offsets on the SD card (located between the partition table and the first partition) Feb 18 02:01:15 a less often used alternative is to use a FAT boot partition Feb 18 02:02:26 The latter seems like something I should try. Feb 18 02:02:28 the offset for the MLO containing u-boot spl is sector 256. the start sector for u-boot.img is 768 Feb 18 02:02:32 Thanks for your help :) Feb 18 02:02:47 for FAT the files need to be named "MLO" and "u-boot.img" Feb 18 02:03:01 the FAT partition needs to be partition 1 and marked bootable iirc Feb 18 02:03:37 I don't know if there's mainline support for the pocketbeagle yet Feb 18 02:05:39 there isn't in u-boot v2018.01 Feb 18 02:06:31 I've found https://eewiki.net/display/linuxonarm/PocketBeagle#PocketBeagle-Bootloader:U-Boot Feb 18 02:06:34 Cool. Feb 18 02:07:17 yeah that's the u-boot used on official beaglebone images Feb 18 02:07:30 you can also find them prebuilt at https://rcn-ee.com/repos/bootloader/am335x_boneblack/ Feb 18 02:07:55 you probably don't care about the overlays patch if you're not using the official image, or maybe you do, I dunno Feb 18 02:27:04 Whoops, it wasn't buildroot now I recall Feb 18 02:27:27 I was using Alpine Linux's generic armhf image, which doesn't have the proper u-boot version. Feb 18 02:27:31 makes sense I guess Feb 18 02:28:11 Well regardless, starting from a known-good image seems like a sane way to prove out your UART setup. Once something works, start tinkering, yeah? Feb 18 02:28:49 Yes, I'm going to sleep now Feb 18 02:28:53 Thanks all. Feb 18 02:28:55 btw, as for expecting uart output Feb 18 02:29:23 if there's no sd card and you avoid enumerating it as usb device (e.g. use an usb charger instead of a computer), it should emit CCC on the serial console Feb 18 02:29:35 (attempting XMODEM boot) Feb 18 02:29:51 Yes, CCC was seen every time Feb 18 02:29:55 ok Feb 18 02:30:18 so that answers your "What should I see ..?" Feb 18 02:30:25 Yes it does. Thanks. Feb 18 02:30:29 Oh that's hilarious. that's in the chip's core? xmodem baked in? Feb 18 02:30:49 the boot order is { spi flash, μSD, usb (rndis), uart (xmodem) } Feb 18 02:31:20 myself: yes it is. that's by no means the weirdest boot device it supports though Feb 18 02:31:38 the winner for that goes to presenting itself as usb rndis device and doing netboot over that Feb 18 02:32:38 That's a lot of silicon for a rarely-used feature. But super amusing. Feb 18 02:32:54 I bet some customer demanded it a decade ago. Feb 18 02:33:08 the usb thing is great for recovery purposes I think Feb 18 02:33:30 and easier to deal with than the older usb boot of omap SoCs Feb 18 02:33:48 a lot of these peripheral modes are not meant as primary boot device obviously Feb 18 02:33:52 DFU? *shudder* Feb 18 02:34:01 no I think even weirder Feb 18 02:34:07 custom Feb 18 02:34:50 I remember I was playing with an nvidia tk1 at work a while back, and couldn't reflash it because the IT goons' USB-security-shim-shit on the work laptop. I brought in my personal machine to do the reflash and it went flawlessly. :P Feb 18 02:35:48 USB-security-shim-shit ? Feb 18 02:36:55 yeah, like this thing that logs the serial number of every flash drive connected, and enables only approved devices. For engineering laptops, the approved-device mask is "everything", so I don't know why it's even installed, but it gets in the way of all sorts of stuff. Feb 18 02:37:38 Corporate IT is only slightly above corporate legal departments on my scale of 'people who could cease to exist and I'd shed nary a tear'. Feb 18 02:38:12 lol Feb 18 02:38:42 it actually does sound like somewhat useful functionality in some situations Feb 18 02:38:45 I have this perverse desire to try that rndis-boot thing... tftp once the interface is up, I assume? Feb 18 02:39:02 I have an example of how to use it at https://github.com/mvduin/bbb-asm-demo Feb 18 02:39:28 it'll build a tiny demo you can run on a beaglebone Feb 18 02:39:35 and there's a dnsmasq.conf in extra Feb 18 02:41:17 Hah, neat. Feb 18 02:41:35 So the bbb has an ethernet port, but I didn't notice that in your boot order list? Feb 18 02:41:52 oh right, you need to fiddle with the boot order Feb 18 02:42:39 pull P8.43 down (or equivalently hold down the S2 button) and pull P8.45 up Feb 18 02:42:46 during power on Feb 18 02:43:18 but if you want to try usb rndis then the default boot order is fine Feb 18 02:43:37 aye, ok. Feb 18 02:43:48 or, well, eMMC is first then on the BBB. so you'll probably want to hold down the S2 button to get eMMC out of the boot order Feb 18 02:44:10 BBB default is { eMMC, μSD, uart, usb } Feb 18 02:44:18 BBB with S2 button held down is same as pocketbeagle Feb 18 02:44:30 is the rom code readable / storred in some sort of OTP? Feb 18 02:44:43 it's rom, not OTP Feb 18 02:44:48 part of the SoC's mask Feb 18 02:44:54 a ok Feb 18 02:45:17 you can dump public ROM, you cannot dump secure ROM (on the am335x at least, they fucked up the protection of secure ROM on the related dm814x) Feb 18 02:48:19 interesting Feb 18 02:54:44 (public ROM is located at 0x40020000 - 0x4002bfff with an alias at 0x20000-0x2bfff) **** ENDING LOGGING AT Sun Feb 18 03:00:00 2018