**** BEGIN LOGGING AT Thu Apr 06 03:00:03 2017
Apr 06 04:35:06 <zmatt> lol, I just tested whether the omap-sham driver (for the md5/sha1/sha256 hw accelerator) is useful at all, by comparing: regular sha256sum  vs  the in-kernel sha256-neon (sw) and omap-sha256 (hw) implementations (the latter two via AF_ALG)
Apr 06 04:35:10 <zmatt> https://pastebin.com/raw/tBfz84V8
Apr 06 04:35:30 <zmatt> it's slower *and* produces the wrong answer
Apr 06 04:35:32 <zmatt> nicely done
Apr 06 06:12:00 <LetoThe2nd> zmatt: don't be so harsh. as we all know, its only essential that the generated hashes are unique ;-)
Apr 06 06:28:38 <ayjay_t> zmatts the worst person to work with
Apr 06 06:28:43 <ayjay_t> someone who knows what hes talking about XD
Apr 06 06:43:38 <thinkfat> gm
Apr 06 09:22:30 <parduz> hello. There's any wxWidgets 3.1.x library compiled for the BBB Jessie? I can't find any, and i failed to compile the sources...
Apr 06 09:23:29 <smallhorse> hi，i am smallhorse
Apr 06 09:25:53 <smallhorse> i have some problem about the beaglebone black wireless with 4DCAPE-43T LCD
Apr 06 09:26:11 <smallhorse> just only backlight and nothing display
Apr 06 09:28:00 <smallhorse> anyperson can give me help? thank you
Apr 06 10:42:03 <ayjay_t> ooooh
Apr 06 10:42:10 <ayjay_t> sorry smallhorse i wish i could help you
Apr 06 10:42:20 <ayjay_t> i love the bbb and i love lcd capes!
Apr 06 10:42:34 <ayjay_t> but its hard to help without any further information
Apr 06 10:47:21 <grove> ayjay_t: He left about a minute after asking
Apr 06 10:47:40 <kyranf> i hate that
Apr 06 10:47:45 <kyranf> kids these days
Apr 06 10:47:57 <kyranf> gone like the wind, before they even let their fart settle.
Apr 06 10:48:24 <kyranf> does anyone know of plans for a dual/quad core beaglebone updated hardware?
Apr 06 10:48:51 <kyranf> everyone is bringing out these wifi enabled ones, which is great (i'm using the BB green wireless from Seeedstudio currently for a big project)  but I really need more guts in the processor
Apr 06 10:49:05 <LetoThe2nd> kyranf: there is V
Apr 06 10:49:06 <LetoThe2nd> https://beagleboard.org/x15
Apr 06 10:49:15 <LetoThe2nd> nothing else in the rumours.
Apr 06 10:49:17 <kyranf> i'm crunching opencv solvePnP algorithms and trying to run multi-threaded applications with some form of reasonable speed
Apr 06 10:49:52 <kyranf> i need the same form-factor (or smaller) as the beaglebone black/green/blue
Apr 06 10:50:07 <kyranf> the X15 looks neat though
Apr 06 10:50:10 <LetoThe2nd> well then probalby no beagle for you.
Apr 06 10:50:26 <kyranf> i'm thinking to transition to the Odroid offerings
Apr 06 10:50:31 <kyranf> small, crazy quad-cores
Apr 06 10:51:03 <LetoThe2nd> engineering rule #1 use what fits the problem.
Apr 06 10:51:37 <kyranf> actually #0 supercedes that, as long as it's a grey area, which is "use what you know to get shit done fastest"
Apr 06 10:52:41 <kyranf> it turns out, after benchmarking, that the  1Ghz single core AM335x just isn't quite fast enough for me.. :(  It will do, but  I was hoping there was a more powerful version in the works from the beaglebone community
Apr 06 10:54:32 <agraf> kyranf: you certainly don't want the beagle for its cpu power ;)
Apr 06 10:54:56 <agraf> kyranf: its main point for it are the PRUs
Apr 06 10:55:00 <kyranf> no, i wanted it for the GPIO, I2C, wireless (from the green wireless version) and small formfactor
Apr 06 10:55:05 <agraf> kyranf: if you don't need PRUs, something different is probably better
Apr 06 10:55:19 <agraf> kyranf: check out the 96boards
Apr 06 10:55:21 <kyranf> there was a possibility of using the PRUs for interfacing with my FPGA
Apr 06 10:55:37 <kyranf> but I ended up using an ARM cortex m4 as the interface between the BB and the FPGA
Apr 06 10:56:33 <kyranf> interfacing with the FPGA like a massive shift register using the PRU and 16-bit parallel data bus would have been neat, in hindsight
Apr 06 10:56:41 <kyranf> and it could just be buffered straight into shared RAM with the ARM core
Apr 06 10:57:07 <agraf> kyranf: yeah, the 16-bit shift should work well if you have an FPGA on the other side
Apr 06 10:57:15 <agraf> kyranf: or does it? hmm
Apr 06 10:57:21 <kyranf> I really like the PRU and i've used it before, like 5 years ago on the original BB white
Apr 06 10:57:35 <agraf> kyranf: well, depends on how you design your protocol, but since you have control over everything it might just work :)
Apr 06 10:57:38 <kyranf> i have a low-end FPGA, Lattice ICE40
Apr 06 10:57:48 <kyranf> and yeah, it is already fully custom
Apr 06 10:58:07 <kyranf> well currently it's over SPI at 24Mhz but the packets are all custom (of course)
Apr 06 10:58:29 <agraf> kyranf: if you can use proper hard ip blocks, you're even better off, true
Apr 06 10:58:52 <kyranf> no, i had to scavenge soft SPI IP blocks for this particular FPGA :(  . anywho, i don't fully regret using the BB
Apr 06 10:59:03 <agraf> kyranf: so again, if all you need are just reasonably good CPUs and a small form factor plus wifi, even the original hikey wouldn't be too bad
Apr 06 10:59:25 <kyranf> the intel edison on a carrier board might have been a good match too
Apr 06 11:00:22 <kyranf> jesus christ the hikey is insane
Apr 06 11:01:07 <agraf> :)
Apr 06 11:01:21 <kyranf> an octo- 1.2Hz!?
Apr 06 11:01:26 <kyranf> gHz*
Apr 06 11:01:50 <agraf> yep
Apr 06 11:01:57 <agraf> kyranf: if you need more power, the x20 also has A72s
Apr 06 11:01:58 <kyranf> if i could get opencv to compile on that beast, and if it has an external I2C bus and a couple of GPIO this would be epic
Apr 06 11:02:38 <agraf> kyranf: opencv should theoretically run on the GPU even, no?
Apr 06 11:02:48 <kyranf> only if the GPU is supported
Apr 06 11:02:52 <kyranf> by opencv
Apr 06 11:02:56 <kyranf> when it's compiled
Apr 06 11:03:21 <kyranf> the BB is meant to have GPU acceleration for openCV but i'm not sure if it is working or not
Apr 06 11:03:53 <agraf> i see
Apr 06 11:04:09 <agraf> well, then you may want to look at the qcom chip - it has an open source gpu stack now
Apr 06 11:04:30 <agraf> "dragonboard"
Apr 06 11:04:42 <agraf> i haven't played with that one yet though
Apr 06 11:05:07 <agraf> but if opencv is your main use case, you may want to explore something with a usable gpu for it
Apr 06 11:05:21 <agraf> either way, use the beagle for things the beagle is great at :)
Apr 06 11:05:43 <kyranf> indeed
Apr 06 11:05:55 <kyranf> well thanks for the chat agraf, I appreciate it
Apr 06 11:14:29 <kyranf> actually relating to performance on the beaglebone, with the latest linux kernels, have you guys had any luck with changing p-thread priorities and the scheduler to round-robin in C++ ??
Apr 06 11:14:47 <kyranf> all the examples I find are either out-dated, or fail silently (they appear to work, but don't)
Apr 06 11:15:16 <kyranf> as in, i can set the scheduler and priority without any errors thrown/perror set, but when i read the thread priority back it hasn't changed. :(
Apr 06 11:17:33 <ayjay_t> grove do you keep join/parts on?
Apr 06 11:29:57 <grove> ayjay_t: Yes
Apr 06 11:59:04 <ayjay_t> ugh so gross
Apr 06 13:13:18 <ayjay_t> hmm i'm trying to execute a NOP in SRAM but I get an exception each time meh
Apr 06 13:33:26 <thinkfat> ayjay_t: not properly mapped?
Apr 06 13:34:34 <ayjay_t> no i think its fine
Apr 06 13:34:39 <ayjay_t> the address is correct
Apr 06 13:34:46 <ayjay_t> http://xomf.com/sgynl
Apr 06 13:34:51 <ayjay_t> as soon as i type "si" though it will break
Apr 06 13:35:08 <ayjay_t> http://i.xomf.com/sgynl.png is better
Apr 06 13:35:33 <ayjay_t> you can see its a nop at 0x1ffff000 which is the correct ram address
Apr 06 13:56:51 <thinkfat> ayjay_t: what's your jtag backend, openocd?
Apr 06 13:58:38 <ayjay_t> thats right
Apr 06 13:59:13 <thinkfat> ayjay_t: and working on a frdm board with a kl43z
Apr 06 14:00:20 <ayjay_t> fuck yah thinkfat lol why
Apr 06 14:00:40 <ayjay_t> i'm actually working on a custom board now but i hooked it up to the FRDM board just to see why RAM was crashing
Apr 06 14:00:43 <ayjay_t> TOLD ME NOTHING
Apr 06 14:02:10 <thinkfat> ayjay_t: no, just making sure you're not on a bbb trying to execute something in sram
Apr 06 14:04:13 <ayjay_t> LOLEF
Apr 06 14:04:50 <ayjay_t> maybe i'll throw all those esoteric memory barrier commands and flushes and stuff at it
Apr 06 14:04:55 <ayjay_t> lets see how that does
Apr 06 14:06:09 <thinkfat> should not matter, no external observers
Apr 06 14:06:21 <thinkfat> I mean there's just one single cortex-m core
Apr 06 14:07:15 <thinkfat> I'm not really familiar with cortex-m, does it have an instruction and data cache?
Apr 06 14:08:51 <ayjay_t> no clue
Apr 06 14:08:58 <ayjay_t> don't understand how microcontrollers work on a fundemental level yet
Apr 06 14:09:11 <ayjay_t> and you're right it didn't matter
Apr 06 14:12:51 <ayjay_t> bah
Apr 06 14:14:13 <thinkfat> ayjay_t: on a cortex-a system I would be sure you'd have to invalidate the d- and i-cache after copying the code to sram
Apr 06 14:14:31 <thinkfat> ayjay_t: on cortex-m I'm not sure if such thing exists
Apr 06 14:22:05 <zmatt> there's a one-word write-buffer :P
Apr 06 14:23:44 <zmatt> and some amount of instruction prefetch... so if you'd make self-modifying code you will need dsb;isb after writing code before executing it I think
Apr 06 14:25:24 <ayjay_t> i mean i ran dmb; dsb; isb; bx r0;
Apr 06 14:25:26 <ayjay_t> then it goes to ram
Apr 06 14:25:29 <ayjay_t> and it breaks on nop
Apr 06 14:25:50 <ayjay_t> and htis is a resident function in ram
Apr 06 14:26:09 <ayjay_t> so its put there by the boot script
Apr 06 14:26:24 <zmatt> hmm, 0x1ffff000 .. that's in dcode/icode space
Apr 06 14:26:51 <zmatt> are you sure dcode and icode actually point to the same thing on this target? :P
Apr 06 14:27:14 <ayjay_t> were at the point where i google things you say and nothing turns up
Apr 06 14:27:15 <ayjay_t> what not
Apr 06 14:27:21 <ayjay_t> s/not/now/
Apr 06 14:27:38 <zmatt> which cortex-m is this?
Apr 06 14:27:43 <ayjay_t> 0+
Apr 06 14:28:30 <zmatt> ah nm, it doesn't have split buses
Apr 06 14:28:54 <ayjay_t> :-(
Apr 06 14:29:30 <zmatt> on the m3, the range 0x0 - 0x1fffffff can be different for data access and for code execution
Apr 06 14:30:09 <zmatt> (although it's not common to actually hook it up like that)
Apr 06 14:31:21 <ayjay_t> so maybe i should just try putting this somewhere else?
Apr 06 14:31:26 <ayjay_t> like a different range of ram
Apr 06 14:31:32 <ayjay_t> shots in the dark
Apr 06 14:31:42 <thinkfat> ayjay_t: what type of exception?
Apr 06 14:31:44 <ayjay_t> i'm /s/SRAM the trm right now to see if there are any hints
Apr 06 14:32:00 <ayjay_t> i actually don't know to tell the execption lol
Apr 06 14:32:11 <thinkfat> xpsr
Apr 06 14:32:14 <ayjay_t> it goes oh okay
Apr 06 14:32:49 <thinkfat> and openocd should tell you something, too
Apr 06 14:33:09 <zmatt> which mcu are you using?
Apr 06 14:33:38 <ayjay_t> oh gosh actually now that i've looked at open ocd it might be telling me a lot
Apr 06 14:33:48 <ayjay_t> its a freescale/nxp kl43 128kb
Apr 06 14:36:24 <ayjay_t> its a hardfault
Apr 06 14:37:17 <zmatt> probably because you don't have fault handlers, which means any fault escalates to hard fault.  presumably the m0+ has registers which give more details about the cause
Apr 06 14:38:03 <ayjay_t> i haven't set up any fault handlers
Apr 06 14:38:28 <zmatt> that's normally not a problem
Apr 06 14:39:56 <ayjay_t> i'm looking for a tbale to describe registers during a hardfault now in the trm
Apr 06 14:40:31 <thinkfat> how much sram?
Apr 06 14:40:40 <zmatt> 16 KB
Apr 06 14:40:41 <ayjay_t> 16kb
Apr 06 14:40:42 <ayjay_t> yeah
Apr 06 14:40:54 <thinkfat> and you load your code where?
Apr 06 14:40:56 <ayjay_t> i might just try and move it.. i mean what could be the worst that happens
Apr 06 14:40:59 <ayjay_t> into the vurry bottom
Apr 06 14:41:03 <ayjay_t> 0x1FFF0000
Apr 06 14:41:10 <zmatt> that's invalid
Apr 06 14:41:12 <thinkfat> indeed
Apr 06 14:41:27 <ayjay_t> typo
Apr 06 14:41:30 <ayjay_t> four f's
Apr 06 14:41:31 <ayjay_t> three 0's
Apr 06 14:41:42 <thinkfat> only 1/4th of sram is available below 0x20000000
Apr 06 14:41:45 <ayjay_t> right
Apr 06 14:41:55 <ayjay_t> which is 0x1000
Apr 06 14:42:01 <zmatt> indeed
Apr 06 14:42:02 <thinkfat> yes
Apr 06 14:42:07 <zmatt> strange memory map
Apr 06 14:42:08 <ayjay_t> so 0x1FFFF000 is where i load it
Apr 06 14:44:04 <thinkfat> trm doesn't have anything to say about sram
Apr 06 14:44:15 <ayjay_t> nope
Apr 06 14:44:34 <zmatt> apparently writes to peripherals are posted... that's not important right now but it's good to know
Apr 06 14:45:29 <thinkfat> ayjay_t: can you telnet to the openocd console while your debug session is on?
Apr 06 14:45:51 <thinkfat> and then type "arm disassemble 0x1ffff000 4 thumb"
Apr 06 14:45:51 <zmatt> i.e. if you write to a peripheral and need to be sure the write has landed there, you need to follow it by a read from the same peripheral
Apr 06 14:46:00 <zmatt> (same as on the am335x)
Apr 06 14:46:26 <ayjay_t> yeah i saw that read-write-serial it called it
Apr 06 14:46:43 <ayjay_t> okay so first i'm trying to load it into 0x20000000 and see if the ram there makes any difference
Apr 06 14:47:05 <ayjay_t> so in my startup copy function i should just perform a ldr after every str to ram?
Apr 06 14:47:14 <ayjay_t> and then i'm going to google telnet
Apr 06 14:47:15 <zmatt> no
Apr 06 14:47:27 <zmatt> this is about peripherals specifically
Apr 06 14:47:43 <ayjay_t> you're saying sram isn't a peripheral
Apr 06 14:47:49 <ayjay_t> i'm a lottle confused
Apr 06 14:47:53 <ayjay_t> at what you're getting at
Apr 06 14:48:48 <zmatt> it isn't, and even if it used posted writes it wouldn't matter since writes to memory have no side-effects
Apr 06 14:49:04 <ayjay_t> thinkfat: is that different than runnig the command from GDB with the "monitor" prefix? because i can "mon mdh 0x1ffff000"
Apr 06 14:49:09 <zmatt> hence I said "not important right now"
Apr 06 14:49:28 <ayjay_t> ohhh i didn't see what you wrote above thinkfat
Apr 06 14:52:01 <ayjay_t> i mean it reads at 46c0 which i'm sure is nop
Apr 06 14:52:50 <ayjay_t> oh that... that did something different
Apr 06 14:52:51 <zmatt> (btw apparently it *is* possible for an m0+ to be coupled to a cache, since the armv6-M architecture reference manual shows that the code space (below 0x20000000) is write-through while the "sram space" (0x20000000 - 0x3fffffff) is marked as write-back write-allocate.  I haven't seen any mention of a cache yet so I doubt it's used, though even if it is it wouldn't matter)
Apr 06 14:53:02 <ayjay_t> that address range behaved differently wow
Apr 06 14:53:09 <zmatt> hmm?
Apr 06 14:53:31 <ayjay_t> but... hmm
Apr 06 14:53:44 <ayjay_t> it looks like it didn't let me step through the hardfault ROM exception handler
Apr 06 14:53:51 <ayjay_t> and it just restarted and went to a breakpoint
Apr 06 14:53:54 <ayjay_t> lemme try again
Apr 06 14:55:18 <ayjay_t> sigh
Apr 06 14:57:12 <thinkfat> ayjay_t: yeah you can use "mon" in gdb instead of telnet to openocd
Apr 06 14:57:37 * zmatt is afk
Apr 06 14:57:45 <ayjay_t> yeah its turning up the right opcodes i think but
Apr 06 14:59:04 <thinkfat> ayjay_t: how do you get gdb to jump into sram?
Apr 06 14:59:37 <thinkfat> ayjay_t: or do you put a breakpoint there and just let it run?
Apr 06 14:59:42 <ayjay_t> i'm using si
Apr 06 15:00:02 <thinkfat> but from where?
Apr 06 15:00:10 <ayjay_t> flash
Apr 06 15:00:16 <ayjay_t> i'm stepping from the branch into ram
Apr 06 15:00:21 <thinkfat> ah ok
Apr 06 15:00:34 <thinkfat> what version of openocd?
Apr 06 15:01:10 <ayjay_t> 0.10.0-dv
Apr 06 15:01:10 <thinkfat> just collecting data
Apr 06 15:01:12 <ayjay_t> haha
Apr 06 15:01:23 <thinkfat> -dv is what? not official release I guess
Apr 06 15:01:40 <ayjay_t> sorry -dev
Apr 06 15:01:46 <ayjay_t> i didn't know if i should include that
Apr 06 15:01:49 <ayjay_t> i think i compiled this myself
Apr 06 15:02:00 <ayjay_t> so stepping works but
Apr 06 15:02:02 <ayjay_t> breakpoints dont
Apr 06 15:02:22 <thinkfat> oh that is weird
Apr 06 15:02:34 <thinkfat> hmm
Apr 06 15:03:05 <thinkfat> your openocd config, does it configure a work area, and where is it?
Apr 06 15:03:09 <ayjay_t> oh god
Apr 06 15:03:28 <ayjay_t> i should know this because you know, i had to modify the cfg file but
Apr 06 15:03:40 <thinkfat> just pastebin the file
Apr 06 15:03:40 <ayjay_t> i mean doesn't it only use that work area for programming?
Apr 06 15:03:57 <thinkfat> no
Apr 06 15:04:47 <ayjay_t> okay well i'm going to test it on a different board using SPI over uart so we'll know if it works lol
Apr 06 15:04:50 <ayjay_t> but yeah i'm getting that cfg
Apr 06 15:05:18 <ayjay_t> ah fuck it's at 0x20000000 @ 0x1000
Apr 06 15:05:22 <ayjay_t> the second number being the size
Apr 06 15:06:39 <thinkfat> iirc the work area is also used to fastpath the register retrieval on debug entry
Apr 06 15:06:47 <thinkfat> so it will corrupt SRAM at that address
Apr 06 15:07:13 <thinkfat> doesn't explain though why SRAM_L behaves strangely
Apr 06 15:07:20 <ayjay_t> i mean but all my reads are turning up correctly ahh
Apr 06 15:07:28 <ayjay_t> no i'm gonna end up calling nxp
Apr 06 15:08:26 <ayjay_t> it doesn't work even with isp
Apr 06 15:08:32 <ayjay_t> so it's probably not that workarea isue
Apr 06 15:13:40 <ayjay_t> oh my god
Apr 06 15:17:00 <Parduz> hello.
Apr 06 15:17:41 <Parduz> there's a wxwidget 3.1.x compiled library for the BBB jessie? i can't fin any and i failed to compile it from the sources
Apr 06 15:23:28 <ayjay_t> hey thinkfat do you know about the +1 rule with bx
Apr 06 15:24:15 <ayjay_t> i just want to really sincerely thank thinkfat and zmatt for trying so hard to help me
Apr 06 15:24:38 <ayjay_t> and i wanna deeply apologize for being somewhat mentally disabled
Apr 06 15:24:46 <ayjay_t> and i mean that sincerely
Apr 06 15:25:01 <ayjay_t> the bx instruction wasn't working properly because the last bit of any address has to be 1
Apr 06 15:26:05 <mistawright> so until my replacement beaglebone black comes in today. how can i flash a beaglebone black that will boot up to the point of uboot showing c's. Is there an easy way to flash the emmc as I believe the microsd card reader is not working
Apr 06 15:29:09 <ayjay_t> were you holding down the boot button?
Apr 06 15:31:35 <mistawright> dude im way pass stuff like that
Apr 06 15:31:46 <mistawright> like i said i am trying to flash through uboot
Apr 06 15:32:23 <ayjay_t> yeah but the boot button causes a hardware branch from the rom bootloader
Apr 06 15:32:24 <mistawright> through the microusb cable
Apr 06 15:32:25 <ayjay_t> thats pre-uboot
Apr 06 15:33:00 <ayjay_t> i'm glad your past it tho ha
Apr 06 15:33:54 <mistawright> smh
Apr 06 15:34:51 <thinkfat> ayjay_t: hum, arm-thumb interworking? yes
Apr 06 15:35:14 <thinkfat> ayjay_t: but I didn't think it applies to cortex-m as well since it only executes thumb
Apr 06 15:35:43 <mistawright> https://github.com/ungureanuvladvictor/BBBlfs is this still a viable method of flashing a different image to the beaglebone black?
Apr 06 15:36:15 <ayjay_t> thinkfat: well its works now aaaaaaaaaaaaaafff
Apr 06 15:36:44 <zeekhuge> NTQ: did that work ?
Apr 06 15:36:54 <thinkfat> you'd think the assembler took care of that automatically
Apr 06 15:36:56 <thinkfat> stupid toolk
Apr 06 15:37:57 <thinkfat> ah, but because you load r0 with the function address and not use bx directly it doesn't know...
Apr 06 15:37:58 <NTQ> zeekhuge: I did not quite understand how to use the compiled kernel module, the ko file. But today I can not work on the project. I don't have the beaglebone here.
Apr 06 15:39:02 <ayjay_t> yeah thats right i'm doing everything myself
Apr 06 15:40:15 <zeekhuge> NTQ: https://github.com/ZeekHuge/BeagleScope#how-to-use-releases
Apr 06 15:58:54 <zeekhuge> NTQ: oh ! Sorry ! I didn't read that "not" there ..
Apr 06 16:59:29 <nextloop> hello! is there any multicore beaglebone around?
Apr 06 17:34:02 <mistawright> hi guys i need some help trying to recover my beaglebone black. when i attempt to boot it this is the output i am given: https://pastebin.com/8B14D3gp
Apr 06 19:27:39 <mikini_> mistawright: uboot is failing to find a primary partition as the first partitin on MMC1 (eMMC=onboard flash). is any there? holding the boot switch (S2) should make it attempt MMC0 (microSD) if you got a sd-card with anything bootable.
Apr 06 22:07:19 <zmatt> nextloop: technically it is multicore :P  one cortex-a8, two pru cores, and a cortex-m3 for power management
Apr 06 22:09:16 <zmatt> thinkfat: yeah cortex-m does require bit 0 set in code addresses, to keep compatibility with cortex-a/r
Apr 06 22:09:26 <zmatt> otherwise you get a UsageFault
Apr 06 22:10:02 <zmatt> ayjay_t: quite often the assembler does know about this though
Apr 06 22:10:19 <zmatt> or there was something to inform it, or something
Apr 06 22:11:37 <zmatt> e.g. in my start.S I have an entrypoint in ARM mode containing:    ldr pc, = _start     where _start is my entrypoint in thumb mode
Apr 06 22:12:11 <zmatt> since this works, the assembler clearly knows that _start is a function symbol in thumb mode, hence needs to have bit 0 set
Apr 06 23:56:43 <hanetzer> sup. attempting to use the beaglebone black screwdriver for coreboot/etc dev. apparently the root param isn't set right or something. what would be the proper way within the bbb ecosystem to set this up?
Apr 07 00:40:50 <ayjay_t> zmatt: is start declared as a function?
Apr 07 00:41:05 <ayjay_t> zmatt with the psuedo-op .function
Apr 07 00:42:56 <zmatt> ayjay_t: I have macros that deal with the annoying boilerplate... see link to include file at top of https://liktaanjeneus.nl/start.S.html
Apr 07 00:49:11 <ayjay_t> yeah i mean, i think it might have to do with the psuedo-op
Apr 07 00:50:10 <ayjay_t> ooh look at all those macros
Apr 07 00:50:14 <ayjay_t> and also, the color scheme wow
Apr 07 00:50:35 <ayjay_t> +1 +1 +1
Apr 07 00:50:49 <zmatt>         .thumb_func
Apr 07 00:50:59 <zmatt> that sounds like it might be the trick
Apr 07 01:06:55 <ayjay_t> i will get to the bottom of this...
Apr 07 02:02:37 <zmatt> ayjay_t: actually I'm quite certain that .thumb_func is what's needed to make the linker treat the symbol as being a thumb function
Apr 07 02:03:10 <zmatt> why it doesn't suffice to simply mark the symbol as being a function, while in .thumb mode, is a mystery to me
Apr 07 02:07:07 <ayjay_t> i have .thumb_func there tho
Apr 07 02:07:14 <ayjay_t> although its after the label so maybe thats why
Apr 07 02:55:22 <zmatt> "This directive specifies that the following symbol is the name of a Thumb encoded function."
Apr 07 02:55:52 <zmatt> "This directive is not neccessary when generating EABI objects." ... hah
Apr 07 02:56:21 <zmatt> that's probably someone's wishful thinking
**** ENDING LOGGING AT Fri Apr 07 03:00:00 2017