camus has quit [Read error: Connection reset by peer]
camus1 has joined #u-boot
camus1 is now known as camus
camus has quit [Ping timeout: 245 seconds]
monstr has joined #u-boot
zkrx has quit [Ping timeout: 246 seconds]
camus has joined #u-boot
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
mckoan|away is now known as mckoan
stefanro has quit [Quit: Leaving.]
stefanro has joined #u-boot
zkrx has joined #u-boot
<sng>
sjg1: For the capsule entry type node, you suggested using the 'type = "efi-capsule";' property to avoid the additional nesting. however this does not work, in that the efi-capsule type is never searched for.
<sng>
what am i missing?
<sng>
the entry.Create mothod does not get called for the capsule node. it does get called for the blob subnodes that i put
<pivi>
NishanthMenon: tested our board enablement series on top of your DTS sync patch, and related dependency. it breaks the ethernet functionality for us, within u-boot. I asked Marcel to write this to the mailinglist with the few logs he has (I have not tested it myself)
xypron has quit [Quit: xypron]
xypron has joined #u-boot
sng has quit [Read error: Connection reset by peer]
mmu_man has joined #u-boot
monstr has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
zkrx has quit [Ping timeout: 244 seconds]
zkrx has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
mncheck has joined #u-boot
vigneshr has quit [Quit: Connection closed for inactivity]
sng has joined #u-boot
zkrx has quit [Ping timeout: 244 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
zkrx has joined #u-boot
goliath has quit [Quit: SIGSEGV]
Leopold has quit [Ping timeout: 260 seconds]
goliath has joined #u-boot
Leopold has joined #u-boot
<NishanthMenon>
See the changes in board-uboot.dtsi
vfazio__ has quit [Remote host closed the connection]
vfazio has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
prabhakar has quit [Quit: Connection closed]
prabhakarlad has joined #u-boot
prabhakar has joined #u-boot
Peng_Fan has quit [Quit: Connection closed for inactivity]
Guest99 has joined #u-boot
goliath has quit [Quit: SIGSEGV]
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
LinuxHackerman has joined #u-boot
matthewcroughan- has joined #u-boot
mvaittin has joined #u-boot
aisha[m] has joined #u-boot
vulpes2[m] has joined #u-boot
sfo[m] has joined #u-boot
sylensky[m] has joined #u-boot
aat596 has joined #u-boot
rainbyte[m] has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
<pivi>
Tartarus: marcel is gone for good till wednesday next week :-/ I just checked and he did not push anywhere, not even in our internal git, his latest status
<Tartarus>
pivi: Ugh
<Tartarus>
Might just need to follow up on top then?
<Tartarus>
NishanthMenon: in yet?
<NishanthMenon>
Tartarus: ? I see Maxime responded to Marcel - looks like the verdin patches might need an update
<pivi>
Tartarus: yes, that would make sense. you apply and if we figure out something is wrong we'll fixup. TI AM62 SK seems to work and Verdin AM62 is not yet there
<pivi>
NishanthMenon: he did it, from what he told me. but unfortunately I cannot double check myself nor share the branch :-(
<Tartarus>
OK. I'll push those patches out in a bit then
<NishanthMenon>
pivi: i also tracked an interesting problem with beagleplay yesterday with Roger - looks like the manual mode of cpsw mdio might have a timing bug of sort.. we are still debugging the driver https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v2.1-enet-debug - not sure what the heck was going on with those two prints making things work..
sng has quit [Read error: Connection reset by peer]
sng has joined #u-boot
<NishanthMenon>
pivi: waiting for roger to get a beagleplay (already on shipment) before we can debug better..
ikarso has quit [Quit: Connection closed for inactivity]
sng has quit [Remote host closed the connection]
sng has joined #u-boot
davlefou has joined #u-boot
ldevulder has quit [Quit: Leaving]
stefanro has quit [Quit: Leaving.]
<sjg1>
sng: Thanks, what do I type to repeat the problem?
mncheck has quit [Ping timeout: 260 seconds]
<sng>
sjg1: you can simply build for the sandbox variant. it should generate those Test* capsule files. it does not. it just creates the image files, but those are not the capsule files that need to be generated
<sng>
if i put a efi-capsule entry, it then generates the capsule files as expected
<sng>
sjg1: the relevant binman entries are under arch/sandbox/dts/u-boot.dtsi
<sjg1>
Sng Is there a binman test I can run? It is much easier debug than a full build
<sjg1>
sng:
<sng>
sjg1 i have made some changes to the tests, but haven't tried them out. because the capsule generation does not happen.
<sng>
do you want me to try them out on my side?
<sjg1>
sng: single test with a single capsule node and its contents would be easy for me to debug
sng has quit [Remote host closed the connection]
sng has joined #u-boot
<sng>
sjg1 okay let me work on that
mckoan is now known as mckoan|away
<sjg1>
sng: OK, I see there is already testCapsuleGen() which should be enough for me?
<sng>
sjg1 some tweaks are needed
<sng>
sjg1 while i work on getting the tests working, can you check if the capsule nodes in the sandbox's u-boot.dtsi are using the type property correctly
<sjg1>
sng: Sorry, but this whole thing is a mess. There is a basic disconnect in how binman works
<matthewcroughan->
Can anybody tell me whether rock-4c-plus-rk3399 was ever tested? I can't find any confirmation by reading commit logs, PRs, etc
<matthewcroughan->
It seems that flashing the u-boot-rockchip.bin with seek=64 is not good enough
<sng>
sjg1 okay, where do you see the disconnect? you had earlier suggested using a subnode for the payload that goes into the capsule. and to use the mkimage entry as reference. what do you see wrong here?
<sjg1>
sng: I pushed a patch to my github sjg20/for-sng
<sjg1>
The disconnect is the understanding of how binman works. It does not use files to communicate with ittself. It just uses things thin memory
<sjg1>
Take a look the the patch and see if you can make the test work and address my comments
<sng>
sjg1 yes, i understand how this is supposed to work when we are packaging an image. but this case is a bit different in that there is no packaging of images happening here to create a final image.bin. instead we just need to call a tool for generating capsules with a bunch of command-line arguments
<sng>
how is this different from the args = "" method of passing arguments to mkimage
<marex>
matthewcroughan-: try and check with naoki (seems away now)
<sjg1>
sng: You need to let go of that. It is not at all different. Just follow the path and it will be a lot easier
<sng>
that is all that is happening here. for example, for arguments like image-index, image-type-id, how do we use subnodes for these? these are pretty much same as the args being passed to mkimage
<sjg1>
sng: I pushed another patch to try to illustrate this point
<sng>
sjg1 okay. let me check that
<sjg1>
sng: Those things are just properties of the capsule that binman creates...I don't know what they have to do with subnode
<sjg1>
sng: Just make that simple test produce a valid capsule and check that it looks OK. Then you know that your etype works
<sjg1>
sng: Most important: return the data as bytes in Python. Binman is in control of the final image, not some capsule utility
<sjg1>
sng: Just follow along and get that working and then you can build on that
<marex>
sjg1: what is the status of binman for-marek in your github now ? I am now stuck on this massive stack of patches for binman, but they dont seem to be in upstream and they dont even rebase on another massive stack of binman patches that is now upstream
<sng>
sjg1 the capsule tool has been around from before this series. moreover, it is doing something very similar to what is being done by mkimage. even for the mkimage entry type, we explicitly read the output adter having run the command
<sjg1>
marex: Everything is upstream now (up to d12c14ff16b binman: Reduce state.SetInt to debug level)
<sjg1>
sng: Yes it's fine to read the output from a *temporary* file that binman creates for that purpose. That is what mkimage does
<matthewcroughan->
<marex> "matthewcroughan - nix.how: try..." <- Yeah I pinged the maintainer yesterday, no response yet, then saw them leave via IRC, so wondering if the ping got through or not, since I'm using a matrix client. You're the first confirmation that I have :D
<cambrian_invader>
do we ever call malloc before mem_malloc_init ?
<cambrian_invader>
that is, the real thing and not simple_malloc
<sng>
so we need to tweak the tool to support what binman expects. this tool is currently in use for generating capsules, and based on what you suggest, that would mean that the tool's interface would have to change
<sng>
because then, the tool would have to output the capsule data instead of writing it to a capsule file, which it currently does
<cambrian_invader>
it doesn't seem like it
<sjg1>
sng: I don't see why it needs to change at all. It writes it to a capsule filename provided by binman. Then binman reads it in
ikarso has joined #u-boot
<sng>
sjg1 so that is currently been done. we have the option to write to a capsule filename provided as a property, or to the filename provided by binman
<sjg1>
Yes, drop the property and all will be well
<sng>
sjg1 okay. i can do that. but that is a nit. the real issue at hand is that the type property does not work as expected
<sjg1>
sng: I don't see any problem with my patch applied. Did you try it?
<sng>
sjg1 oh, so do you see the test.capsule getting generated?
<sjg1>
sng: who knows...it is just binary junk. But there is something there:
<marex>
sjg1: what about + args; /* hack so we can subclass mkimage */
<marex>
?
<marex>
sjg1: I guess I'll have one more look
<sjg1>
sng: What build? We haven't got to that yet..we are trying to get your etype to work
<sjg1>
Tartarus: Yes that seems OK...can we have something in doc/ about it?
<Tartarus>
sjg1: At some point, sure
<sjg1>
marex: Well we are stuck with that for now, I suppose? Can we deal with it once you have everything working?
<marex>
sjg1: sure, currently I have nothing working so ...
<marex>
sjg1: when I regain willpower to deal with binman again, yeah
<sjg1>
Tartarus: OK
<sng>
sjg1 the goal here is to get capsules built as part of the sandbox build. and that works when we have the additional nesting. but without the additional nesting, the capsule does not get generated during the build
<sjg1>
smg: We need to break down your goal and start with something simple, as this is way off in the weeds
<sjg1>
Once you have got testCapsuleGen() doing what it should, let me know
<sng>
sjg1 the goal is not to have testCapsuleGen() working. although i see that is does work. what is needed is that when we build sandbox, the capsules be generated. and that does not happen when we use the type = "efi-capsule" property
<sjg1>
sng: OK, so that test is fixed now, right? It wasn't working before but now it is fixed?
<sng>
sjg1 yes it does work. so it seems that the type property gets interpreted correctly when called from test, but not when binman gets called as part of the platform's build
<sjg1>
sng: But your capsule1, etc. still have filenames in them
<sjg1>
sng: Binman tests should be in binman...the sandbox test is for checking that the capsules can be used for an update, I am guessing?
<sng>
sjg1: yes, and so does the testGenCapsule dts file. like i said earlier, it does work with the additional nesting. similar to what i had in my v5 series
<sng>
sjg1 yes, the capsules generated through the sandbox build would be used for testing the capsule update feature.
<sjg1>
sng: What are you typing, what do you do, what do you expect to see?
<sng>
the binman tests are the standalone tests that are only testing capsule generation
<sjg1>
sng: Yes, as well as the failure cases since we need 100% code coverage in binman
<sng>
sjg1: i use the following command 'make mrproper && make sandbox_defconfig && make all'. I expect the capsule files specified in the 'capsule' property to have been generated. they are not, "without the additional nesting"
<sng>
if i use the format which i used in my v5 patch 12/12, the capsules do get generated as part of the sandbox build
<sjg1>
sng: You are still confused about the filenames
<Tartarus>
sjg1: did you see the issue I filed about the binman maintainers check?
<sjg1>
sng: Drop the 'capsule' property. Put a 'filename' property in the capsule1 {} node. Then the output image will be written there
<sng>
sjg1: Simon, the filename is an irrelevant aspect here. i will fix it when i submit the next version. the issue is avoiding the double nesting using the type property
<sjg1>
Tartarus: Oh I did now. But without a defconfig, what board does the entry relate to?
<sng>
sjg1: when i do away with the additional nesting, and use the type = 'efi-capsule', the entry's constructor does not get invoked.
<sjg1>
sng: What additional nesting? It seems to work fine if your etype is correct, but you are not understanding what I am saying about filenames
<sjg1>
I pushed another patch that shows how it should be done
<sng>
sjg: okay, let me make the filename change and push that to my github. we can then discuss
<Tartarus>
sjg1: what do you mean?
<Tartarus>
It relates to what's in the entries
<Tartarus>
Just like everything in the top-level maintainers file
<Tartarus>
board/mikrotik/crs3xx-98dx3236/MAINTAINERS first entry is valid
<Tartarus>
Just doesn't have a specific config too
BWhitten has joined #u-boot
Gravis_ has joined #u-boot
Gravis has quit [Ping timeout: 260 seconds]
<sjg1>
Tartarus: OK I thought that each entry (apart from top-level MAINTAINERS) had to have a defconffig, since otherwise we don't know what board it related to?
Gravis_ has quit [Ping timeout: 244 seconds]
Gravis has joined #u-boot
<Tartarus>
Yeah, there's no restriction like that on other MAINTAINERS files
<sjg1>
Tartarus: That's a shame, as it makes it hard to check the data
<Tartarus>
Fixes the problem, but buildman is still unhappy
<Tartarus>
an "F" line that doesn't have an actual match is wrong
<Tartarus>
But an "F" line for just board/foo, or just drivers/whatever, is fine
<Tartarus>
And the mikrotik example is better as there's nothing wrong in there, as far as I can tell
<Tartarus>
all the F things listed exist
<Tartarus>
This is why I was saying "new tool" so much :)
<Tartarus>
We need something that parses the maintainers files and then can report things
<Tartarus>
like "what lacks an entry"
<Tartarus>
"what's orphaned"
<Tartarus>
We started off on making everything have a specific maintainer, and then just stopped at making sure defconfigs have one
<sjg1>
Tartarus: Yes I just misunderstand the format...it doesn't seem to actually be fully documented anywhere, or this would be a lot easier. I also don't see any tests anywhere that we need to pass
<sjg1>
Tartarus: Also I see X and K options which we don't support
<sjg1>
Tartarus: (and don't use?)
<sjg1>
Tartarus: It is unhappy about board/mikrotik/crs3xx-98dx3236/MAINTAINERS because it does not reference a defconfig, so it doesn't know to which board it relates
<Tartarus>
Yes, it's a very ad-hoc thing
<Tartarus>
And yes, just that first entry doesn't have a defconfig, every other entry does
<Tartarus>
and presumably the maintainers did that on purpose
<sjg1>
Tartarus: So what does it mean? I suppose we just look for files referred to that don't exist? And files not referred to that do?
<Tartarus>
Yes, that's what we'd want in a stand alone tool, along with being able to ask for status about files
<Tartarus>
It really really doesn't belong in the buildman boards.cfg mojo :)
<Tartarus>
That was just where it was at one point because it was there
<sjg1>
Tartarus: Yes sure I agree with that. Why doesn't someone in kernel land write a proper tool? And a proper spec? Is there a maintainer for MAINTAINERS?
<Tartarus>
I cannot say
<broonie>
Joe Perches maintains get_maintainer.pl
<Tartarus>
a 24k long file is not what I expect in the kernel
<broonie>
Torvalds was recently having some fun sorting it.
<Tartarus>
broonie: Yes, and get_maintainer.pl is kinda slow
<sjg1>
kinda??
<broonie>
Plus a menace for false positives.
<Tartarus>
Even with the git part off
<broonie>
But that does make him the nearest thing to a maintainer for the format.
<Tartarus>
Anyways, yes, no, there's not some formal spec or other tool for it
<broonie>
It's more intended to be a hint than an authoritative tool in the kernel. which sounds like a bit if a different goal to the way you're trying to use it
<Tartarus>
I don't think we're going much harder here than the kernel does
<Tartarus>
Before I gave up on the loop, the kernel is really good about not having unlisted files
<sjg1>
IMO it is a mess. If I were to upstream a tool I'm sure the first thing that people would say is that it needs to be written in Perl...the second thing is that it doesn't deal with feature xx of the MAINTAINERS files
<sjg1>
Anyway at some point I'll pull it out into a new tool with the same bugs and we can go from there
<sjg1>
scripts/get_maintainer.pl --self-test
<broonie>
The kernel's thing with not having unlisted files comes mainly from tending to have entries for subsystems, finding driver maintainers with it is a bit random.
<sjg1>
but I don't think it does...it starts working through the real MAINTAINERS file
<broonie>
sjg1: That option is misnamed, it's for validating MAINTAINERS not a test for the script.
<sjg1>
cunning...
<broonie>
Someone should write some self tests and add them as a --lint-maintainers option :P
sng has quit [Read error: Connection reset by peer]
sng_ has joined #u-boot
sng_ has quit [Remote host closed the connection]
BWhitten has quit [Ping timeout: 246 seconds]
cambrian_invader has joined #u-boot
<pivi>
Tartarus, NishanthMenon : so marcel figured out the issue with the verdin am62 ethernet, v4 series was sent. I though he was gone for a long weekend, but in the end he worked pretty late to get to the bottom of this
<NishanthMenon>
pivi: glad to have his help on it. was getting worried if we uncovered yet another issue . Please share our Thank you to Marcel for digging deep and finding the root cause.