<sjg1>
Tartarus: Hmm there's a crazy number of size changes. I'm not sure that approach will work
<sjg1>
Tartarus: Just one example, look at drivers/misc/gsc.c
<sjg1>
Tartarus: It has U_BOOT_CMD() which currently is compiled into SPL, even though of course it isn't used
<sjg1>
Tartarus: With split config it is dropped, since CONFIG_CMDLINE is not enabled in SPL
<Tartarus>
Hummm
<sjg1>
Tartarus: It's similar to the env problem...the current behaviour isn't really correct, but it doesn't break anything
<sjg1>
Tartarus: Perhaps I can dig into things like that antry to get it closer to similar
<Tartarus>
Well, interesting. I suppose if the changes are things like "we exclude command functionality that was always never used but now isn't taking up space"
<Tartarus>
that's a bug fix
<Tartarus>
But that's also an infrequent one, since cmds shouldn't be, but sometimes are, outside of cmd/
<sjg1>
Tartarus: Yes, in that case I can change the behaviour
<Tartarus>
or, well, cmd/Makefile I guess has some logic too
<Tartarus>
Depends on how often it happens
<sjg1>
There are also loads of boards that do funny things...but only sometimes does it create a problem with split config
<Tartarus>
What else do you see, in terms of categories of size change?
<sjg1>
E.g. they use 'proper' Kconfig syms and SPL syms interchangeably and inconsistently
<sjg1>
Tartarus: E.g. arch/arm/mach-mvebu/Makefile see
<Tartarus>
odroid-go2 and chromebook_bob are worrying at first glance
<Tartarus>
imx8mn_bsh_smm_s2 too maybe, skimmed too quick and thought it was a cmd
<sjg1>
Tartarus: Yes, I need to make them closer and then look through things like that
<Tartarus>
I do, fwiw, wish that I could get the before/after size change output as a csv :)
<Tartarus>
That'd make filtering and seeing important changes easier
<sjg1>
Tartarus: That's a good idea
Forty-Laptop has joined #u-boot
<sjg1>
Tartarus: for chromebook_bob it is because sizeof(struct global_data) has changed, so it cannot use a single instruction to set the new_gd address on ARM. So it adds a few instructions. I don't think it will matter
<Tartarus>
struct global_data has to be the same between all stages, yes?
<sjg1>
chromebook_bob: part_get_info() is because PARTITION_TYPE_GUID is now 0 for SPL builds
<sjg1>
Tartarus: No, we allow it to be smaller in SPL. It was 0x1f8 in SPL before and now is 0x1c8
<Tartarus>
Really? I thought we passed it along in some/most cases
<Tartarus>
And, is PARTITION_TYPE_GUID being off in SPL now, is a good idea?
<sjg1>
Tartarus: There seem to be lots of places where we use 'proper' configs for build SPL, so are adding code we don't need
<Tartarus>
Well, if we can do this and remove actually unused code in SPL, that's good
<Tartarus>
but we need to investigate them
<sjg1>
PARTITION_TYPE_GUID means to collect the GUID of the partition type. It is used in a few places but I'm not sure it is used in SPL
<Tartarus>
How many HW platforms have you booted the series on?
<sjg1>
Hmm PARTITION_TYPE_GUID seems to be used in SPL for mmc for redundant environment in some cases...I wonder if any boards actually do that, though? It seems we just have a lot of stuff that builds OK and works so people don't worry too much about it
<sjg1>
Just some boards in my lab and rockpro64. I haven't tried the very latest though
<sjg1>
I can give things a try this weekend...perhaps add some more pre-patches to reduce the delta a bit
<Tartarus>
I'd try and be real sure that SPL case is not used
<Tartarus>
And, well, do post something when ready, and I'll throw it at my lab
<Tartarus>
and depending on what else is going on around here I might before/after and peek a few
<sjg1>
Tartarus: OK
<sjg1>
Tartarus: I do think this could be a significant clean-up of things
<Tartarus>
Yeah, I do want to see what it all looks like once done, size and also code change wise
<sjg1>
Tartarus: But there is one drawback. If someone decides to split an option so that it now has separate SPL and Proper versions, then they will affect existing boards that use the option in SPL
<sjg1>
Tartarus: i.e. those boards will see the option turned off, unless there is some sort of 'default y if...'
<Tartarus>
we have tricky things like that too today already when adding/changing options
<Tartarus>
and interesting, x86 discards _cmd_ list in SPL, no one else does
<sjg1>
Tartarus: Yes that's true...it has certainly been illuminating digging into this area. It would be nice to tighten it all up
<sjg1>
The workaround for that problem would be to put CONFIG_PPL_ before the options, so that the behaviour doesn't change. Of course, the problem is that most boards will not be using the behaviour anyway...
<Tartarus>
Yeah, lets see where things are at and how many of those PPL options we can't avoid
tperrot has quit [Read error: Connection reset by peer]