jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
Guest9 has joined #beagle
Guest9 has quit [Client Quit]
ft has quit [Quit: leaving]
PhotoJim has quit [Ping timeout: 248 seconds]
PhotoJim has joined #beagle
Guest10 has joined #beagle
Guest10 has quit [Client Quit]
Guest9 has joined #beagle
<Guest9>
hello?
AKN has quit [Read error: Connection reset by peer]
<zmatt>
hi?
<Guest9>
I am using a BBB and have been having issues downloading the windows drivers. I've tried to disable driver signage via startup settings but bootloader requires my computer recovery key which I do not currently have access to. I've tried downloading and running more recent signed drivers via
<zmatt>
I'm not sure what drivers you've been trying to install
<zmatt>
or rather, all usb device drivers used for the BBB are built-in drivers from Microsoft
<zmatt>
I'm not 100% sure but I think the thing you linked to might be the FTDI drivers that were used for the original BeagleBone (aka the BeagleBone White)
<Guest9>
I have an old BBB I got when my robotics club was getting rid of old equipment. The date modified for those files is 2013
<Guest9>
Would an old BeagleBone Black still not require drivers?
<zmatt>
no, the age of the BBB is irrelevant. the beaglebone White was different hardware with an integrated FTDI usb-serial converter... so even for that you didn't really need it unless you wanted to access the serial console (which is typically only used for debugging boot issues or networking issues that make it impossible to log in normally)
<zmatt>
maybe I'm wrong though, I'm not a Windows user
<zmatt>
and usb on Windows sucks quite a lot
<Guest9>
No you are right. I was focused on the drivers without stopping to think what they were used for.
<zmatt>
but the interfaces used by the BBB are either standard (CDC-ACM, CDC-ECM/NCM) or Microsoft-proprietary (RNDIS)
<Guest9>
I've configured it to run off RNDIS
<zmatt>
as far as I understand it can however sometimes be difficult to even convince Windows to use Microsoft's own fucking drivers for their own proprietary RNDIS protocol, so who knows *shrug*
<zmatt>
the best ways to not have any usb driver related issues are either 1. don't use Windows, or 2. don't use USB (i.e. connect via Ethernet)
<Guest9>
I am having issues with logging on to the board via SSH tho. I installed putty and have sucessfully connected via IP address, that should have been the first clue :/. Tried both use:pwd "root:" and "debian:temppwd" to no avail. I'm planning to flash a new image onto the board via ssd, but is there any other solution?
<Guest9>
As to the above 1. Windows is currently more convenient for me:p 2. I dont have an ethernet cable yet.
<zmatt>
well if the previous owners set a different password then you'd need to boot from external sd card to mount the emmc and manually reset the password, though if the emmc contents is unknown and potentially ancient you're probably better off reflashing anyway
<zmatt>
do keep in mind that if it's an ancient BBB then it may have only 2G of eMMC rather than 4G, so then you'd want a console/minimal image rather than an IoT image
<Guest9>
I've ordered an SD card which should arrive soon, so thanks for the advice about the minimal image. What's an emmc?
<zmatt>
eMMC is the on-board storage, essentially like an sd card but as a chip
<zmatt>
it's what you'd typically boot from
<zmatt>
(if you intend to run from sd card instead, it's highly recommended to wipe eMMC using "sudo blkdiscard /dev/mmcblk1" since an old bootloader on eMMC can cause weird and subtle problems when booting a much newer system from sd card)
<Guest9>
How would I run that command? The board does not allow me to login
<zmatt>
you'd use it once you've booted from sd card
<zmatt>
obviously even if you could login right now, wiping eMMC while booted from eMMC would be ill-advised
<Guest9>
yeah
<zmatt>
oh, and right now you may still be able to get into the system via the usb serial console
<Guest9>
huh
<zmatt>
which acts like a normal serial console, but is exposed via usb (as a CDC-ACM usb serial device)
<Guest9>
I'll look into that
<zmatt>
it should show up as a COM port
<Guest9>
device manager?
<zmatt>
yeah you should see it there
<zmatt>
and iirc putty can connect to COM ports as well
<zmatt>
or you'd use some other terminal program
<zmatt>
actually, never mind I'm dumb
<zmatt>
I just realized the serial console still requires login
<zmatt>
the *real* serial console might allow bypassing it but I'm not sure, and certainly not the usb serial console
<Guest9>
so boot from SD, run the discard command, turn off and remove SD and repower?
<zmatt>
ehh if you wipe eMMC it will need an SD card to boot
<zmatt>
note that that advice was for "if you intend to run from sd card instead"
<Guest9>
oh
<Guest9>
so typical flash procedures should be fine? (ie replace the old image?)
<zmatt>
I would generally recommend reflashing eMMC and booting from that, not from SD card, unless you really need more space than eMMC has
<Guest9>
There wont be any issues when booting the new image before the flash completes?
<zmatt>
if there's a really ancient or weird bootloader on eMMC this could prevent the BBB from booting from a modern image on SD card, in that case you'd need to bypass eMMC by holding down the S2 button (the button closest to the SD card slot) while powering on the board (you can let go of the button once the power led turns on)
<zmatt>
this will cause the on-chip bootrom to ignore the eMMC and load the bootloader from SD card instead
<Guest9>
is that the USER/BOOT button?
<zmatt>
(this setting is persistent until next power-cycle, a warm reboot/reset does not suffice)
<zmatt>
yeah
<Guest9>
Ok
<Guest9>
So if I wish to run the image off SSD, and not emmc, boot off of SSD and run 'sudo blkdiscard /dev/mmcblk1 ' to delete old image, then DONT remove the ssd? In this configuration would I have to power up with S2 ?
Shadyman has quit [Quit: Leaving.]
<zmatt>
also, if you're going for a minimal/console install then it may be worth using the latest bullseye testing image rather than the 2020-04-06 console image... like, for IoT there are presumably still reasons to stick with the stable 2020-04-06 image, but for a minimal/console image I'd just go with the recent bullseye one ( ...
<zmatt>
Guest9: you wouldn't need the S2 button anymore. by default bootrom tries to get the bootloader from eMMC but if that's missing it falls back to loading it from SD card
<Guest9>
ok
<zmatt>
the S2 button is only needed to force it to load from SD card, completely ignoring eMMC
<zmatt>
of course wiping eMMC is not strictly needed in general to boot from SD, usually it'll be fine to use the bootloader on eMMC to boot from SD card, if they're the same version or at least close enough.... but if the bootloader on eMMC is much older than the system on SD card, it might not understand all of the options configured on that system's /boot/uEnv.txt
<zmatt>
which can result in a system that boots but doesn't quite work right the way it's supposed to
<Guest9>
Could I ask why would booting from SD would eventually flash emmc?
<zmatt>
??
<Guest9>
Sorry I'm just a little confused.
<zmatt>
so am I, I don't understand what you mean
<Guest9>
I thought that when flashing the emmc, the BBB would use the old bootloader to boot the new image, running into the issues previously mentioned
<Guest9>
I'm mixing things up
<zmatt>
reflashing eMMC will completely wipe and replace its contents, including bootloader
<zmatt>
the issues I mentioned are just when booting from SD card, without having used the S2 button, when an old system (or more specifically an old bootloader) is present on eMMC
<Guest9>
Ok thank you for the clarification.
<zmatt>
since then bootrom will load the bootloader from eMMC which then should load and boot Linux from SD card, but that second step can go wrong... both overtly wrong (i.e. failing to boot, or ignoring the SD card and booting from eMMC instead) or subtly (booting from SD card but not everything works quite right)
<zmatt>
usually it'll at least boot from SD card, which suffices to be able to login and either get it to flash to SD card or wipe eMMC to make sure next time it will boot using the SD card's bootloader rather than the eMMC one
<zmatt>
very rarely, if the eMMC bootloader is _really_ ancient or just very incompatible (e.g. not from a beagleboard.org image), you may need the S2 button to make it boot from SD card
bryanb has quit [Ping timeout: 248 seconds]
bryanb has joined #beagle
<Guest9>
How does flashing work? and whats the difference between flashing and booting via SD card?
<zmatt>
flashing to eMMC is done by booting into a special flasher (which, instead of booting normally, installs the system onto eMMC and then powers off), which is accomplished in one of three ways:
<zmatt>
1. some images also have special "eMMC Flasher" versions you can download and write to SD card. this is the easiest option, but unfortunately not all images have a corresponding flasher image
<zmatt>
2. for the new bullseye (debian 11) images, you can boot from SD card and then "sudo enable-beagle-flasher && sudo reboot" to boot the image into the eMMC-flasher
<zmatt>
3. for the buster (debian 10) images, you need to modify the /boot/uEnv.txt file on the SD card to uncomment the line that causes it to boot into its flasher, I think it's always the last line in the file but it's easy to recognize regardless, it starts with "cmdline=" and contains something about eMMC flasher. if you're on Windows, editing /boot/uEnv.txt on the SD card is best accomplished by ...
<zmatt>
...booting the SD card, logging in, ...
<zmatt>
... and then editing the file from there
AKN has joined #beagle
bryanb has quit [Ping timeout: 260 seconds]
<AKN>
Hi all. could anyone help me out n how to define gpio pinmux for beaglebone ai dts
<AKN>
i tries these cape_pins: cape_pins {
<AKN>
compatible = "gpio-leds";
<AKN>
pinctrl-names = "default";
<AKN>
};
<AKN>
pinctrl-0 = <&cape_pins_default>;
<AKN>
cape_pins_default: cape_pins_default {
<AKN>
pinctrl-single,pins = <
<AKN>
/* Comment format:
<AKN>
Ball: Default Funcationality // Functionality as per Mux Mode // Functionality in Hardware
AKN was kicked from #beagle by zmatt [please don't spam in chat]
<Guest9>
zmatt thank you for all the help. Do you mind if I recap?
<zmatt>
go ahead
<Guest9>
For Flashing, S2, with sd card, access and run number 2. of the flash options you listed.
<Guest9>
For Booting of SD card, either ensure that the emmc image is not ancient by deleting it or reflashing it
AKN_R has joined #beagle
AKN has quit [Quit: Leaving]
<zmatt>
S2 optional (usually not needed but doesn't hurt to use it just in case), and which of the three flashing options depends on what image you downloaded
<zmatt>
and yes. if you initially can't boot from SD card at all you'd need to use S2 once, but that problem will be solved once eMMC is wiped or reflashed
<Guest9>
So if I wanted the IOT image booted from SD, since my board probably has less memories than newer models, it would be best to flash via the above instructions the new image, load IOT image onto SD, and run?
<Guest9>
the bootrom loads the bootloader onthe emmc (minimal image) which loads the image from the SD card (IOT)?
<zmatt>
if you wanted to boot the IoT image and don't have enough eMMC space (i.e. you have a BBB rev B or older) then you'd just download the normal (not eMMC flasher) IoT image and boot from that, and to be safe wipe eMMC once you've booted from it
<zmatt>
(in all cases, for writing an image to SD card it is recommended to use balena Etcher, etcher.io)
<Guest9>
Thank you for all the help
<zmatt>
you can also tell whether your eMMC is the old 2GB one by just visually inspecting the board: the eMMC is the chip on the top side close to the leds, and the old 2GB one is a Micron eMMC with part marking "JW896"
<zmatt>
(while the 4GB is either Micron "JWA06" or a Kingston chip)
<Guest9>
yup its the 2GB version
<zmatt>
yeah, then either flash a minimal image to eMMC, or wipe it and boot from SD card
<zmatt>
depends on what you want to do with the beaglebone and how comfortable you are with debian
<Guest9>
not at all lol
<zmatt>
like, the minimal image would require you to install whatever packages you want via the internet (by connecting the BBB via Ethernet to a network)
<zmatt>
ok yeah then you probably want to just boot from SD card and leave the eMMC unused
<Guest9>
would a gateway connection through usb work?
<Guest9>
yeah
<Guest9>
so clear emmc, boot from SD?
<zmatt>
sharing internet to the BBB via usb is possible in theory but in general a headache that requires messing with network settings on both sides and risks losing your only connection to the BBB
<zmatt>
boot from SD, clear eMMC (without booting from SD you don't have a way of clearing eMMC)
<Guest9>
ok
<zmatt>
clearing eMMC will 1. make sure you don't need the S2 button (if you needed it to get it to boot from SD the first time), and 2. make sure there's no subtle problems due to version incompatibility between the bootloader and the linux system
<Guest9>
If i wanted to have a minimal system on emmc, and the graphical system on SD, would powering on the board with SD without boot button launch the graphical interface?
<zmatt>
it'll prefer booting from SD card if there's a bootable SD card present yes
<zmatt>
note that none of the current BBB images include a graphical interface
<Guest9>
oh
<zmatt>
or, well, I guess there might be images for it, but the IoT image doesn't
<zmatt>
the BBB uses an industrial SoC whose very limited graphical capabilities are basically just intended for simple touchscreen interfaces, not for running a modern desktop environment
<zmatt>
it can run one, but definitely not very comfortably or with good performance
<zmatt>
ok yeah a graphical (Xfce) debian 11 (bullseye) testing image does exist for the BBB, but I wouldn't expect too much from it in terms of how well it will run :P
<zmatt>
most commonly you'd use SSH to access the beaglebone
<Guest9>
ic
<Guest9>
So then given my experience level, a minimal snapshot should be fine?
<zmatt>
ehh, like the name implies, a minimal image comes with very little preinstalled, so it expects you to be okay with providing the BBB with internet access and using that to install any packages you need to do whatever you want to do
<zmatt>
while the IoT image comes pretty much with everything and the kitchen sink apart from a GUI
<Guest9>
ok so IOT it is
<zmatt>
in the end it'll also depend on what you want to do with it
<Guest9>
This will actually be my first time messing with something like it
<Guest9>
so baby steps for now
<zmatt>
anyway, I'm off for a bit
<Guest9>
thanks for alll the help
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Quit: Stat_headcrabed]
ft has joined #beagle
ft has quit [Quit: leaving]
Guest9 has quit [Quit: Client closed]
otisolsen70 has joined #beagle
AKN_R has quit [Read error: Connection reset by peer]
ft has joined #beagle
nparafe has quit [Ping timeout: 265 seconds]
nparafe_ has joined #beagle
ikarso has joined #beagle
Guest48 has joined #beagle
<Guest48>
Hi
<Guest48>
I am looking for LCD TFT boasrd
<Guest48>
so can you provide the suggetion
Guest48 has quit [Quit: Client closed]
buzzmarshall has joined #beagle
bryanb has quit [Remote host closed the connection]
bryanb has joined #beagle
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
Guest9 has joined #beagle
vvn has quit [Quit: WeeChat 3.8]
ikarso has quit [Quit: Connection closed for inactivity]
vvn has joined #beagle
<brook>
Does anyone here have a Beaglebone Black board running NetBSD?
otisolsen70 has quit [Quit: Leaving]
ikarso has joined #beagle
Guest9 has quit [Ping timeout: 260 seconds]
vagrantc has joined #beagle
zjason``` has joined #beagle
zjason`` has quit [Ping timeout: 250 seconds]
ikarso has quit [Quit: Connection closed for inactivity]