<juanesf91>
Tomorrow during the day I will try to update my local repository
Daanct12 has quit [Quit: WeeChat 4.6.1]
Daanct12 has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
juanesf91 has quit [Quit: Connection closed for inactivity]
gsz has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
inf has joined #linux-sunxi
apritzel has joined #linux-sunxi
dsimic has quit [Quit: Lost terminal]
dsimic has joined #linux-sunxi
<loki666>
apritzel: does your sunxi-fw tools works for a527 ?
<apritzel>
loki666: for the DRAM parameters you mean? It should, I think I got the parameters for the X96QPro+ TV box this way
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<apritzel>
does anyone else get RCU warnings on A523/T527 devices? They show up if I just let it sit idle for a few seconds. On v6.15-rc1 + jernej's TF-A branch
<loki666>
apritzel: yes the DRAM params, on which column ?
<loki666>
anyway... the handheld tokyovigilante and I got will probably not be hackable at all... there is no UART port
<apritzel>
loki666: I used the H616 column, that worked for me
<loki666>
ok thanks
<apritzel>
oh I see, without a UART that's basically a long way out. Are there no pads at all?
<loki666>
none that I could identify no... didn't find group of 3/4 pads together
<loki666>
we might get access to the source code, but it will probably a 5.15 BSP crap
<loki666>
if they didn't lock the thing with a secure rom, currently it boot on the internal eMMC, not even sure if it can boot on the SD
<loki666>
but without a dts... it's dead
<loki666>
it's sad, because the device is nice, build quality is good
<apritzel>
loki666: can you use FEL somehow? Maybe try the fel-sdboot SD card method, to see if it still boots into the eMMC
<loki666>
I can try that, how does that works... there is no fel button
<apritzel>
if it still boots from eMMC, that could either mean the SD card is not MMC0, or that the device has secure-boot enabled
<loki666>
I saw your GPU pd patch got merged, still no activity on my V2 ... should I cry in their irc ?
<apritzel>
loki666: you sent it towards the end of the merge window, it might have been overlooked then. Maybe reply to the cover letter on Monday, and ask for the status
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
<loki666>
Ok
apritzel has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
warpme has quit []
gsz has joined #linux-sunxi
Daanct12 has quit [Quit: WeeChat 4.6.1]
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
<dlan>
apritzel: I've not seen RCU warning, but got weird signal kill/segfault issue
Kirby64 has joined #linux-sunxi
<Kirby64>
Alright, I'm back at my A133 u-boot issues... is there a way to extract the PMIC voltage settings from an AW boot0? the hex seems to reference ldos if I stare at it, but it's all gibberish for how it's actually formatted
<Kirby64>
I'm suspecting my DRAM problems are coming from poorly set PMICs, perhaps. Not sure what else could be wrong at this point... unless someone thinks the a133 DRAM init code is broken
<Kirby64>
Maybe worth someone double-checking my make config file to see if there's any stupid mistakes here?
<apritzel>
Kirby64: so you definitely need to set the DRAM PMIC rail to the voltage that your DRAM requires, so for instance 1.1V for LPDDR4
<apritzel>
in the past this was ensured by some PMIC fuses or strap resistors, but recently the SPL needs to take care of this
<Kirby64>
Right. So, I'd accomplish this presumably by modifying the CONFIG_AXP_ settings somewhere?
<Kirby64>
I guess I'm just not sure which ones to modify, since it's unclear to me how this is actually pinned out on the device
<apritzel>
yes, CONFIG_AXP_DCDCx_VOLT=1100 for instance
<apritzel>
whats your PMIC, exactly? It's not a AXP707, right?
<Kirby64>
I borrowed the config from MasterR3C0RD which had 'CONFIG_AXP_DCDC5_VOLT' listed, but also that config was from a different PMIC
<Kirby64>
it's an AXP305
cnxsoft has quit [Ping timeout: 480 seconds]
<Kirby64>
(or, AXP305B I guess, but same cheap afaict)
<Kirby64>
same chip*
<Kirby64>
It might very well be the same chip as an AXP805, too, actually.
<apritzel>
we assume the AXP805 and AXP305 are the same, at least software wise
<apritzel>
so the AXP805 is mostly used on boards with the H6, and DRAM there is on DCDCE (or DCDC5 in U-Boot lingo), BUT:
<apritzel>
on H616 board we see the AXP305, and DRAM there is on DCDCD / DCDC4
<apritzel>
Kirby64: do you get a BSP boot log on the UART? Often there is some hint of the PMIC setup
<Kirby64>
oh goodie, mysteries
<Kirby64>
I do not, unfortunately. UART is totally dead on the BSP boot
<Kirby64>
Seems like best course of action would be to replace the pmic portion of my dts with an ax305/805 model (h616-orangepi-zero2 looks about right) then play with my config options?
<apritzel>
problem is PMIC experiments are risky, since you might apply the wrong voltage
<Kirby64>
well, I've already apparently been doing this
<apritzel>
does FEL mode work? Often a SoC/watchdog reset keeps the PMIC set up, so you can try to dump the PMIC registers using FEL
<Kirby64>
oh, yeah. That could work.
<Kirby64>
FEL works great on this, and like I mentioned previously I can boot normally then reset directly into FEL and it seems to keep all register states
<Kirby64>
that's how I got the BSP boot0
<Kirby64>
dumped it straight out of SRAM
<Kirby64>
How would I go about dumping PMIC registers via FEL?
<apritzel>
as in: boot the BSP, somehow reset, make sure FEL triggers (FEL button? FEL SD card), then load a hacked SPL which dumps the PMIC registers (in drivers/power/axp_spl.c)
<Kirby64>
yup. I can do that for sure. I've got 'FEL' and 'RESET' buttons on my board
<Kirby64>
and a combo of normal boot followed by FEL+RESET gets me into FEL just great while keeping the RAM states
dsimic is now known as Guest14553
dsimic has joined #linux-sunxi
<apritzel>
so do some pmic_bus_read() calls in axp_init()
<apritzel>
then just printf the results
<apritzel>
the registers in question are 0x12-0x16, compare the axp_spl_dcdc_regulators[] array in the AXP305 section in that same file
Guest14553 has quit [Ping timeout: 480 seconds]
<apritzel>
do you know which type of DRAM it is? DDR3? LPDDR4?
<Kirby64>
LPDDR4
<Kirby64>
I take it no pre-done fork of this anywhere to help out? Gonna be me adding debugs throughout this file?
apritzel has quit [Ping timeout: 480 seconds]
<Kirby64>
I guess as simple as adding pmic_bus_read() right before the init and hit all of those regs... hmm, on it
Kirby64 has quit [Ping timeout: 480 seconds]
juanesf91 has joined #linux-sunxi
<jernej>
apritzel: regarding RSB to I2C patch - boards were always designed with I2C in mind, since that's what BSP used at the time. I would say RSB is a gamble, which works most of the times, but based on that bug report, not always. That's way it's safer to have I2C. And obviously, I2C was used before switching to RSB, so it is tested.
<jernej>
I quickly ruled out RSB on OrangePi 3 LTS when working on DT, it didn't always worked.
<montjoie>
fun debug, a83t crypto fail with multi_v7 defconfig but not with sunxi_defconfig...
BroderTuck has joined #linux-sunxi
<BroderTuck>
montjoie: Sounds fun indeed...
<BroderTuck>
Anyway, if the maxio thing can be driven with a generic phy driver, we should be closer to having working ethernet on the proplus. Would the GMAC2000 support be better off as a new driver or included in the current one?
<jernej>
Lightsword: ask me on monday or tuesday :)
<jernej>
but h616 should have ac300
<jernej>
iirc, that doesn't matter much, basic configuration and eth phy should be the same as on ac200
<Lightsword>
jernej, well apparently h616 has a random mix of ac200 and ac300, that address is an efuse that is used by BSP drivers to determine if it's an AC200 or AC300 AFAIU, I scanned over a dozen h616 boards and it's a completely random mix of AC200 and AC300 it seems
<jernej>
but does that matter?
<Lightsword>
jernej, I don't think they are the same, I mean there are some similarities but AC300 is not configured using i2c at all it appears
<Lightsword>
jernej, my device I've been testing on based on the efuse is an AC300, and commenting out essentially all the i2c3 initialization stuff in my uboot patch does not prevent it from functioning
<jernej>
Lightsword: can you point me to BSP driver which checks for ac200 vs. ac300? I can't find it right now.
<jernej>
hm... I have two BSPs for H616, one based on v4.9 and other on v5.4. Only newer has this code that you linked.
<Lightsword>
jernej, hmm, I've seen this code in 4.9 BSP's as well...but it may not have been there originally
<Lightsword>
jernej, do you have multiple h616 devices?
<jernej>
yes
<Lightsword>
jernej, was your ac300 driver tested on just one board or multiple?
<Lightsword>
I guess probably a good idea to check "devmem 0x0300622c 32" on all of them
<jernej>
don't remember honestly, it was some time ago
<Lightsword>
jernej, btw the AC200 datasheet mentions the TWI interface, while the AC300 has no mention at all
<jernej>
Lightsword: so, have you tried this driver on H616 with AC200?
<Lightsword>
jernej, no, I don't have physical access to any boards with efuses indicating they have AC200's, I only have remote access to them and they are running vendor firmware
<jernej>
do you have ac300 datasheet by any chance?
<jernej>
I see. Yes, that's for sure without MFD part and basically just ordinary ephy.
<jernej>
fun, technically same soc with different packages
<jernej>
I hope one type of board uses only one type of soc
apritzel has joined #linux-sunxi
<apritzel>
jernej: I think Lightsword's board are actually indicating the opposite :-(
<apritzel>
boards*
<Lightsword>
jernej, well no such luck it seems for my boards, even devices from similar batches appear to be completely mixed
<apritzel>
jernej: I was thinking we can maybe check this fuse in U-Boot and enable one or the other chain of nodes in the DT then
<Lightsword>
I need to figure out how to get a hold of an ac200 board physically, lol, all the ones I have access to appear to be in the middle of nowhere
<jernej>
apritzel: I was just typing that :)
<apritzel>
from the code Lightsword showed it looks like the AC300 controls gates and reset via MDIO registers
<apritzel>
which sounds a bit odd, since I would be thinking that you need them enabled *before* you can talk to the device
<apritzel>
Lightsword: thanks for the datasheet link!
<apritzel>
jernej: so I guess we take your PHY driver (which we thought was optional), and add the AC300 PHY bits
<apritzel>
just need to figure out whether the PHY ID is different, that would be of course the most elegant solution
<apritzel>
(though I somehow have the bad feeling they are using the same ID ...)
<apritzel>
well, that complicates things, since we now would need some driver or device that probes before the PHY and would reference the efuse
<apritzel>
Lightsword: this kind of "probing and see what happens" is quite unpopular in the kernel, and also we would need to model this in the DT, which sounds not only a challenge, but somehow artificial
<Kirby64>
apritzel: looks like that worked. I've got PMIC reg dumps that don't match defaults for 0x12-0x16
<Lightsword>
x-powers,ac200-ephy-ctl already references an efuse for calibration
<apritzel>
Kirby64: yes, looks like DCDCE/DCDC5 is 1.1V, so that sounds like what you are looking for
<Lightsword>
I'm thinking the mfd driver should reference the efuse that determines if it's an ac200 or ac300.
hazardchem has quit [Read error: Connection reset by peer]
<apritzel>
Lightsword: but ephy-ctl is an I2C device
hazardchem has joined #linux-sunxi
<apritzel>
and so is the MFD device, IIRC
<Kirby64>
forgive my ignorance here, but do I need to update the .dts file I'm using to match these settings as well? Right now my dts file has essentially no detail on the axp used
<Kirby64>
Not sure if that matters for getting u-boot up and running or not
<apritzel>
Kirby64: not for U-Boot, but you would need it eventually for the kernel
<Lightsword>
apritzel, yeah, I'm just thinking those drivers could have a efuse check and enodev bail out if it's not an AC200
<apritzel>
Kirby64: for now it's probably the safest to just ignore that
<Kirby64>
Roger. Yeah, I'm working through baby steps here. Figure once I get a dump of the actual firmware on-chip I can flesh out DTS as needed
<apritzel>
Lightsword: I get what you mean, but that sounds slightly too hackish for mainline, I'd say
<apritzel>
the idea of the DT is to tell the kernel exactly what is there, so it doesn't need to guess or probe for existence
<Lightsword>
apritzel, I vaguely recall running into a similar issue in the past with trying to autodetect i2c based touchscreens
<apritzel>
so this "there is some I2C device, or maybe not" probably raises some eyebrows
<apritzel>
and didn't you say that I2C communication timed out, so it's best avoided?
<Lightsword>
apritzel, to me it seems like device tree's lack of support for proper runtime hardware autodetection is kinda a design flaw as it seems perfectly normal to expect linux to be able to autodetect hardware components
<apritzel>
Kirby64: so you probably figured, but those voltages are 1.1V, 1.8V, 940mV, 1040mV, 1.1V
<apritzel>
the first is probably CPU, the third and fourth smell like VDD_SYS and GPU, not sure which is which
<Lightsword>
apritzel, it does time out, but if we have the efuse check before we try to communicate with the i2c device then we could just bail out before that's even an issue right?
<Kirby64>
Yup, already did the translation and got em burned into a config. Still failing the dram simple test though :(
<apritzel>
Kirby64: did the latest version of sunxi-fw detect multiple DRAM parameters?
<apritzel>
Kirby64: and btw: the A133 DRAM driver is very new, and basically mostly written to work on the few devices we had access to
<Kirby64>
I think so? It had a set of DRAM params that matched A133 and were LPDDR4
<Kirby64>
lemme find the pastebin of that we previously talked about
<apritzel>
Kirby64: ah, but that's still a single of parameters (just different views of it). Some A133 BSP contained different *sets* of parameters, and the BSP chose one of it at runtime
<Kirby64>
Ah. Secret parameters, lovely. How latest of sunxi-fw are we talking? That was 5 days ago which I believe I haven't seen anything newer since then
<apritzel>
Kirby64: what I merged when we talked earlier this week, which is basically MasterR3C0RD's branch - which I think you were using already
<Kirby64>
Yeah. Before I used that branch the A133 settings didn't even show up
<apritzel>
Lightsword: mmh, interesting, that still might not quite fit since the AC300 is not an I2C device
<Lightsword>
apritzel, yeah, I'm kinda wondering if this technique could somehow be adapted for efuse based probing
<apritzel>
Lightsword: well, keep digging, but I'd say we have the DT patching technique always as a fallback
<apritzel>
we could introduce some artificial platform device that just checks the efuse, then traverses down either of the two possible paths
<apritzel>
but that sounds, well artificial, and basically made up to satisfy Linux' driver model, which leaves a bitter taste
<Lightsword>
apritzel, btw I think there may be an issue in that we have to configure the same i2c3 pins for the AC200 and AC300, so that might cause some conflicts as well
<apritzel>
but didn't you say we don't need i2c for AC300 as well?
<apritzel>
this solution I just described would only activate I2C if the efuse indicates so
<Lightsword>
apritzel, well we don't need i2c communications, but I think the pin configuration is the same and was critical for both to initialize properly
<apritzel>
the Linux DT parser does not traverse to every child, only when the parent node tells it so, so we could completely mask the other one
<apritzel>
which would solve that problem
<Kirby64>
apritzel: more DRAM weirdness: should FEL time out if I try to read from 0x4000 0001, but not if I read from 0x4000 0000 ?
<Kirby64>
that seems... not right
<Kirby64>
(unless it's an aligned by 32-bit thing)
<apritzel>
read how? Indeed you need to mostly observe alignment, definitely when the MMU is off
<Kirby64>
via sunxi-fel readl
<Kirby64>
Yeah okay maybe it just broke when I read off alignment
<apritzel>
yes, readl uses "ldr" (deliberately, since that's mostly needed for MMIO), which requires 32-bit alignment
<apritzel>
sunxi-fel read should work with any address, since it's reading byte-by-byte, and you should be able to dump a whole range
<Kirby64>
Yeah, that's worked just fine in the past - how I got the boot0 dump from SRAM for instance
<apritzel>
(so "read", not "readl", mind that subtle difference)
<Kirby64>
The TF-A binary works now, but I'm still hanging when it attempts to reallocate to the top of RAM it looks like...
<apritzel>
Kirby64: are you still using the changed SPL address, for BSS? That was just for experiments, to isolate DRAM issues, so you should not keep it
<Kirby64>
Nope, I deleted that
<Kirby64>
(or, pulled it from config anyways)
<Kirby64>
I'm suspecting maybe the DRAM is not correctly being identified here. I have the datasheet for the DRAM, and the device addressing doesn't seem to match what the debug output shows despite both coming up with 2GiB
<Kirby64>
i.e., output from U-boot is: DRAM:Testing ranks = 1, 32-bit bus
<Kirby64>
cols = 10, rows = 15, banks = 3, bank groups = 0, ranks = 1, full width = 1
<Kirby64>
expected size: 2048 MB
<Kirby64>
Datasheet shows: ranks per channel: 2; number of banks per channel: 8
<Kirby64>
and number of channels is 2
<Kirby64>
At very least I'd think ranks should be 2?
<Kirby64>
unless I don't understand what cols, rows, banks, bank groups mean
<apritzel>
Kirby64: I think the A133 DRAM driver encodes ranks as bits, so ranks = 1 means 2 ranks, really
<apritzel>
Lightsword: that sounds a bit too involved, I think. What's your opposition against the "U-Boot patches the DT" solution?
<Kirby64>
Hm. Is there a decoder ring somewhere I could cross-check this? I guess banks = 3 would correspond to 8 (assuming 0 = 1, 1 = 2, 2 = 4, 3 = 8)
<Kirby64>
oh it's all 2^n....
<apritzel>
Kirby64: what does the datasheet say about rows and columns? There would be encoded in power of 2 in the driver as well, I think
<Kirby64>
rows per bank = 32768 (which is 2^15)
<apritzel>
exactly
<Kirby64>
columns = 64 per datasheet (which is not 2^10)
<apritzel>
times 16 bits?
<Kirby64>
Is that how that works?
<Kirby64>
Here's datasheet, for context. Page 2 has the table
<apritzel>
what's the organisation of one chip? Is it x16, x8, or x32?
<Kirby64>
lists x16 for row/column addressing I guess. But I'd think same would apply to rows if we're multiplying by 16
<apritzel>
so yes, it's by 16, so that would match
<apritzel>
no ;-)
<Kirby64>
I'll take your word for it ;)
<Kirby64>
Where does channels come into play? is that full width? Or just, implicit in 32-bit bus addresses two channels simultaneously?
<apritzel>
the two channels are interesting, I don't think we have seen this before
<Kirby64>
Yeah, and every one of these chips are two channel apparently...
<apritzel>
normally we see one x32 chip, or two x16 chips, or eight x4 chips, and so on
<apritzel>
unless it's only half width, but that's fortunately rare these days (as it leaves half of the performance on the table)
<Kirby64>
Wouldn't that essentially be transparent to the SoC?
<Kirby64>
i.e., 1 32x chip vs 2 16x chips
<Kirby64>
Basically just 2 16x chips in one package, no?
<apritzel>
well, somewhat, I think the parameters might slightly differ in each case
<apritzel>
and yeah, I wonder why you would want two channels, but each only 16 bits wide
<apritzel>
normally you use 16bits only if you want to save traces/complexity
<apritzel>
(or use smaller chips, maybe)
<Kirby64>
1 die, 3 separate parts I guess?
<Kirby64>
just package 1, 2, or 4 dies together
<apritzel>
well, maybe, but you have just a single chip, right?
<Kirby64>
correct
<apritzel>
we often see that, but then it's just a plain x32 chip
<apritzel>
dual-channel sounds more odd, maybe for special cases
<apritzel>
more odd => more expensive
<apritzel>
maybe like for two separate SoCs/controllers?
<Kirby64>
I dunno, I found the same chip on an AW 'reference' for the A133. Can't be that expensive haha
<apritzel>
interesting. I think it's not the same as one x32 chip, since most signals are separate, and I think just wiring them together might not work easily
<apritzel>
the AW BSP DRAM driver often supports many configurations and DRAM options, we typically just implement those that we encounter and can test
<Kirby64>
Hm. Any way for me to force it to run 16-bit and see if it starts working with only 1GB of RAM accessible?
<Kirby64>
Might be easy enough to try
<Kirby64>
No idea if that would work though
<apritzel>
dunno either, but as you say: worth a try
<apritzel>
Kirby64: btw: in the datasheet you see under "Row addresses": R[14:0] and under "Column addresses": [9:0], so there you have your 15 and 10
<Kirby64>
Yeah, I see that. I also saw the note: "The lower two column addresses (C0–C1) are assumed to be zero and are not transmitted on the CA bus."
<Kirby64>
Maybe that's normal for DRAM? since aligned by 32?
hentai has joined #linux-sunxi
<apritzel>
Kirby64: also: we have seen some probing and calibration lately for some DRAM configs, so the parameters stored in the image were not the ones eventually used, exactly
<apritzel>
if you isolate boot0, you could try to run this in isolation (via FEL). I have seen cases where boot0 went to FEL when it didn't find a follow-up image to load
<apritzel>
then you can dump some DRAM registers (via sunxi-fel readl), and deduce the parameters used
<apritzel>
if that doesn't work automatically, I had some luck in the past with hacking boot0 to return to FEL after DRAM init, but before the MMC access
<Lightsword>
apritzel, I'm not entirely opposed to the uboot method, I'm just thinking it might not be the cleanest way of handling this.
<apritzel>
I actually think it's by far the cleanest, but I see that having something entirely in Linux might be better
<apritzel>
I am more for having a little "hack" in U-Boot, which has device specific builds anyway, if that helps to keep the kernel clean (which is device agnostic)
<Lightsword>
apritzel, yeah, I guess I'm just thinking that device tree should be made a little more dynamic in general as autodetection is a pretty common use case as this isn't the first time I've run into this sort of limitation
<apritzel>
DT is actually there to avoid the kernel guessing and probing, since this creates all kinds of problem in a generic (single image) kernel
<apritzel>
in its origins the DT was actually generated on the fly by firmware, depending on "educated probing", so the OS could just go ahead and rely on its description
<apritzel>
so I think it's only fair if we mimic this, and we do this already: U-Boot adds DT nodes and properties, also TF-A does it in some cases
<apritzel>
and this pinephone patch I referenced the other day is a good example: that would have been painful to implement in Linux, and it would have also involved to create some artificial device that doesn't exist
sdfgsdfs has quit [Ping timeout: 480 seconds]
<Lightsword>
apritzel, but avoiding probing entirely isn't really practical with how a lot of hardware ends up being designed, I'm thinking a way to do this is to make the AC200 and AC300 depend on SID driver registers and have the SID driver use of_changeset_detach_node to conditionally detach the dependent nodes depending on values being read, not sure if that would work in practice
<apritzel>
that *might* be possible, but sounds quite convoluted, tbh. DT overlays *within* the kernel are rather odd, not sure they are widely used anyway. It's more a thing of: DT overlay applied by firmware, before the kernel gets to see it
<apritzel>
like those RPI hats thing: the RPi firmware knows how to probe safely for hats, and it then applies the overlays
<Lightsword>
apritzel, I don't think of_changeset_detach_node uses DT overlay, it's something newer I think designed for dynamic probing
<Lightsword>
like probing from within linux
<apritzel>
I might be wrong, but IIRC this is overlays applied *at kernel runtime*, isn't it?
<Lightsword>
apritzel, AFAIU it's analogous to uboot device tree patching, but done at kernel runtime
<apritzel>
Lightsword: but how would you trigger this, if not by an artificial DT node?
sdfgsdfs has joined #linux-sunxi
<Lightsword>
apritzel, in the SID driver I'm thinking via properties
<apritzel>
I think our problem is that there isn't such a nice natural parent device we could (ab)use
<apritzel>
each case on its own is clean: a special, but still regular PHY (with its own driver), vs. some I2C MFD devices
<Lightsword>
is not what's expected as configured under the SID child then the SID driver would simply remove the node depending on the specific efuse
<Lightsword>
so like AC200 and AC300 would depend on specific efuse nodes, and efuse would in turn search for dependencies and kill them based on a kill flag of some sort
<Kirby64>
apritzel: on isolating boot0, I believe I have a clean boot0 isolated. Do I just need to turn it into a .fex and load it via FEL for execution?
<apritzel>
Kirby64: try to just use "sunxi-fel spl" the boot0 binary
<apritzel>
Lightsword: sorry, but this all sounds quite involved and convoluted, when we could have a much easier and cleaner alternative, by making this U-Boot's problem
<apritzel>
and honestly, ChatGPT saying "yes, ... is clean, efficient and entirely feasible" doesn't mean it wouldn't be shot down in five minutes on the list ;-)
<apritzel>
Kirby64: this will probably not return to FEL, but it's worth a try. The other thing to try is write boot0 on an otherwise empty SD card, and see if that triggers FEL entry, after DRAM init
<apritzel>
Kirby64: oh, just thinking: I have seen boot0 images that would output on the PortF UART, so on the SD card pins
<apritzel>
loki666: which makes me think that this could be something for you as well: get something like this: https://www.sparkfun.com/sparkfun-microsd-sniffer.html and configure to use the CLK and CD pins on there
<apritzel>
this is how I got UART output on a tablet without opening it
<Lightsword>
apritzel, hmm, let me test this out, what I like about this approach is that it would even let us have boards with custom efuses defining hardware component presence entirely via device trees
<Kirby64>
apritzel: no SD card on this thing, at least none pinned out. Also, boot0 bin that I have says SPL checksum check failed?
<apritzel>
Kirby64: did you change something in it? Does it have the correct size?
<apritzel>
and you can correct it with a hex editor, sunxi-fw gives you the expected value. The checksum is at offset 0xc, so the last four bytes on the first line
<apritzel>
size is at offset 0x10, so first four bytes on the second line
<Kirby64>
Uh, it's entirely possible it's not quite the right size. It's exactly 64.0 KB but it might be expecting 64000 bytes?
<Kirby64>
cause remember I snipped this from a chunk of SRAM
<apritzel>
no, it's much more likely to be aligned to 8KB or so
<apritzel>
you don't need to guess, the size is in the file
<Kirby64>
Yeah, I think we went through this and that's how I got to 64KB. Size is at 0x10
<Kirby64>
And size is 00 00 01 00
<apritzel>
so yes, 64K exactly. so just correct the checksum and give it a try
<Kirby64>
they'd have an invalid checksum in the boot0? oh boy lol
<apritzel>
no, that wouldn't boot. Probably some code changed it in SRAM, before you dumped it
digetx has quit [Ping timeout: 480 seconds]
<Kirby64>
yeah, okay, fixing checksum seemed to do... something? It booted I guess?
<Kirby64>
But my PMIC registers are different now.
<Kirby64>
(after I re-run SPL)
<Kirby64>
PMIC REG 0x12: 0x1e
<Kirby64>
PMIC REG 0x13: 0x10
<Kirby64>
PMIC REG 0x14: 0x1e
<Kirby64>
PMIC REG 0x15: 0x16
<Kirby64>
PMIC REG 0x16: 0x0
<loki666>
apritzel: interesting... I confirmed to boot and enter fel with the fel SD card.. which is good, and t think it also enter fel with the Vol- and power button. As this is how I updated the eMMC with PhoenixSuit
<apritzel>
Kirby64: what's your AXP_yyy_POWER symbol? Check drivers/power/Kconfig to see that those AXP_DCDCy_VOLT symbols depend on certain regulator types
<apritzel>
if it's AXP305_POWER, then only CONFIG_AXP_DCDC4_VOLT would be considered