<BeagleSeeker>
zmatt thanks for the tip on beagle usb. Don't intend to use it much, but it's good for things like quick easy console, light duty wifi, that stuff. I never trusted USB as an embedded its gotta work standard anyway. there's better buses for that. also you rock, thanks for the link to open droneID.
<BeagleSeeker>
where in the kernel sources does one find module/driver sources for various sensor chips and various io chips? is there an index of supported devices by function such as RTC, canbus, wifi, humidity, pressure, orientation, etc?
Shadyman has joined #beagle
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #beagle
<zmatt>
drivers are organized hierarchically by type in the drivers/ directory, although you sometimes need a bit of background to know where to look, e.g. humidity/pressure sensors (when handled by a kernel driver rather talking to them directly from userspace via e.g. i2c or spi) would be handled by the iio subsystem hence be found in drivers/iio/
<zmatt>
the descriptions of the various drivers are also in the Kconfig files you find throughout the linux source tree (which are used to describe all kernel config options in machine-readable format)
vagrantc has quit [Quit: leaving]
Guest4955 has joined #beagle
<Guest4955>
Hello, I downloaded the Debian image from here https://beagleboard.org/latest-images. But is seems only the rootfs, not including boot loader and kernel image. Is it right?
<zmatt>
Guest4955: those are part of the image
<zmatt>
they're not separate things
<zmatt>
they're complete bootable images
aussetg has quit [Remote host closed the connection]
aussetg has joined #beagle
Guest4955 has quit [Quit: Client closed]
Guest4971 has joined #beagle
<Guest4971>
Hello, I downloaded the Debian image from https://beagleboard.org/latest-images and it seems only rootfs, no boot loader and kernel image included. Is it right? Thanks!
<zmatt>
Guest4971: they are complete bootable images, including kernel and bootloader
<Guest4971>
I used balenaEtcher to open the image downloaded from here and flash to SD card. And then there is only one partition on the SD card with rootfs. Is it possible that something is missing?
<zmatt>
no, that's correct
<zmatt>
if you're expecting a separate boot partition, beagleboard.org images haven't used that in many many years
<zmatt>
the kernel is installed on the rootfs, the bootloader is located in the space between the partition table and the rootfs partition
<Guest4971>
ok
<Guest4971>
Where is kernel image put? And is it possible to see the bootloader?
<zmatt>
kernels are installed into /boot/ like on every debian system
<zmatt>
not sure what you mean by "see the bootloader" ... the bootloader consists of two parts (u-boot SPL and the full u-boot.img) located at fixed offsets from the start of the image
<zmatt>
start sector 256 and 768 respectively
<Guest4971>
Ok. So it is raw data, not in the file system, right?
<zmatt>
correct, it's outside the filesystem
<zmatt>
like I said, in the space between the partition table and the rootfs partition
<Guest4971>
Got it. Clear now. Thanks a lot!
<zmatt>
this applies specifically to images for AM335x and AM572x btw... I think the images for the bbai64 actually do use a FAT boot partition of some sort
<zmatt>
(because of different bootrom behaviour)
<Guest4971>
Ok got it. Nice! Thank you!
<Guest4971>
The live chat is really good. Thank you again. Bye!
<set_>
Wait!
<zmatt>
depends on if someone happens to be around ;)
<set_>
Sorry...nevermind.
<Guest4971>
Ok understand. It looks I am lucky today:-)
<Guest4971>
No worries
<Guest4971>
By the way, could eMMC boot still be bypassed?
<zmatt>
depends on what you mean by that... bootrom will by default load u-boot from eMMC unless it can't find it there in which case it tries to load it from SD card. if you power on with the S2 button held down (it's sampled the moment the device turns on) the bootrom will ignore eMMC and load u-boot from sd card only
<zmatt>
in either case, u-boot will try to load linux from sd card first and eMMC second
<zmatt>
so in practice if a bootable sd card is present, the beaglebone will boot from that instead of from eMMC ... with the caveat that it's still using the u-boot from eMMC, so if that's a very different version from what the system on sd card is expecting you may get problems
<zmatt>
(hence if it's desired to boot from sd card, I would generally recommend wiping eMMC to ensure bootrom loads u-boot from sd card)
<Guest4971>
just don't want to hold boot switch when power up the board.
<Guest4971>
So need to erase eMMC partition
<zmatt>
sudo blkdiscard /dev/mmcblk1
<zmatt>
will wipe eMMC
<zmatt>
note that generally I would recommend flashing to eMMC rather than running from sd card, unless eMMC doesn't have enough disk space for your use-case
<Guest4971>
Ok. got it.
<Guest4971>
Yes I think it makes sense.
<zmatt>
the BBB can read from eMMC about twice as fast as it can from SD card
<Guest4971>
Just wondering where the content in eMMC are from?
brook has quit [Remote host closed the connection]
<zmatt>
flashed during production with the latest official image at that time
brook has joined #beagle
<zmatt>
of course you never know how long a BBB has been lying on some shelf before you buy it, so there's always a risk that the image on eMMC is in fact quite old
<Guest4971>
Yes
<Guest4971>
Anyway to know that and update it?
<zmatt>
easiest way is by downloading an eMMC flasher image, write that to SD card, and boot the beaglebone from it... it'll proceed to reflash eMMC (and then power itself off when done)
<zmatt>
you can also turn a normal image into an eMMC flashed by uncommenting a particular line in /boot/uEnv.txt ... I think it's the last line of that file, something with cmdline=init=...yada yada eMMC flasher something.sh
brook has quit [Ping timeout: 252 seconds]
<Guest4971>
Ok. But, "write that to SD card", if the boot loader in SD card is in raw data, it needs to be very careful, right?
<zmatt>
(it directly accepts .img.xz files and will decompress them on the fly, and it will verify the contents of the sd card after flashing)
<Guest4971>
Ok that's good. You mean, by modifying the uEnv.txt, etcher will flash boot loader to eMMC?
<zmatt>
??!?
<zmatt>
you're mixing two different instructions
<zmatt>
if you download an eMMC flasher image and flasher it to SD card you don't need to do anything with /boot/uEnv.txt
<zmatt>
but if you already flashed a normal bootable (non-eMMC-flasher) image to SD card, you can *convert* it into an eMMC flasher by modifying /boot/uEnv.txt on the SD card
<zmatt>
(eMMC flasher images are clearly labeled as such on the download page, e.g. "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher")
<zmatt>
and etcher doesn't flash anything to eMMC, etcher is a tool you run on your PC to flash SD cards
<Guest4971>
ok, I think I need to digest what you said.
<zmatt>
regardless of which of the two methods you use to make an eMMC-flasher sd card, if you boot a beaglebone from one it will proceed to flash the system from sd card to eMMC
<zmatt>
(including bootloader)
<Guest4971>
one question, when you said "(it directly accepts .img.xz files and will decompress them on the fly, and it will verify the contents of the sd card after flashing)", this refers to normal etcher flashing process, right?
<zmatt>
I was talking about Etcher yes
<Guest4971>
But when I said ""write that to SD card", if the boot loader in SD card is in raw data, it needs to be very careful, right?, you replied "using https://www.balena.io/etcher is recommended". I was wondering how etcher can use the eMMC flash imager?
<zmatt>
I don't understand what you mean
<zmatt>
Etcher just writes an image directly to sd card
<zmatt>
it doesn't care what's on this image
<zmatt>
the presence of a bootloader in a particular place on the image is of no relevance to Etcher
<Guest4971>
So, you mean Etcher also takes the separate eMMC flash imager, not just the whole image which is downloaded from beagleboard.org/latest-images?
<zmatt>
???
<zmatt>
an eMMC-flasher-image is also downloaded from beagleboard.org/latest-images
<zmatt>
they're nearly identical to the normal images, except their /boot/uEnv.txt is modified so that instead of booting normally it will boot into a tool that flashes the system to the beaglebone's eMMC
<Guest4971>
Ok, sorry I was thinking it wrongly when you said download eMMC flash imager at the first time.
<Guest4971>
Got it now.
<Guest4971>
Thanks for your patience(y)
<zmatt>
you can alternatively make that change to the /boot/uEnv.txt yourself, but ready-to-go eMMC flasher images are also made available for download for convenience
<Guest4971>
One more question about the IP address after Linux is running.
ikarso has joined #beagle
<Guest4971>
Getting started page says "Your Beagle should be running a DHCP server that will provide your computer with an IP address of either 192.168.7.1 or 192.168.6.1, depending on the type of USB network adapter supported by your computer's operating system. Your Beagle will reserve 192.168.7.2 or 192.168.6.2 for itself." It is fixed as 192.168.7.1 or
<Guest4971>
192.168.6.1?
<zmatt>
the beaglebone has two usb-network interfaces: one using the usb standard CDC-ECM or NCM (depending on image version) protocol, the other using microsoft's proprietary RNDIS protocol because microsoft of course couldn't be fucking bothered to actually implement usb standards properly
<zmatt>
so on Windows it'll use the RNDIS interface, on which the beaglebone is 192.168.7.2 (and your PC will get the IP 192.168.7.1)
<zmatt>
on Mac it will use the CDC interface, on which the beaglebone is 192.168.6.2 (and your PC will get the IP 192.168.6.1)
<zmatt>
Linux supports both hence the beaglebone will show up as two interfaces, both of which work
<Guest4971>
Trying to connect. If the user LED is flashing, does it mean Linux is running, right?
<zmatt>
if the usr1 led is flashing in a heartbeat pattern yeah, but it starts doing that as soon as the kernel loads, it can take a bit before it has booted up far enough to be able to ssh
<Guest4971>
Ok, it seems something is wrong here. usr0 is flashing fast twice then wait a little longer, not at heart beat rate. usr2 is on, but very weak, occasionally flash once.
<zmatt>
"flashing fast twice then wait a little longer" ... that's a heartbeat pattern :P
<zmatt>
usr2 "on but very weak, occasionally flash" => cpu mostly idle with a little bit of activity going on, and shorts bursts of activity every now and then
<zmatt>
sounds normal to me
<Guest4971>
Ok good
<Guest4971>
But when I ping 192.168.7.1, it doesn't respond.
<zmatt>
.1 is your own pc, the beaglebone is .2
<zmatt>
(although I'd still expect .1 to be pingable, but maybe windows firewall blocks that or something :P )
<Guest4971>
Same result. If my network subnet is 192.168.1.xxx, would the IP address still be 192.168.7.1 or 192.168.6.1?
<Guest4971>
I will use Linux
<zmatt>
on the usb-network interfaces that show up when your connect a beaglebone via USB to your computer, your network subnet will not be 192.168.1.xxx
<zmatt>
if you're talking about Ethernet and your beaglebone is connected via that, then your beaglebone will obtain an IP address from your router
<zmatt>
in which case you may be able to reach the beaglebone by hostname, either just "beaglebone" or "beaglebone.local" may work
<Guest4971>
I am using usb-network interface
<zmatt>
did it indeed show up on your PC as network interface?
<zmatt>
or indeed any kind of device
demirok has quit [Quit: Leaving.]
<Guest4971>
It just didn't work in Windows
<Guest4971>
Ok I can log in now.
<Guest4971>
Thanks a lot zmatt for your help today. Much appreciated.
<zmatt>
you're welcome
<Guest4971>
Is is so knowledgeable of you. Hope to see you later.
Guest4971 has quit [Quit: Client closed]
demirok has joined #beagle
rob_w has joined #beagle
indigaz has quit [Quit: Ping timeout (120 seconds)]
indigaz has joined #beagle
florian has joined #beagle
ft has quit [Quit: leaving]
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #beagle
xet7 has quit [Remote host closed the connection]
Shadyman has quit [Remote host closed the connection]
demirok has quit [Quit: Leaving.]
demirok has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
rob_w has quit [Remote host closed the connection]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
ikarso has quit [Quit: Connection closed for inactivity]
brook has joined #beagle
ikarso has joined #beagle
BeagleSeeker has quit [Quit: Client closed]
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
florian has quit [Quit: Ex-Chat]
ikarso has quit [Quit: Connection closed for inactivity]
BeagleSeeker has joined #beagle
vagrantc has joined #beagle
<BeagleSeeker>
where can i find info about using the BNO055 from userspace and how exactly once the kernel has the correct driver how the device is presented to the user? all the examples i can find use python or similar to hide the details. other drivers (like the pca9685 pwm driver chip) just give a nice set of files to write to (or read from) which makes
<BeagleSeeker>
use from userspace really nice!
<BeagleSeeker>
zmatt have you looked at the beaglebone green gateway? Does it follow the same BBG stupidity or did they finally learn from their error?
Himanshu has joined #beagle
Himanshu has quit [Client Quit]
ft has joined #beagle
jfsimon1981_b has quit [Remote host closed the connection]
jfsimon1981_c has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 268 seconds]
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #beagle
jfsimon1981_b has joined #beagle
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #beagle
jfsimon1981_c has quit [Ping timeout: 252 seconds]
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
vagrantc has quit [Quit: leaving]
brook_ has quit [Quit: Leaving...]
brook has joined #beagle
<zmatt>
BeagleSeeker: it sacrifices real ethernet, it instead has some wonky "usb hub with integrated usb-ethernet adapter" chip
<zmatt>
well, dunno if it's wonky, but it's usb :P
<zmatt>
LAN9512
<BeagleSeeker>
zmatt real nice how they just ignored and left hanging the ethernet they abandoned when they started down their wonky road isn't it?
<zmatt>
pretty sure they did it because the pins normally used for ethernet are used for wifi
<zmatt>
on the gateway
<zmatt>
so it doesn't have the same problem as the green-wireless
<zmatt>
basically, having ethernet *and* wifi on a beaglebone either means you have to sacrifice a bunch of expansion header pins (to get the equivalent of a beaglebone black + wifi cape) or you put one of the two on usb