ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
mansr has quit [Ping timeout: 480 seconds]
<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 has quit [Ping timeout: 480 seconds]
hentai has quit [Quit: SIGTERM]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
mansr has joined #linux-sunxi
junari has joined #linux-sunxi
apritzel has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
chewitt has joined #linux-sunxi
Namidairo has quit [Quit: ZNC - https://znc.in]
Namidairo has joined #linux-sunxi
apritzel has joined #linux-sunxi
<warpme> apritzel: fyi: it looks mine zero3 board needs dram vdd increase to 1150mV. WIth this it looks i have stable operation (tested few hours of hd live tv playback with hw video decoding + opengl based deinterlacing). FYI: this DT: https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.4/files/0636-arm64-dts-allwinner-h618-add-OrangePI-Zero3.patch gives me working: sd, eth, usb, hdmi, gpu, audio, bt, wifi, cec, ths
vveapon has joined #linux-sunxi
<warpme> dmesg is like this: https://termbin.com/iqg8g
ShaneonConduitrs[m] has quit []
Newbyte has quit []
DanielakaCyReVolt[m] has quit []
Tooniis[m] has quit []
exkc has quit []
sajattack[m] has quit [Quit: Bridge terminating on SIGTERM]
psydroid[m] has quit []
AntoniAloyTorrens[m]1 has quit []
chuang[m] has quit []
insep has quit []
vulpes2[m] has quit [Quit: Bridge terminating on SIGTERM]
rsglobal[m] has quit []
pgwipeout[m] has quit []
aerospace[m] has quit []
obbardc has quit [Write error: connection closed]
MattTrescott[m] has quit [Write error: connection closed]
cperon has quit [Write error: connection closed]
JuniorJPDJ has quit [Write error: connection closed]
movedon5b2z4xywybidzannet[m] has quit [Write error: connection closed]
ungeskriptet has quit [Write error: connection closed]
KAmlogicAllwinnerRockchipMedia has quit [Write error: connection closed]
DasChaos1 has quit [Write error: connection closed]
aperezdc has quit [Write error: connection closed]
mripard has quit [Write error: connection closed]
dittid[m] has quit []
JosephWatson[m] has quit []
<warpme> fyi: if anybody want to play with archlinux on opi zero3 (with not always booting leeboby uboot) - test image is here: https://github.com/warpme/miniarch/releases/download/20230531-6.3.5-g66a40f5ba/MiniArch-20230718-6.4.8-board-h618.orangepi_zero3-SD-Image.img.xz
<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
<warpme> iirc tx/rx delays i took from bsp
<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 ...
<DarkNeutrino> Hmmm fair
DanielakaCyReVolt[m] has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
<warpme> apritzel: fyi: for speedbin support on h616 im using code like this: https://github.com/warpme/minimyth2/blob/02f6923aa22ccee2df7be99100a1e4e9928cd238/script/kernel/linux-6.4/files/0601-drivers-thermal-allwinner-add-h616-ths-support.patch When all works well it gives in dmesg "sun50i-cpufreq-nvmem: will use speed0 CPU OPPs"
<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....
indy has quit [Ping timeout: 480 seconds]
indy_ has joined #linux-sunxi
paulk-bis has quit []
paulk has joined #linux-sunxi
indy has joined #linux-sunxi
indy_ has quit [Ping timeout: 480 seconds]
sunshavi has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
<jernej> warpme: be aware there was a serious bug in thermal zones handling, so patch https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ac4436a5b20e0ef1f608a9ef46c08d5d142f8da6 is needed unless you run 6.4.8
Guest7752 has quit []
Danct12 has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
warpme has quit []
juri_ has joined #linux-sunxi
juri__ has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
kuba2k2 has quit [Ping timeout: 480 seconds]
wasutton3 has joined #linux-sunxi
<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_boot_signature- sunxi_boot_signature sub-system
<wasutton3> sunxi_flash- sunxi_flash sub-system
<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
<wasutton3> sunxi_boot_signature- sunxi_boot_signature sub-system
<wasutton3> sunxi_flash- sunxi_flash sub-system
<wasutton3> sys_config- show the sys config value
<wasutton3> test - minimal test like /bin/sh
<wasutton3> tftpboot- boot image via network using TFTP protocol
<wasutton3> timer_test- do a timer and int test
<wasutton3> timer_test1- do a timer and int test
<wasutton3> true - do nothing, successfully
<wasutton3> uburn - do a burn from boot
<wasutton3> version - print monitor, compiler and linker version
<wasutton3> that was supposed to be a debian pastebin
<wasutton3> bah, sorry for the spam
<wasutton3> smaeul, but fastboot doesn't want to give up its secrets as to what commands i can use
<wasutton3> smaeul, i know, my clipboard didn't copy the debian pastebin url like i thought it did
<smaeul> what secrets? like I said, you can find the source
<wasutton3> i mean valid fastboot commands. half of the standard ones i try return "FAILED (remote: 'fastboot oem operation fail: unknown cmd')"
<wasutton3> fastboot flash seems to work though, the question is mapping nanda-nandg to the partition names
<smaeul> it's not going to be an oem command. it'll be the normal `fastboot flash <partition>`
<wasutton3> right, but that was just an example
<wasutton3> right, i think i have the mapping of partition to backed up files
<wasutton3> ok. so i've definitely got the right partition data
<wasutton3> next step is to figure out how to get the right modifications made
hentai has joined #linux-sunxi
warpme has joined #linux-sunxi
<wasutton3> hmmm now its mentioning a partition doesn't exist, despite the boot log showing it
chewitt has quit [Ping timeout: 480 seconds]
<wasutton3> its named "UDISK" so im not sure if something else is going on
warpme has quit []
chewitt has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
<DarkNeutrino> Robot vacuum now thats impressive lol
<wasutton3> DarkNeutrino, hey, it works! and it runs linux
<DarkNeutrino> I mean thats to he expected that it runs linux in some form but that they left uboot console there lol
<wasutton3> they "left" the uboot console in there as in you short out some nand flash pins so it fails to boot
<wasutton3> they actually even blanked out the serial console too
chewitt has joined #linux-sunxi
<wasutton3> im just grateful this is my day job, or i'd be looking at a pile of e-waste
<wasutton3> embedded dev/hardware/linuxy things that is
<wasutton3> aaaand theres the big problem
<wasutton3> while they did everything right-ish, they did NOT change the mac address from unit to unit
chewitt has quit [Quit: Zzz..]
<wasutton3> not sure if thats buried in the firmware somewhere or if its burned into the wifi adapter
warpme has joined #linux-sunxi
JohnDoe_71Rus has quit []
warpme has quit []
macromorgan has quit [Quit: Leaving]
ftg has joined #linux-sunxi
<wasutton3> nope, burned into the adapter
juri__ has joined #linux-sunxi
juri_ has quit [Ping timeout: 480 seconds]
hentai has quit [Remote host closed the connection]
hentai has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
kuba2k2 has quit []
apritzel has joined #linux-sunxi
chewitt has joined #linux-sunxi
chewitt has quit [Ping timeout: 480 seconds]
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
<DarkNeutrino> Wow ok Mac address change is kinda a big oversight lol.
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
chewitt has joined #linux-sunxi