nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
set_ has joined #beagle
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
hnv has quit [Quit: Client closed]
<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 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 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 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> is the primary repo for the patches I think
<schorsch76> I found ... ok ....
<schorsch76> Thx :)
florian has joined #beagle
<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 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
<schorsch76> Ins uncommented in the end ^
Shadyman has quit [Quit: Leaving.]
<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
<zmatt> the problem is, I know it doesn't have the exact commit corresponding to the u-boot version you listed, since that would have to be
<schorsch76> That was what i expected
<zmatt> but that's probably just due to a difference in git metadata (e.g. commit date)
<schorsch76> The whole arm universe is just like a mess.... each board is different ... like the famous rant from Linux
<schorsch76> Linus
<zmatt> I think passing --committer-date-is-author-date to git-am should make the commit hashes reproducible
ayjay_t has quit [Ping timeout: 256 seconds]
ayjay_t has joined #beagle
vagrantc has quit [Quit: leaving]
_av500_ has quit [Ping timeout: 256 seconds]
_av500_ has joined #beagle
schorsch76 has quit [Quit: Client closed]
_av500_ has quit [Ping timeout: 240 seconds]
_av500_ has joined #beagle
Guest71 has joined #beagle
rcn-ee_ has joined #beagle
rcn-ee has quit [Read error: Connection reset by peer]
johanhenselmans_ has joined #beagle
johanhenselmans has quit [Ping timeout: 256 seconds]
johanhenselmans_ is now known as johanhenselmans
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
buckket has joined #beagle
schorsch76 has joined #beagle
schorsch76 has quit [Quit: Client closed]
hnv has joined #beagle
Guest71 has quit [Quit: Client closed]
hnv has quit [Quit: Client closed]
hnv has joined #beagle
<rcn-ee_> zmatt, still a lot of legacy using the old u-boot tree's.. on the forum's snapshot pages, i link to the branch of u-boot used..
dirtcastle has joined #beagle
<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 ./ 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?
<rcn-ee_> easy 8mm of more vertial space to plug in a serial adpater..
<SJFriedl> ok. I think my right-angle thing will serve the same purpose. I was hoping there was some magic solution
<set_> I used wires instead of a direct connect from BBGW to Cape and the header in question is then easy to access.
<SJFriedl> I wish these pins would be moved to where the cape wouldn't be in the way.
<set_> Besides that, GenTooMan, I took notes last night on reactance (capacitive and inductive) and MOSFETs being encompassed in this field.
<set_> Two pages later, I nice right up will be done w/ SCIENCE in mind and not just "DO IT THIS WAY" ideas.
<set_> I also noticed that MOSFETs not FETs where patented in '60, i.e. the year after two people from Bell Labs invented them.
<set_> SJFriedl: Did you use wires "inside" the cove of BBB and Cape to manage your UART header(s)?