Posted tagged ‘Symbian’

Attempting to boot Symbian^3 on the TMDSEVM3530 : Take 2

August 1, 2011

I’ve just received the USB/RS-232 adapter (which is based around the FTDI FT232BM chipset, and supported under Linux without any additional work), and connected it to the board’s UART1/2 port and my laptop using the null modem cable supplied with the board.

For the curious, dmesg reports:
[ 177.992226] usb 2-2: new full speed USB device using ohci_hcd and address 3
[ 1090.655407] usb 2-2: USB disconnect, address 3
[ 1160.036191] usb 2-2: new full speed USB device using ohci_hcd and address 4
[ 1160.656891] usbcore: registered new interface driver usbserial
[ 1160.656938] USB Serial support registered for generic
[ 1160.659703] usbcore: registered new interface driver usbserial_generic
[ 1160.659709] usbserial: USB Serial Driver core
[ 1160.676061] USB Serial support registered for FTDI USB Serial Device
[ 1160.677502] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[ 1160.677628] usb 2-2: Detected FT232BM
[ 1160.677632] usb 2-2: Number of endpoints 2
[ 1160.677635] usb 2-2: Endpoint 1 MaxPacketSize 64
[ 1160.677639] usb 2-2: Endpoint 2 MaxPacketSize 64
[ 1160.677642] usb 2-2: Setting MaxPacketSize 64
[ 1160.694632] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 1160.696459] usbcore: registered new interface driver ftdi_sio
[ 1160.696466] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

sudo lsusb -v reports:

Bus 002 Device 004: ID 0403:6001 Future Technology Devices
    International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0403 Future Technology Devices
     International, Ltd
  idProduct          0x6001 FT232 USB-Serial (UART) IC
  bcdDevice            4.00
  iManufacturer           1 FTDI
  iProduct                2 USB-to-Serial
  iSerial                 3 FTE2QSKA
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower               44mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 USB-to-Serial
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
(Bus Powered)

We can confirm that everything works by running cat /dev/ttyUSB0 from a BASH session, and powering on the board:

tyson@UmBongo:~$ cat /dev/ttyUSB0 

Texas Instruments X-Loader 1.47 (Jan 14 2011 - 15:43:28)
Starting X-loader on MMC
Reading boot sector

212836 Bytes Read from MMC
Starting OS Bootloader from MMC...
Starting OS Bootloader...

U-Boot 2010.06 (Jan 14 2011 - 15:43:45)

OMAP3430/3530-GP ES3.1, CPU-OPP2 L3-165MHz
OMAP3 EVM board + LPDDR/NAND
I2C:   ready
DRAM:  128 MiB
NAND:  256 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial
Read back SMSC id 0xffff0000
Die ID #2f7c000400000000040365fa1801900d
Net:   smc911x-0
Hit any key to stop autoboot:  0
mmc1 is available
reading boot.scr

421 bytes read
Running bootscript from mmc ...
## Executing script at 82000000
reading uImage

** Unable to read "uImage" from mmc 0:1 **
***** RootFS: /dev/mmcblk0p2 *****
Wrong Image Format for bootm command
ERROR: can't get kernel image!
OMAP3_EVM #

Obviously, since I renamed the uImage file on my Android SD card from earlier (to kuImage), the board fails to successfully boot Linux.

After downloading and installing CuteCom (a Qt-based serial console utility), and configuring it to communicate with the board at 115200 baud, using 8 data bits, and without parity or software/hardware handshaking, the help command command can be issued to the board’s bootloader – which results in:

OMAP3_EVM # help
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dhcp    - boot image via network using DHCP/TFTP protocol
echo    - echo args to console
editenv - edit environment variable
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
false   - do nothing, unsuccessfully
fastboot- fastboot- use USB Fastboot protocol

fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fsinfo  - print information about filesystems
fsload  - load binary file from a filesystem image
go      - start application at address 'addr'
help    - print command description/usage
i2c     - I2C sub-system
imxtract- extract a part of a multi-image
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls      - list files in a directory (default /)
md      - memory display
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub-system
mtest   - simple RAM read/write test
mw      - memory write (fill)
nand    - NAND sub-system
nandecc - switch OMAP3 NAND ECC calculation algorithm
nboot   - boot from NAND device
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
showvar - print local hushshell variables
sleep   - delay execution for some time
source  - run script from memory
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true    - do nothing, successfully
version - print monitor version
OMAP3_EVM #

At this stage, it’s necessary to remove the SD card from the board, and attempt to copy a Symbian ROM image to it.

Unfortunately, after installing Android, it’s also necessary to resize the ~70MB primary partition in order to make it fit. The quickest way to do so would probably be to use GParted and a USB card reader, if you’re using Linux under a virtual machine (as opposed to rebooting into a Wubi installation, in order to use my laptop’s internal reader, which I was initially tempted to do).

An SD card prepared using the the tool from the aforementioned archive contains an x86 partition table, and 3 partitions (a 70.57MiB FAT32 boot partition, a 941.31MiB Ext3 root partition, and an 870.71MiB FAT32 data partition).

Since it is possible to reconstitute these partitions using that tool, and since they’re unnecessary for the Symbian Platform, we can remove the root and data partitions, and then resize the boot partition to be 512.97MiB in order to store the Symbian ROM with some allowances for future growth.

If that process fails with “GNU Parted cannot resize this partition to this size. We're working on it!“, then:

  • Mount the boot partition (usually sdb1)
  • Copy all of its contents to a convenient location
  • Unmount the partition
  • Remove the partition using GParted
  • Create a new 512.97MiB FAT32 partition with 0MiB free space preceding it
  • Mount the newly created boot partition
  • Copy the “boot.scr“, “MLO” and “u-boot.bin” files from earlier to said partition
  • Unmount the partition – if you’re using a VM, and want to copy the ROM using the host OS, instead of the guest OS

Now, we can attempt to copy “beagle.rom.img” from the “ROM Images” directory to the root of the boot partition as “uImage“, unmount the partition, and then insert the card back into the board.

Unfortunately, at this stage, although several LEDs on the board illuminate, I can’t see any output from it on the serial console – which leads me to suspect that the bootloader and firmware on the card isn’t being loaded. Testing using the Windows CE card lends credence to that thought.

Attempting to copy the x-load.bin.ift file from /OMAP35X/Boot_Images to the root of the boot partition also yields the same result.

After quickly making some raw sector dumps of both SD cards, I suspect that the structure of the x86 MBR/partition table, and the location of the boot partition is a factor in the ability to boot the board.

For comparison, file reports the following, for the Windows CE card:

dump: x86 boot sector, code offset 0x0, OEM-ID "MSDOS5.0", sectors/cluster 64, root entries 512, Media descriptor 0xf8, sectors/FAT 236, heads 64, hidden sectors 135, sectors 3858489 (volumes > 32 MB) , serial number 0x61636637, unlabeled, FAT (16 bit)

For the modified Android card, this is reported, instead:

dump2: x86 boot sector; partition 1: ID=0xb, starthead 32, startsector 2048, 1048576 sectors, code offset 0xb8

With that in mind, since I’ve got a complete raw backup of the Windows card that I can restore later; I’ll remove the EBOOTSD.NB0, MLO, and NK.BIN files, and copy over the Android boot files (modulo the Linux kernel binary), plus a Symbian ROM image.

Lo and behold, we now have X-Loader and U-Boot, which attempt to boot our “Linux” kernel into 0x82000000, but seem to get stuck afterwards.

After getting this far, I’ll probably take a break, and see if manual intervention at the bootloader prompt gets us any further, later. 🙂

Advertisements

Attempting to boot Symbian^3 on the TMDSEVM3530 : Take 1

July 31, 2011

Given that I’ve recently obtained a Texas Instruments TMDSEVM3530 development board (which is supposedly a cousin of the slightly-more-popular BeagleBoard, from what I can gather), thanks to Andrew Back (and DesignSpark), I thought that it’d be interesting to see if I could get Symbian^3 running on it.

I’ve got another, more detailed post sitting in my WordPress drafts, but I thought that I’d share some rough notes that I managed to salvage from an unsaved document, prior to yet another ATI driver-induced BSOD moment, in the meantime.

Note: Everything mentioned here is the hypothetical product of “thinking out aloud”, and I can’t guarantee that anything mentioned here will actually work, or that your expensive development board won’t be reduced to a smouldering pile of rubble.

I also recommend obtaining a USB/RS-232 cable, if you haven’t either already got one, or you’re unfortunate enough to have a “modern”/”legacy-free” PC without RS-232 serial ports. Unfortunately, mine’s currently in Paris according to FedEx, so I’m working blindly for the moment.

It’s also probably a good idea to make either a copy of the individual files from the Windows CE demo SD card that ships with the board, or create a raw disk image of its sectors using WinImage, dd or a similar tool.

With that in mind:

  • Download and unpack the ROM Images.zip archive from DropBox
  • Rename or move the NK.BIN file in the root directory of the aforementioned SD card, so that it can be restored later
  • Copy either beagle.rom.img or wildducks_demo.rom.img from the ROM Images directory to the root directory of the card as NK.BIN
  • Unmount the card and insert it into the board’s SD card slot
  • Attempt to boot the board…

It’s probably also necessary to replace the MLO and/or EBOOTSD.NB0 files with new ones, although I haven’t got around to figuring out what to replace them with, yet.

Inserting the card into the board’s SD Card slot will cause it to display a splash screen containing 4 coloured squares during the boot process – but seemingly causes it to do little else (unsurprisingly).

At this stage, if you rely on using the Windows CE card to test booting from SD, it’d be a good idea to reinstate the original NK.BIN file.

Another approach would be to obtain another SD card, use the shell script contained within the “OMAP35x EVM” package from this page to install Android on it, and then replace the uImage file (after backing it up) with one of the files from ROM Images.

However, doing so results in the board’s LCD being blank during boot.

The chances are that at this stage, you’ve either:

  • Irreversibly damaged your board – unlikely, since booting the WinCE card works successfully
  • Got stuck in a bootloader loop somewhere – very likely, according to a wild guess
  • Successfully achieved a boot of the OMAP35x evaluation board using a ROM that obviously wasn’t intended for it – very unlikely

If you’re unable to debug the board using one of its serial ports afterwards, then the most that you can do is either stare at 4 LEDs, or replace the uImage file with the original version and play with an unstable build of Android.

With a serial cable, and the board’s bootloader console, you could probably attempt to try a modified version of the Quick Start instructions from the old Symbian Wiki.

If those don’t work, then attempting to load the ROM image at one of the memory locations mentioned in this QNX-related page, or at the Wild Ducks page might (if you’re lucky).

I’ll probably have another play, once my cable arrives…

Here We Go Again

January 13, 2011

As I compose this post, I realise that I’m extremely fortunate to have made it this far through life – especially when considering others living in developing countries, for instance.

After all – although I haven’t got the support of a wealthy, stable family, I’ve still got:

  • Food and potable drinking water
  • Heating, electricity and other necessities
  • A dry roof over my head
  • Broadband Internet connectivity
  • Good friends, and a handful of family members who mean well – even if I don’t always agree with them

In just over 6 months from now, I’ll have reached the 2 decades old milestone – which is somewhat worrying to contemplate; although I’m cautiously excited about future possibilities.

With that in mind, I’d like to reflect on the happenings of 2010, and the beginning of 2011.

In many aspects, 2010 was just another unspectacular, run-of-the-mill year – a monotonic continuation of 2009, to be blunt; although it brought change and progress in many ways.

However…

From a positive perspective, it was a good year for academia, software development, travelling, and personal relationships, amongst other things.

  • I was able to return to London, shortly after my 19th birthday in order to spend some time volunteering at the Symbian Foundation – details of what I did are available as part of my LinkedIn profile.
  • I received a number of references from several people, which were fairly useful (thanks!)
  • I finally managed to obtain a part-time, intensive placement on a 4-5 year long Computer Science course at the University of Bradford – and completed my first semester, shortly before Christmas 2010.
  • I learned the fundamentals of Java, and managed to write a number of C++-based applications using Qt – some of which I published the source code for on BitBucket.
  • Towards the end of 2010, I released a modified version of Sebastian Reichel’s ISI dissector for Wireshark with support for USB-encapsulated packets. I have since refactored the USB handling code and integrated it into the main dissector, in addition to writing new dissectors for the SIM, GSM Stack Server and Supplementary Services resources; and worked with Sebastian on incorporating these changes into his version successfully.
  • I also managed to reconnect with several people whom I haven’t heard from in a while.

But…

From a negative perspective, it was a bad year for older personal projects, family and financial-related issues, injuries, and the Symbian Foundation.

  • The server hosting DNS records for one of my domains (house404.co.uk) and Web services for several projects, which Sjors Gielen generously provided access to for several years finally succumbed to hardware failure – so I’ve lost some old data, some of which was of dubious utility, and some of which was fairly useful.
  • In November, I was unfortunate enough to have been involved in a hit-and-run traffic accident, whilst returning home from the supermarket in Boroughbridge. Thankfully, I sustained only minor injuries (from which I later fully recovered); although the suspect was never identified, after filing a police report.
  • In December, as a result of the harsh realities of the current economic climate, and decisions from handset manufacturers to slowly withdraw from the Symbian Foundation, the decision was made to effectively cease operations – which left community members such as myself to pick up the pieces.

I remain pessimistically hopeful that things improve in 2011.

Thanks to everyone who’s helped in various ways; provided advice and interesting discussion points; and otherwise persisted with me so far.

Hopefully, I’ve been useful to others in some way, too – and I’m glad, if that’s the case.

An ISI/PhoNet-over-USB dissector for Wireshark

December 25, 2010

Whilst working on Project Iris, I have found Sebastian Reichel‘s Wireshark dissector plug-in invaluable for identifying the content of ISI packets generated by my handset.

However, it relies upon the ability to use the Linux PhoNet stack – which isn’t always possible under certain circumstances.

For example, the stack may not be available at all under the running Linux kernel version; or the USB device generating ISI traffic may be connected to a virtual machine running a Windows-based application – which is obviously invisible to the host’s network stack.

With that in mind, I’ve decided to release a modified version of the aforementioned plug-in on BitBucket (in source code form only, at present), and I’ve uploaded a sample trace file to test it against, here.

Rough instructions for building it against an SVN release version of Wireshark under Fedora are provided in the repository; as are a copy of my colouring rules for working with USB and ISI traffic.

At present, the dissector has the following features:

  • Basic support for dissection of ISI/PhoNet packets encapsulated in USB framing (AKA “CDC PhoNet”) – for USB CDC_DATA class packets
  • Basic support for dissecting ISI GPS and SIM Authentication packets (inherited from the original version of the dissector)
  • Basic support for identifying specific types of CDC_DATA packets (works for ISI, PPP and AT/Hayes commands)

However, there are also a number of limitations and bugs – especially when compared to the original version:

  • ISI packets encapsulated in Linux Cooked framing are currently unsupported
  • Due to lack of heuristics, this dissector will override the PPP dissector (and the ISO/IEC 13818-1 dissector) when working with USB trace files
  • The length indicator may not always be accurate – although a lot of effort was spent on attempting to make it work

When working with this dissector, I recommend either using the isi.usbtype == 0x1b display filter, or individually filtering out various other types of USB packets, in order to avoid confusion.

For curious folks, a screenshot of the dissector in action is provided:

I hope that others find this useful for something.

That aside, I’d like to thank the following:

  • Chris Maynard for his USB patches (especially the CDC Ethernet one), which were useful for figuring out how to integrate with the USB dissector
  • Sebastian for providing the initial version of the dissector
  • William Roberts for providing the Nokia N73 that’s serving me well as my primary handset (and its USB cable, of course), and for persisting with me whilst I grappled with various stupid mistakes during learning C and C++

I wish readers a happy Christmas, and all of the best for 2011! 🙂

Lighting the Mines

November 29, 2010

With the recent news of the Symbian Foundation board of directors deciding to gradually reduce the scope of the organisation to that of a mere licensing body, and talk of the community Websites closing imminently, there has understandably been somewhat of an uproar within this small-yet-vocal community.

A case in point being a post and poll from Julien Fourgeaud on his blog, which spawned this frantic discussion on the DevCo mailing list.

Despite reassurances of plans to make content available to the public (including mailing list posts if desired, from what I’ve been told), there’s still a great deal of uncertainty over what the future holds for not only the codebase and supporting resources, but for the incredible community that has coalesced around it over the past 2 years or so.

Because I consider the Symbian Platform codebase to be a rich, valuable resource for learning from and working with; and believe that it deserves to be publicly accessible in some way for both current developers, and for future generations, I have taken an interim step to preserve a large subset of it.

Over the past few days, I’ve started a Google Code project that initially aimed to preserve the “incubation project” repositories primarily, as they were the most vulnerable due to being transient in nature; although it now also hosts copies of the Kernel & Hardware Services, and Classic UI FCL repositories.

There’s obviously no point in listing every single repository here, although the majority of the “incubation project” ones should be covered; and I’ve also provided copies of various licensing documents for future reference.

With that in mind, I’ve kept things open-ended – because I don’t know how others will want to use these resources.

If others feel like working within the repositories and using the project’s wiki and issue tracker resources, I’m happy to open them up.

Of course, if others feel like downloading or cloning the repositories to fork them, I won’t complain – after all, it means that the codebase continues to spread in a healthy manner!

If there’s interest, I’m also willing to work with the Symbian Foundation team on a transition/temporary migration plan, whilst the situation with Nokia is resolved.

All aside, I hope that others enjoy using these resources as much as I did making them available; and I wish everyone involved during these difficult times the best of luck! 🙂

Project Iris: Affordable, Instant Connectivity for Syborg/QEMU

November 1, 2010

Apologies for not updating here as often as I wanted – although in order to keep things concise, I won’t detail the reasons for my hiatus in this post.

That aside, whilst I can remember the details, I’d like to share a proposal for a novel (in my humble opinion – but I’m prepared to be corrected) method of potentially using unmodified, off-the-shelf Nokia handsets as a modem under Symbian OS running on QEMU.

Please note that I have so far been unable to implement this, or test certain individual components (e.g. the Linux PhoNet stack); although I believe from the research that I’ve done that individual components should work in isolation.

Additionally, this isn’t intended to be a competitor to the excellent Wild Ducks project, or the ad-hoc efforts surrounding getting regular modems utilising Hayes/AT commands to work, either. (It’s for folks who for whatever reason either can’t afford to acquire a fully fledged Wild Ducks set-up, don’t want to commit themselves for the long-term, or just want a quick-‘n’-dirty way to test stuff that requires network connectivity).

With that in mind, I’ll introduce the architecture diagram, and hopefully try to provide further details – because a picture is apparently worth a thousand words:

Click to view full size

The system itself consists of the following components, in no specific order:

  • A version of QEMU with customisations specific to the Symbian Platform, as detailed in my ancient post on the Symbian Blog – and a few others, since then!
  • Two brand new components, which will be described in further detail later (the TI SSI bus “pseudo-modem” and the raw PhoNet-to-SSI bridge)
  • The Linux PhoNet protocol stack, which was contributed to the mainline Linux kernel by Nokia on behalf of members of what was once known as the “Maemo Computers” department (if memory serves correct)
  • Your favourite Nokia device, providing that it supports USB connectivity and the “PC Suite” profile – since that’s how we can access certain baseband services via PhoNet! (A well-kept secret, so it seems)…
  • The Symbian Platform (which consists of the Symbian OS, UI framework, middleware and other components) and the baseport – Syborg, in the case of Project Iris
  • Nokia’s baseband “TSY” (telephony support plug-in), which should work in conjunction with a well-designed TI SSI bus “pseudo-modem” and the raw PhoNet-to-SSI bridge to simulate the presence of a real Nokia baseband by proxy 🙂

The most interesting components are the TI SSI bus “pseudo-modem” and the raw PhoNet-to-SSI bridge, which are pivotal to making this thing work.

The raw PhoNet-to-SSI bridge can potentially either be integrated into QEMU, or left standalone –  although designing the IPC mechanism for the latter use-case is left as an exercise for the reader.

Communication with the device could occur via either a /dev/phonet0 device node (if such a thing existed, but according to this IRC log, it seems that it doesn’t under certain circumstances), or directly bound low-level datagram/pipe sockets to communicate with the user’s handset via raw PhoNet/ISI packets encapsulated in USB frames.

Obviously, the raw PhoNet-to-SSI bridge will encapsulate and decapsulate PhoNet packets that are transmitted/received by the handset into Texas Instruments-proprietary SSI frames for consumption by the “pseudo-modem”.

The “pseudo-modem” works in conjunction with the Nokia TSY (as mentioned earlier) and the raw PhoNet-to-SSI bridge; and will be a brand new, integral component of QEMU. It has minimal state of its own; and other than creating the illusion of a genuine Nokia/TI modem’s presence, it serves solely to transport packets between the bridge and the TSY.

Finally, the interaction between the TSY, network and telephony stacks and other parts of Symbian OS are extensively documented elsewhere.

For those curious about the title, the “instant” bit refers to the fact that as of recent versions of the Linux kernel and NetLink stuff, things should Just Work™ when a PhoNet device is connected (according to this page and this presentation from 2009), and that limited hardware knowledge is necessary to use one – just plug it in and switch it on.

The “affordable” bit refers to the fact that Nokia devices are relatively low-cost, easy to obtain, and plentiful (unlike specialist hardware such as the BeagleBoard and standalone GSM modems – as great as they are, for example).

A Quick-ish Update

August 23, 2010

Since folks have asked nicely, I thought that I’d compose a quick post, whilst being in the process of making last-minute preparations for a trip to London.

The grand plan is that I’ll be stopping in York with a relative tonight; and then taking a coach down to London for roughly two days, in order to spend some time at the Symbian Foundation as part of an ongoing volunteering arrangement.

I probably shouldn’t discuss the agenda at this stage, although the arrangement thus far is that I’ll be meeting with either William or Sebastian on the 24th to continue working on enhancing the developer documentation, in addition to doing something (hopefully exciting!) with the build team.

On the 25th, I’ll have an opportunity to catch-up with others, and meet folks whom I haven’t already seen (including Victor); plus I might have time to do some sightseeing on the London Eye.

Finally, I also have some (mostly negative) news regarding my ongoing university application saga to share, upon my return.