Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
Ntemis has quit [Remote host closed the connection]
Mr__Anderson has quit [Quit: Leaving.]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
jernej has quit [Ping timeout: 258 seconds]
Rondom has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
<naobsd> MoeIcenowy: ping
<naobsd> MoeIcenowy: I noticed esp8089 driver is based on old Rockchip SDK
apritzel has quit [Ping timeout: 276 seconds]
<naobsd> MoeIcenowy: there are few updates in official up-to-date tree https://github.com/rockchip-linux/kernel/commits/release-4.4/drivers/net/wireless/rockchip_wlan/esp8089
<naobsd> MoeIcenowy: I'm not sure these updates are useful for you, just FYI...
Uninstall has quit [Ping timeout: 248 seconds]
igraltist has quit [Ping timeout: 248 seconds]
igraltist has joined #linux-sunxi
Uninstall has joined #linux-sunxi
ganbold_ has quit [Quit: This computer has gone to sleep]
chomwitt has quit [Ping timeout: 240 seconds]
bugzc has joined #linux-sunxi
ganbold_ has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
ganbold_ has quit [Quit: Leaving]
agin_ has joined #linux-sunxi
<agin_> Hello all!
agin_ has quit [Changing host]
agin_ has joined #linux-sunxi
ErwinH has joined #linux-sunxi
popolon has quit [Quit: WeeChat 1.4]
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
Laibsch has joined #linux-sunxi
leviathan_ has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
juri__ has quit [Ping timeout: 240 seconds]
juri_ has joined #linux-sunxi
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
juri_ has quit [Remote host closed the connection]
ninolein_ has quit [Ping timeout: 245 seconds]
Andy-D has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
petr has quit [Ping timeout: 256 seconds]
<swiftgeek> has anyone seen Silead Ctouch Configure Suite ?
petr has joined #linux-sunxi
victhor has quit [Ping timeout: 260 seconds]
<agin_> MoeIcenowy: are you there?
libv_ has joined #linux-sunxi
libv has quit [Ping timeout: 264 seconds]
<agin_> I wonder can anyone here help me with DE2.0 registers?
<agin_> How do I route the DE2.0 Frame Buffer address to TCON1/0?
ErwinH has joined #linux-sunxi
Laibsch has quit [Read error: Connection reset by peer]
dave0x6d has quit [Quit: Connection closed for inactivity]
ErwinH has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
libv has joined #linux-sunxi
terra854 has joined #linux-sunxi
libv_ has quit [Ping timeout: 240 seconds]
ErwinH has quit [Ping timeout: 252 seconds]
pg12 has quit [Ping timeout: 240 seconds]
Laibsch has joined #linux-sunxi
pg12 has joined #linux-sunxi
<MoeIcenowy> agin_: I don't know...
<MoeIcenowy> you got TCON work?
<agin_> yes
<agin_> MoeIcenowy
<agin_> I hve Composite video on uboot
<agin_> though I am not sure what I should be seeing...
<MoeIcenowy> you saw nothing?
<agin_> there is a strange Green Image ... with squares
<agin_> it starts off black
<agin_> and then there is a green square image...?
<MoeIcenowy> something to mention:
<MoeIcenowy> TCON in H3+ has some testing functions
<MoeIcenowy> Try to change TCON1 Control Register at 0x0090
<agin_> the src select
<agin_> to BLUE instead of DE?
<MoeIcenowy> yes
<MoeIcenowy> it's a way to test tcon
<MoeIcenowy> and pipelines beyond tcon
<agin_> so what would be
<agin_> 0x01C0D090?
<MoeIcenowy> here
<MoeIcenowy> yes
<agin_> okay, so I change the value from
<agin_> 0x80100160 to 0x80100162 and the green squares all go blue
<MoeIcenowy> is the full screen blue now?
<agin_> no, its red squares...
<agin_> they were green
<agin_> funny, if I goto boot Linux
<agin_> and poke into that register again
<agin_> the screen is all Red
<agin_> 01: BLUE data(FIFO2 disable,RGB = 0000FF)
<agin_> does that mean the screen is all RED?
<agin_> as RGB = 0x0000FF = RED only
TheSeven has quit [Ping timeout: 240 seconds]
TheSeven has joined #linux-sunxi
<MoeIcenowy> from my test of it on A64 TCON1, it's really blue
ErwinH has joined #linux-sunxi
<agin_> hmmm, yea I get lots of red from both Linux and uboot
<agin_> okay I see some problem I need to fix
ErwinH has quit [Ping timeout: 240 seconds]
<agin_> okay MoeIcenowy , so its got a black screen
<agin_> and I get the test signal
<MoeIcenowy> "test signal" mean the blue screen of success? ;-)
<agin_> yes
<agin_> But no Console output...
<MoeIcenowy> now you'd deal with DE...
<agin_> I'm using the fork which has HDMI
<MoeIcenowy> does the serial log says a console is initialized?
<agin_> yes, it says composite
<agin_> 720x576i initialised
<MoeIcenowy> maybe you should change the mixer id
<agin_> where is this?
<agin_> the composer...
<MoeIcenowy> some DE2 have two mixers
<agin_> H3 page 423
<agin_> the mux...?
<MoeIcenowy> should be
<MoeIcenowy> let me have a look at moinejf's drm driver
<agin_> where can I find some DE2.0 info?
<MoeIcenowy> you add "#define DE_MUX1_BASE (u8*)(SUN8I_DE_BASE + 0x00200000)" after "#define DE_MUX0_BASE (u8*)(SUN8I_DE_BASE + 0x00100000)" in arch/arm/include/asm/arch-sunxi/display2.h
<MoeIcenowy> and change codes of composer init from DE_MUX0_BASE to DE_MUX1_BASE
<agin_> okay
<agin_> wait a sec
<agin_> i have to restart my VM
mpmc has quit [Ping timeout: 248 seconds]
agin__ has joined #linux-sunxi
<agin__> hey Moe
ErwinH has joined #linux-sunxi
camh has quit [Ping timeout: 248 seconds]
camh has joined #linux-sunxi
<MoeIcenowy> agin__: hey
<agin__> MoeIcenowy: I changed the Mux0 to the DE2_BASE +0x20000
<agin__> MoeIcenowy: I changed the Mux0 to the DE2_BASE +0x200000
<MoeIcenowy> so ugly ;-)
<agin__> just as a test, but nothing
<MoeIcenowy> MUX0 is really at 0x100000, and there's really a MUX1 at 0x200000
liushuyu has joined #linux-sunxi
<agin__> any other ideas?
agin_ has quit [Ping timeout: 260 seconds]
<MoeIcenowy> still do not work?
<agin__> hmmmm
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy> is DE2's clock properly initialized?
<agin__> probalby not....
<agin__> :)
ErwinH has quit [Ping timeout: 252 seconds]
<MoeIcenowy> oh the global control registers should also be initialized...
<MoeIcenowy> setbits_le32(SUN8I_DE_RESET_REG, 1); to setbits_le32(SUN8I_DE_RESET_REG, 4);
mpmc has joined #linux-sunxi
<MoeIcenowy> setbits_le32(SUN8I_DE_GATE_REG, 1); to setbits_le32(SUN8I_DE_GATE_REG, 2);
<MoeIcenowy> setbits_le32(SUN8I_DE_MOD_REG, 1); to setbits_le32(SUN8I_DE_MOD_REG, 2);
<agin__> where is that?
<agin__> Global Control Registers....
<agin__> ?
<liushuyu> MoeIcenowy: I wonder if sun8i efuse bug can be workarounded? Seems like your guys made a lot of conversations on this
<MoeIcenowy> agin__: yes
<MoeIcenowy> liushuyu: yes, can be workarounded
<agin__> MoeIcenowy: I can't set the DE registers...
<MoeIcenowy> ?!
<agin__> I check my clocks again
<MoeIcenowy> the registers keep to be 0 ?
<agin__> yea...
<agin__> But the RST and GATE are setup
<agin__> they are both set
<MoeIcenowy> how about MOD?
<agin__> what is that?
<agin__> Where is this MOD reg?
<MoeIcenowy> oh you mean the external reset and gate controlled by CCU?
<MoeIcenowy> if registers keep to be 0 usually it's clock issue
<agin__> Okay
<agin__> so I have cheked the CCU Reset, Gate they are good
<agin__> I have also checked the DE Clk Reg, that's good its routed to DE PLL
<MoeIcenowy> can you set the registers at 0x01000000?
<agin__> yes
<MoeIcenowy> but you cannot set the registers at 0x01200000 ?
<agin__> no
<agin__> how do i set up the DE clocks properly
<agin__> there is Gate, Bus, RST and Sel
<agin__> maybe I am not doing that correct
<MoeIcenowy> just clean Sel
<MoeIcenowy> and what do you mean about Bus?
chomwitt has joined #linux-sunxi
<agin__> okay, to set the registers at 0x01200000, i need to set
<agin__> 0x01000000 to: 00000003 00000003 00000005
mosajjal has joined #linux-sunxi
<mosajjal> Hi everyone
<mosajjal> I read your logs and saw my name
<mosajjal> what's up ? :D
ErwinH has joined #linux-sunxi
<agin__> do you know about the DE2.0?
<mosajjal> rellla: hello
<agin__> OH WOW ITS WORKING!!!
<agin__> BUT its really messed up
<agin__> HAW HAW
<agin__> I can see The Penguin in the top left!
ErwinH has quit [Ping timeout: 276 seconds]
Laibsch has quit [Ping timeout: 255 seconds]
LargePrime has quit [Ping timeout: 240 seconds]
jernej has joined #linux-sunxi
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
<agin__> be back in a bit
<jernej> mosajjal: You managed to get r6p2 mali driver?
<mosajjal> jernej: yes I did
<jernej> Can you post original tarball somewhere? EULA date is suspicious, dated 2014 but driver version is for sure newer
foxx_ has joined #linux-sunxi
tomcheng76 has joined #linux-sunxi
<mosajjal> the original tarball didn't contain any EULA and licenses. had a discussion with "fbturbo" admins, went back to allwinner tech supp and asked for it, they said it's the same as all Mali Drivers
<mosajjal> so I copied one and put it there
<jernej> well, there are two licenses, old and new
<jernej> new one is more relaxed
<mosajjal> like I said, allwinner didn't share any lisences directly to me
<mosajjal> they seem to be very vague about it
<jernej> I really wonder why they don't want to put any clear licenses anywhere
<jernej> as they are afraid of something
<mosajjal> if you look at the commits, the licences were added later. also, the original tarballs are there, I think in the original commit. If you get history of the git repo. I've removed the tarballs myself
<mosajjal> idk about any of that
<mosajjal> but I'm interested in getting it to work
<mosajjal> specially in chromium
<jernej> I know, but a lot of people here won't touch anything without a proper license, which imo is still an issue
LargePrime has joined #linux-sunxi
<jernej> the only instance Allwinner provided mali license is in TinaOS release, but that version is generally unsufel, unless you are using musl libc replacement
iamfrankenstein has quit [Ping timeout: 245 seconds]
<mosajjal> what's the version of Mali driver on TinaOS ?
<mosajjal> and where can I download TinaOS ?
ErwinH has joined #linux-sunxi
<jernej> r5p2
muvlon has quit [Ping timeout: 245 seconds]
IgorPec has joined #linux-sunxi
<jernej> and it is changed OpenWRT
<jernej> at least it seems so
<jernej> I'm not sure if anyone here tried to use it
<mosajjal> so the files are useless because of EULA
ErwinH has quit [Ping timeout: 252 seconds]
<jernej> they are useful for private use of course, I'm almost managed to make it work
<jernej> ANAL but I guess EULA must come from Allwinner
<ssvb> mosajjal: they are useful because they show that recent mali drivers still support a number of different configurations (ump/dmabuf/fbdev/wayland/...)
<mosajjal> it's pretty straightforward to get it to work
<mosajjal> I guess
<mosajjal> at the time, I didn't have the patched U-boot with HDMI support in it
<mosajjal> that made it difficult
<mosajjal> ssvb: you know something about those files !! hi !
<mosajjal> they did send me the weston/wayland patches as well
<jernej> ssvb: yes, what about it? doesn't seem legit?
<ssvb> jernej: well, that license notice looks like somebody just took the standard ARM license and edited it to replace ARM with Allwinner
leviathan_ has quit [Remote host closed the connection]
<jernej> so does anybody know how the proper license looks like?
<ssvb> maybe we just should contact ARM people at http://malideveloper.arm.com and ask if everything looks fine to them
<ssvb> if yes, then everything is great
<ssvb> if no, then we will know what to ask from Allwinner
<jernej> great plan, if they bother to answer
<ssvb> well, they do provide some sort of support there
<mosajjal> great plan. but keep in mind Allwinner always do shady stuff when it comes to licensing.
HeavyMetal has quit [Ping timeout: 264 seconds]
<ssvb> usually they reply that the blobs need to be obtained from the SoC vendor
<jernej> ok, worth trying then
<mosajjal> and trust me, allwinner won't send anything
<mosajjal> i've contacted them like 100 times
<mosajjal> regarding EULA
<mosajjal> they refer me to their legal team
<jernej> but they sent you driver immediatelly?
<mosajjal> not immediately. after 20 emails :P
iamfrankenstein has joined #linux-sunxi
<mosajjal> but they responded quickly
<mosajjal> when I mentioned EULA in my emails, they stopped replying.
<jernej> :)
<mosajjal> I'm gonna send
<mosajjal> the original email text
<mosajjal> let me take a screenshot
<ssvb> maybe you shouldn't do this without their permission
<mosajjal> it's one line of text
<mosajjal> what's the worst that could happen?
jernej has quit [Ping timeout: 258 seconds]
<mosajjal> ok I won't
chomwitt has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
Laibsch has joined #linux-sunxi
DullTube has joined #linux-sunxi
<MoeIcenowy> maybe someone should try to ask in Chinese ;-)
<ErwinH> If only we knew someone who speaks Chinese
<MoeIcenowy> mosajjal: I do respect your patience ;-)
<mosajjal> MoeIcenowy: LOL
<dgp> I'm guessing the answer will be something like "We don't even have a license from ARM for this stuff so don't expect a proper EULA any time soon"
<MoeIcenowy> oh maybe I should use "admire"
cnxsoft has quit [Read error: Connection reset by peer]
medvid has quit [Ping timeout: 252 seconds]
<MoeIcenowy> mosajjal: are your binary dma-buf ones?
<MoeIcenowy> (I didn't found libUMP
<MoeIcenowy> 'oh found libUMP... Orz
<MoeIcenowy> weird
cnxsoft has joined #linux-sunxi
<mosajjal> MoeIcenowy: yeah it's there. actually I almost gave up on it but I thought it wouldn't be fair not to share it with everyone
msevwork has joined #linux-sunxi
maz has joined #linux-sunxi
florianH has joined #linux-sunxi
agin__ has quit [Ping timeout: 260 seconds]
medvid has joined #linux-sunxi
<ssvb> MoeIcenowy: do you have anything personal against libUMP?
f0xx has joined #linux-sunxi
<ssvb> mosajjal, jernej: I have added a question here, but did not mention Allwinner yet - https://community.arm.com/graphics/f/discussions/134/where-is-the-user-space-driver-x11-on-the-mali-450/207
massi has joined #linux-sunxi
JohnDoe71rus has joined #linux-sunxi
<mosajjal> ssvb: let's see what they reply
JohnDoe_71Rus has quit [Ping timeout: 248 seconds]
wzyy2 has joined #linux-sunxi
agin_ has joined #linux-sunxi
<rellla> mosajjal: hi. thanks for joining!
<mosajjal> rellla: hi! my pleasure :)
IgorPec has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
wzyy2 has quit [Read error: Connection reset by peer]
medvid has quit [Ping timeout: 252 seconds]
<agin_> hey my Composite Output from uBoot is all green....
medvid has joined #linux-sunxi
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dh1tw has joined #linux-sunxi
wzyy2 has joined #linux-sunxi
dh1tw has quit [Ping timeout: 240 seconds]
Laibsch has quit [Read error: Connection reset by peer]
<agin_> MoeIcenowy: Any ideas?
tkaiser has joined #linux-sunxi
<tkaiser> willmore: Nightly image for OPi PC2 being broken yesterday was as expected. The only purpose of this is now getting productive feedback for ErwinH's new DVFS table for OPi PC2. Please see https://forum.armbian.com/index.php/topic/2869-armbian-for-orangepi-pc2-allwinner-h5/page-4#entry23975 for details.
Worf has joined #linux-sunxi
<MoeIcenowy> ssvb: I want to use mainline kernel and drm
agin__ has joined #linux-sunxi
<MoeIcenowy> The X11 one is UMP, but fbdev and wayland ones are dmabuf
agin_ has quit [Ping timeout: 260 seconds]
INdek has joined #linux-sunxi
liushuyu has quit [Quit: Konversation terminated!]
INdek has quit [Remote host closed the connection]
paulk-collins has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<MoeIcenowy> Is there anyone still WIP on H3 THS?
<ErwinH> Haven't seen progress. I'm using Megous driver atm.
<ErwinH> I only altered it to use the correct formula for H5.
agin_ has joined #linux-sunxi
agin__ has quit [Ping timeout: 260 seconds]
cobra_koral has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
fkluknav has joined #linux-sunxi
<agin_> MoeIcenowy: My Composite Output is very Green looking :(
<agin_> But I can make out the text a bit
<jelle> cool!
<agin_> Why would it be green?
<agin_> I mean the Hsync clocks etc look okay as I'm getting the picture
<MoeIcenowy> I don't know...
mosajjal has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<agin_> hey I found the colour bar!
<MoeIcenowy> ?!
<agin_> but it is not correct
<agin_> its overlapping itself...
<agin_> yes, actually if I run the colour bar test in Linux, it looks the same
<jelle> do you have a public branch and howto mod the orange pi zero on the wiki?
<agin_> as the uBoot, so I reckon it is the buffer
<agin_> who are you talking to?
<agin_> jelle?
<jelle> agin_: to you :P
<agin_> do I have a public branch? yes I have forked a uboot
<agin_> a howto mod?
<agin_> I haven't modded anything tho
<jelle> oh it's just ground / signal from the cable => two pins
matthias_bgg has joined #linux-sunxi
<agin_> yea
bugzc has quit [Ping timeout: 245 seconds]
<agin_> I guess I should git commit something
<agin_> but I have a feeling the DE output is broken
<agin_> Because the colour bars are looking good on both Linux and uboot
clonak has quit [Ping timeout: 240 seconds]
<tkaiser> jelle: Regarding the USB ports on all (!) the Expansion boards for OPi Zero: Why/how should they work if they're not defined in DT (for strange reasons I fail to understand)?
<jelle> tkaiser: since MoeIcenowy doesn't have an expansion board
<jelle> tkaiser: yes that's what I realized yesterday when I went to bed. Will add and test it tonight :)
<MoeIcenowy> in fact, since mripard do not want to add them
<tkaiser> jelle: No, the reason is that 'common sense' is that these Expansion headers on NanoPi NEO and Orange Pi Zero should be useless with mainline kernel ;)
<jelle> MoeIcenowy: oh why?
<jelle> tkaiser: huh?
<tkaiser> Now we have a NAS Expansion board that doesn't work as expected (using all the 13 pins in the same way), the other HAT that can not be used at all with mainline kernel and so on.
<MoeIcenowy> they do not want to enable components that needs an expansion board
<jelle> MoeIcenowy: ok, so u-boot has to do some magic?
<MoeIcenowy> s/they/he
<MoeIcenowy> he want us to use DT overlay for it
<MoeIcenowy> I do have schedule to buy one expansion board ;-)
<jelle> MoeIcenowy: I'd be happy to hack on it, I guess I should look at what mripard did with the C.H.I.P.
<MoeIcenowy> but it's Chinese New Year now (or precisely it's 1.28 that is the Day 1, Month 1 in the Chinese lunar date)
<MoeIcenowy> (this year)
Worf has quit [Quit: Konversation terminated!]
<tkaiser> FriendlyELEC designs a whole ecosystem around the many (!) NanoHATs and pin mappings are always the same: http://www.cnx-software.com/2017/01/20/30-bakebit-starter-kit-adds-sensors-buttons-to-your-nanopi-neo-neo-air-boards/
<jelle> FriendlyELEC, LibreELEC,..
<MoeIcenowy> jelle: it seems that CHIP have an automatic expansion board detect framework based on 1-wire bus
<jelle> MoeIcenowy: yup
<MoeIcenowy> but for Nano Pi Neo and Orange Pi Zero we have nothing
<tkaiser> MoeIcenowy: Only that what the vendors uses and implements in various HAT variotions like http://www.friendlyarm.com/index.php?route=product/product&product_id=160
<jelle> MoeIcenowy: I think their expansion board has indeed a 1 wire sensor (with an address) to check which board it is
<agin_> Is there a way to override the frame buffer in uBoot?
<MoeIcenowy> jelle: whose?
<MoeIcenowy> opi or npi?
<jelle> MoeIcenowy: C.H.I.P.
<tkaiser> jelle: There's is absolutely no need for that. The pin mappings are defined
<MoeIcenowy> jelle: yes
<tkaiser> At least on Orange Pi Zero and NanoPi (I really don't care about CHIP)
<MoeIcenowy> for Orange Pi Zero, it has a small problem:
<MoeIcenowy> although 12 pins on the header is fixed-function
<MoeIcenowy> the 13th one (IR) is a muxed GPIO
<tkaiser> MoeIcenowy: So what? There are now 2 Expansion boards around that use it as IR and *all* useable OS images depend on this specific pin used for IR hard coded.
<tkaiser> So there might be one person on this earth who wants to use this pin as GPIO and that's the reason the whole 13 pin header is made useless?
<tkaiser> Really?
<MoeIcenowy> mripard thinks every expansion board needs a device tree overlay
<MoeIcenowy> yes it's a theortically pretty solution
<MoeIcenowy> but not so friendly to consumers
<MoeIcenowy> tkaiser: for Armbian, I think you can implement some option in uEnv that loads the overlay
<tkaiser> mripard seems to ignore that there is only one DT overlay needed since *all* Expansion boards expect identical pin mappings
<mripard> then it's easy to support
<MoeIcenowy> and, mripard, jelle, tkaiser, everyone: Do we need to open a repository for DT overlays?
<jelle> MoeIcenowy: huh why?
<MoeIcenowy> for handling different DT overlays for different boards ;-)
<tkaiser> MoeIcenowy: In Armbian we patch the DT currently since no user understands why USB can't be used with Expansion boards or DIY expansions (and there are a lot and USB is always on the same pins -- it makes absolutely no sense to disable it!)
<jelle> I thought that the DT overlays where handled in u-boot and therefor work in linux?
<MoeIcenowy> jelle: U-Boot have the ability to change the DT to pass to Linux.
<MoeIcenowy> one of the abilities are applying DT overlays
<jelle> yup
<jelle> so then the overlays live in u-boot right?
<MoeIcenowy> it live in where is accessible from U-Boot
nashpa has quit [Quit: Going away]
nashpa has joined #linux-sunxi
<MoeIcenowy> and, I think after a DT overlay repository is started, users can add not only expansion boards for expansion bus, but also expansion boards for "Raspberry Pi-compatible" bus
fkluknav has quit [Ping timeout: 256 seconds]
<MoeIcenowy> for example, SPI LCDs that is designed to be inserted into the 26-pin bus
<jelle> I have one of those :-)
<jelle> MoeIcenowy: but I first want to get the expension board working out of the box
<MoeIcenowy> yes
<MoeIcenowy> in fact I think everything except IR can be enabled by default
<MoeIcenowy> as they're all fixed-function pins
<MoeIcenowy> but I don't think mripard will agree
<jelle> mripard: how would you propose that we handle the expansion boards for the orange pi zero?
* MoeIcenowy currently working on making sunxi_sid driver properly support H3
<agin_> what is SID?
<MoeIcenowy> agin_: the on-chip eFUSE
<MoeIcenowy> which stores some unified ID of the chip
<agin_> hmmm, is there any way to force a colour to the uboot screen?
<agin_> because it's a sea of green with some text that I can barely read with this composite
<MoeIcenowy> and, also importantly, the thermal sensor calibration data is also in SID after H3
<agin_> I have a feeling the console buffer and the DE aren't talking to each other in the right format
<agin_> I've sort of checked its all X888
<agin_> format
<agin_> any advice is greatly appreciated
<agin_> or something to look for
<mripard> jelle: create an overlay, apply the overlay at boot
<jelle> mripard: ok, but how do we detect if we need to apply the overlay?
<mripard> if all the expansions boards are using the same pins and are using the same treatment, then you don't need to write multiple overlay, a single one is enough.
<mripard> this is board specific, I don't know
<mripard> well designed boards have a way to do that based on some bus or GPIOs
<MoeIcenowy> jelle: for orange pi zero you can now just apply it by default
<mripard> but if you feel like it's always the same thing, you can just apply it all the time
<jelle> well there is the nas and normal expansion board
<MoeIcenowy> jelle: they're using same pin configurations
<jelle> MoeIcenowy: do we have schematics of them?
<MoeIcenowy> I think nope
<jelle> I'll try to create an overlay then just to educate myself :)
<MoeIcenowy> you can try from opi0 standard expansion board
<MoeIcenowy> as it's very simple one ;-)
<jelle> MoeIcenowy: yup thanks :)
<MoeIcenowy> you can at first only care usb
<jelle> I guess I can use any remote to test IR
<MoeIcenowy> mripard: for 4.10-rc5 the mmc clk timeout issue still exists
<MoeIcenowy> how will it be fixed in 4.10?
<msevwork> can I ask one off-topic question please...Which keywoard do I need to search for in WiringOP library so i know that it works (if i change the pin mapping) on orange pi zero
<msevwork> there must be some command where it is talking to the underlying system
<MoeIcenowy> KotCzarny: do you still remember the whole SID readout result?
<mripard> MoeIcenowy: I sent the patch, wens acked it, so we're just waiting for the maintainer to pick it up
<MoeIcenowy> and why is not the dt convert accepted in 4.10?
<mripard> MoeIcenowy: but usuall a good way to have bugs fixed in time is also to report it in time...
<MoeIcenowy> I do not want this kind of critical bug live aftre rc...
<MoeIcenowy> after
<mripard> they were supposed to be initially, but because of the holidays, they were not
<mripard> so they got delayed
<MoeIcenowy> thus get it into a difficult situation...
tsuggs has quit [Read error: Connection reset by peer]
JohnDoe71rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
JohnDoe_71Rus has joined #linux-sunxi
muvlon has joined #linux-sunxi
agin_ has quit [Ping timeout: 260 seconds]
agin_ has joined #linux-sunxi
<agin_> How can I check if the cfb_console is filling the video buffer correctly?
<agin_> When I do a colour test with the Composite Video Out in uboot, it looks like it does in Linux which is working.
<agin_> so I guess it's the input to the TVEncoder which is faulty
<agin_> but that comes from the DE
<agin_> which is filled by the cfb
<agin_> I've checked the graphic_device structure
<agin_> and the parameters look okay
<MoeIcenowy> you can try to look at the register map of DE2
<MoeIcenowy> with sunxi_display2.c and display2.h you can dig out where the framebuffer is.
<MoeIcenowy> KotCzarny: I did a SID readout patch
<MoeIcenowy> megous: ^
<agin_> Is this all the information on DE2 there is?
<agin_> display2.c and display2.h?
<MoeIcenowy> not all
<MoeIcenowy> but enough
<MoeIcenowy> for *all* info you can only refer to BSP driver
<agin_> where is the latest BSP driver?
dizz74 has joined #linux-sunxi
<MoeIcenowy> agin_: http://filez.zoobab.com/allwinner/h2/201609022/lichee/ is the most recent BSP codedrop we can get
<agin_> yes I have that lichee
<agin_> This would be a lot easier with proper documentation....
<agin_> seems like I'm trawling around looking for things
<MoeIcenowy> no proper documentation...
<MoeIcenowy> what a pity
<agin_> is there proper documentation or can I just not find it?
<MoeIcenowy> no one here found it
<dizz74> Hi. I have device Allwinner R16(=A33) with 1Gb RAM(2 chips x 512Mb). If I reball chips to 2x1024Mb(total 2Gb RAM) - what i need to remake in software that device seen the second Gb of ram?
<MoeIcenowy> I think no one have already seen any A33 devices with 2G DRAM
<MoeIcenowy> so no one can promise the software supports it
<wens> dizz74: mainline u-boot auto-detects the DRAM size, provided the combination is actually supported
<muvlon> sheeeesh reballing for just another gig of ram?
<MoeIcenowy> wens: but for 2GiB RAM I don't think it can be supported...
<MoeIcenowy> no one tested it
<MoeIcenowy> and there may be some quirks -- since A23 have only the ability to use 1GiB
<wens> right, that's what i meant about it being supported
<dizz74> ok, thank you
<muvlon> software support is not even the bigger problem
<muvlon> the memory controller needs to be able to handle it
<wens> yup
<MoeIcenowy> and for test it I think one must also do reball as there's no existing device with such large memory
<muvlon> but I'm told all these ARM SoCs have basically regular LP-DDR3 memory controllers
<muvlon> so you could maybe even make a board with a regular SO-DIMM socket
<muvlon> which spares you the hard part of reballing (getting stuff off is comparatively easy)
<muvlon> scratch that, you still need to get the SoC onto the new board
<muvlon> do the reball :D
<wens> lol
<MoeIcenowy> but the boards are often made to work with a few chips
<MoeIcenowy> not many chips on SO-DIMM
fkluknav has joined #linux-sunxi
<muvlon> Are there any allwinner-based boards with SO-DIMM sockets?
<MoeIcenowy> I think no
<dizz74> It has already been reballed. But loading with showing only 1 Gb.
<dizz74> And another question: I need info about new SoC T3. except http://www.allwinnertech.com/uploads/pdf/2016080317583523.pdf May be somebody knows something
<tkaiser> dizz74: T3 is most probably just an R40 with a different business unit being responsible for
<dizz74> for car spec.
<MoeIcenowy> dizz74: currently Allwinner is divided into several bussiness units
<MoeIcenowy> and nearly each BU holds a SoC series
<MoeIcenowy> but they do not have so many SoC designs
<MoeIcenowy> so many SoC designs exist in different BU with different name
<MoeIcenowy> it's like the problem R16 = A33
<MoeIcenowy> as R16 is from the BU of IoT and A33 is from the BU of tablets
<dizz74> and about R16. I opened R16 datasheet : support 2Gb RAM
<MoeIcenowy> yes A33 datasheet also says so
<MoeIcenowy> mripard: oh I want to tell another problem about my new A33 tablet: it cannot load zImage from MMC properly
<MoeIcenowy> (but with the same SD card on another tablet, it's bootable
MACscr has quit [Ping timeout: 255 seconds]
<MoeIcenowy> oh maybe I got a buggy device...
<MoeIcenowy> it cannot even use SD well in stock Android
apritzel1 has joined #linux-sunxi
mosajjal has joined #linux-sunxi
juri_ has joined #linux-sunxi
Andy-D has joined #linux-sunxi
<mripard> MoeIcenowy: that's a pretty bad sign :/
<MoeIcenowy> sorry for annoying you :-(
<MoeIcenowy> although it
<MoeIcenowy> although it's really weird
<ssvb> MoeIcenowy: you can try to downclock DRAM
<MoeIcenowy> mripard, apritzel1: P.S. I'm modelling after mripard's CCU and pinctrl driver for sun5i to writing driver for sunxi-h3-h5
<ssvb> MoeIcenowy: your symptoms may be caused by DRAM corruption, this was not exactly uncommon
<MoeIcenowy> but on stock Android it failed with "cmd 18 RD DCE"
Patsie has quit [Ping timeout: 240 seconds]
<ssvb> hmm, maybe the SD card slot is defective then
<ssvb> but at least the SPL is getting loaded correctly, right?
<MoeIcenowy> U-Boot is also
<MoeIcenowy> but U-Boot cannot finish to loda zImage
<ssvb> hence I'm suspecting the DRAM corruption or maybe some sort of overclocking
<agin_> which lichee file is all the DE2.0 stuff in?
<agin_> similar to the sunxi_display2
<agin_> .c
<MoeIcenowy> mripard: can I make PINCTRL_SUN8I_H3 at bit 1 and PINCTRL_SUN50I_H5 at bit 2?
<MoeIcenowy> I think it won't conflict PINCTRL_SUN5I_A10S at bit 1 and PINCTRL_SUN5I_A13 at bit 2, right?
<mripard> I'd rather not have conflicts
<MoeIcenowy> so h3 at bit 4 and h5 at 5?
<MoeIcenowy> when will we run out of it ;-)
apritzel1 has quit [Ping timeout: 255 seconds]
tkaiser has quit [Quit: jIRCii - http://www.oldschoolirc.com]
Seppo has joined #linux-sunxi
<Seppo> anyone know what might cause serial8250: too much work for irq
<Seppo> [192818.700790] serial8250_interrupt: 46 callbacks suppressed
<Seppo> <3>serial8250: too much work for irq51
f0xx has quit [Ping timeout: 240 seconds]
<Seppo> also: [192694.618114] INFO: rcu_preempt self-detected stall on CPU<c>
fkluknav has quit [Ping timeout: 258 seconds]
<MoeIcenowy> mripard: here's a problem: for H3 there's only one ts controller, and the pin is named "ts"
<MoeIcenowy> but for H5 there's multiple and must be called "ts0" "ts1" "ts2"
fkluknav has joined #linux-sunxi
<mripard> just call it ts0 in both cases then
<swiftgeek> btw anyone with access to wenku baidu?
<MoeIcenowy> mripard: unfortunately I think I must go back to split H3's driver with H5...
<MoeIcenowy> as H5 have PF as a new GPIO bank with interrupt support
<MoeIcenowy> and on 0x220 offset of H3 it's the interrupt controller of PG
<MoeIcenowy> 0x220 of H5 is the interrupt controller of PF
mosajjal has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
mhlavink has quit [Ping timeout: 240 seconds]
<Net147> I guess I will try out Mali r6p2 on fbdev and see if it works
vishnup has quit [Ping timeout: 240 seconds]
robogoat_ has quit [Ping timeout: 240 seconds]
bbrezill1 has quit [Ping timeout: 258 seconds]
bbrezill1 has joined #linux-sunxi
robogoat has joined #linux-sunxi
mhlavink has joined #linux-sunxi
vishnup has joined #linux-sunxi
<mripard> MoeIcenowy: ok
<willmore> tkaiser, I understood that from the thread and was hoping to do similar testing. I'll keep following the thread.
yann-kaelig has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
<walkiry> Hi guys, do you know where i can find a A64 rom dump?
<MoeIcenowy> mripard: for CCU I added the new clock in H5 with ID after the original clocks in H3
<MoeIcenowy> in order to keep dt compatibility
<mripard> good
chomwitt has joined #linux-sunxi
leviathan_ has joined #linux-sunxi
<willmore> Oh, I love this: "BTW: This is also not a call for stupid requests ('When will Armbian be ready...'). Those will be either deleted or moved to a special thread 'The user requests that prevent any dev doing any more work'."
<agin_> what does DE2.0 UI's have to do with TCON1?
<agin_> there are 4 sets of conifgs
<MoeIcenowy> finished the refactor of H5 code
<MoeIcenowy> can "default MACH_SUN8I || MACH_SUN50I" work?
<MoeIcenowy> oh my god... it's not MACH_SUN50I but (ARM64 && MACH_SUNXI)
<wens> hehe
<MoeIcenowy> maybe we will sometime add back a MACH_SUN50I ;-)
<MoeIcenowy> silly again... it's not MACH_SUNXI but ARCH_SUNXI
agin_ has quit [Ping timeout: 260 seconds]
DullTube has quit [Quit: Leaving]
popolon has joined #linux-sunxi
max___ has joined #linux-sunxi
max___ has quit [Client Quit]
cnxsoft has quit [Quit: cnxsoft]
ninolein has quit [Ping timeout: 240 seconds]
ninolein has joined #linux-sunxi
<willmore> ErwinH, my PC2 is alive. Thank you. I'm doing some basic stability testing to start with.
<MoeIcenowy> do you have any branch that merges apritzel's H5 support and FIT support?
<ErwinH> But armbian uses a patch for FIT support.
<ErwinH> Or this one if you want a all in one sollution: https://github.com/ehoutsma/u-boot-h5
<MoeIcenowy> I have already bl31 and other things ;-)
<MoeIcenowy> and I'm debugging my kernel support
<willmore> I guess I better get the 3d printer back online so I can print cases. tkaiser wants data from PC2s inside enclosures.
IgorPec has joined #linux-sunxi
[Awaxx] has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
reinforce has joined #linux-sunxi
[Awaxx] has joined #linux-sunxi
TheSeven has quit [Remote host closed the connection]
elvirolo has joined #linux-sunxi
<elvirolo> hi all
<elvirolo> I'm trying to setup my olinuxino lime2 board's rootfs to be able to be decrypted via ssh. Does anyone know which modules should be loaded by the initramfs to be able to connect to the network via eth0?
<elvirolo> is it realtek?
vickycq has joined #linux-sunxi
The_Loko has joined #linux-sunxi
<elvirolo> or dwmac_sunxi
<elvirolo> ?
<TheLinuxBug> hmm, not sure the answer to your questions but if your doing that on SDcard I imagine the little board will run slower than molasses
<TheLinuxBug> seeing as you already have a lot of slowness on sdcard you add the overhead of more CPU time for encryption for every access
<TheLinuxBug> may slow to a halt?
<MoeIcenowy> elvirolo: why don't you compile your needed driver in the kernel?
<TheLinuxBug> I had never thought of trying to setup an armboard with luks like that though
<TheLinuxBug> would be interested to hear your outcome if you get it working
<TheLinuxBug> willmore: was the current nightly for PC2 (desktop) worth testing? is that what you were looking at earlier?
<elvirolo> TheLinuxBug: Might be slow, but I'd like to know :)
IgorPec has quit [Ping timeout: 255 seconds]
<elvirolo> MoeIcenowy: I don't know which one it is ^^
<elvirolo> but i think I found it
<TheLinuxBug> elvirolo: you should be able to find out which module is loading at boot time, you then need to compile it as module to be loaded by initrd assuming that works
<TheLinuxBug> check dmesg when board is booted and see which driver is loaded for ethernet
<elvirolo> TheLinuxBug: thanks
<elvirolo> looks like it's sun7i-dwmac
<elvirolo> ...which is not loaded, so no
<elvirolo> ok, the module name is dwmac_sunxi
<elvirolo> thank you :)
<elvirolo> (I'll write a guide if I manage to get this running)
<TheLinuxBug> ;)
<TheLinuxBug> willmore: nm I grabbed it and it seems like it just loops, so guess will wait for next nightly ;p
<willmore> TheLinuxBug, yes, I used the 27 nightly and it works fine on mine. I didn't use the 'desktop' version as I don't need all that fluff.
<willmore> The 26 version was flawed and, I believe, has been deleted.
<Guest65167> Hi there.
<Guest65167> <MoeIcenowy> mripard: for 4.10-rc5 the mmc clk timeout issue still exists
<Guest65167> <mripard> MoeIcenowy: I sent the patch, wens acked it, so we're just waiting for the maintainer to pick it up
<Guest65167> mripard: could you be so kind and point to the submitted patch ?
Guest65167 is now known as danand1
<danand1> Thanks alot :)
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-sunxi
<willmore> cpuminer running on PC2 with four cores gets ~3.2KH/s at runs 1056MHz between 71-75C. Seems pretty nicely tuned. I
<willmore> I'll put it in a box and see how that changes things.
foxx_ has quit [Ping timeout: 245 seconds]
IgorPec has joined #linux-sunxi
vishnup has quit [Ping timeout: 260 seconds]
tyler-baker has quit [Read error: Connection timed out]
tyler-baker has joined #linux-sunxi
vishnup has joined #linux-sunxi
<elvirolo> now, what is boot.imx?
<elvirolo> u-boot.imx*
mhlavink has quit [Ping timeout: 248 seconds]
<elvirolo> I can ping the machine, but I can't ssh into it
<MoeIcenowy> thus you may just forgot sshd
<elvirolo> no I haven't
<elvirolo> at least I don't think so
martinayotte has joined #linux-sunxi
diego_r has joined #linux-sunxi
elvirolo1 has joined #linux-sunxi
elvirolo has quit [Ping timeout: 264 seconds]
fkluknav has quit [Ping timeout: 245 seconds]
massi has quit [Ping timeout: 240 seconds]
IgorPec2 has joined #linux-sunxi
leviathan_ has quit [Ping timeout: 264 seconds]
TheSeven has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
fl_0 has quit [Ping timeout: 255 seconds]
fl_0 has joined #linux-sunxi
fkluknav has joined #linux-sunxi
IgorPec has quit [Ping timeout: 240 seconds]
muvlon has quit [Ping timeout: 245 seconds]
afaerber has joined #linux-sunxi
xal1us has joined #linux-sunxi
IgorPec2 has quit [Ping timeout: 240 seconds]
MACscr has joined #linux-sunxi
jernej has joined #linux-sunxi
iamfrankenstein has quit [Ping timeout: 264 seconds]
<TheLinuxBug> hmm
MACscr_ has joined #linux-sunxi
MACscr has quit [Read error: No route to host]
leviathan_ has joined #linux-sunxi
MACscr_ has quit [Ping timeout: 240 seconds]
lkcl has quit [Ping timeout: 255 seconds]
<MoeIcenowy> ErwinH: do you know where should I write the sun50i-h5.itb to?
<Seppo> anyone has any idea what this might be
nove has joined #linux-sunxi
massi has joined #linux-sunxi
The_Loko has quit [Quit: Leaving]
elvirolo has joined #linux-sunxi
MACscr has joined #linux-sunxi
elvirolo1 has quit [Ping timeout: 240 seconds]
dh1tw has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
Mr__Anderson has quit [Remote host closed the connection]
xal1us is now known as BenG83_
paulk-collins has quit [Remote host closed the connection]
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-sunxi
apritzel1 has joined #linux-sunxi
massi has quit [Remote host closed the connection]
popolon has quit [Quit: WeeChat 1.4]
<jernej> agin_: Please push your current TV out code on git and I will take a look what is missing
ErwinH has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
lkcl has joined #linux-sunxi
ErwinH has quit [Ping timeout: 240 seconds]
Andy-D has quit [Ping timeout: 240 seconds]
fkluknav has quit [Ping timeout: 256 seconds]
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has quit [Changing host]
yann-kaelig has quit [Quit: Leaving]
ErwinH has joined #linux-sunxi
Ntemis has joined #linux-sunxi
ErwinH has quit [Ping timeout: 260 seconds]
leviathan_ has quit [Ping timeout: 240 seconds]
ErwinH has joined #linux-sunxi
ErwinH_ has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
ErwinH_ has quit [Ping timeout: 240 seconds]
elvirolo has quit [Quit: Leaving.]
elvirolo has joined #linux-sunxi
ErwinH_ has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
IgorPec has joined #linux-sunxi
ErwinH_ has quit [Ping timeout: 252 seconds]
vinimac has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
terra854 has quit [Quit: Connection closed for inactivity]
IgorPec has quit [Ping timeout: 255 seconds]
apritzel1 has quit [Ping timeout: 255 seconds]
<TheLinuxBug> Anyone around with either an Orange Pi PC or Orange Pi PLus 2E that would be willing to test something for me - will require writing an image to SDcard and testing booting it - if you have a few minutes to test just drop me a PM. Thanks.
<plaes> TheLinuxBug: test what?
<TheLinuxBug> plaes: pm
<MoeIcenowy> apritzel: on my Pine64 when your newest ATF branch and spl-fit-rfc branch combined it cannot boot
<TheLinuxBug> plaes: left you a pm about it when you have time to check
<MoeIcenowy> hangs after "NOTICE: BL3-1: Built : 03:54:42, Jan 27 2017"
<MoeIcenowy> (I workarounded the PLL_CPUX set, and it works again
netlynx has quit [Quit: Ex-Chat]
ErwinH has joined #linux-sunxi
elvirolo has quit [Ping timeout: 258 seconds]
ErwinH has quit [Ping timeout: 252 seconds]
iaglium has quit [Ping timeout: 240 seconds]
juri_ has quit [Ping timeout: 264 seconds]
reinforce has quit [Quit: Leaving.]
juri_ has joined #linux-sunxi
juri_ has quit [Ping timeout: 256 seconds]
apritzel has joined #linux-sunxi
iaglium has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
cptG_ has joined #linux-sunxi
iaglium has quit [Ping timeout: 264 seconds]
cptG has quit [Ping timeout: 264 seconds]
nove has quit [Quit: nove]
juri_ has joined #linux-sunxi
juri_ has quit [Ping timeout: 255 seconds]
lemonzest has quit [Quit: Leaving]
HeavyMetal has quit [Quit: BNC Services Provided by the ASoTnet IRC Network.]
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
HeavyMetal has quit [Changing host]
afaerber has quit [Quit: Leaving]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
afaerber has joined #linux-sunxi
Andy-D has joined #linux-sunxi
hp197 has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
ErwinH has quit [Remote host closed the connection]
ErwinH has joined #linux-sunxi
ErwinH has quit [Ping timeout: 252 seconds]
juri_ has joined #linux-sunxi
vinimac has quit [Quit: Leaving]
Mr__Anderson has quit [Remote host closed the connection]
agin_ has joined #linux-sunxi
<agin_> What is the difference between the UI and VI registers in the DE2.0?
<jernej> VI is for video channels and UI is for UI channels, obviously. First ones supports YUV color space and second RGB
<jernej> so you want to use UI
<jernej> but, not every SoC has same configuration of VI & UI channels
<jernej> but according to drivers/video/sunxi/disp2/disp/de/lowlevel_sun8iw7/de_feat.c you should be ok with using channel 1 (same as for hdmi)
<agin_> jernej: so is the UI channel for cursor movements they say?
<agin_> like on a desktop?
<agin_> but each channel has 4 layers
<jernej> I don't really now in detail, but UI channel is for full graphical interface, because traditionally it uses RGB color space
<jernej> including cursor, but not limited to
<jernej> HDMI framebuffer uses UI channel and it works pretty well
<jernej> no reason why it wouldn't work with TV too
<agin_> I see, because my composite video out looks nutty
<agin_> its very green
<agin_> and the text is a bit squashed