USB - the Elephant in our Room


 
803 posts   Page 28 of 33   1 ... 25, 26, 27, 28, 29, 30, 31 ... 33
by tufty » Fri Nov 02, 2012 6:03 pm
obcd wrote:Is there a post here that might give a different impression? ;)
I just didn't found the performance boost a satisfying answer explaining why the usb driver would be implemented as FIQ first and as VPU code afterwards?

FIQ code keeps the entirety of the driver on the ARM side and thus open source. Moving to a GPU implementation means that a part of the driver becomes, of necessity, closed source, and thus the foundation gets flamed for not being open source enough. Again.

Simon
Posts: 1368
Joined: Sun Sep 11, 2011 2:32 pm
by jamesh » Fri Nov 02, 2012 9:41 pm
The Foundation can NEVER win. Whatever we do!
Soon to be employed engineer - Hurrah! Volunteer at the Raspberry Pi Foundation, helper at PiAcademy September 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11902
Joined: Sat Jul 30, 2011 7:41 pm
by thradtke » Fri Nov 02, 2012 9:48 pm
Everyone providing an open forum will get positive as well as negative response, except those without success ;-). Take it as an expression of high interest.
Full-time noob forever.
Posts: 431
Joined: Wed May 16, 2012 5:16 am
Location: Germany / EL
by obcd » Fri Nov 02, 2012 10:00 pm
I was hoping for an answer from one of the foundation members involved.
It would be a win win situation for me and the foundation. :|
Posts: 890
Joined: Sun Jul 29, 2012 9:06 pm
by ... » Sat Nov 03, 2012 1:24 am
jamesh wrote:The Foundation can NEVER win. Whatever we do!


Maybe if you spent some of your profits on hiring more programmers and engineers...
Posts: 11
Joined: Mon Oct 29, 2012 7:05 am
by Lob0426 » Sat Nov 03, 2012 4:11 am
tufty wrote:
obcd wrote:Is there a post here that might give a different impression? ;)
I just didn't found the performance boost a satisfying answer explaining why the usb driver would be implemented as FIQ first and as VPU code afterwards?

FIQ code keeps the entirety of the driver on the ARM side and thus open source. Moving to a GPU implementation means that a part of the driver becomes, of necessity, closed source, and thus the foundation gets flamed for not being open source enough. Again.

Simon


I say do what will work best. The Open Source or DEATH people, will complain either way.
512MB version 2.0 as WordPress Server
Motorola Lapdock with 512MB
Modded Rev 1.0 with pin headers at USB

http://rich1.dyndns.tv/
(RS)Allied ships old stock to reward its Customers for long wait!
User avatar
Posts: 1940
Joined: Fri Aug 05, 2011 4:30 pm
Location: Susanville CA.
by mic34 » Sat Nov 03, 2012 9:36 am
dom wrote:
... wrote:I thought the approach was to make a EHCI translation layer which would run on the GPU?

That's a distant goal. The code Gordon is working on now is FIQ based.


Dom, can we infer from your statement that a FIQ based solution is not distant, ie close? ;)

Seriously, an order of magnitude for the estimated timescale for this long awaited USB fix would be extremely helpful and welcome.
Posts: 8
Joined: Sun Oct 07, 2012 8:53 am
by jamesh » Sat Nov 03, 2012 9:39 am
... wrote:
jamesh wrote:The Foundation can NEVER win. Whatever we do!


Maybe if you spent some of your profits on hiring more programmers and engineers...


And maybe if you were not so unrelentingly negative people would listen to what you have to say?

And since you have no idea what the Foundation is doing behind the scenes (obviously), perhaps it would be better to keep your thoughts to yourself? The problem with making *assumptions* then spouting off about them on the internet, is that it comes back to haunt you. The internet never forgets.
Soon to be employed engineer - Hurrah! Volunteer at the Raspberry Pi Foundation, helper at PiAcademy September 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11902
Joined: Sat Jul 30, 2011 7:41 pm
by p4trykx » Sat Nov 03, 2012 9:42 am
tufty wrote:FIQ code keeps the entirety of the driver on the ARM side and thus open source. Moving to a GPU implementation means that a part of the driver becomes, of necessity, closed source,

Why does this driver have to be closed source?
Posts: 120
Joined: Wed Jan 11, 2012 2:55 pm
by jamesh » Sat Nov 03, 2012 9:47 am
p4trykx wrote:
tufty wrote:FIQ code keeps the entirety of the driver on the ARM side and thus open source. Moving to a GPU implementation means that a part of the driver becomes, of necessity, closed source,

Why does this driver have to be closed source?


Anything that runs on the GPU is closed source. FIQ code will run on the Arm and therefore will be open source.
Soon to be employed engineer - Hurrah! Volunteer at the Raspberry Pi Foundation, helper at PiAcademy September 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11902
Joined: Sat Jul 30, 2011 7:41 pm
by mahjongg » Sat Nov 03, 2012 9:54 am
The GPU is a proprietary piece of digital logic, which can execute a proprietary assembly language assembled with a proprietary assembler.

Its not simply "closed" software running on a known architecture.

So no actual code can be released, as it would divulge details about the GPU that Broadcom doesn't want to be divulged, because it would show the competition how their GPU hardware works.
User avatar
Forum Moderator
Forum Moderator
Posts: 5690
Joined: Sun Mar 11, 2012 12:19 am
by jamesh » Sat Nov 03, 2012 10:50 am
mahjongg wrote:The GPU is a proprietary piece of digital logic, which can execute a proprietary assembly language assembled with a proprietary assembler.

Its not simply "closed" software running on a known architecture.

So no actual code can be released, as it would divulge details about the GPU that Broadcom doesn't want to be divulged, because it would show the competition how their GPU hardware works.


We do have a C/C++ compiler as well!
Soon to be employed engineer - Hurrah! Volunteer at the Raspberry Pi Foundation, helper at PiAcademy September 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11902
Joined: Sat Jul 30, 2011 7:41 pm
by obcd » Sat Nov 03, 2012 3:32 pm
So, by reveiling a piece of code (that has nothing to do with graphics) that runs on one of the 47 cores which forms the soc gpu, competitors would be able to figure out how the gpu was designed?

I can understand that Broadcom needs to give it's permission before the code can be made public.

It still doesn't explain why we need both the FIQ and VPU approach.
If the driver can't be made public, so be it.
If it works as expected, I have no need to start digging into it's source.
Posts: 890
Joined: Sun Jul 29, 2012 9:06 pm
by jamesh » Sat Nov 03, 2012 3:42 pm
obcd wrote:So, by reveiling a piece of code (that has nothing to do with graphics) that runs on one of the 47 cores which forms the soc gpu, competitors would be able to figure out how the gpu was designed?

I can understand that Broadcom needs to give it's permission before the code can be made public.

It still doesn't explain why we need both the FIQ and VPU approach.
If the driver can't be made public, so be it.
If it works as expected, I have no need to start digging into it's source.


You already have ALL the source code for the driver right now - feel free to dive in - there are lots of people complaining, but very few actually trying to help! At the moment, no GPU code has been written - and it may never be written depending on how the FIQ approach goes. I believe it was proposed because the GPU can service interrupts much faster than the Arm, so it was an option should the Arm not be fast enough.

As to revealing code, there is no problem with C code fragments like a driver giving away secrets, BUT, no-one would be able to compile it and build it in to the GPU blob anyway, so it would just be an reading exercise. But like I said, no GPU code for this USB issue exists, so it's a moot point anyway.
Soon to be employed engineer - Hurrah! Volunteer at the Raspberry Pi Foundation, helper at PiAcademy September 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11902
Joined: Sat Jul 30, 2011 7:41 pm
by gsh » Sat Nov 03, 2012 8:28 pm
Actually the point is that you'll not have access to a compiler capable of compiling the driver so having the source wouldn't help anyway...

And since the source would be 'almost' exactly the same in the FIQ as in the GPU then it really doesn't make any difference. Personally I'd say we'll just leave it in the FIQ and leave up to the linux community to care / not care about having a FIQ in Linux...

No the EHCI solution is not imminent, there is progress, but basically I still am the only person capable of doing work on it (since no-one else seems to be interested in helping out). I have found a bug in the current FIQ fix though so would be interested to know if people complaining of the ethernet dropping out can do the following:

Wait until it crashes out...

sudo -s
echo 08 > /sys/devices/platform/bcm2708_usb/regoffset
cat /sys/devices/platform/bcm2708_usb/regvalue

I expect the value to be 0x00000031

If the value is 0x00000030 then do this:

echo 0x31 > /sys/devices/platform/bcm2708_usb/regvalue

If this fixes the ethernet it will be very useful to know...

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 789
Joined: Sat Sep 10, 2011 11:43 am
by mahjongg » Sun Nov 04, 2012 12:34 am
jamesh wrote:We do have a C/C++ compiler as well!

Ah, yes... Obviously I was only talking about writing assembler code, which I would think would be the norm for writing code for the GPU. Obviously if you can also use C (C++) then there is no reason not to divulge the code, but as was already said, I would strongly suspect it would be remarkably like the ARM fast interrupt (FIQ) code in that case, as its simply doing the very same job..
User avatar
Forum Moderator
Forum Moderator
Posts: 5690
Joined: Sun Mar 11, 2012 12:19 am
by jamesh » Sun Nov 04, 2012 9:08 am
mahjongg wrote:
jamesh wrote:We do have a C/C++ compiler as well!

Ah, yes... Obviously I was only talking about writing assembler code, which I would think would be the norm for writing code for the GPU. Obviously if you can also use C (C++) then there is no reason not to divulge the code, but as was already said, I would strongly suspect it would be remarkably like the ARM fast interrupt (FIQ) code in that case, as its simply doing the very same job..


In fact the vast majority of code is C - speed of development and maintenance reasons as much as anything. We need to use assembler for vector code or very time critical stuff.
Soon to be employed engineer - Hurrah! Volunteer at the Raspberry Pi Foundation, helper at PiAcademy September 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11902
Joined: Sat Jul 30, 2011 7:41 pm
by Sandgrounder » Sun Nov 04, 2012 11:46 am
This discussion is very interesting but does not solve the problem.

I am trying to transfer a "Gbyte file to a USB memory stick with FTP from a WinXP box and it keeps crashing. I have tried two different memory sticks .

Is there a work around to make this work? ( I have tried smsc95xx.turbo_mode=N)
Posts: 28
Joined: Fri Jul 20, 2012 3:22 pm
by MaxK1 » Sun Nov 04, 2012 12:38 pm
Need more details. Distro, overclocking and whether everything is up to date etc. When you say "it" keeps crashing, do you mean the Pi or FTP? Any logs available?

I'll assume you have checked that there is room on the stick for the file ;-)
Posts: 492
Joined: Sun Aug 26, 2012 11:34 pm
by jamesh » Sun Nov 04, 2012 12:53 pm
One way to test - instead of copying to the stick, copy to /dev/nul. So if it still goes wrong it indicates a ethernet problem. But more information is needed - wired or wireless? DIstro?

Although these discussions don't fix the problem, the problem is being worked on. There is no 'final solution' as yet.
Soon to be employed engineer - Hurrah! Volunteer at the Raspberry Pi Foundation, helper at PiAcademy September 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11902
Joined: Sat Jul 30, 2011 7:41 pm
by Sandgrounder » Sun Nov 04, 2012 1:56 pm
OK - sorry. I should have added more details.

The build is the Rasbian build as supplied by Farnell two weeks ago ....
.... but I have run apt-get update and apt-get upgrade a number of times including today.

It is the Pi which crashes when the file is partly transfered. There is room on both sticks. I tried it on two Pis - both 512M from Farnel two weeks ago.

Since my last post, I have thought of a work around, which is to use raspi-config to extend the root partition to the full 16Gbyte avalable on the CD card and to FTP the file to that. (worked first time). I can also copy the 2Gbyte file from the SD card to the USB memory sticks with no problems. It is when I try to use the wired Network and the USB stick at the same time that Raspbian falls over.

I will leave you alone to discuss the USB problem, unless you want to tell me where I might find any log information. I can not see anyting in /var/log/messages but I am not sure what to look for.
Posts: 28
Joined: Fri Jul 20, 2012 3:22 pm
by MaxK1 » Sun Nov 04, 2012 2:23 pm
Does it get to a certain point and then crap out, or does it transfer a random amount or choke right away? Does it work with smaller files?
Posts: 492
Joined: Sun Aug 26, 2012 11:34 pm
by mic34 » Sun Nov 04, 2012 3:02 pm
jamesh wrote:One way to test - instead of copying to the stick, copy to /dev/nul. So if it still goes wrong it indicates a ethernet problem. But more information is needed - wired or wireless? DIstro?

Although these discussions don't fix the problem, the problem is being worked on. There is no 'final solution' as yet.


Jamesh, I see here https://github.com/raspberrypi/firmware/issues/19 that the USB problem has been identified and worked on for 6 months already, has the foundation or Broadcom given itself a deadline to fix it?
Posts: 8
Joined: Sun Oct 07, 2012 8:53 am
by Kemp » Sun Nov 04, 2012 3:49 pm
mic34 wrote:Jamesh, I see here https://github.com/raspberrypi/firmware/issues/19 that the USB problem has been identified and worked on for 6 months already, has the foundation or Broadcom given itself a deadline to fix it?


From reading the rest of this thread, it appears that Broadcom have no interest in fixing their problems and the foundation doesn't have the manpower to give you a deadline. As always, if anyone is willing to help they will gladly accept it...
Posts: 29
Joined: Tue Jul 03, 2012 12:56 pm
by mic34 » Sun Nov 04, 2012 4:25 pm
Kemp wrote: From reading the rest of this thread, it appears that Broadcom have no interest in fixing their problems and the foundation doesn't have the manpower to give you a deadline. As always, if anyone is willing to help they will gladly accept it...


It has been said that Gordon is a Broadcom employee, so surely they must have given him a deadline for this task?
Posts: 8
Joined: Sun Oct 07, 2012 8:53 am