<marex>
samueldr: that patch is wrong as far as I can tell, Fixes should be generated with git show -s --color=never --pretty='tformat:%h ("%s")' and also ... CMD_BMP should depends on BMP, not select it
<samueldr>
thanks for the reply
<samueldr>
though uh, I used `git send-email`
<samueldr>
(first time)
<marex>
samueldr: is this really fixing anything last minute ?
<samueldr>
yes
<marex>
what ?
<marex>
I mean, you need to flip two symbols most likely, that's not really any grave defect that needs to be fixed this instant
<samueldr>
I'm not sure what you're getting at here
<marex>
samueldr: what issue is the aforementioned patch fixing exactly ?
<marex>
you need to select BMP=y and CMD_BMP=y separately ?
<samueldr>
re-threading the verification to show complete proof, but as written in the commit, when CMD_BMP is enabled on an existing configuration, which had the default to `n`, yes, BMP is not set and build fails
<samueldr>
(I'll send a v2 for the depends on rather than select once checked)
<marex>
samueldr: the kind that is last minute fix is "stuff does not boot" "stuff crashes" etc., not Kconfig sym inconvenience that you have to select two syms to enable $feature
<marex>
the release date is literally today, so this is likely not going to be part of it
<samueldr>
right, so a regression where builds won't work is not a fix
<samueldr>
thank you
<samueldr>
sorry, I'm being extenuated by external stuff from here
<samueldr>
I shouldn't have answered like that
<samueldr>
I mean, this should be something that got caught with the introduction of a new option
naoki has joined #u-boot
<marex>
samueldr: the builds would work, just select the two symbols in your config ; CI would actually catch it if this was a bug in any of the upstream configs, so, are you triggering it with some downstream stuff ?
<samueldr>
yes with configured builds
<marex>
samueldr: that said, I agree it is a fix, I also agree it should have been caught in patch review already, but alas, it wasn't
<samueldr>
but unpatched otherwise
<samueldr>
given how trivial, I would have thought it could go in, and is why I'm asking about the usual process
<marex>
samueldr: ask Tartarus , but since there are review comments and we're literally hours from release, that's unlikely this would go in, esp. since it then needs testing and validation that the change did not break any existing boards
<samueldr>
ok, just checked: `depends on BMP` is the wrong dependency; BMP provides the `bmp_display` function, among others, so it requires enabling BMP before CMD_BMP is availble, rather than the BMP option being intrinsically enabled as dependend on by CMD_BMP
<marex>
you already have to enable VIDEO to make CMD_BMP available, so, same for BMP, right ?
<samueldr>
I'm not sure, I'm not sure what the intention behind BMP was, it looks like BMP would be considered not a subsystem, but like "library dependencies" is my understanding
<samueldr>
but maybe I'm misunderstanding how KConfig options should be written to make sense for developers
<samueldr>
I would expect that BMP be turned on as needed
<marex>
BMP seems like a library dep
<samueldr>
and never make sense to turn on outside of within KConfig machinery
<samueldr>
but I've not really had to deal with authoring complex networks of options in KConfig-using projects much, so I don't know what's the expectation
<samueldr>
it makes sense for CONFIG_VIDEO to be depends on; that itself is a coarse feature, is my mental model
<samueldr>
when enabling CMD_BMP by going through `make menuconfig` (after a make [...]_defconfig) the build will fail with undefined refs to bmp_display and bmp_info
<samueldr>
oh oops, I was scrolled up and mistaken your early question ignore the last message [while still true]
stipa_ has joined #u-boot
stipa has quit [Ping timeout: 250 seconds]
stipa_ is now known as stipa
<marex>
samueldr: make menuconfig -> /BMP -> select both -> Ctrl+C -> Save -> Yes
<sjg1>
marex: OK I have cracked mkimage and will send a series once CI passes
<sjg1>
marex: You should be able to get your new etype going using mkimage as a base now
<sjg1>
marex: Longer term I have some ideas on how to simplify things, as I fell that the cfg files is really just getting in the way, when binman is used
<sjg1>
marex: But we need to get it all working first
naoki has quit [Quit: naoki]
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
jclsn has quit [Ping timeout: 246 seconds]
jclsn has joined #u-boot
stipa_ has joined #u-boot
stipa has quit [Ping timeout: 245 seconds]
stipa_ is now known as stipa
naoki has joined #u-boot
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #u-boot
sng has joined #u-boot
qqq has joined #u-boot
vvn has joined #u-boot
<vvn>
hi there -- I'm writing a fitImage in a raw partition (mmc 0:2). How do I boot it from u-boot?
monstr has quit [Read error: Connection reset by peer]
monstr has joined #u-boot
paulbarker has joined #u-boot
sng has joined #u-boot
vagrantc has quit [Quit: leaving]
jaganteki has joined #u-boot
mckoan|away is now known as mckoan
sng has quit [Remote host closed the connection]
mmu_man has joined #u-boot
sng has joined #u-boot
apteryx has quit [Ping timeout: 245 seconds]
frieder has joined #u-boot
<jclsn>
I don't fully get what moveconfig is doing. Is it for transferring legacy hardcoded configurations from headers to the kernel style defconfigs?
mmu_man has quit [Ping timeout: 245 seconds]
hanetzer has quit [Ping timeout: 250 seconds]
hanetzer has joined #u-boot
apteryx has joined #u-boot
vigneshr has joined #u-boot
ldevulder has joined #u-boot
stipa_ has joined #u-boot
stipa has quit [Ping timeout: 250 seconds]
stipa_ is now known as stipa
stipa_ has joined #u-boot
stipa has quit [Ping timeout: 246 seconds]
naoki has quit [Quit: naoki]
stipa has joined #u-boot
stipa_ has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
ikarso has joined #u-boot
stipa_ has joined #u-boot
stipa has quit [Ping timeout: 252 seconds]
stipa_ is now known as stipa
jaganteki has quit [Quit: Client closed]
sng has quit [Remote host closed the connection]
___nick___ has joined #u-boot
jaganteki has joined #u-boot
monstr has quit [Remote host closed the connection]
monstr has joined #u-boot
monstr has quit [Remote host closed the connection]
monstr_ has joined #u-boot
sng has joined #u-boot
Hypfer2 has joined #u-boot
sng has quit [Ping timeout: 258 seconds]
Hypfer has quit [Ping timeout: 246 seconds]
Hypfer2 is now known as Hypfer
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
frieder has quit [Ping timeout: 264 seconds]
mmu_man has quit [Ping timeout: 240 seconds]
rainbyte has quit [Ping timeout: 245 seconds]
frieder has joined #u-boot
jaganteki has quit [Quit: Client closed]
mmu_man has joined #u-boot
SlimeyX has quit [Ping timeout: 250 seconds]
SlimeyX has joined #u-boot
<marex>
sjg1: can you push a branch too ?
<jclsn>
sjg1: So I downloaded the aarch64 toolchain, rebuilt the moveconfig data base and now I get 973 matches for "GPIO". No idea what this is telling me though
sszy has joined #u-boot
<marex>
vvn: see help mmc -> see read subcommand
<marex>
vvn: load the partition content to DRAM address 0xsomething and then bootm 0xsomething
<jclsn>
Ah seems that zsh does not process the arguments correctly. I got the command ./tools/moveconfig.py -f GPIO ~DM_GPIO to work in bash. In zsh you can surround the arguments in quotes. If I understand correctly though this command lists boards where the write protect lock support is implemented??
<marex>
vvn: see bdinfo command output for DRAM layout
<marex>
jclsn: both GPIO and DM_GPIO is already converted to Kconfig ?
<jclsn>
marex: How to I check that? If they are listed in cmd/Kconfig?
<jclsn>
In your defconfig only a CMD_GPIO can be found
<jclsn>
DM_GPIO is available in drivers/gpio/Kconfig though
<marex>
$ git grep config.GPIO$ | grep Kconfig
<marex>
drivers/gpio/Kconfig:menuconfig GPIO
<jclsn>
Thanks
<jclsn>
Yeah that is there
<jclsn>
I would have to add it to our defconfig though I reckon
<sjg1>
jclsn: Oh. For the GPIO, what board are you using? If it doesn't already use DM_GPIO then you will need to convert it if you want to use driver model for GPIO
<sjg1>
marex: No...but I just had a look and it doesn't work. It is a bit of a mess, but I will see if I can figure it out. Oh dear
<jclsn>
sjg1: It is a Layerscape LS1028A series SoC. I tried enabling DM_GPIO in the defconfig earlier, but that did not fix the issue. What do I need to convert? The BSP for the Layerscape you mean?
<SlimeyX>
heh
<marex>
it would be a good starting point to use up to date U-Boot ...
<sjg1>
marex: OK with the changes I made to your entry type, it does add the symbols. I pushed it to github again, this time on top of v3 - for-marek
<sjg1>
marex: It is a subclass of the mkimage entry type.
<sjg1>
marex: Hmmm but actually it can just be a subclass of section...the important thing is to implement BuildSectionData() since that is the thing that builds the contents of a section
SlimeyX has quit [Ping timeout: 246 seconds]
SlimeyX_ is now known as SlimeyX
<sjg1>
marex: the 'args =' stuff that you have cannot work as is, since it specifies an internal binman filename. You'll hit problems when you write the test, since the filename will be in a different directory
<sjg1>
marex: But a suitable hack for now might be to use something like: args = "-n CFG-T imx8mimage" and then manually update self.section._args in Entry_nxp_imx8mimage_cfg.ReadNode()
<marex>
sjg1: what is the proper solution ?
<marex>
sjg1: I mean, there are two FIXMEs in the .dtsi
<sjg1>
marex: for the -n FIXME, you can see the docs for mkimage etype. It is designed for passing data to mkimage. If you use data-to-imagename it can pass -n, but in this case you are not passing the data (in the section). You are creating a .cfg file to pass it
<sjg1>
marex: That's what I mean about the cfg file getting in the way. But for now I suggest you just make it work as above
<jclsn>
marex: I can't
<sjg1>
marex: For the second FIXME, it is expanded and symbols are now updated. It does not appear expanded in the fdtmap, since Binman (at present) considers expansion to be an internal thing. We could change that if you think it would help
<marex>
jclsn: you are asking upstream developers for help, and yet you conveniently omitted the fact that you are missing 8715 patches in your work tree
<sjg1>
jclsn: 2015 is really old...if the latest U-Boot doesn't work for you, you might end up having to hack things
<jclsn>
It is 2022.04
<jclsn>
I wouldn't call that ancient
<marex>
sjg1: so with whatever you pushed, the flash.bin is generated identical with/without the topmost patch ?
<sjg1>
jclsn: Oh OK, I got confused with the other message. That is quite recent and I would expect it to support DM_GPIO as the deadline was a long time ago
<jclsn>
marex: That is a lot indeed
<jclsn>
I still can't change it I fear. We are three months away from the release
<marex>
ah ... drat, so I ported those almost 1000 patches for various obsolete downstream "secure" things like "trusted" firmware and optee-os, but now it seems the ABI has changed again and the kernel won't even boot
<marex>
what a horrid crap this whole move toward "firmware" interface is, utter fail
jaganteki has quit [Quit: Client closed]
<marex>
[ 1.994416] arm-scmi: probe of firmware:scmi failed with error -95
<marex>
of course ...
<marex>
next time someone says burying stuff into firmware is a good idea ... no, it so is not
<marex>
hmmm, but if I want to downgrade secure firmware for a test, the machine wont boot at all, due to incompatibility between obsolete downstream fork 1 and less obsolete downstream fork 2
<marex>
of course
<rfs613>
marex: don't worry, they will solve this problem with a new API and a new layer of indirection :P
sng has joined #u-boot
<rfs613>
btw, the missing while() loop I was asking about last week, I eventually found it one level up, in spi_nor_write(). So that problem at least is solved ;-)
<SlimeyX>
so its shows like compatible = "fsl,t1024-dcsr-epu", "fsl,dcsr-epu"; instead
paulbarker has quit [Quit: Connection closed for inactivity]
sng has quit [Remote host closed the connection]
<marex>
hm sure, if broken unstable firmware ABI does not crash me, poor support for all this SCMI crap does not crash me, then TEE WDT does because that is disabled and somehow it is not
<marex>
what a shyte
<marex>
sjg1: it is valid
<marex>
SlimeyX: ^
<marex>
cfr dt spec stringlist encoding
<SlimeyX>
cool
ldevulder has quit [Quit: Leaving]
<sjg1>
sjg1: Yes, it is how string lists are stored, with a \0 after each string
<sjg1>
marex: We need VBE and Firmware Handoff
sng has joined #u-boot
<marex>
sjg1: what ?
jaganteki has joined #u-boot
<marex>
hmm, some ATF upstream maintainer just provided a review on my behalf ... wow ... I guess thats how it works there, even if I might disagree
<marex>
what a diseased upstream that one is, ugh
sng has quit [Remote host closed the connection]
qqq has joined #u-boot
___nick___ has quit [Ping timeout: 250 seconds]
aak-rookie has quit [Quit: Client closed]
vagrantc has quit [Ping timeout: 240 seconds]
hanetzer has quit [Ping timeout: 260 seconds]
hanetzer has joined #u-boot
<marex>
damn ... ST failed to pull in bugfixes in last two months for this release