SqueakNOS July 2006

squeaknos@lists.squeakfoundation.org

5 participants
30 discussions

ioRelinquishProcessor, timer, power consumption and IRQs
by Gerardo Richarte 20 Jul '06

20 Jul '06

Hi, since the biggining I thought that it was a good idea to replace all code in ioRelinquishProcessor for a simple hlt assembly instruction. hlt puts the processor in a suspended state until a new IRQ comes in. Using hlt will (hopefully) reduce power consumption... When I did my first tries, SqueakNOS almost died (was incredible slow), and thinking I realized that timer IRQs, by default, come only at 18.2Hz in PCs, and by reading the comment in ioRelinquishProcessor and looking up every uses of it in Squeak I realized that ioRelinquishProcessor must not take longer than the requested time, and it's always called with either 1ms and .5 ms (that's 1KHz and 2KHz). So, as I was doing hlt and only returning at 18.2 Hz, everything was, understandably, slower. At the time I decided I had to increse the timer frequency to at least 2KHz and then hlt would be ok, but until now I haven't done it. Changing the PCs timer frequency is not a big deal, but I was lazzy on touching the native part. I finally did the change a few days ago, but after doing it the internat clock was kind of too fast (2x), now I had the time to take a look, and a stupid bug was making SqueakNOS set a 4KHz+ frequency. Fixed the bug, fixed the time speed difference. Now SqueakNOS runs with a 2KHz time resolution, and does hlt on ioRelinquishProcessor. I thin this is correct, as every external event can only be triggered by IRQs (be it a Delay or a Network packet or mouse move). At the same time, incresing the timer will supposedly put more preasure on the processor, because it has to deal with more IRQs per second, but it's no big deal I think, and improving the timer resolution it's a must IMHO, and the lower power consumption it's a very desirable side effect... oh well... my emails are always long... do you see any drawback in doing this? gera

2 2

SqueakNOS running on 3.9b build 7046
by Johnathon Meichtry 19 Jul '06

19 Jul '06

Coolio - check out the attached! Man I love Squeak/SqueakNOS/Smalltalk etc etc!!!!! I finally got SqueakNOS to work on Squeak 3.9b build 7046. I don't yet have the NIC working and I had to comment out the "Transcript show:'s " in PIC8259>>enableIRQ: before it would give me keyboard and mouse control but finally "Squeak" is working normally and I have full access to it etc. I am still working on the NIC issue and will shortly send out an email with the list of steps I followed to get it to work but I had to send this to the list before I exploded as I've been playing around with this for a week or more and I kept hitting roadblocks. Johnathon

2 4

Release 16-Jul-2006: Basic networking is working!
by Gerardo Richarte 17 Jul '06

17 Jul '06

hi! we just released a new .iso image. We should have released it a few weeks ago, as there are some bug fixes and additions in the native part (for example, FFI is included now), but we delayed it a little bit to be able to release an image that can be pinged over the net :-) download form: http://sourceforge.net/project/showfiles.php?group_id=3891&package_id=3865 The first Networking driver we have is LanceNICDevice, with support for AMD 79C790 cards, as emulated by vmware, what means that the .iso image can be booted in a vmware and pinged :-) We included networking support as implemented mainly by Luciano a while ago, all his work is now available as a Monticello package from http://www.squeaksource.com/Net.html. Although we have only included the Packet and a quick hack to respond to ARP requests and ICMP echo requests, support for most of the protocol in the TCP/IP suit is ready and only has to be plugged into SqueakNOS. We are working on improving the support for this network card, adding new cards (probably RTL8139 is going to be the next), and adding and improving all TCP/IP support. As usual, in this .iso you'll find everything needed to boot and test the system (either directly from the CD in a real box or with vmware), and to rebuild everything. enjoy as much as possible, if you have any questions, as usual, don't hesitate to ask. gera

2 3

We can now send ethernet packets!
by Gerardo Richarte 15 Jul '06

15 Jul '06

What we have today is a very simple (and pour) implementation of the LanceNICDevice, however, I think it's a decent starting point. With what I just send to Squeaksource we can now do things like: "Initializae Networking" LancePCIDevice installOn: Computer current. "easy accesors" netdev := Computer current defaultNetworkInterface. netdev enableInterrupts. tring := netdev initializationBlock transmitRing. "Build EthernetPacket" eth := EthernetPacket new: 1000. eth source: ((ByteArray new: 6) copyFrom: netdev macAddress). eth destination: ((ByteArray new: 6) atAllPut: 255). "Build ARPPacket (ARP Request)" arp := ARPPacket on: eth. eth type: arp class etherType. arp opcodeName: #Request. arp senderHardwareAddress: eth source. arp senderProtocolAddress: (InternetAddress fromString: '192.168.247.128'). arp targetProtocolAddress: (InternetAddress fromString: '192.168.247.1'). "send" tring message: eth asString. This will install and initialize the device, then it will generate a proper ARP request, send it... and get a proper response from a real box :-) this is so exciting!!! I'm happy, and I'm going to sleep now :-) stay tunned, I think we'll have a new release on Sunday, and it'll hopefully be a really good one :-) gera

2 2

Screnshot: SqueakNOS showing received packets
by Gerardo Richarte 14 Jul '06

14 Jul '06

I just added a new Screenshot of SqueakNOS receiving packets using IRC, and showing them in the Transcript. For this we're using NetSqueak (http://www.squeaksource.com/Net.html) https://sourceforge.net/project/screenshots.php?group_id=3891&ssid=37701 You can see the first packets are ARP requests, then and ICMP EchoRequest (ping) and then an incoming TCP SYN request to port 23. Packet sending is not implemented yet, so I had to manually set the mac address using 'arp -s' on the source box. The screenshots are shrinked for some reason, but if you take a close look, you can see #handleIRQOn: and the Transcript nicely showing the Packets with a very nice print string. >From now on you will need to grab NetSqueak from Monticello too in order to properly build SqueakNOS. It's not really necessary yet, but if you want to "Computer current defaultNetworkInterface enableInterrupts", you will either have to modify LanceNICDevice>>handleIRQOn: or bring NetSqueak in. as usual, enjoy as much as you can! :-) gera

1 0

Another aesthetic question
by Gerardo Richarte 13 Jul '06

13 Jul '06

The device I'm working on, as well as other devices, have bits which can be set, cleared and tested. For this we need three different methods (could be two). The question is on how to name them: opt. 1: isOwnedByHost (test) beOwnedByHost (set) beOwnedByCard (clear) opt. 2: ownedByHost (test) etc. opt. 3: isEndOfPacket (test) beEndOfPacket (set) dontBeEndOfPacket (clear) opt. 4: isEndOfPacket (test) endOfPacketSet endOfPacketClear or any mix, or anything else. Right now I have a mixture, like opt1 and opt4. I'm not sure if this is the best thing to do (mix the flavors) or stick to a more strict naming convention and leave the English semantic aside. Remember English is not my native tongue, so I may as well misjudge what's sounds better. Uses of this would be, for example receiveRing isOwnedByHost ifTrue: [queue add: (EthernetPacket bytes: receiveRing message)] transmitRing beEndOfPacket. transmitRing dontBeEndOfPacket or transmitRing endOfPacketSet transmitRing endOfPacketClear thoughts? thanks! gera.

3 2

Question for all
by Gerardo Richarte 13 Jul '06

13 Jul '06

uhm... one of this questions that newbies usually ask, I need your subjectivity. PortHardwareDevices have a basePort. All I/O is indexes through this port, i.e. PortHardwareDeivce>>byteAt: portNumber ^ self primInPortByte: basePort+portNumber (where portNumber should actually by portOffset or something). Anyway, from this implementation we can see that PortHardwareDevices have a 0-based semantic for accessing the ports. This is what common literature uses (register 0, register 1, for example), and what every other software out there uses to (C based or asm based mostly). Now, we all know that indexable objects in Smalltalk have a 1-based semantic. so, the obvious question for the incredulous reader is: should we have 0-based or 1-based semantic for the PortHardwareDevices? 0 based will be "mathematically correct"(?), will be ok according to standard literature and other implementations. 1 based will be Smalltalkish... and I guess we could get used to it (but I'm sure will introduce more bugs when copying from documentation or other code to Smalltalk) so? ah! got you! :-) I don't really want a debate, but some opinions will be nice gera gera

2 1

Re: [SqNOS] Networking is comming to a theater close to you!
by Johnathon Meichtry 12 Jul '06

12 Jul '06

Gera, Your the Squeak Device Driver God!!!! :) Your instructions on the squeaksource page work perfectly and I can initialize the device, see the flag change form 128 -> 3 and also query the buffer with all results being returned by the inspector in decimal. Totally cool!!! I was looking around the buffer and what I find is interesting is that sections 7,8 and 9 in the buffer are all derivatives of the source MAC address. That is: In this example the source MAC address performing ping: 00-50-56-C0-00-08 self buffer unsignedLongAt: 8 => Decimal 1448083711 >> Hex 56 50 00 FF self buffer unsignedLongAt: 7 => Decimal 3226882048 >> Hex C0 56 50 00 self buffer unsignedLongAt: 8 => Decimal 12605008 >> Hex C0 56 50 self buffer unsignedLongAt: 9 => Decimal 134266966 >> Hex 8 00 C0 56 self buffer unsignedLongAt: 10 => Decimal 134742208 >> Hex 80800C0 So you could say all of 9 and three bytes of 8 make up the MAC address but I need to test that with a different PC/MAC to see if each byte positioned in the same place. Johnathon ----- Original Message ----- From: "Gerardo Richarte" <gera(a)corest.com> To: "Johnathon Meichtry" <johnathon-dev(a)meichtry.org> Sent: Tuesday, July 11, 2006 6:30 PM Subject: Re: [SqNOS] Networking is comming to a theater close to you! > btw, I'm on squeak's irc right now (brown.freenode.net #squeak). If it > still doesn't work and you can access irc, we'll fix your problem there > more interactively > > gera >

3 7

Networking is comming to a theater close to you!
by Gerardo Richarte 11 Jul '06

11 Jul '06

hah! after fixing a very (very!) stupid bug, the networking code I wrote on the weekend just worked!!! now, if I do ping from outside vmware to the box inside vmware, a value changes from 128 to 3 (belonging to the card = 128, belonging to the host + first buffer + last buffer). So, we are now officially receiving packets, and if we inspect the packet, we see the source mac address, the destination mac address, and all the byte of the packet! happinesss!! gera

3 7

Memory, ideas?
by Gerardo Richarte 03 Jul '06

03 Jul '06

ok, the time has come. Hardware devices usually need to know some memory addresses, for example, in this case, the network device I'm implementing (AMD Lance, works on vmware) needs to know a pointer to a "configuartion block" which in turns has a pointer to a "receive ring" and a "transmit ring", which have pointers to several receive and transmit buffers. Problem: If we use, lets say, ByteArrays for buffers, and a garbage collect moves the buffer to a different memory position, the hardware may try to incorrectly access it in the old memory address. Ideas (3): . Use some kind of "Object Locking" to mark unmovable objects, so the garbage collector doesn't move our buffers around. Is this possible? How will this affect the performance of the garbage collector? what special care should we have if we do this? . Create a a map of the external memory (including, for example, where the Interrupt Descriptor Table and the Global Descriptor Table are located, what memory is available (mapped), where's the video memory, where in memory is loaded the interpreter (kernel), and where starts the .image). Then create the ExternalMemoryManager class in Squeak and use it to administer this external memory) . Probably the most interesting idea, collaborated by [uhm... shit, forgot your name and can't find your emails, I'll fill this space asap] Create a second ObjectMemory to take care of the biggest block of external memory available. I like this idea, however we either need to be able to lock some objects in this externalObjectMemory, or we seldom (never?) do a garbage collect in it. How do we do this? Craig? :-) What do you think? this is what has me stoped right now. I have all the information needed (and more) to implement simple networking (ethernet) support (for a single NIC now). If too long passes without solving this (1 week), I will implement it anyway, and latter see how we solve this. But we seriously need to solve it. all ideas are more than welcome! thanks! gera

1 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

SqueakNOS July 2006