brook has quit [Remote host closed the connection]
brook has joined #beagle
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #beagle
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 260 seconds]
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 244 seconds]
jfsimon1981_b has quit [Remote host closed the connection]
GenTooMan has quit [Ping timeout: 264 seconds]
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
behanw has joined #beagle
ikarso has joined #beagle
rob_w has joined #beagle
<LetoThe2nd>
NishanthMenon: hmm not sure I get you. This means that there is an upstream kernel+dtb suitable for the ai64, but not in the ti kernel? which in turn means, there is no recipe for it yet?
Beagle45 has joined #beagle
behanw has quit [Quit: Connection closed for inactivity]
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 268 seconds]
otisolsen70__ has joined #beagle
otisolsen70_ has quit [Ping timeout: 260 seconds]
jfsimon1981 has joined #beagle
ft has quit [Quit: Lost terminal]
GenTooMan has joined #beagle
otisolsen70__ has quit [Quit: Leaving]
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #beagle
GenTooMan has quit [Ping timeout: 264 seconds]
otisolsen70 has joined #beagle
Shadyman has quit [Remote host closed the connection]
<NishanthMenon>
LetoThe2nd: I will try and see if I can backport the patches to TI tree and get some basic support in meta-ti
<LetoThe2nd>
NishanthMenon: well redirecting to a mainline kernel, I think I can manage that.
jfsimon1981 has quit [Remote host closed the connection]
<NishanthMenon>
LetoThe2nd: I think the new rev is so new, I don't think it has been merged upstream yet.
<LetoThe2nd>
NishanthMenon: ok understood
GenTooMan has joined #beagle
jfsimon1981 has joined #beagle
CrazyEddy has joined #beagle
Beagle45 has quit [Quit: Client closed]
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #beagle
brook has joined #beagle
rob_w has quit [Quit: Leaving]
Beagle45 has joined #beagle
<vvn>
zmatt: hi! About the mini usb configured as host, it worked, but sometimes it doesn't, it seems spurious. You mentioned the vbus of the port, is there something I should configure in the device tree for that? I don't understand why it'd work sometimes, sometimes not.
Beagle45 has quit [Quit: Client closed]
<zmatt>
if vbus isn't present then it will not "work sometimes", it will just not work
<zmatt>
at all
<zmatt>
if you're having problems, I suggest you check kernel log
<zmatt>
there is nothing else to configure in DT, any remaining issues will most likely be hardware-related
<zmatt>
in some sense it's surprising it works at all, given that this usb controller is designed as an OTG controller and normally uses the ID pin to determine the port mode and normally expects to be able to switch vbus power itself (with close monitoring of the vbus voltage)... I'm not sure how the kernel driver manages to bully the usb controller into working in host mode (in contradiction to the ID pin) ...
<zmatt>
...with a fixed non-switchable vbus
brook has quit [Remote host closed the connection]
brook has joined #beagle
lucascastro has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Remote host closed the connection]
vagrantc has joined #beagle
brook has joined #beagle
brook has quit [Ping timeout: 265 seconds]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
<jfsimon1981>
Good evening
<jfsimon1981>
There's a blog article about ethernet Phy not being able to be addrssable on power up, i never seem to experience this issue, is this actual or addressed, has someone got hit with it ?
<zmatt>
jfsimon1981: so, there are various issues the phy can have. sometimes it's merely on the wrong phy address, that part has been fixed (or worked around rather) in software a long time ago
<zmatt>
the phy can also be completely non-operational, that part can't be fixed in software (the workaround in that blog port is hazardous and should not be used)
<zmatt>
we occasionally hit it and implemented an external workaround to reduce the probability
<jfsimon1981>
really that's lucky i don't rely on it
<jfsimon1981>
Not very good though
<jfsimon1981>
yes i see.
<zmatt>
bbb rev c3 also includes a reset line to the phy which means a complete fix could be implemented in u-boot now
<zmatt>
I don't know if such a fix has been implemented yet
<jfsimon1981>
ok
<jfsimon1981>
i'll check it
<zmatt>
(I don't think it has)
<jfsimon1981>
you mean tied to to the main sys reset
<jfsimon1981>
so the chip resets itselfs to get the phy to reset too.
<zmatt>
no, there's a gpio to the ethernet phy reset
<jfsimon1981>
ah
<zmatt>
the phy reset tied to the chip reset is what's been causing the problem
<zmatt>
(apparently due to the slow rise time of the chip reset as a result of the ridiculously large capacitance on it)
<jfsimon1981>
ok 0.1u, like a bypass cap
<zmatt>
no there's a much larger cap
<zmatt>
unless that got removed in C3
<jfsimon1981>
i'll get( latest schematic
<jfsimon1981>
I'm on c rev now
<zmatt>
they did change it!
<zmatt>
"Changed C24 from 2.2uF to DNI"
<zmatt>
I didn't realize that
<jfsimon1981>
ok
<jfsimon1981>
That's a great news
<zmatt>
rcn-ee: has an ethernet phy reset on rev C3 (using the gpio) been implemented in u-boot? with C24 gone, the reset pulse at power on is technically too short for the phy (shorter than that's mandated by the datasheet)
<zmatt>
*what's mandated
<jfsimon1981>
they worked this out it looks
<jfsimon1981>
GPIO 1_8
<jfsimon1981>
and system reset
<jfsimon1981>
i only see a 100n on sys_resetn (C30) therefore 0.1u
<zmatt>
ideally phy reset would not have been connected to sys_resetn at all, but I guess they wanted to keep that for backwards compatibility
<jfsimon1981>
Though i don't quite get it, the software is supposed to reset the ethernet PHY is unresponsive ?
<zmatt>
technically with the new C3 design u-boot ought to reset the phy at least once. I don't know if the phy problem can still occur with this new design, but in case it does happen u-boot could reset the phy again until it *does* respond
<jfsimon1981>
Basically the and gate is a shlmitt trigger
<jfsimon1981>
means the output has fast rising edge
<zmatt>
yeah indeed
<jfsimon1981>
that may have taken care of it so
<zmatt>
which is why it's a bit weird they also removed C24 ... I would have kept C24 in this case
<zmatt>
since the AND gate already cleans up the edge, and C24 would make sure the power-on reset time meets the phy specification
<jfsimon1981>
perhaps why i never noticed it, i run the project since november 2021, they revised it april 2021
<jfsimon1981>
I see DNI stands for do not install
<zmatt>
correct
<jfsimon1981>
C24 was there to prevent spurious reset i think
<jfsimon1981>
2.2 micro is very high i guess
<zmatt>
no, it was to extend the reset timing to meet the phy spec
<zmatt>
the reset pulse duration from the pmic is technically insufficient
<jfsimon1981>
ok
<jfsimon1981>
there's a C147 there
<jfsimon1981>
4.7 uF
<zmatt>
which should absolutely not be there
<zmatt>
I don't understand why it is there
<jfsimon1981>
It's an open drain gate
<zmatt>
they should have used a nand gate with push-pull output
<jfsimon1981>
When open it charges theough r33
<zmatt>
I guess that does extend the reset time again
<zmatt>
but it also again exposes the phy reset to a slow rising signal, which appears to have been the cause of the original issue
<jfsimon1981>
indeed with an open drain the ground time is a fast edge, rise time is an RC constant
<zmatt>
I dunno, the root cause of the phy issue has never been understood, maybe this different reset circuit happens to fix the problem
<jfsimon1981>
It was 0.1u not it is 4.7uF
<zmatt>
C24 was 2.2uF
<zmatt>
or what do you mean?
<jfsimon1981>
2.2u yes
<zmatt>
yeah so now it's an even slower rise time
<zmatt>
in the testing I've done with a beaglebone that prominently suffered from this problem I found a clear correlation between reset rise time and probability of phy failure: the slower the rise time, the higher the probability of failure
<jfsimon1981>
So the RC time constant owed to be at sys_resetn input of the gate somehow
<jfsimon1981>
if i understand right the concern about pulse duration.
<zmatt>
ehh I can't parse that sentence
<jfsimon1981>
To extend properly the reset at ethernet phy and get fast edges
brook has quit [Remote host closed the connection]
<zmatt>
(note that the NAND gate is new in rev C3, and this comment was written before then)
<jfsimon1981>
not using an open drain, instead have rc at the input B for example
<jfsimon1981>
that would extend the pulse and give it fastt edge.
<jfsimon1981>
yes in rev c3
<zmatt>
I'm lost at what you're saying
<jfsimon1981>
you mention the phy ethernet needs a fast reset pulse with a certain duration
<jfsimon1981>
which is why they used c24 and now c174
brook has joined #beagle
<jfsimon1981>
if rc is on input side of the gate, with a shitt trigger there's fast edge
<jfsimon1981>
c174 ought to be on input of the gate, if i understand the issue.
<zmatt>
they could have left C24 and just used a push-pull NAND gate
<jfsimon1981>
yes the same
<jfsimon1981>
except you couldn't reset the phy
<zmatt>
?
<zmatt>
yes you could, via the NAND gate?
<jfsimon1981>
GPIO1_8 now allows it
<zmatt>
that's the whole purpose of the NAND gate
<jfsimon1981>
yes sorry
<jfsimon1981>
I mean just an inverter would be fine, no need for a GPIO
<zmatt>
??
<zmatt>
ehh, AND gate
<zmatt>
it's an AND gate, not a NAND obviously
<jfsimon1981>
I'm not sure the gpio reset is required
<jfsimon1981>
if that's just for that bug
<zmatt>
the purpose of the gpio reset is to be able to reset the phy if the issue happens again
<zmatt>
with the gpio reset you at least know that should there be any further problems, they can be worked around in software
<jfsimon1981>
yes, though it's multiplexed
<zmatt>
?
<jfsimon1981>
GPIO1_8 is used for something is it not
<zmatt>
no
<zmatt>
it was not-connected on previous BBB revisions
<jfsimon1981>
indeed
<jfsimon1981>
It was NC my mistake
<jfsimon1981>
there must be something else
<jfsimon1981>
"The Pin19 nRST (ETH_RESETn) of PHY
<jfsimon1981>
LAN8710A is Schmitt trigger input type."
<zmatt>
yeah it makes no sense
<jfsimon1981>
Means there shouldn't be any issue with slow rise at the pin input
<zmatt>
and yet, that is what I observed in actual testing
<jfsimon1981>
Ok
<zmatt>
¯\_(ツ)_/¯
<jfsimon1981>
You mean they made it worse, but i have never had any issue, or maybe didn't notice it
<zmatt>
I don't think I've observed it with the new setup either, which makes things all the more mysterious
<zmatt>
but I've also not been looking for it
<jfsimon1981>
At least it can be reset too, that's something good
<jfsimon1981>
yep
<zmatt>
I *think* our devices collect statistics on it, I'll need to ask the other devs about this tomorrow
<jfsimon1981>
ok
<jfsimon1981>
it's interesting if you can share this info
<jfsimon1981>
if that's at all possible of course
<jfsimon1981>
i'm not too confident with all this,
<jfsimon1981>
i had an issue with PRU driver of some sort, a quadrature encoder to mess with the PWM so that you helped me disable it, it was doing random kernel panic
<zmatt>
yeah the buggy out-of-tree eqep driver
<jfsimon1981>
the ethernet issue which went for a couple years eventually
<zmatt>
every product has bugs, every chip has bugs
<zmatt>
it's just the way it is
<jfsimon1981>
yes i can run tests for a particular setup to make sure it works well but you can't always test all conditions
<jfsimon1981>
i'm relying of it to be working free of bugs for years, though i think it's doing good enough, probably the emmc was the biggest potential risk
<jfsimon1981>
i was intending to run openbsd on it, this os is quite sane and simple, but it might have other issues, with lack of support
<jfsimon1981>
i intend to check it, except it might be less resilient to halt by simple power than linux is
<zmatt>
if you want a stable low-risk system, I certainly wouldn't run something as poorly supported as openbsd on it
<jfsimon1981>
openbsd is supported, though a handful of drivers are available
<zmatt>
"supported"
<jfsimon1981>
indeed linux ecosystem for it seems mature
<jfsimon1981>
i've had so few issues with openbsd, i understand it much better, it's quite clean
<jfsimon1981>
at the moment i say i have no luck to make it run with it, but i can check deeper, if there a chance for it that would be what i'd opt for
<jfsimon1981>
maybe netbsd
<zmatt>
lol
<jfsimon1981>
makes you laugh
<jfsimon1981>
or develop thourough test platform and deal with them
<zmatt>
just go baremetal development :)
<jfsimon1981>
that's what i prefer you're right
<jfsimon1981>
except i can't do the whole things in a lifetime
<zmatt>
TI has sort of an SDK for that on the am335x, called StarterWare, but it's a steaming pile of pig manure
<jfsimon1981>
i just need i2c, a serial com with RTS for RS485, usb host, a storage location, and self updating capability
<jfsimon1981>
yep
<zmatt>
like, it was written by devs who clearly do not understand interrupts or race conditions and who have no business touching driver code with a ten foot pole
<jfsimon1981>
the client opted for Arduino but that didn't fit for all those need
<zmatt>
their uart driver caused random corruption, and their uart echo example would compile into a deadloop if you enabled any optimization
<zmatt>
:D
<jfsimon1981>
i might run projects with the graphic accelerator later, that's not needed for this present project at all
<jfsimon1981>
yes i see
<jfsimon1981>
the baremetal sdk
ikarso has quit [Quit: Connection closed for inactivity]
brook has quit [Remote host closed the connection]
brook has joined #beagle
Guest66 has joined #beagle
<Guest66>
hello
<Guest66>
I have a pocket beagle with the seeed grove cape. I used the adafruit library to add gpis controls to control a relay. My concern is whether this presents a conflict with the Grove drivers which were probably set up by default.
<zmatt>
there's no such thing as "grove drivers"
<Guest66>
no special drivers loaded for the grove cape?
<Guest66>
can you recommend an example of code to control an I2C relay board?
<zmatt>
that depends on what's on the relay board
<Guest66>
it's the seeed relay board 103020133 grove-4channel spot relay
<Guest66>
spdt
<zmatt>
they're not using any sort of standard i2c chip to drive the relays, for some reason they chose to use a microcontroller
<zmatt>
and neither the product page nor the wiki page appears to document their custom protocol
<zmatt>
so typicaly I'd avoid this sort of mess
<Guest66>
I've created a scenario where I send an email from my iPhone containing commands like "Relay 1 On" to my email address. An Applescript parses this and places the body in a file which is picked up by a python program and uses ssh to start a python program on the beagle to enable the relay. I use a 2 channel port relay which works, but I want to get
<Guest66>
the 4 channel working too.
<Guest66>
thanks
<zmatt>
it looks like it's a two-byte write: 0x10, value where bits 0..3 of the value are the four relays
<zmatt>
i2c slave address is programmable but 0x11 by default
<zmatt>
I really don't understand why they didn't just use one of the ubiquitous i2c gpio controllers
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
<Guest66>
is there an example of the code used to send an I2C command?
<Guest66>
the examples with the grove kit for other I2C controls use compiled python code