User: Password:
|
|
Subscribe / Log in / New account

Raspberry Pi VideoCore driver code released

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 0:54 UTC (Thu) by airlied (subscriber, #9104)
In reply to: Raspberry Pi VideoCore driver code released by dlang
Parent article: Raspberry Pi VideoCore driver code released

there is an ACPI interpreter in the BIOS, its not a compiler, it doesn't take highlevel C like language and compile it down to basic assembler opcodes, ACPI langugage is like assembly, GLSL is exactly like C.

But anyways I'm not sure why you think I care about your opinion, you've made up your mind that you want to live with what you are given by vendors, I'm more interested in what vendors can do to help Linux than themselves.

Like if I put the whole of Linux below the syscall interface onto a second CPU and didn't give you the source, but all apps called into it via an RPC interface, you'd probably think it was the greatest open-sourcing ever.


(Log in to post comments)

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 1:18 UTC (Thu) by dlang (subscriber, #313) [Link]

> Like if I put the whole of Linux below the syscall interface onto a second CPU and didn't give you the source, but all apps called into it via an RPC interface, you'd probably think it was the greatest open-sourcing ever.

not the greatest open-sourcing ever no :-)

but if you were talking about open-sourcing the application and software running on the first CPU, I would say that yes, the system on the first CPU was open-source, even though it called an independent system that lives on the second CPU.

I don't see this as being significantly different from an Open Source tool that makes calls to Google Maps.

If it's running on a separate CPU, and it's not doing things like sharing memory, then it doesn't count as far as the Openness of the first software.

As others have noted, if you keep drilling down, you get to things like the microcode on the x86 CPU as something that's not open, and that you are accessing through a much higher level API from what the native chip supports. The x86 CPUs can even include compilers to convert the x86 instruction set to lower level code.

Does it make Linux any less free if it's running on a Transmeta CPU than on a 80386 CPU?

Does it make Linux any less free if it's running on vmware emulating a x86 CPU instead of on native hardware?

what about running Linux on an ARM emulator running on Windows instead of on a real ARM chip?

at what point does the manipulation of the commands before they hit the actual circuit mean that the API for those commands is not 'legitimate'?

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 13:23 UTC (Thu) by pboddie (guest, #50784) [Link]

but if you were talking about open-sourcing the application and software running on the first CPU, I would say that yes, the system on the first CPU was open-source, even though it called an independent system that lives on the second CPU.

I think the objections people have to this announcement are mostly centred on the assertion that Broadcom have opened up access to the underlying technology when in practical terms all they have really done is acknowledged the nature of the API for specific functionality provided by the SoC. And all of this publicity downplays the fact that they've moved software behind the curtain and onto the proprietary CPU core.

So although this release helps people to write software against that narrow API, it's very much business as usual.

Does it make Linux any less free if it's running on a Transmeta CPU than on a 80386 CPU?

Although you can have CPUs with loadable microcode, I don't think these arguments really help the discussion along because they inevitably lead to remarks like "You can't fabricate your own CPUs, and I suppose you extremists won't be happy until the proletariat have seized control over the means of production!"

Far more illustrative is to consider things like printers supporting standard interfaces like PostScript. It's a positive thing that you can (or could) get a printer that any system could talk to using a well-defined (and hopefully standard) communications mechanism, but it's a different matter from being able to enhance the printer's own operation, if this is desirable.

And it's always necessary to question the redefinition of system boundaries because you can easily end up with a dumb terminal talking to a proprietary mainframe that does all your graphics and printing for you. Or you have all your applications running in a proprietary cloud. And so on.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 20:26 UTC (Thu) by dlang (subscriber, #313) [Link]

did they move functionality, or has their chip always worked this way?

pushing functionality away from the main CPU and providing higher level abstractions and APIs is an ongoing process that has been going on as long as computers have been around.

The assertion is that everything running on the ARM processor is now open.

They have said for a while that the source for this userspace code was not going to be particularly interesting to people, but there was still a loud demand for this code to be opened. They did so and now people are complaining that it's not interesting.

no matter what you believe the boundary of openess should be, there is no doubt that this is a move in the right direction.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 22:07 UTC (Thu) by pboddie (guest, #50784) [Link]

It's actually not correct to bundle things like abstraction together with where functionality has migrated to over the years, mostly because functionality has migrated in different directions, whereas the level of abstraction in the components of the average system has mostly increased.

For example, video control was indeed done by the CPU in various microcomputers and then migrated to dedicated circuits of different forms and with increased sophistication, but other activities - notoriously, modems and printers - have seen the CPU bear the bulk of the workload in various periods. Much of this depends on whether it is considered worthwhile to have dedicated hardware for a particular task that could be done in software running on general purpose hardware.

I agree that for practical purposes being able to build these "drivers" from source increases the general level of support for the SoC in Free Software projects and is thus an improvement on the previous situation, but given the limitations on actually modifying the system's behaviour (the objections brought up by various driver developers), it's clearly not the milestone that we've been sold by the announcement.

Raspberry Pi VideoCore driver code released

Posted Oct 25, 2012 23:23 UTC (Thu) by ncm (subscriber, #165) [Link]

It depends on whether the second CPU has access to the RAM and devices of the first, no?

Raspberry Pi VideoCore driver code released

Posted Oct 26, 2012 9:37 UTC (Fri) by renox (subscriber, #23785) [Link]

>It depends on whether the second CPU has access to the RAM and devices of the first, no?

As if there wasn't other devices with drivers in the Linux kernel which has closed source firmware and which can corrupt your RAM with DMA.
If memory serves, the IO-MMU which can protect you from buggy devices is(was?) often deactivated because it didn't work correctly..


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds