Hi Guys
I was talking to Jason and we found we need to draw a bit better the API and responsibilities between us. I figure out I`m going to support hardware detection and initialization, and a framework to read and write blocks from MSC devices.
Looking the current libpayload`s source code I found UHCI is pretty complete and meets the requirements I mentioned above. So, the focus should be put on EHCI and OHCI. Of course bug fixing what becomes needed as well.
Again looking in the source code, I found abstractions that will ease the process of coupling the other host controller interface drivers, I don`t have many questions regarding the internal design and API of libpayload(by now at least) but how Jason is going to integrate and use libpayload usb stack.
To test and improve my understanding I put together[1] some code from FILO, libpayload and a stub option ROM, just to see how it`s supposed to be integrate(PS: this option ROM is a work in progress and will be used just for testing the usb implementations I`m going to do, and it`s not functional yet).
For now, I have two major questions, #1: I`ve seen other projects like FILO including libpayload with svn:external, once seabios is maintained with git, how it should be done with seabios? how would we manage the source code integration and maintainability between seabios and libpayload?. #2: libpayload uses kbuild/kconfig but seabios doesn`t, what would be the best approach to integrate their build system? (PS: Sorry, it wasn`t two questions, but many questions and two areas. ;-) )
A third questions would be, how people test the libpayload stuffs? do they write small payloads for that? is that feasible writing an option ROM for testing the libpayload`s usb stack?
A last question. Should I CC the mentors and people I judge interested? or, is coreboot@coreboot.org good enough? ;-)
[1] - http://vps.dorilex.net/cgi-bin/gitweb.cgi
Thanks in advance....
Hi all,
On Wed, May 6, 2009 at 10:05 PM, Leandro Dorileo ldorileo@gmail.com wrote:
Hi Guys
I was talking to Jason and we found we need to draw a bit better the API and responsibilities between us. I figure out I`m going to support hardware detection and initialization, and a framework to read and write blocks from MSC devices.
i also want to know how can i support the api functions with option rom. I have a little doubt that the hardware detection and initialization can be done with out optionrom which in my eyes should be done within optionrom.
Looking the current libpayload`s source code I found UHCI is pretty complete and meets the requirements I mentioned above. So, the focus should be put on EHCI and OHCI. Of course bug fixing what becomes needed as well.
Again looking in the source code, I found abstractions that will ease the process of coupling the other host controller interface drivers, I don`t have many questions regarding the internal design and API of libpayload(by now at least) but how Jason is going to integrate and use libpayload usb stack.
To test and improve my understanding I put together[1] some code from FILO, libpayload and a stub option ROM, just to see how it`s supposed to be integrate(PS: this option ROM is a work in progress and will be used just for testing the usb implementations I`m going to do, and it`s not functional yet).
For now, I have two major questions, #1: I`ve seen other projects like FILO including libpayload with svn:external, once seabios is maintained with git, how it should be done with seabios? how would we manage the source code integration and maintainability between seabios and libpayload?.
that's also what i am thinking about, mabe we can put the optionrom in coreboot, just let the seabios to load the optionrom .
#2: libpayload uses kbuild/kconfig but seabios doesn`t, what would be the best approach to integrate their build system? (PS: Sorry, it wasn`t two questions, but many questions and two areas. ;-) )
A third questions would be, how people test the libpayload stuffs? do they write small payloads for that? is that feasible writing an option ROM for testing the libpayload`s usb stack?
A last question. Should I CC the mentors and people I judge interested? or, is coreboot@coreboot.org good enough? ;-)
[1] - http://vps.dorilex.net/cgi-bin/gitweb.cgi
Thanks in advance....
-- (°= Leandro Dorileo //\ ldorileo@gmail.com - http://www.dorilex.net V_/ Software is a matter of freedom.
Hi Jason
On Thu, May 7, 2009 at 11:34 AM, Jason Wang wangqingpei@gmail.com wrote:
Hi all,
On Wed, May 6, 2009 at 10:05 PM, Leandro Dorileo ldorileo@gmail.com wrote:
Hi Guys
I was talking to Jason and we found we need to draw a bit better the API and responsibilities between us. I figure out I`m going to support hardware detection and initialization, and a framework to read and write blocks from MSC devices.
i also want to know how can i support the api functions with option rom. I have a little doubt that the hardware detection and initialization can be done with out optionrom which in my eyes should be done within optionrom.
AFAICS the libpayload will supply the option ROM with a common API that knows how to detect the Host Controller Interfaces, the functions/hubs plugged in and so on. The option ROM should organize the execution path using the libpayload usb stack.
That`s what I understand, and it`s how I`ve designed things to work, I may be wrong of course. ;-)
Looking the current libpayload`s source code I found UHCI is pretty complete and meets the requirements I mentioned above. So, the focus should be put on EHCI and OHCI. Of course bug fixing what becomes needed as well.
Again looking in the source code, I found abstractions that will ease the process of coupling the other host controller interface drivers, I don`t have many questions regarding the internal design and API of libpayload(by now at least) but how Jason is going to integrate and use libpayload usb stack.
To test and improve my understanding I put together[1] some code from FILO, libpayload and a stub option ROM, just to see how it`s supposed to be integrate(PS: this option ROM is a work in progress and will be used just for testing the usb implementations I`m going to do, and it`s not functional yet).
For now, I have two major questions, #1: I`ve seen other projects like FILO including libpayload with svn:external, once seabios is maintained with git, how it should be done with seabios? how would we manage the source code integration and maintainability between seabios and libpayload?.
that's also what i am thinking about, mabe we can put the optionrom in coreboot, just let the seabios to load the optionrom .
I hadn`t thought that but I think there`s no technical limitations for that. Very well thought any way. ;-)
#2: libpayload uses kbuild/kconfig but seabios doesn`t, what would be the best approach to integrate their build system? (PS: Sorry, it wasn`t two questions, but many questions and two areas. ;-) )
A third questions would be, how people test the libpayload stuffs? do they write small payloads for that? is that feasible writing an option ROM for testing the libpayload`s usb stack?
A last question. Should I CC the mentors and people I judge interested? or, is coreboot@coreboot.org good enough? ;-)
Regards..
On Wed, May 6, 2009 at 8:05 AM, Leandro Dorileo ldorileo@gmail.com wrote:
For now, I have two major questions, #1: I`ve seen other projects like FILO including libpayload with svn:external, once seabios is maintained with git, how it should be done with seabios? how would we manage the source code integration and maintainability between seabios and libpayload?. #2: libpayload uses kbuild/kconfig but seabios doesn`t, what would be the best approach to integrate their build system? (PS: Sorry, it wasn`t two questions, but many questions and two areas. ;-) )
Kevin and others probably has some opinion about this but I think that you should start with libpayload and worry about the integration later.
A third questions would be, how people test the libpayload stuffs? do they write small payloads for that? is that feasible writing an option ROM for testing the libpayload`s usb stack?
Yes, an option ROM built with libpayload would be a good way to test. The ROM can test USB directly and it can also provide the API. (This may answer question 1 and 2. SeaBIOS can always load the option ROM that can extend SeaBIOS's services).
Marc
On Wed, May 06, 2009 at 10:05:34AM -0400, Leandro Dorileo wrote:
For now, I have two major questions, #1: I`ve seen other projects like FILO including libpayload with svn:external, once seabios is maintained with git, how it should be done with seabios? how would we manage the source code integration and maintainability between seabios and libpayload?. #2: libpayload uses kbuild/kconfig but seabios doesn`t, what would be the best approach to integrate their build system? (PS: Sorry, it wasn`t two questions, but many questions and two areas. ;-) )
As I understand the GSOC project, it is to build an option rom that provides usb services to applications that use legacy bios functions. I don't believe the project is specific to SeaBIOS. That is, the project is to build an option rom that uses libpayload, not to add libpayload to SeaBIOS.
-Kevin
On 08.05.2009 03:02, Kevin O'Connor wrote:
As I understand the GSOC project, it is to build an option rom that provides usb services to applications that use legacy bios functions. I don't believe the project is specific to SeaBIOS. That is, the project is to build an option rom that uses libpayload, not to add libpayload to SeaBIOS.
Yes, that's the idea.
Regards, Carl-Daniel
-
Carl-Daniel Hailfinger -
Jason Wang -
Kevin O'Connor -
Leandro Dorileo -
Marc Jones