00:10 <marex> sjg1: dont forget to implement vfs and pipes, if I can do tftp | gunzip | mmc write, it will be perfect

11:20 <sjg1> marex: I'm not sure I would even know how to do that. Some sort of producer/consumer API?

11:20 <marex> sjg1: shouldnt hush implement large part of it already ?

11:21 <sjg1> marex: a large part of...?

11:24 <marex> pipes at least

11:27 <sjg1> marex: I haven't looked but I imagine hush relies on unix fork and pipes to do all that work

11:28 <marex> sjg1: and that is a problem ?

11:28 <marex> you can use main loop callbacks to implement those

11:29 <sjg1> marex: Well U-Boot doesn't have those. Perhaps we could ask Wolfgang about turning U-Boot into an OS?

11:30 <sjg1> marex: Yes, I suppose having some sort of producer/consumer API that is widely implemented would do it

11:30 <sjg1> marex: and/or spin up 3 CPUs and have them run concurrently

11:32 <marex> main loop callbacks/hooks would be useful, I did sent a prototype many months ago, it was ignored

11:32 <sjg1> marex: link?

11:35 <marex> sjg1: its in patchwork somewhere, callback: was the tag I think

11:42 <sjg1> marex: OK I found it. With the pipe example, it would always happen in the background?

11:43 <marex> sjg1: pipe should be just buffer passing

11:43 <marex> command foo fills buffer, passes it to command bar

11:46 <sjg1> marex: Sounds like an interesting project

11:48 <marex> sjg1: have fun, I'm currently busy

11:49 <sjg1> marex: Yes, I'm sitting on my hands over here :-)

11:50 <marex> sjg1: I dont think that's very good for your blood circulation

11:52 <sjg1> marex: keeps my hands warm though

11:55 <marex> then please keep at it

12:33 <sjg1> marex: yes Dr Marek

12:59 <sjg1> Tartarus: Just wondering about that old common.h series...any thoughts on where to take it next?

13:23 <ecrn> it looks like the memory performance issue is not caused by CCM/clock configuration either - I dumped the CCM registers, and there are differences only in some unrelated ones

13:23 <ecrn> the DRAM configuration I rewrote to use mx6_dram_cfg, but the result is still the same

14:15 <Tartarus> sjg1: Other than to pick another header file out of common.h, add it back sparingly (rather than just where common.h was used before) and make sure that now that we have link-time checking for gd size changes, we don't trip that again, no.

14:27 <ecrn> from v7_arch_cp15_set_l2aux_ctrl: asm volatile ("mcr p15, 1, %0, c15, c0, 0\n\t" : : "r"(l2actlr)); <- is this valid? the ARMv7 architecture reference manual says that ACTLR write is mcr p15, 0, <Rt>, c1, c0, 1

14:30 <sjg1> Tartarus: Should I have another crack at it? It would be great to get it finished. The script I use adds the header only if a symbol from the header is used. Of course if the header is included transitively already, the script will still add it, i.e. it doesn't work off build errors, just the code in the file

14:34 <Tartarus> sjg1: maybe just one at a time, then.

14:44 <sjg1> Tartarus: OK

14:47 <Tartarus> sjg1: Maybe add a pass to remove the header from other headers, then have the script re-add to headers which directly require it still?

14:49 <sjg1> Tartarus: Removing the header from other headers is hard to do programmatically. The other header may actually need it. Is it really such a big problem to 'include what you use?' It is standard practice in some projects

14:50 <Tartarus> sjg1: er, since you have a tool that already sees if the code needs a given header, let it pass over the header files too?

14:50 <Tartarus> And before you do that, find include | xargs sed -i '/#include <foo.h>/d'

14:52 <sjg1> Tartarus: for the first point, you are asking about removing headers from other headers. That is not the point of my series, which is to remove headers from common.h. So that would be a separate job. I did some of it, but it is a large undertaking, particularly without an 'include what you use' policy, since it uncovers loads of new files that break

14:53 <sjg1> Tartarus: E.g. I hit net.h which includes nearly everything!

14:53 <Tartarus> sjg1: Right, perhaps I misunderstood, don't you have a tool for seeing if a given file needs a given header?

14:53 <sjg1> Tartarus: yes, it works by seeing if the C file makes use of any of the symbols in the header

14:54 <Tartarus> right, ok

14:54 <Tartarus> So, popping open common.h right now

14:54 <Tartarus> Touching config.h is iffy due to Kconfig migration, next up is errno.h

14:55 <Tartarus> 11 header files use <errno.h>, that seems reasonable to audit if they need it directly or not

14:55 <Tartarus> Drop it from <common.h>, add <errno.h> directly as needed in code, see what shows up as an issue

14:56 <sjg1> Tartarus: that's OK so long as I can add errno.h to any C file that uses symbols in errno.h ?

14:56 <Tartarus> Yes

14:56 <sjg1> Tartarus: The concern came up from Heinrich I think, who claimed that the series was adding the header to files that didn't need it

14:56 <sjg1> Tartarus: I never saw evidence of that though

14:57 <Tartarus> sjg1: Yeah, I think I saw some when auditing around gd_t stuff, but that's tricky

14:57 <sjg1> Tartarus: When I compare the patch you applied it has 1361 files changes, which is actually more than the patch I originally sent.

14:58 <Tartarus> I went audit'ing and found more cases where we needed it directly and a few we didn't

14:58 <sjg1> Tartarus: I'm not claiming it doesn't happen, but the cost of zero is infinite, right?

14:58 <Tartarus> We should clean up more, yes

14:58 <Tartarus> But I don't want a big series because it's harder to review and spot check

14:59 <Tartarus> Like errno.h, OK, I bet almost all of the direct includers need <linux/errno.h> instead

14:59 <Tartarus> since errno.h is <linux/errno.h> and then almost nothing else

14:59 <Tartarus> But it's widely included

14:59 <Tartarus> So the correct thing would be to grab <linux/errno.h> directly most of the time and <errno.h> in a few places.

15:00 <Tartarus> Taking extra care on host tools of course

15:01 <sjg1> Tartarus: OK. But just to check, you are OK with a C file including a header if it uses a symbol from that header (even if it actually isn't needed because of a transitive include in another header which also needs it)?

15:02 <Tartarus> sjg1: yes, I am.

15:02 <sjg1> Tartarus: OK

15:02 <Tartarus> Perhaps another part of the lack of clarity here is that I'd like to see a given header removed from C if not needed

15:02 <Tartarus> So start out with find . -type f | xargs sed -i '/#include <foo.h>/d'

15:02 <Tartarus> Then add

15:03 <Tartarus> Roughly anyhow :)

15:55 <sjg1> Tartarus: OK

16:39 <replayer> do uimage or fit add any code (similar to setup.bin for the linux kernel) to the kernel or is it just metadata? i.e. decompression is handled by uboot and not my some loader stub added to the image

16:49 <ecrn> AFAIK no stubs are added

17:04 <Tartarus> But also, to be clear, on arm, "zImage" is what's inside of uimage typically and that does decompress.

17:04 <Tartarus> Image on aarch64 for example does not

21:20 <PoroCYon> hi, I'm trying to make a Zynq BOOT.BIN image using mkimage (so that I don't have to deal with xilinx tools as much as I can avoid it), however, I don't seem to be able to add more than one file to the image? (I'd need to add an fsbl/spl, bitstream, and u-boot as "fsbl application", so that's 3 files). If I use a colon as separator (as done in the --help output), it simply thinks it's

21:20 <PoroCYon> one single file path and cannot find it. using multiple -d arguments results in only using the last one... any idea if this is possible?

21:34 <PoroCYon> looks like -T zynqmpbif can parse xilinx bootgen .bif files, but the generated BOOT.BIN files don't seem to work on non-MP (i.e. non-UltraScale) Zynq devices (or at least not the ones I have here)

21:44 <PoroCYon> ok looking at the source code, -T zynqimage just doesn't seem to do multiple files

21:44 <PoroCYon> that's, not very useful

22:49 <vagrantc> not sure why, but this broke booting on the sifive_unmatched: first bad commit: [149108a3eb594b03561073aa6fd512cacab57c62] efi_loader: clear OsIndications