13:00 <ssvb> apritzel: the idea was to be able to keep just a single bootloader binary for both secure and non-secure hardware configurations (unless there's a really good reason not to do this) and the text in https://linux-sunxi.org/TOC0#TOC0_images_generation pretty much explains everything

13:02 <apritzel> ssvb: oh, long time no see!

13:03 <apritzel> ssvb: well, what would be the reason for a single bootloader binary, if it still needs to be put through a script?

13:04 <apritzel> ssvb: so my plan is to have a U-Boot Kconfig switch, so it automatically generates the u-boot-sunxi-with-spl.bin with a TOC0 SPL

13:05 <apritzel> for devices which are always secure (Remix Mini) this would be in the defconfig, in other cases people can enable it separately

13:05 <ssvb> it doesn't have not be put through a script, because this functionality (conversion on the fly) can be integrated into a flasher software

13:07 <apritzel> which flasher software ;-)

13:08 <ssvb> I know that right now 'dd' is commonly used as a flasher, but this isn't perfect. Because this is error prone and the users may easily hurt themselves.

13:10 <ssvb> Having something slightly more intelligent than 'dd' would be a major improvement for user experience.

13:10 <apritzel> ssvb: maybe we can have both approaches? mainline SPL learns to deal with being loaded via a TOC0 (checking for TOC0 magic as well and behaving accordingly)

13:11 <apritzel> then we teach the U-Boot build system to directly create TOC0, if requested

13:11 <apritzel> or the user creates the default eGON and puts it through your script?

13:11 <apritzel> which could then possibly lose the TOC0->eGON disguise hack, since the SPL can natively deal with this?

13:13 <apritzel> ssvb: and yeah, this: how to best install your firmware seems a somewhat trivial, but still unsolved problem

13:22 <ssvb> This "if requested" part is bothering me. In the ancient past, if the users wanted to boot via USB FEL, then they had to build a special U-Boot version via using a separate defconfig. Only a few boards supported this, the users had to be able to build their own bootloader rather than downloading some pre-built binary, etc. And of course, by the time when someone would be interested in building a FEL binary, this functionality was

13:22 <ssvb> likely to fail to build or run due to bitrot.

13:24 <apritzel> ssvb: I guess we need to work out what the use case for secure boot firmware is

13:24 <apritzel> ssvb: AFAICT there are only a very few boards that come with the secure fuse burnt

13:25 <apritzel> ssvb: which makes this a somewhat niche use case

13:29 <apritzel> ssvb: but I could upstream Remix Mini support and keep testing that, also I have a "converted" Pine64

13:30 <ssvb> hmm, so your goal is just to support a few "unfortunate" boards with a pre-burnt e-fuse rather than take advantage of secure boot benefits?

13:31 <ssvb> I think jemk mentioned that these boards could be be switched back to egon mode by burning a different efuse bit. I haven't verified this myself.

13:31 <apritzel> yeah, heard about this, but indeed didn't dare to try this

13:32 <gediz0x539> is Mainline U-Boot SPL capable to boot from FEL on A64?

13:33 <apritzel> gediz0x539: yes, since v2021.01

13:33 <apritzel> ssvb: and I don't know what the goal is: there are some people interested in explicitly enabling secure boot, but the benefits are questionable, as they seem to be holes/bugs in the BROM

13:33 <gediz0x539> apritzel: great. i'm still using sunxi64-fel32

13:34 <gediz0x539> it's cool though

13:34 <apritzel> gediz0x539: also sunxi-fel can now deal with FIT images, so you can just say: sunxi-fel uboot u-boot-sunxi-with-spl.bin

13:34 <apritzel> on every SoC, with v8 or v7 cores

13:36 <apritzel> ssvb: bauen1 (still over at Freenode ;-) discovered some BROM bugs (in the H6, at least) that allows booting unsigned payloads

13:36 <gediz0x539> it sounds like the easiest-to-use form

13:38 <apritzel> gediz0x539: btw: the mainline solution is with an AArch64 SPL, we found some clever way of resetting back to AArch32 before returning to FEL

13:54 <gediz0x539> apritzel: this one? https://github.com/u-boot/u-boot/commit/0e4d5db4e0379da9ca4eee00dbca9773d8718e8e

13:54 <apritzel> gediz0x539: yes

13:56 <gediz0x539> seamless

14:27 <ssvb> apritzel: That's a good question about the secure boot benefits. My own primary motivation is to avoid the theoretical risk of https://en.wikipedia.org/wiki/Boot_sector#Boot_sector_viruses (which exists because of the SD card boot priority) or other similar attack vectors.

14:28 <ssvb> apritzel: on the other hand, by improving secure boot support we may be digging our own grave if various vendors start making unbreakable locked down devices

14:38 <apritzel> ssvb: indeed! I was always wondering why not more vendors use secure boot for their embedded devices (like this Nintendo console), at least as some hurdle

14:38 <apritzel> ssvb: but better not give them funny ideas ;-)

14:39 <apritzel> but at the end there might be ways around it anyway, as bauen1 had discovered

14:56 <libv> ssvb!

15:54 <macromorgan> question... I'm trying to run kexec by doing the following: |kexec -s -d zImage --dtb=sun5i-r8-chip.dtb --command-line="root=/dev/sda1 console=ttyS0,115200"| and I'm getting the following error: Could not find a free area of memory of 0x285840 bytes...

15:54 <macromorgan> anyone seen this before? Here is my memory: https://paste.debian.net/1198740/

15:54 <macromorgan> and here is my free output: https://paste.debian.net/1198741/

15:55 <macromorgan> doing this on an R8

16:54 <ssvb> libv: What's up with the irc channel migration? Seems like both old and new channels are active at the same time and this looks ugly.

16:56 <ssvb> And the message at the top of https://freenode.irclog.whitequark.org/linux-sunxi page suggests to contact them to continue logging the new channel.

16:59 <anarsoul> time to set +m on freenode?

17:07 <libv> anarsoul: i've been thinking about it, but it seems to hardhanded

17:08 <anarsoul> not really

17:08 <anarsoul> topic clearly states where everyone went

17:08 <anarsoul> and most of regulars are already here

17:09 <libv> so +1 from anarsoul

17:09 <libv> any other takers?

17:11 <MoeIcenowy> I don't think we should set +m on freenode

17:11 <MoeIcenowy> it's still the most centralized IRC network

17:11 <MoeIcenowy> and gets pre-inputed on the server field on many IRC clients

17:12 <MoeIcenowy> currently, because some channels migrate to oftc and others migrate to libera, no other one can replace freenode's place now

17:13 <libv> fragmentation... the only real irc network left, ruined for shortsighted profit

17:15 <jernej> I don't mind being logged in two servers, but having two active channels for same thing on two servers is confusing...

17:15 <jernej> without some kind of force, it will stay splitted, so +1 from me

17:15 <libv> +2:-1

19:52 <rellla> fragmentation is bad, so +1 from me, too. time flies and people will find it, once they found out what irc is...

21:31 <jelly> also, there are 27 users in the eponymous channel on libera; it would probably be nice to take over that one and point users over here at least in the topic

23:57 <smaeul> indeed, since it is broken, I'm interested in secure boot mostly as a curiosity. in fact, I had to exploit H616 SBROM before I could dump it :)