sunshavi has quit [Read error: Connection reset by peer]
gnufan has joined #linux-sunxi
sunshavi has joined #linux-sunxi
dddddd has quit [Remote host closed the connection]
anarsoul|3 has quit [Ping timeout: 260 seconds]
reinforce has quit [Quit: Leaving.]
BenG83 has joined #linux-sunxi
megi has quit [Ping timeout: 256 seconds]
anarsoul has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
willmore has joined #linux-sunxi
lurchi_ is now known as lurchi__
nots has quit [Quit: Page closed]
cnxsoft has quit [Ping timeout: 265 seconds]
SP7RT has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-sunxi
[7] has quit [Ping timeout: 245 seconds]
leviathan has joined #linux-sunxi
leviathan has joined #linux-sunxi
TheSeven has joined #linux-sunxi
TheSeven has quit [Ping timeout: 255 seconds]
TheSeven has joined #linux-sunxi
rexxster has quit [Remote host closed the connection]
montjoie has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 264 seconds]
megi has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
qeed has quit [Quit: Leaving]
IgorPec has quit [Ping timeout: 260 seconds]
Putti has quit [Ping timeout: 245 seconds]
nuuuciano_ has quit [Ping timeout: 260 seconds]
airwind has joined #linux-sunxi
SP7RT has joined #linux-sunxi
chewitt has joined #linux-sunxi
clemens3_ has joined #linux-sunxi
clemens3 has joined #linux-sunxi
smaeul_ has quit [Quit: cya]
smaeul has joined #linux-sunxi
<hitech95>
hi guys does someone can help me? I'm porting a R16 board to armbian, but i have an strange behavour, after the boot the pmic stop sending power to the SOC (I have no idea why). The kernel looks fine becaouse if i change the rootfs to another one (built on yocto) the board works fine.
<KotCzarny>
removing systemd might also work. though that requires working os first
<hitech95>
beeble, how can i check that? is in the scr file? I'm still tring to understand the boot process of sunxi. I used to work with mips with spi flash and it was easyer
<beeble>
hitech95: thats a kernel command line. add it to your bootargs
<beeble>
you want to debug the init process
<beeble>
and thats the same as on mips
<hitech95>
beeble, yup but on pips we had uboot enviroment, here there is the .scr file or something. give me a sec to figure it out
<hitech95>
*mips
<beeble>
you can also use the u-boot environment
<beeble>
that script stuff is optional
AneoX_ has joined #linux-sunxi
<beeble>
load kernel, fdt, initrd
<KotCzarny>
boot.scr is txt file with a header
clemens3 has quit [Ping timeout: 256 seconds]
<KotCzarny>
you can remove the header, edit file, then mkimage it again into scr
funkathustra has joined #linux-sunxi
<beeble>
and do a bootm
<hitech95>
beeble, KotCzarny oh ok. thx
<KotCzarny>
mkimage -C none -A arm -T script -d boot.cmd boot.scr
<KotCzarny>
with that command
<hitech95>
ok thx i try give me a sec.
<KotCzarny>
it's a bit more flexible than uboot env because you can edit it with external editor/os
AneoX has quit [Ping timeout: 260 seconds]
funkathustra has quit [Client Quit]
funkathustra has joined #linux-sunxi
funkathustra__ has joined #linux-sunxi
funkathustra__ has left #linux-sunxi [#linux-sunxi]
<hitech95>
right now the bootarg is: "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} hdmi.audio=EDID:0 disp.screen0_output_mode=${disp_mode} panic=10 consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} ubootsource=${devtype} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}"
<hitech95>
but looks like it load an arbianENV.txt
<hitech95>
KotCzarny, I can add an extraargs parameter on that file and buid it, right?
fkluknav has joined #linux-sunxi
<KotCzarny>
you can do it multiple ways, but yeah, if you want to use whatever armbian way has
<KotCzarny>
just a note, when pasting from pastebin.com try clicking 'raw' first, saves some ads for others
<hitech95>
? ok :)
jaydcarlson_ has joined #linux-sunxi
jaydcarlson_ has left #linux-sunxi [#linux-sunxi]
jaydcarlson has quit [Client Quit]
funkathustra has joined #linux-sunxi
funkathustra has quit [Read error: Connection reset by peer]
jaydcarlson has joined #linux-sunxi
jaydcarlson has quit [Read error: Connection reset by peer]
jaydcarlson has joined #linux-sunxi
<beeble>
hitech95: so now you know it's something that gets started by init. so maybe take a look at /etc/systemd/system if there are any services that look suspicious
test29384738 has joined #linux-sunxi
dddddd has joined #linux-sunxi
test29384738 has quit [Client Quit]
mripard has joined #linux-sunxi
annonymous234783 has quit [Ping timeout: 260 seconds]
<hitech95>
Ok I try to see what it can be! if you have some suggestions xD I looked into init.d but looks normal to me.
dh1tw has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Andy-D_ has joined #linux-sunxi
Andy-D__ has quit [Ping timeout: 256 seconds]
lurchi_ is now known as lurchi__
matthias_bgg has joined #linux-sunxi
foxx_ has joined #linux-sunxi
BenG83 has quit [Ping timeout: 248 seconds]
AneoX has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 240 seconds]
jaydcarlson has quit [Ping timeout: 256 seconds]
dgp has quit [Read error: Connection reset by peer]
dgp has joined #linux-sunxi
LargePrime has quit [Ping timeout: 255 seconds]
LargePrime has joined #linux-sunxi
naggety has joined #linux-sunxi
foxx_ has quit [Ping timeout: 260 seconds]
<naggety>
Hi! I hope I can get some help with a problem I have. A few weeks ago I asked about it here too, but I have not solved it yet.
<naggety>
I'm working with old disp driver, kernel 3.4. I know it's not supported, but the problem seems to be related to memory mapping, and I hope someone can guide me a bit about this.
Ntemis has joined #linux-sunxi
<naggety>
I'm porting the tv-decoder driver to mainline, and with the most recent changes, the demo program I had to test it have stoped working. This demo program just pass the buffer from tv-decoder driver to disp driver.
<naggety>
It uses DISP_CMD_VIDEO_SET_FB ioctl for that. In that ioctl, one argument is the memory address of the buffer.
<naggety>
Funny thing is that the demo program pass the mmap offset, not the real memory address. And it worked, until now.
fkluknav has quit [Ping timeout: 265 seconds]
<naggety>
However, if instead of passing the address to disp driver, I copy the content from the real memory addres to a file in disk, the content is copied OK. That's why I know the content is in the address that mmap returned.
<naggety>
(To copy to disk I use real address returned by mmap, not mmap offset)
<naggety>
I've been digging in disp driver code, and it seems that it call to __phys_to_bus to convert the address I pass to it.
<naggety>
Like this, from disp_video.c: scal_addr.ch0_addr = __phys_to_bus(g_video[sel][id].video_cur.addr[0]);
<naggety>
Anyone can figure out why it worked before passing mmap offset and why it doesn't work now, neither with mmap offset nor the real address?
<naggety>
(sorry for the long text)
chewitt has quit [Ping timeout: 245 seconds]
fire219 has quit [Ping timeout: 240 seconds]
fire219 has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
kaspter has joined #linux-sunxi
<naggety>
I'm still digging and I see that after converting the address with __phys_to_bus, it's just written without no other conversion to a register of something called "scaler" (which I guess that scales the image ;). Seeing this, I understand even less how it could work with mmap offsets
<naggety>
file de_fe.c, function DE_SCAL_Config_Src
<naggety>
Looking to A20 user manual, it seems that this scaler code is writting to DEFE registers. Address registers are DEFE_BUF_ADDR0_REG, DEFE_BUF_ADDR1_REG and DEFE_BUF_ADDR2_REG
<naggety>
How must addresses be passed to this registers?
Andy-D_ has quit [Ping timeout: 264 seconds]
megi has quit [Quit: WeeChat 2.1]
xerpi has joined #linux-sunxi
xerpi has quit [Remote host closed the connection]
xerpi has joined #linux-sunxi
Mr__Anderson has joined #linux-sunxi
elros has joined #linux-sunxi
tom_nov has joined #linux-sunxi
leviathan has quit [Ping timeout: 256 seconds]
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi
<Net147>
Wizzup: everything working fine with the 4.3" screen?
leviathan has joined #linux-sunxi
reinforce has joined #linux-sunxi
mavkhimenia has joined #linux-sunxi
mavkhimenia has quit [Client Quit]
megi has joined #linux-sunxi
<Wizzup>
Net147: yes, although I am not a home currently. touchscreen worked, displayed fine, backlight worked, brightness worked
<Wizzup>
Net147: anything specific you had in mind?
IgorPec has quit [Ping timeout: 264 seconds]
elros has quit [Ping timeout: 256 seconds]
elros has joined #linux-sunxi
<Net147>
Wizzup: sometimes the LCD doesn't render grayscale gradients well and needs dithering to 18-bit
<Wizzup>
ok, I definitely didn't test that.
xerpi has quit [Quit: Leaving]
<Net147>
it is nice to see my list of patches getting less for each kernel release. I updated sun7i-drm-wip branch for 4.16.
IgorPec has joined #linux-sunxi
gumblex has quit [Quit: ZNC 1.7.0+deb1+b1 - https://znc.in]
gumblex has joined #linux-sunxi
kozy has quit [Ping timeout: 264 seconds]
fkluknav has joined #linux-sunxi
phdeswer_ has joined #linux-sunxi
fkluknav has quit [Ping timeout: 260 seconds]
qeed has joined #linux-sunxi
fkluknav has joined #linux-sunxi
afaerber has quit [Quit: Leaving]
naggety has quit [Ping timeout: 276 seconds]
rexxster has joined #linux-sunxi
gnufan1 has joined #linux-sunxi
gnufan has quit [Ping timeout: 260 seconds]
naggety has joined #linux-sunxi
airwind has quit [Quit: Lost sanity]
afaerber has joined #linux-sunxi
<naggety>
Easy question from a newcomer: how must I include the file arch/arm/plat-sunxi/include/plat/memory.h? #include <arch/memory.h> didn't work
<naggety>
I want to use virt_to_phys function, but including asm/io.h or sys/io.h as it's said in many places on the internet, it says that the function is undefined
<gab>
you probably shouldn't include this file directly
<naggety>
What file should I include to call virt_to_phys?
<gab>
try asm/memory.h instead
<agraf>
naggety: are you sure that's the function you want?
<agraf>
naggety: fwiw it will only work for linear mapped ram - and on 32bit only in non-pae ranges
<naggety>
not 100% sure, but I need to try because I have no more ideas right now
<agraf>
naggety: what are you trying to map?
cnxsoft has quit [Ping timeout: 256 seconds]
<naggety>
I'm using old disp driver (kernel 3.4), and I have to pass to it the address of the next video buffer
<naggety>
I have the virtual address of the buffer, I get it with mmap, using the offset returned by the tv-decoder driver
<naggety>
I think that disp driver expect physical address
<naggety>
because in disp code it uses phys_to_bus to convert the address I pass to it
<naggety>
gab: asm/memory.h isn't found
<agraf>
naggety: is the virtual address a user space virtual address or a kernel linear map virtual address?
<agraf>
naggety: my guess is on the former
<agraf>
naggety: i haven't done device drivers myself yet, but I'm fairly sure there's an api that allows you to pin the user pages and give you the PA to them along the way
<agraf>
naggety: probably something with dma in its name ;)
<naggety>
I have no previous experience with linux and memory mapping, but I think is user space virtual address. From a userspace program I get a mmap offset from tv-decoder driver. Then I call mmap with that offset.
<dgp>
naggety: if the buffer is from a user process you need to use copy_from_user or something to get it into the kernel
<naggety>
No, the buffer is allocated in kernel space by tv-decoder driver
<naggety>
From user space I get a virtual address to that buffer, with mmap
Ntemis has quit [Remote host closed the connection]
<naggety>
Sorry, maybe I'm not explaining it well, I don't understand how all this works
<naggety>
All this memory mapping things is completely new for me
<naggety>
1 - tv decoder driver allocate buffers (kernel space)
<naggety>
2 - user program request to tv-decoder driver the memory offset of that buffer
<naggety>
3 - user program call to mmap with that offset (so I think I have a user space virtual address pointing to the buffer)
<naggety>
4 - user program have to inform disp driver about buffer address. I think I have to do it passing physical address.
<dgp>
so you have a buffer in the kernel and you're using something in userspace to get the address of the buffer and send that into another driver?
<naggety>
Yes
fdcx has quit [Ping timeout: 240 seconds]
pmpp has joined #linux-sunxi
<dgp>
naggety: how is the buffer being allocated in the tv decoder driver?
<naggety>
I'm not sure. It's a V4L2 driver, and uses MMAP allocation method. Does this answer your question?
pmpp_ has quit [Ping timeout: 268 seconds]
<naggety>
Ah, the driver delegate to videobuf2 the allocation
<dgp>
It sounds like you just need to work out how that allocation works (it might already be the physical address), translate it if needed and just pass the value using your userspace stuff
<naggety>
The driver doesn't return an address, but an offset that you have to pass to mmap
<naggety>
That's why I think it's not the physical address
<gab>
naggety: you probably want to do DMA mappings, take a look at Documentation/DMA-API.txt and Documentation/DMA-API-HOWTO.txt
<gab>
or look at functions that manipulate videobuf_dma_contig_memory structures
<gab>
seems like videobuf2 does this on a higher level
<naggety>
gab: this seems to be for drivers development. It is OK for userspace programs too?
<gab>
no
<gab>
you can't address physical memory from userspace anyway
<gab>
you need a kernel driver to map it in your process
<naggety>
But I don't want to use it from userspace. I just want to get the address and pass it to the disp driver
<gab>
from where do you want to pass the address to the disp driver ? userspace ?
<naggety>
yes
IgorPec has quit [Ping timeout: 240 seconds]
<gab>
that's not something you can easily do directly
<gab>
your driver needs at least to tell you the physical base address of your mmapped buffer
<gab>
then you can compute it with base + offset and pass it to the disp driver
<gab>
(that's a huge security hole btw)
<naggety>
I guess that's why you stoped using disp driver xD
<naggety>
In linux-sunxi wiki it says that disp driver is unsecure
<naggety>
But for now, for different reasons, I have to use it
IgorPec has joined #linux-sunxi
<naggety>
gab: I guess that getting bus address is as difficult as physical, right?
phdeswer_ has quit [Ping timeout: 265 seconds]
<gab>
naggety: same problem
<gab>
userland is not meant to manipulate physical addresses directly
<gab>
that's why mmap exists
<naggety>
Maybe physical address is not what I need. disp driver calls phys_to_bus with the address you pass to it. That's why I think I need physical address.
<naggety>
But maybe it's not physical address. Disp driver is not a good driver, but it is possible to use it from userspace...so there must be a way
<naggety>
The main problem is that I don't know what memory is expecting disp driver, anybody answered me about this. So I wanted to try this.
nuuuciano_ has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
<gab>
naggety: you can also try something dirtier and parse /proc/<your pid>/pagemap
<gab>
but that's very naughty :p
foxx_ has joined #linux-sunxi
<gab>
(Documentation/vm/pagemap.txt for more info)
<naggety>
I'm very confused with this. TV-decoder was using videobuf1, and now I've ported it to videobuf2 because I want to mainline it. With videobuf1, passing THE OFFSET to disp driver worked. Now it doesn't, but I don't understand how it could work before.
<naggety>
But programs like GStreamer and ffmpeg work well with the driver with videobuf2, so it is not a tv-decoder driver fault
<naggety>
I'm thinking that the best I can do is patching disp driver.
<naggety>
In disp driver (kernel space) can I get physical address only with offset value previously returned by tv-decoder driver? Without passing the file descriptor to disp driver.
<naggety>
the file descriptor of the tv-decoder driver, I mean
cnxsoft has quit [Quit: cnxsoft]
<naggety>
Like this:
<naggety>
1 - User space get the offset from tv-decoder driver
<naggety>
2 - User space program pass that offset to disp driver
<naggety>
3 - disp driver convert it to physical address
<naggety>
Or maybe:
<naggety>
1 - User space program get the offset from tv-decoder and get the virtual address with mmap
<naggety>
2 - User space program pass to disp driver the virtual address
<naggety>
3 - disp driver convert that virtual address to physical address
<naggety>
Is something like this possible?
xerpi has joined #linux-sunxi
xerpi has quit [Remote host closed the connection]
xerpi has joined #linux-sunxi
<hitech95>
KotCzarny, beeble. It was an issue with the power supply. The pmic for some odd reason shut down the board. Now I have problems with the bluetooth xD
willmore has quit [Ping timeout: 245 seconds]
Putti has joined #linux-sunxi
kaspter has quit [Ping timeout: 240 seconds]
OnkelUlla has quit [Ping timeout: 276 seconds]
megi has quit [Quit: WeeChat 2.1]
Gerwin_J has joined #linux-sunxi
<hitech95>
huys is there someone that know hot the audio layer works?
AneoX has quit [Read error: Connection reset by peer]
IgorPec has quit [Ping timeout: 240 seconds]
matthias_bgg has quit [Quit: Leaving]
fkluknav has quit [Ping timeout: 260 seconds]
IgorPec has joined #linux-sunxi
<Putti>
hitech95, is there something more specific you might want to know?
<hitech95>
Putti, right now i just would like to know why arecord -l doesen't show anythig but alsamixer have mic1 and mic2.
LargePrime has quit [Ping timeout: 240 seconds]
tom_nov has quit [Quit: Leaving]
<Putti>
hitech95, ok, I don't know about that so let's hope someone else here does