ikarso has quit [Quit: Connection closed for inactivity]
starblue1 has joined #beagle
starblue has quit [Ping timeout: 258 seconds]
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 258 seconds]
vagrantc has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
set_ has quit [Quit: I thought I saw a puddy-cat...]
mikkel has joined #beagle
xet7 has quit [*.net *.split]
xet7 has joined #beagle
set_ has joined #beagle
m-atoms has quit [Ping timeout: 250 seconds]
MrAureliusR has joined #beagle
<MrAureliusR>
hey everyone! I just pulled my BBB out of a drawer, and the last time I had it out I was looking into using the PRUs, but I remember running into a bit of a wall because there wasn't that much info on them that I could easily find.
<MrAureliusR>
I'll take a look through the beaglebone website and see if there's any info there. I hope there's some sort of easy way to program them directly in C from the BBB
<zmatt>
there is yes, though using C negates some of the advantages of using pru in the first place
<MrAureliusR>
why is that?
<MrAureliusR>
shouldn't C be the best choice?
<zmatt>
one of the advantages of PRU is its deterministic instruction timing, which can be taken advantage of for things like signal timing
<MrAureliusR>
right. so it's C or assembly, then?
<zmatt>
originally it was assembly-only, but there's been a C compiler for some time (though the quality of the code output is pretty meh, in part because the PRU instruction set was designed for hand-written assembly and not designed to be targeted by a C compiler)
<zmatt>
for code loading, the old libprussdrv only supports raw binaries as produced by pasm (the original pru assembler), the new remoteproc-pru framework only supports ELF executables as produced by clpru, my py-uio library ( https://github.com/mvduin/py-uio ) supports both
<MrAureliusR>
oh cool!
<MrAureliusR>
will check it out
<zmatt>
though py-uio does not support rpmsg yet (mainly because I think it's a dumb bloated mechanism that destroys performance)
<zmatt>
(and I haven't had any motivation to implement it)
set_ has quit [Ping timeout: 244 seconds]
rob_w has joined #beagle
LetoThe2nd has joined #beagle
johanhenselmans has quit [Ping timeout: 244 seconds]
johanhenselmans has joined #beagle
vagrantc has quit [Quit: leaving]
starblue1 has quit [Ping timeout: 250 seconds]
shoragan[m] has quit [Write error: Connection reset by peer]
jkridner[m] has quit [Read error: Connection reset by peer]
mvaittin has quit [Read error: Connection reset by peer]
shoragan[m] has joined #beagle
mvaittin has joined #beagle
jkridner[m] has joined #beagle
calculus has joined #beagle
calculus has quit [Client Quit]
calculus has joined #beagle
Shadyman has quit [Quit: Leaving.]
calculus has quit [Ping timeout: 272 seconds]
calculu5 has joined #beagle
starblue1 has joined #beagle
starblue1 has quit [Ping timeout: 245 seconds]
set_ has joined #beagle
aswin has joined #beagle
<aswin>
My busybox linux fails while booting. It stops Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist.
<aswin>
Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist.
<aswin>
Looks like init process is failing. But I dont have any clue what may be going wrong!
<zmatt>
that's just a message, not a failure
<zmatt>
I assume anyway
<zmatt>
but if you don't intend to use tomoyo then you should just disable it
<zmatt>
if this is the entire log (no further messages after this) then my guess would be init is either hanging or its output is not going to the serial console
<aswin>
I think after init process the output is not getting printed
<zmatt>
you're using earlyprintk ? is this output from earlyprintk or from the normal serial console?
<zmatt>
can you share the full log?
<aswin>
Sure
<zmatt>
maybe it's switching from earlyprintk to normal serial console (though this would be a bizarrely late time to do so) and losing console output at that point
<aswin>
zmatt: Success! Removing earlyprintk solved the issue
<zmatt>
it also seems your serial console is being activated quite late... maybe double-check whether the relevant drivers are configured as built-in and not as module
<zmatt>
I'd normally expect that within the first second
<aswin>
zmatt: Btw was there any earlyprintk option in the 4.x kernels?
<zmatt>
I don't think "earlyprintk" has ever been a thing on ARM... there's "earlycon" but that needs special configuration
<zmatt>
given how late your serial console comes up I can understand why you were trying to get early-console. but I'd be more interested in why the normal serial driver is getting probed so late
<zmatt>
this is on our production beaglebones:
<zmatt>
[ 0.336174] console [ttyS0] enabled
<zmatt>
hmm, it seems that almost two seconds passes around [ 1.036522] random: fast init done
<zmatt>
try adding rng_core.default_quality=100 to your kernel parameters, see if that speeds up boot
<zmatt>
(this should enable the kernel to actually *use* the hwrng on the am335x)
<aswin>
Sure lemme try that
<zmatt>
hmm, that won't help I guess since the hwrng driver loads after that
<zmatt>
by default yes (for some reason), though it works equally fine without it (and boots faster)
<zmatt>
I don't use initramfs
<aswin>
zmatt: Do you have documentation for building busybox rootfs ?
<zmatt>
note that the cmdline variable above is the *additional* kernel parameters u-boot appends to whatever parameters it passes by default (e.g.: console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait)
<aswin>
netboot=echo Booting from microSD ...; setenv autoload no ; load mmc 0:1 ${loadaddr} uImage ; load mmc 0:1 ${fdtaddr} am335x-boneblack.dtb ; run netargs ; bootm ${loadaddr} - ${fdtaddr}
<aswin>
uenvcmd=run netboot
<aswin>
This is my uEnv.txt
<zmatt>
please don't paste multi-line stuff into chat, use pastebin or other paste site
<zmatt>
okay so you're completely overriding the built-in boot script
<zmatt>
and you're directly setting the kernel parameters (bootargs)
<aswin>
Yes
mothblur_ has joined #beagle
<zmatt>
passing mem= is a bit weird btw, the ram size is part of the device tree
djinni_ has joined #beagle
esteban_ has joined #beagle
rob_w has quit [Quit: Leaving]
<zmatt>
normally the 'root' and 'console' kernel parameters are provided by u-boot since it knows what serial port is used as console (which depends on board detection) and what the rootfs is (from which it loads /boot/uEnv.txt, the kernel, initramfs if used)
<zmatt>
(and the dtb)
<zmatt>
my only experience with busybox on a beaglebone was a tiny initramfs image for usb flashing, which did not use busybox init
<zmatt>
and I don't really remember anything about it, it was a long time ago
set_ has quit [*.net *.split]
signal11 has quit [*.net *.split]
djinni has quit [*.net *.split]
vagrantc has joined #beagle
zjason` is now known as zjason
javaJake has joined #beagle
calculus has joined #beagle
starblue2 has joined #beagle
aswin_ has joined #beagle
starblue1 has quit [*.net *.split]
aswin has quit [*.net *.split]
calculu5 has quit [*.net *.split]
johanhenselmans has quit [*.net *.split]
ds2 has quit [*.net *.split]
ds2 has joined #beagle
charlie5 has joined #beagle
aswin_ is now known as aswin
<aswin>
zmatt: Found the solution
<aswin>
zmatt: Earlier I thought it booted properly after removing the earlyprintk from uEnv.txt
<aswin>
zmatt: But it didn't. After couple of hours of debugging I got the issue. It was in inittab
<aswin>
Busybox wasn't getting access to the serial console for some reason
<zmatt>
that's why I suggested testing with init=/bin/sh
<aswin>
zmatt: I added console::respawn:/bin/ash to inittab
<zmatt>
if no inittab is found it should spawn a shell on /dev/console
<aswin>
zmatt: One other thing I noticed here is the permissions. under /dev I can't see my ttyS0
<aswin>
after gaining access to the console I tried cd to /dev
<aswin>
but it's throwing permission denied
<zmatt>
does it exist?
<aswin>
the /dev?
<zmatt>
yes
<aswin>
yes I created one when I made the rootfs
<aswin>
and created console, null and zero
<aswin>
using mknod
<zmatt>
ew
<zmatt>
why not use devtmpfs ?
<aswin>
zmatt: I need to learn about devtmpfs. I am just experimenting and learning
<zmatt>
set CONFIG_DEVTMPFS_MOUNT=y or use kernel parameter devtmpfs.mount=1
<zmatt>
and leave /dev empty
<zmatt>
the kernel will automatically mount devtmpfs at /dev after mounting the root filesystem, before spawning init
<aswin>
CONFIG_DEVTMPFS_MOUNT=y in the kernel compile time?
<zmatt>
yes, or like I said you can override that with the devtmpfs.mount kernel parameter
<zmatt>
but CONFIG_DEVTMPFS_MOUNT=y is pretty standard
<aswin>
devtmpfs.mount pass it when it loads the kernel?
<aswin>
using uEnv.txt?
<zmatt>
was your kernel built with CONFIG_DEVTMPFS_MOUNT=n ?
<aswin>
lemme check
<zmatt>
if it was =y (which is what I'd expect) then there's no need for the kernel parameter override
<aswin>
zmatt: CONFIG_DEVTMPFS=y
<zmatt>
if you compare what you just said with what I asked, you'll find that doesn't answer the question
<aswin>
zmatt: Sorry CONFIG_DEVTMPFS_MOUNT is not set
<zmatt>
ok, then you can use devtmpfs.mount=1 in your kernel parameters to override that config variable, and if you're happy with devtmpfs put recompiling the kernel with CONFIG_DEVTMPFS_MOUNT=y on your to-do list
m-atoms has joined #beagle
m-atoms has quit [Quit: Client closed]
m-atoms has joined #beagle
m-atoms has quit [Client Quit]
m-atoms has joined #beagle
Guest23 has joined #beagle
Guest23 has quit [Client Quit]
otisolsen70 has joined #beagle
<otisolsen70>
The URL http://bbb.io/start mentioned in the topic results in a blank page saying just: "Last updated by jkridner.wordpress.com on Wed Apr 26 2017 15:25:13 GMT-0000 (UTC)"
<otisolsen70>
Is that supposed to happen? Or should it contain more info?
<aswin>
zmatt: I added devtmpfs.mount=1 as boot param and changed rewrote the initab to boot to ttyS0
<aswin>
zmatt: And It worked!!! Thank you for helping zmatt. Lots of learning today!
<zmatt>
otisolsen70: hmm, I'm not getting a blank page
<zmatt>
the first two HTTP redirects (301 and 303 respectively), the last one using javascript
<zmatt>
that last redirect is no doubt the problem
<zmatt>
otisolsen70: I think it's because it logs the redirect to google analytics, and you probably have something that's causing that to hang
<zmatt>
I'm personally not a fan of delay website navigation on google analytics... at the very least it ought to have a very very short timeout
<zmatt>
*delaying
otisolsen70 has quit [Quit: Leaving]
buzzmarshall has joined #beagle
behanw has joined #beagle
Guest64 has joined #beagle
<Guest64>
hello guy, i want to install a lower version for tesseract on my bb. Now i use 4.0.2, but is bit slow and i want to use a older version eg 3.0.4
<Guest64>
how can i do this?
<zmatt>
build from source code I guess
<Guest64>
ok. and how i do that? i am not familiar with linux
<zmatt>
but, from what I'm reading tesseract 4 still includes engine that was used in tesseract 3
<zmatt>
"Tesseract 4.0 should be a full replacement for Tesseract 3.05 and have the same features when used with the old OCR engine (--oem 0)."
<zmatt>
setting the thread limit to 1 like suggested in that thread also sounds like a good idea
<zmatt>
upgrading to a _newer_ version should also help, since they added ARM NEON support
<zmatt>
(quite recently, last november)
<zmatt>
that only applies to the new LSTM engine though
<zmatt>
hmm, and it's only part of tesseract 5 which is in alpha
<zmatt>
though based on the commit message it sounds like it results in a large performance improvement
aswin has left #beagle [#beagle]
v0n has joined #beagle
<v0n>
hi all -- bbb supports GPT, right?
<Guest64>
i tried to add "-oem 0" -> pytesseract.image_to_string(img, lang = "eng", config = "--oem") and i have error : (1, "failed loading languege 'eng' tesseract could't load anu langueges
<zmatt>
"--oem 0", not "--oem" nor "-oem 0"
<Guest64>
--oem 0* i used, sorry
<zmatt>
then dunno, I don't know anything about tesseract beyond what I read about it the last 20 minutes
<Guest64>
oh, thank that you do it for me
<zmatt>
v0n: I don't immediately see an objection to it... as long as u-boot supports it
<zmatt>
v0n: and the fact that the u-boot SPL (in MLO format) and u-boot.img are by default located at fixed offests (256 and 768 sectors from start respectively)
<zmatt>
*and as long as GPT is okay with the fact that...
<zmatt>
but I don't see a problem there, GPT uses the first 34 and last 33 sectors
<zmatt>
v0n: so assuming u-boot has been built with GPT support I see no reason why it wouldn't work... worst case you'd need to recompile u-boot to get it working
<v0n>
zmatt: I'm using barebox, I'll ask them
<zmatt>
the only thing to be mindful of in that case is that putting the MLO in a FAT boot partition (which bootrom supports as fallback if it can't find a configuration header at fixed offsets 0, 256, 512, or 768) won't work, since bootrom doesn't support GPT
<zmatt>
so you have to put the MLO with prepended configuration header at offset 256/512/768 (in sectors)
<zmatt>
from that point on it's all up to barebox and no longer hardware-dependent in any way
mothblur_ has quit [Ping timeout: 252 seconds]
<Guest64>
zmatt i found this for tesseract 5
<Guest64>
Add this line for Stretch(i386, amd64, arm64, armhf):