<jelle>
well i2s would mean a smaller case, and no usb overhead
<KotCzarny>
jelle, its digital, so you can take it away from the board (comparing to the builtin audio)
<KotCzarny>
also, it doesnt use up the usb port
<jelle>
KotCzarny: I'll have to check now if the C.H.I.P. has it
IgorPec has joined #linux-sunxi
<jelle>
ah no i2s
<KotCzarny>
yeah, a13 apparently has no i2s
lemonzest has joined #linux-sunxi
<jelle>
KotCzarny: weird, A10 has it and the GR8
fvogt has joined #linux-sunxi
<miasma>
i've bought boards with enough usb ports and used usb dacs. seem to work, but otoh i only use $1000 headphones and $4000 speakers. $5 ebay dacs are good enough for me
<jelle>
haha
<KotCzarny>
:)
<jelle>
KotCzarny: but the c.h.i.p. pro has it but that doesn't have a nice battery charger
<KotCzarny>
im going to use it with a20
<mripard>
jelle: it has the same battery charger than the CHIP
<KotCzarny>
mripard s/than/as/ ?
<jelle>
mripard: ah yes I see the pins
<jelle>
btw, does anyone else have ethernet issues for the H3 with u-boot? I think the 'in progress' part can be removed since it worked on my orange pi h3 devices https://linux-sunxi.org/Mainline_U-boot
<jelle>
can't test A83T/A64 though
iamfrankenstein1 has joined #linux-sunxi
<mripard>
KotCzarny: yes
Putti has joined #linux-sunxi
tkaiser has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
<tkaiser>
longsleep: But at least in germany it should be available through distributors soon. I would check with ALLNET first.
<longsleep>
tkaiser: yes, lets see what the price will be in EURO :)
<miasma>
so is sinovoip now the official bpi vendor? not lemaker?
alexxei has quit [Ping timeout: 246 seconds]
<tkaiser>
miasma: It's easy but even more complicated ;)
<tkaiser>
miasma: Foxconn orders a design, Xunlong does it as ODM, then SinoVoip does manufacturing and scaring customers away (look into that banana forum) and LeMaker is out of the game since approx a year now
<KotCzarny>
xunlong still does odm for bananas? o.O
iamfrankenstein has quit [Read error: Connection reset by peer]
<longsleep>
tkaiser: interesting thanks
iamfrankenstein1 has quit [Read error: Connection reset by peer]
<jelle>
hmm everyone makes A64 boards these days
<longsleep>
but nobody one with 3GB RAM .. :/
iamfrankenstein has joined #linux-sunxi
<miasma>
didn't 32-bit SoCs like h3 support up to 2GB too
<tkaiser>
longsleep: But I don't know whether GbE will be available and fear that it will be prone to overheating. And now with H5 (internal Fast Ethernet PHY) it doesn't make that much sense to use A64 at all unless battery is needed?
<longsleep>
tkaiser: yes, but i do not care much about the SoC itself, just arm64, GbE and 2GB+ RAM :)
<longsleep>
tkaiser: and it should be very cheap and small
<tkaiser>
I wonder whether the '3 GB max' can only be achieved with 12 Gb DRAM modules or also by combining 2 x 4 Gb + 2 x 8 Gb...
<KotCzarny>
longsleep: i guess you should wait for xunlong's 2gb offering then?
<longsleep>
KotCzarny: yes, i certainly will look into that one once the details are available
<tkaiser>
longsleep: Same size and connector positions as with http://linux-sunxi.org/Orange_Pi_Plus_2E -- not that small but most probably showing good heat dissipation.
premoboss has joined #linux-sunxi
berenm has quit [Quit: berenm]
<beeble>
wens: sure, even if i'm not sure if i qualify :)
bugzc has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 260 seconds]
whaf has joined #linux-sunxi
matthias_bgg has joined #linux-sunxi
<wens>
beeble: i did a clean up of PSCI, and now i get CC-ed on all U-boot PSCI patches
<wens>
beeble: i don't think i'm qualified either :)
<NiteHawk>
wens: patman loves you :)
<wens>
NiteHawk: what's that?
<KotCzarny>
maybe short from 'patch manager'
<NiteHawk>
exactly. it's a tool within u-boot that helps with automated patch submission - and it likes to CC people that have touched portions of the code ;)
Pepe has joined #linux-sunxi
<montjoie>
like getmaintainer.pl for linux
<wens>
NiteHawk: didn't know u-boot had this, thx
<KotCzarny>
might be also a tiny bot that likes to pat men
<zoobab>
@tkaiser "brute-force attempt" <- love the approach
apritzel has joined #linux-sunxi
<tkaiser>
zoobab: But testing was useless, with H5 BSP kernel in its current state you get 940 MBits/sec in RX direction after applying the usual tunables but are stuck at 500 Mbits/sec in the other direction. I think first the tons of patches longsleep did to A64 BSP kernel need to be applied there too.
scelestic has joined #linux-sunxi
<zoobab>
the difference is due to those length tunings?
<Net147>
I wonder if the Mali X11 blobs can be made to work on fbdev by writing a shim library...
apritzel has quit [Read error: Connection reset by peer]
<tkaiser>
zoobab: Nope, I tested through 0-7 TX delay and 0-31 RX delay in all variations and it's basically always the same. And in TX direction it seems to be CPU bound (or IRQ handling).
<Net147>
at least it would be simpler to have a single Mali blob that works with both X11 and fbdev
<tkaiser>
zoobab: IIRC with Pine64 it was similar in the beginning and improved then 'over time'. But 'over time' the kernel has also been patched up from 3.10.65 to 3.10.104 ;)
<Net147>
buZz: that just seems to copy framebuffers...
<Net147>
buZz: I was thinking a shim that pretends to be X11 so you don't need X11 server at all
<KotCzarny>
or well.. you know, get the source?
<tkaiser>
zoobab: And replacing the kernel with those from latest Xunlong 'server image' greatly decreased network speed. I put the board back into the drawer now :)
<KotCzarny>
tkaiser: when are you getting r40 board?
<tkaiser>
KotCzarny: As soon as Xunlong does the one from my wishlist ;)
<KotCzarny>
not risking the banana?
<tkaiser>
KotCzarny: No way
<buZz>
Net147: well the output of mali moves to fb, doesnt it?
<KotCzarny>
:)
<buZz>
Net147: i -think- the r6 mali drivers can do direct to fb
<Net147>
buZz: any idea how?
<buZz>
i mean the binary driver thats now supplied with the 'CHIP's image
<buZz>
it appears it just ignores X all together
<Net147>
buZz: last time I tried it, it handles X windowing and requires X to be running
<buZz>
well last night it didnt
<buZz>
are you sure you use r6 version of the driver? cause thats pretty new
<Net147>
buZz: I am using r6p0 on A20
<buZz>
hmm
<buZz>
maybe its just the setup on CHIP then
<mripard>
buZz: the setup on the CHIP uses X.
<buZz>
ah guess i'm confused by the lack of DRM
<buZz>
nevermind :)
apritzel has joined #linux-sunxi
terra854 has joined #linux-sunxi
perr has quit [Quit: Leaving]
lkcl has joined #linux-sunxi
<mripard>
and it has DRM
<mripard>
but we already had that discussion :)
alexxei has joined #linux-sunxi
<buZz>
yeah but not used for mali :)
Putti has joined #linux-sunxi
<scelestic>
i'm trying to figure out mainline kernel support for H3, it seems the only things missing (for me) would be THS and emac, emac i can find recent versions but THS seems to link to a patch dated november 2015, anyone know if this really is the latest?
<ErwinH>
tkaiser: I was looking at the code you linked, and noticed a difference in the dtsi files between branch 4.7 and 4.8/4.9 for sun8i-h3, maybe that's the reason why the THS doesn't work anymore?
<mripard>
Net147: yes, but nothing working at the moment
montjoie has joined #linux-sunxi
<Net147>
mripard: I2C driver for EDID + EDID parsing?
<mripard>
that works
<mripard>
but it's basically the only thing that does
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
tkaiser has joined #linux-sunxi
<tkaiser>
miasma: Was it you who were interested in 'suspend consumption' yesterday?
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
IgorPec has joined #linux-sunxi
cnxsoft has quit [Client Quit]
<tkaiser>
Anyway, just tried it out with OPi PC 2 and BSP u-boot/kernel: http://pastebin.com/FfkbYjba -- consumption now is +700 mW which is not that great.
<tkaiser>
But I fear I use still wrong DT settings. The Xunlong guy is still pretty busy fiddling around with DT and added the necessary fix to 'wake up' the board now with power key just yesterday. And the kernel I use does not even contain that feature so I have to restart anyway now.
<miasma>
tkaiser: ok that doesn't sound too great.
theone has joined #linux-sunxi
<tkaiser>
miasma: True, but maybe just settings aren't ok now. My powermeter showed 0.3W (PSU included) when I did tests with OPi PC. Which would translate to less than 250 mW in this mode.
<miasma>
tkaiser: it still sounds like the whole SoC is on but the clock rate is just lower? even 0.3W is quite a lot if it's just a simple mcu or something similar
<tkaiser>
miasma: Don't know exactly. But I just remembered that we had to build the kernel with CONFIG_SUNXI_GPIO_KEY=y to be able to wake up with the button defined in [gpio_power_key] section (PL03 on all H3 devices). No idea whether ARISC can take over and wait for PL03 to wake up A7 cores.
mzki has joined #linux-sunxi
mzki has quit [Client Quit]
mzki has joined #linux-sunxi
<tkaiser>
OTOH this whole design is meant for OTT TV boxes. Dimming the backlight of the 40" screen nearby by 1% has probably way more influence on overall consumption than standby mode of the OTT box
<miasma>
tkaiser: i get < 100 mW idle power consumption with a esp8266 (160 MHz, 32b single core) controlled solid state relay :) it has a full wifi stack and listents to ethernet packets
JohnDoe_71Rus has joined #linux-sunxi
<tkaiser>
miasma: Sure, the ESP8266 is not a OTT box ;) And as already said: I doubt Xunlong's current OPi PC 2 settings match reality yet.
<MoeIcenowy>
mripard: I thought that there's some clock change
<MoeIcenowy>
then I checked the clock
<MoeIcenowy>
I used the clk_dump json file in /sys/kernel/debug/clk
<MoeIcenowy>
Then I found that the position of lcd-ch0 changed
<ssvb>
tkaiser: ARISC can use GPIO just fine, the ar100-info project has everything that is necessary
<ssvb>
I'm not sure about IRQ handling though, nobody has tried this yet
victhor__ has quit [Ping timeout: 256 seconds]
<ssvb>
ARISC can handle its own interrupts just fine (the timer, the unknown instruction trap, etc.), but I don't know how to configure handling of the interrupts from GPIO
<ssvb>
naturally, you don't want to be just polling the PL03 pin if you care about power consumption
<tkaiser>
ssvb: Is Allwinner's ARISC stuff open or blobs?
<tkaiser>
ssvb: I neither want nor can. But it's interesting, especially the idea to run only on the OpenRISC core in ultra low-power mode and only activate the ARM cores on demand :)
afaerber has quit [Ping timeout: 245 seconds]
<KotCzarny>
yeah
afaerber has joined #linux-sunxi
<ssvb>
tkaiser: well, everything is already there, and you only need an OpenRISC toolchain to compile it
<KotCzarny>
i wonder if in that mode power consumption would be comparable to esp8266 and friends
<KotCzarny>
ssvb: how does it look from the dev side? is it c-like compiler or more like assembly?
<KotCzarny>
is there simple libc?
<tkaiser>
ssvb: We should suggest this to Brian Benchoff from HaD to write something about (this one is the Allwinner basher) ;)
<ssvb>
KotCzarny: it's just a GCC compiler with newlib as a standard C library
<KotCzarny>
curious.
<KotCzarny>
and you have all dram available or limited to something builtin openrisc core?
<wens>
mripard: probably pll-mipi can deliver a closer clock rate
<mripard>
MoeIcenowy: what puzzles me is that it calls twice the clk_set_rate function, and comes up with two different parents and rates
<KotCzarny>
ssvb, btw. how to app running on it, can it write to uart?
<MoeIcenowy>
mripard: yes I also wonder why they are clocked differently
<MoeIcenowy>
I will check the clock now (I patched ccu, entered system, stopped X, and TCON got restarted
<MoeIcenowy>
and TCON works now
<zoobab>
@ssvb this AR100 core is another core then the ARM cores on H3?
<wens>
MoeIcenowy: can you do a full dump?
<MoeIcenowy>
wens: yes
<MoeIcenowy>
do you want both the working one and not-working one?
<wens>
both
<wens>
thx
<miasma>
KotCzarny: in esp8266 most of the power consumption comes from wifi. the idle consumption with radio of is like 15 mW
<miasma>
*off
<mripard>
MoeIcenowy: thanks for looking into that :)
<miasma>
it seems AR100 is a lot lower powered
<MoeIcenowy>
I suddenly thought about clocks :-)
<MoeIcenowy>
it's some kind of inspiration :-)
<MoeIcenowy>
I will firstly revert my tcon changes (as the real reason is in ccu)
<MoeIcenowy>
maybe the reason why mripard didn't discover this issue is that he's not using a 800x480 screen :-)
The_Loko has joined #linux-sunxi
f0xx has quit [Ping timeout: 250 seconds]
simosx has joined #linux-sunxi
<MoeIcenowy>
wens, mripard: https://pastebin.anthonos.org/view/e0342504 , in which "patched" means patched ccu (removed pll-mipi parent), "vanilla" means ccu in 4.9-rc; "before" means before bug-triggering (which works), "after" means after bug-triggering (which doesn't work with vanilla ccu)
<wens>
MoeIcenowy: possible, another likely reason is that fex file timings already have the dot clock rounded to MHz
<wens>
MoeIcenowy: whereas you and i are using some 800x480 panel we dug up from panel-simple, and also need the 5% tolerance patch :)
<MoeIcenowy>
yes
<wens>
the tolerance lets you use the panel, but because of the clock rate granularity mismatch, it may try to use pll-mipi instead
<MoeIcenowy>
But I think pll-mipi should theortically also be usable, right>
<MoeIcenowy>
?
<wens>
it should, yes
<MoeIcenowy>
the problem is only that it's not capable of outputing such a clock?
<wens>
it should, yeah
vagrantc has joined #linux-sunxi
<MoeIcenowy>
wens: how can you fix this point of ccu?
<wens>
i'm digging through allwinner's kernel
<wens>
suprise suprise
<wens>
* surprise
<jelle>
that's a lot of suprises
<MoeIcenowy>
what's surprise?
<wens>
allwinner's kernel also sets bits 22 and 23 when enabling pll-mipi
<wens>
those bits are labeled "LDO{1,2}_EN" in A23 and A31 manuals
<MoeIcenowy>
also in A33 manuals
<wens>
MoeIcenowy: so, can you change the 'gate' part to BIT(31) | BIT(23) | BIT(22) and test again?
<MoeIcenowy>
ok
IgorPec has joined #linux-sunxi
<wens>
and if it works, please send a patch :)
<MoeIcenowy>
is it clean enough as a fix?
<wens>
what do you mean?
<MoeIcenowy>
just add the LDO bits into clock gate
<wens>
MoeIcenowy: why not? just document it properly
tkaiser has quit [Ping timeout: 260 seconds]
<wens>
you can say that pll-mipi didn't seem to be running, and after some comparison, found that allwinner's kernel enabled those 2 bits as well
<MoeIcenowy>
this time the clock works properly under pll-mipi
<MoeIcenowy>
wens: should I add it for A23/31?
<MoeIcenowy>
I only found the LDO enable code for A33
<wens>
i guess you should
<wens>
at least my A23 doesn't work, though i haven't dug into it :|
<MoeIcenowy>
I will submit only A33 at v1 patch
<ssvb>
KotCzarny: Yes, the ar100-info application uses UART for output. And I'm going to be awfully rude, but all the information about the OpenRISC core had been already documented. Just read it rather than asking questions.
* jbrown
perks up -- hmm? Is there an Allwinner thing with an OpenRISC core on it?
<rellla>
4 days left to the 4th anniversary of the first mainline commit :p
<MoeIcenowy>
rellla: congrats!
jernej_ has quit [Quit: Konversation terminated!]
<rellla>
not mine :) sunxi's
<MoeIcenowy>
oh also congrats to sunxi!
Pepe has joined #linux-sunxi
IgorPec has quit [Ping timeout: 246 seconds]
<MoeIcenowy>
wens: I think you should check your failure, and check whether the lcd-ch0 clock's parent is set to pll-mipi when your tcon fails to start
<wens>
MoeIcenowy: yeah, need to find time to do that
<wens>
MoeIcenowy: one of your tablets uses lvds?
<MoeIcenowy>
could you also test it on your A31s board?
<zoobab>
17 apr 2004 - GPL testing in court by the Netfilter/Iptables team, due to refuse to give source code of the Sitecom WL-122 (isl3893 based!). In the same time, some source code has appeared on the webserver of Sitecom.
<MoeIcenowy>
yes usual tablet users do not care about GPL ;-)
<MoeIcenowy>
they only care about that MediaTek tablets come with integrated baseband
<zoobab>
nice to have
<MoeIcenowy>
but allwinner cannot make basebands
<zoobab>
they have to add another chip
<MoeIcenowy>
to be honest I got interested into some Uniscom tablets
<zoobab>
which might lead to higher prices
<MoeIcenowy>
they *claims* to have A33 SoC, 2G RAM, high-quality IPS screen
<MoeIcenowy>
oh I broke the TF card in my A33 tablet when disassebling it, and it cannot work at all now...
<ssvb>
MoeIcenowy: A33 only has 16-bit DRAM bus width, the performance will be horrible if you use it with a good high resolution screen
<MoeIcenowy>
(Finally I know why in movies the spies will try to chew up the TF card, as thus it's really difficult to restore it
<MoeIcenowy>
ssvb: but it claims to be dual-channel...
<ssvb>
I believe that A13, A23 and A33 have been designed for cheap 800x480 LCD screens, where the memory bandwidth does not matter much
<ssvb>
are you sure about dual-channel?
<MoeIcenowy>
not so sure
<MoeIcenowy>
A33 is now not only a 800x480 chip... it is now the main tablet chip of Allwinner
<ssvb>
the manual says "Support 16-bit single-channel DDR3/DDR3L SDRAM"
<ssvb>
1024x600 is probably also OK
<ssvb>
what about the A64 tablets?
<MoeIcenowy>
yes I'm wrong :-(
<MoeIcenowy>
ssvb: at least I cannot find A64 ones on Taobao
<MoeIcenowy>
maybe someday I should go to Shenzhen to seek one in Huaqiang North
montjoie has quit [Ping timeout: 260 seconds]
<MoeIcenowy>
in 11.11 an A83T tablet by Onda is on sale in only ￥399 (~$70)
<tkaiser>
Didn't Allwinner try to position A64/A83T as 'hybrids' now? Like Azpen Hybrx?
<MoeIcenowy>
maybe it's the target of H
<MoeIcenowy>
although H64 is really A64 (the same chipid)
<MoeIcenowy>
H8 is very very like A83T (although chipid is different)
montjoie has joined #linux-sunxi
<MoeIcenowy>
I'm wondering whether there's any V3/V3s development boards...
<Pepe>
but Azpen Hybrx for early bird backers had good price for all components..
<MoeIcenowy>
several days ago a link to V3s datasheet/user manual is present in this channel
<tkaiser>
Pepe: Did you had a look at the display?
<MoeIcenowy>
allwinner's live is also difficult now :-)
<Pepe>
No, just images what they provide to their campaign.
<tkaiser>
MoeIcenowy: V3s has 64 MB DRAM integrated. And people want more than 2 GB on dev boards ;)
<MoeIcenowy>
;-)
<MoeIcenowy>
I have only one devborad with 2G RAM :-( (Pine64+ 2GB ver)
<tkaiser>
Pepe: Something I would want to work with should have a display where I can look into more than 10 minutes without getting headache ;)
<MoeIcenowy>
the second popular version of devboard is that which has a smaller RAM amount (256MB/512MB) but is very small in size
<tkaiser>
MoeIcenowy: s/size/price/
<MoeIcenowy>
e.g. Raspberry Pi Zero, Nano Pi NEO {,AIR}, Orange Pi Zero
<MoeIcenowy>
I really mean size
<Pepe>
I see your point. I agree with you, but I don't have this issue, so I'm clear XD
<MoeIcenowy>
although the size-limited boards are also price-limited
JohnDoe_71Rus has joined #linux-sunxi
<MoeIcenowy>
OK I think I can provide a full stable 3D acceleration stack on A33 Q8 800x480 tablets when 4.9 is out
<tkaiser>
Pepe: I thought about buying the Azpen to use it as Linux laptop. But then Pine64 LCD arrived which reminded me how cheap LCDs look like.
<MoeIcenowy>
some allwinner tablets come with acceptable LCDs, for example, my iNet D978 Rev02-based A33 tablet
<MoeIcenowy>
it's a 10" 1024x768 LVDS, very good quality, can be used to do long-time read
<MoeIcenowy>
(but the tablet is expensive in A33 world -- ￥460 even in Huaqiang North)
<MoeIcenowy>
ok mripard's xf86-video-armsoc fork have still some issues... will try to fix them
<MoeIcenowy>
and try to mainline sun4i part to xf86-video-armsoc
<tkaiser>
terra854: The 'not waking up after sleep' issue with Linux BSP kernel on Pine64 is most probably none.
<terra854>
tkaiser: none?
<TheLinuxBug>
I think he meant 'one'
<tkaiser>
terra854: wakeup sources have to be configured. And the power button needs a driver to be treated as a 'key', then it needs a definition in DT and then you can send the board to sleep and it wakes up at the press of a (the) button
<tkaiser>
Maybe this driver is simply missing. No idea, never tested but it should work since... it's a BSP kernel made for tablets
utente_ has joined #linux-sunxi
<terra854>
tkaiser: So basically this patch will let the attached power button act like those power/lock buttons on typical Android phones?
<tkaiser>
terra854: But I've no idea whether this is directly transferrable to A64. But since it works with Android it *has* to work with Linux BSP kernel right out of the box too. Don't believe this BS some stubborn old men tell over there that hardware only works with Android (LCD for example) ;)
whaf has quit [Quit: Leaving.]
whaf has joined #linux-sunxi
florianH has quit [Quit: Connection closed for inactivity]
utente__ has joined #linux-sunxi
<terra854>
tkaiser: Oh I get it, so it allows someone to boot the device via power button on the IR remote?
<terra854>
tkaiser: tbh, i am kind of confused on what that patch does
utente_ has quit [Ping timeout: 240 seconds]
<tkaiser>
terra854: I don't know really whether it can be applied (since 'wakeup from IR remote' is more of an OTT box thing). But at least every basic stuff like sleep/suspend that originates from Android should work with BSP kernel in Linux too.
<terra854>
tkaiser: Do we need any patches to uboot for the "wake on ir or power button" feature?
<tkaiser>
terra854: That would only be required to 'power on' the Pine64 via power key or ir remote. To wake from sleep only kernel functionality should be needed.
cptG_ has joined #linux-sunxi
enrico__ has quit [Quit: Bye]
cptG has quit [Ping timeout: 250 seconds]
<terra854>
tkaiser: So with the patch, it allows the Pine to do what the sleep command on Windows does?
<tkaiser>
And this has happened then a H3 board wakes up from sleep. But only if the kernel also has this sunxi gpio key setting enabled. Maybe it's just that.
<Pepe>
No, no. Backers inc. me are waiting for it. They should ship it at end of November.
<tkaiser>
Pepe: ok, would've been interesting to get the .dtb
<Pepe>
I can provide it to you, when I will receive it :-)
<tkaiser>
Pepe: Would really be interesting to be able to have a look. I would assume they use an I2C trackpad and maybe driver is already included in BSP sources.
<tkaiser>
Pepe: also interesting whether display is accessed through HDMI/eDP or not. But this should also be clear by looking at DT
IgorPec has quit [Ping timeout: 252 seconds]
phipli has quit [Ping timeout: 240 seconds]
<jelle>
apritzel1: hi
IgorPec has joined #linux-sunxi
leviathanch has quit [Read error: Connection reset by peer]
lamer14794131424 has joined #linux-sunxi
lamer14794131424 has quit [Client Quit]
leviathanch has joined #linux-sunxi
tkaiser has quit [Ping timeout: 260 seconds]
tkaiser has joined #linux-sunxi
The_Loko has quit [Ping timeout: 240 seconds]
apritzel1 has quit [Ping timeout: 260 seconds]
mzki has joined #linux-sunxi
leviathanch has quit [Remote host closed the connection]
leviathanch has joined #linux-sunxi
terra854 has quit [Quit: Connection closed for inactivity]
yann-kaelig has joined #linux-sunxi
jernej has joined #linux-sunxi
<Ntemis>
jernej: hi
<jernej>
Ntemis: hi
<Ntemis>
in the fex where it says dram_mr0 = 6208
<Ntemis>
can i use dram_mr0 = 0x6208?
<Ntemis>
or it wont work?
<KotCzarny>
ntemis: did you test limamemtester?
<jernej>
I don't know what these settings really are. I just adopted them. But that is great difference anyway, hex vs dec
<Ntemis>
yes but others are hex others are dec
phipli has joined #linux-sunxi
<beeble>
mripard: damn, applying patches a minute before i send out my email. now i look stupid :)
<Ntemis>
yes it is u r right
<jernej>
Aren't those settings used only in U-Boot anyway?
<jernej>
except maybe ram frequency
<Ntemis>
yes but will it read them?
<jernej>
no
<Ntemis>
in whatever format hex or dec
<tkaiser>
jernej: BSP u-boot only
<jernej>
mainline u-boot doesn't use them
<Ntemis>
ok
<jernej>
Ntemis: AFAIK there is no use changing ram settings in fex if you are using mainline u-boot
<jernej>
except frequency
<Ntemis>
am using sunxi one
<Ntemis>
same as your oe
<tkaiser>
jernej: legacy kernel honors the remaining info there only if CONFIG_DEVFREQ_DRAM_FREQ=y
<tkaiser>
jernej: And then *only* if throttling occurs
<jernej>
nope, my OE fork is using mainline kernel
<jernej>
*u-boot
<Ntemis>
oh
<jernej>
a long time, around 8 months?
<jernej>
a bit less
<jernej>
half a year maybe
<Ntemis>
jernej: i am adapting opipc2 dram timings to opipc
<jernej>
as I said, I don't really understand those ram settings, so I can't help here
<jernej>
but there are others here which can
<jernej>
I didn't yet start working on opi pc 2
<jernej>
to much fun with u-boot video driver...
leviathanch has quit [Read error: Connection reset by peer]