05:11 <voldial> reading https://events.opensuse.org/conferences/oSC16/program/proposal/946 I'm confused (the slides are like a flipbook movie), the goal is to boot x86 and ARM from the same block device, where I got lost is, uboot->uefi->grub2 is that just for the ARM case? Because in the x86 case, isnt there is another(?) UEFI stage before uboot or it's BIOS boot routines, hybrid mbr etc...?

05:37 <voldial> ah, I misunderstood the goal. are there any project attempting that? seems possible since the arm side isnt going to care about the x86 boot code, it's just going to find the file it needs on the FAT

05:37 <voldial> 2x initrd, 2x /bin etc

05:38 <voldial> but shared config as far as possible. gentoo is prob easiest to attempt that with

06:43 <mckoan> good morning

10:12 <mckoan> hello, is the iMX8 watchdog supported in u-boot?

10:35 <mckoan> u-boot_2020.04 with i.MX 8QuadPlus (i.MX 8QP)

10:36 <mckoan> maybe you have any hint, patch, whatever?

11:03 <ad__> hi mckoan :) in the mainline i don't see anything about. but you shold be able to configure it with few linesm as in 12.9.3.4

11:04 <ad__> is there a way to have u-boot printing scripts command he is executing ?

11:48 <mckoan> ad__: thx

11:56 <marex> git diff says the NXP downstream v2020.04 has 1318 files changed, 243128 insertions(+), 14357 deletions(-)

11:57 <marex> so maybe you need to ask NXP for support with their insane amount of changed lines

11:57 <marex> I suspect you are looking for the SC watchdog, which is not supported

14:00 <mrnuke> marex: ever consider trademarking u-boot and requiring forks to use a different name?

14:01 <mrnuke> similar to what mozilla does to firefux

14:06 <marex> mrnuke: there are forks which use different name, all of them sub-par afaict

14:08 <mrnuke> marex: I know, right. Nobody beats us in terms of #ifdefs! :)

14:09 <marex> mrnuke: I'm not sure if you're sarcastic or serious, because either option fits

14:09 <mrnuke> marex: Both!

14:18 <sjg1> Tartarus: Can you give me an example of the growth? I did see some minor things around the swith() statements, but may have missed something

14:21 <Tartarus> sjg1: No, it's all of those kinds of growth. It's small and I feel like I need to see if I can make a simple test-case that shows it and file a bug as it seems like an optimization problem

14:30 <sjg1> Tartarus: Oh I see, ta

16:40 <mckoan> marex: thanks

18:38 <mrnuke> Umh, "+arc-linux-ld.bfd: error: u-boot: unable to merge CPU base attributes ARC7xx with ARCEM" with buildman

18:39 <mrnuke> Is it just me, or a known issue with arch toolchain?