Hi all, Right now, I start laying down the infrastructure for the Windows version of flashrom utility, i.e. the kernel mode driver and the very basic user mode application. Because this version of flashrom will be quite different in terms of code due to inherent differences between Linux/other Unix and Windows, I think it's better to put it as a "branch" of the flashrom directory. I'm still thinking about the way to incorporate the flash chip and motherboard support in as seamless way as possible so that every newer chip/motherboard support will be merged easily. In the mean time I need the information on how to commit the code once I have a tested version of the Winflashrom. Anyway, I wonder how the qa (Quality Assurance / auto build, etc.) system will handle a windows version source code :-? especially the header files.
Regards, Darmawan
Hello Darmawan
May I request -- quite urgently -- that if at all possible you make this proposed "Windows Flash Rom" boot into MSDOS as well?
XP, I know, doesn't support MSDOS; but if you do not also allow a boot into MSDOS, the XO will be,missing a truly enormous opportunity as an educational tool.
Cheers, Martin Woodhouse
Darmawan Salihun darmawan.salihun@gmail.com wrote: Hi all, Right now, I start laying down the infrastructure for the Windows version of flashrom utility, i.e. the kernel mode driver and the very basic user mode application. Because this version of flashrom will be quite different in terms of code due to inherent differences between Linux/other Unix and Windows, I think it's better to put it as a "branch" of the flashrom directory. I'm still thinking about the way to incorporate the flash chip and motherboard support in as seamless way as possible so that every newer chip/motherboard support will be merged easily. In the mean time I need the information on how to commit the code once I have a tested version of the Winflashrom. Anyway, I wonder how the qa (Quality Assurance / auto build, etc.) system will handle a windows version source code :-? especially the header files.
Regards, Darmawan
Hi Martin, It is quite complicated to incorporate DOS support this time around because we will need a DOS extender, such as DOS4GW or something else that can provide us access to the 4GB linear address space. I'm not experienced enough in that kind of thing. If you have seen Uniflash, it's maybe a better choice for you right now because it also comes with source code ;-). Yeah, uniflash maybe a little outdated, but it runs on top of DOS. I might add DOS support in the future though. Nonetheless, it's not in the top priority list at the moment, due to various constraints.
Cheers, Darmawan
MARTIN WOODHOUSE wrote:
Hello Darmawan
May I request -- quite urgently -- that if at all possible you make this proposed "Windows Flash Rom" boot into MSDOS as well?
XP, I know, doesn't support MSDOS; but if you do not also allow a boot into MSDOS, the XO will be,missing a truly enormous opportunity as an educational tool.
Cheers, Martin Woodhouse
*/Darmawan Salihun darmawan.salihun@gmail.com/* wrote:
Hi all, Right now, I start laying down the infrastructure for the Windows version of flashrom utility, i.e. the kernel mode driver and the very basic user mode application. Because this version of flashrom will be quite different in terms of code due to inherent differences between Linux/other Unix and Windows, I think it's better to put it as a "branch" of the flashrom directory. I'm still thinking about the way to incorporate the flash chip and motherboard support in as seamless way as possible so that every newer chip/motherboard support will be merged easily. In the mean time I need the information on how to commit the code once I have a tested version of the Winflashrom. Anyway, I wonder how the qa (Quality Assurance / auto build, etc.) system will handle a windows version source code :-? especially the header files. Regards, Darmawan -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
Hi Darmawan
No problem, I'm thinking about making MSDOS-booting USB RAM-sticks and doing things that way round.
Cheers, Martin
Darmawan Salihun darmawan.salihun@gmail.com wrote: Hi Martin, It is quite complicated to incorporate DOS support this time around because we will need a DOS extender, such as DOS4GW or something else that can provide us access to the 4GB linear address space. I'm not experienced enough in that kind of thing. If you have seen Uniflash, it's maybe a better choice for you right now because it also comes with source code ;-). Yeah, uniflash maybe a little outdated, but it runs on top of DOS. I might add DOS support in the future though. Nonetheless, it's not in the top priority list at the moment, due to various constraints.
Cheers, Darmawan
MARTIN WOODHOUSE wrote:
Hello Darmawan
May I request -- quite urgently -- that if at all possible you make this proposed "Windows Flash Rom" boot into MSDOS as well?
XP, I know, doesn't support MSDOS; but if you do not also allow a boot into MSDOS, the XO will be,missing a truly enormous opportunity as an educational tool.
Cheers, Martin Woodhouse
*/Darmawan Salihun /* wrote:
Hi all, Right now, I start laying down the infrastructure for the Windows version of flashrom utility, i.e. the kernel mode driver and the very basic user mode application. Because this version of flashrom will be quite different in terms of code due to inherent differences between Linux/other Unix and Windows, I think it's better to put it as a "branch" of the flashrom directory. I'm still thinking about the way to incorporate the flash chip and motherboard support in as seamless way as possible so that every newer chip/motherboard support will be merged easily. In the mean time I need the information on how to commit the code once I have a tested version of the Winflashrom. Anyway, I wonder how the qa (Quality Assurance / auto build, etc.) system will handle a windows version source code :-? especially the header files.
Regards, Darmawan
-- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
* Darmawan Salihun darmawan.salihun@gmail.com [070518 13:33]:
I'm still thinking about the way to incorporate the flash chip and motherboard support in as seamless way as possible so that every newer chip/motherboard support will be merged easily.
I wonder whether we could create human readable config files describing the mainboard and flash chip support, instead of compiling this information directly into flashrom. This way both the windows and the linux version could use the same files easily.
Anyway, I wonder how the qa (Quality Assurance / auto build, etc.)system will handle a windows version source code :-? especially the header files.
There is no qa for flashrom at all at the moment. ;)
We could hook it up to the test system, if someone offers a patch.
* MARTIN WOODHOUSE hokusai@btinternet.com [070518 14:07]:
Hello Darmawan
May I request -- quite urgently -- that if at all possible you make this proposed "Windows Flash Rom" boot into MSDOS as well?
XP, I know, doesn't support MSDOS; but if you do not also allow a boot into MSDOS, the XO will be,missing a truly enormous opportunity as an educational tool.
The XO is using a forked version of flashrom already, it is called olpcflash there. Since it comes with Linux preinstalled, it should be easier to use Linux than to try getting MSDOS working on there..!?
Stefan
On Fri, May 18, 2007 at 01:07:07PM +0100, MARTIN WOODHOUSE wrote:
May I request -- quite urgently -- that if at all possible you make this proposed "Windows Flash Rom" boot into MSDOS as well?
Miscommunication here I think.
Winflashrom is a Windows version of the flashrom utility, which is used only to program a binary file (such as linuxbios.rom) into a flash chip.
So, this is only an auxiliary tool.
Re. booting MS-DOS I think that FreeDOS would be easy to adjust so that it can be booted from LinuxBIOS, but personally I have very little motivation for that.
If there was a DOS program that I wanted to use I would instead make an effort to port it over to Linux. :)
//Peter
On Fri, May 18, 2007 at 06:33:42PM +0700, Darmawan Salihun wrote:
Because this version of flashrom will be quite different in terms of code due to inherent differences between Linux/other Unix and Windows, I think it's better to put it as a "branch" of the flashrom directory.
Please don't make a subdirectory of flashrom. I would instead suggest creating a new directory in util/ e.g. named winflashrom or whatever you prefer.
I'm still thinking about the way to incorporate the flash chip and motherboard support in as seamless way as possible so that every newer chip/motherboard support will be merged easily.
I can come up with two ways:
1. Use a database separate from the programs (as suggest by Stefan) 2. Create a library used by both programs.
I prefer 2 a lot;
* No database file to keep track of, the binary ALWAYS works * For winflashrom the database needs to be sent to the kernel driver somehow, if not right now then I think at least in the future. That means extra work, when it could just be in code already.
The benefit of 1 is that the database can be updated at any time. But I think at least the Windows version should have more intelligence in the kernel driver than in the application so upgrading will be a largeish operation anyway.
In the mean time I need the information on how to commit the code once I have a tested version of the Winflashrom.
What you do is send a signed off patch to the mailing list. Use svn diff to produce it. Then people on the list review and if it looks good it gets committed. :)
Anyway, I wonder how the qa (Quality Assurance / auto build, etc.) system will handle a windows version source code :-? especially the header files.
What is your current development environment? I would like it a lot if you could write the software so that it is possible to build with MinGW, then it could be cross-compiled easily and binaries could be generated automatically.
//Peter
Peter Stuge wrote:
In the mean time I need the information on how to commit the code once I have a tested version of the Winflashrom.
What you do is send a signed off patch to the mailing list. Use svn diff to produce it. Then people on the list review and if it looks good it gets committed. :)
OK. I'm new to svn. So, this kind of hint is helpful ;-)
Anyway, I wonder how the qa (Quality Assurance / auto build, etc.) system will handle a windows version source code :-? especially the header files.
What is your current development environment? I would like it a lot if you could write the software so that it is possible to build with MinGW, then it could be cross-compiled easily and binaries could be generated automatically.
I'm currently using Windows 2003 DDK to create the driver and Visual C++ 2003 to create the user mode application. I think the user mode application may be quite easy to port to MinGW. However, the device driver will stay as it is.
Cheers, Darmawan
* Darmawan Salihun darmawan.salihun@gmail.com [070519 06:09]:
What is your current development environment? I would like it a lot if you could write the software so that it is possible to build with MinGW, then it could be cross-compiled easily and binaries could be generated automatically.
I'm currently using Windows 2003 DDK to create the driver and Visual C++ 2003 to create the user mode application. I think the user mode application may be quite easy to port to MinGW. However, the device driver will stay as it is.
Microsoft Visual C++ can be downloaded for free from their web site. It's actually not a bad compiler! I've been doing cross compiles by installing it in a vmware virtual machine together with cygwin's opensshd and controlling it via ssh from linux shell scripts. Works like a charm.
Stefan
On Sat, May 19, 2007 at 11:09:08AM +0700, Darmawan Salihun wrote:
OK. I'm new to svn. So, this kind of hint is helpful ;-)
Have a look at the SVN book: http://svnbook.red-bean.com/
What is your current development environment? I would like it a lot if you could write the software so that it is possible to build with MinGW, then it could be cross-compiled easily and binaries could be generated automatically.
I'm currently using Windows 2003 DDK to create the driver
The DDK is obviously not a development environment, but I guess you're building also the driver with VC++.
Dunno if gcc can build drivers.
and Visual C++ 2003 to create the user mode application. I think the user mode application may be quite easy to port to MinGW.
If you want to look into MinGW I think that would be awesome. It does not require porting unless you are doing very compiler specific (=bad, IMHO) things in your code.
However, the device driver will stay as it is.
You want to stick with VC, that's perfectly fine of course.
//Peter
On Sat, May 19, 2007 at 09:12:12AM +0200, Stefan Reinauer wrote:
installing it in a vmware virtual machine together with cygwin's opensshd and controlling it via ssh from linux shell scripts.
Crossing the bridge to get water eh? I will never like that. :p
//Peter
On 5/20/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Sat, May 19, 2007 at 11:09:08AM +0700, Darmawan Salihun wrote:
OK. I'm new to svn. So, this kind of hint is helpful ;-)
Have a look at the SVN book: http://svnbook.red-bean.com/
I'm reading the book right now :-)
What is your current development environment? I would like it a
lot if you could write the software so that it is possible to build with MinGW, then it could be cross-compiled easily and binaries could be generated automatically.
I'm currently using Windows 2003 DDK to create the driver
The DDK is obviously not a development environment, but I guess you're building also the driver with VC++.
Dunno if gcc can build drivers.
I don't know either :-(
and Visual C++ 2003 to create the user mode application. I think
the user mode application may be quite easy to port to MinGW.
If you want to look into MinGW I think that would be awesome. It does not require porting unless you are doing very compiler specific (=bad, IMHO) things in your code.
I'm still evaluating it. But, I think it should be quite easy to do.
-- Darmawan Salihun a.k.a Pinczakko -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
* Peter Stuge stuge-linuxbios@cdy.org [070520 03:12]:
On Sat, May 19, 2007 at 11:09:08AM +0700, Darmawan Salihun wrote:
OK. I'm new to svn. So, this kind of hint is helpful ;-)
Have a look at the SVN book: http://svnbook.red-bean.com/
Also, most important commands can be found either here:
http://www.linuxbios.org/Download_LinuxBIOS
or here:
http://www.linuxbios.org/Development_Guidelines
Stefan
Hi, I'd like to ask about the availability of some features in MinGW because I'm not proficient enough in MinGW in the Windows platform (I barely use it for about 6 months 4 years ago). OK, here's my questions: 1. Is the "platform specific (I'm not sure whether this function is platfomr specific or not)" mmap() function is available in MinGW? 2. Do you think using MinGW in DevCPP IDE is acceptable/good enough compared to using it in it's command line incarnation?
More questions to come :-).
Anyway, this questions has a direct impact on the Winflashrom that I'm currently working on. I'm using MS Visual C++ before, and I can say that I'm proficient enough with it compared to using MinGW. Hopefully, there's proficient MinGW user here that can help.
TIA, Darmawan
* Darmawan Salihun darmawan.salihun@gmail.com [070610 11:45]:
Hi,
- Is the "platform specific (I'm not sure whether this function is
platfomr specific or not)" mmap() function is available in MinGW?
Good question... There is some code in cygwin that emulates it: http://www.koders.com/cpp/fid6DDC4FEBF84310315F4303C64C86EAAEAC1945B0.aspx
- Do you think using MinGW in DevCPP IDE is acceptable/good enough
compared to using it in it's command line incarnation?
What's the DevCPP IDE? ;-)
Stefan
* Stefan Reinauer stepan@coresystems.de [070610 13:49]:
- Darmawan Salihun darmawan.salihun@gmail.com [070610 11:45]:
Hi,
- Is the "platform specific (I'm not sure whether this function is
platfomr specific or not)" mmap() function is available in MinGW?
You could try to use the AWE API (Address Window Extenstion): http://msdn2.microsoft.com/en-us/library/ms810461.aspx http://msdn2.microsoft.com/en-us/library/aa366531.aspx
Several projects have mmap implementations:
libgw32c has one (here from clamav) http://www.koders.com/c/fidBEF73F4272C501403E37D4C34B2288CD3D37B102.aspx
Microsoft's "SFU" might have one (Services for Unix) http://www.microsoft.com/downloads/details.aspx?FamilyID=896C9688-601B-44F1-...
Stefan
On Sun, Jun 10, 2007 at 04:45:36PM +0700, Darmawan Salihun wrote:
- Is the "platform specific (I'm not sure whether this function is
platfomr specific or not)" mmap() function is available in MinGW?
MinGW is not really a platform. You may be confusing it with Cygwin.
MinGW is just a native gcc for Win32 and open source header files for a large part of the Win32 API.
- Do you think using MinGW in DevCPP IDE is acceptable/good enough
compared to using it in it's command line incarnation?
I think you should use whatever you are most comfortable with.
That said, I see many advantages in having as much code as possible buildable with MinGW since that means easy cross-compiles and also dealing with only one compiler.
Finally, I can not imagine that a project will _require_ a particular IDE to build if it is using MinGW and has some good Makefiles.
Anyway, this questions has a direct impact on the Winflashrom that I'm currently working on. I'm using MS Visual C++ before, and I can say that I'm proficient enough with it compared to using MinGW. Hopefully, there's proficient MinGW user here that can help.
Again, I often just think of MinGW as just a native Win32 gcc.
The application should be buildable with MinGW without problems and probably without much special care even if you use an IDE for development.
The kernel driver may not be as easy to build, depending on what kind of linker tricks that are required to make kernel drivers. Also, I'm not sure if the w32api (the open source header project) includes kernel headers as well.
My advice for getting comfortable with MinGW is to just install it. It's only a few megabytes.
You may or may not want MSYS as well. If MinGW is the compiler, MSYS is bash and various other tools and programs that are intended really to make autoconf configure scripts happy about building using MinGW.
If you install MinGW and MSYS then MSYS does some of the work to set up environment variables and so on, but it is by no means required just to run MinGW gcc.
If you want a sample app, look at http://stuge.se/dlg.zip which is just a really basic dialog example that I've prepared for people who want to get started creating dialog RC files using a text editor. (I haven't found any really good RC dialog editor tools.)
//Peter
On 6/10/07, Stefan Reinauer stepan@coresystems.de wrote: ...
- Do you think using MinGW in DevCPP IDE is acceptable/good enough
compared to using it in it's command line incarnation?
What's the DevCPP IDE? ;-)
DevCPP is an Integrated Development Environment for MinGW in Windows. Yeah, more like the GUI for Visual C++ (Visual C++ can be invoked from command line as well; with its cl.execompiler commands ;).
-- Darmawan Salihun a.k.a Pinczakko -------------------------------------------------------------------- -= Human knowledge belongs to the world =-
-
Darmawan Salihun -
MARTIN WOODHOUSE -
Peter Stuge -
Stefan Reinauer