00:29 <smaeul> apritzel: are you using $fdtcontroladdr?

00:29 <apritzel> yes

00:30 <smaeul> and TF-A reports that SCPI is in use and it changed the DTB?

00:31 <apritzel> just: SCP/INF: Crust v0.5.3\nINFO: PSCI: Suspend is available via SCPI

00:33 <apritzel> next line is then INFO: BL31: Preparing for EL3 exit to normal world

00:35 <apritzel> I see sunxi_idle_states.o, but don't find "cpu-sleep" or "cluster-sleep" in the output of strings on the final binary or .elf file

00:41 <smaeul> apritzel: hmm, weird. I'm running 2f5eaf2bd6efc1488334fbddfed36b1c0aac4a87 (that exact commit) on Pine64-LTS, and I do see those in the binary, and `fdt addr $fdtcontroladdr; fdt print /cpus` prints the expected contents

00:44 <smaeul> actually I see that the phandle values in the cpu-idle-states property are off by one, but nothing is missing

01:21 <smaeul> apritzel: did you build with SUNXI_AMEND_DTB=1 ? It's not the default. You should see "INFO: Changed devicetree." as the last line from TF-A.

14:32 <kuba2k2> uhmm, a quick question: how on Earth does U-Boot detect my exact NAND part number? I've searched the entire source code, as well as the resulting binary file and there's no mention of that specific (or even any similar) string whatsoever (Micron MT29F32G08CBACA3W)

14:32 <jakllsch> probably by JEDEC ID numbers

14:33 <kuba2k2> do you mean that the NAND chip has the model number written somewhere in it? (I don't mean any IDs, I mean literally the model number as a readable string)

14:34 <jakllsch> no, I mean the chip isn't identified to software using a string

14:35 <jakllsch> (it's identified by binary numbers)

14:35 <kuba2k2> I'm aware of that. My question then is, how is the software (U-boot) able to print out a string of the model number?

14:35 <jakllsch> lookup table somewhere

14:35 <kuba2k2> the source code doesn't contain this model number in nand_ids.c, or anywhere else

14:36 <jakllsch> are you sure you're looking at the sources to your u-boot build?

14:36 <kuba2k2> yes, the exact sources that I used to build this image just yesterday

14:39 <kuba2k2> I grepped the entire codebase for "MT29F32" and for "CBACA", case insensitive, and found nothing

14:40 <jakllsch> the string could be constructetd

14:48 <jakllsch> maybe it's printed by something that's not u-boot?

14:50 <jakllsch> can you show the surrounding messages?

14:55 <kuba2k2> NAND: device found, Manufacturer ID: 0x2c, Chip ID: 0x68

14:55 <kuba2k2> Micron MT29F32G08CBACA3W

14:55 <kuba2k2> 4096 MiB, MLC, erase size: 1024 KiB, page size: 4096, OOB size: 224

14:55 <kuba2k2> 4096 MiB

14:55 <kuba2k2> MMC: mmc@1c0f000: 0

14:55 <kuba2k2> Loading Environment from FAT... OK

14:56 <kuba2k2> so yeah, that's U-Boot

14:56 <kuba2k2> there's nothing else on the device

14:56 <jakllsch> oh, looks like it gets the string from the chip nand_onfi_params

14:56 <jakllsch> /* manufacturer information block */

14:56 <jakllsch> char manufacturer[12];

14:56 <jakllsch> char model[20];

14:57 <kuba2k2> ah, right. So the model is actually retrieved from the NAND itself at some point?

14:57 <jakllsch> yeah

14:57 <kuba2k2> huh, cool. Thanks, good to know!

14:58 <jakllsch> nand_flash_detect_onfi()

15:18 <jernej> kuba2k2, jakllsch: There is exact model number stored in chip, which can be retrieved by "Read parameter page" command.

15:19 <jernej> ah, you figured it out already

15:24 <kuba2k2> currently, I'm trying to figure out how does SPL detect the correct params for talking to the NAND.. like ECC

15:25 <kuba2k2> when I flash U-Boot through LiveSuit, SPL detects ecc_bytes as 32, which doesn't correspond to anything

15:26 <kuba2k2> when I flash U-boot from U-boot (as described in board/sunxi/README.nand) then it detects ecc_bytes=24, which looks more like it

15:26 <kuba2k2> in either case, reading the entire image just yields ECC errors and the image doesn't load and boot at all...