* vagrantc
keeps hunting for more features to enable to get sound to work
<vagrantc>
i was perfectly happy not having sound at all until today... :)
<vagrantc>
really glad to be on track with a 5.x kernel, though
<anarsoul>
still not working?
<tuxd3v>
hello Guys,
<tuxd3v>
Does any one knows if mainline 5.0.4 is a good kernel at support level for Alwinner H6?
<tuxd3v>
Like Orange PI one plus?
<vagrantc>
anarsoul: modules load, but no device...
<vagrantc>
anarsoul: hoping it's just missing some other random config
<vagrantc>
SND_SOC_SPDIF ?
<anarsoul>
check dmesg?
vagrantc_ has joined #linux-sunxi
<vagrantc_>
asoc-simple-card sound: ASoC: codec-analog@1f015c0 not registered
<anarsoul>
do you have codec-analog loaded?
<vagrantc_>
sun50i_codec_analog 24576 0
<vagrantc_>
loaded as module ... or some other module?
<anarsoul>
oh, you also need CONFIG_SND_SOC_SIMPLE_AMPLIFIER
<vagrantc>
i should see some /dev/snd/pcm* and /dev/snd/control* ?
<anarsoul>
card won't be registered until you get CONFIG_SND_SOC_SIMPLE_AMPLIFIER
<anarsoul>
afterwards check /proc/asound/cards
<vagrantc>
thanks yet again :)
<anarsoul>
did it work?
<vagrantc_>
still rebuilding kernel
<vagrantc_>
the downside of building a kernel with the kitchen sink and related plumbing built as modules
agraf has quit [Ping timeout: 244 seconds]
zumbi has quit [Ping timeout: 246 seconds]
agraf has joined #linux-sunxi
zumbi has joined #linux-sunxi
vagrantc_ has quit [Quit: leaving]
vagrantc_ has joined #linux-sunxi
<vagrantc_>
well, devices are there, no actual sound coming out of speakers, but that could just be software configuration
<anarsoul>
vagrantc_: enable aif1 in alsamixer
<anarsoul>
and lineout
<anarsoul>
aif1 dac
<vagrantc_>
anarsoul: ok, apparently i had to enable headphones to get the speakers to work ...
<anarsoul>
I see
<vagrantc_>
if both headphones and line out are "unmuted" then speakers play ...if headphones are muted, i don't hear anything, regardless of line out
<vagrantc_>
but yay!
<vagrantc_>
sound.
lurchi__ has joined #linux-sunxi
lurchi_ has quit [Read error: Connection reset by peer]
victhor has quit [Ping timeout: 258 seconds]
Rafael1980 has quit [Quit: Konversation terminated!]
lurchi__ has quit [Quit: Konversation terminated!]
lurchi__ has joined #linux-sunxi
<vagrantc_>
well, that feels like success
<tuxd3v>
I was talking specifically for H6
<tuxd3v>
:)
<vagrantc>
i don't have any H6 devices to test, just working on what i've got
<vagrantc_>
there are definitely patches rolling in for H6, but not sure what exactly you need
<tuxd3v>
I mean sound video, ethernet, and so
<tuxd3v>
:)
<vagrantc>
not sure if 5.0 is there yet, but i have no real-world devices to test
vagrantc_ has quit [Quit: leaving]
<tuxd3v>
its possible to get Mali to work
<tuxd3v>
or will we be fbdev limited?
<vagrantc>
wow, the pinebook feels a lot faster on 5.0 thank 4.19 or 4.20
<veremitz>
vagrantc: did you build with gcc 8 too?
<tuxd3v>
I am also on the wagon for gcc8
<tuxd3v>
but still on 32 bits gcc 4.9 for uboot
<vagrantc>
i think 4.19+ kernels i've used have all been built with gcc-8, since that's been the default compiler in debian for quite a while
<tuxd3v>
even ubbot?
<tuxd3v>
uboot
<vagrantc>
yes
<vagrantc>
u-boot upstream requires gcc 6, if i'm remembering correctly
<tuxd3v>
woow
<tuxd3v>
that would mean tru 64 bits support..
<tuxd3v>
Am I correct?
<vagrantc>
i have no idea what you're getting at :)
<tuxd3v>
I haven't tried yet upstream uboot
<vagrantc>
i maintain u-boot in debian, and try not to diverge to far...
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
<wens>
vagrantc: the codec driver export the full range of controls to userspace, and they are named from the codec's view, so it's kind of confusing for newcomers
nashpa has quit [Ping timeout: 250 seconds]
chewitt has joined #linux-sunxi
nashpa has joined #linux-sunxi
JC_Yang has joined #linux-sunxi
<JC_Yang>
for H6, does the official BSP from allwinner android only? I've learned that the mainline effort is not feature complete for this SoC yet, so is it possible to use VE in a linux(non-android) setup, at this moment?
<JC_Yang>
is the official BSP for android only?
<tuxd3v>
What I lern is that mainline kernels burns a lot the CPUs...
<tuxd3v>
like passing from 35C in standby
<tuxd3v>
to 40-50C
<tuxd3v>
but that has to do mostly with the device tree
<tuxd3v>
Mailine one, is like crazy
<tuxd3v>
those guys put there values in mv , but in decimal...
<tuxd3v>
so interpreted in hexa... you put alot of voltage on the ldos..
<tuxd3v>
craazyy
<wens>
what?
<wens>
the values are supposed to be in decimal, and it's not interpreted in hexadecimal, unless prefixed with 0x
<tuxd3v>
humm
<tuxd3v>
for what I understand its always hexa
<wens>
no it's not
<tuxd3v>
ho yeah
<tuxd3v>
or
<tuxd3v>
I am massing with the fex format..
<tuxd3v>
but I think I am right
<tuxd3v>
do a dmesg
<tuxd3v>
and you will find out the lods out of range..
<tuxd3v>
ldos
<wens>
go take a look at /sys/kernel/debug/regulator/regulator_summary , match that up with the DT, then come back
<wens>
the LDO defaults are out of range of the "constraints" described by the DT. the kernel brings them within constraints
<wens>
read the code, get some more data points, dump the registers
<wens>
you'll see that everything works as it should, and the values are proper decimal
<tuxd3v>
so why you pass from the BSP 35C in standby to 50C using a heatsink and a fan above?
<tuxd3v>
the best I found was around 40C
<tuxd3v>
even today create d a image and bum.. 50C
<wens>
and mainline doesn't implement deep suspend like Android does
<tuxd3v>
for an H6 board
<wens>
H6 doesn't support DVFS yet, duh
<wens>
so you're running at full speed, full voltage, all the time
Jojo1411_73 has joined #linux-sunxi
<JC_Yang>
question again, does the official H6 BSP provide a well-baked linux(non-android) userspace environment for VE?
<wens>
I don't think so, but I haven't looked closely
<wens>
JC_Yang: check the various board vendors for Linux images running old kernels
vagrantc has quit [Quit: leaving]
tuxd3v has quit [Quit: Leaving]
<JC_Yang>
the board vendor told me that it's only feature complete for android, but I doubt whether it's feasible to adapt it to be used with ffmpeg or gstreamer like framework. I've learned some status from the wiki, it's not clear enough, it seems that different peoples are working on different driver models and different userspace API wrappers, counting the official BSP one, totally three alternatives exist, right? the situation is a bit messy, I'm a bit
<JC_Yang>
confused, while considering the chip has a good price performance ratio, hardware wise, any easier to understand or better conclusion for the status quo?
<wens>
3 models?
<wens>
the BSP cedar libraries / driver is much like the nvidia gpu drivers, the kernel shim passing all register access to userspace
<wens>
the new fancy cedrus driver uses the requests API in v4l2, which should be a standard (stable) API of the mainline kernel
<wens>
ffmpeg / gstreamer can then implement support on top of that (from what I heard, it's already in progress)
<wens>
on the other hand, the BSP driver is a custom interface
<wens>
and each vendor comes up with their own, so you end up having to support each one separately
nuuuciano has quit [Ping timeout: 250 seconds]
<JC_Yang>
isn't there a libvdpau port too?
<wens>
that is an attempt to expose a more standard API (VDPAU) while using the cedarx (bsp) kernel
<wens>
the one to look forward to is the v4l2 one
<wens>
I think the better question is, what features do you need?
<JC_Yang>
so what you mean is, the BSP kernel hand over most 'driver' responsibility to the userspace libs for VE control? I'm considering this SoC as the based of a linux box, which can run Qt apps and provide a mature media codec interface for the sake of video/audio playback.
kaspter has quit [Ping timeout: 250 seconds]
<wens>
that is my understanding. I might be wrong.
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Client Quit]
camh2 is now known as camh
kaspter has joined #linux-sunxi
TheSeven has quit [Disconnected by services]
[7] has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
clemens3_ has quit [Remote host closed the connection]
clemens3 has joined #linux-sunxi
perr has quit [Ping timeout: 245 seconds]
<libv>
rellla: it is perhaps time to put the sunxi-3.4 kernel to bed, at least from a manual build howto pov
<libv>
(since you seem to be one of the few people who does care about the wiki :))
<libv>
at this point, it is just confusing matters, and i doubt that many people still actively use that frankenstein tree
<rellla>
libv: i'm supporting this since i personally haven't dealt with 3.4 since months, maybe years.
<libv>
it's more likely that people use the bsp trees than them using sunxi-3.4
<rellla>
though i still have 2 machines running it, because they are my TV-boxes which use libvdpau-sunxi.
<libv>
rellla: i am not advocating throwing it away
<libv>
nor am i advocating removing it from the wiki
<rellla>
and they run rock stable since years now :p
<libv>
but it might be time to make the manual build howto all about "upstream"
<rellla>
yeah, we should move/archive it, not delete it
<libv>
and fork off the sunxi-3.4 kernel
<libv>
as there is no point anymore in keeping this doubled up
<rellla>
we have that "confusion" all over the wiki btw.
<libv>
plaes, paulk-leonov: ^^^
<libv>
yeah, it made sense back in 2014 and 2015
<libv>
nowadays though...
<rellla>
people should be pointed to mainline and only should get the "legacy" pages after a search.
<rellla>
imho people that most really that use or need to use 3.4 still, use armbian anyway, and don't build the package by themselves
<plaes>
yeah.. I've been adding "deprecation warnings" here and there...
<libv>
or just have a single link at the top of the manual build howto
<rellla>
argh
<rellla>
what would i tell you??
<libv>
?
<rellla>
my sentence above got weird, but i think it's understandable :)
victhor has joined #linux-sunxi
<KotCzarny>
rellla, if they are h3/a64, you might give libreelecH3 a try
<KotCzarny>
it works nicely as a tv/iptv box
<libv>
rellla: yeah, it was, at least more understandable than your outcry about it ;p
<libv>
KotCzarny: sunxi-3.4 is the a10/a13 tree with a20 bits added
<paulk-leonov>
agreed about archiving sunxi-3.4
<libv>
so it definitely will not run on h3/a64
<paulk-leonov>
it's useful for reference, but hardly for real-life usage
<KotCzarny>
libv, but H3 also uses sunxi-3.4
<paulk-leonov>
and indeed distros like armbian that ship downstream kernels use bsp trees
<libv>
KotCzarny: are you sure that it is our tree?
<paulk-leonov>
KotCzarny, does it? IIRC armbian uses a bsp tree
<libv>
and not some bsp tree which is also 3.4?
<KotCzarny>
libv, missed the part about sunxi specific tree, just triggered on 3.4
<libv>
KotCzarny: while it has since become quite universal
<libv>
sunxi was pretty much a name chosen when we created this channel and the website
<libv>
allwinner is still producing 3.4 kernels
<rellla>
KotCzarny: i have www.tvdr.de running and therefore need libvdpau... i think, there would be some tweeks in the userspace app necessary to get it running with our drm driver and v4l2/vaapi
<rellla>
i doubt, libreelec offers this atm, though i could switch to kodi...
<libv>
dated may 2012
<rellla>
... which i don't want atm :)
<KotCzarny>
:)
<KotCzarny>
paulk-leonov: i didnt say anything about armbian, did i?
<paulk-leonov>
KotCzarny, right, I was just pointed it out
<paulk-leonov>
pointing it out*
<KotCzarny>
anyway, LEH3 is quite usable as a iptv box, i should say
<KotCzarny>
the things i miss is deinterlacer and some stability on bad streams
<rellla>
KotCzarny: yeah, deinterlacer... how difficult may it be to implement it?
<KotCzarny>
i must say i know next to nothing about video decoding internals
<KotCzarny>
at this moment 1080i streams are very 90sh when viewed via cedrus
<paulk-leonov>
yeah it's something I'd like to see support in the v4l2 cedrus driver
<paulk-leonov>
it's not particularly difficult to do AFAIK
<paulk-leonov>
since that shouldn't have to involve the ISP
<rellla>
paulk-leonov: is the deinterlacer part of cedrus/v4l2 or display/drm?
<rellla>
or would that require a separate driver?
<paulk-leonov>
rellla, IIRC it's part of the DE1
<paulk-leonov>
probably DE2/3 too
<paulk-leonov>
I don't really have a clear idea of whether the VPU can deinterlace on its own (I would tend to think it can't)
<paulk-leonov>
but maybe socs > sun6i need the ISP for that
<paulk-leonov>
IIRC jernej tried cedrus with interlaced and probably knows best
<rellla>
iirc the bsp for A10/A20, so DE1, has implemented it in the display driver, since DE2 allwinner kernel used at least a separate kernel module...
* paulk-leonov
had never looked at drivers/char/sunxi*
Andy-D has quit [Ping timeout: 250 seconds]
JC_Yang has quit [Quit: Leaving]
<MoeIcenowy>
paulk-leonov: I think only R40 has one
<MoeIcenowy>
A64 surely have none
<MoeIcenowy>
the TR is something inside DE2, and the doc is available in DE2 spec
<paulk-leonov>
right, looks like TR is attached to DE2
<paulk-leonov>
looks like the mixer is what they call g2dv2
<rellla>
MoeIcenowy, paulk-leonov: the g2d is called mixer processor in the manual. A10 and A20 have it.
<MoeIcenowy>
rellla: yes
<MoeIcenowy>
I think only A10/A20/R40 has it
<rellla>
libvdpau-sunxi uses is (of the legacy kernel version) for blitting/blending ops of the rgb/osd layer
<rellla>
s/uses is/ uses it/
<paulk-leonov>
I think A31 and A80 also have the first G2D block
<paulk-leonov>
but that's about it
Rafael1980 has joined #linux-sunxi
tuxillo has quit [Remote host closed the connection]
tuxillo has joined #linux-sunxi
perr has joined #linux-sunxi
tnovotny has joined #linux-sunxi
SergiusUA has joined #linux-sunxi
<libv>
we will be using g2d for fosdem-video to go from the rgb from the camera/hdmi input to the encoder
<libv>
so wait and see how that will be implemented
tuxd3v has joined #linux-sunxi
perr has quit [Ping timeout: 250 seconds]
dddddd has joined #linux-sunxi
camh has quit [Ping timeout: 244 seconds]
hanni76 has joined #linux-sunxi
fkluknav_ has quit [Remote host closed the connection]
fkluknav has joined #linux-sunxi
tllim has joined #linux-sunxi
tnovotny has quit [Ping timeout: 268 seconds]
tllim has quit [Quit: Leaving]
lurchi_ is now known as lurchi__
ashleyk has joined #linux-sunxi
tnovotny has joined #linux-sunxi
CepriN has joined #linux-sunxi
SergiusUA has quit [Ping timeout: 246 seconds]
lurchi__ has quit [Read error: Connection reset by peer]
lurchi__ has joined #linux-sunxi
chewitt has quit [Ping timeout: 250 seconds]
JohnDoe_71Rus has joined #linux-sunxi
chewitt has joined #linux-sunxi
chewitt has quit [Ping timeout: 246 seconds]
chewitt has joined #linux-sunxi
mistiry17 has joined #linux-sunxi
selfbg has quit [Remote host closed the connection]
mistiry17 has quit [Remote host closed the connection]
ShapeShifter499 has joined #linux-sunxi
ShapeShifter499 has quit [Remote host closed the connection]
camh has joined #linux-sunxi
AMD1212_ has joined #linux-sunxi
koshii19 has joined #linux-sunxi
koshii19 has quit [Remote host closed the connection]
AMD1212_ has quit [Remote host closed the connection]
zersh has joined #linux-sunxi
zersh has quit [Remote host closed the connection]
Guest31414 has joined #linux-sunxi
Guest31414 has quit [Remote host closed the connection]
hoodow20 has joined #linux-sunxi
hoodow20 has quit [Remote host closed the connection]
CepriN has quit [Quit: Leaving]
CepriN has joined #linux-sunxi
CepriN has quit [Remote host closed the connection]
SergiusUA has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
Anshu has joined #linux-sunxi
<jernej>
wens: paulk-leonov: rellla: A bit late to the deinterlacer discussion, but I can confirm that SoCs with DE2 and DE3 have completely separate deinterlace peripheral
<paulk-leonov>
jernej, understood :)
<paulk-leonov>
jernej, and the VPU doesn't have any deinterlacing ability on its own, right?
<jernej>
with DE3 you can even connect deinterlacer output directly to DE3 input (skip the need for intermediate buffer)
<jernej>
paulk-leonov: yes
dlan has quit [Ping timeout: 255 seconds]
<paulk-leonov>
jernej, about DE3: that makes the v4l2/drm distinction very blury
netlynx has joined #linux-sunxi
<paulk-leonov>
but it's kind of the same case as the DE1 frontend that can also do mem2mem
<paulk-leonov>
IMO we'd need two drivers (both drm for integration in the pipeline and v4l2 for mem2mem)
anshu_ has joined #linux-sunxi
<jernej>
yeah, I'm not sure how to implement that in kernel, but it's just an option, not something we have to support right away
<jernej>
talking about connectiong between deinterlacer and DE3 ^
<Mangy_Dog>
anyone know what the rough power draw is of a orange pi zero 2+ on full load?
<Mangy_Dog>
roughly
<Mangy_Dog>
300 400 500 600 700 ma? 1a?
diskless has joined #linux-sunxi
<jernej>
btw, transform unit found in DE2 and DE3 is actually standalone unit. It is used for screen rotation.
<paulk-leonov>
jernej, ah so it's not integrated in the display pipeline at all?
<jernej>
afaik, no
<jernej>
but I'm not 100% sure
<paulk-leonov>
okay
* ElBarto
will need to look at this
<jernej>
I have never seen any bit which would connect transform unit output to any mixer input
<paulk-leonov>
fair enough :)
jubalh23 has joined #linux-sunxi
jubalh23 has quit [Remote host closed the connection]
anshu_ has quit [Ping timeout: 256 seconds]
<diskless>
Hello everyone. I have been working with the Orange Pi PC board for a couple of years now. I just booted up the Armbian 5.75 Bionic image for Orange Pi PC, with mainline kernel 4.19.20, on an H3 based TV box board. The TV box is an MXQ PRO 4K.
<diskless>
The image boots just fine. However, it looks like the board is running real slow. I ran sysbench on the Orange Pi PC and this board to compare what's going on. I see that the OpiPC pulls 89002.74 CPU events/second and 511897.41 RAM events/second. These metrics for my test board are 26406.37 and 151228.75 respectively. That's 29% of the OPiPC. The kernel in use is 4.19.20-sunxi. The DTB file being used is for the Orange Pi PC.
<diskless>
Is there some way I can improve the performance of this board by creating a new DTS file for this board? How would I learn what changes to make to the DTS in order to improve performance of the board?
Anshu has quit [Quit: Page closed]
<karlp>
heh, so there's mxq pro 4k baords with rockhip, amlogic and also allwinner now? nice.
<paulk-leonov>
diskless, that doesn't sound too surprising since you are indeed using a dtb that's not for your board
<paulk-leonov>
could be operating points that differ
<paulk-leonov>
although I'm not really sure of what the mainline support status for that is on h3
<diskless>
Heh heh, yeah @karlp. Looks like they just keep reusing the brand name. I have an S905W based MXQ PRO and that runs mainline Linux like a charm. It is only this H3 based board that is giving me pain.
<paulk-leonov>
diskless, also the u-boot setup can play a role, especially if you're using wrong DRAM settings
<diskless>
Ah. Yeah. DRAM is setup in u-boot. Where would I look for DRAM settings in u-boot?
<paulk-leonov>
diskless, can you do analog audio out on that connector marked "AV"?
fkluknav has quit [Remote host closed the connection]
fkluknav has joined #linux-sunxi
<diskless>
Heh heh, @paulk-leonov, nope, there is no analog audio out on the AV connector. That's the other problem, but I am not super concerned about that right now. With the same image audio works flawlessly on the Orange Pi PC.
Nnavd24 has quit [Remote host closed the connection]
<paulk-leonov>
diskless, what you really need is to dump the fex from the factory system and get the right values from that
Putti has joined #linux-sunxi
<diskless>
OK. So there is Android on the NAND flash on the board. I presume the fex is in there somewhere. I know mainline Linux doesn't support NAND on H3. How do I get a hold of this fex file?
pmpp has quit [Disconnected by services]
pmpp_ has joined #linux-sunxi
ashleyk has quit [Remote host closed the connection]
<wens>
paulk-leonov: doesn't the drm framework support writeback?
ashleyk has joined #linux-sunxi
<paulk-leonov>
wens, yeah actually it does, but it's exposed as a connector, so I'm not sure it's such a good fit
<paulk-leonov>
as far as I understood, it's meant more for crtc output writeback, not for writeback of elements of the pipeline
<Mangy_Dog>
anyone see my question about power consumption?
<paulk-leonov>
Mangy_Dog, yes, we all see it
<Mangy_Dog>
ok :)
<paulk-leonov>
Mangy_Dog, but I guess nobody had an answer to give you sofar
<Mangy_Dog>
so any idea?
<paulk-leonov>
diskless, yep, it should be in there -- there is wiki documentation about retreiving the fex file
<Mangy_Dog>
ill accept a rough power draw based n the h3 or h5 chip based orange pi boards
<Mangy_Dog>
what woudl a reasonable assumption be?
<paulk-leonov>
diskless, you can also get it from the FEL USB mode
<paulk-leonov>
if the device supports that
<paulk-leonov>
diskless, also don't hesitate to fill up a wiki entry about the device with your findings :)
<diskless>
paulk-leonov yes, I found http://linux-sunxi.org/Retrieving_device_information and have been reading it. I now need to find a soldering iron and solder the UART pins in. That can only happen tomorrow because it is 10pm here now.
<paulk-leonov>
hehe, always solder with natural light indeed :)
<diskless>
paulk-leonov, for sure, I will create a new linux-sunxi wiki entry with my device findings. I made one earlier, in 2015, with my investigation of an A20 device.
<paulk-leonov>
neat :)
<diskless>
paulk-leonov Yes, natural light is good. But having soldering iron is even better. I don't have one at home :-). Which is bad. I am getting weak. What is a man without his soldering equipment?
<ashleyk>
a punk!
camh1 has joined #linux-sunxi
<paulk-leonov>
:))
camh has quit [Ping timeout: 245 seconds]
MrMobius27 has joined #linux-sunxi
MrMobius27 has quit [Remote host closed the connection]
diskless has quit [Ping timeout: 256 seconds]
pmpp_ has quit [Ping timeout: 246 seconds]
sparr26 has joined #linux-sunxi
sparr26 has quit [Remote host closed the connection]
pmpp has joined #linux-sunxi
clemens3 has quit [Ping timeout: 244 seconds]
ashleyk has quit [Remote host closed the connection]
kurosu has joined #linux-sunxi
ashleyk has joined #linux-sunxi
kurosu has quit [Remote host closed the connection]
gauge3 has joined #linux-sunxi
gauge3 has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
return0e_ has joined #linux-sunxi
return0e has quit [Ping timeout: 250 seconds]
sunshavi has quit [Ping timeout: 246 seconds]
diskless has joined #linux-sunxi
diskless has quit [Quit: Page closed]
SergiusUA has quit [Remote host closed the connection]
addo29 has joined #linux-sunxi
Ben6417 has joined #linux-sunxi
addo29 has quit [Remote host closed the connection]
Ben6417 has quit [Remote host closed the connection]
return0e has joined #linux-sunxi
return0e_ has quit [Ping timeout: 246 seconds]
ashleyk has quit [Remote host closed the connection]
ashleyk has joined #linux-sunxi
seanBE25 has joined #linux-sunxi
seanBE25 has quit [Remote host closed the connection]
nuuuciano has joined #linux-sunxi
sunshavi has joined #linux-sunxi
nuuuciano has quit [Ping timeout: 246 seconds]
return0e has quit []
return0e has joined #linux-sunxi
nuuuciano has joined #linux-sunxi
Guest67700 has joined #linux-sunxi
Guest67700 has quit [Remote host closed the connection]
camh1 is now known as camh
phadej18 has joined #linux-sunxi
phadej18 has quit [Remote host closed the connection]
wwilly has joined #linux-sunxi
lemmi4 has joined #linux-sunxi
lemmi4 has quit [Remote host closed the connection]
anto8 has joined #linux-sunxi
anto8 has quit [Remote host closed the connection]
tllim has joined #linux-sunxi
d-fence_23 has joined #linux-sunxi
d-fence_23 has quit [Remote host closed the connection]
Zerqent0 has quit [Remote host closed the connection]
netlynx has quit [Quit: Ex-Chat]
Emil14 has joined #linux-sunxi
Emil14 has quit [Remote host closed the connection]
paulliu has quit [Quit: Leaving.]
vagrantc has quit [Ping timeout: 258 seconds]
Andy-D has joined #linux-sunxi
xxpor has joined #linux-sunxi
tuxd3v has quit [Remote host closed the connection]
xxpor has quit [Remote host closed the connection]
Rosiak15 has joined #linux-sunxi
Rosiak15 has quit [Remote host closed the connection]
gamelaster has joined #linux-sunxi
victhor has joined #linux-sunxi
Andy-D has quit [Ping timeout: 272 seconds]
f0xx has quit [Ping timeout: 255 seconds]
<lvrp16>
is there any use for multi_v7_defconfig? i thought all armv7 kernels had to be different?
juri_ has quit [Ping timeout: 272 seconds]
hanni76 has quit [Quit: Leaving]
gamelaster has quit [Ping timeout: 272 seconds]
Mangy_Dog has quit [Ping timeout: 250 seconds]
Jikai has joined #linux-sunxi
Jikai has quit [Remote host closed the connection]
fuchstronaut24 has joined #linux-sunxi
fuchstronaut24 has quit [Remote host closed the connection]
nbari10 has joined #linux-sunxi
nbari10 has quit [Remote host closed the connection]
Andy-D has joined #linux-sunxi
gamelaster has joined #linux-sunxi
stiv2k17 has joined #linux-sunxi
stiv2k17 has quit [Remote host closed the connection]
<karlp>
allow me tto introduce my friend, miss device tree.
<anarsoul>
:)
karlp has quit [Quit: WeeChat 2.4]
daaniel_5 has joined #linux-sunxi
daaniel_5 has quit [Remote host closed the connection]
vagrantc has joined #linux-sunxi
<lvrp16>
karlp: are you reply to me or someone else?
gamelaster has quit [Ping timeout: 255 seconds]
karlp has joined #linux-sunxi
<anarsoul>
lvrp16: I'm pretty sure he replied to you
<lvrp16>
anarsoul: ahh ok, i was under the assumption that multi defconfig only worked on armv8...didn't know it worked on armv7 as well. thought kernel had restrictions for different boards. thanks.
misc14 has joined #linux-sunxi
Rafael1980 has quit [Quit: Konversation terminated!]
misc14 has quit [Remote host closed the connection]
Rafael1980 has joined #linux-sunxi
karlp has quit [Quit: WeeChat 2.4]
karlp has joined #linux-sunxi
lem-fr6 has joined #linux-sunxi
lem-fr6 has quit [Remote host closed the connection]
veremitz has joined #linux-sunxi
mzki has quit [Ping timeout: 252 seconds]
Rafael1980 has quit [Quit: Konversation terminated!]
mzki has joined #linux-sunxi
lurchi__ is now known as lurchi_
spopo has joined #linux-sunxi
spopo has quit [Remote host closed the connection]
Andy-D has quit [Ping timeout: 255 seconds]
honestly18 has joined #linux-sunxi
honestly18 has quit [Remote host closed the connection]
<willmore>
Pretty sure the Rpi people use device tree and pre-v8, FWIW.
<vagrantc>
multiplatform kernels work even in arm v5 (at least for some boards)
culot has joined #linux-sunxi
culot has quit [Remote host closed the connection]