dddddd has quit [Remote host closed the connection]
anarsoul_ has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
nuuuciano__ has joined #linux-sunxi
Rafael1980 has joined #linux-sunxi
nuuuciano_ has quit [Ping timeout: 246 seconds]
anarsoul_ has quit [Client Quit]
anarsoul_ has joined #linux-sunxi
anarsoul_ has quit [Client Quit]
anarsoul|c has joined #linux-sunxi
agraf has quit [Max SendQ exceeded]
anarsoul|c has quit [Client Quit]
anarsoul|c has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
<suprothunderbolt>
still confused about tear effect with DSI and if it's meant to connect up to something
tlwoerner_ has quit [Quit: Leaving]
shfil has quit [Quit: Connection closed for inactivity]
victhor has quit [Ping timeout: 258 seconds]
lurchi_ is now known as lurchi__
pg12_ has joined #linux-sunxi
pg12 has quit [Ping timeout: 252 seconds]
megi has quit [Ping timeout: 250 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
<MoeIcenowy>
avernos: mainline kernel just doesn't support the NAND
arc_phasor has left #linux-sunxi [#linux-sunxi]
kaspter has quit [Read error: Connection reset by peer]
camus has joined #linux-sunxi
tllim has joined #linux-sunxi
camus is now known as kaspter
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 252 seconds]
<suprothunderbolt>
in my quest to get DSI working I'm trying to get a 5.0 kernel running on an A64. Do I need to change uboot if I'm running a recent armbian image?
<anarsoul>
no if it uses mainline u-boot
<suprothunderbolt>
okay.
<suprothunderbolt>
Also I asked earlier about early printk but it appears that doesn't exist on ARM64
DonkeyHotei has joined #linux-sunxi
<suprothunderbolt>
so the sunxi boot.cmd on the wiki has a different address than the armbian one I'm running. If I install a mainline kernel (not built with armbian tools) do I have to change that?
<suprothunderbolt>
trying to work out why this kernel doesn't boot...
jaho has quit [Remote host closed the connection]
jaho has joined #linux-sunxi
f0xx has joined #linux-sunxi
_whitelogger has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
<suprothunderbolt>
any hints on getting a mainline 5 kernel to boot on a64, running armbian.
<suprothunderbolt>
currently i'm getting nothing on the terminal. I'm attempting to get the 5 kernel running so I can check if the original branch of these patches works and it's just my porting them to 4.19 that's broken
<avernos>
i have connected SATA without problem, but not booting from external hdd
<KotCzarny>
fALSO: then maybe your psu is bad?
<fALSO>
maybe my chinese external usb HDD cases
<fALSO>
suck
<fALSO>
do you guys recomend any good one? for "big" disks
<KotCzarny>
my bpir1 works for years with my hdd
<KotCzarny>
3T
<fALSO>
3.5 ?
<KotCzarny>
yup
<KotCzarny>
wd green
<fALSO>
do you have any special HDD case ?
<KotCzarny>
bpir1 has A20 soc
<fALSO>
and power supply
<KotCzarny>
for psu i use meanwell rd-65-b i think or -a, dont rmeember, needed dual voltage 5/12
<avernos>
KotCzarny, i dont have the tool nand-part mentioned there, i do have nanddump nandtest nandwrite, are these the equivalent updated version ?
<KotCzarny>
as for the case, i just use old desktop pc case, i have lots of things added there (including microamp, so it works as a audio system too
<mripard>
avernos: if you are using a mainline kernel, NAND is not supported at the moment unfortunately
<avernos>
somehow i was expecting to pass a bootarg with the nand to get through
<fALSO>
I have to buy a better USB HDD Case
<fALSO>
thats probably my problem
<avernos>
mripard, was afraid of that, thanks!
<KotCzarny>
$ apt-file search bin/nandtest
<KotCzarny>
mtd-utils: /usr/sbin/nandtest
<mripard>
avernos: it's not really an Allwinner SoC issue itself, but that the filesystem stack hasn't been designed to deal with the newer generations of NAND chips
<mripard>
and unfortunately, those are the very vast majority of the NAND chips that are found on the Allwinner boards
<avernos>
arg, wasnt expecting this to be anything new
<KotCzarny>
mripard: not even in slc mode?
<avernos>
i see
<mripard>
KotCzarny: as far as I know, switching to SLC mode requires some work, it's not the default state of an MLC NAND chip
<mripard>
and Linux doesn't support that either
<mripard>
that's way easier to support though
<KotCzarny>
mripard: might be sensible to update wiki then, to let potential newbies know
<mripard>
KotCzarny: we're not documenting anywhere how to run things in SLC mode, so I'm not sure what ther eis to update
<mripard>
KotCzarny: Installing_to_NAND is about legacy kernel, NAND mostly as well but has a link to MTD_Driver, that doesn't mention anywhere the MLC-as-SLC mode
<KotCzarny>
mripard, it's misleading information then
<mripard>
what is misleading?
<KotCzarny>
giving hope it's doable (using nand with mainline)
<KotCzarny>
that's why it would be sensible to add some 2019 update note to both
<mripard>
it's doable, if you have an SLC
<mripard>
and we have boards with SLC
dddddd has joined #linux-sunxi
<KotCzarny>
imagine you are new user, how would you know what can and what cant be done, and how to do it?
<mripard>
where the very first sentence is that you shouldn't do it for MLC
<KotCzarny>
k, going to add the paragraph/link to that page to /NAND
* karlp
wonders how the MLC staring match will end.
<KotCzarny>
done.
tnovotny has quit [Remote host closed the connection]
Gerwin_J has quit [Ping timeout: 264 seconds]
fkluknav has quit [Remote host closed the connection]
fkluknav has joined #linux-sunxi
lurchi__ is now known as lurchi_
<diego71>
avernos: uboot usually warns you if it fail to load the kernel
<avernos>
diego71, might have messed up passing console args at that time. but i think i tried. no output whatsoever. but if it wasnt that, then i suppose the kernel had something broken which seems wierd because i could get it to work with tftp. might have used daily on tftp.. not sure.
<avernos>
im surprised SD card approach worked for you on current release. maybe its only for cubieboard1..
megi has quit [Ping timeout: 268 seconds]
<MoeIcenowy>
mripard: what board is sunxi w/ SLC?
<mripard>
MoeIcenowy: off the top of my head, the Chip Pro and the (Super) NES Classic
lurchi_ is now known as lurchi__
forkbomb has quit [Quit: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move.]
<MoeIcenowy>
all uses quite small NANDs
pepee has joined #linux-sunxi
forkbomb has joined #linux-sunxi
<buZz>
mripard: arent half of the normal CHIP's also SLC?
<buZz>
at least, the later ones
<buZz>
or are they all MLC?
<mripard>
buZz: there's been several batches of the CHIP, all of them with MLC
<mripard>
but the first one that shipped did running in MLC-as-SLC mode
<diego71>
avernos: the last time I tried the sd card, was about 6 month ago on some olimex board
<mripard>
with an 8GB chip, where you were losing half the capacity
<mripard>
and the second run was running as MLC, but in "MLC mode
<mripard>
but with a 4GB chip
<mripard>
that's why when the 4.4 release came out, you could "upgrade" to 8GB on older chips
<buZz>
mripard: ahhh
<buZz>
yeah, tnx
selfbg has quit [Remote host closed the connection]
<avernos>
diego71, i think the previos setup worked just fine. tried some SD card sources from archive and worked halfway. at some point complaned for not having same kernel version on SD and ISO.. but i was hoping to upgrade to latest stable anyway. anyhow, as i said, might only affect cubieboard1. have a cubieboard2 somewhere, will check if works later on.
<avernos>
dont know where to report this, perhaps, if i am right, a couple of notes for others might help. but possibly no one uses this anymore
Mangy_Dog has joined #linux-sunxi
vagrantc has joined #linux-sunxi
tllim has joined #linux-sunxi
\\Mr_C\\ has quit [Ping timeout: 255 seconds]
msimpson has quit [Quit: Leaving]
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 250 seconds]
camus is now known as kaspter
JohnDoe_71Rus has joined #linux-sunxi
megi has joined #linux-sunxi
mpmc has quit [Ping timeout: 252 seconds]
mpmc has joined #linux-sunxi
<MoeIcenowy>
mripard: is MLC-as-SLC mode going to be mainlined ?
<KotCzarny>
+1, better working 2GB than 0GB
nuuuciano has joined #linux-sunxi
msimpson has joined #linux-sunxi
msimpson has quit [Remote host closed the connection]
msimpson has joined #linux-sunxi
<mripard>
MoeIcenowy: I hope so, but it's stalled as well
<mripard>
and it doesn't fix all the issues, only most of them
<MoeIcenowy>
mripard: what's the remaining?
<MoeIcenowy>
(to be honest, as now most community-friendly SBCs use eMMC, I hope we can forget the nightmare
<lavamind>
[ mtd: nand: fix some integer overflows
_whitelogger has quit [Ping timeout: 240 seconds]
<bbrezillon>
lavamind: I squashed the fixes in the initial commit
<bbrezillon>
while rebasing
<lavamind>
nice
<lavamind>
what do you think re: u-boot ? is it hopeless ?
<willmore>
fALSO, that makes me now wonder how it's supposed to sound. :)
<fALSO>
LOLOL
<fALSO>
sounds like someone trying to imitate chinese
<fALSO>
but with no idea LOL
<fALSO>
like
<willmore>
No, I mean the actual Chinese pronunciation. :)
<fALSO>
AHHH
<megi>
put it in google translate
<fALSO>
does it mean anything or is it the name of the company
<megi>
it says "Looking for dragon"
<fALSO>
or is a very long XUN
<fALSO>
;-)
<fALSO>
nice megi
<willmore>
megi, is it 寻龙?
<megi>
that's what google says
<MoeIcenowy>
willmore: it's 迅龙
<willmore>
sounds like hu-long
<MoeIcenowy>
quick dragon
<willmore>
ahh
<megi>
nice
<MoeIcenowy>
wens: tllim wants the mainline Linux Pine H64 DT defulat to model B
<willmore>
That's shing-lonnng
<MoeIcenowy>
but he still want to reserve for model A
<willmore>
Thanks, MoeIcenowy
<willmore>
I'd like to meet whomever came with this romanization system for Chinese and slap them about the head and shoulders for getting it so horribly wrong.
<fALSO>
LOL
<MoeIcenowy>
the pronounication of J/Q/X may look strange to westerners
<fALSO>
we probably dont even know how to make those sounds
<MoeIcenowy>
pronounce X in Chinese romanization like the sh in English
<willmore>
MoeIcenowy, understood, but then why write it as X instead of sh? The idea of romanizing a language is to make the non-Chinese speaker able to pronounce sounds like those of the native Chinese speaker.
<KotCzarny>
su-shi?
<MoeIcenowy>
Because SH is occupied by another sound
<willmore>
good point
<MoeIcenowy>
Will you care Unicode IPA here?
<fALSO>
hehe
<willmore>
Might make the most sense.
<fALSO>
Portuguese also has weird stuff
<willmore>
It'd be painful at first. :)
<fALSO>
like: ç ã â
<karlp>
willmore: why do english speakers sitll bother with c and k? or c and s? there's mountains of english that is traditional or aesthetic too.
<MoeIcenowy>
In fact Chinese romanization have even latin character variation
<karlp>
there's lots of "sh" sounds too....
<willmore>
As someone who speaks English and Spanish, I have to say that Portuguese just sounds wrong. :( Sorry, fALSO
<fALSO>
LOL willmore =)
<willmore>
karlp, I'm for getting rid of those!
<MoeIcenowy>
in Chinese romanization, sh is /ʂ/
<fALSO>
I can understand a bit of spanish, if they talk slowly
<fALSO>
something they never do
<MoeIcenowy>
x is /ɕ/
<MoeIcenowy>
they're different
<MoeIcenowy>
fALSO: do you know that Chinese uses the tone to represent some meaning?
<willmore>
MoeIcenowy, I understand. My arguement is that they could have picked letter sequences which would sound more like the original sound. X to most English speakers sounds nothing like the sh sound it's meant to stand for.
<willmore>
And English completely has no concept of tone.
<willmore>
Well, not in that way. We have inflections, etc.
<fALSO>
damn....
<fALSO>
we use some TONE when we ask questions
<fALSO>
so that people can understand its a question
<MoeIcenowy>
when tone is romanized, it uses latin variations
<fALSO>
but nothing for meaning :-)
<willmore>
fALSO, that's the inflection I'm talking about--the rising pitch of the voice at the end of a sentence to indicate a question.
<fALSO>
yes willmore !!!
<fALSO>
i dont know the terminology
<MoeIcenowy>
and even when no tone is used
<fALSO>
i just know about computers :-PPPPPPPPPPPPPPPppppppppppppp
<MoeIcenowy>
Chinese romanization contains ü
<MoeIcenowy>
which in fact become a problem in Computer era ;-)
<fALSO>
i can do that
<fALSO>
ü
<willmore>
uwu?
<fALSO>
with my keyboard
* willmore
ducks
<megi>
you can use pitch change and elongation for all kinds of effects, and meaning in english
<fALSO>
Portuguese a long time ago used those two pixels, but it was removed
<MoeIcenowy>
to be honest, keyboards at China are US ANSI keyboards
<fALSO>
¨ <- this
<willmore>
megi Valspeak does not count.
<megi>
:D
<fALSO>
I use a IBM MODEL M
<fALSO>
with portuguese layout
<fALSO>
the only acceptable keyboard :-P
<MoeIcenowy>
Because usual Chinese romanization doesn't use V
<willmore>
MoeIcenowy, how do you get the variations? shift/ctrl/alt, etc?
<MoeIcenowy>
when typing words that romanized as ü, we use v instead
<MoeIcenowy>
willmore: gucharmap
<willmore>
Ahh, okay.
<fALSO>
man, that must be hard
<willmore>
fALSO, imagine tryping on a 9 key keyboard in Chinese...
<fALSO>
lolololol
<MoeIcenowy>
willmore: it will have many words waiting for me to choose
<MoeIcenowy>
when I typed a key sequence
* willmore
nods
<karlp>
willmore: I dunno man, I've been seeing x in english words from asia for most of my life, it's pretty normal for lots of us.
<MoeIcenowy>
but I use qwerty, not T9
<willmore>
karlp, where did you grow up? I grep up in the great wide midwest.
<willmore>
MoeIcenowy, your flip phone must have been huge!
<megi>
lol
<MoeIcenowy>
willmore: do you know in typing machine era our typing machine have thousands of keys?
<DuClare>
So I guess I'm looking at the right gpio but still dumb because I've no idea what's up, heh
<KotCzarny>
you can read base gpio numer from sysfs too
<KotCzarny>
and before starting working on it you have to set it to i/o
<DuClare>
Oh you do?
<DuClare>
I thought they'd be set that way by default
<DuClare>
That is, unless another function has been assigned
<DuClare>
(But I don't see another function, and I suppose it wouldn't let me export the pin if something else were hogging it)
<KotCzarny>
what is it set to now?
<DuClare>
How do you check? I mean I'm not setting anything in dts so it should be whatever's the default, and IIRC pretty much everything's gpio by default
<megi>
you'd need to determine the address from the datasheet for the soc
<megi>
it would show you values for the entire PE port
jaho_ has joined #linux-sunxi
pepee has quit [Quit: pepee]
jaho has quit [Ping timeout: 246 seconds]
<DuClare>
Yea, no changes in data register :(
<megi>
and is it set as input?
<DuClare>
Yea, but let me check the configure registers
<megi>
then it will probably be something hw related
<DuClare>
Huh
Mangy_Dog has quit [Ping timeout: 245 seconds]
<DuClare>
Could I change port configuration with devmem just by writing to the configure registers, or does it require another write or reset elsewhere to actually configure?
<megi>
you can change it directly
<megi>
linux may get confused, though
<megi>
but you should probably be extra careful ;)
<DuClare>
Ok, so the pins were all configured "IO Disable"
<megi>
interesting
<DuClare>
(That's the config register's default value as per datasheet, btw)
<DuClare>
I changed all pins in a config reg to input and now reading the data register does reflect my inputs
<megi>
yeah, what soc is this and what kernel?
<DuClare>
(Although linux got confused)
<megi>
good! :)
<DuClare>
S3, 5.1.0-rc1
f0xx has quit [Ping timeout: 246 seconds]
<megi>
hmm, is dts correct?
<megi>
like correct base address for pinctrl?
<DuClare>
Yes, that address is ok
<DuClare>
And fwiw I think some pins work ok
<megi>
it seems odd that exporting gpio would not configure the pins correctly
<DuClare>
Yea..
<DuClare>
I've got some gpio chipselects on spi and these seem to work; on the other hand I also have one that doesn't work so
<DuClare>
I can also control a status led via gpio
cmeerw has joined #linux-sunxi
<megi>
I don't remember, but after export the default direction is input or does it have to be set specifically?
<DuClare>
It reads input
<DuClare>
I guess I could try change it explicitly
<megi>
it may be a bug in early rcs
<megi>
if you can you should try the last one
<DuClare>
Ok that's interesting, direction reads "in" by default but actually writing "in" to it results in a change in the configuration register
<megi>
That looks like a kernel bug.
<megi>
I wonder if it's a regression in 5.1
<megi>
and if it's still there in the last rc
dev1990 has joined #linux-sunxi
<DuClare>
More likely support for this board never matured to the point where all this stuff works
<DuClare>
Well, this soc
<DuClare>
There's plenty of (afaik) uncommitted patches floating about
<megi>
i don't think so, most of pinctrl code is shared among all socs
<megi>
and this may even be gpio-sysfs driver issue
<megi>
s/alls socs/all allwinner socs/
<DuClare>
But thanks for the help, at least I got somewhere and know the hardware is functioning :)
<megi>
:)
<DuClare>
Still need to figure out what's with the spi gpio but that's for another night..
<megi>
there's some bug there that was fixed after rc1 in the commit logs related to spi CS
<megi>
that I noticed
<megi>
may be related
Mr__Anderson has quit [Remote host closed the connection]
BenG83 has quit [Quit: Leaving]
BenG83 has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
cmeerw has quit [Quit: Leaving]
BenG83 has quit [Quit: Leaving]
jstein has quit [Ping timeout: 244 seconds]
lurchi__ is now known as lurchi_
egbert has quit [Ping timeout: 250 seconds]
mzki has quit [Ping timeout: 245 seconds]
mzki has joined #linux-sunxi
egbert has joined #linux-sunxi
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
camus has joined #linux-sunxi
kaspter has quit [Ping timeout: 246 seconds]
camus is now known as kaspter
jaho_ has quit [Read error: Connection reset by peer]
kaspter has quit [Ping timeout: 246 seconds]
kaspter has joined #linux-sunxi
suprothunderbolt has joined #linux-sunxi
vagrantc has quit [Quit: leaving]
shfil has quit [Quit: Connection closed for inactivity]