00:01 <apritzel> megi: mmh, so this other patch is not needed at all? Even better! I will test it tomorrow

00:01 <megi> https://lkml.org/lkml/2021/6/6/422

00:02 <megi> it avoids some re-probes, but it's not necessary for boot success

00:03 <megi> sram patch

00:05 <apritzel> seems like I need to still dig deeper into fwlink then ... so the SRAM dependency wasn't the problem, I take it?

00:05 <megi> yes

01:32 <wens> seems like the non-standard RISC-V page table stuff won't get accepted

08:28 <apritzel> wens: so did AW really use reserved bits in the PTE in the D1?

08:39 <gediz> did anyone get encounter "xmalloc failed" errors on u-boot when rotation is enabled?

09:39 <gediz> i did not get the error anymore after disabling private libgcc.

09:44 <apritzel> gediz: what do you mean with "rotation"? Video output/screen rotation?

09:44 <apritzel> and which board/SoC is this?

09:50 <wens> apritzel: I don't know if it's the hardware or just the poster's workaround

11:00 <apritzel> wens: me neither, but it looks like AW did their usual job of "just somehow get this to work", and interpret standards and specs rather loosely ...

11:26 <gediz> apritzel: i meant video output rotation

11:26 <gediz> custom board with an A13

11:27 <gediz> i had a similar problem while trying to enable TTF fonts after DM_VIDEO is implemented for sunxi

11:28 <gediz> it's okay for now but i don't know how and why disabling private libgcc fixes this problem

11:33 <apritzel> gediz: ah, I think there are some generic issues with DM_VIDEO

11:33 <apritzel> amazingly this is not really up to par with the old video support

11:41 <gediz> i think it's acceptable. looks more complex compared to the legacy video implementation.

11:45 <apritzel> gediz: well, but if everyone is forced to move to DM_VIDEO, I would expect it to be at least not worse than the old one

11:46 <apritzel> but for instance the nifty logo support is missing, also there is no visible cursor

12:07 <gediz> i'm working on logo. going to send the patch.

12:08 <gediz> but yes, it may actually be considered as a slight regression in some terms.

12:35 <arnd> apritzel: it sounds like T-Head already had the reserved page table bits, but AW relied on using them, rather than making the SoC cache-coherent

15:04 <karlp> delightfull. been trying to diagnose some spi issues, works _without_ teh LA attached, gives bad results when the LA is attached.

16:11 <jernej> apritzel: do you think this patch is good to go? https://github.com/LibreELEC/LibreELEC.tv/blob/master/projects/Allwinner/devices/H5/patches/u-boot/0001-OrangePi-PC2-Update-defaults.patch

16:12 <jernej> I updated this according to schematics and vendor images...

16:47 <awenth> I'm attempting to build u-boot with toc0 (efuses set) for the Allwinner H5. I have an orangepi-zero-plus module. The build of smaeul's u-boot (toc0 branch) fails with: MKIMAGE spl/sunxi-spl.bin; make[1]: *** [scripts/Makefile.spl:424: spl/sunxi-spl.bin] Error 1. If I tell make to verbosely print the commands (make V=1) then it succeeds.... u-boot-sunxi-with-spl.bin is generated successfully. Has anybody else had this problem?

16:53 <apritzel> jernej: sure, send it to the list, and CC: the maintainers ;-)

16:53 <apritzel> jernej: out of curiosity: why do you set the voltage in U-Boot? Is that for older kernels or DTs?

16:56 <jernej> apritzel: well, there is regulator and it's supported by U-Boot already and other H3 boards do it, so...

16:56 <jernej> I enabled it :)

16:57 <jernej> to be honest, I don't know what is default sy8106a voltage

16:57 <awenth> If I look inside u-boot-sunxi-with-spl.bin, the file is padded with 0's up to 0x840. This is clearly invalid. Compared to a mainline u-boot build, the file has the identifier 'eGON.BT0' at the top of the file. I'll investigate more why 'MKIMAGE spl/sunxi-spl.bin' is failing

17:01 <jernej> apritzel: default (power up) voltage seems to be 0.68 V which is a bit low

17:02 <apritzel> oh, indeed

17:02 <jernej> ok, I'll send it and we can discuss it further there

17:03 <apritzel> jernej: even better I can just test it ;-)

17:55 <awenth> smaeul: Looking through the source of the u-boot repo, toc0 branch, I saw that sunxi_toc.0.c requires rotpk.pem. I've copied my key that I used to sign uart0_helloworld with to the root of the repo. Running "./tools/mkimage -T sunxi_toc0 -a 0x10060 -n "sun50i-h5-orangepi-zero-plus" -d spl/u-boot-spl.bin spl/sunxi-spl.bin" now prints: Allwinner TOC0 Image, 3 items, 32768 bytes ....; Writing the image to a SD card & booting it in the H5 with its e-fuses

17:55 <awenth> burned doesn't boot u-boot. It sequence falls through to USB/FEL. Is there any settings that must be changed under menuconfig?

19:30 <apritzel> awenth: so check the generated image: does it contain the "TOC0" magic at the beginning? (offset 0x4, I believe)

19:31 <apritzel> awenth: and did you write it to the right location of the SD card (assuming you use that)?

19:31 <apritzel> awenth: and of course the BROM should not boot normal eGON images anymore (have you checked that?)

19:37 <awenth> apritzel: I'm looking with a binary editor at the contents of u-boot-sunxi-with-spl.bin. From byte offset 0, it starts with the text: TOC0.GLH

19:37 <apritzel> awenth: offset 0?

19:38 <awenth> apritzel: If I compare this to uart0-helloworld-sdboot.toc0, it also starts with TOC0.GLH at byte 0 of the file

19:38 <apritzel> awenth: ah, OK, I thought it was offset 4

19:38 <awenth> I wrote it to SD card as: dd if=<file.toc0 of=/dev/sdc bs=1024 seek=8

19:38 <apritzel> so uart0.toc0 works?

19:39 <awenth> The signed sunxi-tools uart0-helloworld-sdboot.toc0 example boots correctly.

19:39 <awenth> However, using the same key during the build process of u-boot-sunxi-with-spl doesn't print anything on the UART during bootup.

19:40 <apritzel> awenth: did you burn a hash into the fuses?

19:40 <awenth> apritzel: yes. The contents of rotpk.bin was written with another tool into the fuses

19:41 <apritzel> and uart0-helloworld-sdboot.toc0 is generated via this egon2toc0.rb script?

19:42 <awenth> apretzel: I've used jemk_mktoc0.rb to convert from egon to toc0. The script was obtained from: https://gist.github.com/jemk/2abcab1359c4bce793679c5854062331

19:43 <apritzel> awenth: https://linux-sunxi.org/TOC0#TOC0_images_generation contains a link to an improved version, but that should produce similar results

19:44 <awenth> apretzel: I've seen it mentioned. I've already downloaded it but haven't yet used the tools.

19:45 <awenth> apretzel: Should this tool be able to convert a stock u-boot image to toc0? Or was there other work done by smaeul in his u-boot repo to get toc0 working for u-boot?

19:47 <apritzel> awenth: they are two different approaches: the script takes an existing eGON image and adds some code to make it compatible with the existing SPL code

19:47 <apritzel> as some aspects of the booting process are different beyond the mere loading

19:48 <apritzel> smaeul's version is the better solution, as it makes TOC0 a first class citizen in U-Boot's SPL

19:49 <awenth> apritzel: Apart from attaching a JTAG, is there any way to get debug info on why the boot process failed? My u-boot copy build clean after adding the rotpk.pem file to the root of the repo

19:50 <apritzel> awenth: I would run some experiments to narrow it down

19:50 <apritzel> you said it ends up in FEL?

19:51 <apritzel> that would point to the signature not being acknowledged by the BROM

19:51 <awenth> apritzel: yes.

19:52 <apritzel> on the working side you have uart0.toc0

19:52 <apritzel> so as a test I would try building a normal U-Boot eGON image, then using egon2toc.rb

19:53 <awenth> apritzel: I've just copied the contents of my rotpk.pem into egon2toc and converted the uart0 example to toc0. I want to test it quickly

19:54 <awenth> apritzel: The uart0 example did print "Booted from MMC0, entering an infinite loop' on previous runs

19:54 <apritzel> maybe the expected rotpk key format is different between mkimage and the ruby scripts?

19:55 <awenth> mmm

19:55 <awenth> could be.

19:55 <apritzel> I think I ever only tried this without an actual key hash in the fuses, which means the BROM accepts any key

19:55 <awenth> apritzel: A readme would have helped ;)

19:56 <apritzel> awenth: hey, this is code in development, and smaeul was just kind enough to share his (pretty neat) code ...

19:57 <awenth> apritzel: I know. I'm very gratefull for his effort.

19:57 <apritzel> the README is a stretch goal for the funding process ;-)

19:58 <apritzel> it would just be great if more people push for upstream: many people here show up, get their problems solved and then vanish :-(

20:01 <awenth> apritzel: Thats the nature of the beast... Who's maintaining linux-sunxi.org? I'm keeping a step-by-step guide for myself of what I've done sofar. It might help some noobs to get toc0 going from scratch

20:03 <apritzel> awenth: maintaining? It's a wiki. Just register (painless and anonymous), then edit the page

20:03 <awenth> apritzel: I've successfully booted uart0-helloworld-sdboot.toc0 as generated by egon2toc.rb, which was updated to contain my private key certificate file. Output on UART0: Hello from Allwinner H5!\nBooted from MMC0, entering an infinite loop!

20:04 <awenth> apritzel: I'm trying to convert my eGON u-boot image with the same script. It reports: The SPL is larger than 24K, so 'spl_addr' argument is required.

20:04 <awenth> apritzel: Do you know off-hand what the correct adress value is?

20:05 <apritzel> H5? 0x10000 I believe, but let me double check

20:06 <apritzel> yes, it is

20:06 <apritzel> abort "'spl_addr' argument must be either 0x0 or 0x10000."

20:07 <awenth> apritzel: Thx. Thats where SRAM A1 is mapped. On the 32-bit architectures its at 0x0

20:07 <apritzel> yes, exactly

20:10 <awenth> apritzel: Very interesting... I'm getting a uboot response: U-Boot SPL 2019.07 (Sep 03 2019 - 22:44:07 +0200)\nDRAM: 512 MiB\Trying to boot from MMC1

20:10 <apritzel> and it stops there?

20:12 <awenth> apritzel: Let me check with the eGON version on a board with unaltered efuses. I was expecting the board to do a boot countdown, but its hanging there

20:12 <apritzel> did you build from a clean U-Boot branch? or from smaeul's branch? You can't do the latter with that script, the two approaches bite each other (trying to fix the same thing twice)

20:13 <apritzel> if it stops there, it means it fails loading U-Boot proper, or your Trusted Firmware is wrong or missing

20:13 <awenth> apritzel: This is an old mainline u-boot that I've been using for ages on the H5

20:13 <apritzel> OK

20:14 <apritzel> yeah, if you have an "insecure" board, try the unchanged eGON there

20:14 <awenth> apritzel: This is the first successfull uboot response that I've seen sofar. the egon2toc.rb seems to be an inprovement over the older jemk_mktoc0.rb script

20:15 <apritzel> yeah, that's the main reason for egon2toc0's existence, I believe

20:16 <apritzel> but in the long run we want smaeul's version to work

20:16 <apritzel> because that blends in much better into the building process

20:17 <awenth> apritzel: The eGON version boots fine on an 'unsecured' board. It prints this immediately after 'Trying to boot from MMC1': NOTICE: BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)

20:17 <apritzel> OK, thanks for verifying that

20:19 <awenth> apritzel: Is the A2 ram the main system RAM or another onchip block? The 0x44000 address seems rather low. I wonder with the script complaining about the u-boot size and wanting another offset if everything works as expected in the egon2toc.rb script

20:20 <apritzel> SRAM A2 is the secure SRAM

20:20 <apritzel> it is where Trusted Firmware lives in

20:21 <apritzel> and the egon2toc.rb script uses this area temporarily for something, IIRC

20:21 <apritzel> but that shouldn't hurt, since it's only the SPL that loads TF-A, long after the script has done its magic

20:22 <apritzel> awenth: and if you look into the script, you'll see that it's really either 0x0 or 0x10000, so that's definitely the right value for the H5

20:24 <awenth> apritzel: Is there anything that needs to be set in the menuconfig as part of the configuration of smaeul's u-boot repo? The only setting that I've set was under SPL/TPL: Maximum size of SPL image: 0x20000

20:25 <awenth> apritzel: I've used 'make orangepi_zero_plus_defconfig' to create the initial .config. If he's been using another board, presumably a H6, then the default configs might have some important difference

20:30 <apritzel> I think the last patch hacks everything up so that it works (TM)

20:31 <apritzel> awenth: you could try to revert the H616 patch, not sure if that breaks the other SoCs

20:31 <awenth> apritzel: I've checked out his toc0 branch of his repo. Was it rolled up into his master already?

20:32 <awenth> apritzel: I'm actually a BZR fan, so GIT navigation has always been a bit bizare for me

20:32 <apritzel> "git show HEAD~1 | patch -p1 -R" is a quick hack to revert the penultimate patch

20:33 <apritzel> awenth: that bracn

20:33 <apritzel> awenth: that branch as is should be fine

20:35 <awenth> apritzel: Meaning that I should not have to revert one patch back?

20:36 <apritzel> well, that's a WIP branch, and I don't know if the H616 support patch is compatible with the other SoCs

20:36 <apritzel> so I'd revert that patch if I were you, just to be sure

20:37 <awenth> apritzel: I see tools/sunxi_toc0.c was modified. Let me rebuild

20:37 <apritzel> it changes something in the TOC0 layout, so could theoretically break on older SoCs (pure speculaion)

20:40 <awenth> apritzel: Nope, still falls through to FEL without printing anything on the uart.

20:41 <awenth> apritzel: I see the 'allwinner' branch is newer and mentions the secure monitor being loaded into A2 SRAM.

20:41 <awenth> apritzel: Will that be using toc0 too?

20:42 <awenth> apritzel: Nope, it only has sunxi_egon.c under tools

20:57 <apritzel> awenth: yeah, but that patch is for the H3 only anyway

20:57 <apritzel> but he also pulled that patch in

21:03 <awenth> apritzel: If the rotpk.pem is present and I run the mkimage command manually, it prints the spl layout as follow:

21:03 <awenth> apritzel: $ ./tools/mkimage -T sunxi_toc0 -a 0x10060 -n "sun50i-h5-orangepi-zero-plus" -d spl/u-boot-spl.bin spl/sunxi-spl.bin

21:04 <awenth> apritzel: 00000000:00000090 Headers \n 00000090:00000538 3 Key Ladder \n 000005c8:0000025d 1 Certificate \n 00000840:00006c48 2 Firmware \n 00007488:00000b78 Padding \n Load address: 0x00010060

21:05 <awenth> apritzel: At least the command seems happy with its inputs