Eric Anholt offically announces support of VC4 without acces

[Electron752]

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.

[ktb]

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.

[Electron752]

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.

[321a]

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.

[fruitoftheloom]

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

[Electron752]

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?

[Electron752]

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.

[ghans]

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

[321a]

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.

[ghans]

https://github.com/christinaa/rpi-open-firmware

lots to do ...

ghanw

[jamesh]

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.

[jamesh]

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.

[Electron752]

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.

[Electron752]

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.

[gregeric]

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.

[jamesh]

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.

[321a]

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.

[jamesh]

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.

[Electron752]

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.

[Electron752]

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.

[jamesh]

You do need some code running on the GPU, as that controls things like the power supply and some other bits and pieces.

[Electron752]

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.

[gtechn]

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.)

[Electron752]

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.

[jamesh]

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