Re: Re: Transmeta

#52454

jaclaz
Member

@gianxxx wrote:

Hello. I’m interested too

I’ve got a FUTRO S300 floating around, with a D-Link multi LAN or a simple PCI card it could be a good solution…I hope so…

Yep, that’s exactly the machine I had lying around.
As said it was a temporary workaround since the idea was to use an Epia 5000 (of which I had two “lying around”).
See:
https://www.zeroshell.org/forum/viewtopic.php?t=3687
But after some experiments with them, and besides the fact that I didn’t manage to resolve the error I posted about, I looked a bit around and found how it esy to find Futro’s, the 210 or 220 model for anything between 20 and 50 Euro on e-bay (in Germany).
I then bought two “new” Futro S220 for 70 Euros, they came with 128 Mb RAM and a 128 Mb CF card.
The one I used temporarily was a S300, and I installed the Zeroshell 1 beta 16 on the internal (4 Gb) CF card.
Because of the issues with BIOS (see below) I temporarily used a “standard” MBR, as detailed in my initial post.
The thingy is working (though I have not particularly “high” needs) since beginning on september without a hitch.
The only issue is that in case of blackout the Futro does not re-power itself (no such setting in the BIOS) so you have to physically push the power button.
Since the BIOS has two settings for PME and WOL, I will have to experiment with re-powering it remotely through network.

For this new test with S220 I started with a new approach:

  1. leave the 128 Mb card
  2. use a USB stick for Zeroshell (I have a bunch of 2 Gb no-name ones)

The Futro is more or less a Commercial operation by Fujitsu-Siemens, the actual PC is a TR5670 manufactured by Teco, they seemingly just change the splashscreen and print “Fujitsu Siemens” on the unmodified case.

I won’t comment (in order to avoid cursing) about the amount of data/documentation/drivers/support/etc. provided by Fujitsu Siemens (next to none) or by Teco (actually none) and about the amount of available data from third parties (very, very little). (and let’s not comment about the Insyde guys, see below)

The issue is – as often is – the BIOS, it is made by Insyde and it is the MobilePro version 4.20.80 (BIOS 1.05.05).
In my experience I have seen crappy BIOSes, but the ones made by Insyde are the worst of all.
Besides the way to select choices is simply crazy, you use Space or Enter to select/enable things on a “random” basis, it has very limited options, most of them poorly implemented or simply mislabeled/wrong.
Additionally that BIOS “checks” the MBR boot code and won’t accept the GRUB one (but see below).
The boot options are:

  1. IDE
  2. USB Floppy
  3. USB CDROM
  4. Network (PXE)

What is NOT specified/documented is that if you insert a (partitioned) USB stick in a USB port, the thingy will attempt to boot from it first.
As said the GRUB MBR code (used in Zeroshell 1 Beta 16) is NOT compatible with that stupid BIOS /as well as the GRUB2 one used in Zeroshell 2), the good news being that some time ago this issue was found during the development of grub4dos and solved.
For reference:
http://reboot.pro/10503/#entry117680

For some strange reasons (that I have not yet fully understood/tested) the USB ports have both the USB 1.1 and the USB 2.0 speed and it seems like it boots anyway at USB 1.1 speed (slow) though as said it could be an issue with the BIOS settings I haven’t yet fully experiemnted with.
So, the “easy” way to have the Zeroshell booting from it on a USB stick or CF Card is the following (under Windows, but under Linux it won’t be any different).
I used the Qemu + Qemu Manager using a grub4dos Dos floppy (If you need info on how to make one ask) and the latest “Featured” release of grub4dos Chenall:
http://code.google.com/p/grub4dos-chenall/downloads/list
http://code.google.com/p/grub4dos-chenall/downloads/detail?name=grub4dos-0.4.5c-2012-06-19.7z&can=2&q=
grub4dos-0.4.5c-2012-06-19.7z
You can boot Qemu allright from the Zeroshell “ZeroShell-1.0.beta16-CompactFlash-IDE-USB-SATA-1GB.img” then copy to first partition (or “boot” partition) the files grldr and bootlace.com.
Then you run from the booted Zeroshell bootlace.com to replace the GRUB (legacy) MBR boot code with the grub4dos one, you can leave the “standard” /grub/menu.lst as is.
Then you dd the image to the stick.

Due to having the USB 1.1 speed issue and an otherwise unused 128 Mb CF CARD, I went a bit further.
Since my USB sticks are 2 Gb, I created on the stick (mounted in Qemu as \.PhysicalDrive) a FAT 16 partition and added to it a DOS floppy image with the PLoP install files (but the floppy image can be added to the first partition or “boot” partition allright), mounted it to –mem and installed PLoP to the CF Card.
A word of warning though.
The 128 Mb CF card is seen by the Futro BIOS as 500/16/32, since the PLoP code is longer than 32 sectors if you are going to make a partition on the CF card, it will overwrite the PLoP code, so you either leave the CF-Card UNpartitioned (with just the PLoP installed) or you need to make the first partition start on at least third head.
So, I disable the “legacy USB” support in BIOS, the thingy boots from the CF card (and thus to PLoP) which I set – after a few experiments – to boot automatically from USB with a delay of 10 seconds (there were some timeing problems if the delay was shorter when rebooting from Zeroshell), then grub4dos “takes control” and loads the kernel and initrd fast (USB 2.0) speed.

I have no idea – sorry – about the -O2 flag and Transmeta, the thingy is working, boots and actually routes what it should route, the only issue is the mentioned “init: Id 7 respawning too fast: disabled for 5 minutes.” messages (and I am not sure to understand your note about inittab)

The inconsistencies I mentioned are mostly because I am a rather picky (and critical) kind of guy and would like to have things “clear” and “as simple as possible”.
As said the partitioning scheme of the images seems like having been made using numbers obtained by dice throwing, no “common” tools, including the Linux fdisk included in Zeroshell “like” them, the choice of using GRUB (legacy) and all ext2fs/ext3fs partitions (including the partition ID of the CDROM one) makes matters much more difficult for non-expert Linux users, the choice to have the CDROM partition in the middle of the image makes the first one, and more generally the whole image, “unmodifiable” (unless you know where your towel is) with “common” tools such as gparted, let alone the Dos/Windows tools.
It seems to me like Zeroshell is the second or third best thing after the invention of the ice cream, and has (IMHO) the greatest potentialities, but right now to have to deal with it is extremely difficult unless you have some good backgrounds in booting matters (of which I know something) AND a “solid” background with Linux (which I almost completely lack of).
Some things are most probably – as said – perfectly “natural” to an expert Linux user, but believe me they do look “queer” to someone coming from a different experience, another thing that I banged my head against some time (before understanding and finding the solution):
https://www.zeroshell.org/forum/viewtopic.php?t=3688

Let me know if (apart form the ranting parts) the “how to” instructions are good enough or you need further assistance.

jaclaz