<set_>
Is anyone hooking up their MOSFETs to make things right now and if so, what are some basic calculations needing to be made on your part or mine (for instance)?
<set_>
I ask b/c I have been reading (again). And...I seem to think the future of my life deals w/ motors (at times). But...I need to figure out the correct way to go about things. slva714d.pdf from ti.com shows some neat ideas...
<set_>
Slew rate, ideas pertaining to switching EMI and frequency issues of the switch, and all under the hood. I still have not quite found out about Miller time.
<set_>
Sorry. Miller region and not Miller time.
<set_>
GenTooMan: What is the Miller region regarding MOSFETs?
<set_>
Oh and @zmatt: I have not quite handled the GPIO/SYSFS lib. you made. I am still waiting to figure out my controller and driver in hardware for now. I am still trying. Posts will soon be on the way. I just need to perform something reasonable one day, e.g. not just "DO IT THIS WAY" routines.
<set_>
You know...actual Science!
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 250 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
buzzmarshall has quit [Quit: Konversation terminated!]
rob_w has joined #beagle
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
<jfsimon1981>
Hi set
<jfsimon1981>
Recommend the EEVblog youtube channel, very interesting
Guest3 has joined #beagle
Guest3 has quit [Client Quit]
ayjay_t_ has quit [Ping timeout: 256 seconds]
schorsch76 has joined #beagle
ayjay_t has joined #beagle
buckket has quit [Ping timeout: 268 seconds]
<schorsch76>
Good morning. I play around with a BBAI and especially the booting. I compiled u-boot 2022.01 and it boots. but it cant access the mmc0 (sd card). It can just access mmc1. The running debian mainline kernel linux-image-5.10.0-11-rt-armmp can only access mmc0 and not mmc1. I bootet the BBAI via netboot pxe. So i compared the dts of u-boot and the
<schorsch76>
kernel. THey are different in many places. Why are they so different? How to match betwen a u-boot version and a kernel version?
<zmatt>
most of the dts is irrelevant to u-boot anyway
<zmatt>
and the kernel dts is kernel version dependent, so u-boot keeps its own dts files
<schorsch76>
Yes, i know that the kernel keeps it own version. U-boot loads it as a seperate file on the startup of the kernel
<zmatt>
not sure what you mean by "match between u-boot version and kernel version" ... there's generally no version-dependency between those
rob_w has quit [Quit: Leaving]
<zmatt>
or actually, there's just no version dependency between those... an ancient u-boot should load the latest kernel just fine and conversely the latest u-boot should have no problem loading an ancient kernel
<schorsch76>
Maybe i mismatched my experiments with the pi4 which just has one dtb for both u-boot and kernel. it doesnt load it again from netboot (Rpi4 with u-boot)
<zmatt>
how odd
<zmatt>
that makes no sense, u-boot's dts needs to be compiled into u-boot, which you can't do with the kernel dts since it's kernel version dependent
<schorsch76>
At the pi4, the dtb is on the first partition and get loaded by the firmware. Thats all....
<zmatt>
by u-boot you mean?
<zmatt>
oh, or by an earlier bootloader stage?
<schorsch76>
Rpi4 firmware. early boot loader
<zmatt>
yeah I guess that could work... that's a very unusual arrangement though
<schorsch76>
Yes, i was used to the BBB way...
<zmatt>
but the rpi is strange anyway, the ARM core isn't even the boot cpu
<zmatt>
it boots from the videocore ("gpu")
<zmatt>
which then brings up the ARM subsystem
<zmatt>
at least that's how it works on older rpis, I assume it's still the same on the rpi4
<schorsch76>
On the image from bb.org for the BBAI, i got u-boot 2019.07-rc4-00001-g607b5b738b . But that version is not upstream. Where can i find it?
<schorsch76>
i mean in the u-boot upstream src from denx
<zmatt>
yeah bb.org has custom patches on top, e.g. for things like u-boot overlays
<zmatt>
I don't remember off the top of my head what the primary repo is for those, I'd need to check
<zmatt>
yeah I think that contains snapshots of the resulting patched trees, but isn't where those patches are maintained... I *think*
<zmatt>
rcn-ee: am I saying that right?
<zmatt>
it would be nice if there was a repo with the final patched trees, tagged with the version string that's actually in the u-boot builds found on beagleboard.org images (e.g. 2019.07-rc4-00001-g607b5b738b) to remove any ambiguity on what the source code for these binary builds looks like
<schorsch76>
This builds for am335x_boneblack and am335x_evm
<zmatt>
am335x_evm is used, not am335x_boneblack afaik
<zmatt>
am335x_evm autodetects the board
<zmatt>
for all am335x-based boards
<zmatt>
Bootloader-Builder is also used for non-am335x boards
<zmatt>
pretty sure about that
<schorsch76>
The BBAI is am5729
<schorsch76>
I look into it
<zmatt>
correct, u-boot target am57xx_evm
<zmatt>
and I'm seeing a bunch of hits for "am57xx_evm" in build.sh
<zmatt>
is the commit that changed from building am57xx only by default to building am335x only by default
<zmatt>
it probably just reflects what he's working on at any given moment, dunno
<zmatt>
you'd need to ask him
<zmatt>
I'll agree it is a bit odd
<schorsch76>
as the version from upstream denx cant access mmc0 (sd) i wanted to build the version that is running on the image and change 2 options ..... i guess i can make that work ;)
<schorsch76>
and as i see the patch folder of the Bootloader Builder, i can see why this script exists :D
<zmatt>
yeah like I said, it would be nice if it were more obvious how to get the exact source tree corresponding to one of the binary u-boot builds
<zmatt>
the beagleboard/u-boot repo would be first place I'd expect people to look, it ought to just have tags corresponding to binaries
<rcn-ee_>
i'm moving both to v2022.01 under a single branch, jsut a differet build config..
<rcn-ee_>
i like have a simple ./build.sh under that branch, so users will see that going forward too..
<dirtcastle>
hi o/
av500 has joined #beagle
_av500_ has quit [Ping timeout: 256 seconds]
buzzmarshall has joined #beagle
florian has quit [Quit: Ex-Chat]
dirtcastle has quit [Remote host closed the connection]
hnv has quit [Quit: Client closed]
hnv has joined #beagle
vagrantc has joined #beagle
waldo323 has joined #beagle
nparafe has quit [Ping timeout: 240 seconds]
nparafe has joined #beagle
djinni has quit [Quit: Leaving]
philenot1ound is now known as philenotfound
djinni has joined #beagle
otisolsen70 has quit [Quit: Leaving]
set_ has quit [Ping timeout: 240 seconds]
set_ has joined #beagle
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
<SJFriedl>
How do people normally use the serial console on a BeagleBone when a cape is mounted on top. I've been removing the 7-pin 0.10" header and replacing it with a right-angle one.
<rcn-ee_>
SJFriedl, i use a lot of thru hole spacers on the cape headers..
<SJFriedl>
through-hole spacers?
<SJFriedl>
like nylon standoffs to boost them higher?