Thread: [Prex-devel] Problem getting Prex 0.9.0 to work in bochs
Status: Beta
Brought to you by:
kohtani
Menu
▾
▴
prex-devel
|
From: Adam K W. <ak...@gm...> - 2009-10-06 03:04:19
|
I am trying to get Prex 0.9.0 to work in Bochs under fedora 10 64-bit and am having trouble. I have build a gcc cross compiler for i386-elf using gcc 4.4.1 and have used it to successfully compile Prex 0.8.1 (after I fixed the builtin-stdarg-start bug). Prex 0.8.1 ran successfully in Bochs and on real hardware (Pentium laptop) without any problems. I then used my cross compiler to build Prex 0.9.0 and had no compile issues. I ran it successfully on real hardware (again, Pentium laptop) without any problems. However, it does not want to run under Bochs 2.3.7. It prints the Loading Prex line and then moves to a blank screen and never displays a prompt. Bochs displays "SetCR0: GP(0) when attempt to set CR0.NW with CR0.CD cleared !" in the command window. While I have a fair amount of experiance developing applications for embeded systems, I do not have much experience developing operating systems and am wanting to learn using Prex. I am planning on trying to figure out where in the code the OS is "locking up" and will provide more information. Also, any ideas or questions are welcome. Thanks, Adam |
|
From: Kohsuke O. <ko...@us...> - 2009-10-07 12:33:06
|
Adam K Winsor wrote: > It prints the Loading Prex line and then moves to a blank screen and never > displays a prompt. Bochs displays "SetCR0: GP(0) when attempt to set CR0.NW > with CR0.CD cleared !" in the command window. Hi, Please try the attached fix. Thanks. - Kohsuke -- diff -urN prex-0.9.0/bsp/hal/x86/arch/locore.S src/bsp/hal/x86/arch/locore.S --- prex-0.9.0/bsp/hal/x86/arch/locore.S 2009-07-28 03:45:43.000000000 +0900 +++ src/bsp/hal/x86/arch/locore.S 2009-10-07 20:59:42.585840000 +0900 @@ -493,7 +493,7 @@ */ ENTRY(cache_init) movl %cr0, %eax /* Clear cache disable bit */ - andl $~(CR0_CD), %eax + andl $~(CR0_CD|CR0_NW), %eax movl %eax, %cr0 ret |
|
From: <xax...@fo...> - 2009-10-08 09:15:18
|
Hey there, Id read about some TCP/IP implementations (uIP / lwIP). "uIP is different from other TCP/IP stacks in that it requires help from the application when doing retransmission" (from uIP Doc) So I think it's senseless to try this one, caused by the ability to use posix-conform applications. The other one lwIP sounds really good. lwIP's API is simply accessible through a wrapper to BSD-sockets. Only the "select() / poll()" functions aren't supported (don't know how necessary this would be). Hopefully somebody could tell me something about this topic. I need networking support for my project in February next year ^^ Greets Phil |
|
From: Andrew D. <and...@gm...> - 2009-10-08 22:40:13
|
On Thu, Oct 8, 2009 at 8:15 PM, <xax...@fo...> wrote: > Hey there, > Id read about some TCP/IP implementations (uIP / lwIP). > > "uIP is different from other TCP/IP stacks in that it requires help from > the application when doing retransmission" (from uIP Doc) > > So I think it's senseless to try this one, caused by the ability to use > posix-conform applications. > > The other one lwIP sounds really good. lwIP's API is simply accessible > through a wrapper to BSD-sockets. Only the "select() / poll()" functions > aren't supported (don't know how necessary this would be). > > Hopefully somebody could tell me something about this topic. I need > networking support for my project in February next year ^^ Hi Phil, LWIP is ok in the short term if you are in a hurry. I can publish the LWIP "sysarch" we used to use. Unfortunately the LWIP code is a bit of a mess, so this isn't a long term solution. These is a LWIPV6 derivative with IPV6 support but I haven't looked at this as it uses the GPL license which confuses the licensing for commercial products based on Prex. I agree with Ivo and Dmitriy that a different IP stack is the best solution. I would further propose focusing on IPV6 only. It is a much better fit for embedded devices as by design the network configuration is automatic. We moved from LWIP to a small UDP only IPV6 stack that we wrote in house in one man week. This has solved many issues we had with network configuration, performance, etc. Andrew |
|
From: Adam K W. <ak...@gm...> - 2009-10-08 16:03:39
|
Kohsuke, The fix worked. I was able to run Prex in Bochs. I also tested it on hardware and had no problems as well. Thanks, Adam On Wed, Oct 7, 2009 at 7:33 AM, Kohsuke Ohtani < ko...@us...> wrote: > Adam K Winsor wrote: > >> It prints the Loading Prex line and then moves to a blank screen and never >> displays a prompt. Bochs displays "SetCR0: GP(0) when attempt to set >> CR0.NW >> with CR0.CD cleared !" in the command window. >> > > Hi, > > Please try the attached fix. > > Thanks. > - Kohsuke > > -- > diff -urN prex-0.9.0/bsp/hal/x86/arch/locore.S > src/bsp/hal/x86/arch/locore.S > --- prex-0.9.0/bsp/hal/x86/arch/locore.S 2009-07-28 > 03:45:43.000000000 +0900 > +++ src/bsp/hal/x86/arch/locore.S 2009-10-07 20:59:42.585840000 +0900 > @@ -493,7 +493,7 @@ > */ > ENTRY(cache_init) > movl %cr0, %eax /* Clear cache disable bit */ > - andl $~(CR0_CD), %eax > + andl $~(CR0_CD|CR0_NW), %eax > movl %eax, %cr0 > ret > |
|
From: Ivo V. <ivo...@gm...> - 2009-10-08 09:34:56
|
Hello, I propose to work on a full implementation of a networking stack. In the long term i think this is better solution because at some point we would like to have firewall, routing, ipv6, etc, etc, etc I'm ready to actively help in development. /ipv On Thu, Oct 8, 2009 at 12:15 PM, <xax...@fo...> wrote: > Hey there, > Id read about some TCP/IP implementations (uIP / lwIP). > > "uIP is different from other TCP/IP stacks in that it requires help from > the application when doing retransmission" (from uIP Doc) > > So I think it's senseless to try this one, caused by the ability to use > posix-conform applications. > > The other one lwIP sounds really good. lwIP's API is simply accessible > through a wrapper to BSD-sockets. Only the "select() / poll()" functions > aren't supported (don't know how necessary this would be). > > Hopefully somebody could tell me something about this topic. I need > networking support for my project in February next year ^^ > > Greets Phil > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie |
|
From: Dmitriy T. <to...@on...> - 2009-10-08 10:21:28
|
> Hello, > > I propose to work on a full implementation of a networking stack. In > the long term i think this is better solution because at some point we > would like to have firewall, routing, ipv6, etc, etc, etc > > I'm ready to actively help in development. > > /ipv How we can help? May be lets use git for cooperative work? |
|
From: David G. <dg...@co...> - 2009-10-09 03:10:29
|
Andrew Dennison wrote: [...] > I agree with Ivo and Dmitriy that a different IP stack is the best > solution. I would further propose focusing on IPV6 only. It is a much > better fit for embedded devices as by design the network configuration > is automatic. IPv6 has such little penetration that if you do that then the result won't be usable on most networks --- I only know one person, for example, who uses IPv6 at all and that's only as a toy. IPv4 still rules, like it or not. And yeah, IPv6 has built-in automatic network configuration, but IPv4 has DHCP, which while it's a hack, does actually work... (Of course, if the network stack was made an out-of-kernel server with only the ethernet driver being in-kernel for performance, then with careful design it ought to be possible to have multiple drop-in network stacks depending on what you wanted to do. It would need to be planned for in advance, tho Regarding network stacks: has anyone looked at Minix 3's? Minix is a microkernel-based design that should map reasonably-well onto Prex. Plus, the licensing is compatible. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "They laughed at Newton. They laughed at Einstein. Of course, they │ also laughed at Bozo the Clown." --- Carl Sagan |
|
From: David G. <dg...@co...> - 2009-10-09 03:19:18
|
David Given wrote: [...] > stacks depending on what you wanted to do. It would need to be planned > for in advance, tho > Regarding network stacks: has anyone looked at Minix 3's? Minix is a Stupid Thunderbird crashed while sending my message and I accidentally sent out a partial draft. There should obviously be a "ugh.)\n" in there. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "They laughed at Newton. They laughed at Einstein. Of course, they │ also laughed at Bozo the Clown." --- Carl Sagan |
|
From: Andrew D. <and...@gm...> - 2009-10-09 05:12:50
|
On Fri, Oct 9, 2009 at 2:10 PM, David Given <dg...@co...> wrote: > Andrew Dennison wrote: > [...] >> I agree with Ivo and Dmitriy that a different IP stack is the best >> solution. I would further propose focusing on IPV6 only. It is a much >> better fit for embedded devices as by design the network configuration >> is automatic. > > IPv6 has such little penetration that if you do that then the result > won't be usable on most networks --- I only know one person, for > example, who uses IPv6 at all and that's only as a toy. IPv4 still > rules, like it or not. And yeah, IPv6 has built-in automatic network > configuration, but IPv4 has DHCP, which while it's a hack, does actually > work... Yeah - it depends on your application. I tend to think in terms of link-local products when I'm working in the embedded space - and working both with and without infrastructure such as DHCP. If you only care about link local then using IPV6 (and mDNS) is fantastic for embedded devices that communicate with Linux, XP, Vista, etc. I agree that for more general use IPV4 still lives on. IPV6 will slowly take over without anyone realising - I think a lot of the backend infrastructure for wireless gadgets (smartphones, etc) is probably already IPV6. Andrew |
|
From: Ivo V. <ivo...@gm...> - 2009-10-09 08:30:32
|
Hello, Back to the subject at hand I have the following concerns: Using IPv6 only is bad idea. It will limit the user base severely. Transitioning is slow. However we can use different stacks (as in different processes) for IPv4 and IPv6. If you want IPv4- or IPv6-only start only the appropriate processes. Minix 3 network stack may be with compatible licence but i do not recommend using it. It is vastly outdated, parts of it even broken, not to mention the performance issues. I am not driver programmer myself but i will be happy to start working on network stack if someone can provide at least minimal working driver for a 'classic' NIC that some virtual machine/emulator supports :) Since PREX is microkernel OS there is another concern too: How will the network stack be divided ? What separate process will be there ? Is it ok to provide external 'routing' process (for ARP, IPv4, IPv6, policy routing, etc) ? How we gonna deal with multiple routing tables ? Will the firewall be separate process as well ? For example QNX uses modified NetBSD 1.6 network stack and it is a single process. I don't think this is a good idea. With correct design even performance should not be a problem ... /ipv On Fri, Oct 9, 2009 at 8:12 AM, Andrew Dennison <and...@gm...> wrote: > On Fri, Oct 9, 2009 at 2:10 PM, David Given <dg...@co...> wrote: >> Andrew Dennison wrote: >> [...] >>> I agree with Ivo and Dmitriy that a different IP stack is the best >>> solution. I would further propose focusing on IPV6 only. It is a much >>> better fit for embedded devices as by design the network configuration >>> is automatic. >> >> IPv6 has such little penetration that if you do that then the result >> won't be usable on most networks --- I only know one person, for >> example, who uses IPv6 at all and that's only as a toy. IPv4 still >> rules, like it or not. And yeah, IPv6 has built-in automatic network >> configuration, but IPv4 has DHCP, which while it's a hack, does actually >> work... > > Yeah - it depends on your application. I tend to think in terms of > link-local products when I'm working in the embedded space - and > working both with and without infrastructure such as DHCP. > > If you only care about link local then using IPV6 (and mDNS) is > fantastic for embedded devices that communicate with Linux, XP, Vista, > etc. > > I agree that for more general use IPV4 still lives on. IPV6 will > slowly take over without anyone realising - I think a lot of the > backend infrastructure for wireless gadgets (smartphones, etc) is > probably already IPV6. > > Andrew > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie |
|
From: Dmitriy T. <to...@on...> - 2009-10-09 10:43:11
|
> I am not driver programmer myself but i will be happy to start working > on network stack if someone can provide at least minimal working > driver for a 'classic' NIC that some virtual machine/emulator supports > :) > > Since PREX is microkernel OS there is another concern too: How will > the network stack be divided ? What separate process will be there ? > Is it ok to provide external 'routing' process (for ARP, IPv4, IPv6, > policy routing, etc) ? How we gonna deal with multiple routing tables > ? Will the firewall be separate process as well ? For example QNX uses > modified NetBSD 1.6 network stack and it is a single process. I don't > think this is a good idea. With correct design even performance should > not be a problem ... May be something like split networking in levels with netserver as a manager. NetManager - Prex server Transport layer (TCPServ,UDPServ) Network layer (IP, ICMP, IPX) Link layer (Ethernet, ARP, PPP) Phys layer (drivers) Transport and network level is a one process, link and phys is another. Every process have API to communicate each other and prev\next level and internal "plugins". NetManager work at application level. It gets message for network, and send it to protocol level. Protocol server decides what protocol it will use and send message to "plugin" TCP. TCP returns it after some work, protocol server send result to IP "plugin", and then to next level. So complicated... :) |
|
From: Dmitriy T. <to...@on...> - 2009-10-09 11:11:17
|
Update. Looks like this kind of split be better. NetManager - Prex server Transport layer (TCPServ,UDPServ) Network layer (IP, ICMP, IPX) Link layer (Ethernet, ARP, PPP) Phys layer (drivers) |
|
From: Ivo V. <ivo...@gm...> - 2009-10-09 12:18:02
|
... every one of those should call the firewall/routing code somehow :) To be able to imagine the overwall picture I include an ugly drawing of the whole sub-system the way I see it. Common borders represent communication endpoints. /ipv On Fri, Oct 9, 2009 at 1:56 PM, Dmitriy Tochansky <to...@on...> wrote: > Update. Looks like this kind of split be better. > > NetManager - Prex server > > Transport layer (TCPServ,UDPServ) > > Network layer (IP, ICMP, IPX) > Link layer (Ethernet, ARP, PPP) > > Phys layer (drivers) > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Prex-devel mailing list > Pre...@li... > https://lists.sourceforge.net/lists/listinfo/prex-devel > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie |
|
From: Ivo V. <ivo...@gm...> - 2009-10-09 12:19:26
|
... and the actual attachment :) On Fri, Oct 9, 2009 at 3:11 PM, Ivo Vachkov <ivo...@gm...> wrote: > ... every one of those should call the firewall/routing code somehow :) > > To be able to imagine the overwall picture I include an ugly drawing > of the whole sub-system the way I see it. Common borders represent > communication endpoints. > > /ipv > > On Fri, Oct 9, 2009 at 1:56 PM, Dmitriy Tochansky <to...@on...> wrote: >> Update. Looks like this kind of split be better. >> >> NetManager - Prex server >> >> Transport layer (TCPServ,UDPServ) >> >> Network layer (IP, ICMP, IPX) >> Link layer (Ethernet, ARP, PPP) >> >> Phys layer (drivers) >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Prex-devel mailing list >> Pre...@li... >> https://lists.sourceforge.net/lists/listinfo/prex-devel >> > > > > -- > "UNIX is basically a simple operating system, but you have to be a > genius to understand the simplicity." Dennis Ritchie > -- "UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity." Dennis Ritchie |
|
From: Dmitriy T. <to...@on...> - 2009-10-09 12:38:42
|
> ... and the actual attachment :) Not sure that routing and filtering is useful at transport level. And second question is how we split it on several processes. Socket level is network server, I guess. It get messages from applications and what next? May be you can paint something like diagram like app -> socket server -> TCP -> filter -> IP -> filter -> hardware? PS We have IRC at freenode #prex. :) |
|
From: Konrad E. <ko...@ga...> - 2009-10-14 14:14:03
|
I would not underestimate the difficulty in implementing a new ipstack. I'd say it is a oder of magnitude more difficult and time consuming than implementing the kernel itself. -- Konrad Ivo Vachkov wrote: > ... every one of those should call the firewall/routing code somehow :) > > To be able to imagine the overwall picture I include an ugly drawing > of the whole sub-system the way I see it. Common borders represent > communication endpoints. > > /ipv > > On Fri, Oct 9, 2009 at 1:56 PM, Dmitriy Tochansky <to...@on...> wrote: >> Update. Looks like this kind of split be better. >> >> NetManager - Prex server >> >> Transport layer (TCPServ,UDPServ) >> >> Network layer (IP, ICMP, IPX) >> Link layer (Ethernet, ARP, PPP) >> >> Phys layer (drivers) >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9 - 12, 2009. Register now! >> http://p.sf.net/sfu/devconference >> _______________________________________________ >> Prex-devel mailing list >> Pre...@li... >> https://lists.sourceforge.net/lists/listinfo/prex-devel >> > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X