Michal's bloggy

I'm moving

2011-02-07T20:20:00.003+01:00

Hello folks!

The last post on this blog is almost one year ago, that feels like eons! Well, as the time passed I lost motivation to post here.

Now I'm going to quit posting here entirely. After a backup of this site I will remove it from blogspot. But no worry, I will not quit blogging at all. Instead, I'm moving to my new site:

http://meehow.de/

and I hope to keep this one more up to date :)

Update, again

2010-03-14T23:35:00.005+01:00

Hello folks,

Today a short report only. Markus Weiss was working intensively on getting OWB to compile and work on PPC targets. Of course, he succeeded! Thank you, Markus.

In my last post I've told you about some issues with setjmp/longjmp. The unaligned FPU double access, which crossed 16-byte boundary generates an alignment exception on PowerPC machines. My first fix was rather stupid one - alignment enforcement in setjmp and longjmp calls. Now, I wrote a special exception handler which takes care of misaligned data. It helped Markus a bit and make OWB work on Sam440EP.

Thanks to Markus work and his great fixes to the code, DHCP client does not enter an endless loop on Sam440 anymore. Now, setting network up on Samantha is a matter of few mouse clicks.

Stay tuned for more news. New ISO is on the way (I may tell you that its size increased again. Now it has 475 MB approximately).

PS. This blog entry was written on AROS running on Sam440EP in OWB browser :)

Any news?

2010-03-09T19:39:00.004+01:00

Hello there.

Yup, typical me :) I made some fuzz about things being currently done (or not done) and then disappeared for a while. No information, no updates. Nothing :)I've been asked several times about the status update of AROS for sam440. Well, there are few changes which have happened to the whole AROS recently. We do have a changeable mouse pointers and they do work on Sam440. Since there are few of them delivered on the ISO, you may change the red triangle to something more Amiga-like, if you want to. A red mouse pointer with alpha blending and shadow? No problem. Start preferences, select the correct image and voilà!

Markus Weiss managed to compile OWB for PPC target and, if it works as expected, you will find it on the next ISO. Neil Cafferkey made some important improvements to the installer. Now, it installation on sam440 shall be simpler. Keep in mind the installation will be incomplete, since the AROS' slb (aka Parthenope) is not installed yet.

The changes local to Sam440 port include support for the onboard I²C bus. The RTC is used by the battclock.resource, so now you will see the correct time on AROS, provided your RTC is correctly set up. If not, you may use AROS' time preferences to adjust it. Additionally, few fixes for the setjmp/longjmp are made, so that the functions do not crash in case of unaligned jmp_buf pointer. Anything else? Ah yes, I'm working on the EHCI Poseidon driver for Sam440 AROS. Stay tuned :)

Screenshot? Here you have it. Nothing special in it. Just AROS on Sam440 in a bit higher resolution :)
Greetings from the German Aerospace Center :)

Oh, Samantha!

2010-01-31T22:52:00.004+01:00

Hi there!

Samantha is back! After long period of hibernation in the AROS repository Sam440 port of AROS is maintained again. Big thanks to Markus Weiss, who has restarted it and to ACube who gave me the kick in the butt :)

Since the kernel.resource in AROS did evolved a bit since last time I was writing it form Sam, it has been updated a tiny bit now. Most of the features from Efika's kernel have been back-ported to Sam440 port, including:

Loading and releasing of symbols from every ELF file loaded by AROS, including the kernel itself,
System call for cold reboot (accessible only from kernel.resource and exec.library),
Crash handler displays detailed information, including the byte offset of crash occurrence, relevant symbol name (if such name exists at all) and the executable name. The log includes also the backtrace (with offsets, symbol and module names) which tries to reach as far as possible.

Yes, I do know, it's not much. But it is at least a good start (eerm.... rather a good re-birth?) :).

The Sam440 port has been not only extended, but also fixed a bit. I have found there an ancient bug in the exception handler. It could have lead to random system crashes. The reason was the exception handler itself. There was a risk that an interrupt will occur during reconstruction of the CPU context.

Since the AMCC440EP CPU does not maintain cache coherency (no, it's not a bug, it's a feature fairly well documented in the manuals!), some portions of the code had to be fixed. Now, more AROS code uses CachePreDMA and CachePostDMA pair of functions. Because of that partitions on harddrive are recognised properly now. AROS on Sam440 boots nicely and coexists with OS4.1 on the same harddrive. Nice, isn't it?

Now, the last but not least, after some sleepless nights the OHCI driver of Poseidon is fixed and operates properly on Sam440ep. Wanna proof? Watch the attached screenshot :)

Stay tuned for more news. I promise to write a bit more now ;)

New (small) build

2009-03-08T21:47:00.003+01:00

Howdy.

After a long break I present you herewith a new test iso for Efika. It's much much smaller than all previous images, because I have not included the "contrib" build. The reason was instability of some third party MUI classes which either crashed the Zune preferences or did not allowed the prefs program to start.

The most important changes worth mentioning are USB fix, sync with current source tree and extended debug. The first fix repairs an anciend bug in OHCI driver, where the USB ports were powered up upon driver's initialization. It lead to some "zombie" devices on the bus. The Efika source tree has been synced with the SVN repository too, therefore Efika build got all recent changes and updates from the main tree. The most important and Efika specific is extended debug. Until now, if anything on native aros crashed, I have had no clear information about the code that failed. Just some address in memory. Debugging under such conditions was so ineffective, that I've finally decided to improve the crash log a bit.

Now, every single module in the system registers itself at the kernel.resource with name and headers of ELF file. Kernel resource scans the file and remembers all symbols referring executable sections. The same is done with Kernel during the bootup too. Now, if a crash occurs, I become much more verbose information, which eventually helps :) The information includes the location of crash (which byte offset, which function, which module) and the call backtrace up to the birth of the task/process. Have a look at NList crash:

[KRN] Exception 3 (DSI) handler. Context @ 0xff7fb948, SysBase @ 0x32c0, KernelBase @ 0x4bac
[KRN] Process 0xcae00 (Zune)
[KRN] Crash at byte 8 in func strcmp, module muimaster.library
[KRN] SRR0=00ed4428, SRR1=0000f030
[KRN] CTR=ff8066e4 LR=00e94270 XER=00000000 CCR=28004044
[KRN] DAR=00000013 DSISR=40000000
[KRN] HASH1=07000000 HASH2=070fffc0 IMISS=00ed4420 DMISS=00000013
ICMP=80000003 DCMP=80000000
[KRN] SPRG0=ff7fbaf0 SPRG1=00da9598 SPRG2=28004044 SPRG3=00000000
SPRG4=00004bac SPRG5=000032c0
[KRN] GPR00=00e80980 GPR01=002c9950 GPR02=00000000 GPR03=00da9598
[KRN] GPR04=00000013 GPR05=00da50c0 GPR06=002c99b8 GPR07=00da9598
[KRN] GPR08=012ecc00 GPR09=0000004e GPR10=00000120 GPR11=00da50c0
[KRN] GPR12=48004022 GPR13=00000000 GPR14=00000000 GPR15=000d0000
[KRN] GPR16=00f5fed0 GPR17=00000001 GPR18=00f60000 GPR19=011cf4bc
[KRN] GPR20=00000002 GPR21=00000000 GPR22=00000000 GPR23=00f60000
[KRN] GPR24=00db0000 GPR25=00da5120 GPR26=00000000 GPR27=8042ac64
[KRN] GPR28=00da50c0 GPR29=00f19cd0 GPR30=00000013 GPR31=00d87620
[KRN] Hash1 dump:
[KRN] 80000010.04000012 800007a0.f800f03a 80000400.8000803a
80000410.8400803a
[KRN] 80000420.8800803a 00000000.00000000 00000000.00000000
00000000.00000000
[KRN] Hash2 dump:
[KRN] 8000000f.03fff012 800007bf.07ff0010 8000040f.83ff703a
8000041f.87ff703a
[KRN] 00000000.00000000 00000000.00000000 00000000.00000000
00000000.00000000
[KRN] Instruction dump:
[KRN] 00ed4428: 88040000
[KRN] 00ed442c: 7c604851
[KRN] 00ed4430: 4c820020
[KRN] 00ed4434: 2f890000
[KRN] 00ed4438: 4d9e0020
[KRN] 00ed443c: 39000000
[KRN] 00ed4440: 7d674214
[KRN] 00ed4444: 7d444214
[KRN] Backtrace:
[KRN] 00e80980: byte 40 in func MUIMaster_MUI_GetClass, module
muimaster.library
[KRN] 00e82070: byte 56 in func MUIMaster_MUI_NewObjectA, module
muimaster.library
[KRN] 011049d0: byte 176 in func MUI_NewObject, module NList.mcc
[KRN] 010d9a50: byte 632 in func mNL_New, module NList.mcc
[KRN] 010db7e0: byte 880 in func _Dispatcher, module NList.mcc
[KRN] 00e941cc: byte 28 in func metaDispatcher, module muimaster.library
[KRN] 010d35c0: byte 48 in func DoSuperMethodA, module Mailtext.mcc
[KRN] 010d291c: byte 80 in func Mailtext__OM_NEW, module Mailtext.mcc
[KRN] 010ceac0: byte 204 in func Mailtext_Dispatcher, module Mailtext.mcc
[KRN] 00e941cc: byte 28 in func metaDispatcher, module muimaster.library
[KRN] ff8af35c: byte 40 in func CoerceMethodA, module intuition.library
[KRN] ff8842dc: byte 164 in func Intuition_NewObjectA, module intuition.library
[KRN] 00e82098: byte 96 in func MUIMaster_MUI_NewObjectA, module
muimaster.library
[KRN] 0110b27c: byte 176 in func MUI_NewObject, module Mailtext.mcp
[KRN] 01108088: byte 952 in func MailtextP__OM_NEW, module Mailtext.mcp
[KRN] 01105b68: byte 180 in func MailtextP_Dispatcher, module Mailtext.mcp
[KRN] 00e941cc: byte 28 in func metaDispatcher, module muimaster.library
[KRN] ff8af35c: byte 40 in func CoerceMethodA, module intuition.library
[KRN] ff8842dc: byte 164 in func Intuition_NewObjectA, module
intuition.library
[KRN] 00e01110: byte 2476 in func init_gui, module Zune
[KRN] 00e016f8: byte 276 in func main, module Zune
[KRN] 00dffcb4: byte 452 in module Zune
[KRN] ff8c2a38: byte 36 in func DosEntry, module dos.library
[KRN] ff8c5274: byte 13092 in module dos.library
[KRN] **UNHANDLED EXCEPTION** stopping here...

The next release will get rid of the "stopping here..." message. Instead of halting whole aros, the failing task will be moved away, a popup message will appear, and AROS will continute to work. Stay tuned...

One tiny fix...

2009-02-10T12:01:00.004+01:00

... and suddenly everything goes better :-)

as you may remember, I have released a test pre-alpha iso with AROS for Efika recently. However, there were some issues with using it. Some people tried to boot it from DVD-USB devices, some tried USB Flash Keys. The former succeeded mostly (but not always) whereas the latter failed pathetically. I was scratching my head and found no sane solution. Once, being completely desperate, I have enabled full debug of OHCI driver, in order to see every single transfer description used by all USB devices in the system. There was it! In some cases, OHCI chip was instructed to read 512 bytes starting from physical address 0xffffffff. That cannot be and it couldn't work. At that point the reason of OHCI hanging was known. But why was it like this???

Well, the answer surprised me a bit. The issue was the sign extension during APTR to uint64_t cast. At some moment, AROS wanted to read from all bootable devices the first sector into it's local table in .bss section. Since that piece of code belongs to kernel, the virtual address of this portion of memory was somewhere around 0xff7f0000. Sign extended address, 0xffffffffff7f0000 was of course not found in the MMU hash table and the KrnVirtualToPhysical() call failed. Sign expansion fixed, et voilà! All the issues with mass storage are gone.

For those who do not own an Efika, a tiny screenshot:

here, you can see the PCI Tool (doesn't show much because the most of Efika devices are on MPC5200B SoC), the screenshot tool itself, About AROS window with the mysterious "chrp-ppc Build efika", and shell. I wanted to show you there, where the SYS: assign is pointing to. The volume labeled AROS: is a boot device named UH0. This is the USB flash key. The USB1: device is my DVD drive connected throughout USB bus.

The torrent file is here, if anyone of you is willing to test it. Keep in mind I have toyed with scheduler there. If it does not work smooth for you, let me know. If it works well, let me know too. If the iso fails on your machine, do not hesitate writing me about (in such case try to provide the debug log, if you can).

PS. If the boot starts before the USB key is enumerated, it will not be bootable for AROS. It sucks, but that's the way AROS boots (some people are considering few changes there). In such case, you may add a command line option, eg. bootdelay=5 will introduce additional delay of 5 seconds right before booting. The iso has a bootdelay of 3 seconds by default, because all my USB devices attached to efika (keyboard, mouse, flash key and DVD) are sitting on a hub.

New efika iso

2009-01-30T00:55:00.003+01:00

The last ISO you got was a bit annoying. There were almost forty modules to load by OF. It took long. Moreover, putting these files on FAT-formatted USB stick failed, since OF was unable to find some of the files.

I made few changes to the bootstrap code and AROS itself. AROS sets up interrupts in proper way. It should not lock anymore, as it happened before. The USB mass storage has been fixed a bit and should work a bit better now. Regarding the bootstrap code, following changes have been made:

os_image does not need the boot-device setting anymore. Boot it from any place and it will work as expected.
os_image honors the command line argument passed from OF. Now, if both menu.lst and OF command line contain parameters for kernel, they will be joined together.
os_image supports packages. No need to load 40 boot files through OF anymore. There will be few packages: generic-ppc, efika, usb and few other files to load. It means faster boot time and less risk of OF issues ;)
os_image does not support timeout option anymore. If there are more kernel configurations, it will stop and wait for an input.

Although timeout is gone, os_image on this cd will boot aros without waiting. I have removed the second boot option, which was not used anymore. How to boot? Put the CD into drive and type:

boot cd os_image

whereas "cd" corresponds to the boot device you use. You may find this iso here.

Updates, updates

2009-01-26T10:44:00.004+01:00

OMG, it was a busy weekend... :)

Last 48 hours were quite intensive. The source tree of Efika5k2 branch has been updated - the tree was almost 4 months old! I have added a complete contrib directory to the build - the iso is now 150 MB large and contains a complete gcc compiler toolchain for Efika as well as some other goodies.

The kernel.resource got new function, which may be used to change the WMID bits of certain pages of memory. One may use it, for example, to disable caching in some RAM areas. This feature is used by the PCI driver class for efika. Every region allocated for use by PCI bus master devices is excluded from caching. This manouver may simplify driver's code significantly. For example, the OHCI driver uses Endpoint Descriptors (ED) and Transfer Descriptors (TD) which may be used by both CPU and OHCI controller. With an incoherent cache enabled, the driver has to either flush or invalidate the cached copies of descriptors permanently. Here, uncached region for these descriptors permits a more simple and error-safer code.

I have changed the scheduler a bit. The old one was not so stable upon very small CPU loads. It's tendency was to lock interrupts and put CPU into sleep mode. Very unfortunate, I must say ;) The updated code introduces the Idle Task which enters the power saving mode in a safer way. The scheduler calculates the time which CPU spent during execution of very task. Have a look yourself at C:TaskList command to understand what I mean :)

Wait, Did I wrote "have a look yourself"? Yes! Download this torrent, and test the AROS for efika yourself. It is not complete yet. You will surely see it crashing. The both IDE and network drivers are missnig. The release is unstable. Just put the ISO on CD, put it into your USB-CD or USB-DVD drive and start efika. Then, type following commands in the OF prompt:

setenv boot-device cd
boot cd os_image

Once you see the Boot? > prompt, press 1 and be patient. The OF needs some time to read all aros' modules and will put enourmous amount of debug info. It will even report some missing file. Once AROS starts up, you will see the mouse pointer on the screen and CD drive working. Have fun. The serial port outputs debug information at 115200bps, 8N1.

PS. My upstream is limited. Please seed the file after download.

Coincidence, or MassStorage contd.

2009-01-20T23:44:00.006+01:00

Every modern USB presents itself as a SCSI conforming bulk-only mass storage device to the system. Therefore, in order to do any IO operations, I have had to do them in the old good SCSI style. Therefore, the mass storage class do contain a DirectSCSI method and exposes it to rest of the world.

What a coincidence! I have added a few-lines long implementation of HD_SCSICMD to the .device layer of mass storage. I have started AROS in QEMU and forwarded the USB->PATA converter with a DVD attached to it and AROS CD inside (I didn't want to test anything special, but it was the first CD I saw on the desktop). AROS booted and stopped. Then, the timeout errors appeared. A lot of them. A bit disappointed I've left my desk and did something else. Suddenly, the CD started to spin and AROS booted from USB CD device! Great!

A short investigation showed, that the CD filesystem used in AROS performs the INQUIRY SCSI command with a fixed size, whereas the USB protocol provides a much shorter data in return, which leads to a timeout. Then, it tries to get the full-sized TOC and such. Anyway, AROS team will either need to fix CD filesystem a bit, or I will have to give up 10 second timeouts in mass storage and introduce four pipes there: two of them with very short timeout (100 miliseconds or so) and two with the 10 second timeout.

So, now the mass storage can not only access any USB sticks and USB harddrives, but also USB CD/DVD readers and burners. Nice, isn't it? :) The next step: booting Efika CD directly :)

Back to Efika

2009-01-19T07:31:00.002+01:00

Good Day Everyone!

After my last fights with the USB Mass Storage bounty I have decided to take a break there and continue with AROS port for Efika. The Mass Storage is basically ready, at least in my eyes, since I do lack the hardware where the whole USB stack makes any issues at all. It works here with two PC's I own and with two virtual machines: QEMU and VmWare Player.

Anyway, I'm back with Efika right now. I took my freshly written mass storage class, fixed the OHCI driver again (it uses the physical address provided by the CachePreDMA() call) and copied the whole Efika CD onto my SFS partition of USB stick. And guess what! I have the wanderer desktop on Efika in front of my eyes now! Horray! Screenshot will follow as soon as I organise a USB hub (two USB slots are not enough for mouse, keyboard and USB stick, you know :)

One note: as you may know from the lecture of my previous posts, both FAT and FFS filesystems lack proper caching and thus are relatively slow, especially on Efika. Attempting to boot from FFS partition on USB stick may take more than 10 minutes. Booting from FAT will not work, because this filesystem is still incomplete. As for SFS, Efika needed one minute to boot from it, approximately.

PS. Since the SFS filesystem for linux is not working well on my machine (it crashes the linux kernel during mount already), I have started VMWare with AROS and Efika cd's attached. Then I have plugged my usb stick, attached it to vmware and copied all the Efika ISO contents to the stick. Just as a proof that all the things are working here as expected.

Almost there :)

2009-01-10T21:40:00.003+01:00

This week was a very active one. I was working on my mass storage class all the time and got some really impressive results. The bounty is almost ready, at the moment I'm testing the class and the USB stack as a whole too. I have tested the mass storage class on my two USB sticks and a 4-in-1 USB card reader. All of them seems to work properly. In my private test phase were incorporated three different machines:

my dying laptop (either gfx chip or it's VRAM attempts to die pathetically - a chance of successful boot into X11 or Windows oscillates around 5%) used for development
x86_64 box with 32 bit native aros to do some heavy testing
my wifes PC which was the very first computer in the world booting AROS from USB stick ;)

Additionally, a qemu with USB forwarding has been used for immediate tests (in this case, the qemu takes a whole device of my wish over). In all this cases the USB stack and mass storage class seem to work properly. The mass storage is also being tested by other people, whom I'm very thankful :)

Once the eventual bugs are ironed out the bounty, according to it's description, will be completed.

Note about the speed: AROS' USB stack has at the moment the OHCI and UHCI drivers. It means, only the USB1.1 speed may be expected. The closest to the maximal transfer rate is, with 1.4MB/s, the SmartFilesystem. Both fat and ffs filesystems are dramatically slow, achieving 160KB/s and 140KB/s, respectively. Keep this information in minde while toying with AROS :)

USB Mass Storage - status update

2009-01-04T11:29:00.004+01:00

Mass storage class for AROS' USB stack is almost ready now. I have completed the exec-device interface and fixed few most annoying bugs. The class should support all devices supporting bulk-only protocol (that is, almost everything), including all USB card readers. USB DVD drives might work too, but I do not have the hardware to test.

Using the mass storage class, I have formatted a small SFS partition on my USB stick. It worked. I've tried to copy my whole AROS CD there. It worked again. Reading from the very same partition works. FAT partition from the very same stick worked too, both in read and write mode. The screenshot I've made for you was stored on FAT partition of USB stick :-) Welcome new and easier way to transfer data to and from AROS :)

During next few days I will clean the code a bit and commit it to AROS' repository. Apart from that I will fix the USB stack and AROS a bit in order to make booting from USB key feasible. Then, the USB Mass Storage bounty will be completed.

Remember me?

2008-12-11T23:26:00.003+01:00

Last few weeks I satvery far away from all my computers. The reason, you ask? We have changed our flat against a bigger one, so that all of us have more room for work, amusement and a living. Moving affects thousands of resources, costs money and affects health. I bet I have more gray hair now than a month ago ;)

I have applied for the mass storage bouty recently and I have been working on it again during last few days. This USB class adds an exec-style device to the system, named usbmss.device. It allows programs and filesystems not aware of AROS' USB stack to talk with the MSS class devices attached to the computer. Currently, it's able to forward many exec-style commands to and from the USB device. It does not report medium change and lies about media type (it says that evertything is of type DG_DIRECT_ACCESS). Once this issues will be addressed, the device interface will be completed. Then, the USB Mass Storage will call expansion's AddBootNode function and I will hopefully boot AROS from USB stick.

Then, the bounty might be considered complete. ;)

PS. On the screenshot below, the freshly created FAT32 partition on virtual MSS device on QEmu.

Evolution?

2008-11-08T19:57:00.003+01:00

Do you believe in evolution of an operating system? Can a system get all the nice features thanks to it? Can it stay backwards compatible?

What do you think? What would be your preference?

USB Mass Storage

2008-10-27T08:00:00.007+01:00

Moin.

Since I have signed for the USB Mass Storage bounty, I started to toy with the USB manuals, AROS' USB stack and Efika. During my coding evening it suddenly turned out, that I've lost the bits and pieces of AROS USB code which were responsible for Bulk transfers. Funny. They were there a very long time ago, among my sources, now they were gone.

Whatever. I've added the bulk transfer support to USB stack implemented it in both OHCI and UHCI driver ~~(the support for UHCI will follow shortly)~~ and wrote the first bits and pieces of mass storage class. Here's the result:

[USB] USB::NewDevice()
[USB] Trying external class "hid.hidd"
[USB] Trying external class "storage.hidd"
[MSS] MatchCLID(0x8ed55, 0x89d74)
[MSS] UDCLASS_IN_INTERFACE OK. Checking interface 0
[MSS] iface 0 @ 0x89d7d class 8 subclass 6 protocol 80
[MSS] Interface may be handled by Mass Storage Class
[MSS] Lucky you. The device supports Bulk Only transport
[MSS] Protocol used: SCSI complete
[MSS] Pick me! Pick me! Pick me! I can handle it!
[USB] clid = 0xff93ede4
[MSS] Storage::New()
[USB] USBDevice::New()
[USBDevice::New] Device 0165:1307 00/00/00 at address 0008c314:02
[USBDevice::New] Default LangID=0904
[USBDevice::New] iProduct = "USB Flash Disk"
[USBDevice::New] iManufacturer = "General"
[USBDevice::New] iSerial = "4b25950686c791"
[MSS] GetMaxLUN returns 0
[MSS] Interface is supposed to have 3 endpoints
[MSS] OUT endpoint found
[MSS] IN endpoint found
[MSS] DirectSCSI -> (43425355,00000001,00000008,00,80,0a)
[MSS] DirectSCSI <- (53425355,00000001,00000000,00)
[MSS] Detected capacity: 964MB
[MSS] DirectSCSI -> (43425355,00000002,00000400,00,80,0a)
[MSS] DirectSCSI <- (53425355,00000002,00000000,00)
[MSS] 0000: eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 20 01 00 .<.MSDOS5.0.. ..
[MSS] 0010: 02 00 02 00 00 f8 f1 00 3f 00 ff 00 00 00 00 00 ........?.......
[MSS] 0020: 00 20 1e 00 00 00 29 b6 3b 10 80 4e 4f 20 4e 41 . ....).;..NO NA
[MSS] 0030: 4d 45 20 20 20 20 46 41 54 31 36 20 20 20 33 c9 ME FAT16 3.
[MSS] 0040: 8e d1 bc f0 7b 8e d9 b8 00 20 8e c0 fc bd 00 7c ....{.... .....|
[MSS] 0050: 38 4e 24 7d 24 8b c1 99 e8 3c 01 72 1c 83 eb 3a 8N$}$....<.r...:
[MSS] 0060: 66 a1 1c 7c 26 66 3b 07 26 8a 57 fc 75 06 80 ca f..|&f;.&.W.u...
[MSS] 0070: 02 88 56 02 80 c3 10 73 eb 33 c9 8a 46 10 98 f7 ..V....s.3..F...
[MSS] 0080: 66 16 03 46 1c 13 56 1e 03 46 0e 13 d1 8b 76 11 f..F..V..F....v.
[MSS] 0090: 60 89 46 fc 89 56 fe b8 20 00 f7 e6 8b 5e 0b 03 `.F..V.. ....^..
[MSS] 00a0: c3 48 f7 f3 01 46 fc 11 4e fe 61 bf 00 00 e8 e6 .H...F..N.a.....
[MSS] 00b0: 00 72 39 26 38 2d 74 17 60 b1 0b be a1 7d f3 a6 .r9&8-t.`....}..
[MSS] 00c0: 61 74 32 4e 74 09 83 c7 20 3b fb 72 e6 eb dc a0 at2Nt... ;.r....
[MSS] 00d0: fb 7d b4 7d 8b f0 ac 98 40 74 0c 48 74 13 b4 0e .}.}....@t.Ht...
[MSS] 00e0: bb 07 00 cd 10 eb ef a0 fd 7d eb e6 a0 fc 7d eb .........}....}.
[MSS] 00f0: e1 cd 16 cd 19 26 8b 55 1a 52 b0 01 bb 00 00 e8 .....&.U.R......
[MSS] 0100: 3b 00 72 e8 5b 8a 56 24 be 0b 7c 8b fc c7 46 f0 ;.r.[.V$..|...F.
[MSS] 0110: 3d 7d c7 46 f4 29 7d 8c d9 89 4e f2 89 4e f6 c6 =}.F.)}...N..N..
[MSS] 0120: 06 96 7d cb ea 03 00 00 20 0f b6 c8 66 8b 46 f8 ..}..... ...f.F.
[MSS] 0130: 66 03 46 1c 66 8b d0 66 c1 ea 10 eb 5e 0f b6 c8 f.F.f..f....^...
[MSS] 0140: 4a 4a 8a 46 0d 32 e4 f7 e2 03 46 fc 13 56 fe eb JJ.F.2....F..V..
[MSS] 0150: 4a 52 50 06 53 6a 01 6a 10 91 8b 46 18 96 92 33 JRP.Sj.j...F...3
[MSS] 0160: d2 f7 f6 91 f7 f6 42 87 ca f7 76 1a 8a f2 8a e8 ......B...v.....
[MSS] 0170: c0 cc 02 0a cc b8 01 02 80 7e 02 0e 75 04 b4 42 .........~..u..B
[MSS] 0180: 8b f4 8a 56 24 cd 13 61 61 72 0b 40 75 01 42 03 ...V$..aar.@u.B.
[MSS] 0190: 5e 0b 49 75 06 f8 c3 41 bb 00 00 60 66 6a 00 eb ^.Iu...A...`fj..
[MSS] 01a0: b0 4e 54 4c 44 52 20 20 20 20 20 20 0d 0a 4e 54 .NTLDR ..NT
[MSS] 01b0: 4c 44 52 20 69 73 20 6d 69 73 73 69 6e 67 ff 0d LDR is missing..
[MSS] 01c0: 0a 44 69 73 6b 20 65 72 72 6f 72 ff 0d 0a 50 72 .Disk error...Pr
[MSS] 01d0: 65 73 73 20 61 6e 79 20 6b 65 79 20 74 6f 20 72 ess any key to r
[MSS] 01e0: 65 73 74 61 72 74 0d 0a 00 00 00 00 00 00 00 00 estart..........
[MSS] 01f0: 00 00 00 00 00 00 00 00 00 00 00 ac bf cc 55 aa ..............U.

With a bit of luck mass storage bounty will be completed next week :)

YASU - Yet Another Status Update

2008-10-22T21:17:00.000+02:00

Hello there,

There is actually not much to tell you, except the small status update :)

The development of AROS for Efika is an interesting coding experience. Some parts come without any trouble, and are ready to use, stable and usable just out of the box. Others require a bit more patience and documentation reading.

I have put a whole bunch of modules into the Efika kernel and they do seem to work properly. As I wrote the last entry in my blog, efika kernel consisted of 23 modules. Now, there are 40! All of them seem to work :-D. The PCI driver for MPC5200B successfully scans the PCI bus full of interesting devices

[PCI] Adding driver PCINative (Efika5200 native direct access PCI driver) to the system
[PCI] Scanning bus 0
[PCIDevice] 00.10.0 = 1002:5960 (Video PC Compatible VGA)
[PCIDevice] 00.10.1 = 1002:5940 (Video Other )
[PCIDevice] 00.1c.0 = 1057:5809 (Bridge Other )
[PCI_Efika] All OK

The ATI hidd communicates with my TFT monitor using our I2C class.

calling InitResident("radeon.hidd", NULL)
[ATI] Init
[timer] OpenDevice(0)
[ATI] Enumerator: checking productid 5960 vendorid 1002 00008904
[ATI] Enumerator: found productid 5960 vendorid 1002 masked_check 0
[KRN] KrnMapGlobal(80000000->80000000 08000000 0305)
[ATI] Got framebuffer @ 80000000 (size=128MiB)
[KRN] KrnMapGlobal(88000000->88000000 00010000 0305)
[ATI] Got registers @ 88000000 (size=64KiB)
[ATI] RomBase provided by ATI card: 88020000
[KRN] KrnMapGlobal(88020000->88020000 00020000 0305)
[ATI] Got BIOS @ 88020000 (size=128KiB)
[ATIBMP] Bitmap at 0x6e640, size 16384 bytes (131072 bits)
[ATI] Video BIOS not detected in PCI space!
[ATI] Attempting to read Video BIOS using openfirmware
[OF] OpenKey('/pci/display')
[OF] looking for child 'pci'
[OF] looking for child 'display'
[ATI] OF reported BIOS at ff1039b8
[ATI] Legacy BIOS detected
[ATI] Connector0: DDCType-2, DACType-1, TMDSType-0, ConnectorType-3
[ATI] Connector1: DDCType-3, DACType-0, TMDSType--1, ConnectorType-2

The timer.device is ready and working. It uses slice timer which, at 33MHz timebase clock, has a minimal resolution of 7 microseconds. If it will be insufficient then I will try to change the clock used. Beloved dos.library complains that no bootable volumes have been found:

[DOS] __dosboot_IntBoot: Could not open bootmenu.resource, something's wrong!
[timer] OpenDevice(1)
[DOS] __dosboot_IntBoot: Checking MountList for useable nodes:
No bootable disk was found.
Please insert a bootable disk in any drive.
Retrying in 5 seconds...

The USB stack is working. It has found my USB stick, yet it is unsupported :))

[USBDevice::New] Address=02, Interface=00, Bus=0x899e4, Hub=0x899e4
[USBDevice::New] Device 1d00:13fe 00/00/00 at address 000899e4:02
[USBDevice::New] Default LangID=0904
[USBDevice::New] iProduct = "DataTraveler 2.0"
[USBDevice::New] iManufacturer = "Kingston"
[USBDevice::New] iSerial = "5B72059F82DF"
[USB] USBDevice::New() = 0x94804

The Efikas MPC5200B CPU has built in OHCI USB controller. Yay! That was fun! Allthough all usual OHCI controllers work in little-endian mode (even the one in PPC based Sam440/Pegasos/AmigaOne and others!!). MPC5200B is different. Here, the whole OHCI chip is a big endian beast. Respect! And wasted time for me ;)

In order to complete the Efika bounty, I need to do

ata.device specific for MPC5200B. If I will do my best, DMA transfers will work.
Network driver for Efika. The rest of TCP/IP stack is already there.

But hey! How will you install AROS on harddrive then? Tftpboot? Hard to do. Remove harddrive and use another machine? Almost impossible and stupid. Well?...

There is a way. Allthough the Poseidon bounty is open, I cannot wait for this bounty. Instead, I will apply for the bounty number 25. What do you think about? Am I cruel? Evil? Will my work on USB mass storage be pointless in spite of Poseidon? Tell me what you think about - I'm ready for all kinds of criticism ;)

During next few days I will consider what has a higher priority right now: USB Mass Storage or ATA.

Cheers :)

AROS on Efika status update

2008-09-30T15:40:00.005+02:00

I haven't been posting here for a very long time - sorry about that. I hope you still remember me :) The AROS port to Efika progresses nicely. There were some issues with handling of the MMU unit but now they are luckily ironed out.

The kernel.resource which happens to be the core of AROS, has been extended compared to the version which sam440 port uses, and even more extended compared to the x86_64 version. It uses MMU a bit more - protect all regions of memory which shouldn't be accessed, provides supervisor address space starting at 0xff000000 and provides access to a "virtual" SysBase, i.e. reading a 32-bit value (and only 32-bit one!) from address 0x00000004 will give you the pointer to the ExecBase structure.

Kernel resource exposes four new functions to the user space. KrnMapGlobal maps the physical address range of specified size into virtual one, using desired protection and caching settings. KrnUnmapGlobal removes the mapping created above. KrnCreateContext creates a cpu context stored in the area accessible by supervisor only. KrnDeleteContext removes the cpu context and eventually unbinds it from the FPU (kernel.resource in efika will use lazy FPU context switching).

There is also a new system call - SC_REBOOT. It performs a soft reboot of AROS on efika. Don't be afraid about non-intentional syscall which could reboot your efika, it may be done only in kernel.resource and exec.library. A system call which would occur from any other address range would cause no action.

Apart from the low-level stuff I tried to boot AROS with a bit more modules. The result looks like this:

Welcome to SmartFirmware(tm) for bplan EFIKA5K2
Version 1.3 (20070122084838)
SmartFirmware(tm) Copyright 1996-2001 by CodeGen, Inc.
All Rights Reserved.
Pegasos BIOS Extensions Copyright 2001-2007 by bplan GmbH.
All Rights Reserved.
ok boot

Second Level Bootloader for OpenFirmware
Build 242 from Sep 13 2008
Available memory 128MB

Available boot configurations:
1. AROS for Efika 5200
2. AROS for Efika Test 2
Boot? (4.8)>

Loading "AROS for Efika 5200"
boot/aros-efika
boot/modules/expansion.library
boot/modules/utility.library
boot/modules/partition.library
boot/modules/battclock.resource
boot/modules/aros.library
boot/modules/bootloader.resource
boot/modules/mathieeesingbas.library
boot/modules/oop.library
boot/modules/hiddclass.hidd
boot/modules/misc.resource
boot/modules/graphics.hidd
boot/modules/gfx.library
boot/modules/keymap.library
boot/modules/intuition.library
boot/modules/layers.library
boot/modules/input.device
boot/modules/timer.device
boot/modules/gameport.device
boot/modules/keyboard.device
boot/modules/pci.hidd
[KRN] EFika5200B Kernel build on Oct 1 2008
[KRN] BootMsg @ 0x19111e4
[KRN] Copying TagList and data
[KRN] CmdLine: 'command_line_option_1 command line "line option"'
[KRN] Initializing exception handlers
[KRN] Initializing MMU
[KRN] Location of MMU tables: 07000000-070fffff
[KRN] SDR1 = 0700000f
[KRN] Flushing TLB
[KRN] MBAR at f0000000
[KRN] HID0=0000c000 HID1=40000000
[KRN] Entering ictl_init.
[KRN] Stopping all interrupt activities
[KRN] Mapping 00003000-06ffffff range for public use
[KRN] Mapping f0000000-f002fffc range for MBAR
[KRN] Mapping ff100000-ff123fff range for public read-only access
[KRN] Mapping ff124000-ff7f4fff range for supervisor
[KRN] Mapping ff7f5000-ff7fffff range for read-write
[KRN] Mapping ff800000-ff8b6fff range for read-only
[KRN] Mapping ff8b7000-ffffffff range for supervisor
[KRN] Supervisor mem: 6979KB free
[exec] AROS for Efika5200B - The AROS Research OS
[exec] Preparing the ExecBase...
[exec] ExecBase at 00003280
[exec] Clearing ExecBase
[exec] Initializing library...
[exec] Adding memory
[exec] Done. SysBase->ThisTask = 0x004180
[exec] Resident modules (addr: pri version name):
[exec] + 0xff80fd50: 127 2 "kernel.resource"
[exec] + 0xff811070: 126 41 "exec.library"
[exec] + 0xff8142ec: 110 41 "expansion.library"
[exec] + 0xff81b658: 104 1 "partition.library"
[exec] + 0xff816828: 103 41 "utility.library"
[exec] + 0xff81c92c: 102 41 "aros.library"
[exec] + 0xff81f9c0: 101 40 "mathieeesingbas.library"
[exec] + 0xff81d820: 100 41 "bootloader.resource"
[exec] + 0xff823d5c: 94 41 "oop.library"
[exec] + 0xff824fe4: 92 1 "hiddclass.hidd"
[exec] + 0xff8b56a4: 90 1 "pci.hidd"
[exec] + 0xff866a60: 65 41 "graphics.library"
[exec] + 0xff8aaa38: 60 41 "layers.library"
[exec] + 0xff8aded0: 50 41 "timer.device"
[exec] + 0xff81bdf0: 45 41 "battclock.resource"
[exec] + 0xff82582c: 45 41 "misc.resource"
[exec] + 0xff8af5b0: 44 41 "gameport.device"
[exec] + 0xff8b0d2c: 44 41 "keyboard.device"
[exec] + 0xff86b158: 40 41 "keymap.library"
[exec] + 0xff8acc8c: 30 41 "input.device"
[exec] + 0xff8a0afc: 10 50 "intuition.library"
[exec] + 0xff869d30: 8 41 "cybergraphics.library"
[exec] + 0xff83c4d8: 0 1 "graphics.hidd"
[exec] InitCode(RTF_SINGLETASK)
enter InitCode(0x2, 0)
calling InitResident("kernel.resource", NULL)
[KRN] Kernel resource post-exec init.
[KRN] Interrupts enabled
[KRN] Entered user mode
calling InitResident("expansion.library", NULL)
leave InitCode(0x2, 0)
[exec] InitCode(RTF_COLDSTART)
enter InitCode(0x1, 0)
calling InitResident("partition.library", NULL)
calling InitResident("utility.library", NULL)
calling InitResident("aros.library", NULL)
calling InitResident("mathieeesingbas.library", NULL)
calling InitResident("bootloader.resource", NULL)
[BootLdr] Init. msg=0xff7ffc30
[BootLdr] KRN_CmdLine=0xff123ad0
[BootLdr] CmdLine="command_line_option_1 command line "line option""
[BootLdr] Init: Argument command_line_option_1
[BootLdr] Init: Argument command
[BootLdr] Init: Argument line
[BootLdr] Init: Argument "line
[BootLdr] Init: Argument option"
calling InitResident("oop.library", NULL)
calling InitResident("hiddclass.hidd", NULL)
calling InitResident("pci.hidd", NULL)
[PCI] Initializing PCI system
[PCIDriver] Dummy Driver initialization
[PCI] base class initialization
[PCI] Everything OK
calling InitResident("graphics.library", NULL)
calling InitResident("layers.library", NULL)
calling InitResident("timer.device", NULL)
calling InitResident("battclock.resource", NULL)
calling InitResident("misc.resource", NULL)
calling InitResident("gameport.device", NULL)
calling InitResident("keyboard.device", NULL)
calling InitResident("keymap.library", NULL)
calling InitResident("input.device", NULL)
calling InitResident("intuition.library", NULL)
calling InitResident("cybergraphics.library", NULL)
calling InitResident("graphics.hidd", NULL)
leave InitCode(0x1, 0)
[exec] I should never get here...
[KRN] Uhm? Nothing to do?
[KRN] STOPPED

Next module beeing working on is timer.device. Unfortunately, it will have worse resolution than the timer in sam440 - circa 7µs.

Ten years ago...

2008-09-12T21:57:00.003+02:00

... I was preparing my very first commit for AROS. It wasn't much. A tiny bootsector loading few sectors from floppy. These sectors contained some startup code followed by empty function written in C. Everything else was written in assembler.

No, it wasn't working yet. It was just proof of concept. A small check whether I will be able to perform this task. I was ten years younger and much more stupid of course. It was beginning of a great adventure.

And then, three days later, the cvs mailer generated an email containing these few lines:

* schulz 15.09.1998 22:31:13

AROS/config/ibmpc/boot/: Makefile(A), README(A), bootsect.S(A),
head.S(A), init.c(A), setup.S(A), video.S(A):

At least. The first pre-alpha version. Not to much for now, but it
is.

The mysterious story of native x86 AROS begun. It's time to open some wine :)

Boot? (5.0) >

2008-08-20T07:35:00.002+02:00

Second Level Bootloader for OpenFirmware
Build 238 from Aug 19 2008
Available memory 128MB

Available boot configurations:
1. AROS for Sam440
2. AROS for Efika 5200B

Boot? (4.3)>

select yourself... ;)

SAM440 Bounty

2008-07-24T23:27:00.004+02:00

Has been marked as completed. I have been working on AROS port for SAM440 for half a year. It was an extraordinary experience. I have never been working on such "young" hardware before. I have never been cooperating with board developers at this degree before. Thank you all for letting me do it! :)

The ISO of Sam440 AROS can be found here (MD5: 68b1010851d29de3aaf711af7fa9144e). It is compressed with 7zip again. Network starts automatically upon AROS startup. Due to some inconvenience in AROS (it lacks __ckhabort() function) I haven't used DHCP protocol to set the IP of Sam440. Instead, the static address 192.168.2.211 is used.

I want to thank all of You who did helped me. My Wife for patience and acceptance, Randy Vice for leading TeamAROS for so long, and for very nice cooperation, Massimiliano Tretene and Nicola Morocutti for all the help, tons of good technical information and nice talks late evenings, all Bounty supporters and the whole AROS team and all you who whished me luck.

I will not leave the sam440 alone. There is still so much to do :)
... and never enough time.

Bye,
M.

Try it Yourself

2008-05-19T22:58:00.002+02:00

Sam440 port of AROS is missing the EMAC driver at the moment. Nevertheless I have decided to give you a test version to try. Few comments on this iso:

Download it from this address,
Compressed size: 7492755 bytes, Uncompressed size: 37980160 bytes,
the MD5 sum equals 6f630f0bff9f5c5922d5ef76e1c748f5
The kernel of AROS assumes that your machine has 512MB of memory,
The default resolution is set to 1024x768x16. Due to a bug hiding in Zune, AROS might be unstable after the mode switch.
I have tested AROS connected to monitor through the DVI port - this one works for sure.

Have fun with it.

Status update - USB on Sam440

2008-04-28T00:04:00.005+02:00

I have thought that fixing OHCI driver for endianess will be painful, since the OHCI chip works internally only in LittleEndian mode. Fixing it was like a fight with armor in form of preprocessor macros... But one day the war was over. The USB chip was, at least in theory, expected to work flawlessly.

It was not.

I have plugged the USB mouse and watched the debug. Wooha! OHCI root hub detected the change on one of it's ports. Great! The base USB class wanted to get on of mouse' descriptors, but it failed. It turned out that a local copy of transfer descriptor was in the data cache of CPU. Well, whatever. It may happen since AMCC440 does not maintain cache coherency. So, I did proper CacheClearE() and continued....

Two days later I was still fighting... Everything should work perfectly. The USB mouse got configured, my USB HID class knew what device it is. It was even able to parse the incoming reports. But there were none. Why oh why there are no reports from mouse???

Well, due to one mistake the OHCI chip was told that it should commit 0% (zero) for periodic transfers. Once fixed, USB mouse started to work. USB Stack is as usable as on a x86 architecture: USB - mice, keyboards, tablets and hubs are supposed to work. Additionally, I have fixed all cache issues in USB stack and enabled copy-back caching again.

You may see the PCITool app on sam440 - one of the very first programs I've started as soon as I could move the mouse pointer. Other Sam440 and AROS related screenshots may be found here.

I'm going to test AROS a bit this evening. As soon as everything will work as expected I will attempt to write the network driver for samantha.

Small status update

2008-04-21T08:36:00.003+02:00

Hello there.

If you were wondering where the hell am I, here's the answer. My son, Oliver, was in a hospital recently. Twice within a month, once with nephritis, once with pneumonia. I have shared all my time between work, taking care of my daughters and visiting Oliver. There was very few time for AROS.

It does not mean that I did nothing, though. First of all I have been trying to make our ata.device work with Sam440's SiL3114 SATA chip. With a significant help of Tomasz Wiszkowski I made it work on Sam! There were few issues which were not ever seen on x86 architecture. I have had to implement cache flushing in exec.library (finally! I should have done it before ;)), I have added some endian swapping code and had to flush data cache after the setup of PRD entries for DMA transfer.

The next step was radeon.hidd. It simply wasn't working as expected. Initialization of any screen mode put my monitor into sleep mode. Not good. I had to add proper timing function to the driver (previously it used busy loops for all kinds of delays), then I have embedded a real BIOS into the sam440 variant of this driver - still no luck with displaying. I have added i2c support to the driver and now it even uses DDC bus and EDID information of the connected monitor. Still no luck. Finally, I have synced the video mode restore in my driver with xorg repository. That helped. It seems that the PLL setting on radeon is awfully fragile.

Having SATA and Radeon chips working, I have decided to give AROS a try. I have burned it on CD and booted on SAM. Ouch. Program exception. It turned out that I have had an outdated version of ELF LoadSeg, which was not flushing any caches. Another try brought me a bit further, but AROS hung on the following lines in startup-sequence:

If EXISTS ENV:SYS/Packages
    List ENV:SYS/Packages NOHEAD FILES TO T:P LFORMAT="If EXISTS $SYS/Packages/%s*NCD $SYS/Packages/%s*NIf EXISTS S/Package-Startup*NExecute S/Package-Startup*NEndif*NEndif*N"
    Execute T:P
    Delete T:P QUIET
    CD SYS:
EndIf

Out of curiosity, I have deleted the SYS:Prefs/env-archive/SYS/Packages directory and tried once more. Moooo! Success. The wanderer screen showed up as you may see on the screenshot. BTW. Photographing display sucks. :-) I will investigate the issue with startup-sequence a bit later. Right now it's a bit to early for it.

Now I gave the OHCI driver a look. The code assumed to some degree that it works on little endian machines. Moreover, it did assumed, that the processor uses very nice feature called cache snooping, which is the case on x86 family of CPU's. Cache snooping means, that the CPU watches all transactions on the bus, and thus keeps it's all caches up to date. Since it is not the case on sam440, the OHCI code needs to be reorganized a bit - it requires tons of CacheClearE() calls and few CachePreDMA/CachePostDMA pairs. At the moment all caches on Sam440 are working in write-through modus and will stay so until I fix all cache-irrelevant issues in the USB stack. I hope to have the whole stack working within few weeks.

In the mean time, I have helped Kalamatee with ACPI code a bit. Together we have made all CPU's in x86_64 SMP system booting. At the very moment all Application Processors are switched into 64bit mode of operation and then put to sleep.

UBoot Second Level Bootloader (UB2LB) update

2008-03-18T08:43:00.003+01:00

I have been fiddling with my UBoot Second Level Bootloader (UB2LB) project. I ahve cleaned the code a little bit and added some nice features... Until now UB2LB assumed that user wants to perform network boot (through TFTP) only. Now it listens to the uboot and uses it's list of boot devices. It tries to boot of media selected through the environment variables boot1, boot2 and boot3. As soon as it supports booting from desired media and as soon as the media contains boot/menu.lst file (the file defining the layout of kernel modules and other boot options) it will start booting from it.

Currently the UB2LB supports booting through TFTP and CD (ISO9660 with optional RockRidge extensions). Since UBoot in Sam440 does support ElTorito, one can boot AROS (or at least parts of it, as Sam440 AROS is not yet ready ;)) directly from CD.

Besides ub2lb, I have been working on AROS for Sam440 too. There are already 30 modules loaded together with kernel into memory! Among them one may find dos.library and radeon driver. Both still need intensive testing though. At the very moment the filesystems and SATA driver are missing, therefore dos.library complains in it's usual way:

No bootable disk was found.
Please insert a bootable disk in any drive.
Retrying in 5 seconds...

Which is a lie of course, since it retries every 10 seconds :) The radeon driver is much more noisy and says

[ATI] Init
[ATI] Enumerator: checking productid 4c66 vendorid 1002 01004414
[ATI] Enumerator: found productid 4c66 vendorid 1002 masked_check 0
[ATI] Got framebuffer @ a8000000 (size=128MiB)
[ATI] Got registers @ b0000000 (size=64KiB)
[ATI] Got BIOS @ c0000 (size=128KiB)
[ATI] Restoring MEM_CNTL (00000000), setting to 2d002d01
[ATI] Radeon init
[ATI] flags: IsMobility
[ATI] R300CGWorkaroung = No
[ATI] Video memory = 64MiB (128 bit DDR SDRAM)
[ATI] Primary:
Monitor -- AUTO
Connector -- DVI-D
DAC Type -- TVDAC/ExtDAC
TMDS Type -- Internal
DDC Type -- DVI_DDC
[ATI] Secondary:
Monitor -- AUTO
Connector -- VGA
DAC Type -- Primary
TMDS Type -- External
DDC Type -- VGA_DDC
[ATI] Video BIOS not detected, using default clock settings!
[ATI] PLL parameters: rf=2700 rd=12 min=12500 max=35000; xclk=10300
[ATI] Usable size: 65536KB
[ATI] AllocBitmapArea(4096x16@4) = 0
[ATI] AllocBitmapArea(64x64@4) = 0x40000
[ATI] Enumerator found a card (ProductID=4c66)
[ATI] The card is supported

The AROS for Sam440 looks really promising. I am going to work on SATA driver right now and see how far will AROS boot.

No screenshot today... Again... Instead, if you are happy Sam440 owner, you may download test iso here. Do not expect much from it. If you assume that it will boot on any PPC hardware, then you are wrong. It will not work on any MacIntosh hardware. It will not work on any other OpenFirmware hardware. No, it will not work on Pegasos. Neither on Efika. This ISO does require UBoot firmware (with implementation of the boota command!) to work.

Ah, yes. Do not even try to boot this iso on AmigaOne, µA1 or any other. It will crash system before even exec.library will say "Hello, world!". AMCC440 CPU conforms the PowerPC E-Book specification and this version of AROS will not work any other type of PPC core :)

Anyway, have fun and stay tuned for more news :)

PS. Happy Easter to You all :))

Some news

2008-02-27T08:17:00.004+01:00

Please forgive me, there will be no screenshot today! :) Instead, I may offer you bunch of log entries which I have found on the RS232 wires...

The kernel is still highly adjustable and thanks to the modules which are in PPC-form already it's a tiny bit bigger than previously

[KRN] Kernel size: 798KB code, 43KB data

It consists of the amcc440-aware kernel linked statically with exec.library (these two beasts have to cooperate somehow and depend on each other) and add-ons loaded by the UB2LB. They all are living in write-guarded address space far far away from any other allocatable memory. The kernel.resource does scheduling, handles interrupts, provides sane MMU mapping and handles exceptions properly. One of them is (and has to) issued everytime when the code tries to read a longword from absolute address 0x00000004. This area does not correspond any memory and assignment of the SysBase is done in exception handler. It is slower and inconvinient but accessing the SysBase pointer at 4UL is considered a bug anyway. Everything should be able to work without it. Later, the MMU handler will put some debug regarding such barbarian SysBase access.

Let's continue. The kernel pre-exec routine has been executed and did it's magic. Then, the exec's startup is called. It puts SysBase at the bottom of usable memory

[exec] AROS for Sam440 - The AROS Research OS
[exec] Preparing the ExecBase...
[exec] ExecBase at 008d0280

and scans for all modules loaded by the bootstrap code. There are lots of them currently, some of them even work :)

[exec] Resident modules (addr: pri version name):
[exec] + 0xff80bbd0:  127   1 "kernel.resource"
[exec] + 0xff80c5a0:  126  41 "exec.library"
[exec] + 0xff80f668:  110  41 "expansion.library"
[exec] + 0xff8166a8:  104   1 "partition.library"
[exec] + 0xff811b9c:  103  41 "utility.library"
[exec] + 0xff817454:  102  41 "aros.library"
[exec] + 0xff8186b8:  101  40 "mathieeesingbas.library"
[exec] + 0xff81cafc:   94  41 "oop.library"
[exec] + 0xff81ddb4:   92   1 "hiddclass.hidd"
[exec] + 0xff8a7cc0:   90   1 "pci.hidd"
[exec] + 0xff8aa588:   89   1 "pci-amcc440.hidd"
[exec] + 0xff85d904:   65  41 "graphics.library"
[exec] + 0xff8a10b0:   60  41 "layers.library"
[exec] + 0xff81e5ec:   45  41 "misc.resource"
[exec] + 0xff8abe0c:   44  41 "keyboard.device"
[exec] + 0xff8ad50c:   44  41 "gameport.device"
[exec] + 0xff861d64:   40  41 "keymap.library"
[exec] + 0xff8a3304:   30  41 "input.device"
[exec] + 0xff897338:   10  50 "intuition.library"
[exec] + 0xff860990:    8  41 "cybergraphics.library"
[exec] + 0xff8b1a88:    4  41 "console.device"
[exec] + 0xff834b38:    0   1 "graphics.hidd"
[exec] + 0xff8b6ce4: -120  44 "workbench.library"
[exec] + 0xff8bcb3c: -126  41 "con.handler"
[exec] + 0xff8c669c: -126   1 "packet.handler"
[exec] + 0xff8bece8: -127  41 "nil.handler"
[exec] + 0xff8c2e94: -127  41 "ram.handler"

Once the SysBase is up and operable, the exec.library calls InitCode. Twice. The first call is done with RTF_SINGLETASK and it wakes up the kernel.resource and expansion.library. The second, post-exec init of the kernel.resource prepares system to work without supervisor mode, eg. it enables userspace apps to flush caches. Then the interrupts are enabled and user mode is entered.

[exec] InitCode(RTF_SINGLETASK)
[KRN] Kernel resource post-exec init
[KRN] Allowing userspace to flush caches
[KRN] Interrupts enabled
[KRN] Entered user mode

Once expansion.library finishes it's setup, exec issues InitCode for the second time, with RTF_COLDSTART. There the real boot begins... Libraries are initialized, some of them fail at the very moment (eg. the input.device does a guru mediation since it cannot open timer.device yet) and the only visible (visible on serial debug of course!) effect of AROS booting is the PCI subsystem, which talks a lot (and works!)

[PCI] Initializing PCI system
[PCIDriver] Dummy Driver initialization
[PCI] base class initialization
[PCI] Everything OK
calling InitResident("pci-amcc440.hidd", NULL)
PCI440: Driver initialization
PCI440: Adding Driver to main the class OK
[PCI] Adding Driver class 0x01001d84
[PCI] Adding driver PCINative (AMCC440 native direct access PCI driver) to the system
[PCI] Scanning bus 0
[PCIDevice] 00.00.0 = 1014:027f (Bridge Other )
[PCIDevice] 00.0a.0 = 12d8:8150 (Bridge PCI-PCI Standard)
[PCIDevice] 00.0c.0 = 1002:4c66 (Video PC Compatible VGA)
[PCIDevice] 00.0e.0 = 1095:3114 (Mass storage Other )
[PCI] Scanning bus 1
[PCIDevice] 01.04.0 = 1013:6005 (Multimedia Audio )
[PCIDevice] 01.05.0 = 1131:1561 (Serial USB )
[PCIDevice] 01.05.1 = 1131:1561 (Serial USB )
[PCIDevice] 01.05.2 = 1131:1562 (Serial USB )
PCI440: All OK

Actually, the InitCode(RTF_ColdStart) should never return to exec.library. Due to missing dos it does return however

leave InitCode(0x1, 0)
[exec] I should never get here...

and this is the end of the story. At least today :)

Everything is virtual

2008-02-07T23:52:00.000+01:00

Well, almost :)

The very first goal towards the SAM440 port of AROS is halfway done. The UBoot Second Level Bootloader is able to use TFTP protocol and load AROS menu.lst configuration file and binaries. It loads the AROS executables and relocates properly. It has reached the stage where I can live it as it is for a while and concentrate on the real goal - making AROS work on SAM440 board!

I have decided to separate the kernel (and libraries loaded together with it) from user space. The kernel is loaded somewhere within first 16MB of RAM and then relocated to the virtual address at the very top of the 32-bit address space. The bootstrap loader works in the same way as the x86_64 bootstrap did. It puts all read-only sections upwards from the kernel base, and all writable sections downwards from the kernel base. Since I'm evil by definition, my core of SAM440 AROS will greedily take all the memory *below* it's physical location for itself. This memory (few megabytes) will be used as a local pool for kernel and will be excluded from usermode access of any kind.

I must admit I was a bit surprised and shocked as I read the AMCC440 documentation. The PowerPC E-Book from IBM stands quite clearly:

Book E provides binary compatibility for 32-bit PowerPC application programs.
Binary compatibility is not necessarily provided for privileged PowerPC instruc-
tions.

And you know what? They really mean that! Writing lowlevel code for AMCC440 cpu is very different from my previous experience with G3 CPU. :)

No screenshot today. Even worse, my bootlogs are very boring this days. Have a look if you're strong enough...

Filename 'boot/aros-amcc440'.
Load address: 0xe15a078
Loading: ######
done
Bytes transferred = 27062 (69b6 hex)
[BOOT] Loading ELF file from address 0e15a078
[BOOT] ELF: section loaded at 00800000 (Virtual addr: ff800000)
[BOOT] ELF: section loaded at 00802000 (Virtual addr: ff802000)
[BOOT] ELF: section loaded at 007feffc (Virtual addr: ff7feffc)
[BOOT] ELF: section loaded at 007feff0 (Virtual addr: ff7feff0)
[BOOT] ELF: section loaded at 007fef90 (Virtual addr: ff7fef90)
[BOOT] ELF: section loaded at 007f5f94 (Virtual addr: ff7f5f94)
[BOOT] Flushing all caches
[BOOT] Jumping into kernel
[BOOT] Bss: ff7fef90-ff7fefeb, 0000005c
[BOOT] Bss: ff7f5f94-ff7fef8b, 00008ff8
[KRN] Clearing BSS
[KRN] 0xff7fef90-0xff7fefeb
[KRN] 0xff7f5f94-0xff7fef8b
[KRN] Kernel resource pre-exec init
[KRN] MSR=00029000

Stay tuned for more news.

I've promised to show you some screenshot

2008-01-22T22:18:00.001+01:00

That's how it looks like. The menu drawing and handling in bootstrap is for real. The menu.lst file is made for testing purposes, just to see whether it will be interpreted properly.

The default boot option is marked red and will be booted in 2 seconds (as seen on the screen) unless some other option gets selected. Of course one may change both the default option and the timeout.

The menu.lst config file which was parsed by bootstrap was like this:

# menu.lst config file for PPC AROS. Test version ;)

timeout 20
default 0

title AROS PowerPC test 1
   kernel boot/aros-ppc1 arg1 argument_2 "some arg 3" another_one
   module Libs/arosc.library
   module boot/modules.pkg
   module boot/test1.module

title AROS PPC test 2
   kernel boot/aros-ppc2
   module boot/modules.pkg
   module boot/test2.module

title AROS PPC third option
   kernel boot/blah

Power for your embedded ideas.

2008-01-14T21:43:00.000+01:00

I like embedded systems. They are beautiful and simple, yet powerful enough to surprise you. They surround us :-) Beware, they are watching you ;). Recently I have applied for the AROS bounty number 60 - port of AROS to the SAM440. Yes, going back to PowerPC world for some time.

The board is already at home and working. I have made a PPC crosscompiler toolchain on my laptop and have a very nice dev environment. I make the PPC build on x86 machine, boot on sam440 through TFTP protocol and watch the debug output sent over serial line on x86 again. Recently, I have even added the rs232 terminal support to my beloved Eclipse IDE, and I don't need to switch between Eclipse and xterm anymore :)

The porting process may be divided into few logical parts:

Writing the second level boot loader
Making AMCC440EP aware Kernel (with kernel.resource as it's interface)
Porting the core system
Testing and debugging
Porting the contrib/necessary (including the USB stack and TCPIP stack)
Testing and debugging
Even more testing and debugging ;)

The U-Boot installed on sam440 provides a boota command which was initially supposed to boot AmigaOS4 operating system. This command looks for possible boot sources and launches the proprietary second level bootloader used in OS4. On my setup it loads the open-sourced second level bootloader which is responsible for loading AROS kernel and additional modules in the same fashion x86_64 does. This step should be halfway ready (initially with boot through TFTP only) within next week. Later, the read-only support for several filesystems (FFS, SFS, ISO9660 come to my mind) will be added. You may expect some nice screenshot of this bootloader this week :).

In the mean time I will still hunt for bugs in x86_64 AROS. They are really nerving but hopefully solvable. Recently, it became possible to start the InstallAROS tool on 64-bit machine, format AFFS partitions and install 64-bit AROS onto the drive. AROS can even boot from harddrive after successful installation process. Amazing :)

Find a bug...

2007-11-23T11:24:00.000+01:00

in the following piece of code:

/* Allocate method table for this interface */
ifb->MethodTable = (struct IFMethod *)AllocVec(mtab_size, MEMF_ANY);
if (ifb->MethodTable)
{
  /* Get correct ID for the interface
     (string ID => interface ID mapping) */
  if (init_mi_methodbase(interface_id, &(ifb->InterfaceID), OOPBase))
  {
    ....

Found it? No? Too bad, you loose. Remember my words: "ULONG is BAD, IPTR is GOOD". The init_mi_methodbase expects as a second argument a pointer to an ULONG and the ifb->InterfaceID was declared as an ULONG some days ago. It was supposed to work properly, since the ID is not a pointer in any form. Fine. The issue is, the struct IFMethod which did contained the InterfaceID ULONG field "inherits" from the Bucket used in hahstables of the oop.library. The Bucket structure expets this ID field to be an IPTR....

What a mess!

The 32-bit ULONG variable of struct IFBucket was initialized properly but the Bucket structure expected to find there a 64-bit IPTR one. Until now it was just reading some random values, name them trash. On some machines one had there zeroes instead of random values. That was the case on my machine, on qemu and on vmware. I have not seen this bug :) Now I have modified memory alloc functions, so that they fill allocated region with some trash, unless the MEMF_CLEAR flag was set. Thanks to this small change I was able to see what many of you saw upon trying my last aros64 iso. After some fight with oop.library (adding debug points here and there) I have solved the issue.

You may download the new AROS64 iso from here. The md5 sum of the file is: 4852e85ab83f949e9ffe0019ea039e59.

I hope you will be able to boot into Wanderer now. And remember, AROS64 in VESA mode looks simply better :)

EDIT: I have uploaded newer iso. Here, the kernel limits address space to the 4GB. As soon as proper MMU handling is done, I will remove this limit.

AROS x86_64 Beta 2

2007-11-20T23:25:00.000+01:00

Don't expect much from it. It is a beta 2 in early test phase - many things may just crash without any warning :)

Anyway, you may get it from here.

Awful bug...

2007-11-20T08:58:00.000+01:00

(~0UL/2+1)....

What's that, you will ask? Well, that was TEH BUG which made all buffered dos operations (the ones done through FGetC, FGetS, FPutC, FPutS, Printf and many more) unusable on x86_64 target. What does this line? Well, it should set the highest bit to one and clear all other ones. This tiny line of code works perfectly... Better than enyone expected in the old times, where C's long was 32-bit...

The struct FileHandle of dos.library contains a tiny buffer used to speed up file operations. The buffer could be therefore in both READ and WRITE modes. In order to set it into write mode, the FHF_WRITE on the filehandle's flags has to be set. The fh_Flags field is of type ULONG - it is a 32-bit unsigned number.

The FHF_WRITE was defined as ~0UL/2+1. Fine. On x86, where the type long is 32-bit, the FHF_WRITE equalled 0x80000000. On x86_64 however the type long is 64-bit wide. The FHF_WRITE flags was therefore 0x8000000000000000. And this value does not fit into ULONG variable......

I have redefined the FHF_WRITE variable a bit and suddenly the buffered operations do work, as you may see on the screenshot (yes, the whole shell uses buffered operations :-))). Finally, after one month of useless fight I continue on the x86_64 port. Sweeet.

Welcome, Oliver!

2007-10-26T22:13:00.000+02:00

Oliver Adam Schulz was born today, at 15:25 at the Hospital in Herzberg am Harz. He weights 3420 grams and is 53 centimeters tall. Both he and his mother are doing great. Dad tries to spend the huge caffeine dose he got today in hospital :)

Our daughters will meet Oliver tomorrow and are already excited over this meeting :)

Very close!

2007-10-06T22:40:00.000+02:00

A lot of things and commits have happened since my last blog entry. There was so much to do, that I have forgotten (and actually didn't have had any time to) to blog here :)

There are already filesystems in the AROS64 which may be used to boot the system - the cdvdfs is a good example. As practically everything - it has had some issues visible on 64-bit architectures only, but everything is fixable, of course :) The standard keyboard and PS/2 are supported together with vesa and vga video drivers.

I have added one long awaited "feature" to the AROS64 - partial MMU support. The kernel is partially protected (the .text and .rodata sections) against accidental writes caused by buggy applications. Moreover, the address range 0 - 0x0fff is excluded completely in both user and supervisor modes. Every write and almost every read to/from address in this range will cause immediate page fault. *Almost*? Yes, the page fault handler looks at the instruction which caused the fault. If it is a 64-bit read from address 4UL into any of the registers, then the SysBase value is saved into the requested register and the faulty instruction is omitted. It is a very simplistic emulation of legacy SysBase. Nevertheless, one should use this feature with care - it's significantly slower.

What will be next? The Zune/Wanderer fixes in order to make this pair completely usable. Then the rest of the standard AROS tree - most programs have not yet been checked in AROS64. Fixing it all will take some time, of course, but it will not take long. Apart from this fixes, I will try to move as much architecture dependences into kernel.resource as possible. Once this target is achieved, it will be possible to replace the kernel and it's userland interface - the kernel.resource, with something completely different... :)

Stay tuned for more news from the new virgin 64-bit AROS-land :)

Found dos.library!

2007-09-17T01:41:00.000+02:00

Well, the kernel consists of many more modules now, one of them beeing dos.library. It gots bored right after start, unfortunately, saying:

No bootable disk was found.
Please insert a bootable disk in any drive.
Retrying in 5 seconds...

Now, I only need some filesystem and keyboard/mouse drivers to let 64-bit AROS really boot :)
PS. The current list of modules of 64-bit AROS:

[exec] Resident modules (addr: pri version name):
[exec] + 0x000002012000: 127   1 "kernel.resource"
[exec] + 0x000002012c80: 126 41 "exec.library"
[exec] + 0x000002014de0: 110 41 "expansion.library"
[exec] + 0x00000205d2a0: 104   1 "partition.library"
[exec] + 0x000002014b40: 103 41 "utility.library"
[exec] + 0x0000020a6500: 102 41 "aros.library"
[exec] + 0x000002018ea0: 101 40 "mathieeesingbas.library"
[exec] + 0x0000020581e0: 100 41 "bootloader.resource"
[exec] + 0x0000020151c0:   94 41 "oop.library"
[exec] + 0x000002015420:   92   1 "hiddclass.hidd"
[exec] + 0x000002015640:   90   1 "irq.hidd"
[exec] + 0x000002060c00:   90   1 "pci.hidd"
[exec] + 0x00000204c4c0:   89   1 "pcipc.hidd"
[exec] + 0x000002087500:   65 41 "graphics.library"
[exec] + 0x0000020a5820:   60 41 "layers.library"
[exec] + 0x00000204d740:   50 41 "timer.device"
[exec] + 0x00000204b2e0:   45 41 "battclock.resource"
[exec] + 0x00000209c080:   45 41 "misc.resource"
[exec] + 0x0000020180a0:   44 41 "keyboard.device"
[exec] + 0x00000209edc0:   44 41 "gameport.device"
[exec] + 0x0000020acf40:   40 41 "keymap.library"
[exec] + 0x00000209d980:   30 41 "input.device"
[exec] + 0x0000020481c0:   10 50 "intuition.library"
[exec] + 0x0000020572e0:    9   1 "vgah.hidd"
[exec] + 0x0000020ab540:    4 41 "ata.device"
[exec] + 0x000002097f00:    0 41 "arosc.library"
[exec] + 0x000002059a80: -50 41 "Boot Strap"
[exec] + 0x0000020c0800: -120 41 "dos.library"
[exec] + 0x0000020c19c0: -125 41 "LDDemon"

Nice, isn't it?

Hey! Where is my dos.library??

2007-09-16T01:06:00.000+02:00

I have been fighting with 64-bit world and our build system again :) Cannot tell which of them is better or worse in terms of debugging and hunting for undefined behavior ;)

I have provided you another log (well, call this debug output a screenshot if you like). What you may see here is a list of modules present in kernel (remember, some of them have been loaded separately, by GRUB) and a very early startup process of whole AROS. The new and interesting things are timer.device, irq.hidd and ata.device.

The timer.device is a straight recompilation of x86 version. It still does not use the local APIC driven by at least 66MHz source, but uses an ancient 1193180Hz timer. It will change very soon since the new APIC timer has been proven to work properly on AROS. I need some spare time to implement it in timer.device now. There were two more "cosmetic" changes - the timer.device checks the SysBase->Elapsed field and reports forced reschedule if needed. Additionally, timer.device uses kernel resource to add/remove it's interrupt handlers.

The irq.hidd is a simple wrapper for kernel.resource. Used to add and remove IRQ handlers. Nothing less and nothing more. Boring, huh?

The ata.device compiled with some minor issues. First of all, the MakeDosNode function of expansion.library has been changed. The input packet is an array of IPTSs now (it was array of ULONGs previously, which are not suitable for 64-bit system). The other change was the way ata's internal tasks were initialized. I have sent them some parameters through the stack, which is not valid on x86_64 system anymore. Therefore, I have had to change the AddTask calls to the NewAddTask variants, with parameters passed through a TagList. You may see the result on screenshot - two internal tasks of ata.device are added and started. They do something and then wait for input...

Yes, you're right. 64-bit AROS multitask already :)

PS. You may ask about this nasty GURU down the screen. Well, it puzzled me a bit until I've found it. It's a BootStrap which cries loud that it could not open the dos.library :-) So, where's my dos.library, dude???

AROS64 - report

2007-09-05T23:48:00.000+02:00

Hello there!

It has been a very very long time since I wrote anything last time. I Hope you still visit this site :)

Since I was very busy with my work at Uni, I have abandoned idea of writing new kernel by myself, only. Sure it would be nice to do something like that alone, but I'm afraid I would end up with a half-ready kernel, a patchwork which would be big enough to let exec.library work. Nothing less, nothing more.

The plans have changed. I will make a quicker amd64 port - a slightly modified x86 version for amd64 cpu. The old concept reborn. The huge disadvantage is (yes, you will be disappointed now) that the new kernel will offer almost nothing more than the x86 one. That means - all applications will still run in one huge address space common to all processes. It's still the fastest possible approach on x86_64 architecture - some 2 MiB pages covering the very first 4 GiB address space - all of them in translation look-aside buffer (TLB) of the CPU. The SysBase pointer is still at absolute address 4, but it's use is deprecated. One should access the CPU-local SysBase variable at address %GS:8.

What are the advantages, will you ask? Well, have a look at the screenshot. The core libraries are already there. The scheduler should work, at least in theory :). Many libraries and modules may be already compiled thanks to the enormous effort of Henning Kiel, who fights with badly written sources and let them compile. Once irq.hidd and timer.device are done, I should have AROS working on amd64. Neato, huh? Apart from that, I have avoided assembler code as much as possible. Even interrupt and exception handlers are pure C called by very small context-saving asm stub.

As soon as the x86_64 port of AROS will be ready (and bounty will be satisfied), I will start project aiming at creation of new kernel for our OS. I promise.

Stay tuned. Some interesting news are coming....

Damn mcmodel=medium....

2007-06-24T21:55:00.000+02:00

I have wasted my whole weekend on hunting for a not existing bug. A x86-64 kernel was not going to boot, hanging somewhere around the initialization of few classes. After a long and stressful investigation I have found out, that the code compiled with -mcmodel=medium flag was totally wrong (I have to use this memory model, since the kernel is located at address 0x0f8000000000). The gcc documentation said:

`-mcmodel=medium'
Generate code for the medium model: The program is linked in the
lower 2 GB of the address space but symbols can be located
anywhere in the address space.

According to this information, my code has to work! But it didn't. And then, suddenly, after considering two other possibilities (kernel placed either in lowest 2GB or the highest 2GB of address space) I have found the solution:

`-mmlarge-data-threshold=NUMBER'
When `-mcmodel=medium' is specified, the data greater than
THRESHOLD are placed in large data section. This value must be the
same across all object linked into the binary and defaults to
65535.

Adding the "-mmlarge-data-threshold=1" solved all my issues caused by change from gcc 4.0 to 4.1... Oh well... ;)

Moderation

2007-05-30T14:24:00.000+02:00

Due to the increasing amount of spam comments, I have turned on the moderation. Sorry for inconvenience.

AROS ISO with USB built-in

2007-05-17T16:53:00.000+02:00

Hello.

If you would like to test AROS with USB stack built into kernel (no need to manually start or load the stack), download the following link. The md5 sum of this file:

4a6c45111e87e4bc79f6d397b01ad953 aros.iso.bz2

Boot your machine and use your USB mouse and keyboard regardless of the USB host controller of your PC. Be careful - this build sends tons of debug over the serial line (COM2 port). Have fun :)

PS. I have updated the iso. Now the OHCI driver should be less noisy and handle Reset signals on USB ports properly.

USB enters beta, OHCI driver comitted

2007-05-15T06:08:00.000+02:00

Hello there ;)

Last few weeks were horrible. Tons of important things to do in my private life, at my work and here, with AROS (The AROS Research Operating System :)). That was the reason for no posts for a really long time. When I had time for AROS, I was fighting with strange behavior of my UHCI driver with hardware I own. It seemed to me that some devices are refusing to talk with the driver at all, namely the mass storage ones. I do know that I have not written the driver yet, but the base USBDevice class should be able to initialize them at least.

The reason was very simple. The beloved BIOS support and the presence of USB2.0 controller (namely the EHCI) in my system. The EHCI may route some USB ports to legacy UHCI/OHCI hardware, but it doesn't have to. A small EHCI driver I wrote fixes this problem - it resets the EHCI controller and routes all USB ports to the USB1.1 legacy. Now (and after proper BIOS-handoff procedure required to switch the USB legacy support from BIOS off) I may fully use the UHCI driver and hot-plugging is working as expected.

Tonight I have committed the first version of the OHCI driver - it was pre-alpha unstable and non-working release at 9 PM, but I have successfully fixed it by midnight ;). The release which will come to the nightly build is still very noisy, but works. It was really a pleasure to see that my USB devices work on my wife's PC, with OHCI hardware :).

Let me tell you what works and what doesn't. The current USB stack should work properly on all machines containing USB1.1 UHCI and OHCI controllers. Even if you have USB2.0 onboard, you will be able to use USB1.1 mode only. Sorry for that. The USB2.0 EHCI driver will come, but I cannot tell when exactly. The drivers are able to do control and interrupt transfers. Bulk transfers will be easily added soon, but isochronous ones will have to wait a while - until I write a driver for USB device requiring them. Hot-plugging is working of course - without that USB makes no sense for me ;). There is one USB class for devices now - the HID class. It handles successfully USB mice, keyboards (without special keys which are not handled by AROS anyway) and some (perhaps all) tablets already. The command line/GUI tools are still missing. I plan to add some PCITool-like application.

USB stack enters beta stage now. I will hunt for bugs and improve the code. It still needs some semaphore locking here and there.

Anyway, have fun :)

Nick Andrews Interview

2007-05-02T15:16:00.000+02:00

Paul J. Beel did it again :) This time, you may read a very interesting interview with Kalamatee here.

USB: Type with your USB Keyboard

2007-04-04T14:52:00.000+02:00

I was working on support for USB Keyboards (part of the HID class) recently. Almost all keys seemd to work properly with one set of exceptions - all modifier keys were somehow broken. Today morning I have added the only one missing line of code and they work as expected now.

So, right now one may use the USB keyboard for almost everything. The Amiga keys are mapped to the both windows keys, all keys are working. What doesn't? The CapsLock key is not yet handled, the keyboard LEDs are not working (these two are matter of this afternoon) and key repeating does not work at all. The latter is caused by the IND_ADDEVENT command of input.device beeing not properly implemented.

I will try to fix all this issues today evening/tonight and commit the code (allthough I have a very limited network access now) so that the next nightly build will contain the newest and working version of USB HID class.

I have found an IRDA USB converter by my parents. It might be interesting to see whether it would work on aros :)

USB WiP release in nightly

2007-03-14T00:06:00.000+01:00

Howdy! Few days ago I have committed the WiP release of my USB stack to the aros repository (it's in /contrib/necessary/USB now) and made USB stack part of the nightly build. It means, it could be tested by everyone, provided that she/he has a PC with UHCI host controller.

At the very moment only the USB Mouse (including wheel support) should working. The USB tabled and UBS Keyboard are on the shedule. I expect to make them both till end of the week. Once done, I will concentrate on the OHCI driver and on fixing some issues in UHCI...

Yes, UHCI issues. For some reason, the UHCI controller does not change the "Connect status change" in UHCI port status register does not want to get set when I plug in new devices. I'm sure it's my fault somehow, but at the moment I have no clue what the reason is. Ah well, will be fixed. Stay tuned for more news :)

PS. I would like to thank Daniel Holmen for supporting me with an USB keyboard :)

Yet Another USB Status Update

2007-03-07T00:49:00.000+01:00

Hello there!

After my successful PhD promotion I'm back at coding AROS. I have just added support for interrupt pipes which are triggered by USB devices requesting interrupt handling. It means, that the HUB class may be and will be completed very soon now. Apart from that the UHCI class became some more USB Device and USB Hub emulation code.

What's up, doc?

2007-02-18T22:55:00.000+01:00

I have finally had my PhD exam. The day was full of stress and I was very excited about the whole thing (the lecture and exam itself). But everything went very well and I was scored with a "very good" note :-D

Robert Norris Interview

2007-01-31T08:37:00.000+01:00

Robert Norris, our new developer, has been interviewed by Paul J. Beel. You may find this interview here. Read it - it's really worth it :)

USB status update

2007-01-05T15:26:00.000+01:00

I think it's the highest time to let you know what's happening with my USB classes. I hope you do not the faith :) I still need some time to make the USB work on AROS, but some temporary test&debug version should be available soon.

Let me tell you something about the class hierarhy of this system. Currently, there are four standard classes and corresponding interfaces:

The root USB class maintains all devices and drivers in the system. It may decide what class has to be used with particular USB device. This one may be used e.g. to enumerate all devices in the system, find specific device, add the driver and many more.
The USBDevice class is a root class for each USB device attached to any bus in the system. It may be used to "raw" talking with devices, to ask for their general properties and general control over any device.
The USBHub class inherits the USBDevice class and extends it by methods and properties typical for Hubs. Every Hub in the system is either an instance of this class, or implements its interface.
The USBDriver interface provides a common way of talking with USB drivers (UHCI or OHCI, the EHCI driver will come in the future). Every driver inherits the USBHub class (every physical USB interface provides a "root hub") and implements the USBDriver interface.

The UHCI driver is close to complete, it provides control, bulk and interrupt transfers. Control and bulk are realised through the pipes attached to specified endpoints of specified USB devices. The missing thing are isochronous transfers - they will come in the future.

The other USB classes are halfway done, which means that they are operating but still not implementing all desired features. They will be still incomplete in the test&debug release but will be usable. The HID class, which is required by the bounty, will be written soon.

I'm sorry for such a huge delay and I'm terribly sorry that the whole USB subsystem is still incomplete. I have only one excuse which I have used already - lack of time and real life.

Stay tuned for more news... :)

Aaron Digulla interviewed

2006-12-08T13:54:00.000+01:00

Aaron Digulla, the AROS founder, has been interviewed by Paul J. Beel. You may find this very interesting article here.

I am not a $DeadBeef...

2006-12-06T00:23:00.000+01:00

...even if you've though so after almost five months of total inactivity here :) I have had a break with AROS for some time, due to the reasons you know (see my previous post). Apart from that I have finished writting of my dissertation and am waiting for the proofs. Once they're here I will attempt my PhD exam :-D

Working on two different projects at the same time did happen to be an extremenly uncomfortable case. Therefore, I've concentrated on the USB stack right now and I hope to make it work within near future. Apart from that I have added a DTM_WRITE method to our png.datatype (LUT , RGB and RGBA formats are supported). It means that you may now grab screenshots and save them in loseless PNG format.

regards,
M.

Something nice to tell you

2006-07-12T19:47:00.000+02:00

You might probably notice, that my AROS activity dropped a bit recently. Both of my current bounties are overdued and still require some time to complete. I kindly ask you to be patient.

Now, you may finally see the "reason" of my delays. Amelie Anna Schulz was born on eleventh july 2006 at 21:39. She weigh 3220 g and is 52 cm tall. Both mother and doughter feel really fine, just a bit tired, perhaps.

Now, I am really happy. So is my older daughter :-)

x86_64 Status update

2006-06-07T09:24:00.000+02:00

Hello everybody!
It was really a huge break in posting - I hope that you are still with me here :-)

The x86_64 kernel is moving forward, although my development has been slowed down recently. I have to complete my PhD thesis which is of the highest priority at the very moment. But I do my best and in my free time I continue writting the x86_64 kernel.

Recently, I have switcheed over to C++ language, in order to simplify my work (through templates) to use the object-oriented approach (so should it be on AmigaOS-like operating system) and to clearify the source code. It is not a complete C++ implementation - it does not include the STL and libstdc++ even. But it works pretty well.

One of the C++ ideas which I have borrowed from the C# language are events and generics. The EventHadler template is used to generate function objects which may call several different methods (or functions) at the same time. In order to clearify it, have a look at the following code:

  [...]
    EventHandler<char> ev;
    ev += Function1;
    ev += Function2;
    ev("C++ is nice");
  [...]

where the Function1 and Function2 take the char* as the only parameter. Both of them will be called with the "C++ is nice" string in the argument.

Stay tuned for more news :-)

ATI driver update

2006-03-22T19:50:00.000+01:00

I've just updated the binary version of my ATI driver. It draws all lines properly now (the clipping routine was broken) and does display all colors properly. You may download it from here.

Have fun.

Download ATI driver

2006-03-21T08:42:00.000+01:00

Hello!

After long and stressful fight with ATI driver and it's porely documented XFree86 sources, I have managed to make accelerated version of it. It supports accelerated line drawing, rectangles, filled rectangles and polygons. Additionally, it uses accelerated blitting between all bitmaps which reside in Video memory of Radeon card, if only they are in the same resolution (dunno, whether accelerated blitting mixed with color-depth scaling is feasible on Radeons, it was on NVIDIA though).

Comparing to the NVIDIA hidd, the only unaccelerated method is monochrome text drawing. It will be implemented soon. Later, I will finally implement routines for monitor detecting. Like in case of I²C bus, it might happen that the DDC2 will be implemented as a separate class.

If you want to give my driver a try, get it from here, and save it into SYS:Devs/Drivers directory of your native AROS. Additionally, you need the I²C classes in the same directory. You may get binary of I²C from here.

In order to make the driver work, you have to pass the following options to the kernel (from GRUB loader):

lib=DRIVERS:i2c.hidd lib=DRIVERS:radeon.hidd gfx=RadeonDriver

Have fun :)

I2C bus

2006-03-11T07:10:00.000+01:00

I like software developing! Few days ago I have found out, that my ATI driver may works incorrectly with TFT monitors. Due to lack of I²C bus the driver was unable to fetch the DDC2 data from monitor, and therefore could not even guess the type of device connected to the ATI card. I had two options - to implement I²C bus in ATI driver itself, or to provide a general solution. The former would be easier, the later would bie nicer.

The new directory: arch/common/hidd.i2c showed up in AROS source tree. It is a general implementation of the I²C bus for AROS. It will be definitely used in the ATI driver, but it is not the only purpouse of it. The hidd consists of two OOP classes:

1. The I²C bus class which is used by devices and abstracts every hardware bus into well known API. Using it as a superclass and overloading only two of its methods, one creates hardware specific bus driver.

2. The I²C device class which is used by software to communicate with devices over the bus. Using it as a superclass let's one to define new types of protocols, like SMBus for example, which use the I²C as a transport medium.

The specific driver class which uses the genmodule app from Staf Verhaegen (our talented AROS developer) may be as small as few hundred bytes in source, and less than two kilobytes in binary.

The ATI driver is one example of potential use. The I²C bus might be used aswell to communicate with hardware sensors, with TV cards (access the tuner through I²C bus) or even through parallel port (see this link for more details: http://oap.sourceforge.net/oap/i2c_para_module/i2c_para_module.pdf)
to talk with thousands of different IC's which provide the I²C interface.

Have fun with it. I will :-)

News on ATI driver

2006-03-07T09:05:00.000+01:00

Hello. Finally I do have some good news for all of you who are interested in using their ATI cards with AROS. The ATI driver works properly now, however it is still unaccelerated. That means, that at this time it is even slower than the legacy Vesa driver. But finally it works.

The code looks pretty ugly now - it is a mixture of AROS typical code and the XFree86 code (modified BSD licence). Since there are many workarounds needed and the chip initialisation is not trivial, I have just reused the XFree86 code here. Since there are some differences between AROS and XFree86 (in AROS, all bitmaps are stored in VRAM if available, and blits between them are done by 2D accel engine of the card), the rest of the code will be much more cleaner and logical. The driver cannot detect type of connected monitors at the moment and it assumes that they all are CRT's. It does work with my TFT connected through analog DB15. In order to change that, we need i2c bus implementation and support for ddc/ddc2.

I will commit the source into AROS as soon as I clean the code up (it's matter of two days in the worst case) and binary driver will show up somewhere here, including instructions how to use it with already installed AROS.

Stay tuned :-)

Cheap PPC alternative?

2006-02-21T09:13:00.000+01:00

The Amiga community lacks of good and cheap hardware to run their operating systems on. Allthough there are some efforts done in this area, the prices of this products (both current and future) are high. There is however another solution available, which is pretty cheap. The only disadvantage is lower speed of PPC CPU.

Imagine a regular x86 machine with PCI slots and a PPC card in one of them. If such PPC card would be able to initiate Bus Master transfers, it could control the PCI bus totally and thus would become a complete PPC system.

The Crescendo/7200 card from Sonnet is a PCI card with either G3 or G4 CPU running at maximal 500MHz. It consists of a PPC CPU, CPU-to-PCI bridge (well documented, used in another Amiga-like project too), memory and L2 cache. It was designed as an accelerator for PowerPC Macintosh machines. However, due to the beauty of the PCI bus design, it may be easily used in regular PC's, provided they have one 5V PCI slot available.

Recently, I have been talking with the engineer of this card about the internals of this accelerator. It came out, that running this card in PC is perfectly feasible. The x86 CPU would be responsible for booting the PPC, routing IO accesses (probably) and routing interrupts (that's for sure). It does not have to be the newest, fastest and expensive PC. It may be as well an old, passively colled 200MHz x86 machine. Such oldtimer would be more than enough as an IRQ router. It it would be faster, it could be used as an fast and effective coprocessor with it's own memory.

The costs? The card itself may be bought for approx. 100USD. Any old PC might be used as a PCI bus and interrupt router (less than $20). The exact price would be determined by the cost of all peripherals (including memory for both x86 and PPC).

Since all AmigaOS-like operating systems (OS4/MorphOS/AROS) are fast and responsive even on slower CPU's. That and the fact that there would be an underlying x86 as a coprocessor ready for use, would provide very nice and effective PPC platform for Amiga operating system. Let's go dual CPU, let's go Bi-Endian :)

If only any team would like to have it.... ;)

Message from the bottle

2006-02-07T07:23:00.000+01:00

The debug output catched by 64-bit qemu showed today the following output (from emulated serial console):

[BOOT] AROS Bootstrap.
[BOOT] Command line '/aros-x86_64 vesa=640x480x16'
[VESA] module (@ 0010A4BC) size=2144
[VESA] Module installed
[VESA] BestModeMatch for 640x480x16 = 111
[VESA] Module uninstalled
[BOOT] GRUB provides the following memory map:
[BOOT] 0000000000000000 - 000000000009FC00: 1
[BOOT] 0000000000100000 - 0000000007F00000: 1
[BOOT] Setting up descriptor tables.
[BOOT] Mapping first 4G area with MMU
[BOOT] Loading kernel
[BOOT] GRUB has loaded 4 files
[BOOT] * module asmsupport.o
[BOOT] * module aros.o
[BOOT] * package kernel.pkg:
[BOOT] * module aros.o
[BOOT] * module asmsupport.o
[BOOT] * module aros.o
[BOOT] Loading asmsupport.o
[BOOT] Loading aros.o
[BOOT] Leaving 32-bit environment. LJMP $8,$0000000000F80000
--------------------
[AROS64] 64-bit AROS. Copyright (C) 2006 The AROS Development Team. All rights reserved.

Please note, that the bootstrap is now capable to switch VESA mode on demand (best mode match of command line argument), parse modules loaded by grub and even parse packages of modules. :-)

1000 visits

2006-02-03T20:55:00.000+01:00

Today the counter on my blog site reached the magic 1000. I'm am really impressed by such amount of visits on my page :) Thank you.

Bootstrap seems to work :-D

2006-02-02T00:49:00.000+01:00

Hello there!

No, I did not made the 64-bit AROS working natively. Not yet... Instead I was working on 32-bit bootstrap code.

Since the BIOS of x86_64 PCs boots into 16-bit mode and GRUB switches from 16-bit mode into 32-bit one, the new kernel for AROS should be a 32-bit ELF executable. Therefore, the idea of bootstrap was born.

The bootstrap is a small 32-bit application which is loaded by GRUB. It is responsible for setting an environment for 64-bit system up, like the descriptors and MMU page tables. It contains also an ELF-relocator, which is used to load embedded 64-bit ELF image of kernel into arbitrary memory location. The same relocator is used to link any additional modules loaded by GRUB with the kernel.

And you know what?... The bootstrap works already :-D

It's not an achivement worth mentioning (the binary of bootstrap is less than 12KB), but I felt that I have to share my hapiness with you.

I'm alive and 64-bit

2006-01-25T08:38:00.000+01:00

After a long break here I am again!. And I have some good news aswell :-)

Few weeks ago I made my brand new x86_64 system working. It was really a fight. Within only few days I've installed several SuSE distros - all of them failed with my SATA-2 harddrive. It was a nightmare.

And then, finally, I have discoverred the problem. The DSDT ACPI table which is stored in BIOS of my A8N-VM CSM mainboard is simply broken. It contains non-ASCII character in one name, which is illegal. After short fix (fixing the character, disassembling the table, sort of programming again, in order to make the code cleaner and then comiling again - it all took 30 minutes, not more!) and adding the table to initrd image, everything started to work perfectly.

The 32-bit aros compiles well on this machine, even using the gcc4. I've tested only hosted so far, but I would not expect any issues with the native.

The 64-bit Aros is not yet done (sight, who would expect it to be done within three weeks). All types and machine-specific includes are done now. Thanks to that, some libraries compile just fine, others don't.

Right now I'm working on the bootstrap code. It is a small 32-bit application executed by GRUB, which prepares a clean 64-bit environment for native AROS. Additionally, it will allow loading of external libraries and linking them with aros kernel during a boot. Therefore, x86-64 kernel may be as small as bootstrap+exec+some addons, and the rest may be linked with it later. In the future, such bootstrap code may be easily extended in order to support some VESA mode selection.

PS. And recently, I've finally completed my first draft of my PhD disseration :-).

SFS Benchmark

2005-11-26T02:23:00.000+01:00

After my last updates (checkout and test, please) SFS became stable enough to let it work on a real hardware, on native. As a reminder, I will firstly show the raw performance of my harddrive running through ata.device:

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Read from SCSI: 6805708 bytes/sec
[...]
Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Read from SCSI: 57461964 bytes/sec

Now, the SFS partition has been created with 1 sector per logical sector (kind of standard on Amiga) and with all debug turned off. The resulting performance is following:

Testing directory manipulation speed.
File Create: 17744 files/sec
File Open: 26498 files/sec
Directory Scan: 40269 files/sec
File Delete: 10258 files/sec

Seek/Read: 6424 seeks/sec

Please note that the slowness of file operations (create/open/dir scan/delete/seek) is due to enormous amount of context switches. I will probably improve it later, so expect it to be twice as fast soon. Now the real performance:

Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 11043136 bytes/sec
Write to file: 13080896 bytes/sec
Read from file: 12458496 bytes/sec

Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 25875456 bytes/sec
Write to file: 31401984 bytes/sec
Read from file: 16304640 bytes/sec

Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 51707904 bytes/sec
Write to file: 62603264 bytes/sec
Read from file: 15536128 bytes/sec

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 53837824 bytes/sec
Write to file: 31686656 bytes/sec
Read from file: 77266944 bytes/sec

It should be noted, that even with 512-byte buffers the performance is pretty good (11MB/s in the worst case) thanks to a nice cache handling and read-ahead of the SFS. The numbers are of course a bit disturbed (noone will belive in 77MB/s transfers :)), but give some nice hint about the speed of the SFS. Hmm, isn't SFS nice?

PS. I have tried to stress SFS partition a bit, copied many times, benchmarked and such :) No errors have been reported by SFS. Therefore I consider it as a pre-release version (beta was yesterday :)))

Wanna try out the SFS?

2005-11-25T23:54:00.000+01:00

Do you want to try my version of Smart File System out? Go here (or simply click on the title of this post) and enjoy.

PS. Have I already mentioned, that this version is free of checksum-bugs? Theoretically it should work as stable as the original SFS version 1.84. In practise it may behave better, since I've already fixed some issues which were present in the original code.

Yuppi!

2005-11-25T08:02:00.000+01:00

I have found and fixed a nasty bug in Smart File System. The filesystem was never setting the lock/handle type to ST_ROOT. Therefore, plenty of dos.library's functions failed to work. That was the reason why the C:Dir and C:List commands failed to work on SFS partition, too.

I've fixed this issue now, and the filesystem seems to work properly now. Well, actually it still has some problems with checksums on admin blocks (I've copied my whole SYS: to the SFS partition and I saw five or sixchecksum errors), but I hope to solve it really soon.

Stay tuned :)

Smart Filesystem

2005-11-22T12:32:00.000+01:00

Tonight, I have managed to compile the Smart Filesystem (SFS) for AROS! The whole internals are already there, but the filesystem cannot do very much yet. It detects a formatted (with AROS!) partition properly, allows to format a partition and to create directories on it. The rest doesn't work properly yet.

The SFS will be able to work in both BigEndian and LittleEndian modes, allowing maximum performance on desired platform and, by the same time, the compatibility with other SFS variants. Additionally I will try to clean the code up (yes, it is messy right now) and fix some bugs present in the code.

At the end, the SFS sources for AROS (they are already in our SVN repository, check the contrib/SFS) will be synced with the SFS repository on the sourceforge.net. If the need arises, this version of SFS will be ported to the m68k AmigaOS.

64-bit world. Waiting for hardware.

2005-10-13T23:21:00.000+02:00

Well, few days ago I've applied for the x86-64 bounty. Hopefully the Epox mainboard together will nice athlon chip will arrive within the next two weeks. I have to grab all components I need by this time.

Getting 64-bit native into work may be a bit complex but at the very moment I see no reason for it to be undoable. There will be many many fixes to aros required. Some pieces of code will have to be made APTR/IPTR aware (we happen to use ULONG variables to store pointers somewhere in our code nowadays). But it should work.

No. It will work!

I guess I will try to implement some parts of my RFC number 01 there, in order to make kernel really modular. The local APIC of cpu will be used (all 64-bit AMD and Intel CPU's do have it anyway). It may also turn out, that I will have to apply for Bounty #32 just by the way :)

AROS can detect my ATI card now

2005-10-13T23:15:00.000+02:00

There is a progress. The driver just finds my Radeon card and detects amount of it's GFX memory. Of course it still uses the nasty busy loop usleep microsecond delays, but I should turn it into using UNIT_MICROHZ of timer.device within this evening :)

No commit will occur since the driver is still highly unusable.

ATI bounty

2005-10-07T22:05:00.000+02:00

I have taken the ATI Bounty recently. I hope that the deadline of this bounty will motivate me a little bit.

The work will be splitted into several stages, whereas upon completion of every stage a binary driver may be published and the source will be svn-synced with main AROS tree. I hope some of you will be then able to test it and report any issues met.

I have abandoned the idea of universal ATI driver for all cards from this vendor. Instead, the radeon class will be implemented as the first one :). The support for R128 and other ancient models will come a bit later.

It's time to create new project in my Eclipse IDE :)

Beta testers needed

2005-08-18T00:41:00.000+02:00

I have just fixed some annoying bugs in nforce NIC driver. It should behave stable now and not hang whole arostcp if overflooded with packets. Currently the driver puts some debug output about usage of RX and TX queues - 4 messages within every second.

I have been trying to flood my aros machine and my driver with ping. Unfortunatelly 100MBit network was not sufficient to break the driver down. Occasionally, I have tried to flood the attacking machine with pings sent from my aros box, without success too :)

Out of almost 2 millions of packets used in this battle, something like 500 have been lost. Really a lot, just because of my debug output displayed on vga16-driven screen (the slowest driver we have). Some packets are lost too due to the gfx benchmark which I started occasionally at the same time.

I need betatesters now. If you can, please help. I've attached a link to the newest version of driver (binary file to be used in aros directly).

Victory!!!

2005-08-15T23:45:00.000+02:00

I have just made my nforce NIC driver working! Horay! After few days of intensive developing my AROS machine may ping other computers, it responds to external pings properly.

Additionally, I have tested our small ftp client over local network. It performs very well. AROS manages to receive data from my old 200MHz PPC server at 7.5MB/s (a bit faster then linux). In order to confirm the quality of transfer, I've calculated md5sum of 20MB file before and after transfer - they are the same.

The driver is still not perfect. For example, it survives only one minute of intensive ping flood and then dies. It is caused by completely filled RX ring, and will be fixed soon.

nForce ethernet update

2005-08-12T21:38:00.000+02:00

After successful switch to Eclipse IDE (see image) I gave up using the nforce ethernet binary module provided by NVIDIA. Instead, I have used the forcedeth module from linux kernel. It has one disadvantage - the whole nForce ethernet driver has to be GPL'ed. There are however much more advantages.

The driver was reverse-engeneered by kernel hackers. They wrote documentation for it and even fixed some bugs. Moreover, NVIDIA provided recently some patches for this module (sigh!) adding eg. gigabit ethernet support.

The nForce ethernet driver progresses quickly. Since whole source code is available and it is well documented, I may just adapt linux source to SANA-II standard. Currently, only two things are missing. One is the ring buffer support, the another is full SANA-II interface. Nevertheles the development should go way faster than before.

Out of funds...

2005-08-04T16:03:00.000+02:00

Well, there should be next status update of ATI driver. But there isn't one. I hope it will change soon.

Well, the fact is, my financial balance does not allow me to concentrate on ATI driver right now. I will focus on the nforce ethernet driver in order to make this extremely delayed bounty complete. Then I will eventually continue on ATI driver. The speed of development depends strictly on the size of Bounty #34. If the bounty is low ($5 now) I work slowly - my family doesn't see any benefits on spending time for development. If bounty rises up, my family will let me code. I wrote the nVidia driver within two months, whereas basic driver (with very few acceleration) was ready within three weeks.

Well, I look right now like an awful bounty-hunter. Sorry for that. But on the other hand I have to complete my PhD thesis, find new job, get some money, live, eat and such :)

Small sweet candy in this bitter post is my current AROS-TODO:

nforce ethernet driver
ATI driver
USB stack
CABOOM (OOP proposed by Fabio - way faster and simplier than current one)

ATI driver status update

2005-07-22T23:19:00.000+02:00

I've just managed to re-use the code, which is remotely common among all video drivers in AROS (well, at least the same is in nVidia.hidd). So at the moment the ATI-compatible card is searched for and, if found, the memory mappings for framebuffer and MMIO are perpared. ATI driver is currently 12KB (KiB?) long and detects all devices supported - from old Rage128 up to the newest R420 GPU's.

Well, I will have to double the driver, since the Rage128 has to be handled in different way compared to the Radeon family. I hope only that both parts will coexist somehow and share as much code as possible.

Anyway, the next status update should happen soon - and then my ATI card should already show something. Perhaps even Wanderer screen :D

Comment me

2005-07-22T21:39:00.000+02:00

I've just enabled anonymous comments. Fell free to use this ability.

The ATI driver

2005-07-21T09:18:00.000+02:00

Today I have started collecting the documentation and sources needed to make an ATI.hidd - video driver for all radeon cards. I hope to start developing soon (parallel with my old pending NVIDIA ethernet driver).

Most likely it will be quite similar to the nvidia.hidd - that is all bitmaps will be stored in memory of graphics card and from there blitted directly to screens. It should give nice speed boost over the x11 driver which basically uses one big framebuffer and few additional KB of video memory for cursor and line buffers used to do blits with CPU.

As a nice addon I will perhaps add finally AGP support to the pci classes - at least ability to change the agp mode.

EDIT: I've just got my ATI card. It means that the development may start even tonight :)

The very first entry

2005-07-19T07:24:00.000+02:00

Impressing, my own blog. Let's start it :)