UBoot Second Level Bootloader (UB2LB) update

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
TMDS Type — Internal
[ATI] Secondary:
Monitor — AUTO
Connector — VGA
DAC Type — Primary
TMDS Type — External
[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(4096×16@4) = 0
[ATI] AllocBitmapArea(64×64@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

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

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-

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: ######
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

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.

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:

  1. Writing the second level boot loader
  2. Making AMCC440EP aware Kernel (with kernel.resource as it’s interface)
  3. Porting the core system
  4. Testing and debugging
  5. Porting the contrib/necessary (including the USB stack and TCPIP stack)
  6. Testing and debugging
  7. 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 ๐Ÿ™‚