<set_>
I see the AI-64 is out w/ some differences in what chip holds what on it, i.e. PRU biz as usual. Yes, I still type biz.
<set_>
Neat, first off. Secondly, I missed my window. I had to sign up for "let me know when it is back in stock" ideas.
<set_>
I cannot wait to test this pup out!
<set_>
oh...am335x building. Is it possible to build an image from Buildroot still for a BBB?
<set_>
The reason I am asking are these ideas: 1. I thought I could help more. 2. I am no help any longer for whatever reason.
<set_>
I am readin' the manuals for the AI-64. Complicated? Yes...
<set_>
But...I want to put the Robot library on it. I was reading on how to perform this idea.
<set_>
They have a Robotics SDK now for it. Nice.
<set_>
SDKs usually mean well rounded, already put forth the effort to handle things ideas.
<set_>
This is a big deal. You guys?
<set_>
Way to go!
<set_>
Anyway...
<set_>
Back to Buildroot and blah, blah, blah...
<set_>
Look here: https://pastebin.com/EKN53bpV is a conjour of ideas and the board does not want to show me my u-boot prompt like usual. Can you see my error(s)?
<set_>
Anyway...if you get around to it, please let me know. I thought I knew things and how to perform on building but...
<set_>
Turns out, nothing is the same or something changed.
<set_>
Do not be too harsh on me. I am in a phase right now where building images is a thing on my end of the spectrum.
<set_>
Do not fret if the power goes down. It is my house and not me not replying.
<set_>
Come on...help me help you help me. Ha.
<set_>
I understand if people are up to their necks in new ideas. So, I will stay beautifying the land as usual as i wait.
lucascastro has quit [Ping timeout: 272 seconds]
<k-man>
morning
<k-man>
hi set_
<set_>
Hello k-man.
<k-man>
i only recently joined this channel
<set_>
Nice.
<set_>
Me...
<k-man>
it seems there is a fair bit of drop in traffic
* set_
says stuff.
<set_>
Every now and then. yes.
<k-man>
and a few or maybe just 1-2 main people who comment regularly. zmatt is one and is very expert
<set_>
It is like a roller coaster in here.
<set_>
Some days no one says things and that can go on for days. Then, all of a sudden, bam. Lots of traffic.
<set_>
I agree.
<set_>
@zmatt is a smart person w/ tons of info. on Linux, embedded systems, and the am335x along w/ the PRUs.
<set_>
But...
<set_>
He says tis, tis in his own way.
<set_>
And it is not like tis, tis the season.
<k-man>
ok
<set_>
Yeppers.
<k-man>
where are you based set_?
<set_>
I am stuck for life in LA.
<set_>
Louisiana...not the luxurious city of L.A.
<set_>
k-man: Help me help you help me.
<set_>
Did you see the paste?
<set_>
k-man: Did you see the paste from my excursions into Buildroot?
<k-man>
i had a quick look
<k-man>
but i have no experience with buildroot really
<set_>
Awesome...
<set_>
Dang it!
<k-man>
why stuck in LA for life?
<set_>
B/c...I like to believe God, then Family, and lastly Friends. I am just not good at any of the three yet.
<set_>
Like most things in life, Louisiana is a place.
<k-man>
what is your actual goal with buildroot? what are you trying to acheive?
<set_>
Oh.
<set_>
I was going to build an OS, small and insignificant, to assist someone w/ needs.
<k-man>
and a standard prebuilt distro won't work?
<set_>
But...it turns out this persons' needs are creating me to wonder.
<set_>
oh. No or maybe.
<k-man>
if I were you
<set_>
I am not sure. I thought people wanted to have their own distro from Buildroot to handle the GSoC stuff.
<set_>
Yes?
<set_>
k-man: You are me.
<k-man>
if I were you, i'd try and acheive whatever you can with a prebuilt distro first. only if you find it can't be done, then move onto custom distro
<set_>
Right...that is fun to a certain point. I understand.
<k-man>
set_: GSoC? google summer of code? i don't follow
<set_>
Completely.
<set_>
Oh. Yes. GSoC.
<k-man>
if you want to get buildroot going for fun, sure! go for it
<k-man>
but if you want to reach an end goal, don't make buildroot part of that process unless you need to imo
<set_>
There is a person in GSoC whom believes that they need to have a working knowledge of Buildroot to handle their tasks.
<set_>
Okay.
<set_>
So...I figured. "Why would I not try to assist if I found time?"
<set_>
"I would," is the answer.
<k-man>
oh sure - a worth goal in itself
<set_>
Right!
<set_>
So, I wanted to reach out every so often in case I catch someone attending to Buildroot ideas.
<set_>
Me, you, Tom, Henry, whomever.
<set_>
I used to get this build happening and I have not pinpointed exactly what has changed.
<k-man>
there's probably a buildroot irc channel too
<k-man>
or there used to be many years ago i believe
<k-man>
you could look around for that
<set_>
I mean...u-boot has changed, the protocol has different instances of options at different locations.
<set_>
Okay.
<set_>
Whelp. Nice knowing you.
<k-man>
sure
<set_>
See you later.
<k-man>
sorry i can't offer more help
<set_>
After a while.
<k-man>
ok, bye
<set_>
No issue.
<set_>
k-man: I will see you later, i.e. when my concerns are your concerns. This way, we can achieve together or still separately.
<set_>
Either way, Sunday Funday!
thinkfat_ has quit [Ping timeout: 255 seconds]
thinkfat_ has joined #beagle
<set_>
One hour and 20 minutes left before I must depart...
<set_>
Outside of k-man, are there any other people using Buildroot w/ their BBBs?
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
Shadyman has joined #beagle
Guest44 has quit [Quit: Client closed]
lucascastro has joined #beagle
<set_>
Fine...off until later notified.
demirok has quit [Quit: Leaving.]
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #beagle
<set_>
10:00!
GenTooMan has quit [Ping timeout: 255 seconds]
GenTooMan has joined #beagle
Guest11 has joined #beagle
<Guest11>
In the u-boot command line mode, the bootp data packet of the network port cannot be detected, but the USB network port can capture the bootp data packet
<Guest11>
Can anyone help me?
brook has quit [Remote host closed the connection]
<zmatt>
modifying an overlay for the BBAI is a complex matter
<zmatt>
(assuming the CAPE is even theoretically compatible with the BBAI, this is not guaranteed but needs to be evaluated on a case-by-case basis)
<zmatt>
oh it has been translated
<zmatt>
then what do you mean "tried to change the .dts" ? what you've linked *is* for the BBAI
<zmatt>
and compiles just fine for me
<zmatt>
oh ew I just realized what this overlay is doing... that's pretty gross and not compatible with cape-universal, hmm
Shadyman has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #beagle
argonautx has joined #beagle
Z4Tech has quit [Quit: Client closed]
agrue has quit [Quit: Client closed]
brook has joined #beagle
xet7 has joined #beagle
lucascastro has joined #beagle
argonautx has quit [Quit: Leaving]
jfsimon1981 has quit [Ping timeout: 246 seconds]
jfsimon1981 has joined #beagle
xet7 has quit [Ping timeout: 268 seconds]
azarubkin has joined #beagle
azarubkin has quit [Ping timeout: 252 seconds]
Guest44 has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
xet7 has joined #beagle
brook has quit [Ping timeout: 255 seconds]
Guest71 has joined #beagle
Guest71 has quit [Client Quit]
brook has joined #beagle
agrue has joined #beagle
Guest44 has quit [Quit: Client closed]
xet7 has quit [Ping timeout: 255 seconds]
Guest44 has joined #beagle
<Guest44>
zmatt: You around?
<zmatt>
Guest44: whether or not I am shouldn't matter, if you ask your question I'll eventually see or someone else might be able to help you
<Guest44>
Yes, but in this case I wanted to follow up on a previous discussion. Anyway, do I understand correctly that the naming convention for SO libs is that foo.so simlinks to libfoo.so.0 and libfoo.so.0 symlinks to, say, libfoo.so.14? And if so, what is the point of libfoo.so.0?
buzzmarshall has joined #beagle
<Guest44>
I've been reading on SO naming/numbering convention, but I haven't seen anything about that .0 links to some later .x version part.
<zmatt>
libiio.so.0 is the compat name, i.e. the part that describes the ABI compatibility, and symlinks to the actual filename, e.g. libiio.so.0.19
<zmatt>
the compat name is also embedded in an ELF header and is what's embedded in programs that link to it
<zmatt>
e.g. iio_info's dynamic linker sections contains a "NEEDED" entry for libiio.so.0
<zmatt>
libiio.so without any version suffix only exists on development systems, and indicates whatever version of the shared library corresponds to the headers installed on that development system
<zmatt>
you can have multiple incompatible versions of a library installed, e.g. libudev.so.0 and libudev.so.1, and programs which use whichever they were linked against, but you can only develop for one of them at a time
<Guest44>
So, is the problem with iio.py using find_library('iio') is that it isn't specifying which version it needs? (aside from the problem that it doesn't work, at least in my case)
<zmatt>
correct
<Guest44>
That's why it's bad form, right? Because it should say what version it needs or it will produce unpredictable results, right?
<zmatt>
and I don't know how it's even able to produce a result on systems where the libiio.so symlink is missing (which is part of the libiio-dev package, not part of the libiio0 package), preusmably it just makes a random guess
<zmatt>
it should behave like any other program that uses a shared library
<zmatt>
i.e. provide the compat name (libiio.so.0) and let the dynamic linker handle the rest
xet7 has joined #beagle
<zmatt>
not invoke external tools to try to figure stuff out it's not supposed to know or care about
<zmatt>
the only tool whose job it is to perform a search for a versionless shared library is the linker
<Guest44>
It does seem odd that it doesn't specify the version when it's a library that is included in the source tar file, IOW, it's to their own library, not someone else's.
<zmatt>
when you're building an application
<zmatt>
yes, and if a libiio.so.1 were to be present it's essential that it ignores it, since this version of the python binding wouldn't support it
<zmatt>
failing to do this breaks the ability to have a newer incompatible version of the library installed (for applications that need it) without breaking older applications that still depend on the previous major version...
<zmatt>
which is the whole point of having that major version
buzzmarshall has quit [Remote host closed the connection]
<Guest44>
Ok, makes sense. Thanks.
<zmatt>
it appears the primary way find_library() works on linux is by calling /sbin/ldconfig and grepping for libFOO.* where FOO is the library name you pass
<zmatt>
with fallbacks involving gcc and ld
<zmatt>
all of this is horrid
<zmatt>
and bad and wrong
<Guest44>
So, why does find_library() even exist?
<zmatt>
a misguided attempt to be helpful by making an inherently platform-dependent task (loading a shared library) appear to be platform-independent
<zmatt>
the funny thing is that the documentation even says: "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."
<zmatt>
yes, it "may" be better to do the right thing instead of the wrong thing ;)
<Guest44>
"The road to hell is paved with the best of intentions"
<zmatt>
"The purpose of the find_library() function is to locate a library in a way similar to what the compiler or runtime loader does (on platforms with several versions of a shared library the most recent should be loaded), while the ctypes library loaders act like when a program is run, and call the runtime loader directly.
<zmatt>
except 1. what the compiler does and what the runtime loader does are very different things
<zmatt>
2. what find_library() does is neither what the compiler does nor what the runtime loader does
<zmatt>
3. ctypes has no business trying to emulate what the compiler does, the desired behaviour is what the runtime loader does, and it doesn't need to emulate it since it uses the runtime loader to load libraries and therefore will inherently get the appropriate behaviour
lucascastro has quit [Remote host closed the connection]
xet7 has quit [Ping timeout: 268 seconds]
lucascastro has joined #beagle
amir93 has joined #beagle
<aussetg>
Not exactly a surprise but adding a fan to the AI-64 brings it to burning hot to basically cold instantly. Just need to make a Molex MicroFit fan connector now
<aussetg>
* from
<zmatt>
aussetg: I wonder how effective it would be to just somehow mount the board in a vertical orientation that encourages convection across the heatsink... wouldn't be particularly convenient regardless of course
<amir93>
Hi there, I want to use jtag connector on bbai64 with my segger base jlink. Are the pins compatible ? can I just use segger out of the box or should I configure pins manually ? Thanks.
<zmatt>
amir93: it looks like it has 10-pin ARM pinout (when using the TC2050-IDC cable)
indigaz has quit [Quit: Ping timeout (120 seconds)]
<zmatt>
which is slightly odd in itself since the 10-pin ARM JTAG header uses 0.05" pitch while the TC2050-IDC has 0.1" pitch
indigaz has joined #beagle
<zmatt>
(also, the BBAI puts EMU0 on pin 7 while that pin is n/c in the 10-pin ARM JTAG header)
<zmatt>
*BBAI64
<zmatt>
not sure what you mean by "compatible" since the j-link has a 20-pin connector, not a 10-pin one, so it doesn't even physically fit
<zmatt>
oh never mind it's definitely custom and not compatible with 10-pin ARM, so I'm not sure how you're supposed to hook it up
<zmatt>
would have been nice if it used standard 14-pin TI instead
xet7 has joined #beagle
xet7 has quit [Ping timeout: 272 seconds]
akaWolf has quit [Ping timeout: 246 seconds]
akaWolf has joined #beagle
vagrantc has joined #beagle
demirok has quit [Quit: Leaving.]
Guest36 has joined #beagle
Guest36 has quit [Client Quit]
<brook>
Is the standard way to boot a BBB into linux from u-boot to make a kernel with mkimage and then simply use fatload + bootm to load + run that image?
<zmatt>
ehh
<zmatt>
brook: well the standard BBB images don't have a FAT partition, and I don't know what mkimage is
<zmatt>
u-boot on beagleboard.org images actually does a fair bit of work since it applied device tree overlays based on CAPE autodetection and/or user configuration in /boot/uEnv.txt
<zmatt>
*applies
<zmatt>
brook: on the rare occasion I've used u-boot to manually boot a BBB from u-boot (to recover after I fucked something up such that it no longer boots normally), I use these steps: https://pastebin.com/KDjcaz0i
<zmatt>
which is fairly minimal (no DT overlays, no initramfs)
<zmatt>
from what I can find it sounds like mkimage/bootm is something that older versions of u-boot needed that didn't know how to bootload a linux zImage directly
<brook>
Yes, mkimage adds a header to zImage. Your pastebin stuff looks like what an older the u-boot environment would do if you stripped out a bunch of other code paths.
amir93 has quit [Quit: Client closed]
<zmatt>
older compared to what?
<zmatt>
and yeah this is basically just a very stripped-down version of the normal boot path from the pre-overlays era (or if overlays are disabled)
<brook>
Well, for example a 2018 version. Now that I think of it, though, I'm not sure how much of that has changed.
<zmatt>
I know there's a bunch of alternative paths, but this is still the primary boot path on current testing images with a 2022 u-boot, if we ignore overlays
<zmatt>
on beagleboard.org images
<brook>
So, is the bootm + mkimage kernel the same as bootz + normal kernel? Must the latter be compressed?
<zmatt>
bootz is for a compressed kernel (zImage / vmlinuz), which is by far the most common format for a linux kernel
<zmatt>
I've never used bootm/mkimage
<brook>
OK. Thanks and sorry for what are probably silly questions. I just have no linux experience; just BSD.
<lucascastro>
with RCN patch. uboot will doo some test to take a boot decision.
<zmatt>
yeah it supports a bunch of things
<lucascastro>
actually it's defined a uname_r variable and uboot run uname_boot defined in the patch.
<lucascastro>
uname_r in uEnv.txt file
zjason` has joined #beagle
<brook>
Is a compressed linux kernel bootable with bootz any different (other than compression) than an uncompressed linux kernel?
<zmatt>
brook: a zImage is actually executable, it's self-extracting. I'm not 100% sure why u-boot needs to know whether the kernel is compressed or not
<zmatt>
the kernel is typically compressed because waiting on I/O is slower than decompressing
<lucascastro>
zmatt: I guess to known if a compress lib is required?
<zmatt>
lucascastro: again, it's self-extracting
<brook>
Yes, I get the performance/size tradeoff. I'm trying to understand the formats of the files and whether there is different informaton beyond the compression.
<zmatt>
u-boot is not the one doing the decompression, and doesn't even know what compression algorithm was used
<lucascastro>
got it.
<brook>
So presumably the entry point for the two is the same; one just has a bit of code to decompress and jump there?
<zmatt>
brook: yeah the zImage is built from the Image
<zmatt>
if you really want to know what exactly u-boot does different between bootz and booti you'd need to check its source code
<brook>
And they both look the same to u-boot?
<zmatt>
well they look the same to e.g. GRUB on x86 systems... but apparently not to u-boot since it has different commands for them
lucascastro has quit [Remote host closed the connection]
<zmatt>
hmm, it seems the booti command is arm64-specific for some reason
<zmatt>
or rather it *was* arm64-specific in the older u-boot version I checked
<brook>
I'm not familiar with booti. I mentioned bootm earlier.
<zmatt>
bootm is for u-boot's custom image format
<zmatt>
booti = uncompressed linux kernel (Image/vmlinux), bootz = compressed linux kernel (zImage/vmlinuz)
<zmatt>
I've never heard of booti before today, apparently it is or was needed on arm64
Guest44 has quit [Quit: Client closed]
<brook>
When u-boot transfers to the linux kernel, does the kernel then eliminate u-boot from memory or does u-boot provide an API that the kernel uses, even just during the early booting?
<zmatt>
u-boot is gone
<zmatt>
afaik
<zmatt>
I don't think the kernel has any reason to call into u-boot, it passes everything the kernel needs to know
<zmatt>
*u-boot passes
<brook>
Back to booting a BBB. What additional happens when, for example, capes are involved and DT overlays are needed?
<zmatt>
brook: here's the u-boot env from the latest am335x bullseye testing image, with environment variables that contain commands reformatted to look like bash functions for readability: https://pastebin.com/Kt1rUe5V
<zmatt>
if you want to all the details, go dig through that ;)
<zmatt>
some of the autodetection is also in the board.c file
<zmatt>
or whatever it's called
<brook>
Great. Thanks. I've tried to read through the environment, but it is a bit hard without the formating.