Eric Anholt offically announces support of VC4 without acces


28 posts   Page 1 of 2   1, 2
by Electron752 » Tue Mar 21, 2017 5:26 am
It appears the Eric Anholt has announced support for VC4 on mainline linux without any use of the expander. Sounds like he never needed it all along.

http://lists.infradead.org/pipermail/li ... 05945.html

BTW, If you build a mainline version of Linux yourself. You might want to remove the simple frame buffer driver. It's just dead weight.
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by ktb » Tue Mar 21, 2017 6:19 am
:D

There is a lot of activity and good news in that thread.

My favorite bit of news is from Eric's 3/13 LiveJournal post -- http://anholt.livejournal.com/52163.html
I've also started on a fix to allow arbitrary amounts of CMA memory to be used for vc4.
Posts: 1264
Joined: Fri Dec 26, 2014 7:53 pm
by Electron752 » Tue Mar 21, 2017 7:40 am
Yah, the good news is that display is working now on mainline Linux on the RPI 3. It might not have been quite the way people wanted it to, but it works now.

I kind of hope the expander driver gets tossed by the stagging maintainer in upstream. I thought the whole implementation behind it was not the best way to go. It may have accomplished something, but I don't think it's the best long term solution.

I once had a brief discussion with Eric through email about creating a stripped down VC4. He told he it would be way to difficult and he wasn't interested. It's interesting now how he's going to be able to get that accomplished, especially with all the helper/wrapper framework that it's upstream now. I wish him the best of luck on his efforts. :D
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by 321a » Tue Mar 21, 2017 7:49 am
As I've just found out what VC4 is, this link might be useful for others interested. https://en.wikipedia.org/wiki/VideoCore#Linux_support

Sounds good, because you cant always trust black boxes.
Posts: 56
Joined: Fri Mar 17, 2017 11:07 pm
by fruitoftheloom » Tue Mar 21, 2017 7:56 am
321a wrote:As I've just found out what VC4 is, this link might be useful for others interested. https://en.wikipedia.org/wiki/VideoCore#Linux_support

Sounds good, because you cant always trust black boxes.


Yes 3 years ago: https://www.raspberrypi.org/blog/a-birt ... m-broadcom
.
Ex Computer Repair & Service Technician.
RPi 3B, HP Envy 4500 Wireless Printer, Google Chromecast, Android Smart Phone, HD 1080p TV and 3/4G Mobile Internet make ideal companions.
Posts: 13322
Joined: Tue Mar 25, 2014 12:40 pm
Location: Bognor Regis UK
by Electron752 » Tue Mar 21, 2017 7:57 am
I know what you mean about block boxes. It makes one wonder what exactly is happening that they don't want people to know about.

So I wonder what it takes to get the source to the graphics stack and what exactly a clause 3 BSD license means really?
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by Electron752 » Tue Mar 21, 2017 8:11 am
Since my primary interest has always been embedded, I wonder what it would take to make a very basic firmware and boot loader that didn't support the camera and only a very stripped down no acceleration frame buffer display just for occasional debugging. Say when the thing doesn't boot.
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by ghans » Tue Mar 21, 2017 8:11 am
The old open-source release in 2014 was about the "userland" libraries. Those simply pass
all complex graphics commands to the secret firmware , which does all the "heavy lifting".

ghans
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org
Posts: 7152
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany
by 321a » Tue Mar 21, 2017 8:31 am
Electron752 wrote:Since my primary interest has always been embedded, I wonder what it would take to make a very basic firmware and boot loader that didn't support the camera and only a very stripped down no acceleration frame buffer display just for occasional debugging. Say when the thing doesn't boot.


I guess these blackboxes are not easily decompiled then? Although i am aware of decompilers mainly for windows, I've never looked into this sort of thing on the linux platform.
Do you know what would be involved? Are these blackboxes decrypted by the chip for example before being loaded? I'm sure a bit of automation could be useful in reverse engineering these blackboxes, buts its knowing where to start.
Posts: 56
Joined: Fri Mar 17, 2017 11:07 pm
by ghans » Tue Mar 21, 2017 8:42 am
• Don't like the board ? Missing features ? Change to the prosilver theme ! You can find it in your settings.
• Don't like to search the forum BEFORE posting 'cos it's useless ? Try googling : yoursearchtermshere site:raspberrypi.org
Posts: 7152
Joined: Mon Dec 12, 2011 8:30 pm
Location: Germany
by jamesh » Tue Mar 21, 2017 9:36 am
321a wrote:
Electron752 wrote:Since my primary interest has always been embedded, I wonder what it would take to make a very basic firmware and boot loader that didn't support the camera and only a very stripped down no acceleration frame buffer display just for occasional debugging. Say when the thing doesn't boot.


I guess these blackboxes are not easily decompiled then? Although i am aware of decompilers mainly for windows, I've never looked into this sort of thing on the linux platform.
Do you know what would be involved? Are these blackboxes decrypted by the chip for example before being loaded? I'm sure a bit of automation could be useful in reverse engineering these blackboxes, buts its knowing where to start.



You are about 4 years late to the party.

This has been discussed ad infinitum on the forums before. But in precis...

The firmware on the VC4 is closed source. The VC4 has 2 vector/scaler cores running their own instruction set not ARM, not x86), which has been analysed, you can find disassemblers and compilers online. Also on board are 12 Quad processors that power the 3D system and parts of the camera pipeline. These run their own instruction set, which has been published, and is horrible.

Some of the register sets have been published, e.g. the 3D stuff, not the camera or codec stuff.

Fully reverse engineering the firmware blob is nigh on impossible, although people are trying. That code took a team of 50 or more people 10 years to write, and they had access to full documentation of the HW. If you are thinking of doing it, I wouldn't bother - plenty of other stuff to learn without starting on that path.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 16933
Joined: Sat Jul 30, 2011 7:41 pm
by jamesh » Tue Mar 21, 2017 9:39 am
Electron752 wrote:I know what you mean about block boxes. It makes one wonder what exactly is happening that they don't want people to know about.

So I wonder what it takes to get the source to the graphics stack and what exactly a clause 3 BSD license means really?


There's no conspiracy here....there are no back doors, no evilness. It's simply a closed source binary blob like you get on wireless dongles, BIOS's etc. There are trade secrets in that code which Broadcom don't want people to have access to. Also, the DRM on the codecs needs to be maintained.

Eric Anholt's Open Source graphics stack is an new ARM implementation of what is current done in the firmware, plus some other bells and whistles.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 16933
Joined: Sat Jul 30, 2011 7:41 pm
by Electron752 » Tue Mar 21, 2017 10:35 am
I'm not saying anything about conspiracies. Some large company needs to dump alot of resources into making something happen, they can't afford to have people start cloning it right away. That's the way the world works and people accept that, including me.

If I were to go down this path at all, which I'm not sure it even makes any sense, would be to make a very, very small firmware replacement that just does the absolute minimum. And no I don't want to try to reverse engineer the existing stuff. Too much effort and not worth it. In fact, I really don't want to know what's in that box. Honestly.

I was thinking something with just enough bootstrap code to get everything going on the arm, and then it would shut itself down. Or at least as much as it possibly could. And no, I don't think such a system would be for the audience that typically runs Raspbian. I'm thinking more the PI 0 or compute module crowd.

But it sounds like the github link is a good starting point.
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by Electron752 » Tue Mar 21, 2017 10:46 am
Basically what I'm saying boils down to this. The end user should have choices and they should ultimately be the ones making the decision. You use the closed source firmware maybe pay for the codec pack, you get to use the camera or play video with hardware acceleration.

But people should have the option to not that use that box for whatever reason(maybe their paranoid, maybe they just believe in 100% open source, or whatever). But to get that some things just don't work.
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by gregeric » Tue Mar 21, 2017 10:54 am
jamesh wrote:You are about 4 years late to the party.
I know it can be tiresome to repeat things, but the ongoing success of the Pi means it will attract new users like 321a over and over. I remember the time I first read about the fascinating internals of the Broadcom chip, the same intrigue I imagine 321a is feeling right now.
Posts: 1437
Joined: Mon Nov 28, 2011 10:08 am
by jamesh » Tue Mar 21, 2017 11:16 am
Electron752 wrote:Basically what I'm saying boils down to this. The end user should have choices and they should ultimately be the ones making the decision. You use the closed source firmware maybe pay for the codec pack, you get to use the camera or play video with hardware acceleration.

But people should have the option to not that use that box for whatever reason(maybe their paranoid, maybe they just believe in 100% open source, or whatever). But to get that some things just don't work.


I think someone has written a small bootstrapper. Cannot remember who though, was it this guy https://github.com/dwelch67/raspberrypi?

Might be worth checking out the bare metal forum here, lots on interesting stuff being done there.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 16933
Joined: Sat Jul 30, 2011 7:41 pm
by 321a » Tue Mar 21, 2017 12:53 pm
gregeric wrote:
jamesh wrote:You are about 4 years late to the party.
I know it can be tiresome to repeat things, but the ongoing success of the Pi means it will attract new users like 321a over and over. I remember the time I first read about the fascinating internals of the Broadcom chip, the same intrigue I imagine 321a is feeling right now.


I've been using the pi's for a few years now, skipped the A's but started with the B's, the main problem is information overload or not seeing the information.

Having read a court document between the police and a uk software company, they had to describe in the court documents the processes with obtaining forensic data from phones. The steps were succinct and straight to the point, I guess they had to be in order for a judge to even understand the process.
Then having seen this thread today, I wonder whether it would be possible to rig up a device which feed data to the chip. It would be time consuming, but the chip might not have anything built in which would disable itself after so much garbage has been sent to it.

So like you can get a shim device which fits between the sata/(e)ide ports on a motherboard and hard disk in order to extract the passwords manufacturers use to encrypt drives and other data, I also wondered if some sort of device exists which could be plugged into a microSD slot/SD card adapter where you could then emulate an SD card, feeding data ultimately to a RPI.
If such a device existed, then it would be possible given enough time or resource to reverse engineer any chip which doesnt shutdown after X number of failed attempts.

I dont have time, but making a device which fed data to the videocore chip based on best guesses would be how I would approach it. Of course, until tried cant say if it would work, but feeding what was known to work would be the first test of such a hypothetical device.
Posts: 56
Joined: Fri Mar 17, 2017 11:07 pm
by jamesh » Tue Mar 21, 2017 1:01 pm
321a wrote:
gregeric wrote:
jamesh wrote:You are about 4 years late to the party.
I know it can be tiresome to repeat things, but the ongoing success of the Pi means it will attract new users like 321a over and over. I remember the time I first read about the fascinating internals of the Broadcom chip, the same intrigue I imagine 321a is feeling right now.


I've been using the pi's for a few years now, skipped the A's but started with the B's, the main problem is information overload or not seeing the information.

Having read a court document between the police and a uk software company, they had to describe in the court documents the processes with obtaining forensic data from phones. The steps were succinct and straight to the point, I guess they had to be in order for a judge to even understand the process.
Then having seen this thread today, I wonder whether it would be possible to rig up a device which feed data to the chip. It would be time consuming, but the chip might not have anything built in which would disable itself after so much garbage has been sent to it.

So like you can get a shim device which fits between the sata/(e)ide ports on a motherboard and hard disk in order to extract the passwords manufacturers use to encrypt drives and other data, I also wondered if some sort of device exists which could be plugged into a microSD slot/SD card adapter where you could then emulate an SD card, feeding data ultimately to a RPI.
If such a device existed, then it would be possible given enough time or resource to reverse engineer any chip which doesnt shutdown after X number of failed attempts.

I dont have time, but making a device which fed data to the videocore chip based on best guesses would be how I would approach it. Of course, until tried cant say if it would work, but feeding what was known to work would be the first test of such a hypothetical device.


I suspect that the number of combinations involved would mean that any such device would take until the heat death of the universe* to try all input possibilities.

It's a bit like crypto cracking, too many combinations to try .


* approx 10^100 years. So yes, you don't have the time.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 16933
Joined: Sat Jul 30, 2011 7:41 pm
by Electron752 » Tue Mar 21, 2017 1:07 pm
You know what, I think this dwelch guy is alot closer to what I'm trying to accomplish.

I'm not trying to reverse engineer the chip at all. In fact I just want to attempt and it may be beyond my ability to just get a bootstrapper running. I don't really care about those parts of the chip. I'm not interested in the camera, 3D, or codecs. Eric Anholt is already moving in that direction and that's not a direction I'm attempting to go in.

I'm just looking into the potential of running Linux in some form with an absolute bare min amount of functionality. The only parts of the kernel that I know of that could possibly be an issue is a replacement for the firmware based power manager in linux and some kind of video support. Although in theory even basic video support isn't critical but networking is important to me through.

I have absolutely no interesting in using this to run Raspbian or whatever things are moving to. So cell phones are certainly out in left field.
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by Electron752 » Tue Mar 21, 2017 1:17 pm
BTW, I'm browsing through this guys site and he has a very interesting idea in some of the directories.

In some of his examples, he uses bootcode.bin from the standard releases plus custom .elf/.dat replacements. That may well in fact be exactly what I'm looking for. Just use enough of the standard stuff to get things going but have the arm take it from there.

Like I said, the two real issues are going to be getting a basic power management driver on the arm side working and some kind of basic video support. Ideally, my thinking is that after bootup and initialization nothing from the firmware would be left active. So mailbox and what's called vc04_services would be unsupported.
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by jamesh » Tue Mar 21, 2017 1:36 pm
You do need some code running on the GPU, as that controls things like the power supply and some other bits and pieces.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 16933
Joined: Sat Jul 30, 2011 7:41 pm
by Electron752 » Tue Mar 21, 2017 1:42 pm
That's interesting...

I was kind of hoping that could be accessed from the ARM. I though the VC4 driver was doing some of that already?

I've have to read more of dwelch's examples as to exactly how much functionality bootcode.bin gives and how much would need to be written in a replacement for the .elf/.dat files.

Ideally I was hoping as much as possible could be done from the arm. That would really reduce that amount of stuff I would need to learn and possibly implement.
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by gtechn » Tue Mar 21, 2017 2:01 pm
How long is left until the driver is actually complete, fully usable, and fully stable?
Like, what is the ETA for the finished driver?

(Unless this is the finished driver.)
Posts: 11
Joined: Thu Jan 07, 2016 5:32 pm
by Electron752 » Tue Mar 21, 2017 2:10 pm
Exactly, which driver are we talking about here.

If were talking about VC4(I know that was the original topic), I have no idea. You'll need to send an email to him or contact him on his www.github.com page. That's not really something I know much about and isn't really part of what I'm thinking about because he is very interested in 3D. That's something I was thinking could be disabled, or at least as much as possible.

If we're talking about a stripped down firmware replacement, I also have no idea as I haven't started and I have idea even if I will start it.
Posts: 142
Joined: Mon Mar 02, 2015 7:09 pm
by jamesh » Tue Mar 21, 2017 4:05 pm
Electron752 wrote:That's interesting...

I was kind of hoping that could be accessed from the ARM. I though the VC4 driver was doing some of that already?

I've have to read more of dwelch's examples as to exactly how much functionality bootcode.bin gives and how much would need to be written in a replacement for the .elf/.dat files.

Ideally I was hoping as much as possible could be done from the arm. That would really reduce that amount of stuff I would need to learn and possibly implement.


Lots of stuff can be accessed from the ARM, but only if you know the correct registers and their usage. Some of those register sets have been published but not all of them. Eric's code will contain a lot of register information, for 2D/3D, HVS and anything needed to get the display up and running
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 16933
Joined: Sat Jul 30, 2011 7:41 pm