12 replies to this topic

[djod4556]

Hi there !

 

I recently acquired an old BCM97405 development board (same chip as DM500HD and DM800SE) and I'm trying to write a small framebuffer driver for the board. I already get a 3.2 linux kernel for the board but the ethernet driver was missing and there's no clue of any video/framebuffer driver.

 

Does anyone has a link on some repository where there's example of graphic pipeline usage ? How OpenPLI works on those boards ?

 

Thanks for your help !

 

Damien.

[Erik Slagter]

Images use closed source drivers for these layers. It's all closed/NDA stuff...

Edited by Erik Slagter, 24 April 2014 - 15:36.

[djod4556]

Oh crap,

 

It's what I suspected, I assume they are using the /dev/mem to access physical memory and configure/activate/use the video pipeline

 

Thanks for the answer

 

Dam.

[Erik Slagter]

Nope it works different. As the drivers run in kernel space, they can access whatever memory or io they want. Also the drivers have access to memory that even the linux kernel doesn't know of, I suspect it's used for the frame buffer, OSD and (hardware) demuxer buffers.

[pop_eye]

Also the drivers have access to memory that even the linux kernel doesn't know of, I suspect it's used for the frame buffer, OSD and (hardware) demuxer buffers.

If the memory allocation is not known by the kernel then how user space drivers are accessing it ?

Edited by pop_eye, 24 April 2014 - 19:50.

[malakudi]

Images use closed source drivers for these layers. It's all closed/NDA stuff...

 

nexus sdk for bcm7405 has been leaked in the past. Of course it is illegal to distribute it or use it in public images but noone will know if you use it at private project.

[Erik Slagter]

Also the drivers have access to memory that even the linux kernel doesn't know of, I suspect it's used for the frame buffer, OSD and (hardware) demuxer buffers.

If the memory allocation is not known by the kernel then how user space drivers are accessing it ?

I am not the expert in this particular case, but in general there are always ways to achieve this, e.g. with an explicit i/o address space, with untranslated memory access (which is possible from within the kernel, so page tables are completely bypassed). This is the strength and also the weakness of unix, a device driver runs inside the kernel and has exactly the same priviledges as the rest of the kernel, so it can really completely trash the computer. On other operating systems often several levels of priviledge are enforced with the kernel.

 

Luckily "user space drivers" (whatever you exactly mean by that) don't have such access.

Edited by Erik Slagter, 24 April 2014 - 21:18.

[Erik Slagter]

Images use closed source drivers for these layers. It's all closed/NDA stuff...

 

nexus sdk for bcm7405 has been leaked in the past. Of course it is illegal to distribute it or use it in public images but noone will know if you use it at private project.

One could at least remove the name "nexus" from the kernel messages (= VU+)

[littlesat]

Is that how the non ET boxes get WMV?

[pop_eye]

 

Also the drivers have access to memory that even the linux kernel doesn't know of, I suspect it's used for the frame buffer, OSD and (hardware) demuxer buffers.

If the memory allocation is not known by the kernel then how user space drivers are accessing it ?

I am not the expert in this particular case, but in general there are always ways to achieve this, e.g. with an explicit i/o address space, with untranslated memory access (which is possible from within the kernel, so page tables are completely bypassed). This is the strength and also the weakness of unix, a device driver runs inside the kernel and has exactly the same priviledges as the rest of the kernel, so it can really completely trash the computer. On other operating systems often several levels of priviledge are enforced with the kernel.

 

Luckily "user space drivers" (whatever you exactly mean by that) don't have such access.

There is a contradiction somewhere. Because as far as I know all dvb-modules are user space.

The typical dvb-module is loaded after kernel is loaded (or booted).

Edited by pop_eye, 25 April 2014 - 00:53.

[malakudi]

kernel modules run in kernel space.

[MiLo]

If you look at aio-grab you can get some hints as to where things are located in memory.

A big portion of the RAM is assigned to driver/hardware use. It's sometimes still accessible through /dev/mem or a normal iomap by a driver. On many of the chips, the video RAM is not directly addressable by the CPU at all, but can only be accessed via the DMA controller (see also aio-grab source code for that...).

So there are places where even the kernel (drivers, modules) can't reach into.

Reverse-engineering and using "brute force" to find interesting addresses are basically the only way to get to create a frambuffer driver.

[pieterg]

Regarding the framebuffer access from aio-grab, that only works because the kernel drivers setup a framebuffer, and mapped it at that particular address.

So that won't help if you start from scratch.