01:41 <flyback> I give up

01:42 <flyback> the toolchain is broken from u-boot's site

01:43 <flyback> apprentely it's not compatible with lubuntu at all

01:45 <flyback> will have to see if I can run a old version of qemu or something with powerpc support, run a full os off it and compile it that way

01:45 <flyback> cause cross compilers are *CANUCKED*

02:22 <flyback> I guess the easiest thing to do is making a x86 vm of a linux old version where these cross compiler tools actually install and run

10:55 <rburton> Does u-boot support the qemu thing where it can look for a fw-cfg element in the devicetree that specifies kernel options (ie qemu's -append argument when it's not booting a kernel directly)

10:56 <rburton> i'm told edk2 does and uboot probably does

12:21 <MrSaturn> For those of you that have been following my drama of the slow TFTP transfer speeds, I finally solved the (quite unexpected) problem. console multiplexing was enabled and stdout was being routed to both the console and VGA. The act of updating the framebuffer was so taxing on the processor that it was unable to keep up.

12:21 <MrSaturn> That is my theory any way. "setenv stdout serial" solved the issue.

12:35 <Tartarus> rburton: Depends on the part of the fw-cfg thing you're talking about, I think

12:39 <Tartarus> rburton: If you mean passing stuff in via /chosen, yes, I believe we use the passed in device tree as-is, so that should get passed along. If you mean passing kernel/ramdisk/dtb file to use, I forget how widely the qfw command works, I think it might not on ppc for example

13:28 <kabel> any native german here? my cousin received a speeding fine from germany (written in slovak), he paid via bank transaction, and two weeks ago he received another letter, now in german, for the same fine. I think they received the first payment, but didn't pair it yet before sending the second notice, but I may be wrong, and I have problems decoding the buro-deutsch in that letter. Can someone look

13:28 <kabel> at it?

13:52 <rburton> Tartarus: i found the qfw command which is close. so my use-case is I'm booting a disk image but really want to get the kernel to have extra arguments (specifically, i'm passing -append ip=dhcp in environments where we're using slirp). don't want to use qfw load as the kernel/initrd are in the disk image. I did just hack up a 'qfw args' command which pulls the append arguments and sets a variable, which seems like a step in the right direction!

13:57 <Tartarus> Hunh, ok, I would have thought it would just be in /chosen in the generated dtb

13:57 <Tartarus> But yeah, ok, new qfw command then :)

13:57 <Tartarus> If nothing else maybe it'll get someone else to point out what I'm missing/forgetting

13:57 <rburton> i'm still failing around in the dark so i may be doing something wrong

13:59 <rburton> ah i wonder if its the extlinux.conf on disk which means it explicitly sets some values

14:07 <Tartarus> Yeah, extlinux.conf adds more fun

14:07 <Tartarus> I think last time I kicked that stuff with OE I was making sure it had the right arguments in what was generated

15:05 <rburton> i'm tempted to burn wic to the ground

15:06 <rburton> our extlinux.conf tells the uboot where to load a kernel from and some arguments, such as where the rootfs is

15:06 <rburton> but i want to inject more arguments from qemu-land

15:06 <rburton> looks like i can't do that :/

15:12 <MrSaturn> Alright, here we go. I set the TFTP_BLOCK to 4096, tftpboot works great - but when I run tftpput I get this error: "T Payload (4141) too large" any ideas?

15:14 <Tartarus> Yeah, I forget if you'd have more luck trying to go a more UEFI-direction or not

15:15 <Tartarus> depends on if -append gets in to /chosen or not, and you can poke that with the fdt command to check

15:15 <Tartarus> or, if it all gets overwritten with the idea that what's on disk is going to be most correct

15:19 <rburton> Tartarus: "bootargs = "root=/dev/vda rw mem=1024M ip=dhcp console=ttyAMA0 console=hvc0 ";"

15:19 <rburton> so the fdt has the right bits in

15:19 <rburton> guessing the extlinux having another append statement in means that wins when the kernel loads

15:19 <rburton> but i think i can work around this!

15:23 <Tartarus> MrSaturn: block + udp header or wahtever == 4141?

15:24 <Tartarus> rburton: Good progress, yeah. Lemme go check my notes..

15:25 <Tartarus> rburton: OK, yeah, so if we have ${foo} in the U-Boot env, and ${foo} in the extlinux.conf args line (I'd been doing root=PARTUUID=${uuid} so using UBOOT_EXTLINUX_ROOT wasn't absuing variables) it'll get expanded

17:56 <MrSaturn> Tartarus: yes, it appears so

18:13 <Forty-Bot> what does "deferred" mean on patchwork?

18:30 <apalos> rburton: I assume you are looking this into arm related context?

18:30 <apalos> If so Tom's right here, you probably need to test the EFI route (systemready etc)

18:32 <apalos> rburton: efidebug boot add -b 0 'the name' virtio 0:1 <path to image> -i virtio 0:1 <path to initrd -s 'cmd line args' && efidebug boot order 0 && bootefi bootmgr should do thge trick

18:35 <rburton> yes, arm. i think i need to rewrite the entire image generation dance.

18:36 <apalos> well the kernel get's stuffed with a PE/COFF header, so you dont really need to change anything there

18:36 <apalos> there's also a way for you to bake the output of that efidebug command into u-boot

18:37 <rburton> i don't want it baked in, that's the problem

18:37 <apalos> ok the the command is good enough?

18:37 <rburton> we've a wrapper script calling qemu which passes -append parameters depending on whether tap or slirp is being used

18:37 <apalos> there's also a series under review which has a bootmenu and you can graphically choose what you need to load with EFI

18:38 <apalos> but that needs a few more review rounds, generally it works though

18:45 <Tartarus> Forty-Bot: I'm not super consistent, but in the case of the nuvoton stuff, it's because there needs to be a v2 anyhow of other parts of the series and I try and not leave a series as partly new, partly changes requested

18:45 <Tartarus> I do assign to self and deferred when I clear out patches that haven't been applied after 1 year

18:45 <Forty-Bot> thanks; I was trying to figure out what the situation was

18:46 <Tartarus> And I also misread the 7xx and 8xx stuff as being the same, when it's not, but yeah, sure seems like there should be a good deal of driver overlap and so forth

18:46 <Forty-Bot> from what I can tell the 7xx clock driver is exactly the same as the v1 8xx driver but with the constants swapped out

18:47 <Forty-Bot> I'd love if there was some way to filter by which patches I've already reviewed and which I still need to address

18:48 <Forty-Bot> like if there was an intermediate state between "new/under review" and "accepted"

19:09 <Tartarus> there's "awaiting upstream", but I don't think that fits for this case

19:47 <MrSaturn> Yeah, this is pretty strange. I am seeing it on the development board as well. 2 different TFTP servers as well: T Payload (1514) too large

19:49 <MrSaturn> Is it true that "tftpput" is limited in the size you can transfer to less than a block size? It works fine for small files

19:52 <Tartarus> I think the most true statement is that tftput isn't nearly as well tested and used as tftpget/tftpboot so, there might be bugs

19:53 <Tartarus> If you can wireshark/tcpdump that might help (I'm not crazy and tcpdump does everything, right?)

19:53 <MrSaturn> https://paste.debian.net/1237030/ f'ing great. just what I wanted to see in ethernet driver.

19:54 <Tartarus> Welp

19:54 <MrSaturn> Maybe I upstream a patch. :)

19:55 <Tartarus> at least it didn't take long to track down the error message

19:57 <vagrantc> is there a script to tidy up sort order of configs/* ?

19:58 <Tartarus> huh?

19:58 <Tartarus> tools/moveconfig.py -s will re-sync them and I do that periodically

19:59 <vagrantc> like if i dump some random configuration options into configs/someboard_defconfig ... is there a tool to sort the order of the options within it? :)

19:59 <vagrantc> or help prune out redundant ones (e.g. CONFIG_FOO enables CONFIG_BAR, so no need to explicitly enable CONFIG_BAR)

20:00 <vagrantc> guessing moveconfig.py would do some of that...

20:02 <Tartarus> you can use -d to specify a list of them to re-sync rather than all

20:02 <Tartarus> Yes, tools/moveconfig.py will re-sync them

20:02 <vagrantc> though have a couple of those too :)

20:30 <marex> Pali: if you fix the turris updater so it actually updates, I might find BDI2000 with PPC firmware ;-)