<apritzel>
(at the bottom of that page there is the PDF link)
<apritzel>
I will ask some guys here today to see if that fits
<apritzel>
If it does (what I hope), then I am very much for using this interface
<apritzel>
since we will get the whole Linux part (code + bindings) for free, basically
<libv>
apritzel: can you write up how to get such a thing set up?
<apritzel>
the image?
<libv>
like a manual build howto
<mripard>
apritzel: hmm, nice
<libv>
an image is of only short term use
<apritzel>
libv: yes that was my plan
<mripard>
it still misses a few things, notably in the clocks part
<libv>
apritzel: ok, thanks
<mripard>
we're doing more than simply getting / setting the rate
<apritzel>
libv: I will try to use the "it compiles" or "fastmodel boots" breaks today ;-)
<apritzel>
libv: I will post instructions how to put your own kernel and/or rootfs in there
<apritzel>
which should be comparatively easy
naobsd has quit [Quit: naobsd]
<libv>
apritzel: try to use an existing manual build howto as a guideline
<apritzel>
libv: sure
<libv>
:)
<mripard>
apritzel: we need to set the clock phase for the MMC clocks for example, and it doesn't seem to be covered so far
<apritzel>
mripard: you found that in the last 5 minutes? Impressive!
<mripard>
well, I wrote a good part of the clock drivers, so I know what to look for :)
<mripard>
is it something Juno specific, or something that ARM really wants to push ?
<apritzel>
the later
<apritzel>
Juno is mostly the reference platform to demonstrate this
<apritzel>
will peek Lorenzos brain over lunch and can possibly tell you more later today
<mripard>
cool, thanks
<adj_>
KotCzarny, PCs were successful because other companies were capable of making PC clones that could run MS DOS, not because users could install the OS they wanted
<mripard>
apritzel: cool, thanks :)
<KotCzarny>
adj: ms dos wasnt the only one, that's the point, you could've put any os, any hardware
tkaiser has joined #linux-sunxi
pietrushnic has quit [Ping timeout: 260 seconds]
<KotCzarny>
i must say that opipc works nicely with chromium and fbturbo, even without g2d and other accel
<KotCzarny>
i can retire my laptop
<jelle>
hah
<jelle>
KotCzarny: using mainline image?
<KotCzarny>
nope, loboris jessie
<KotCzarny>
i'll switch to mainline when audio and other feats will be supported
<jelle>
aha ok
<KotCzarny>
but i bet mailine could make this config even faster
<KotCzarny>
*mainline
<tkaiser>
KotCzarny: A guy called Jacer provides another OS image based on loboris' that should also provide GPU acceleration. Just in case you want to try it out
pietrushnic has joined #linux-sunxi
<KotCzarny>
tkaiser, same kernel or mainline?
<tkaiser>
3.4.39 (loboris)
<KotCzarny>
hrm
<tkaiser>
Regarding laptop replacement I would believe H3 is the wrong SoC (no PMIC/charging support)
<KotCzarny>
tkaiser, well, i meant desktop laptop (with browser)
<KotCzarny>
not the mobile unit
<KotCzarny>
i can always put external 2x18650 unit with some regulators
lemonzest has joined #linux-sunxi
<KotCzarny>
but opipc eats a bit more than i estimated, ~10W in idle
<tkaiser>
1.6W for me ;)
<KotCzarny>
hrm?
<KotCzarny>
unless my wall meter does funky things
<tkaiser>
It does
domidumont has quit [Quit: Leaving.]
<KotCzarny>
pity onboard regulator doesnt export any v/a sensors
domidumont has joined #linux-sunxi
<tkaiser>
But that can be misleading too. Depends on the schematics of the board in which mode PMIC reports what level of consumption
<KotCzarny>
hrm
<tkaiser>
You can try it out easily with A20 and your Lamobo R1. Only when you use the battery connector for 5V DC-IN then AXP209 provides the whole amperage.
<tkaiser>
If you use DC-IN you get values way lower.
<wens>
yeah, i lot of boards bypass the pmic for 5v
<wens>
s/i/a/
<KotCzarny>
when i compare axp reading and external usb charger they are quite close together
<KotCzarny>
not the same, but close
<tkaiser>
KotCzarny: But it always depends on the board. So even when the PMIC can be queried the value you get are questionable
<tkaiser>
At least undervoltage situations can be detected easily. But amperage/consumption are a different thing
<tkaiser>
BTW: Anyone here has seen Allwinner's R16 in the wild or announced?
<tkaiser>
Should be H3 with PMIC support
<KotCzarny>
hmm, i must say that firefox (iceweasel 38) also is quite snappy on opipc
<tkaiser>
't forget to run update-kernel.sh and fix-thermal-settings afterwards (as usual when using anything based on loboris' stuff)
<KotCzarny>
tkaiser: thx, going to finish configuring this first, then i'll check it out
<KotCzarny>
is there any way to get 800x600 mode on hdmi?
<tkaiser>
'apt-get install fbset'
bmeneg has quit [Quit: \o]
<KotCzarny>
already installed, didnt think it would work
<tkaiser>
Choose the right settings, put the fbset call in /etc/rc.local and you're done
iamfrankenstein has joined #linux-sunxi
_massi has joined #linux-sunxi
bmeneg has joined #linux-sunxi
igraltist has joined #linux-sunxi
HeavyMetal has quit [Ping timeout: 264 seconds]
yann|work has joined #linux-sunxi
<KotCzarny>
hrm
<KotCzarny>
doesnt seem to work
<KotCzarny>
fbset says it changed mode, but monitor is still on 576p
<tkaiser>
Did you put the call in /etc/rc.local followed by a reboot?
<KotCzarny>
nope, i've killed xdm and ran from console
<oliv3r_>
ssvb: load was some python code that kept the cpu toggeling between 800 - 1000 mhz, like a lot lot. Because of that we got segfaults from said python code. We just disabled the cpufreq entirely for now, but yeah using the max voltage for all settings would atleast check if it is the voltage or the frequency scaling.
<oliv3r_>
ssvb: having said that, it's very very hard to reproduce, the tests would always fail, but able to run for half - 1 day
HeavyMetal has joined #linux-sunxi
HeavyMetal has joined #linux-sunxi
<oliv3r_>
ssvb: you think it would be possible to modify cpuburn-arm to put its load just below 100%? adding some nop's/sleeps maybe?
oliv3r_ is now known as oliv3r
Netlynx has joined #linux-sunxi
Netlynx has quit [Changing host]
Netlynx has joined #linux-sunxi
<KotCzarny>
tkaiser, fbset doesnt seem to work
<KotCzarny>
even if i try 640x480-60 etc
<tkaiser>
At boot and called from /etc/rc.local?
<KotCzarny>
boot wouldnt change things i think because console is initialized already anyway
<KotCzarny>
even tried: fbset -a 800x600-60 -rgba 8/16,8/8,8/0,8/24
<tkaiser>
Ok, then if you do not want to try out what's recommended then it's time to stop here
<KotCzarny>
k, gotta put in rc.local, but afaik linux boot sequence it wont work
<KotCzarny>
(you can punch me if it will work)
<KotCzarny>
didnt work
avph_ has joined #linux-sunxi
avph has quit [Read error: Connection reset by peer]
avph_ is now known as avph
<KotCzarny>
i think all fbset does is internal scaling
<KotCzarny>
actual vid mode on the connector stays the same as the one in script.bin
<KotCzarny>
how can i change kernel cmdline? (there is only script.bin and uImage
<apritzel>
is the linux-sunxi mailing list moderated for non-subscribers?
p1u3sch1 has quit [Ping timeout: 265 seconds]
<apritzel>
just sent a post from another account and can't see it there yet
<NiteHawk>
apritzel - afaik: no. it might take a few minutes for your message to show
p1u3sch1 has joined #linux-sunxi
<lordlod_>
Hi, I'm trying to get my head around uboot device trees if anyone can give me a hand
<apritzel>
NiteHawk: cheers, will try more patience then ;-)
<lordlod_>
I have a bananapi, working fine with hdmi output and I want to switch it to using the LCD
<lordlod_>
I think the three framebuffer outputs are defined in sun7i-a20.dtsi but buggered if I can figure out how it selects which one to use
<wens>
lordlod_: u-boot selects it, since the framebuffer is setup by u-boot, and the hardware just keeps outputting
<lordlod_>
wens: sounds good, how do I ask u-boot to select the lcd instead of hdmi output?
<plaes>
lordlod_: have you defined LCD configuration in u-boot conf?
<lordlod_>
plaes: I had a working fex file, I couldn't see any instructions on how to configure the mainline cmd format
<ssvb>
apritzel: I had a hope that arisc could be somehow used as a secondary core for handling user programmable real time tasks even in Linux in addition to its primary purpose keeping a watch while the device is in a deep sleep
<ssvb>
apritzel: but having a single purpose firmware, signed or embedded in the kernel, avoids all the headaches trying to make it safe and secure when running custom user's code
focus has quit [Read error: Connection reset by peer]
focus has joined #linux-sunxi
<KotCzarny>
ok, checked power meter again, ~5W for opipc
<KotCzarny>
(idle)
focus has quit [Read error: Connection reset by peer]
focus has joined #linux-sunxi
Quintus23M has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
domidumont has quit [Quit: Leaving.]
<tkaiser>
KotCzarny: then something's wrong
<KotCzarny>
might be my wall meter, or ac adapter going crazy under load
<KotCzarny>
(right now i power more than orange from it, but bought good 65W ac-adapter and will install it in a few days)
<tkaiser>
Or dvfs settings. I would check using bin2fex
<pjwl>
Hello, I have question. I have the Allwinner A13 board from Olimex and would like to connect a GPIO Matrix Keyboard, how can this be done in the script.fex?
<apritzel>
ssvb: mmh, so that sounds like we should have a RTOS running on the arisc?
<apritzel>
which has one task running doing the PMIC control
<apritzel>
allowing other tasks to be loaded there as well.
<pjwl>
Thanks. Will the matrix keypad driver (who is in Linux) be avaible then and where to put the keymap information?
<plaes>
dunno
<pjwl>
Thanks for you help. Would it be possible to delete the script.fex and use the device tree instead with the Sunxi Linux Kernel?
<ssvb>
apritzel: the arm code can reset arisc and upload new firmware at any time
<ssvb>
apritzel: but in order to make things clean, arisc would just first get a nice request to shutdown itself
<ssvb>
apritzel: but just running any arbitrary code on arisc is dangerous because it has full access to physical RAM and all the peripherals, at least by default
<apritzel>
but I think the SoC can be configured to prevent access from non-secure world to the arisc, right?
<wens>
yes, but not the other way around
<apritzel>
right, good point
<apritzel>
just having some realtime capable execution units in the back sounded tempting to me
<apritzel>
tbh more from a hackers point of view
<ssvb>
there are some configuration knobs which can be used to restrict access
<ssvb>
the main question is whether they are sufficient to prevent the user's LED-blinking arisc code from accidentally or maliciously messing up the system
lynxis_ is now known as lynxis
<apritzel>
I guess we could just leave those "LED blinking games" to bare-metal systems
<apritzel>
and leave this out of Linux at all, then
<apritzel>
since you are right that it's not secure
<apritzel>
so for Linux the arisc would run the PMIC mgmt code and that's it
<apritzel>
firmware would load it and prevent Linux from tinkering with it except for the specified interface
pjwl has quit [Ping timeout: 252 seconds]
maz_ has quit [Ping timeout: 264 seconds]
maz_ has joined #linux-sunxi
lemonzest has quit [Quit: Leaving]
tkaiser has joined #linux-sunxi
yann|work has quit [Ping timeout: 264 seconds]
leio has joined #linux-sunxi
vagrantc has joined #linux-sunxi
ganbold has quit [Quit: This computer has gone to sleep]
mzki has quit [Quit: leaving]
ganbold has joined #linux-sunxi
ganbold has quit [Remote host closed the connection]
ganbold has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
vishnu_ has quit [Quit: Leaving]
cptG has joined #linux-sunxi
cptG_ has quit [Ping timeout: 276 seconds]
domidumont has joined #linux-sunxi
engidea-vr has quit [Quit: Konversation terminated!]
<ssvb>
is there no way to ensure that the DT backwards compatibility is not broken?
Guest21129 is now known as fredy
* ssvb
wonders when the DT will finally become mature enough
<ssvb>
the way is is now, the ACPI camp is going to win pretty soon
<apritzel>
ssvb: ACPI? on embedded? fortunately not ...
<ssvb>
apritzel: well, it may end up with something like "DT is an inferior solution for suckers who are stuck with poorly designed cheap hardware, ACPI is a proper solution for serious people" conclusion :-)
<maz_>
and ACPI doesn't have any bug...
<maz_>
as someone who reads the spec and look at what implements, I have to laugh...
<maz_>
what people implement*
<apritzel>
so you mean ACPI is OK when actually don't need it (because you have PCI, for instance) ;-)
<ssvb>
at the end of the day, any x86 hardware can boot a generic Linux kernel (but admittedly they are trying hard to mess this up with UEFI)
<ssvb>
ARM is much worse in this respect for the end users
<apritzel>
x86's advantage is mostly due to: a) hardcoded addresses (0x3f8 is _always_ the UART) and b) the rest being discoverable buses
<apritzel>
so to speak they have _one_ platform
<apritzel>
anyway: I am strongly against breaking the DT compatibility above
<diego71>
apritzel: x86 have one platform -> almost
<apritzel>
well, they don't have thousands of platforms ;-)
<diego71>
apritzel: for example I see many laptop having the same audio hardware intel, but often wired in different way. So you channel left is right on some laptop, or second audio output are the good one...
<maz_>
on the other hand, the thousand of platform model is what has enabled ARM to strive on the embedded side, because you can produce HW that fits an application.
<diego71>
and every producer have is copy of the driver, with the good configuration. On linux was a mess
<apritzel>
but do you really have to do differentation over the memory mapping or the UARTs?
<maz_>
diego71: that's an unfortunate side effect, which is why I have a job!
<maz_>
apritzel: well, differentiation is a problem when pushed to the extreme, but hey...
<diego71>
and having an hardcoded addresses is not scalable ...
<maz_>
diego71: we haven't had any hardcoded address in a long while...
soderstrom has joined #linux-sunxi
<maz_>
not in new code, I mean.
lamer14534031262 has joined #linux-sunxi
<KotCzarny>
ac97 is rdconfigurable, ie. your mic port can become line-out for example
<KotCzarny>
which is pretty awesome
<diego71>
KotCzarny: yes, but the problem that if you have a new laptop, with the nth combination of port -> I/O, you have to find out where is the mic and so on
HeavyMetal has joined #linux-sunxi
HeavyMetal has quit [Changing host]
HeavyMetal has joined #linux-sunxi
tkaiser has quit [Ping timeout: 264 seconds]
<diego71>
I think the problem now is solved by acpi (also said the bios strikes back :) )
Netlynx has quit [Quit: Leaving]
<KotCzarny>
beauty of the linux is once ONE persone find out the right config and reports it, it gets added to driver for ALL
<mripard>
ssvb: until we have an incentive to do so, I don't see why we should do that
<mripard>
I mean
<mripard>
do we have any real-life use case?
viccuad has joined #linux-sunxi
<KotCzarny>
CC arch/arm/mach-sunxi/power/brom/resume_head.o
<KotCzarny>
gcc: error: unrecognized command line option '--min_array_alignment=4'
<KotCzarny>
can you put resumes.bin from that dir somewhere?
<ssvb>
maybe
<apritzel>
KotCzarny: qemu? ;-)
<KotCzarny>
um, nvm, file is there
<KotCzarny>
lets just comment it out
<KotCzarny>
hehe
<KotCzarny>
worked
<KotCzarny>
(assuming that file was compiled ok already by the blob)
<KotCzarny>
apritzel: providing half of the glibc-64 to satisfy one stupid binary blob? ;)
<KotCzarny>
anyway, compiling on lamobo-r1 and using opipc via distcc
<KotCzarny>
soon i'll add bpi-m1 to the farm ;)
<KotCzarny>
lets see if arm is self sufficient already
mosterta has quit [Ping timeout: 265 seconds]
avph has quit [Ping timeout: 245 seconds]
apritzel has quit [Ping timeout: 248 seconds]
y0g1 has joined #linux-sunxi
viccuad has quit [Ping timeout: 245 seconds]
avph has joined #linux-sunxi
yann|work has joined #linux-sunxi
<ssvb>
mripard: regarding "until we have an incentive to do so, I don't see why we should do that"
<ssvb>
well, so much for the plan/promise to make DTB files a generic operating system independent hardware description...
<KotCzarny>
i've heard that acpi is only useful for m$ systems
<ssvb>
and DT files are also already used in the U-Boot bootloader, with all the trouble synchronizing them between the Linux kernel and U-Boot
viccuad has joined #linux-sunxi
<ssvb>
until you really start *trying* to make them backwards compatible, you don't have practical experience for this job and can't claim that you can do this even when there is an "incentive"
domidumont has quit [Ping timeout: 246 seconds]
<mripard>
well, we could share our DT between systems
<mripard>
but that would require all these systems to review the other systems bindings
<mripard>
to have a common definition of what a DT looks like
<mripard>
so far, it happened only a few times
<mripard>
and failed all the time, with the $project going back and forking
<mripard>
if we have that at some point, then yeah, sure
<mripard>
if the plan is to simply have our own DTs
<mripard>
then I don't see why it matters
<KotCzarny>
how about uboot providing device tree?
<mripard>
uboot is one of these projects
y0g1 has quit [Quit: brb]
avph has quit [Ping timeout: 245 seconds]
<ssvb>
and in the mean time ACPI just works and is usable in practice (with all its bugs and quirks that maz_ is making fun of)
avph has joined #linux-sunxi
<KotCzarny>
hmm, cheapest opipc i can find is 16.50+4.00usd shipping
<KotCzarny>
ahm, 15.00+3.69
<KotCzarny>
sunxi-mdfs.c:(.text+0x107328): undefined reference to `sunxi_usb_device_disable' Makefile:873: recipe for target '.tmp_vmlinux1' failed
<KotCzarny>
huh
akaizen has joined #linux-sunxi
avph has quit [Ping timeout: 245 seconds]
<mripard>
ssvb: well then, ACPI is a superior solution to DT, just like the DT was a superior solution to the platform files
avph has joined #linux-sunxi
viccuad has quit [Ping timeout: 265 seconds]
<KotCzarny>
ssvb, do you recognize this error: sunxi-mdfs.c:(.text+0x107328): undefined reference to `sunxi_usb_device_disable'
<KotCzarny>
(and the fix maybe?)
<KotCzarny>
in: drivers/built-in.o: In function `usb_msg_center':
viccuad has joined #linux-sunxi
avph has quit [Ping timeout: 245 seconds]
<ssvb>
KotCzarny: no, maybe you are using a different kernel config
<ssvb>
and one of the possible configurations exposes this bug
<KotCzarny>
could be
akaizen has quit [Remote host closed the connection]
<KotCzarny>
pity loboris 'forgot' to check config to include /proc/config.gz
avph has joined #linux-sunxi
orly_owl_ has joined #linux-sunxi
orly_owl has quit [Ping timeout: 260 seconds]
apritzel has joined #linux-sunxi
khuey is now known as khuey|away
<yann|work>
trying to get the EGL/FBTURBO stack running on H3, and hitting problems
<yann|work>
looks like sunxi_g2d does not support H3 yet, but that one should not be a blocker for EGL, right ?
Nacho_ has quit [Remote host closed the connection]
Nacho has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
<GeneralStupid>
yann|work: i already tried it, its not supported right now
<yann|work>
FBTURBO says on startup "Module "dri2" already built-in" and "SunxiMaliDRI2_Init: drmOpen failed". But then I don't even have /dev/dri/ - CONFIG_DRM is not enabled in sun8i_h3_defconfig, but it is in sun8iw7p1smp_defconfig
<yann|work>
GeneralStupid: you mean g2d not supported, or do you mean worse ?
paulk-collins has quit [Quit: Quitte]
<GeneralStupid>
yes, no
ricardocrudo has joined #linux-sunxi
<yann|work>
ok, cool :)
avph has quit [Ping timeout: 245 seconds]
ricardocrudo has quit [Remote host closed the connection]
khuey|away is now known as khuey
khuey is now known as khuey|away
yann|work has quit [Ping timeout: 256 seconds]
viccuad has quit [Ping timeout: 250 seconds]
khuey|away is now known as khuey
<ssvb>
mripard: regarding "well then, ACPI is a superior solution to DT" - these are your words, I don't necessarily agree with this statement