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
fraolt_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
fraolt has quit [Ping timeout: 480 seconds]
<apritzel> so indeed the Orange Pi Zero 3 boots mainline Linux v6.5-rc1, when supplied the right DTB
ftg has quit [Read error: Connection reset by peer]
<daschaos> yeah
<apritzel> just sent the DT patches to the list, please all help with review and testing, and any help with getting Ethernet to fully work is welcome
Danct12 has joined #linux-sunxi
jason123onirc has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
jason123onirc has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
vagrantc has quit [Ping timeout: 480 seconds]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
vagrantc has joined #linux-sunxi
montjoie has joined #linux-sunxi
montjoie has quit []
montjoie has joined #linux-sunxi
hentai has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
junari_ has joined #linux-sunxi
warpme has joined #linux-sunxi
mkazantsev has joined #linux-sunxi
junari__ has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
warpme has quit []
mkazantsev has quit [Quit: Leaving]
warpme has joined #linux-sunxi
fraolt_ is now known as fraolt
apritzel has joined #linux-sunxi
Okhunjon007 has joined #linux-sunxi
warpme has quit []
Okhunjon007 has quit [Remote host closed the connection]
junari_ has joined #linux-sunxi
junari__ has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
paulk has joined #linux-sunxi
paulk-bis has quit [Ping timeout: 480 seconds]
Danct12 has quit [Quit: WeeChat 4.0.2]
warpme has quit []
<apritzel> Does anyone know where to get an "official" image for the Orange Pi Zero 3? I just need some BSP based image to compare things and harvest the DRAM parameters, but the Google Drive doesn't allow downloading (anymore?) because of "download quota exceeded" ...
<Jookia> apritzel: what's the google drive?
<apritzel> the official download source as linked from the Orange Pi website, under Downloads
<Jookia> you want the android 12 src?
<apritzel> no, I need an image
<apritzel> something I can boot and log in to, to inspect registers
<Jookia> or will any do
<Jookia> like arch or debian
<apritzel> well, yes, but does downloading work for you? I get "quota exceeded"
<apritzel> arch or debian will be fine, but they are the same: no download possible
<Jookia> let me see
<gamiee> If quota exceeded, save it to your disk
<Jookia> yeah i've tried to download it twice so far but then the prompt disappeared. maybe firefox issue so far
<Jookia> ok yes it is downloading. do you have magic wormhole or croc?
<apritzel> same with Chrome for me, btw, it says "quote for this file" (Bookworm 6.1 server, though I tried others). Which one are you downloading atm?
<Jookia> i'm downloading all the orange pi os (arch) ones- there are three variants, one each for type of memory installed in the board. so all
fraolt has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
fraolt has joined #linux-sunxi
<wens> apritzel: if you have a google account, first copy the file to your drive, then download your copy
<wens> ^ workaround for the quota issue
<apritzel> wens: I see, thanks, though I don't have a Google account (trying to avoid companies wanting my data)
<apritzel> Jookia was so nice to send me the files (many thanks!), so my immediate need is satisfied ...
<Jookia> smuggling linux to those in need :)
<apritzel> yeah, indeed, it's a shame that this is necessary. And for a change I am even a paying customer of Orange Pi ;-)
junari__ has joined #linux-sunxi
junari_ has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
junari__ has quit [Remote host closed the connection]
stipa has joined #linux-sunxi
ItsKaitlyn03 has joined #linux-sunxi
<ItsKaitlyn03> So I have serial now, is it normal that eMMC does not boot?
<jakllsch> hm?
<ItsKaitlyn03> I have serial on my A133 tablet, and I even get output (albeit it outputs garbage??) and Android seems to refuse to boot
<ItsKaitlyn03> Is that normal??
<ItsKaitlyn03> I think I did something very bad maybe?
<ItsKaitlyn03> oh wow it looks like theres some feedback power coming from the allwinner
<ItsKaitlyn03> Cause I unplugged the USB and it was somehow still powered, scary
<ItsKaitlyn03> It looks like the linux kernel is using a different baud rate?
<ItsKaitlyn03> okay something is definitely wrong
<ItsKaitlyn03> okay yeah its unstable for some reason
<ItsKaitlyn03> wtf allwinner?
<ItsKaitlyn03> Now I'm getting "Can't find a good Boot1 copy in nand."
<apritzel> ItsKaitlyn03: feedback power from serial is normal, and it indeed sometimes allows some early boot, just with the power drawn from serial
<apritzel> better boards put a FET in line, to prevent that, but since this is a hacked up tablet, you can't expect that luxury ;-)
<ItsKaitlyn03> I do have a FET pad on it
<ItsKaitlyn03> It's right next to the GND, TX, RX pads
<apritzel> but it's not populated, right?
<ItsKaitlyn03> not entirely sure :) I did notice some components next to the TX/RX pads were not there
<apritzel> we have seen that before: https://linux-sunxi.org/Eachlink_H6_Mini#Adding_a_serial_port_.28might_void_warranty.3F.29
<ItsKaitlyn03> I assume it is not normal for the tablet to boot up immediately when plugging in my serial USB dongle
<ItsKaitlyn03> and then spew out corrupted text anyways
<apritzel> those broken up characters in that frequency and interspersed with proper output looks more like a stability problem, for instance in the cable or interference or something
<apritzel> also keep in mind that there is only little power coming in, so boot without proper power will stop at some point with with weird errors, due to undervolting
<apritzel> changing to complete garbage after a while (when the kernel switches away from the early console) is indeed mostly due to wrong baudrate
<apritzel> which most often is due to clock problems
<ItsKaitlyn03> ah so the board is actually undervolted so badly that its not initializing the hardware correctly
<ItsKaitlyn03> that makes sense
<apritzel> so the kernel programs everything believing it's 115200, but some clock rate does not match what the kernel thinks it is, so the calculation is wrong and thus the actual baudrate
<ItsKaitlyn03> yeah now I'm trying to get it going again and I think its extremely unstable, as it's just saying boot1 can't be found and its failing to init eMMC
<ItsKaitlyn03> soooo
<apritzel> yes, you even get those effect with bad USB power supplies: U-Boot and early kernel works, and when the secondaries come up or the frequency is bumped, the board hangs
<ItsKaitlyn03> okay yeah that FET is missing, as well as some resistor I think
<apritzel> lets just hope you didn't mess up the NAND, I think that can happen by just reading without fixing up the read disturbance effects
<apritzel> ... mess up the NAND *content* ...
<ItsKaitlyn03> Thankfully I do have backups of that
<ItsKaitlyn03> yeah I think the NAND content is screwed
<ItsKaitlyn03> unplugged everything and no boot
<ItsKaitlyn03> oops
<ItsKaitlyn03> never mind it just randomly booted
<ItsKaitlyn03> alright yep, it's missing a FET
<ItsKaitlyn03> there is also a FEL pad next to the RX/TX/GND pads interestingly
<ItsKaitlyn03> so since TX is screwed on this device, should I get a resistor?
<apritzel> since you see *some* valid output, I'd think the missing FET just affects RX, so when you want to type something
<ItsKaitlyn03> let me see what happens if i unplug RX
<ItsKaitlyn03> YEP
<ItsKaitlyn03> it was RX on the device
<ItsKaitlyn03> now I have fully working serial output from the device, just not RX
<ItsKaitlyn03> so RX works (TX on the device board afaik)
<ItsKaitlyn03> but TX is broken (RX on the device board?)
<ItsKaitlyn03> so should I bridge those 2 pads?
<ItsKaitlyn03> on the FET and it should work?
<apritzel> well, do you see a prompt so that you can verify it?
<ItsKaitlyn03> nope, I might just leave RX alone on the device board for now until I get to something that desperately needs it(?)
<apritzel> yes, eventually you might need it, but for now just TX is sufficient
warpme has quit []
ftg has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
<ItsKaitlyn03> okay so, I built your u-boot branch (a133-WIP, my first time actually building u-boot). is "binman: Filename 'bl31.bin' not found in input path (.,.,./board/sunxi,arch/arm/dts)" a normal error? lol
<ItsKaitlyn03> seems like the build completed fine though
<ItsKaitlyn03> it seems like theres multiple bin files, which one would I want to use?
vagrantc has joined #linux-sunxi
<ItsKaitlyn03> oh, I need trusted firmware
macromorgan has quit [Quit: Leaving]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has quit []
<apritzel> ItsKaitlyn03: doc/board/allwinner/sunxi.rst has all the details
<apritzel> but I know, no one actually reads documentation before trying things ;-)
<apritzel> next problem is that there is no Trusted Firmware port for the A133
<apritzel> but you can skip that for now, at the price of losing the secondary CPUs in Linux
<ItsKaitlyn03> ah i tried running it with trusted firmware
<ItsKaitlyn03> oops.
<ItsKaitlyn03> h616 trusted firm to be exact
<ItsKaitlyn03> that's probably why I got zero serial output
<ItsKaitlyn03> can I just set BL31 to /dev/null as well?
<apritzel> not that easily, as the SPL will still branch to that entry point
<apritzel> you are loading via FEL, right?
<apritzel> then you can execute the SPL, load U-Boot proper to 0x4a000000 and start execution there:
<apritzel> $ sunxi-fel spl spl/u-boot-spl.bin write 0x4a000000 u-boot-dtb.bin reset64 0x4a000000
<ItsKaitlyn03> ah yeah im using the other guys modified sunxi-tools for A133 https://github.com/aodzip/sunxi-tools-Allwinner-A133
<ItsKaitlyn03> "SPL: eGON header is not found"
<ItsKaitlyn03> o-oh
<ItsKaitlyn03> unless i need to sunxi mkimage it
<apritzel> oh sorry, it should be spl/sunxi-spl.bin
<ItsKaitlyn03> ah
<apritzel> that's the binary that's mkimage created
<apritzel> typed that line more from the top of my head ...
<ItsKaitlyn03> ah, I get the vibe I probably shouldn't be using sunxi tools from windows "usb_bulk_send() ERROR -7: Operation timed out"
<ItsKaitlyn03> oops
<apritzel> that's normally alright
<apritzel> you just need to make sure you are in FEL mode, and that the SPL works correctly and returns to FEL
<ItsKaitlyn03> I was in fel mode as i did list the device using sunxi-tools (I used zadig)
<apritzel> which isn't exactly straight-forward for an unsupported SoC
<apritzel> if you have a boot0 copy from SD card or NAND or eMMC, you might be able to use that as an SPL replacement
<apritzel> many versions I have seen go to FEL when they cannot find their hardcoded payload (so an SD card boot0 loaded via FEL without an SD card inserted, for instance)
<ItsKaitlyn03> should i just send the uboot SPL then and see if it returns back to FEL?
<ItsKaitlyn03> w/o writing the uboot w/ dtb into memory
<apritzel> you can of course try, but it won't work, unless you have the DRAM controller initialised in the SPL
<ItsKaitlyn03> ah
<apritzel> missing DRAM init is the one most annoying and hard blocker during new SoC enablement
<apritzel> that's why I recommend piggy backing on some BSP based DRAM init for the beginning
<apritzel> if you can extract boot0 from the eMMC, you can try to write just that to sector 16 of an SD card, and see if that drops you into FEL (what I wrote above: missing boot0 payload)
<apritzel> though it might just find the rest on the eMMC and proceed with normal boot
<ItsKaitlyn03> i assume if it drops me into FEL DRAM will be init?
<apritzel> if you have some time, patience, and experience, you can sabotage boot0 to deliberately return to FEL
<apritzel> you should see the DRAM init messages on the serial
<ItsKaitlyn03> ah, I do have some experience with IDA. I could probably hack something together, I assume I just want boot0 to run enough to init DRAM?
<apritzel> exactly
<apritzel> what I do is to look around for code that starts looking for U-Boot on the SD card
<apritzel> then overwrite this with something like "mov r0, 0x20; br x0"
<ItsKaitlyn03> is boot0 the "bootloader_a/b" partition on android tablets?
<ItsKaitlyn03> or do I need to go to a more lower level
<ItsKaitlyn03> cause I can grab bootloader (in fact I already have it dumped)
<apritzel> the eMMC boot0 starts on sector 16 of the eMMC block device
<apritzel> if you look at it with a hexeditor, you should see the "eGON.BT0" signature, at offset 0x4 (the first four byte are a branch instruction)
<apritzel> offset 0x10 tells you the length of boot0
<ItsKaitlyn03> got it, so I should dump the first few bytes of boot0 and then using that read the entirety of it?
<apritzel> that's the universal ("eGON") format the (mask programmed) BROM looks for, and so far that's been the same for all Allwinner SoCs
<apritzel> yes
<apritzel> if you have some image files, you can also scan for this signature in there, it that's easier
<apritzel> *if* that's easier
<ItsKaitlyn03> oh i do indeed have a phoenix image file for this tablet
<ItsKaitlyn03> the original ROM
<apritzel> yes, that is a container format, so it's wrapped, but checking for the signature should work anyways
<ItsKaitlyn03> the first eGON header i find is at 0x31c00
<ItsKaitlyn03> then after that egon header theres another egon
<ItsKaitlyn03> then theres uboot
<ItsKaitlyn03> boot0 is called sboot on this
<ItsKaitlyn03> so sboot is probably the initial thing loaded
<apritzel> stay strong, don't get lured into the Allwinner world of booting images and terms and formats, that's all a big misguided distraction
<ItsKaitlyn03> i feel like they have 1 million terms to call one thing lol
<apritzel> all you need is that eGON image, that's all that counts, because that's what the BootROM needs
<apritzel> the rest is Allwinner software invention which you can mostly ignore
<ItsKaitlyn03> yeah, I have the eGON image now (sboot), how would I go about putting it on an SD card (on windows), especially if i dont have relatively easy access to dd
<apritzel> well, that's the point where you make your like unnecessarily complicated by using Windows ;-)
<apritzel> you could pad that up *at the front* with 8KB (16 sectors) of something, then try one of those SD card image writing tools
<ItsKaitlyn03> yeah I was going to do that and see if that worked
<apritzel> so that the eGON signature eventually lands at sector 16
<apritzel> just be warned that this overwrites the partition table of the SD card
<ItsKaitlyn03> makes sense
<ItsKaitlyn03> so make an image file which has the sunxi image starting at 0x2000?
<apritzel> yes
<apritzel> just keep in mind that's a raw image file, so nothing that get flashed with some Allwinner tool
<ItsKaitlyn03> okay so it seems like it just continues booting
<apritzel> yeah, not surprising, since probably all images are made for the eMMC
<ItsKaitlyn03> well time to break sboot
<ItsKaitlyn03> i already am loading it in IDA
<apritzel> you could hack the eMMC, by clearing some sectors, so that boot0 won't find its payload
<ItsKaitlyn03> so basically write 0's to the uboot header?
<apritzel> for instance
stipa is now known as Guest7521
stipa has joined #linux-sunxi
Guest7521 has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]