<k-man>
are these in cars yet? or too new for that?
<k-man>
what the? 8-Port 2.5Gb switch
<k-man>
built in 8 port switch?
<zmatt>
yup, ethernet is a big thing in automotive these days for internal networking between the car's systems
<k-man>
wow
<k-man>
amazing
<zmatt>
with help of new ethernet standards like TSN that allow for reliable traffic flows with guaranteed low latency
<zmatt>
as for whether these are in cars yet, I have absolutely no idea how long their development process is
<zmatt>
certainly much longer than consumer products!
<zmatt>
k-man: the TDA4VM also has two 6-core PRU subsystems :D (versus one 2-core PRU subsystem on the AM3358 and two 2-core PRU subsystems on the AM5729)
<k-man>
wow amazing
<k-man>
and interesting about the ethernet standard
<zmatt>
yeah, the deterministic latency extensions to ethernet started from the broadcasting industry and was initially called AVB (Audio/Video Broadcasting) but industry and automotive took an interest hence it became known as AVB/TSN (Time-Sensitive Networking)
<zmatt>
because of the need for extremely low latency on control messages in the latter applications there's also a feature added to ethernet that allows for transmission of a packet to be *paused* to interject a high-priority packet and then the interrupted packet is resumed
<zmatt>
(IEEE 802.3br)
<k-man>
amazing stuff
<Guest44>
zmatt: Just wanted to let you know that I created a custom dtb using that adc fragment that you gave me and it works! iio_info shows all 8 channels, etc. So, thanks for your help with that.
<zmatt>
you're welcome!
<Guest44>
The python iio module still crashes when I try to load it, complaining about iio_get_backends_count being an undefined symbol
<zmatt>
sounds like the python library version doesn't match the iio library version?
<Guest44>
Hmm, could be. Good idea; I'll dig into that.
<zmatt>
iirc the python lib is actually built as part of libiio
<Guest44>
Do you know if the iiod daemon is necessary if I'm just using the local backend?
<zmatt>
nope
<zmatt>
(as in, no you don't need it)
<Guest44>
Heh, thanks for the clarification--I was just about to ask for it.
<Guest44>
Looks like XML backend is required for local backend
<zmatt>
?
akaWolf has quit [Ping timeout: 272 seconds]
<Guest44>
In menuconfig, XML backend is selected by default when libiio is selected, as is local backend: they both have [*]. When I unselect XML backend, local backend's [*] changes to -*-
<Guest44>
I thought that indicated a missing dependency.
<zmatt>
you're talking about buildroot I guess?
<Guest44>
Yes. (sorry, I was just thinking/typing out loud)
<Guest44>
I'm rebuilding my rootfs on the chance that something is out-of-sync with it which is certainly possible with all the twiddling I've done today.
<zmatt>
it seems to build fine without xml
akaWolf has joined #beagle
<zmatt>
and works fine too
<zmatt>
so if buildroot isn't letting you enable the local backend without the xml backend, that's a buildroot issue
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 272 seconds]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #beagle
<Guest44>
Apparently in BR -*- for libiio local backend is selected automatically if xml backend is not selected.
<Guest44>
that is, it means it has been automatically selected.
<Guest44>
And the python binding *is* part of the whole libiio package, so I'd think they would be in synch.
<Guest44>
Looks like it's pulling v0.19 from github.
Guest44 has quit [Quit: Client closed]
brook has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 255 seconds]
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
GuillaumeAusset[ has left #beagle [#beagle]
Shadyman has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
<jfsimon1981>
Good morning
demirok has joined #beagle
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #beagle
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
otisolsen70 has joined #beagle
renrelkha has quit [Ping timeout: 268 seconds]
renrelkha has joined #beagle
jfsimon1981 has quit [Read error: No route to host]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
starblue has quit [Ping timeout: 272 seconds]
brook has joined #beagle
akaWolf has quit [Ping timeout: 272 seconds]
xet7 has joined #beagle
akaWolf has joined #beagle
thinkfat has quit [Ping timeout: 244 seconds]
thinkfat_ has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
<brook>
Are there any issues known about uSD cards and the BBB? I'm getting a "data abort" error on boot and I'm wondering about the media (although I have gotten the card to work with other OSes).
vvn has quit [Quit: WeeChat 3.5]
<zmatt>
brook: that problem description is much too vague to help diagnose
<zmatt>
(and no, there are no "issues known about uSD cards and the BBB")
<zmatt>
at what point during boot are you getting this data abort? what's on the sd card?
<zmatt>
use a paste service like pastebin.com to share the log of what you're seeing
<zmatt>
the only thing that comes to mind where an sd card might trigger a data abort is if the beaglebone thinks the sd card is bootable and tries to boot from it but the sd card contains a system not meant for a beaglebone
<zmatt>
but without more context, it's just a random guess
buzzmarshall has joined #beagle
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #beagle
xet7 has quit [Read error: Connection reset by peer]
starblue has joined #beagle
brook has quit [Read error: Connection reset by peer]
<zmatt>
why did you say you were using a BBB when it's actually a BBE ? :P
SteveMarple has left #beagle [Leaving]
<brook_>
That script is from a BBE, yes. I have done the same on both the BBB and BBE and get the same results.
<zmatt>
ok
<brook_>
Any idea how to debug this?
<brook_>
By the way, Debian boots fine from the same uSD card.
<zmatt>
I really don't know anything about netbsd... over the many years I've been here I've seen a few people using OpenBSD but I'm not sure I've seen anyone try to run NetBSD
<brook_>
Fair enough. Still, any ideas on how to go about debugging early stage boot problems like this?
<zmatt>
not really, that will require intimate knowledge of NetBSD's boot process
<zmatt>
and possibly UEFI (which is also something almost noone uses on the BBB)
<brook_>
OK. What is the normal boot process? Can it boot a u-boot kernel, for example?
<zmatt>
this data abort log is also fairly useless since it doesn't even include any details about the abort like the memory address it aborts on
<brook_>
I expected that all the data after "data abort" were that. No?
<zmatt>
normally u-boot is loaded (in two stages, SPL then full u-boot) and then u-boot loads the linux kernel, device tree, and optionally initramfs, and executes the kernel
<zmatt>
no that's just the processor state, not abort info
<brook_>
I see. So the data abort handler would ideally report more? Where would it get the memory address?
<zmatt>
Data Fault Status Register (DFSR) and Data Fault Address Register (DFAR)
<brook_>
Full u-boot is loaded after the SPL. I can break into it and execute commands manually. I'm not really sure what commands I need, though.
<zmatt>
what would you want to do in u-boot? u-boot seems to be doing fine and successfully loads the next stage, which in this case it bootarm.efi
<brook_>
Yes, but I have available other kernels, e.g., u-boot ones. I was thinking I could try booting that instead, but I'm not quite sure how to set up the device trees, etc. Would it make sense to try that?
<zmatt>
I have no idea how NetBSD boot works or what would be needed to get that working
<zmatt>
like, you're one of the very very few people in the world trying to boot NetBSD on a beaglebone... if you don't know the answer to these questions, you may not be the right person to be trying this.
<zmatt>
unless there's a known good way to get a bootable netbsd system on a beaglebone (and evidently the steps you followed are not that, since it didn't result in a bootable netbsd system), you're essentially taking up the role of maintainer when trying something like this :P
<brook_>
Well, I do know how to boot u-boot kernels on other hardware. The u-boot scripts for the BBB seem much more complicated, with lots of options.
Guest7 has quit [Quit: Client closed]
Guest7 has joined #beagle
otisolsen70 has quit [Quit: Leaving]
<brook_>
Yes, I realize that. However, I know others have had success, including the main person who is developing this. I am trying to figure out how to tell what is different for me, even though I am using the same image. That's why I started wondering about the hardware, i.e., uSD card.
<zmatt>
I maen, that depends on how u-boot was built... and since you built it as part of your image, there's no reason for its boot script to be more complicated than on any other target
<zmatt>
the boot script of the default u-boot.img on beagleboard.org debian images is fairly complicated due to supporting lots of things (including DT overlays), but you're not using that u-boot
<zmatt>
actually, do beware of one thing:
<zmatt>
bootrom will prefer loading u-boot from eMMC over loading it from uSD, so to force it to use the u-boot on your SD card you can either wipe the one on eMMC or bypass it by powering on with the S2 button held down (the button closest to the SD card slot). you can let go of the S2 button once any led turns on, and once powered on like this bootrom will ignore the bootloader on eMMC on every reboot ...
<zmatt>
...until the board is power-cycled
<brook_>
Thanks. I have been doing that, but I hope my timing was right. Would it boot the uSD image if the eMMC had been selected? It is clear that this is booting stuff on my uSD card.
<zmatt>
timing for the button is really easy, just hold the button down while connecting power (or powering on using the power button when in poweroff state), and like I said once any led turns on it's safe to let go of the button
<zmatt>
and this u-boot doesn't look like a beagleboard.org one
<brook_>
Would it help to see the u-boot scripts themselves?
<zmatt>
not really no
<zmatt>
like I said, u-boot seems to be doing fine with loading bootarm.efi
<zmatt>
if you want to try loading the netbsd kernel directly without efi you'd need to ask someone who knows netbsd how to do that
<brook_>
That is the sort of thing I tried a bit by dropping into the u-boot console. I can investigate whether others have had success booting directly rather than via efi. That works on other hardware. Is there a reason it should be expected not to work here?
<zmatt>
no reason to expect that no, but it'll depend on netbsd's needs
<brook_>
Yes, but would that be hardware dependent or OS dependent? If a u-boot kernel boots on one platform, would you expect the same u-boot script to boot it on another?
<zmatt>
I don't know what you mean by "a u-boot kernel"
<zmatt>
this question is mostly OS-dependent, and only slightly platform-dependent
<brook_>
OK. I'll have to look at the details, but I think the u-boot kernels have a header in addition to the kernel binary.
<zmatt>
like, when booting linux, there's some agreed-upon way for u-boot to execute a linux kernel while passing it the device tree blob, the initramfs image (if used), and kernel parameters
starblue has quit [Ping timeout: 248 seconds]
<zmatt>
u-boot's responsibility is then to locate these 2 or 3 images (kernel, dtb, optional initramfs) and load them into memory, determine appropriate kernel parameters (specifying e.g. the root filesystem and console), and execute the kernel
<zmatt>
(along with platform-specific early initialization of course)
<zmatt>
the way in which these things are located is generally platform-independent, hence so is the boot script responsible for locating them
<brook_>
Is it reasonable to expect that if a kernel boots on one platform with u-boot performing those steps, that the same kernel on a different platform could use the same u-boot steps?
<zmatt>
as long as the kernel supports both platforms and you didn't accidently hardcode platform-specific details into the steps you're executing
<zmatt>
but these are mostly questions for netbsd folks
<zmatt>
I don't know anything about its boot process
<brook_>
Yes, I realize. Thanks a lot for your help. You have given me some good ideas to pursue.
<zmatt>
a mailing list thread I found also linked to http://www.armbsd.org/ which appears to have prebuilt images for lots of targets including the BBB
<zmatt>
well, maybe "lots" is an overstatement.. a bunch of targets
<brook_>
Yes. Those are claimed to work, but don't seem to on my hardware. I'm trying to figure out where the difference might be.
<zmatt>
to alleviate any worries about the bootloader on eMMC (the button can sometimes be a bit finnicky) you may want to just wipe eMMC ("sudo blkdiscard /dev/mmcblk1" from a bootable debian sd card) .. you can always reflash eMMC later
<zmatt>
or "sudo dd if=/dev/zero of=/dev/mmcblk1 seek=256 count=1" should suffice to prevent bootrom from loading the MLO from eMMC
<brook_>
OK. How does the reflashing work? How do I know I am reflashing a copy of what is there now?
akaWolf has quit [Ping timeout: 246 seconds]
<zmatt>
I mean, generally you'd flash whatever image you want (typically the latest official IoT image for new users, though experiences users may be interested in a debian bullseye testing image and/or a minimal image rather than the IoT image)
<brook_>
And it is just a matter of booting an image with the right u-boot command that does the flashing, right?
<zmatt>
I would normally not care about what image it was shipped with, in fact I'd generally recommend reflashing as step 1 since you never know what random ancient image might be on it (since it's entirely possible it's been sitting on some warehouse shelf for an indeterminate amount of time)
<zmatt>
it's not an u-boot command, but yeah... there are pre-made flasher images, or you can turn a normal bootable image into a flasher by uncommenting one line in /boot/uEnv.txt (I think it's the last line) that passes an init=/path/to/something-with-eMMC-flasher.sh parameter to the kernel
<brook_>
I could presumably save it in a file with dd also, and reuse that.
<zmatt>
(this does not work if the contents of eMMC is so ancient that it still uses a separate FAT boot partition, but if it is that ancient you should definitely just wipe it)
<zmatt>
yup
<brook_>
I'm not sure about the eMMC, but the NetBSD images do that. It looks like the whole beginning is zeros, so the first few boot options are skipped.
<brook_>
I'm not familiar with that, but I have read parts of the TI tech reference manual about this.
<zmatt>
it just summarizes info from the TRM
<brook_>
OK. A summary might be good as the TRM is really long.
<zmatt>
(ignore the examples below the one-paragraph explanation, those are for running the tiny baremetal example program in this repo)
<brook_>
I suppose from this that there are not other copies of the MLO on the eMMC (e.g., at the other three positions).
<zmatt>
correct, beagleboard.org images only use offset 256
<zmatt>
(and offset 768 for u-boot.img)
<brook_>
By the way, if there is no uSD card, it tries to boot from the net prior to trying the eMMC?
<brook_>
(if the switch is closed)
<zmatt>
boot order without S2 is { eMMC, μSD, uart0-xmodem, usb-rndis }, boot order with S2 is { spi-flash, μSD, usb-rndis, uart0-xmodem }
<zmatt>
(this is just the boot order for bootrom, i.e. where it attempts to find the next stage, typically u-boot SPL. it does not affect how/where u-boot looks for an OS to boot)
<brook_>
So, no network interface either way.
<brook_>
Right. U-boot can configure the network interface and use tftp, etc.
<zmatt>
no, usb-rndis will make the bbb show up as ethernet interface via usb and perform bootp/tftp boot via that
<zmatt>
bootrom does support netboot via ethernet, but that requires overriding the sysboot pins (accessible on expansion header P8) using wires (or preferably resistors) to ground/3.3V
akaWolf has joined #beagle
<zmatt>
e.g. this was the setup I used a long time ago for experimenting a bit with baremetal programming on a BBB: https://liktaanjeneus.nl/barebone.jpg .. you can actually see the two resistors between the bottom of P8 (at the topright) going straight across to ground on P9 and diagonally across to 3.3V on P9
<brook_>
But that would not be necessary if u-boot is running, right? It seems I have no trouble getting that far.
<zmatt>
this was without u-boot, just bootrom -> my program
<brook_>
Also, I get messages like the following from u-boot: Loading Environment from FAT... *** Warning - bad CRC, using default environment. Could that be replacing the expected environment with another?
<zmatt>
no since it's failing to load persistent environment variables hence using the (expected) default environment
<brook_>
OK, so ignore that.
<zmatt>
persistent environment variables are a great way to persistently break things ;) the u-boot on beagleboard.org debian images is built without support for persistent environment
<brook_>
And that can be set with one of the u-boot configuration options in the platform definition files?
<zmatt>
support for persistent environment can be enabled or disabled in u-boot's build config... dunno what "platform definition files" are
<brook_>
Sorry, I guess that is what I meant.
<brook_>
I'm thinking of the files that contain a list of configuration options for the build.
<zmatt>
you mean the example configs
<brook_>
Perhaps. I'll have to go back and look at the source code. I just remember a bunch of files for different platforms that had lists of configuration variables. Perhaps I'm hallucinating; I'm not intimately familiar with the u-boot code. Sorry.
<k-man>
What is/was the beaglebone a6?
<k-man>
Did it come out before the bbb?
Guest44 has joined #beagle
<zmatt>
k-man: A6 sounds like a hardware revision number, but both the original BeagleBone (White) and the BBB had an A6 revision
<zmatt>
(BBB revisions are A4A, A5, A5A, A5B, A5C, A6, A6A, B, C, and C3)
<brook_>
What is the best way to determine the revision of a particular board?
<zmatt>
board identification including revision can be read from eeprom
<zmatt>
a BBB will almost always be revision C or C3, the rest are very early boards
<zmatt>
C/C3 has 4G eMMC, the earlier ones 2G
<k-man>
Ah thanks zmatt
<zmatt>
C3 is relatively recent so most BBBs out in the wild will be rev C
<brook_>
The manual lists C, C1, C2, C3, so I was wondering how to tell the difference in case it matters in my case. I've got the later Kingston eMMC, i.e., C2 or C3 I suppose.
<zmatt>
C1/C2 are trivial BOM changes
<zmatt>
none of these changes should matter
<brook_>
The box says C1, but the manual says "initial boxes mistakenly say rev C1". With the later eMMC, I suppose this means it's a C3? I guess none of this will matter, though.
<Guest44>
zmatt: I'm trying to figure out why the python ctypes.util.find_library() isn't working in my buildroot image. It works on the Debian 10.3 running on my BBB, so I'm trying to figure out what is different.
<Guest44>
I've read that setting LD_LIBRARY_PATH before calling python is one way to fix it, but I notice on Debian that LD_LIBRARY_PATH is not set, yet find_library works as desired.
<Guest44>
Do you know how that is?
<Guest44>
That is, what determines the path the find_library follows?
<zmatt>
LD_LIBRARY_PATH is a way to deal with libraries installed into a non-standard place where the dynamic linker doesn't normally search
<Guest44>
I did try that, but it still doesn't work. This makes me think I may have a more fundamental problem in my BR image.
<zmatt>
what library are you trying to find?
<Guest44>
iio
<Guest44>
Which *is* working, btw, so thanks for your help with that.
<Guest44>
Python just can't find it.
<zmatt>
try: ldd $(which iio_info) | grep libiio
<Guest44>
Heh, gotta install ldd into the image first. Be back in a bit.
<zmatt>
oh, you can instead do: LD_TRACE_LOADED_OBJECTS=1 iio_info | grep libiio
<zmatt>
ldd is normally included with the dynamic linker
<zmatt>
but you can instead have the dynamic linker perform the equivalent functionality itself using that environment var
<Guest44>
It says the libiio so is in /usr/lib, which is correct.
<zmatt>
note btw that find_library is normally not used, the API for loading shared libraries normally performs the search itself and it does not return the path, so ctypes find_library has to somehow replicate this functionality
<zmatt>
then I have no idea why you're having problems... especially since earlier you didn't have the same problem (you had a missing symbol, but that suggests it *was* able to load the shared library)
<Guest44>
I'm still getting that same missing symbol error, but I think it's because in the line just before that failure it's calling find_library('iio') but it's failing and just returning None. At least that's what I get when I try it manually.
<zmatt>
ah
<zmatt>
they should just pass "libiio.so.0"
<Guest44>
The missing symbol is iio_get_backends_count, but I've looked and it's in there. I think it's trying to call that method on None which, of course, doesn't work.
<zmatt>
like, what find_library() does is misguided
<zmatt>
and also, "On Linux, find_library() tries to run external programs (/sbin/ldconfig, gcc, objdump and ld) to find the library file" ... so I'm guessing it's just missing those tools
<Guest44>
Yes, that would seem to be easier, although perhaps the intent is to be cross-platform, i.e., so it works on Windows, too.
<zmatt>
I guess, but it's a bad idea
<Guest44>
Hmm. Yeah, I read that about find_library() but now that you say it, it occurs to me perhaps those are missing and that's why it's failing.
<Guest44>
Going to check...
<zmatt>
you want to use the version of the shared library that the software expects... if libiio.so is a symlink to some future libiio.so.1 then a library designed for the libiio.so.0 should not accidently use this newer library
<zmatt>
which is why dynamically linked programs reference libiio.so.0, not libiio.so
<zmatt>
the python binding should likewise load libiio.so.0 and not try to replicate what the linker does
<zmatt>
the ctypes documentation even admits this: "If wrapping a shared library with ctypes, it may be better to determine the shared library name at development time, and hardcode that into the wrapper module instead of using find_library() to locate the library at runtime."
<Guest44>
It's just calling it 'iio' which, from my reading of the ctypes page, is the correct form to pass to find_library().
<zmatt>
the problem isn't how they're calling find_library(), the problem is find_library() itself
<zmatt>
what it does is the Wrong™ thing to do
<zmatt>
the fact it has to kludge around with invocation of external tools is already a very clear hint at that
<zmatt>
the fix is not using find_library()
<Guest44>
CDLL.FindLibrary() does work, btw, although I think that requires the whole path which kinda renders it pointless.
<zmatt>
the output of find_library() on linux is not a path, it's the name of the shared library: 'libiio.so.0'
<zmatt>
or rather, the compat name of the shared library... i.e. the thing that designates binary compatibility
<Guest44>
Oh, right.
<Guest44>
find_library() isn't working on anything, e.g., find_library('c'), etc.
<zmatt>
since 'libiio.so.0' determines the API used by the python binding, that name is what should be hardcoded on linux (other platforms may handle shared library versioning differently)
<zmatt>
that's what I said, most likely find_library() is broken in your environment because it tries to do its misguided job by invoking external tools that aren't installed
<zmatt>
but again, find_library() is just wrong
<Guest44>
BR just pulls the package from Analog Devices' github page, although it's a bit old: 0.19 whereas current is something like 0.24.
<zmatt>
it should hardcode 'libiio.so.0'
<Guest44>
I wonder why it doesn't hardcode it.
<zmatt>
maybe whoever wrote it doesn't understand how shared libraries are supposed to work
<zmatt>
portability seems unlikely given how iio is a linux-specific driver framework
<zmatt>
I guess that's not quite true due to its weird network support
<zmatt>
but using find_library() doesn't really fix that either, e.g. find_library("iio") is not going to work on Windows
<zmatt>
loading shared libraries is just inherently platform-specific
<Guest44>
The language seems rather non-linux oriented.
<zmatt>
yeah well, I can tell you that using find_library() on Linux is a bug
<zmatt>
I'd guess it's probably a bug on other platforms too, but I can tell you for certain it's a bug on linux
<zmatt>
the _only_ correct thing to do on linux is passing 'libiio.so.0' to ctypes.CDLL
brook_ has quit [Read error: Connection reset by peer]
brook has joined #beagle
<Guest44>
But Debian 10.3 has a libiio package, version 0.19, and it works. It would have the same find_library() call in it, wouldn't it?
<zmatt>
yes it works, but it's still a bug
<zmatt>
it doesn't work in all environments
<Guest44>
But how/why is it working on Debian? Seems like it should fail there, too.
<zmatt>
it would also break if there's ever an incompatible new major version version of libiio
<Guest44>
And I just checked some of the new releases, up to 0.24 and it's still in there.
<zmatt>
I already explained why it's probably failing in your environment
<zmatt>
but I don't think you should try to fix it in your environment, since the underlying problem isn't in your environment, the real problem is that ctypes.util.find_library() is well-intentioned but misguided and inherently wrong (at least on linux) even if it may appear to give sensible results in many cases
<Guest44>
On Windows, btw, it looks for libiio.dll.
<zmatt>
and on Linux it should use 'libiio.so.0', without calling find_library()
<Guest44>
Well, at least I can patch that on my build. Guess I'll ask the AD folks about it.
<zmatt>
afaict find_library() is also inappropriate on Winows
<zmatt>
basically, find_library() tries to emulate something that's normally only done at compile-time, and which is not appropriate to do at runtime
<zmatt>
and since your buildroot image isn't a compile-time environment, it fails
<zmatt>
(but even if it succeeds, e.g. on debian images, it's still the wrong thing to do)