<smaeul>
apritzel: it's a typo, I got the RXID and TXID bits switched
<apritzel>
ah, I was just about to sort those bits out
<apritzel>
the old code set some more bits (10, 12, 13, 15), the new just bits 11 and 13, but that seems to work in Linux as well?
<smaeul>
apritzel: the U-Boot change doesn't affect Linux, because linux re-sets the bits anyway
<apritzel>
smaeul: yup, this indeed fixes it, and the Linux code confirms that
<apritzel>
well, I meant replacing the old Pine64+ GBit fix with just bits 11 and 13
<smaeul>
but it should be bits 12 and 13
<smaeul>
this is the bug:
<smaeul>
+ case PHY_INTERFACE_MODE_RGMII_TXID:
<smaeul>
+ val = MIIM_RTL8211E_CTRL_DELAY | MIIM_RTL8211E_RX_DELAY;
<apritzel>
argh, yes, but I meant we don't set bit 10 and 15 anymore
<apritzel>
and don't clear bit 1 and 2
<apritzel>
so does that mean that this old Pine64+ GBit issue was just about incorrect hardware straps?
<smaeul>
yes, that is my understanding
Mangy_Dog has quit [Ping timeout: 480 seconds]
<tuxd3v>
apritzel, many thanks, I thought that the RTC was the source of HW Clock :/
<tuxd3v>
the RTC 23768 is several times a lot more precise than the 24Mhz oscillator, I think.
<tuxd3v>
32768*
<apritzel>
tuxd3v: what makes you think so?
<tuxd3v>
well the RTC is trimmed to 32768, which is divisible by 1
<tuxd3v>
giving you 1 Hz
<apritzel>
computer have no problems counting precisely to 24000000 as well ;-)
<tuxd3v>
yeah true, but the 24Mhz is not a trimmed cristal
<tuxd3v>
I believe is less acurate than the 32768 rtc one..
<tuxd3v>
but it will all depend maybe on the cristal used for 24Mhz
<tuxd3v>
:)
<apritzel>
so you are guessing?
<tuxd3v>
however if the 24Mhz is acurate it could be more acurate than a 32768
<tuxd3v>
I am guessing yeah :)
<apritzel>
I mean you can just test it: leave the kernel running for 24 hours, and compare the output of date with something accurate
<tuxd3v>
maybe because rtc seems to be almost always trimmed to 32768
<apritzel>
then shut Linux down, but leave the RTC power connected, and wait for another day
<tuxd3v>
I believe the real thing would be around how acurate those crystals are infact..
<tuxd3v>
some are 20ppm
<tuxd3v>
would be nice to have a 1ppm or less
<tuxd3v>
:)
<tuxd3v>
but the more precise the more costly they are..
<tuxd3v>
also they are sensible to temperature when soldering them down..
mps has quit [Ping timeout: 480 seconds]
<apritzel>
yeah, better crystals are ... better, but still don't understand what this has to do with the frequency
<apritzel>
having a power-of-2 frequency simplifies timer *hardware*, but this doesn't matter at all for the kernel's timekeeping
<tuxd3v>
well, my Idea was wrong from the neguining because I thought that RTC was the source of time in the system, and as you explained ..its not
<tuxd3v>
so I have to live with the consequences of my 24Mhz crystal not being perfect.. :)
<tuxd3v>
I have databases, dns, and a lot of stuff running here, and I wanted to provide the most accurate time to them, but seems that NTP will have to do the trick on its own..
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
ftg has joined #linux-sunxi
<smaeul>
do we know if there is a good way to distinguish Pine H64 model A vs model B from U-Boot? I would like to add the model B devicetree, but keep it in the same defconfig if possible
Nemo_bis has quit [Ping timeout: 480 seconds]
Nemo_bis has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<jernej>
smaeul: we had discussion about that few weeks ago and there is nothing useful
<jernej>
nothing on pcie side and model A has slot for wifi board, so you can't use that either
<gamiee>
I didn't found any diff between model A and B neither :/
diego71 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
hlauer has joined #linux-sunxi
mps has joined #linux-sunxi
diego71 has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
apritzel has joined #linux-sunxi
superj has joined #linux-sunxi
superj has quit [Remote host closed the connection]
diego71 has quit [Read error: Connection reset by peer]
tnovotny has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
cnxsoft has quit [Read error: Connection reset by peer]
apritzel has joined #linux-sunxi
chewitt has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
<apritzel>
smaeul: yeah, the GPIO differences didn't seem exploitable
<apritzel>
smaeul: does Ethernet work in U-Boot on model B, when using just the model A DTB?
<apritzel>
smaeul: we could probe for that, but probably only in U-Boot proper, and then apply an overlay
<apritzel>
jernej: is the WiFi pinout (on those headers) the same otherwise? So PM1-4 assigned to the same pins?
<smaeul>
apritzel: yes, I have an R329 board now (the MaixSense), so I can review/test that series
macromorgan is now known as Guest5003
Guest4750 has quit [Read error: Connection reset by peer]
macromorgan has joined #linux-sunxi
apritzel has joined #linux-sunxi
cnxsoft has quit []
<jernej>
apritzel: I didn't check, but since schematics are basically the same, I don't expect any differences
<apritzel>
smaeul: many thanks, much appreciated
<apritzel>
jernej: but the aldo2 power supply is one of the differences in the .dts, so I was wondering if that would be missing from the model A DTB, so TF-A wouldn't bring it up
<apritzel>
(but that's the old TF-A problem, I guess, where it brings it up anyway?)
<jernej>
well, ideally regulators should be handled by U-Boot proper and Linux
prefixcactus has quit [Ping timeout: 480 seconds]
<apritzel>
jernej: yes, I understand that "ideal" part, but was wondering if we could use that for differentiating the boards:
<apritzel>
if the EMAC/PHY works without ALDO2 enabled, we have a model A, if we need ALDO2, we have a model B
<jernej>
ah, you would use it for differentiating models
<jernej>
that's a bit overkill if you ask me
<apritzel>
yes, I know
<apritzel>
would just be some experiment for now
<jernej>
a lot of logic for SPL
<apritzel>
exactly, that's why I was thinking about doing that in U-Boot proper
<apritzel>
I know, not nice either, but worth a try, I think
<jernej>
is it possible to override board name and DT from U-Boot proper?
<apritzel>
that's the not-so-nice part ;-)
<apritzel>
we can certainly tweak the $fdtfile variable
<apritzel>
and either patch U-Boot's DT manually, or apply an overla
<apritzel>
y
<jernej>
it wouldn't work for falcon mode, but I'm not even sure if it works now good enough
<jernej>
I'm happy as long as PXE can pick correct overlay automatically :)
<jernej>
s/overlay/board DT/
<apritzel>
jernej: yeah, just something to start with
<apritzel>
does PXE use $fdtfile?
<MoeIcenowy>
apritzel: I think model A needs no ALDO2 but a GPIO
<apritzel>
MoeIcenowy: yes, that's what the DT says, but I was wondering if TF-A enables ALDO2 anyway
<MoeIcenowy>
and it needs some delay after enabling ALDO2 before initializing PHY
<MoeIcenowy>
(but when ALDO2 is brought up by TF-A, it's much delay
<apritzel>
we could try to lower PC16 and see if the EMAC still works
mehdix has quit []
mehdix has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
vagrantc has joined #linux-sunxi
gnarface has joined #linux-sunxi
<jernej>
apritzel: mystery with reboot on OrangePi Zero2 is solved - reg_dcdce must be marked as regulator-always-on (currently regulator-boot-on)
<jernej>
what happens is that reg_dcdce also powers sd card
<jernej>
so, if you disable it at boot, bootrom doesn't find sd card and goes to FEL mode instead
<apritzel>
jernej: interesting. I tried yesterday evening, with v10 on top of 5.15.0, and reset seemed to work for me
<apritzel>
ah, I just did FEL boot, and found it back in FEL after reset
<jernej>
please update this in your patches
<apritzel>
sure, will do
<apritzel>
thanks for testing and the heads up
<jernej>
np :)
<apritzel>
reset is always tricky, since it doesn't affect the AXP
gnarface has quit [Ping timeout: 480 seconds]
gnarface has joined #linux-sunxi
<MoeIcenowy>
apritzel: I think newer AXPs have some register to initiate a reset that resets all power rails
ftg has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
tnovotny has quit [Quit: Leaving]
igraltist_1 has joined #linux-sunxi
igraltist has quit [Ping timeout: 480 seconds]
PPAChao has joined #linux-sunxi
PPA has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has quit []
apritzel has joined #linux-sunxi
Jacmet_ has joined #linux-sunxi
Jacmet has quit [Remote host closed the connection]
warpme___ has quit []
plaes has joined #linux-sunxi
plaes_ has quit [Remote host closed the connection]
veremitz has quit [Remote host closed the connection]
veremitz has joined #linux-sunxi
igraltist_1 has quit [reticulum.oftc.net liquid.oftc.net]
veremitz has quit [reticulum.oftc.net liquid.oftc.net]
paulk1 has quit [reticulum.oftc.net liquid.oftc.net]
hallyn has quit [reticulum.oftc.net liquid.oftc.net]
swiftgeek has quit [reticulum.oftc.net liquid.oftc.net]
dittid[m] has quit [reticulum.oftc.net liquid.oftc.net]
DavidHeidelberg[m] has quit [reticulum.oftc.net liquid.oftc.net]
t4h4[m] has quit [reticulum.oftc.net liquid.oftc.net]
psydroid[m]1 has quit [reticulum.oftc.net liquid.oftc.net]
AntoniAloyTorrens[m] has quit [reticulum.oftc.net liquid.oftc.net]
kmaincent has quit [reticulum.oftc.net liquid.oftc.net]
Esmil has quit [reticulum.oftc.net liquid.oftc.net]
evadot has quit [reticulum.oftc.net liquid.oftc.net]