Custom initrd for NX


I’m coming from a Xilinx background where there is no real toolchain for initrds and it’s pretty open-ended what you can boot.

With the NX and Jetson/Linux_for_Tegra, it appears there is some requirements for a custom initrd. My intent is to replace the initrd in QSPI flash and use that as my rootfs as I have a highly embedded device and don’t want to rely on the eMMC or SD card for booting.

I created an initrd with buildroot 2022-02. This spits out a rootfs.cpio in which I gzip and place at Linux_for_Tegra/bootloader/l4t_initrd.img. When I run ./, I get the following error:

Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
[   0.0003 ] Generating signature
[   0.0008 ] tegrasign_v2 --key  --getmode mode.txt
[   0.0012 ] Assuming zero filled SBK key
[   0.0017 ] 
[   0.0023 ] header_magic: 414e4452
[   0.0035 ] tegrahost_v2 --chip 0x19 --align 1_boot.img
[   0.0044 ] 
[   0.0049 ] tegrahost_v2 --chip 0x19 0 --magicid DATA --appendsigheader 1_boot.img zerosbk
[   0.0052 ] adding BCH for 1_boot.img
[   1.1072 ] 
[   1.1083 ] tegrasign_v2 --key  --list 1_boot_sigheader.img_list.xml --pubkeyhash pub_key.key
[   1.1088 ] Assuming zero filled SBK key
[   1.1513 ] 
[   1.1521 ] tegrahost_v2 --chip 0x19 0 --updatesigheader 1_boot_sigheader.img.encrypt 1_boot_sigheader.img.hash zerosbk
[   1.7234 ] 
[   1.7505 ] Signed file: /home/aclark/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra/bootloader/temp_user_dir/boot_sigheader.img.encrypt Generate header for boot_sigheader.img.encrypt chip 0x19: add 0x2d0b800 to offset  0x8 in sig file Generate 16-byte-size-aligned base file for boot_sigheader.img.encrypt the signed file is /home/aclark/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra/bootloader/temp_user_dir/boot_sigheader.img.encrypt
Making recovery ramdisk for recovery image...
Re-generating recovery ramdisk for recovery image...
~/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra/bootloader/ramdisk_tmp ~/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra/bootloader ~/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra
64001 blocks
cp: cannot create regular file '/home/aclark/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra/bootloader/ramdisk_tmp//lib/aarch64-linux-gnu/': No such file or directory
failed command: cp -fv /home/aclark/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra/rootfs/lib/aarch64-linux-gnu/ /home/aclark/nvidia/nvidia_sdk/JetPack_4.5.1_Linux_JETSON_XAVIER_NX_DEVKIT/Linux_for_Tegra/bootloader/ramdisk_tmp//lib/aarch64-linux-gnu/

It is true that my initrd does not have /lib/aarch64-linux-gnu/, instead, I have /lib/

What use does the flashing tool have in introspecting my initrd?
Can I skip creating the “recovery ramdisk”? Or, is this ramdisk the recovery ramdisk?


armhf is the older 32-bit ARMv7-a architecture. You’d only use that in a compatibility mode for 32-bit. This might actually be used during boot since much of the boot content actually inherits from older 32-bit boots, but then it switches to 64-bit. I don’t know if perhaps your version is compatible or not since there are various “names” (e.g., soname) software might look for, but should your file be compatible, you could just create a symbolic link.

If you are at this location (“/lib/aarch64-linux-gnu”, or the subdirectory on the host PC you are using to create this content), then:
sudo ln -s

This creates a symbolic link,, which points at Normally though it is the other way around: would be the hard file, and would be symbolic. I’m pretty sure this will fail because is intended to be 64-bit, and your file is 32-bit. Consider adding a statically linked for the 64-bit case.


Thanks so much. And you’re correct, this was a mistake. I’m rebuilding my initrd for 64bit - oops.

Once that’s done, I guess I can complete the symlink if that’s absolutely necessary. Maybe you know why that’s specific file at that specific location is required.

Will report back. Thanks so much for your time.

Think of the initrd as an “adapter” between boot when totally in RAM, but transitioning to another environment. If the kernel being used already has everything it needs to transition, then there is no need for the initrd. As an example, if the kernel knows how to use the ext4 filesystem and eMMC or SD card controller without use of additional kernel modules, then it can get everything it needs to pivot_root (or in some cases for pseudo filesystems, switch_root). However, if the running kernel does not understand ext4, then you’d need an initrd with the modules required to mount the final ext4 filesystem (pretty much everything knows how to use ext4, but if for example you wanted to change to the XFS filesystem type, then you’d need an initrd as an “adapter”).

The kernel itself has some built-in search locations for content. For example, modules are always found at “/lib/modules/$(uname -r)/kernel”, and “uname -r” is part of the kernel itself. The first thing a kernel does after it starts is to run a single program, “init”. This tends to be a standard location (and is a symbolic link to “systemd” in current Ubuntu releases), and “init” itself is what deals with libraries and linkers (this is when it becomes “user space” instead of bare metal “kernel space”). Any time you need dynamically linkable user space you need a linker to deal with loading the libraries. Any time you need 64-bit, then you need a linker compatible with 64-bit.

You might find some rescue modes or simplified embedded devices change “init” to actually be a statically linked version of busybox by means of a symbolic link or actually being renamed “init” (and placed where the kernel expects to see it). Or a rescue mode kernel which has been hard wired to use some custom rescue environment. In those cases, if they don’t need a linker, then 100% of all software being run must be statically linked. No way to work with anything linked to a library without that linker.


Thanks for the information. I’m aware of the normal initrd workflow described here and through embedded and desktop systems. I’m also very experienced in traditional init systems.

For my NX-based system, I don’t want a mutable rootfs. Instead, I want to boot from QSPI into an initrd that’s not transitional, but instead is my runtime/rootfs; with busybox and an interactive shell, etc. A bit unconventional but not really when cboot has TFTP boot and I can boot new initrds over the network.

I have another thread (QSPI booting) where I’m trying to figure out which “partition” of QSPI and configuration of cboot will drop be into my custom initrd without relying on the rootfs. I understand I need to modify the kernel parameters, etc.

Anyway, I still don’t know why the flash is failing on the CONTENTS of my initrd.

Just an initial consideration: If this is JetPack/SDKM 5.x+, then it uses UEFI and the boot is quite different than the JetPack/SDKM 4.x or below. I’m not sure how CBoot is used if in 5.x, so you might want to state exactly which release you are working with. Boot information changes drastically depending on which you use. Your example says it is the older 4.5.1, where CBoot is definitely used, but it is good to nail the exact release.

Does your initrd have any kind of pivot_root or switch_root? It sounds like if you were to start with the default initrd for ordinary boot under 4.5.1, and you were to extract this and change any kind of pivot_root to instead be a call to busybox it would be the starting basis for what you want. However, I think the interesting part which might challenge you is that some parts of the boot stages might be examining “/boot” from ext4 rather than using what you have in your initrd. Sometimes those earlier boot stages, if they don’t find what they want in the “/boot” content and extlinux.conf, will substitute partition content as a fallback. For example, kernel and device tree. In the case of an SD card model, some of the content is in QSPI, but it still looks for extlinux.conf. I don’t know enough about custom initrd to tell you if you are running into unknown behavior due to looking at QSPI content, or “/boot”, or fallback content, but it seems likely.

However, in the case of an initrd, I’m guessing you’ve already looked for anything searching for “/boot” content, but perhaps fallback search is not part of initrd, and might instead be part of CBoot (and thus needing an actual CBoot edit…not sure…or device tree edit since early boot stages look at this, including kernel command line).

I almost forgot, you mention failing flash of contents of your custom initrd. You might give details on whether this is a flash error, or assumption that this did not work right because some content appears to not edit the way you edited, so on.

Apologies! My release is 4.5.1. I can move this up to a newer version but in my deployment, the 4.5.1 kernel is the most tested and used.

All of your information is so useful and helpful - thanks so much!

My initrd does NOT do a pivot_root or switch_root, it just sits in busybox init, provides a tty, and runs some services.

I do see in CBoot, the sd is the primary boot path. I tried taking out the SDCard and it just says “no sd card” and reboots ; I expected it to boot the kernel and initrd from QSPI but I guess that’s the part I have to figure out. I do see now how CBoot’s configured through a devicetree (or config file?). I peeked in the default on in the 4.5.1 release and found I can change a few parameters, but I couldn’t find an extensive list of configuration options.

I think I really need to understands CBoot’s default and bootflow. I see a lot of partitions in the file Linux_for_Tegra/bootloader/t186ref/cfg/flash_l4t_t194_spi_sd_p3668.xml that say “kernel” or “recovery” but I’m not totally sure what those really mean. I’m following this document ( from the archive that matches 4.5.1.

I think what’s extra confusing is that in the Cboot section in this document, there is no mention of anything in QSPI flash; affirming that CBoot’s whole purpose is to boot from external devices. Traditionally in u-boot, you just load the contents of QSPI flash into memory and boot it. With the NX’s partition layout, I think the "kernel" "kernel_b" "kernel-dtb" "kernel-dtb_b" partitions made me think CBoot could be made aware of these.

Apologies on the reported error. The error seems clear in my snippet where Making recovery ramdisk for recovery image... seems to introspect the contents of my initrd and fail when a file isn’t there. I guess the whole Linux_for_Tegra flash script flow extracts and uses my initrd for many things.

I tried to go into CBoot, set the boot order to empty string and run boot. Here is what happens:

TEGRA194 # setvar boot-order ""
TEGRA194 # 
TEGRA194 # boot
I> found decompressor handler: lz4-legacy
I> decompressing BMP blob ...
I> Kernel type = Normal
I> Loading kernel-bootctrl from partition
E> Cannot find partition kernel-bootctrl
E> Cannot open partition kernel-bootctrl
W> tegrabl_get_kernel_bootctrl: failed to read primary bootctrl data
I> Loading kernel-bootctrl_b from partition
E> Cannot find partition kernel-bootctrl_b
E> Cannot open partition kernel-bootctrl_b
W> tegrabl_get_kernel_bootctrl: failed to read recovery bootctrl data
W> tegrabl_get_kernel_bootctrl: use default dummy boot control data

What the heck is partition “kernel-bootctrl”? I don’t see that in the partition map XML file or anywhere in any XML file. Any clue what CBoot is doing here?


Thanks for letting me ramble on.

The pressing question: How can I get CBoot to boot the partitions kernel and kernel-dtb when it cannot boot the SD Card? My log above seems default Cboot will look at kernel-bootctrl so I’m off to modify the partitions XML file to have a partition named that.

Thanks! I don’t want to close this yet as there is still an open question of “requirements” that the ./ script workflow needs on my new initrd to complete a “flash” of the device. As mentioned in the first post, apparently ./ does some introspection of the initrd and I don’t know why/how to fix my initrd to make it work.

If this is a dev kit module, then the SD card slot is different than if this is a commercial module plus third party carrier board. In the former case this has drivers and QSPI designed to boot specifically to the SD card based on content first running in QSPI. If this is instead a commercial module on a third party carrier board with SD on the carrier board, then drivers may not be present in boot stages and this might not be possible. Can you clarify if this is a dev kit in its entirety? I can easily see that if this is a dev kit it does not like failing to have an SD card (I’ve not tried it, but perhaps if it is a dev kit, then boot order detection might be adjusted…if it is a commercial module, then I think you are out of luck so far as an SD card boot device is concerned).

I don’t know enough to be certain, but I think that what is going on is that earlier boot stages look for a device tree before reaching the stage where it would load an initrd or Linux kernel. While doing that it will scan for extlinux.conf on the SD card, and if it fails, then this might be getting in the way of progressing. On a commercial module (not an SD card dev kit) there is a partition which the device tree will go in, and if not found on the boot media via the extlinux.conf, then it will revert to the signed device tree partition (and thus in that case it won’t need a device tree in “/boot” via extlinux.conf).

You’re getting to a point though where I don’t know enough to say for sure. Much depends on whether this is a dev kit or a commercial module on a third party carrier board (they are quite different). Can you provide details on which board this is?


I am testing on a devkit but am trying to also be able to target a commercial module. It’s interesting that they are different, but I can why NVidia would do that.

I think I’m understanding more of this now. If I remove the SD from the boot-order, I think it’s trying to boot from QSPI but as you can see in my snippet, it’s not a partition that is present in the default partition layouts. I’m going through the CBoot sources now. I don’t see any forks in the code for devkit vs commercial module so maybe it comes down the the magic that ./ workflow wraps with it’s XML files and various cfg files that control the bootloader and QSPI layout.


The dev kit was only meant as an inexpensive method to develop code. For example, if a company sells a product based on the commercial module, then warranty passes through to the end user; however, if a company sells a product based on the dev kit, then the manufacturer has to take on warranty. The side effect of making this less expensive was to use QSPI memory plus an SD card, but the eMMC commercial module does not need QSPI (it just uses eMMC). There are both hardware and software differences between the two.

I suspect there is a way to work with boot order to get it to boot the custom initrd without an SD card being present, but I do not know what specific change needs to be made. This might just be an environment change, or it might require editing CBoot. If you are comfortable editing CBoot, then I’d suggest hard wiring it to not even detect SD card and simply use the initrd (perhaps use a dummy that lies and says the SD card is present, but since the initrd never transfers to SD, then it might not matter that there isn’t an SD).

Good thinking - and I agree with those assumptions.

I wish QSPI was in the boot-order targets with some well defined partitions. It would be awesome to treat it like a first-class boot target since it’s there, even if it’s small. Especially since CBoot is already has more complex features like networking, etc. Anyway…

but the eMMC commercial module does not need QSPI (it just uses eMMC).

This is what I don’t want actually. eMMC is much less robust in harsh environments (aerospace, etc) than NAND/NOR flash. Also, filesystems are hard to maintain autonomously. I guess if the automotive industry is using eMMC as a primary boot target, then I can just use it too ;).

Regardless of boot target, I need to figure out how to generate a custom ROOTFS that the ./ can boot nicely. I see some material on this. I might run into less issues than treating my initrd as my rootfs as I don’t think the ./ toolset messes with a user’s rootfs.

You can avoid using the eMMC for most uses, but it will have to contain some of the boot content. The rootfs can remain on initrd. This is perhaps not related in the sense of being something you can use, but it looks like some of the future industrial Orin products will use ECC RAM to increase reliability; this wouldn’t help in the case of boot content failure, but it would increase reliability once in the initrd., without special options, flashes everything. If you add the “-r” option to “reuse” the existing “Linux_for_Tegra/bootloader/system.img”, then it still flashes rootfs/APP, but it skips generating a default rootfs and uses whatever is already there. Beyond that you can also specify a single partition to install, e.g., “-k APP” means flash only works with the rootfs (and “APP” is a partition label). Unless boot content is custom though there is no reason to not flash all boot content, even if all you are changing is rootfs.

Very cool, thanks! I started messing with more arguments to ./ and found some shortcuts like you listed above.

It bothers me that there are so many partitions in that XML file (kernel, kernel_b…etc) but they are just somehow avoided/unused since “most people” want SDCards?

Maybe there is a devkit-to-commercial SoM guide lingering out there that explains how to migrate from “code it fast” to “deploy it”. Anyway, thanks!

A large part of those partitions are the equivalent of the CMOS BIOS of a PC. Imagine if the PC did not have a BIOS to create a uniform boot environment via a specification. Several things would occur:

  • The motherboard would be cheaper; it wouldn’t need the CMOS BIOS process or other BIOS hardware.
  • When flashing or installing one would have to flash the BIOS too since this more or less becomes part of booting rather than part of firmware and hardware.
  • You would need a recovery mode to allow programming since there is no self-contained operating environment capable of self-flash.
  • The board could no longer be “bricked”; a motherboard must have a working BIOS to install software for boot, and if the BIOS dies, and if there is no backup BIOS, then the BIOS can no longer be used…even if the BIOS is flashing the BIOS.
  • The boot software is much more complex due to manually bringing up power rails, engaging clocks at the right speed and order, and going through link training on various devices (e.g., memory and perhaps PCI bus).

To say those partitions are not needed would be more correctly phrased “the partitions are used during boot, but not used once boot is complete”. In the case of dual copies of a partition, e.g., kernel and kernel_b, you could think of that as the “backup BIOS” in some way (not exactly, but it is boot process redundancy). If a Jetson is up and running, then you can wipe the content of those partitions; unfortunately, you would no longer be able to reboot without flashing.

very cool, thanks @linuxdev.

From my experience developing custom boards and closed systems, I totally understand the “why” and the potential complexity that I’m writing off. I think the part that keeps getting me is that these partitions are listed, available, and part of the toolchain, but there is no indication what they do or how a user should treat them. I’m not talking about the really low-level ones that are used pre-cboot; I guess those are the partitions I’d agree are for REALLY essential “BIOS” stuff like BCT, and other “recovery” things. I love the recovery path, I think it’s great.

This really comes down to CBoot. This document (CBoot) is really great. It explains that CBoot’s default is SD/eMMC. The interesting part I see now is it’ll load kernel and kernel-dtb partitions if extlinux.conf on the SD/eMMC has no LINUX entry.

I’m just a bit anxious cause I’ve spent so many years with u-boot.

Thanks @linuxdev, for everything. I’m off to ignore the initrd for now and accept I need the SD/eMMC to work. I’m going to try to build my own rootfs and flash it to the APP partition. We’ll see how far I get!

I agree, partitions are something of a “black box”. The part you can look at is CBoot (“CPU Boot loader”), and examine source, or modify it, for the R32.x or before (JP4.x or before); in R34.x+ (JP5+) it switches to UEFI (which I think is a big win), and you can do anything “UEFI-ish”. And yet there is so much more which is just setting up the environment prior to any true bootloader running…you’d never see most of that if it had a BIOS, so you are now in the twilight zone of mixing CMOS flash and bootloader in an intermixed set of partitions (UEFI wins by setting up to a standard such that the bootloader does not need to understand previous stages, whereas earlier releases might require different parts of boot to understand each other).

Aside from CBoot, at least part of the content leading up to reaching CBoot is not published, although there are at least parts of what goes on known (but it is not obvious, e.g., you’ll find documentation for MB1 and MB2, but not necessarily source code or register level details).

FYI, in most of the previous releases CBoot leads up to U-Boot. Eventually, U-Boot was skipped, but the functionality was ported into CBoot such that CBoot became, to a large but not 100% degree, U-Boot compatible in features. Still, one can edit CBoot and get the source code, so if you are familiar with U-Boot source code, then some of CBoot for later releases will have the same “theme”. Also, some of the differences are due to being able to burn security fuses which prevents extlinux.conf from having the power it used to have, and for the most part this is not published source.

Good luck on your project, it will be interesting when done to hear how difficult it might have been. Also, if you really need to modify boot content, I’ll suggest L4T R35.x+ with JetPack5+ (R34.x was developer preview, R35.1 is an actual release). UEFI would mean a uniform boot environment and an ability to adapt bootloading in a standard way which CBoot modification won’t allow.


Thanks so much. All of this helps. I’m still strugging pretty hard with this. I looked at the SD card and found it ./ created a bunch of partitions there? Even though the XML files says device=qspi. Very confused.

I’ve been trying to drop to a shell in the default initrd as part of JP4.5.1. In /boot/extlinux/extlinux.conf, I change the commandline args via the DEFAULT entry to be:

      APPEND ${cbootargs} console=ttyTCU0,115200n8 console=tty0,115200n8 root=/dev/ram0 rw init=/bin/bash ramdisk_size=65535

Since I omit quiet, I see the whole bootlog and it’s going fine. The init script in the initrd says it should drop to bask via:

	echo "No root-device: Mount failed" > /dev/kmsg;
	exec /bin/bash;

However, I see no interactive prompt. Are my console= lines correct? I attached the linux boot log (after cboot and extlinux).

aclark_nx_boot_ram0.txt (58.1 KB)

Some clues:

  1. Maybe I have to use these console paths?
[    1.632928] 3100000.serial: ttyTHS0 at MMIO 0x3100000 (irq = 47, base_baud = 0) is a TEGRA_UART
[    1.634590] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 48, base_baud = 0) is a TEGRA_UART
[    1.635883] 3140000.serial: ttyTHS4 at MMIO 0x3140000 (irq = 49, base_baud = 0) is a TEGRA_UART
  1. I assume only the UART through J14 of the devkit works here as that’s where I see the bootlog.

  2. If I restore it all back to default, I see login prompt and everything (on the SD rootfs) on both J14 UART and USB uart (ttyACM*). So maybe the console configuration is OK?

  3. I don’t think init=/bin/bash is working as I can still see logs from the default nvidia /init at the very bottom of the boot log.

QSPI is persistent memory on the module, similar to a hard drive, but used only for non-rootfs content on an SD-only model. An eMMC shows many partitions which are visible through simple display of disk content; that content is also on the QSPI of that model, but you won’t see it. It is used for boot.

Boot content is always on the Jetson even if you have external rootfs. Some of that content is equivalent to a PC’s CMOS BIOS (a Jetson does not have a BIOS, thus it needs partitions or code run somewhere else). This boot content is what sets up power rails and content, and loads the bootloader (even the bootloader is not the first software…someone has to load the loader, which in turn overwrites itself with the next stage, the Linux kernel). If you had a BIOS, then only the bootloader would be added. When you do flash that “other” content you are adding a pointer to where the starting software will transfer control (you need to point somewhere via QSPI to say where to look for the next stage). The partitions exist in the Jetson regardless of whether you can see them (eMMC models) or not (SD card models with QSPI).


board power rails and clocks (BPMP)
  -> CPU bring-up
    -> Bootloader (and possibly unpacking an initrd for the next stage to use)
      -> Linux kernel (possibly using the hard drive or an initrd)

Note that sometimes the device tree is used in boot prior to Linux running. “extlinux.conf” is just one part of where kernel arguments are passed, but those are named by the bootloader, and not usually directly read by the Linux kernel. Consider that the actual arguments which Linux sees to the kernel is from:
cat /proc/cmdline

Now look at the “APPEND” key/value pair of “/boot/extlinux/extlinux.conf”. Notice this very very important token, which is actually inheriting from the environment which the bootloader passed:

${cbootargs}” starts at the device tree node “chosen->bootargs”. “/proc/device-tree” is a reflection of what the kernel saw as its device tree at the moment of boot (which might have been edited by earlier boot stages versus what you specified). In particular, check this:
cat /proc/device-tree/chosen/bootargs

Note that anything in the “APPEND” of extlinux.conf simply adds on to the inherited “${cbootargs}”. You might even find some content duplicated. If you make a change which needs to be seen in the boot stages prior to Linux running, and you also want this information passed to the kernel as a command line argument, then you have to consider both the device tree’s “chosen->bootargsand the “APPEND” of extlinux.conf. Your initrd is seeing the combination.

I can’t answer your console questions. If this were normal fully booted Linux, then there would be a getty or agetty, and login there would transfer control to a shell. This is true for serial console as well. But this early on in the initrd I’m not sure what else would work as a substitute. I know you can run a statically linked busybox, but what I’m not sure of is how one would link it to the local keyboard and monitor or to the serial UART. Having logs go to serial UART might be a good hint, but this is only output (there must be some configuration to link a keyboard…if the drivers are loaded…to serial console, and maybe this has even been provided in earlier boot stages since serial console is active, but I don’t know for sure).

Note that you will not normally use a “ttyTHS#” for serial console. Earlier boot stages have the legacy 16550A UART driver (8250), but they don’t have the NVIDIA DMA-capable “Tegra High Speed” driver (a ttyTHS). In order for serial console logs to continue from boot stages on through Linux the driver has to remain active. I suspect it is not as easy as it sounds to switch from a ttyS to a ttyTHS if you don’t want to lose content during the switch of drivers. Therein is a good point though: The driver has to be loaded before you can use the UART. Output and input events must be routed to that driver.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.