<zmatt>
ah nice, ethernet is getting an actual reset line?
<zmatt>
vd: rejoice! :D even though it's too late for you
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #beagle
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #beagle
GenTooMan has quit [Ping timeout: 250 seconds]
Guest46 has quit [Quit: Client closed]
<kveremitz>
oooooh
Guest94 has joined #beagle
Guest94 has quit [Client Quit]
GenTooMan has joined #beagle
lucas_ has quit [Quit: Leaving]
lucascastro has joined #beagle
ikarso has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
troth has quit [Ping timeout: 250 seconds]
troth has joined #beagle
rob_w has joined #beagle
LetoThe2nd has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
ikarso has joined #beagle
florian has joined #beagle
vd has quit [Quit: Client closed]
Shadyman has quit [Remote host closed the connection]
<Daulity>
any experience with low level debugging through uart? i enabled early printk and debug_ll but i don't see anything on the console yet
<Daulity>
my console is on uart0
<Daulity>
i see options for kernel low-level debugging port
<Daulity>
but i don't see uart0 in there
<Daulity>
oh one of the options is via 8250 uart and the help says that it's preffered and other options will soon be removed
<Daulity>
i did supply the physical address for uart0 in the config
<Daulity>
i read i have to supply the earlyprintk parameter to the kernel but with it it does nothing
<Daulity>
reason i want early printk is that my kernel doesn't seem to boot (no output) but i do see it set the heartbeat led after a bit of time.
jkridner has quit []
jkridner has joined #beagle
moto-timo has quit []
moto-timo has joined #beagle
<Daulity>
I think I have been doing it wrong
rob_w has quit [Quit: Leaving]
<zmatt>
Daulity: I don't think earlyprintk works, but normal console output tends to work super early
<zmatt>
just make sure the correct "console" kernel parameter is passed and obviously don't pass "quiet" if you want to see console output
<zmatt>
beware that the oldschool console=/dev/ttyO0 only works when the kernel has CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y (or when the deprecated CONFIG_SERIAL_OMAP is used instead of CONFIG_SERIAL_8250_OMAP), while console=/dev/ttyS0 will work with and without CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP (but not with CONFIG_SERIAL_OMAP)
markand has joined #beagle
<markand>
hey there, I have a beaglebone black that I try to boot from SD card by pressing the button while powering on. nothing happens on the serial console nor the led indicators
GenTooMan has quit [Ping timeout: 250 seconds]
<zmatt>
then the sd card is probably not bootable
<markand>
it has a bootable flag on partition 1 though
<zmatt>
that's actually not relevant for bootability
<markand>
ah
GenTooMan has joined #beagle
<markand>
I hate an already .img file but was bigger than my actual SD card so I've partitioned it (1 fat part + 1 ext4 part) and then using losetup I've just rsync the .img files from their respective partitions to the SD card (much quicker than copying the whole img btw)
<markand>
s/hate/have
<zmatt>
that won't result in a bootable system
<zmatt>
also, only really really ancient images used a separate boot partition
<markand>
ah
<zmatt>
though actually, I guess your procedure *should* work for such ancient images
<zmatt>
I don't know what the exact conditions on the fat boot partition is in that case since I haven't used those since... forever basically
<markand>
https://paste.centos.org/view/637a6fd9 (in /mnt/1 there is the content of the .img 1st partition (FAT), and in /mnt/2 the 2nd partition (ext4))
<zmatt>
I'm honestly not sure what I'm looking at, other than that it is indeed ancient given that it evidently uses a 3.8 kernel
<markand>
I think it is
<markand>
initrd_file=initrd.img-3.8.13-bone84
GenTooMan has quit [Ping timeout: 250 seconds]
<markand>
heheh
<zmatt>
but yeah dunno, when using a FAT boot partition this looks like it should be bootable, when the bootable flag is set on the FAT partition
GenTooMan has joined #beagle
<zmatt>
you say nothing happens on the serial console? not even CCCC output?
<markand>
absolutely nothing
<zmatt>
baudrate 115200 ?
<markand>
yes, it works fine if I power it on without SD card
<zmatt>
you do get CCC if you power on without SD card but with the S2 button held down?
<zmatt>
oh I guess CCC output might be suppressed if the device is connected to a computer via usb... I'd need to check the boot order
<markand>
seems not
<zmatt>
boot order with S2 button held down at power-up is... spi, μSD, usb-rndis, uart-xmodem ... ok yeah then you won't see CCC, it'll show up as network interface instead
<zmatt>
does this happen with your non-booting card?
<zmatt>
(that distinguishes between bootrom not being able to load the MLO versus the MLO crashing early)
<zmatt>
a better solution would be to shrink the ext4 partition of the image before flashing, or at least copy the initial part of the image (containing the partition table and FAT partition) and then delete and recreate the ext4 partition
<zmatt>
that way you can be sure that whatever the deal is with the boot partition, it'll be preserved
<zmatt>
also beware that copying a root filesystem with rsync may require -aHAX to be fully functioning properly, merely using -a may be insufficient
<markand>
yes I think I've used aHAXv
<markand>
16:17 <@zmatt> does this happen with your non-booting card?
<markand>
what do you mean there?
<zmatt>
does it show up as usb device?
<zmatt>
usb network interface
<zmatt>
when attempting to boot it
<markand>
yes on my windows I think
<zmatt>
ok yeah then bootrom has not recognized the sd card as being bootable for whatever reason
<zmatt>
my suggestion would be ... well, what I just suggested
* markand
always wondered why SBCs (no matter which brand) do not have easy option to expose on-board eMMC through USB easily so we can just dd/fdisk/mount/mkfs them
<markand>
I mean, what I'd love to see : plug USB cable pressing a button (or put a jumper) and boom, the attached device appears like a mass storage device
vd has joined #beagle
<zmatt>
would be nice yeah
<zmatt>
though I'm also a fan of not making a bootrom (where bugs cannot be easily fixed) unnecessarily bloated
<zmatt>
it is however possible to boot a tiny linux system that does exactly that
<zmatt>
and u-boot has that capability too (if enabled), although last time I checked it was quite a bit slower
<vd>
zmatt Rev C3 would be a new model from the bbb?
<rcn-ee>
vd, updated PCB, for a few EOL and fixes..
florian has quit [Quit: Ex-Chat]
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #beagle
bzyx has quit [Ping timeout: 245 seconds]
vagrantc has joined #beagle
bzyx has joined #beagle
argonautx has joined #beagle
LetoThe2nd has quit [Quit: Connection closed for inactivity]
Guest8 has joined #beagle
Guest8 has quit [Client Quit]
vagrantc has quit [Quit: leaving]
ikarso has quit [Quit: Connection closed for inactivity]
the_person48 has joined #beagle
<the_person48>
hello, I am running ubuntu 18.04 on a beaglebone black rev C
<the_person48>
I was here yesterday as Guest46, but I'll use this nickname from now on
<the_person48>
I am trying to figure out reading from/writing to the gpio pins
<the_person48>
zmatt gave me this udev rule to name the gpio pins:
<the_person48>
I put it as /etc/udev/rules.d/gpio-symlinks.rules
<the_person48>
overall, it's working very well!
<the_person48>
but I had one question: I see two pins show up that I don't recognize and I'm wondering where they're coming from:
<the_person48>
P9_91 and P9_92, which say they correspond to /sys/class/gpio/gpio114&116
<the_person48>
but as far as I can tell, these pins don't exist, and the other symlinks already account for all the gpio pins
<the_person48>
any idea where these are coming from?
<zmatt>
yeah that's caps-universal's weird naming for the second processor pin that goes to P9_41 and P9_42 respectively
<zmatt>
both of these expansion header pins connect to two processor pins each
<the_person48>
huh, so they're for header expansion? or some other purpose?
<zmatt>
you can also see that in my pins spreadsheet, where those pins occupy two rows: https://goo.gl/Jkcg0w#gid=1775283126
<the_person48>
huh
<the_person48>
I guess I still don't understand how those pins have two functions each?
<zmatt>
it's just literally wired to two processor pins
<zmatt>
to extend the functionality available on those pins
<zmatt>
there's almost never any reason to use the P9_91/92 gpios though since they obviously provide the same functionality as the P9_41/42 gpios
<the_person48>
ok, gotcha
<the_person48>
so it sounds like I can just ignore them unless we find some special use for them
<zmatt>
there's basically only one reason to use them: if you use P9_41 (resp P9_42) in a non-gpio mode then you can at the same time use the P9_91 (resp P9_92) gpio in input mode to monitor what's happening on that pin
<the_person48>
ah ok
<the_person48>
that makes sense
<the_person48>
alright, thanks!
the_person48 has quit [Quit: Client closed]
the_person48 has joined #beagle
<zmatt>
(I don't really understand why gpios can't simply monitor a pin even if configured to non-gpio mode... that's how it worked on the older DM814x SoC)
<the_person48>
yeah that is strange
<mranostaj>
rcn-ee: just checking if you got my addition note on the icm-20948 changes :)
the_person48 has quit [Client Quit]
<rcn-ee>
@mranostaj, yeap i saw it, it looks good... just retesting things on local hardware... i try not to break the older kernels too much. ;)
argonautx has quit [Quit: Leaving]
<mranostaj>
rcn-ee: i did test on the old mpu9050 but good idea to confirm it doesn't break anything.. it is a bit of a hack in the current form :)
<rcn-ee>
the Red board was the only one that really used that driver.. the whole "librobotic" stack, wrote their own implementation thus ignoring the kernel driver.. so your safe. ;)
<rcn-ee>
(BeagleBone Blue)
johanhenselmans has quit [Ping timeout: 250 seconds]
<mranostaj>
rcn-ee: yeah i've seen the librobotic stack, and i'll bite my tongue on that 'userspace driver' :)
johanhenselmans has joined #beagle
<rcn-ee>
To be fair... he was working on a PHD... in robotics.... he just needed the data...
<mranostaj>
but the iio driver already existed for that part iirc.. anyway not my problem ;)
<rcn-ee>
oh, yes, Jason and i spent a lot of time explaining that..
<mranostaj>
rcn-ee: does the bootloader get autoreved when changes are commited to bb.org u-boot repo?
<rcn-ee>
extlinux works perfectly fine today, as long as you are using a prebuilt *.dtb..
the_person48 has joined #beagle
<the_person48>
Hello, I have a beaglebone black, and I have heard (here and other places) that booting from the SD card is less reliable than booting from the onboard eMMC. I was just wondering if anyone has a sense of about how frequent failures due to SD card booting are?
<zmatt>
that'll depend heavily on write activity, as well as the SD card
<the_person48>
would like to use the eMMC pins, and apparently they're not accessible unless you boot from SD card. I can potentially work around this, but I'm trying to get a good sense of the level of disadvantage of using the SD card
<the_person48>
ok, that makes sense
<the_person48>
do you have a ballpark sense of reliability with an a typical consumer SD card, and average write frequency? We can control which card we get, but I'm not sure what level of write activity there will be
<zmatt>
the SD card interface also has only half the bandwidth compared to the eMMC
<the_person48>
what do you mean by bandwidth?
<zmatt>
as in, maximum bits/second
<the_person48>
ah ok
<the_person48>
I don't think that'll be an issue for us
<the_person48>
but good to know
<zmatt>
eMMC read performance maxes out around 41 MB/s, SD card around 22 MB/s
<zmatt>
well it'll mean everything is slower... boot time, time to load applications, etc
set_ has quit [Ping timeout: 240 seconds]
<the_person48>
that makes sense
<the_person48>
if we were using the most reliable consumer SD card, and constantly maxing the read/write performance (22 MB/s, alternating between reading and writing), what would you estimate the relative reliability of SD card vs eMMC booting?
<zmatt>
I wish I had concrete data on stuff like that, but I don't
<the_person48>
ok, for sure
<the_person48>
ballpark, is it a big problem, or a small problem?
<zmatt>
reading is mostly irrelevant, writing you're probably not going to be able to max out the bus speed anyway, it'll be limited by the eMMC/SD card... either way if you write continuously at max performance I wouldn't be optimistic about either. it's also an extremely unlikely use-case since you'd run out of disk space within minutes unless you're continuously overwriting the data you wrote a few ...
<zmatt>
...minutes ago.. in which case, why did you write it in the first place?
<the_person48>
gotcha
<zmatt>
also, if you do choose to reuse the eMMC pins, I strongly suggest leaving eMMC clk (P8.21) or eMMC cmd (P8.20) unused to ensure the eMMC doesn't think you're trying to send commands to it
<zmatt>
also, by default bootrom will try to boot from eMMC... you can just wipe eMMC to make it fall back to booting from SD card, but it still means the eMMC pins will see activity during boot which would make it a hazard to drive these pins externally
<zmatt>
you could prevent this by overriding the sysboot0-4 pins (P8.41, P8.43-46) with external pull-up/down resistors (1-10 kΩ) to configure a boot device list that places the SD card at the front
<zmatt>
e.g. pulling sysboot3 (P8.44) down and pulling the other four up will configure the boot device list { μSD, spi0-flash, uart0-xmodem, usb-rndis }
<zmatt>
the only thing to keep in mind with that is that if bootrom can't boot from μSD card for whatever reason (e.g. none is inserted) then it'll fall back to trying spi flash, which involves driving pins P9.17-18 and P9.22
<zmatt>
so that scenario then needs to be considered in the hardware design
<zmatt>
but at least that's only 3 pins rather than the 10 pins of eMMC
Guest40269 has joined #beagle
<the_person48>
ok that's good to know
<the_person48>
so if we avoid driving all of those on boot then it sounds like it should be fine
<zmatt>
*any of those
<zmatt>
and don't mind the activity on the relevant pins, obviously
<the_person48>
noted, thanks. also, random other question: do you know where I can find the input impedance for the analog input pins?
<the_person48>
I'm not seeing it in the BBB reference manual
<zmatt>
though I noticed an oddity: they specify an input capacitance of 5.5 pF, yet they also specify impedance using the formula 1/(65.97e-12 * f) which matches a capacitance of 10.5 pF
<the_person48>
oh I'm looking at the wrong thing
<zmatt>
technical reference manual and datasheet are not the same thing
<zmatt>
electrical parameters are found in the latter
<zmatt>
basically, the datasheet is for hardware design, the TRM is for software development (especially people writing drivers)
<the_person48>
gotcha
<the_person48>
ok I think I got it
<the_person48>
thanks
Guest40269 has quit [Quit: Client closed]
Guest40269 has joined #beagle
Guest40269 has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
vd has joined #beagle
the_person48 has quit [Quit: Client closed]
ikarso has joined #beagle
Shadyman has joined #beagle
russ has quit [Ping timeout: 240 seconds]
ikarso has quit [Quit: Connection closed for inactivity]