00:11 <marex> urja: well imagine you have an FPGA which generates perfectly spaced UART TX data on a line ... and your SoC cannot read all the data from the UART because the CPU just cannot keep up

00:12 <marex> with flow control, the receiving UART block indicates to the TX side it is no longer ready to receive at some point before the FIFO reaches 100% and the TX side should stop

08:10 <__ad> hi, on bootm i get "Wrong FIT format: no description

08:10 <__ad> Bad FIT kernel image format!

08:10 <__ad> "

08:10 <__ad> but in the .its kernel description is there

08:10 <__ad> u-boot 2017.01 + TI stuff

10:40 <__ad> mm if i remove initramfs from its all works

10:55 <__ad> maybe thios u-boot is too old to handle initramfs ?

13:24 <Sout> could that be possible as you can embedded the intitramfs in the kernel so you could? get away with that?

19:34 <sjg1> macromorgan: milkylainen_ Please see the commit message. We should not silently fail so please take a look at what is going wrong - re https://source.denx.de/u-boot/u-boot/-/commit/92f1e9a4b31c0bf0f4f61ab823a6a88657323646

19:36 <sjg1> mrnuke: Tartarus: Well my image series is stuck also...and in fact I sent that before your one. We should probably avoid doing this, but in any case, please either redo your next series or let me know so I can have a try at mine again

19:39 <macromorgan> the clk driver from Rockchip is a subset of the Linux driver, meaning it can't set all the clocks that are defined in the devicetree (which comes from Linux)

19:40 <macromorgan> we can add something in the rk3326-odroid-go2-u-boot.dts file to remove the ones we can't set

19:40 <macromorgan> which is to say the GPU clock, not that we use it anyway since GPU isn't supported until Linux anyway

19:40 <macromorgan> there's a few other clocks that we can add to the clock driver though

21:11 <Tartarus> sjg1: I don't see an image series on https://patchwork.ozlabs.org/project/uboot/list/?submitter=6170 ?

21:34 <mrnuke> sjg1: Which series? Are you referring to https://lists.denx.de/pipermail/u-boot/2021-May/449005.html?

21:35 <sjg1> Tartarus: mrnuke: Yes that one

21:36 <sjg1> It needs rework but not worth doing until mrnuke's stuff is in there

21:36 <sjg1> If it is already, then let me know

21:36 <mrnuke> sjg1: I think our combined patchset has been merged a couple of weeks back

21:36 <Tartarus> Ah, yes, I thought you had deferred to his series which is in

21:37 <sjg1> Tartarus: mrnuke: So nothing pending at this point? If not I can rework and resend

21:38 <mrnuke> sjg1: as far as ifdef cleanups go, nothing pending on my side

21:39 <mrnuke> I had intended to reqork some of the hash algo stuff, but given that our graphics expert has protitized other things, I've been allowed to learn and write OpenGL code on the job

21:39 <sjg1> mrnuke: OK thanks

21:40 <mrnuke> What that mess of words is saying is that I wanted to do more u-boot work, but I can't promise I'll have much BW anytime soon

21:42 <sjg1> Tartarus: mrnuke: That's fine. I think I misunderstood something and then forgot about it

21:42 <sjg1> Tartarus: Also I didn't notice you had applied https://patchwork.ozlabs.org/project/uboot/list/?series=252947&state=* which was the other relating thing

21:42 <sjg1> Tartarus: so I'll take another look at the image series

21:44 <Tartarus> sjg1: OK, yeah, I did do that recently and I think only replied to 1/17 rather than every one

21:44 <Tartarus> Sometimes I get tired of spamming out applied :

21:44 <Tartarus> :)

21:56 <sjg1> Tartarus: Yes indeed. I use a script now

22:51 <mrnuke> Tartarus: speaking of patches, I wish I could push code to gitlab and make a merge request. On most of my ML patches, I mess up some small thing