<apritzel>
tuxd3v: I don't think there is a second PWM channel on the H3
<apritzel>
I can't get it to work. I can program the S_PWM in U-Boot, and see the power LED change brightness
cmeerw has quit [Ping timeout: 480 seconds]
<apritzel>
but if I do the same to channel 1 of the normal PWM, my test LED doesn't light up
<tuxd3v>
I just need to enable it now and see, the problem I have a logic analyzer that hasa mini-usb port, and I can't find the right cable for it right now..
<apritzel>
I can toggle it via GPIO function 1
<tuxd3v>
I am tempted to go with the led test :D
<tuxd3v>
function gpio_out?
<tuxd3v>
I already set 1khz frequency.. but still need to check for that signal there..I am trying to remember were I put the mini-USB cable..
<tuxd3v>
My Idea is to use sigrok logic analyzer to retrieve the data
<tuxd3v>
apritzel, there are a lot of boards that assign pwm1 in pin PA6 :/
<apritzel>
tuxd3v: sadly that doesn't mean much
<apritzel>
it looks like AW first advertised it like this (hence the mentioning in the older version of the manuals)
<tuxd3v>
alright, I made a search ride in the home section I am, and I found it :)
<tuxd3v>
its a 4 chanels one
<apritzel>
and the PWM name of the pin just comes from the old RPi1 pin header, which has the PWM on exactly this pin
<tuxd3v>
but doesn't make sense to cut one channel out
<apritzel>
many board vendors try to mimic the 26pin or 40pin RaspberryPi headers
<apritzel>
"doesn't make sense" is not a valid term when it comes to AW SoCs
<tuxd3v>
It would give them more trouble than just ship it.. if you look they have lots of warts too
<apritzel>
you still don't understand ... they hack their SoCs badly, sometime make mistakes, but ship it anyway
<tuxd3v>
I understand that many vendors try to mimmic rpi GPIO headers, but for that case, they would use PA5 intead of PA6?
<apritzel>
but as you figured, PA5 is UART0
<tuxd3v>
because we know that PA5 for sure its pwm, but they use PA6, for pwm1
<tuxd3v>
yeah, it is indeed
<apritzel>
drop your idea of common sense when it comes to those SoCs
<tuxd3v>
So for sure alwinner wouldn't be to sumb to cut off PA6.. a lot of boards use UART0 for serial console..
<apritzel>
also wishful thinking won't help here: if the SoC doesn't have a second PWM channel, it doesn't have it
<apritzel>
what do you mean with "cut off PA6"
<apritzel>
?
<tuxd3v>
so for pwm they need indeed PA6
<apritzel>
you have the S_PWM on PL10, and the normal PWM on PA5
<apritzel>
that's it
<tuxd3v>
A lot of allwinner board use uart0 for serial console
<apritzel>
this is indeed an unfortunate choice of muxes
<apritzel>
but that doesn't mean it *must* be working
<tuxd3v>
but that means no use of PA5 for pwm, so the unique options are the PA6, or like you said S_PWM on PL10
<apritzel>
PA6 is not connected to the PWM, it's as simple as this
<tuxd3v>
but majority of boards like we observed also use PL10 for the led :/
<apritzel>
the A10 and A20 had two PWM channels, any later chip, including the H3, only have one
<tuxd3v>
so what Options does we have for pwm if not PA6?
<apritzel>
PL10, or use another UART for serial
<apritzel>
or just disabled UART0 at all, and login via SSH
<tuxd3v>
if that is the case, then Allwinner was really dumb, and the same we can say for the amount of board vendors that decided to waist S_PWM for the led, and no pwm1 only uart0
<tuxd3v>
:D
<tuxd3v>
apritzel, looking at the datasheets I agree with you
<tuxd3v>
it seems that way, specially since in the revision history of one datasheet is there "corrections for pwm.." or something like that
<tuxd3v>
but they have tons of uarts, lots of SPI, i2c devices and no pwm? I think you understand what I mean..
<tuxd3v>
I know its there S_PWM, and PWM0 on PA5, but for me there are a 2 channels pwm there, even tought that the last datasheet omits that..
<apritzel>
can you get a PWM output on PA6?
<apritzel>
I couldn't
<apritzel>
we don't need to discuss whether this makes sense or not, you can complain to both BananaPi and Allwinner, but that won't help ...
<tuxd3v>
that is said, and probably you are right since you already tested :(
<apritzel>
I might have messed something up, so please double check, but don't be disappointed ...
<apritzel>
you can still bitbang the GPIO, and hope it's fast and precise enough to be usable
<apritzel>
I see there was once a generic PWM GPIO driver proposed on the list (which did exactly that), but it didn't seem to have been merged
<tuxd3v>
ok, I am trying to use sigrock, but for any reasons that I don't know it is refusing to recognixe my device..
<tuxd3v>
recognize*
<tuxd3v>
its a udev rules for sure..
<smaeul>
> any later chip, including the H3, [with the v1 PWM IP] only have one
<smaeul>
apritzel: did you say at one time that you got an A50 tablet to play with?
<apritzel>
smaeul: an A63 tablet
<apritzel>
smaeul: I think cnxsoft once mentioned that there are A50 tablets out there now
<smaeul>
oh, yeah, I found an A50 tablet
<smaeul>
that seems to be the newest thing available outside China (other than the D1 eval boards)
<smaeul>
I thought it may be helpful to bring up some of the newer peripherals in a familiar ARM environment, but it has secure boot, so it may be more trouble than it's worth
<apritzel>
so the A50 is related to the A100 (which is also "NCAT", IIUC), but with A7 cores?
<smaeul>
yes
<smaeul>
not quite the same (like H313/H616) but similar
<apritzel>
I see
<apritzel>
I was once tempted, for exactly that reason, but the price tag wasn't too compelling, also it's missing half the bits ;-)
<apritzel>
smaeul: btw, it seems like the R40, H616 and any similarly newer chip have a different PWM IP, with much more channels
<tuxd3v>
I switched the defatult option to polarity
<tuxd3v>
it was inverted..
<tuxd3v>
I get no signal..
<apritzel>
this is all pointless, as the driver believes the device is there, and gives you all the options and settings
<apritzel>
and the driver believes this because we explicitly told it so, via the DT and the driver fix (single->dual)
<apritzel>
tuxd3v: what IS interesting is that the bits for the second channel seem to be there (in the control register, one can set them, and bit 23 and bit 29 behave as expected)
<apritzel>
but it still doesn't work, of course
<tuxd3v>
for what I understand pwm1 is a port alternate function, could be that we need to do something else to route it to PA6?
<apritzel>
I already tried function 4 and 5, also everything on PA7 as well
<smaeul>
found the UART on a test point on the back of the board :) https://tpaste.us/1JLQ
<apritzel>
smaeul: that's the A50 tablet? does it use raw NAND flash?
<smaeul>
yes, and yes
<smaeul>
it also has 1GB of DDR3 in 4 chips... in a tablet
<apritzel>
"for kids" - that's what they tend to put in the description for those kind of crap ;-)
<apritzel>
even though modern kids wouldn't touch this with a barge pole, I guess
<smaeul>
H3 has an errata where reading the SID from MMIO space doesn't work. you have to read it by programming the SID controller
<smaeul>
you can use the nvmem device/sysfs and the kernel driver will take care of this for you
<pentabarf1>
smaeul: i tried to program the SID controller by wrting to SID_PRCTL and reading from SID_RDKEY
<pentabarf1>
thanks, i will test you approach
<pentabarf1>
smaeul: when i read sunxi-sid0/nvmem with hexdump everything is zero
<pentabarf1>
btw i burned fuses for rotpk
lurchi__ has quit [Remote host closed the connection]
<smaeul>
pentabarf1: did you set the secure mode in LCJS?
<smaeul>
if so, that's why. only the first few bytes are readable from the NS world when security is enabled
<smaeul>
which fields are you trying to read?
<smaeul>
oh, and I don't thinkg SID_PRCTL is available from the normal world at all
<pentabarf1>
alright thats it. secure mode is set. i am not so firm with all this stuff. trying to figure out a way to secure my application. so i thought about reading the ROTPK as a starting point because it is hard to spoof
<smaeul>
there is a challenge-response method of verifying the ROTPK you can use from the normal world
<pentabarf1>
oh great, tell me more!
<smaeul>
give me a minute... I'll have to pull up my SBROM disassembly
Turl_ is now known as Turl
<pentabarf1>
smaeul: i'll be afk for max 1h. i will response when i'm back. thanks in advance!
<smaeul>
this is from the H616 NBROM. no idea if it works on H3 (H3 NBROM didn't support signed eGON images anyway):
<smaeul>
write the ROTPK to SID+0x120...SID+0x140, then set bit 31 of SID+0x140. wait 256 cycles and check SID+0x140 again. I believe bit 1 set means ROTPK is nonzero, and bit 0 means it matches what you wrote
<smaeul>
(the two success cases are "bit 1 clear" and "bit 0 set". the failure case is "bit 1 set but bit 0 clear")
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
<megi>
apritzel: thanks, I've cleaned up the patches and I will send it
<megi>
sram patch is not really immediately necessary
gamiee has quit [Ping timeout: 480 seconds]
<apritzel>
megi: I haven't dealt with fwlink before, from what I now learnt your solution might be indeed the right one
<apritzel>
it looks a bit out of place to have a vendor specific property in the middle of all those generic ones
<apritzel>
megi: and why do we need to point to the syscon device (the parent of the parent)?
<pentabarf1>
smaeul: tried to reproduce this using mmap with MAP_SHARED on /dev/mem and wrtiting correct or wrong rotpk to the proper address region, then wrote 0x80 to SID+0x140 and read again. in both cases i get 0x00
<pentabarf1>
SID is 0x01C14000?
<smaeul>
pentabarf1: it would be 0x80000000, not 0x80
<pentabarf1>
ah i have to write 32bit. too much time with other uC :D
<smaeul>
yes, SID is at 0x1c14000
<smaeul>
MMIO on Allwinner is always 32-bit
<smaeul>
in fact this now starts to cause problems for D1, as some RISC-V drivers assume 64-bit kernels have 64-bit wide MMIO