<apritzel>
warpme: the reset voltage for DCDC2 on the AXP313a used on the Orange Pi Zero3 is 0.9V, which is the lowest voltage supported by the CPU
<apritzel>
warpme: nevertheless we bump the CPU frequency in U-Boot up to 1008 MHz (1032 MHz, actually, smells like off-by-one), and 0.9V for that frequency is rather optimistic
<apritzel>
read: too low, so prone to random crashes
<apritzel>
warpme: what made you increase the voltage? Does any of the vendor images do this?
<warpme>
apritzel: it was "very inteligent" try&see approach :-(
<apritzel>
warpme: also: is your SD card detection also broken? The schematic shows it wired (inverted to match to usual push-pull switch semantic), but it didn't work for me
<warpme>
yes. also for me it not works
<apritzel>
good, thanks, I was wondering if that is just my board that's broken
<apritzel>
warpme: btw: the way you set the DRAM voltage, just via the DT, but not in the SPL, is a bit dodgy
<apritzel>
because the DRAM init now runs still at 1.1V, but then you step up the voltage later
digetx has quit [Read error: Connection reset by peer]
digetx has joined #linux-sunxi
<warpme>
apritzel : yes i'm fully aware of that. as i'm using spl blob - playing with dram voltage in spl (in atf in fact?) is impossible for me. this may explain why leeboby uboot is so unstable for me. its output (https://gist.github.com/warpme/a848c82a26e665fd45161bcf449b2976) shows me there is no support for axp313 - so dram vdd seems to be axp313 hw reset defaults based (and iirc as you mention isn't it 1200mV?)
<warpme>
"in atf in fact?" - forget this statement. its wrong!
<apritzel>
warpme: ah, does Linux mention the previous voltage, with leeboby's SPL? Look in dmesg for the next few lines after "axp20x ..."
<apritzel>
in your dmesg your see the correction: [ 1.350760] vdd-dram: Bringing 1100000uV into 1150000-1150000uV
<apritzel>
warpme: also, is Ethernet stable for you? I get an IP address, and after adding the clk-out-frequency-hz DT property I can even SSH into my laptop, but then it hangs sooner or later
<warpme>
yes. so when uboot (by accident) + kernel part before pmic load are executed ok - then rest seems to be stable - as dram after axp loaded is 1.15
<apritzel>
warpme: also keep in mind that the PMIC probably doesn't reset if you do a "reboot" from Linux (or any watchdog reset, really), so it might be worth playing with that
<warpme>
i have so far 3h of continuous hd tv playback - no issues so far - so it looks eth seems ok....
<apritzel>
interesting
<apritzel>
do you have any extra Linux Motorcomm PHY driver patches?
<apritzel>
also you seem to use "allwinner,rx-delay-ps = <1800>;"? That was much worse for me, so I stick to the OpiZero2 value of 3100 for now
<warpme>
re motorcomm: i think no. On 6.4.8 mainline it works ok for me on opi3lts and now also on opizero3
<apritzel>
yeah, I was comparing to that file the whole morning ...
<warpme>
also i see opi uses (probably) better cpu bins: 3h of playback with gpu glsl deinterlacer, no any heatsink on cpu and temp stabilises on 72C
<apritzel>
speaking of bins: Can anyone please distill out the actual working OPPs for the H616, and send a patch to the list?
<apritzel>
for years now people seem to carry various patches downstream, and I think mainline deserves better than a fixed 1032 MHz ;-)
juri__ has joined #linux-sunxi
<DarkNeutrino>
The H616 needs a bit more special driver due to bins. The 1.512Ghz is only possible on 2 of them i think. I used have CPU and GPU OPP in Somainline repo. Tho without the driver that takes bins into account
<DarkNeutrino>
So it just boosts my H616 which i know is good bin to 1.512max
juri_ has quit [Ping timeout: 480 seconds]
<apritzel>
but we have code to read out the bin ID and use the right set of OPPs for the H6, so we should be able to use something similar for the H616?
<DarkNeutrino>
Yep. Someone just needs to do that. I have time on monday so i will look into it :)
<apritzel>
DarkNeutrino: thanks!
<apritzel>
DarkNeutrino: might be worth shopping around various downstream "patch collections", I am pretty sure it's out there already
<DarkNeutrino>
Eh. I will rather write the small chunk of code myself :)
<apritzel>
well, if you know which register to poke and how to interpret that ...
<warpme>
of course opp-microvolts are rater mess as i was trying to find logical rule governing in my tvboxes vendor android dt how vcc_cpu is set - but discovered it is total mess.... So i ended with manual correction required for stable oper with dvfs (especially h313 was needing long babysitting)
<warpme>
ideally will be to have kind of TRM with such binX: opp1: vcc=A....
<wasutton3>
I've got a nand dump of a device (robot vacuum). I've also got a uboot prompt as well as a fastboot instance on the device I can access. I'm trying to figure out the incantation to get the raw partition data off the nand since the OS locks out ADB and the serial console instantly after booting the kernel
DarkNeutrino has quit [Ping timeout: 480 seconds]
<wasutton3>
a previous version of this device had an A33 in it, but this one is an R16-j
<wasutton3>
its definitely nand too, and not SPI or emmc.
<wasutton3>
I just don't have a handy list of all the available fastboot commands. is there a method to return all available commands?
DarkNeutrino has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
<wasutton3>
looks like the A33 and R16 are the same thing, just rebranded.
vagrantc has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
<apritzel>
wens: btw, thanks for the tip for downloading files from OrangePi's Google drive using some Google account: it worked on my phone, when the "Google Drive" app took over
kuba2k2 has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
<wens>
I think I learned that trick from some other vendor :p
<smaeul>
wasutton3: easiest way to do a full NAND dump? chip clip. second easiest way? boot mainline Linux (from U-Boot prompt) and use nanddump
<smaeul>
BSP does not provide a way to access the raw NAND underneath their partitioning/wear leveling layer
<wasutton3>
smaeul, not sure booting mainline linux is gonna work for this one. and its a tsop48, so chip clip is out
<wasutton3>
looks like im taking apart the spare, pulling the chip off, making a copy, and putting the image on the dead unit
<smaeul>
note that because of that wear leveling layer, the only thing you will be able to extract from the NAND dump is the U-Boot binary. otherwise it's only useful as a backup
<smaeul>
why not boot mainline? it doesn't need to be destructive. you can use an SD card or FEL
<wasutton3>
smaeul, becuase this board doesn't have an SD card
<wasutton3>
im not sure if it can boot FEL either
<smaeul>
does it have USB or Ethernet?
<smaeul>
there should be an "efex" command from the vendor U-Boot to enter FEL mode
<wasutton3>
its got USB, but no way I can see to boot from it
<wasutton3>
i guess the question is, since i've got a working one, whats the worst case scenario if i make a full rom image of the full chip and copy it to a spare nand chip?
<wasutton3>
looks like efex drops me into a boot mode
<smaeul>
making a full copy should work just fine. I was just trying to avoid the "pulling the chip off" part
<wasutton3>
smaeul, yea me too
<wasutton3>
i have a copy of all the partitions that SHOULD be there, but no way of getting them onto the nand
<smaeul>
hmm, does your u-boot have a sunxi_nand command?
<wasutton3>
nope
<wasutton3>
sunxi_bmp_info- manipulate BMP image data
<wasutton3>
sunxi_bmp_show- manipulate BMP image data
<wasutton3>
thats all ive got
<wasutton3>
for sunxi
<smaeul>
oh, sunxi_flash is probably it. but you might not need even that if fastboot works
<wasutton3>
sunxi#?
<wasutton3>
boota - boota - boot android bootimg from memory
<wasutton3>
base - print or set address offset
<wasutton3>
? - alias for 'help'
<wasutton3>
boot - boot default, i.e., run 'bootcmd'
<wasutton3>
bootd - boot default, i.e., run 'bootcmd'
<smaeul>
have you tried something like `fastboot flash nanda nanda.img` ?
<smaeul>
there's BSP U-Boot source code floating around, so you could see how the fastboot partitions map to the NAND partitions (which I guess was your actual question)
<wasutton3>
bootm - boot application image from memory
<wasutton3>
bootp - boot image via network using BOOTP/TFTP protocol
<wasutton3>
cmp - memory compare
<wasutton3>
check_userdata- check user data
<wasutton3>
cp - memory copy
<wasutton3>
crc32 - checksum calculation
<wasutton3>
delay_test- do a delay test
<wasutton3>
efex - run to efex
<wasutton3>
efex_test- do a usb efex test
<wasutton3>
env - environment handling commands
<wasutton3>
erase_userdata- check user data
<wasutton3>
exit - exit script
<wasutton3>
false - do nothing, unsuccessfully
<wasutton3>
fastboot_test- do a sprite test
<wasutton3>
fatinfo - print information about filesystem
<wasutton3>
fatdown - download data to a dos filesystem
<wasutton3>
fatload - load binary file from a dos filesystem
<wasutton3>
fatls - list files in a directory (default /)
<wasutton3>
go - start application at address 'addr'
<wasutton3>
help - print command description/usage
<wasutton3>
key_test- Test the key value
<wasutton3>
loop - infinite loop on address range
<wasutton3>
logo - show default logo
<wasutton3>
md - memory display
<wasutton3>
mass_test- do a usb mass test
<wasutton3>
memcpy_test- do a memcpy test
<wasutton3>
memtester- start application at address 'addr'
<smaeul>
please don't paste tons of lines of text
<wasutton3>
mm - memory modify (auto-incrementing address)
<wasutton3>
mmc - MMC sub system
<wasutton3>
mmcinfo - display MMC info
<wasutton3>
mtest - simple RAM read/write test
<wasutton3>
mw - memory write (fill)
<wasutton3>
nm - memory modify (constant address)
<wasutton3>
nfs - boot image via network using NFS protocol
<wasutton3>
power_probe- probe the axp output
<wasutton3>
ping - send ICMP ECHO_REQUEST to network host
<wasutton3>
printenv- print environment variables
<wasutton3>
pst - read data from secure storageerase flag in secure storage
<wasutton3>
recovery- sunxi recovery function
<wasutton3>
reset - Perform RESET of the CPU
<wasutton3>
run - run commands in an environment variable
<wasutton3>
save_userdata- save user data
<wasutton3>
saveenv - save environment variables to persistent storage
<wasutton3>
savecfg - save sys_config into flash if you execute command setcfg
<wasutton3>
screen_char- show default screen chars
<wasutton3>
setenv - set environment variables
<wasutton3>
setcfg - modify sys_config.fex
<wasutton3>
shutdown- shutdown the system
<wasutton3>
showvar - print local hushshell variables
<wasutton3>
sprite_test- do a sprite test
<wasutton3>
sprite_recovery- one key sprite recovery
<wasutton3>
standby - run to boot standby
<wasutton3>
sunxi_bmp_info- manipulate BMP image data
<wasutton3>
sunxi_bmp_show- manipulate BMP image data