Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
kaspter has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<MoeIcenowy>
mripard: I tried to use sun4i-ts on A33, but failed
<MoeIcenowy>
and when will your I2S driver get merged?
<MoeIcenowy>
(It seems that A33/A64's audiocodec used an internal I2S
<lennyraposo>
quick question
<lennyraposo>
has anyone used gcc 6 as of yet?
<MoeIcenowy>
lennyraposo: on what purpose?
<MoeIcenowy>
our distro is using gcc 6 for a few weeks
<lennyraposo>
for compiling building kernel
<MoeIcenowy>
(oh our cross toolchain is still 4.9
<MoeIcenowy>
but our x86_64 kernel is built with gcc6
<lennyraposo>
gotcha
<MoeIcenowy>
Linux version 4.6.2-aosc-main (root@general) (gcc version 6.1.0 20160427 (AOSC OS, Core) (GCC) ) #1 SMP PREEMPT Mon Jun 13 13:36:52 CST 2016
<lennyraposo>
kewl and the gang :)
<lennyraposo>
well that answers my question for cisc
<lennyraposo>
ahev you attempted on any arm builds?
<lennyraposo>
just wondering
<MoeIcenowy>
lennyraposo: maybe I should try it this afternoon (Asia/Hong_Kong)
<wens>
lennyraposo: you can ask hans
<wens>
lennyraposo: seems fedora uses the latest GCC, and they hit a bug with my uboot work :(
<MoeIcenowy>
wens: :-)
<MoeIcenowy>
wens: is there any newer version of axp209 battery driver patch?
<MoeIcenowy>
I want make one for axp22x
<lennyraposo>
thanks Moelcenowy
<wens>
not that i'm aware of
<MoeIcenowy>
wens: ah-oh
<MoeIcenowy>
laga and bonbons are all not here...
Gerwin_J has quit [Quit: Gerwin_J]
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
lennyraposo1 has joined #linux-sunxi
lennyraposo has quit [Read error: Connection reset by peer]
lennyraposo1 has quit [Ping timeout: 258 seconds]
kaspter has quit [Remote host closed the connection]
lennyraposo has joined #linux-sunxi
lennyraposo has quit [Client Quit]
lennyraposo has joined #linux-sunxi
fire2191 has quit [Read error: Connection reset by peer]
lennyraposo has quit [Client Quit]
lennyraposo has joined #linux-sunxi
tithrion_ has quit [Ping timeout: 240 seconds]
lennyraposo has quit [Quit: Leaving.]
lennyraposo has joined #linux-sunxi
_stephan has joined #linux-sunxi
<_stephan>
hi. I got that PE0 pin bank running applying wens hint (LDO3 hat to be set to 2.8V). I have another problem...
<_stephan>
I try to set up PE0 pin to be pull down for use as sysfs gpio. So I put this in the DTS: http://pastebin.com/7i47hdLU - but the pin is still floating
<_stephan>
(so, with no voltage applied, it randomly has 0 or 1 in /sys/class/gpio/gpio128/value)
<wens>
for the pinmux to be applied, it has to be tied to a device
<wens>
just adding a node under &pio does nothing
<_stephan>
ah, thank you. do you have any advice, which device to tie it to, to make it usable through sysfs?
<_stephan>
it's only used in userspace...
<wens>
if you're just testing stuff yourself, you could tie it to any device that's enabled
<wens>
for formal stuff that will be submitted, i don't know
<_stephan>
okay. thanks you very much. for both (the regulator stuff and this :))
<_stephan>
maybe I just use it in the pio device itself... that might be the cleanest thing to do.
TheSeven has quit [Ping timeout: 272 seconds]
[7] has joined #linux-sunxi
kaspter has joined #linux-sunxi
IgorPec has joined #linux-sunxi
fredy has quit [Excess Flood]
IgorPec has quit [Ping timeout: 244 seconds]
fredy has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
IgorPec10 has joined #linux-sunxi
Gerwin_J has joined #linux-sunxi
tithrion_ has quit [Remote host closed the connection]
tithrion_ has joined #linux-sunxi
IgorPec10 has quit [Ping timeout: 258 seconds]
jernej has quit [Ping timeout: 240 seconds]
IgorPec has joined #linux-sunxi
vagrantc has joined #linux-sunxi
dearfibonacci has joined #linux-sunxi
<_stephan>
wens, thank you, it works fine now.
fredy has quit [Excess Flood]
fredy has joined #linux-sunxi
Nyuutwo has quit [Ping timeout: 240 seconds]
Nyuutwo has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
Mr__Anderson has quit [Remote host closed the connection]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 244 seconds]
ricardocrudo has quit [Remote host closed the connection]
yann|work has joined #linux-sunxi
phipli has joined #linux-sunxi
Amit_T has joined #linux-sunxi
phipli has quit [Ping timeout: 244 seconds]
vagrantc has quit [Quit: leaving]
afaerber has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
sW`` is now known as sW`
dearfibonacci has quit [Quit: Leaving]
dearfibonacci has joined #linux-sunxi
JohnDoe_71Rus has quit [Read error: Connection reset by peer]
JohnDoe_71Rus has joined #linux-sunxi
popolon has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
<speakman>
wens: Thank you. Although I've been through the Input section in kernel config many times, I still missed the CONFIG_EVDEV. Woops. :)
dearfibonacci has quit [Read error: Connection reset by peer]
dearfibonacci has joined #linux-sunxi
dearfibonacci has quit [Read error: Connection reset by peer]
dearfibonacci has joined #linux-sunxi
mnr has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
<speakman>
I still don't see how I can set LCD parameters to enable LVDS output.
premoboss has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<speakman>
Is it up to U-boot to initialize the frame buffer?
<MoeIcenowy>
speakman: which chip
<speakman>
MoeIcenowy: A20
<MoeIcenowy>
I have used mainline linux on a Viewsonic 133Q Tablet
<NiteHawk>
speakman: for "simplefb" yes
<MoeIcenowy>
which has a 13.3" LVDS
<MoeIcenowy>
you can easily configure a LVDS in u-boot config
<MoeIcenowy>
CONFIG_VIDEO_LCD_IF_LVDS=y
<MoeIcenowy>
CONFIG_VIDEO_LCD_PANEL_LVDS=y
<MoeIcenowy>
Then write CONFIG_VIDEO_LCD_MODE according to script.fex
<speakman>
MoeIcenowy: Thanks! Sounds great :)
<speakman>
Do you guys know if this can be altered within u-boot environment variables?
<speakman>
I have a couple of different displays I need to use
<MoeIcenowy>
speakman: Please prepare different u-boot
pekka10 has quit [Ping timeout: 260 seconds]
<wens>
speakman: no, these are compile time settings
IgorPec10 has joined #linux-sunxi
pekka10 has joined #linux-sunxi
<speakman>
Ok, I have to figure something out then. :)
tithrion_ has quit [Ping timeout: 240 seconds]
tithrion_ has joined #linux-sunxi
enrico_ has joined #linux-sunxi
IgorPec11 has joined #linux-sunxi
IgorPec10 has quit [Ping timeout: 252 seconds]
IgorPec11 has quit [Quit: Nettalk6 - www.ntalk.de]
IgorPec11 has joined #linux-sunxi
IgorPec11 has quit [Client Quit]
Nyuutwo has quit [Ping timeout: 240 seconds]
The_Loko has joined #linux-sunxi
Nyuutwo has joined #linux-sunxi
massi has joined #linux-sunxi
kelvan has quit [Remote host closed the connection]
Da_Coynul has joined #linux-sunxi
premoboss has quit [Quit: Sto andando via]
kelvan has joined #linux-sunxi
normalform has joined #linux-sunxi
normalform has quit [Ping timeout: 252 seconds]
iaglium has quit [Quit: Bed Time]
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
arossdotme has joined #linux-sunxi
arossdotme-planb has quit [Ping timeout: 246 seconds]
ricardocrudo has joined #linux-sunxi
kaspter has quit [Ping timeout: 246 seconds]
enrico_ has quit [Quit: Bye]
mnemoc has quit [Read error: Connection reset by peer]
reinforce has joined #linux-sunxi
Amit_T has quit [Ping timeout: 240 seconds]
tithrion_ has quit [Ping timeout: 240 seconds]
<oliv3r>
how do i interrupt the default sunxi bootloader, I recall there was some secret key combo to stop it
<speakman>
now I have my /dev/input/ directory with eventX device files. But that makes me thing; how are things supposed to use input devices if not through /dev/input/eventX ?
<NiteHawk>
oliv3r: usually you have a BOOTDELAY default of 2 seconds - if you press a key / send any character over the UART console, the autoboot will stop
<oliv3r>
your speaking of u-boot :)
<oliv3r>
i'm talking about boot0/boot1
<oliv3r>
old skool crappy allwinnner stuff
<oliv3r>
:)
<oliv3r>
boot1 actually, boot0 is still functional
<NiteHawk>
ah, okay :)
<NiteHawk>
wasn't that '0' or '1' for boot0?
<oliv3r>
that's what i thought
<oliv3r>
but can't find it on our wiki anymore
<oliv3r>
i'm smashing my head that I didn't document it when i wrote the piece about the BROM :)
<jmcneill>
I'm not familiar with Linux but does that mean it uses pll_periph for parent of ahb2?
orly_owl_ has joined #linux-sunxi
jstein_ has joined #linux-sunxi
jstein is now known as Guest85790
vagrantc has quit [Quit: leaving]
orly_owl has quit [Ping timeout: 246 seconds]
jstein_ is now known as jstein
<apritzel>
ssvb, agraf: I think pointing to the SRAM C usage patch in U-Boot as the culprit for breakage on the Pine64 was a bit premature
Guest85790 has quit [Ping timeout: 252 seconds]
<apritzel>
I bisected again, and in contrast to last time, where it pointed me to the SRAM C patch, it now tells me that TINY_PRINTF is to blame
<apritzel>
and indeed removing it from the Kconfig fixes it for me
<apritzel>
that seems to affect the SPL only
<apritzel>
so I guess the SRAM C was just helping because my old SPL was just not compatible with that change
<apritzel>
(you have to compile both the SPL and the proper U-Boot either with or without the patch)
<ssvb>
apritzel: was it a mistake when doing bisecting? or does reverting the SRAM C usage patch instead of TINY_PRINTF also help?
<apritzel>
ssvb: I am also wondering about that
<apritzel>
this time I bisected over the SPL
<apritzel>
last time over the real U-Boot
<ssvb>
could you please confirm it?
<ssvb>
SRAM C is a weird thing
<apritzel>
so I guess last time I just used the _old_ SPL (before the SRAM C patch), which was using the old addresses
<apritzel>
and AFAICT this change has to be on both SPL and proper U-Boot, right?
<apritzel>
also I think agraf was using the SPL from my old branch yesterda
<apritzel>
y
<ssvb>
I think that it is only expected to affect the SPL
<apritzel>
ssvb: but let me double check that ...
<ssvb>
initially I was trying to move the stack to SRAM C because the SPL with linked libdram is larger than 24K, and we still need some space for the stack
<ssvb>
apritzel: but with AHB1 clocked at 200 MHz, the SPL was mysteriously deadlocking
<ssvb>
apritzel: I tried to do simple read/write tests in SRAM C but these tests could not detect any problems
<ssvb>
apritzel: and considering that there is also the libdram blob, debugging this all was not a very attractive idea
<ssvb>
apritzel: then I tried to use SRAM C as a temporary buffer for the FEL based SPI flasher and could see that changing the AHB1 clock speed seems to affect the reliability
<ssvb>
apritzel: downclocking AHB1 to 100 MHz also resolved the "SPL stack in SRAM C problem" for me, which used to be a strange mystery before
<ssvb>
apritzel: but if you can observe something weird on your board, then some problem with SRAM C might be still there
zuikis has left #linux-sunxi [#linux-sunxi]
<ssvb>
Wizzup: yes, it should be compatible
<jemk>
apritzel: ssvb: don't know if this is relevant, but i think maybe sram C is still used for VE as it was in A10/A20, it only isn't documented anymore.
<jemk>
at least on h3 it is, as it only works there after the ve clock gate is enabled
IgorPec has quit [Ping timeout: 264 seconds]
<ssvb>
jemk: this is interesting, thanks
reinforce has quit [Quit: Leaving.]
reinforce has joined #linux-sunxi
<ssvb>
so can we also enable SRAM C on H3 in the bootloader if we poke some VE configuration bits?
jemk_ has joined #linux-sunxi
jemk has quit [Remote host closed the connection]
<Wizzup>
ssvb: ok, it's on my x200 - trying to flash libreboot
<jemk_>
ssvb: yes, by setting bit0 in 0x01c20064, but i don't know if it is safe
jemk_ is now known as jemk
<ssvb>
I always thought that the SRAM C in the H3 manual was a copy/paste error from some other SoC documentation :)
<jemk>
also the mapping bits in sysctrl reg0 still work, but the manual doesn't mention them anymore
<ssvb>
it's good to know this, and also testing/confirming it with A64 may be a good idea
<ssvb>
we actually currently only see 108K of SRAM C instead of 160K on A64, and there may be some knobs responsible for controlling this
<ssvb>
Wizzup: are you trying to use the sunxi-fel tool as a general purpose SPI flasher to hack your x86 laptop firmware? :-)
<ssvb>
Wizzup: just in case, it's best to be a bit careful with it, this code is still experimental
<jemk>
ssvb: on A20 only the first 62kB worked, the rest was strange, readonly, sometimes only one byte per word and such stuff, some bytes even changed themself
tlwoerner has quit [Ping timeout: 276 seconds]
<KotCzarny>
magic
matthias_bgg has joined #linux-sunxi
<nove>
it is guessed that those part of sdram (or all) represents the internal state of the video engine
<ssvb>
jemk, apritzel: if the SRAM C is owned by the video engine, then it not the right place for the ATF firmware either way
<jemk>
the lower part is the area for various tables (huffman, scaling lists,...) on a20, i haven't checked it anywhere else
<ssvb>
we could try to use it as a temporary storage for the stack or the heap early at the boot time (before the DRAM is initialized), but then the VE state probably needs to be properly configured too
<ssvb>
jemk: are these tables getting written there by the CPU during video decode?
<jemk>
on a20 the whole ve had to be clocked, on h3 it seems to be enough to enable the bus gate
<Wizzup>
ssvb: acknowledged. using the goodfet now
<Wizzup>
(since some time)
<Wizzup>
but since/if they are the same spi flash with same protocol, why would it now work? ;)
<jemk>
ssvb: yes, through the two sram regs (0x?e0/0x?e4)
<nove>
(in jpeg encoding, the quantization coefficients writing into the fifo register, can be seen in some (readonly) place of the sdram)
<ssvb>
jemk: I mean is the CPU ever addressing this data in SRAM C directly? because right now it looks like when the AHB1 clock speed is "too fast", then data corruption is happening
<jemk>
ssvb: not in normal operation
<jemk>
it can, but it doesn't
Shirasaka-Hazumi has quit [Ping timeout: 250 seconds]
<ssvb>
is this "cedar_devp->sram_bass_vir" register documented somewhere?
<apritzel>
ssvb: the plot thickens for tiny_printf
<apritzel>
with USE_TINY_PRINTF: DRAM Type = <hangs>
<ssvb>
aha, this makes sense :-)
<apritzel>
without: DRAM Type = 3 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3 ... boots on fine
<apritzel>
this is called from libdram
phipli has quit [Ping timeout: 244 seconds]
<jemk>
ssvb: it is system control (0x01c00000), but the manual doesn't say anything about these regs
popolon has joined #linux-sunxi
<ssvb>
apritzel: hmm, strings says "DRAM Type = %d (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3)" and this does not look like something that is expected to upset tinyprintf
<ssvb>
apritzel: still if you revert the stack move patch, does it start working even with tinyprintf?
xalius has joined #linux-sunxi
xalius has quit [Client Quit]
<ssvb>
apritzel: a potentially unreliable SRAM area used for the stack may cause all kind of problems
<apritzel>
no, reverting your patch doesn't help anymore
<apritzel>
that only fixed something because SPL didn't have it, but U-Boot had it
<apritzel>
so reverting it in U-Boot just put both binaries back to the same state
<apritzel>
just put a printf %d in front of the libdram call: it hangs as well
<apritzel>
so it's not related to some libdram pecularities
Mr__Anderson has quit [Remote host closed the connection]
nove has quit [Quit: nove]
mnr has quit [Quit: leaving]
tlwoerner has joined #linux-sunxi
Nacho has quit [Remote host closed the connection]
Nacho has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
iamfrankenstein1 has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 258 seconds]
iamfrankenstein1 is now known as iamfrankenstein
<apritzel>
ssvb: looks like a linking problem
afaerber has quit [Quit: Ex-Chat]
<apritzel>
div_out tries to access "zs", which gets address 4ff80104 in the binary
<ssvb>
apritzel: hmm, something like the .bss section in DRAM weirdness?
popolon has quit [Quit: WeeChat 1.3]
<ssvb>
apritzel: the sunxi-common.h header has #define CONFIG_SPL_BSS_START_ADDR0x4ff80000
Da_Coynul has joined #linux-sunxi
<apritzel>
yes, zs is in .bss
<ssvb>
I think that this shit was invented as a workaround for some poorly written code, which uses large global buffers (was it FAT filesystem support?)
<ssvb>
but sunxi does not have a large .bss section
<apritzel>
yes, initialising the two .bss variables in tiny-printf to 1 and thus moving them out of BSS fixes the problem
<ssvb>
and instead of fixing the FAT bastard, somebody thought that it is a very cool and creative idea to place the .bss section in DRAM and try to make sure that nobody uses the data allocated in .bss before the DRAM is initialized
<apritzel>
are there boards using FAT from SPL?
<apritzel>
RPi?
<apritzel>
ssvb: yes, just another prove that those assumptions _will_ break sooner or later
<ssvb>
I think that the sunxi linker script was just copy/pasted from omap
<apritzel>
any suggestion for better .BSS offset?
<apritzel>
maybe the broken SRAM C region ;-)
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<ssvb>
it's probably best to drop this .bss DRAM hack altogether, we are saving a lot more by just enabling TINY_PRINTF
<ssvb>
the SRAM C section is not available on every sunxi board
<apritzel>
yeah, was just a joke (because it reads as zero initially ;-)
<apritzel>
I meant the region after 108K
<ssvb>
:)
<apritzel>
anyway, in my build .bss is now 256 Bytes
<apritzel>
with tiny-printf enabled it's 264 Bytes
<ssvb>
anyway, we are saving X bytes by enabling TINY_PRINTF and wasting Y bytes (~256) by dropping the BSS DRAM hack
<ssvb>
X is much bigger than Y, and IMHO this is a good justification
<apritzel>
indeed
<apritzel>
so remove this symbol and let the linker figure it out?
<buZz>
i'm gonna preorder that FSFcertified cpucard and a desktopcase , i think :P
<ssvb>
LOL - "A20 Dual-Core ARM Cortex A7, 1.2 GHz"
<buZz>
nobody posted that link here yet? tsk tsk
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<ssvb>
why on earth so many Allwinner based boards advertise unrealistic overclocked CPU speed?
<apritzel>
why an A20? Seems like they don't even use the only A20 "killer feature" (SATA)
reinforce has quit [Quit: Leaving.]
<ssvb>
buZz: maybe it's a better idea to just buy some Olimex board with Allwinner A20 if you care about OSHW?
<buZz>
ssvb: oh its not my first A20
<buZz>
i'm just curious how fun EOMA68 could be, and wanna keep ppl that make fun stuff occupied and happy ;)
<ssvb>
does anybody really think that Allwinner A20 supposedly clocked at 1.2GHz is somehow better than the same Allwinner A20, but clocked at the nominal 1GHz?
<buZz>
no
<buZz>
well, probably loads of people
<buZz>
like, turbo buttons used to sell computers
<ssvb>
yeah, it's probably better for their marketing
<buZz>
ssvb: i guess what i care about most is people knowing about each others efforts, and ability to ride along on their productions
<MoeIcenowy>
EOMA68 is FSF certified?
<MoeIcenowy>
oh so free
<buZz>
MoeIcenowy: thats what that link mentions behind the 'Libre CPU board'
<buZz>
> Respects Your Freedom (RYF) Certification from the Free Software Foundation (currently in progress with no known blockers - a full refund will be available if certification is for some reason not granted)
<buZz>
(that bet is also part of the reason i want to back this project :P )
merbanan has quit [Ping timeout: 264 seconds]
<ssvb>
such marketing lies about the CPU clock frequency backfire in the end, contributing to the already existing "Allwinner makes buggy hardware" stereotypes
<MoeIcenowy>
Will sunxi BROM be considered as some "non-free blob"?
<MoeIcenowy>
or it should be considered as a part of hardware (SoC)?
<ssvb>
MoeIcenowy: no, because it is not upgradeable
<MoeIcenowy>
ssvb: so it's not blob?
<ssvb>
let me search the old Raspberry Pi story about the FSF requirements
<buZz>
raspi now has opensource bootloader :D
<buZz>
or well -a- opensource bootloader
<apritzel>
buZz: and the other one containing a tiny bit of GPL code ;-)
<buZz>
so its in breach of license?
<MoeIcenowy>
I think Replicant can be ported to sunxi device...
<MoeIcenowy>
Thus RMS can finally have a tablet to use :-)
<apritzel>
buZz: hard to prove, I guess
<apritzel>
though they once published some code snippet which had the very same comments ...
tlwoerner has quit [Ping timeout: 250 seconds]
<apritzel>
and the disassembly looks strikingly similar
<buZz>
:)
<ssvb>
MoeIcenowy: ok, I give up, but there was a story about the Raspberry Pi people actually seeking for FSF approval, and one of the possible solutions was to make their firmware non-upgradeable
* buZz
finds the defendant; guilty
<ssvb>
MoeIcenowy: then it can be treated as part of the hardware and be perfectly fine from the FSF point of view
<MoeIcenowy>
ah-oh
<MoeIcenowy>
interesting
<buZz>
hmm
<ssvb>
MoeIcenowy: FSF cares about the freedom to modify the code (if this is doable in principle), but if the code is inherently non-upgradeable then it is not an issue :-)
<ssvb>
both the hardware maker and the end users have equal rights in this case and nobody is more privileged than the other
<buZz>
thats excellent actually
Da_Coynul has joined #linux-sunxi
<apritzel>
I am not sure people want to see this code anyway, will only cause eye strain ;-)
tlwoerner has joined #linux-sunxi
Da_Coynul has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<ssvb>
"The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product."
<ssvb>
of course, different people may have different interpretations of this
apritzel1 has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
<ssvb>
the "secondary processor" concept is poorly formulated there, so it is a kind of loophole for the Raspberry Pi because their VPU core may be interpreted as "secondary"
<ssvb>
now I'm not so sure how the Allwinner's boot ROM fits there, but I guess the arisc firmware still does not need to be open source according to the FSF criteria