tnovotny has quit [Remote host closed the connection]
tnovotny_ has quit []
tnovotny has joined #linux-sunxi
apritzel has joined #linux-sunxi
ad__ has joined #linux-sunxi
<ad__>
hi all, looking for a suggestion on an allwinner possibly easy to soder (qfp), ddr2 support is ok, for a very small linux app
vpeter has quit [Remote host closed the connection]
<karlp>
what easy to solder ddr2 are you going to add to it?
vpeter has joined #linux-sunxi
<apritzel>
ad__: I don't know if any of those numerous newer wimpy SoCs use it, but AFAIK the A13 was the last/"latest" with QFP?
<apritzel>
ah, the V3s is a tad more modern, and comes in a 128-pin eLQFP package
<apritzel>
karlp: and the V3s has consequently embedded DDR2 ;-)
<apritzel>
ad__, by why do you want to make your own board? why not just use one of those existing boards or a SoM?
<ad__>
apritzel, i design and solder linux boards at hope, i enjoy with them, and has been the chance to mainline a lot of stuff in the kernel
<ad__>
*at home
<ad__>
for this case, i am about to design a specific board for my caravan. DDR2 embedded is perfect for my case
<ad__>
will check V3s, thankls a lot
<apritzel>
If this is a single board, it would be *MUCH* easier to just use one of those tiny boards (<xxx>pi Zero), because they solved all of the nasty problems for you
<apritzel>
those Linux SoCs are a whole different story than an AVR, for instance ...
<ad__>
yes it's easier. but you don't learn anything. never bought any of them
Mangy_Dog has joined #linux-sunxi
<ad__>
my designs are done in kicad, until ddr2 i am good with them. my kernel patches are now 46, something that gives me some goot points on cv. This is the main reason why i develop my boards.
mps has joined #linux-sunxi
<mps>
on Allwinner A20 bananapi board poweroff doesn't work with latest stable kernels, it shutdown OS (linux) but power led stays red, last kernel which works was 5.11
<mps>
anyone knows what should/could be changed in kernel config, or is this a bug
Net147_ has joined #linux-sunxi
Net147 has quit [Ping timeout: 480 seconds]
<ad__>
mps, maybe i would enable loglevel=7 to see any dmesg on shutdown
<ad__>
seems a good chance for a patch :)
<mps>
ad__: I already enabled but don't see anything on serial console
<mps>
last kernel message is '[ 92.883306] reboot: Power down'
<ad__>
you need the sources (linux.git), pointing to exact commit/tag with the issue
<ad__>
then you "bisect" giving a non working commit back in time
<mps>
hmm, not sure this will work for me. If i know which driver or subsystem to look I could be a lot faster, I think
<mps>
for me 'git log -p good/bad drivers/../..' works fine
<mps>
and problem is in 5.12 and between 5.11
<mps>
after 5.11*
<mps>
anyway thanks for url, looks like is simple enough to understand bisect
<karlp>
mps: you can exit a bisect at any stage, and it's quicker than you think.
<karlp>
you can always see what commits are still int he list and you can see what it's likely to be if you know what you're looking for.
<mps>
karlp: problem is I don't what I have to look for, i.e. which file/s
<mps>
I don't know*
<mps>
i.e. where is poweroff code in linux tree
<karlp>
well, bisect then :)
<mps>
:)
<karlp>
when it starts showing you smaller lists (which is quick) you might see something that stands out
<mps>
I'm not kernel hacker to understand what would lead me to have idea which commit made this problem
<karlp>
well, then just bisect all the wya. it will tellyou
<karlp>
the commit titles are normally not _too_ bad.
<mps>
eh, I'm oldtimer and teaching me new 'tricks' will not be easy, I have impression ;)
<karlp>
git bisect is straight forward,just have to wait for the boring rebuilds at each step
<mps>
to simply put, I don't have any idea what to look git bisect
<karlp>
but it's pretty painless.
<karlp>
you just art bisecting, 5.11 good, 5.12 bad.
<mps>
I understand concept now
<karlp>
it will automatically checkout the middle, you rebuild and test,
<karlp>
you say "git bisect good|bad"
<karlp>
and it automatically moves to the next split point
<karlp>
you can be pretty naiive and just keep going and it will eventually just spit you out a commit
<mps>
isn't this boring and need a lot time and machine cycles
<karlp>
it's actually surprisingly quick,
<karlp>
you might need to rebuild like 5-8 times, but .... you don't have to go randomly rummaging around trying to find things in the dark
<mps>
but if I know which driver (file) to look I think it will be faster, or I'm naive
<karlp>
but you don't know.
<karlp>
and you haven't gotten an answer here promptly.
<mps>
that's true
<karlp>
so you might as well start bisecting...
<karlp>
and it might be spread across other things,
<mps>
I'll wait few days, maybe someone know which file to look
<karlp>
you would be well and truly finished bisecting by that time :)
<mps>
:)
<mps>
I have other 'works' to do for open source in meantime
<karlp>
well, good luck with it then :)
<mps>
btw, I noticed this bug when the 5.12 is released, but I was patient till today, waiting for someone to fix it
<karlp>
power off failures tend not to be noticed much as far I can see, historically
Daanct12 has joined #linux-sunxi
ftg has joined #linux-sunxi
<mps>
karlp: thanks for sharing this, good thing to remember
Danct12 has quit [Ping timeout: 480 seconds]
cnxsoft has quit []
<apritzel>
mps, waiting for someone else to fix the problem is a bad strategy
<apritzel>
at least report it, so others know what to look for
<apritzel>
the problem is that those bubbles we operate in are so small: there are not that many people that power off A20 devices with recent kernels, for instance
<apritzel>
a problem, say in the SATA driver, is seen by the a lot of people, so it's quickly fixed, but once you go down into the more obscure corners, it gets lonely pretty quickly
<apritzel>
and karlp is right: if you don't know about the problem or have no time to dig deeper, a bisect is always your friend:
<apritzel>
it's easy to do and works quite well, and doesn't require any special knowledge, other than how to reproduce the problem
Daaanct12 has joined #linux-sunxi
<apritzel>
mps, the only thing to look out for is to keep track of the steps: if rebuild and test take a while, you have to remember where you were and what's the next step (git bisect? compile? test?)
<apritzel>
and don't you dare to go for lunch in the middle ;-)
<karlp>
(I sometimes write down in an other file what commits I've tested. you can restart git bisect at any later date with the good ones again)
<apritzel>
yeah, that's a good idea
<karlp>
it's muhc too hard to find it in the scrollback, and git reflog only shows the commits, not whether they were good or not
<mps>
apritzel: I understand all this, but if I report every bug I have (and had) I will need 48 hours in a day, besides my $day_job
<apritzel>
mps: reporting could be as simple as just mentioning it here
<mps>
I simply had a hope that someone on this channel already knows for this bug
<apritzel>
I can dig out my BPi tonight and have a look
<apritzel>
mps: you can always hope, but at least now people know
<mps>
apritzel: nice :)
<apritzel>
and quite some people read the logs, so you might see some response hours or days later
<apritzel>
(with response maybe even being a patch)
<mps>
I'll ask on olimex channel does they noticed something like this on their A20 boards
<apritzel>
mps: so in summary: thanks for the report ;-)
Daanct12 has quit [Ping timeout: 480 seconds]
<mps>
apritzel: karlp: ad__: thank you all for trying to help
<mps>
btw, I noticed yet another bug with gpadc (or something similar), will report also this when I prepare 'testbed' for it
Daanct12 has joined #linux-sunxi
lunixoid has quit []
Daaanct12 has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
<ad__>
mps yw, good luck
lunixoid has joined #linux-sunxi
hlauer has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
cmeerw has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #linux-sunxi
Daanct12 has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has quit []
obbardc19 has quit []
obbardc19 has joined #linux-sunxi
TuxBlackEdo has quit []
TuxBlackEdo has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
<MoeIcenowy>
megi1: why is "drm: sun4i: sun6i_mipi_dsi: fix horizontal timing" reverted on your kernel tree?