ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
apritzel_ has quit [Ping timeout: 272 seconds]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #armlinux
amitk has joined #armlinux
guillaume_g has joined #armlinux
heat has quit [Ping timeout: 246 seconds]
bps2 has joined #armlinux
amitk_ has joined #armlinux
amitk has quit [Ping timeout: 265 seconds]
cbeznea has joined #armlinux
frieder has joined #armlinux
cleger has joined #armlinux
iivanov has joined #armlinux
viorel_suman has joined #armlinux
<linusw_>
ukleinek: not written by me but I try to maintain it and I use it so I guess I know a little...
<linusw_>
for example I should convert it to use regmap, which did not yet exist when that driver was written...
frieder has quit [Ping timeout: 260 seconds]
mcoquelin has quit [Remote host closed the connection]
<ukleinek>
javierm: still not sure I really want that :-)
<javierm>
ukleinek: fair :) if you don't, please remind me which patches from you are still pending to be reviewed and/or pushed
<javierm>
I was on PTO for a couple of weeks and I barely remember my name :P
<ukleinek>
PTO = please turn over?
<ukleinek>
(/me guesses that's something like parental leave)
<javierm>
ukleinek: Personal Time Off, sorry for using acronyms
<ukleinek>
javierm: my honest guess wasn't so bad then, no problem on my side
<javierm>
ukleinek: but I honestly think that you should apply, you do a lot of tree wide cleanups so it would be good for you to have commit access
<javierm>
that way you don't get blocked by DRM, since as most subsystems everyone is too busy there and things could fall through the cracks
<javierm>
ukleinek: getting your patches reviewed then would be enough for you to push them and have one less subsystem to keep track
<ukleinek>
javierm: it's an imbalance, because I don't have commit access anywhere and pinging fallen through patches is much more straight forward to me than to remember/reresearch the specifics of drm-misc and if it's good enough to be committed to drm-misc-next (or was it for-linux-next?)
<javierm>
ukleinek: I see. That's a good point too
<javierm>
but there may be patches that weren't reviewed because where superseded
<ukleinek>
having said that, there are patches 38-43 from my big series that I would expect to go in via drm-misc
<javierm>
ukleinek: have all those been reviewed/acked ?
<ukleinek>
javierm: they were reviewed by a guy named "Javier Martinez Canillas" who seems to work for Redhat :-)
<javierm>
:)
<javierm>
ukleinek: Ok, I'll use a combination from patchwork and git log to figure out which one are still pending to be applied and go through them later today
<javierm>
ukleinek: I'll answer in the mailing list when doing so that you know that were applied
<ukleinek>
javierm: I can go through the patchwork list and tell you which patches are still "open" on my list if that helps you
<ukleinek>
javierm: OMG, so many old patches ...
<javierm>
ukleinek: that would definitely help a lot and save me time :)
<javierm>
yeah, is a pity that patchwork patch status isn't updated. The only subsystem I know where maintainers do it properly is media/v4l2
<javierm>
ukleinek: maybe by email or as a private message to not spam this channel :)
<ukleinek>
javierm: I just did: pwclient update -p dri-devel -s handled -c 3fd269e74f2feec973f45ee11d822faeda4fe284 12047623
<ukleinek>
javierm: and that worked just fine
<javierm>
ukleinek: awesome, that's even better
<javierm>
then I know that is only the ones that are remaining in state == 'New'
cbeznea has quit [Quit: Leaving.]
<ukleinek>
javierm: I'll ping you when I'm through, but it will take some time ...
<javierm>
ukleinek: sure, no rush since I won't be able to push anyways until later today
<ukleinek>
bah, doesn't seem to work via the webif
<ukleinek>
ah, it doesn't work for patches sent via my private email address
<ukleinek>
javierm: I mark the patches that are already in drm-next as "applied"
<ukleinek>
("accepted" is the right term)
<javierm>
ukleinek: yeah, I believe anything but new would be enough. I take care of the status of my own patches but don't seems to be consistent with what is set to
<javierm>
sometimes Accepted, other times Mainlined or Queued
<ukleinek>
javierm: it should be easy to script something that picks the Link: footer of commits and marks the patchwork patches as accepted
monstr has quit [Remote host closed the connection]
matthias_bgg has quit [Quit: Leaving]
tomde has joined #armlinux
headless has joined #armlinux
frieder has quit [Quit: Leaving]
cleger has quit [Remote host closed the connection]
<tomde>
Hello, what could be the reason for a device boot-up hanging at (i.e. immediately after) "Starting kernel...", with u-boot well running before that? [... am away for 45 mins ...]
<bjdooks>
a number of issues, can you get early printk via a known working uart going?
<tomde>
not yet, (that's also the reason for being away soon), I have only some hours ago read about some "early printk".
<Xogium>
what about jtag ?
<Xogium>
random idea but
<tomde>
I have no jtag iface on the board.
<Xogium>
well damn
<Xogium>
earlyprintk is definitely the best option then
<ukleinek>
javierm: don't apply the oldest in the list, I will rebase that and trigger that on the ML, there were some concerns ...
<ukleinek>
javierm: and for the two drm/imx/dcss patches I can also ping my colleagues
tomde has joined #armlinux
<tomde>
On the printk (etc.) ideas: On the working (i.e. booting) kernel image, I got debug console output activated. Shows lots of output. An aside: More crucial than setting earlyprintk was to use the kernel param "debug". ...
<tomde>
Using the same kernel parameters with the non-booting kernel image, produced _no_ debug output after "Starting kernel", i.e. (for me) the kernel code is not properly started. -> entrypoint issue (but these are set the same in both boots)
<geertu>
tomde: Tried "earlycon keep_bootcon"?
<tomde>
No. What is bootcon ... will look it up...
<geertu>
tomde: "keep_bootcon" means to keep printing on earlycon, even after another console became available. Sometimes it's needed to get to see the crash reason.
<tomde>
ok, doc seen.
<geertu>
Disadvantage is that you will see everything printed twice when it does boot fine.
<tomde>
can try this... (10min)
<tomde>
Result: absolutely no output. My idea was that the kernel image is of wrong type. Has someone ever peeked with a hex editor in their own kernel images? (arm64 in my case)
<tomde>
The u-boot script has a "booti" in the end. Doc says: "...loads a compressed or a flat image". Does "flat" mean uncompressed?
<tomde>
I let uboot load an uncompressed Image, the result from arch/arm64/boot
<geertu>
which is what should give you some output on arm32...
<geertu>
Now, you can still modify printk() to write all messages to a buffer at a fixed address in RAM, and inspect that buffer from U-Boot after crash and reset
<tomde>
I noticed two main differences in the Image files: first: at position 0x38 one reads in both "ARMd", with "d" apparently for 0x64. The byte thereafter is different. Can "you" check with the images you have?
<tomde>
I read about the warm-boot, but dont know how to do this.
<tomde>
Does this work without powering off, and hitting a reset button? (the latter which I dont have)
<ukleinek>
javierm: resent the oldest patch now and marked it as superseeded
headless has quit [Quit: Konversation terminated!]
<tomde>
NB: "you"=someone. Further: ".. is what should give you some output on arm32...". The arch/arm/boot does not contain any binary output. Or maybe the phrase was meant differently.
tomde has quit [Quit: Leaving]
mcoquelin has quit [Quit: Leaving]
<arnd>
I merged my work-in-progress boardfile removal branch into the soc for-next tree. What could possibly go wrong