00:07 <tokyovigilante> apritzel: have done a bit more PMIC debugging based on your AXP717 driver, current failure seems to be in the ret = pmic_bus_read(AXP717_CHIP_VERSION, &axp_chip_id);

00:08 <tokyovigilante> call, I get PMIC: 0x8d, ret: 21504024 where 0x8d is the returned axp_chip_id, and 2150424 is the return code, which presumably represents a failure

00:09 <tokyovigilante> have set the I2C address to 0x68 which is mentioned in the manual, I see the 305/313 use 0x36.

00:13 <tokyovigilante> I do note there is no chip version mentioned in the register tables in the datasheet, so maybe this is just not supported?

00:31 <apritzel> tokyovigilante: the chip version is often not mentioned in many other manuals

00:31 <apritzel> but honestly you can just remove this check, we don't really need it

00:32 <apritzel> I adjusted this according to some AXP2202 BSP code somewhere, but if it's in the way, just get rid of it

00:48 <tokyovigilante> ok, thanks. Getting the same failures for setting DCD2/3, might try without the DCD2 voltage

00:48 <tokyovigilante> pmic_bus_init: ok

00:48 <tokyovigilante> axp_set_dcdc2: 21504024

00:48 <tokyovigilante> axp_set_dcdc3: 21504024

01:12 <apritzel> tokyovigilante: can you try to read those values back from I2C? To get an idea if the whole bus access is actually working?

02:26 <tokyovigilante> This is what's being written - DCDC3: writing 0x3c to reg 0x85

02:26 <tokyovigilante> but getting 21504024 as a return value

03:39 <tokyovigilante> "pmic_axp not enabled, using i2c_write" - could be a problem

03:44 <tokyovigilante> aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in region `.sram'

03:44 <tokyovigilante> nope

03:52 <tokyovigilante> so just to confirm, expectation would be using I2C in the SPL to write to the PMIC chip, using CONFIG_SPL_SYS_I2C_LEGACY?

04:25 <MoeIcenowy> jernej: well at that time I was just prototyping for DE2

05:12 <tokyovigilante> ok, clearly an I2C issue

05:12 <tokyovigilante> Error, wrong i2c adapter 0 max 0 possible

07:46 <tokyovigilante> ok, seem to have arrived at a working (no errors and no failed core voltage setting error) config using apritzel's AXP717 driver with an I2C address of 0x34. Doesn't boot past "DRAM: 1024 MiB" but I'll try enabling DCDC2 and see if that helps

10:02 <apritzel> tokyovigilante: ah, nice, so it was just the wrong I2C address? I was already wondering whether we need the 7-bit or 8-bit address (w/ or w/o the R/W bit)

19:41 <tokyovigilante> apritzel: yeah realised after your message that 0x34 << 1 is 0x68, with 0x68 quoted in the 717 datasheet

19:42 <tokyovigilante> The SPL seems to be successfully running now and has brought up the DRAM and brought the CPU up to speed, but not progressing to u-boot proper.

20:05 <apritzel> tokyovigilante: do you see any signs of TF-A? What's the last message you see? Trying to boot from MMC1?

20:25 <tokyovigilante> no the DRAM:1024 MiB message is the last one. I did have to make one small DT change to the one that was extracted from the vendor BSP to remove a MMC device which wasn't compiling, so maybe the SPL can't find the TF-A firmware to continue booting

20:28 <apritzel> with the vendor BSP you mean something like what macromorgan_ posted before, shipped with vendor's boot0 based firmware and some ancient kernel?

20:29 <apritzel> because that is most likely totally incompatible to mainline, to both what U-Boot and the kernel expect

20:30 <apritzel> so you cannot use that DT directly, you would need to copy something from close by (say OPi Zero3), and then adjust

20:30 <tokyovigilante> Correcy yeah

20:30 <tokyovigilante> *correct

20:30 <tokyovigilante> OK, there is a H618 TV box one as well. Will give those a try.

20:32 <apritzel> you could start with removing any PMIC nodes for now, and use fixed regulators, that should get you further at least

20:34 <apritzel> please note that the DT isn't really used at this stage, you should see this "Trying to boot from" message first

20:34 <apritzel> if it hangs right after the DRAM message, this could mean that the DRAM is not really working, still

20:35 <apritzel> because right after that, it will clear BSS, which is residing in DRAM already, and the MMC stack will use that memory

20:35 <apritzel> so maybe the DRAM setup was good enough the pass the driver init routine, but then isn't stable?

20:36 <apritzel> Can you do FEL booting? that is typically easier to debug, and I guess the SPL would be able to return to FEL in your case

20:37 <apritzel> if that device really has USB0 on that USB-C port, it should be dead easy to setup...

20:39 <tokyovigilante> Sure, that makes sense. I'm not sure whether the USB-C is just being used for power or whether the data lines are also connected, but can certaingly give it a go. I've added a bunch of debugging and certainly it does make it through the DRAM checks and as far as pushing the CPU up to full power, but I guess that is no guarantee.

20:42 <tokyovigilante> Will save me a lot of swapping out my uSD card if nothing else...

20:45 <apritzel> yeah, it does, I use it all the time, and it makes things much easier. You would need to write fel-sdboot.sunxi from sunxi-tools.git to an SD card, to get into FEL mode

20:45 <apritzel> (as I guess the board doesn't have a FEL button)

20:45 <apritzel> or sorry, actually much easier: just power on without any SD card, that should do the trick, too

20:46 <apritzel> then connect a host PC to a USB-A <-> USB-C cable and look for a new USB device popping up

20:54 <tokyovigilante> Ta, will give it a roll later on today.