ikarso has quit [Quit: Connection closed for inactivity]
buzzmarshall has joined #beagle
Shadyman has joined #beagle
Guest19 has joined #beagle
<Guest19>
hello all, I'm getting a kernel hard crash on bootup when I specify usbcore.nousb in my grub command line. I'm running 5.4.129-bone-rt-r55 on a beaglebone black. I have another machine that is running similar but not identical configuration under 5.4.91-bone-rt-r43. Where should I start investigating?
<Guest19>
(I wasn't clear: the other machine running .91 is not crashing)
buzzmarshall has quit [Quit: Konversation terminated!]
<Guest19>
ok, I've resorted to just blacklisting usb drivers instead. Just not sure which project to even ping for this bug. Would it be linux kernel? anyways.
Guest19 has quit [Quit: Client closed]
<set_>
GenTooMan: Have you ever heard of a Pick & Place file? The co. wants it in .xlsx format but the software is rendering it in .txt format but the .txt format cannot be saved as is...
<set_>
Anyway, I was just wondering how to create such a file w/out knowing the exact coordinates of the components. blah!
<set_>
I have a bunch of gerber files and the processing mfg. wants a .xslx file formatted as coordinates, i.e. X24mm, Y57mm and so on.
<set_>
I got some fancy 300 or less component software to handle the files. Barf. No go. So, I will just keep looking...argh.
<set_>
I mean...I got the .txt file but nothing is labeled so far and nothing is in coordinate based format.
<set_>
This is for the TIDA-00320.
dinuxbg has quit [Ping timeout: 256 seconds]
dinuxbg has joined #beagle
<set_>
Now, I have a Pick and Place file in .txt format but I have no clue as to which components to list under these coordinates. Ha! I am losing slowly!
<set_>
10:00! Dang it.
<GenTooMan>
hmm set_ that's kind of the trouble you get for using existing build files sometimes. perhaps ask in ##electronics?
ikarso has joined #beagle
nerdboy has joined #beagle
Guest40 has joined #beagle
<Guest40>
Hi
Guest4023 has joined #beagle
<Guest4023>
Hi! I just got a new BeagleBone AI and I'm trying to connect to ta PC but I got some issue with a driver from VAYU
<Guest4023>
Any suggestion? I just connect de USB C to PC and it trying to search that driver but nothing happened
Guest40 has quit [Ping timeout: 256 seconds]
vd has quit [Ping timeout: 256 seconds]
Guest4023 has quit [Quit: Client closed]
vd has joined #beagle
rob_w has joined #beagle
Bogdan has joined #beagle
rob_w has quit [Remote host closed the connection]
mpan has joined #beagle
mpan has left #beagle [#beagle]
<Bogdan>
Hi! Can somebody help me with getting started with Beaglebone AI?
alan_o has quit [Ping timeout: 260 seconds]
alan_o has joined #beagle
Bogdan has quit [Quit: Client closed]
florian has joined #beagle
rob_w has joined #beagle
otisolsen70 has joined #beagle
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
rob_w has quit [Quit: Leaving]
Shadyman has quit [Remote host closed the connection]
otisolsen70 has quit [Quit: Leaving]
CrazyEddy has quit [Ping timeout: 260 seconds]
tigerxyz has joined #beagle
<tigerxyz>
Hi, Is there a pre-built BeagleBone image to boot from SD card without EEPROM (blank) for BeagleBone Black Wireless ?
<tigerxyz>
@rcn-ee, just to confirm that buster-console will boot from sd with blank EEPROM? Thank you
<rcn-ee>
tigerxyz, BBBW-blank-debian-10.11-console-armhf-2021-11-01-1gb.img.xz "should" boot and programe the "eeprom" for BBBW... haven't tested in over a year, but that's what it was for..
<rcn-ee>
Plug in J1 and watch u-boot, that's what it should do..
<tigerxyz>
I am currently using debian10.11-console 2021-11-01 image. I have a bare board doesn't boot. So I am confused right now, and nor sure is because of blank EEPROM or something else
<rcn-ee>
tigerxyz, can you get into u-boot prompt?
<tigerxyz>
I can, but I have to wait to do it
<rcn-ee>
our u-boot version has a bunch of "run eeprom_" scripts for checking eeprom/setting etc.. https://paste.debian.net/1218337/
otisolsen70 has joined #beagle
<tigerxyz>
It (u-boot) can be loaded or booted from SD card?
<rcn-ee>
thyes
<rcn-ee>
bbbw: run eeprom_dump; run eeprom_blank; run eeprom_bbb_header; run eeprom_bbbw_footer; run eeprom_dump; reset;
<rcn-ee>
tigerxyz, that inside u-boot would setup the default eeprom for bbbw..
<tigerxyz>
@rcn-ee I will try alter, thank you
tigerxyz has quit [Quit: Client closed]
CrazyEddy has joined #beagle
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 256 seconds]
otisolsen70_ has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
Guest3126 has joined #beagle
set_ has quit [Ping timeout: 268 seconds]
<Guest3126>
Do anyone know if the Beagle Bone AI can be powered by the USB-A port?
<Guest3126>
Does*
<zmatt>
that doesn't even make sense, USB-A is never a power input, it's a power output
<Guest3126>
Ah, the issue I'm having is I'd like to use the USB-C port for something else, but it needs to be used for power, I believe?
<zmatt>
yes, in general the usb-c port cannot really be used in host mode (since it is not a power output nor does it support PD data role swap) although it apparently does work with some charging hubs / docks when combined with a software hack to force the port into host mode
<Guest31>
zmatt I lost connection, apologies, I was the one asking the dumb question about the USB-A port. the issue I'm having is I'd like to use the USB-C port for something else, but it needs to be used for power, I believe?Could the power cape be used to input power to the board?
<zmatt>
16:03 <@zmatt> yes, in general the usb-c port cannot really be used in host mode (since it is not a power output nor does it support PD data role swap) although it apparently does work with some charging hubs / docks when combined with a software hack to force the port into host mode
<Guest31>
Can the power cape output voltage to power the board?
Guest3126 has quit [Ping timeout: 256 seconds]
<Guest31>
thanks for the link!
<zmatt>
I'm not familiar with the power cape but it should be possible to power the BBAI via the P9 expansion header, though I don't see how that would be helpful in your situation
<zmatt>
(since the BBAI cannot have power source role on usb-c you're not going to be able to connect a device to the usb-c port directly anyway, and if you dodge that using one of the charging hubs that are known to work with the BBAI then the power situation is also solved)
buzzmarshall has joined #beagle
<Guest31>
what I was looking to get was basically 2 ethernet ports that would support a higher bandwidth than what the USB-B would support. being that if I used the 1g onboard and a usb-c to ethernet adapter my connections would be faster than running an adapter on the USB-B.
<Guest31>
I would have went POE, but I don't see an official cape for that either.
<zmatt>
the beagleboard-x15 has two gigabit ethernet ports, though no PoE either... though perhaps there are standalone devices to extract power from PoE ? (the x15 has a 12V power input)
<zmatt>
(the bbai and bbx15 use the same AM5729 SoC)
<Guest31>
Thanks, I'll check out that board
<zmatt>
the main disadvantage of the x15, especially for experimenting and rapid prototyping, is that its expansion connectors are more annoying to deal with than those of the bbai
<zmatt>
(but they have better signal integrity characteristics which is why the bbx15 expansion headers include PCIe and SATA which the bbai expansion headers do not)
<Guest31>
thanks for the tips
Guest31 has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
vagrantc has joined #beagle
mattb0ne has joined #beagle
<mattb0ne>
zmatt: switching up the filter settings worked
crazymax has joined #beagle
crazymax has joined #beagle
crazymax has quit [Changing host]
tigerxyz has joined #beagle
tigerxyz has quit [Client Quit]
vd has quit [Quit: Client closed]
vd has joined #beagle
lucascastro has quit [Quit: Leaving]
lucascastro has joined #beagle
lucas_ has joined #beagle
lucascastro has quit [Ping timeout: 260 seconds]
NishanthMenon has quit [Ping timeout: 245 seconds]
NishanthMenon has joined #beagle
ogra has quit [Ping timeout: 260 seconds]
ogra has joined #beagle
ogra has quit [Excess Flood]
ogra has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
lucas__ has joined #beagle
lucas_ has quit [Read error: Connection reset by peer]
xet7 has quit [Ping timeout: 268 seconds]
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
dwkai has joined #beagle
<dwkai>
I am attempting to boot Debian 11.1 on BeagleBoneBlack using the SD Card image (2-part) downloaded from Debian.org. The kernel boot hangs. Prior to the hang I see the following debut output:
<dwkai>
[ 7.765533] sdhci-omap 48060000.mmc: supply vqmmc not found, using dummy regulator
<dwkai>
[ 7.785049] ------------[ cut here ]------------
<vagrantc>
dwkai: i'll try to reproduce the issue locally
<dwkai>
vagrantc: Thank you for the response. I am new to "this game", so I am looking into how to file the bug report. Do you have any suggestions for how I might begin to debug this myself?
<vagrantc>
dwkai: capture the full boot log via serial console, perhaps?
<dwkai>
I have done that.
<vagrantc>
dwkai: i'm somewhat curious if you're running u-boot off the eMMC or the microSD, and if that somehow might be causing issues
lucas__ has quit [Quit: Leaving]
lucascastro has joined #beagle
<vagrantc>
if there's u-boot on the eMMC, it will default to using that unless you press a button on the board
<dwkai>
vagrantc: using u-boot on the sd card
<vagrantc>
dwkai: can you post the boot log?
<vagrantc>
dwkai: should be u-boot version 2021.01+dfsg-5, if i recall correctly
* vagrantc
hasn't booted or tested bbb since ~ 2020 07 or so, apparently
<dwkai>
vagrantc: how do you recommend that I post the log?
<vagrantc>
if it complains about it being too long ... hrm.
dwkai_ has joined #beagle
<dwkai_>
vagrantc: done
dwkai has quit [Ping timeout: 260 seconds]
<vagrantc>
dwkai_: looks like it tried to boot one boot.scr and failed, and then proceeded to another one ...
jkridner[m] has quit [Ping timeout: 246 seconds]
mvaittin has quit [Ping timeout: 264 seconds]
<vagrantc>
that's a bit odd ... and it loads at two different addresses (maybe not an issue)
<dwkai_>
still listening...
<vagrantc>
have you ever run saveenv from u-boot on this board?
<vagrantc>
nevermind, it says it's using the default environmnet
<vagrantc>
dwkai_: what it looks like is it is loading the installer boot script, and then falling back to some other boot script
<vagrantc>
dwkai_: so to debug, i would try to figure out the discrepancies between the two different boot scripts, and where they are coming from
<vagrantc>
dwkai_: you could also stop auto-boot and try to determine which boot device is actually loading ... it's odd on the first it says Running bootscript from mmc0 ... which fails ... and then Scanning mmc 0:1...
<vagrantc>
might be some discrepancy between legacy boot methods and distro_bootcmd
<vagrantc>
dwkai_: you can interrupt the boot process and start inspecting boot variables, too
russ has quit [Ping timeout: 260 seconds]
<vagrantc>
dwkai_: printenv bootcmd ... and then printenv on the next variables and so on
<dwkai_>
Are there other sources of support, or contacts, that you would recommend?
mvaittin has joined #beagle
<vagrantc>
irc.oftc.net #debian-arm and #debian-installer
<vagrantc>
dwkai_: fwiw, i reproduced your issue
<dwkai_>
vagrantc: good news! I appreciate your effort.
jkridner[m] has joined #beagle
<vagrantc>
dwkai_: oh, sorry, the channel would be #debian-boot (not #debian-installer)
<vagrantc>
the legacy of "bootfloppies" lives on
<vagrantc>
dwkai_: though honestly, most of the folks there will point you to me :)
<vagrantc>
though might catch something i don't
* vagrantc
tries the latest debian-installer images...
<vagrantc>
seemed to boot find with an pre-release image ... hrm.
russ has joined #beagle
<dwkai_>
hrm?
<vagrantc>
i did a network boot with an older kernel, that seemed to boot fine
<vagrantc>
should also test the 10.0 boot images...
<vagrantc>
er, 11.0 images
<dwkai_>
vagrantc: what are some good resources for me to learn how to debug this issue?
<vagrantc>
dwkai_: and .... it works with the 11.0 image
<vagrantc>
dwkai_: so you found a regression!
<vagrantc>
dwkai_: admittedly, i just dove into this sort of thing years ago and not sure i have the best resources to recommend
<vagrantc>
dwkai_: i did give a talk at debconf19, but it doesn't go into a lot of detail...
<dwkai_>
vagrantc: I would love to learn how to be helpful to the community.
<vagrantc>
an earlier version boots, but fails to detect a network card in debian-installer ... and the daily image running linux 5.14.x boots but fails to detect a network card in debian-installer
<rcn-ee>
vagrantc, i don't like the new ethernet changes...
<zmatt>
I'll admit I've never tried a regular debian install
<zmatt>
what new ethernet changes?
<rcn-ee>
they rewrote the cpsw layer...
<vagrantc>
rcn-ee: if they break completely, i'm not much of a fan either :)
<rcn-ee>
someone forgot to test the am335x...
<vagrantc>
it *could* be modules got renamed, though?
<zmatt>
I mean, if they genuinely broke it then someone needs to get yelled at on the kernel mailing list
<rcn-ee>
looking at git log, v5.14.x should be safe... okay what else came across to break things..
<vagrantc>
i should test without debian-installer, as that ... does some annoying things splitting up the kernel package into dozens of kernel module packages ... and is thus very prone to breaking
set_ has joined #beagle
<rcn-ee>
vagrantc, do you have a dmesg/boot log for debian's v5.10.x
<rcn-ee>
v5.10.67 was the first verison that broke, v5.10.75 has the fix..
<vagrantc>
ok, so the next point release will most likely include a newer version ... assuming that it doesn't get pushed with a security update
<dwkai_>
I have attempted to install the previous Debian release (20210731). The kernel loads up and runs the installation program. The program cannot find the ISO image file. Where should this file be?
<vagrantc>
dwkai_: maybe on USB
<vagrantc>
dwkai_: any available alternate media, basically
<vagrantc>
dwkai_: although i prefer to use the netboot option ... usuaully ... when the ethernet is working :)
<vagrantc>
which it does not appear to be ...
<vagrantc>
hrm, did not plan to be troubleshooting *this* today :/
lucas_ has joined #beagle
lucascastro has quit [Remote host closed the connection]
<dwkai_>
when using the hd-media/SD-card-images approach to installation, where does one obtain the corresponding installation cd image?
<dwkai_>
vagrantc: is there a document that explains how to use these various components on a "not pc" system?
<vagrantc>
dwkai_: more than there are stars in the sky
<dwkai_>
also, is there anything else I can do to help "the team" troubleshoot this issue?
<vagrantc>
it's a complicated mess of interacting parts and the answer mostly comes down to "it depends"
<zmatt>
it would be cool to just have a tool that performs a debian installation directly onto the eMMC of a usb-connected beaglebone (like the old BBBlfs or newer replacements, but not merely flashing an image but performing a proper fresh install with debian installer) ... it should be totally doable with a bit of effort
<vagrantc>
zmatt: yeah, that should be pretty doable
<vagrantc>
oh, except the debian-installer part
<vagrantc>
but using mmdebstrap or debootstrap or whatever, not too difficult
<zmatt>
doesn't debian-installer support making an image for another system?
<zmatt>
or that I guess
* vagrantc
needs to find time to write up live images and corresponding installer...
<vagrantc>
it's been on my TODO list... since i started messing around with beagleboneblack in ... 2013?
<zmatt>
I guess another method for usb-install would be to usb-netboot the debian installer on the beaglebone
<zmatt>
if you can get it to use usb gadget as console
<zmatt>
or ssh
<vagrantc>
i don't htink the necessary gadget modules for ethernet are in debian-installer ...
<vagrantc>
are they in u-boot?
<zmatt>
yeah ssh would be easier, that avoids the need for making a composite network/serial gadget
<zmatt>
ethernet gadget just requires the g_ether kernel module and dependencies
<vagrantc>
i vaguely recall asking to enable that and getting NACKed
<vagrantc>
but now i could just push it, maybe :)
<vagrantc>
for boards like the pocketbeagle where they have no ethernet, that would be needed
<zmatt>
I mean, you'd need a slightly customized debian installer for this anyway since you want it to not just automatically load g_ether but also automatically start sshd
<zmatt>
dunno, the debootstrap method definitely sounds easier to build, perhaps not easier to use
<zmatt>
if you're not going to run an interactive installer then the benefit compared to just flashing a prepared image seems limited
<vagrantc>
zmatt: the network console is a boot option for debian-installer
<zmatt>
how does that work exactly?
<zmatt>
oh you mean via ssh?
<zmatt>
ok
<vagrantc>
i forget off the top of my head, might need a specific image variant that has sshd and whatnot
<zmatt>
currently our method of flashing beaglebones is to just boot them from an sd card that contains a custom install tool (which takes the hostname of the new system as argument, flashes a master image to eMMC, and then performs relevant personalization (set hostname, randomize filesystem uuid and machine-id, generate ssh keys)
<zmatt>
)
<vagrantc>
ugh, debian-installer on buster (10.0) also fails to boot ...
<zmatt>
which is a solution that isn't great but works well enough that I never really seem to get around to improving it
<vagrantc>
yeah, not a bad approach
<vagrantc>
only thing i'd do differently is make it a live image that doesn't save state between uses
<zmatt>
the image being flashed is unrelated to the system being booted on sd card
<zmatt>
it's just an .img file on the sd card
<vagrantc>
but it's a writeable filesystem?
<zmatt>
which?
<vagrantc>
saves /var/log/* and whatnot?
<vagrantc>
the one you boot into in order to run the flashing tool
<zmatt>
yes it's a writable system, it stores backups of certain information of the beaglebones that have been flashed. /var/log/ is writable though there's not really anything that logs there... lastlog and btmp/wtmp I guess
<zmatt>
having the last invocation of the flasher tool in your shell history is also convenient when you're flashing a whole bunch of sequentially numbered devices
<zmatt>
I see no benefit in making it a read-only live image, only downsides