Dear,
For the Xfce [1] project we acquired an HP Proliant DL145G3 to act as a buildbot [2],[3] (mainly for creating testbuilds of Xfce for different distro's, unix flavors and different architectures, so to shorten the release process, and spot compiler problems early in the development process.
Upon installing the machine I discovered that for some reason HP decided to disable the hardware virtualization of the machine. I flashed the bios to the newest available version, tried enabling svm from userspace and kernel mode code, all to no avail. Contacted HP to give me a proper bios which didn't succeed either :( . This seem to be an issue known all of the internet: [4], [5].
As the Xfce project does not have unlimited funds we are kind of depending on the functionality of this machine. We can't just buy another server. So either we succeed in enabling kvm for the machine or we will have to depend on software emulation of virtualization.
That's where coreboot comes into play. If there is any chance in enabling the hardware virtualization on the processors of this machine it will have to come from proper firmware, like coreboot. The first reference to coreboot in the context of this machine was found using google: [6]. After contacting the author it seems like the port that was made still had timing issues: [quote]Das Interrupt Problem, das wir damals hatten war, dass der Timer Interrupt quasi doppelt so schnell lief, d.h. im laufenden System verging die Zeit "doppelt so schnell". Ich kann auch nicht garantieren, dass alle Peripherie laueft, ich glaube wir haben nur Teile getestet.[/quote] translated: The interrupt problem that we had back then was that the timer interrupt ran twice as fast, meaning in a running system the time passed "twice as fast". I also cannot guarantee that all peripherials are working, I think we only tested some parts.
It's not entirely clear how severe these "issues" are but I understand the current patchset is not sufficient to get a production firmware.
So, in the name of the Xfce community, I'd like to invite you to investigate the possibility to create coreboot port for this machine. On developing such a firmware we could reward the developer (or any foundation of his choice) with a 100 euro (which is a part of the money we raised to upgrade the hardware of the machine)
In the mean time I can provide you with the following hardware information: cpuinfo [7] lspci [8] dmidecode [9] If more info is required please ask.
Kind regards,
Samuel Verstraete
[1] http://www.xfce.org [2] http://blog.xfce.org/2008/12/topics-raised-at-uds/ [3] http://gezeiten.org/post/2009/03/Xfce-Buildbot-Server-Call-for-Donations [4] http://actes.sstic.org/SSTIC08/Rump_sessions/SSTIC08-Rump-Ruff-HP-0.2.pdf [5] https://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=11178... [6] http://ra.ziti.uni-heidelberg.de/coeht/pages/events/20090211/ulrich_bruening... [7] http://merlin.ugent.be/~samuel/dl145g3/cpuinfo.txt [8] http://merlin.ugent.be/~samuel/dl145g3/lspci.txt [9] http://merlin.ugent.be/~samuel/dl145g3/dmidecode.txt
Hi Samuel,
On Tue, Mar 24, 2009 at 11:20 AM, samuel samuel.verstraete@gmail.com wrote:
[quote]Das Interrupt Problem, das wir damals hatten war, dass der Timer Interrupt quasi doppelt so schnell lief, d.h. im laufenden System verging die Zeit "doppelt so schnell". Ich kann auch nicht garantieren, dass alle Peripherie laueft, ich glaube wir haben nur Teile getestet.[/quote] translated: The interrupt problem that we had back then was that the timer interrupt ran twice as fast, meaning in a running system the time passed "twice as fast". I also cannot guarantee that all peripherials are working, I think we only tested some parts.
This is probably a problem in the clock source selection of the RTC. It should be a simple fix.
I hope that someone takes this up as it is a great opportunity for coreboot to fix a problem in the vendor BIOS.
Marc
Marc Jones wrote:
I hope that someone takes this up as it is a great opportunity for coreboot to fix a problem in the vendor BIOS.
Me too. Does someone still remember working on HT1000?
//Peter
Hi everybody,
I'll try to gather the stuff we had done on that machine and post it here together with the current status. For that I will first reactivate our DL145G3 and try to run our last version. Stay tuned, hope to have that ready tomorrow night (european time). Being optimistic :-)
Regards, Mondrian
Hi,
On Wed, Mar 25, 2009 at 3:19 PM, Mondrian Nuessle nuessle@uni-hd.de wrote:
Hi everybody,
I'll try to gather the stuff we had done on that machine and post it here together with the current status. For that I will first reactivate our DL145G3 and try to run our last version. Stay tuned, hope to have that ready tomorrow night (european time). Being optimistic :-)
That would be nice of you :)
So I ordered 5 blank rom chips and they arrived today at my place. So i decided to experiment with them right away. As you can guess i do not have access to a rom writer device or whatever you call these machines. So i have to rely on hotflashing.
I first read the original bios from the rom chip (http://merlin.ugent.be/~samuel/dl145g3/bios_rom/original_bios.bin) Pulled out the chip (pushpin method works great), dropped in a replacement, erased it (flashrom -E), tried to write the original one in it (flashrom -wv original_bios.bin) but the last step always ends with a "FAILED":
root@kopiluwak ~/bios/flashrom # ./flashrom -wv ../original_bios.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "Broadcom HT-1000", enabling flash write... OK. Found chip "SST SST49LF080A" (1024 KB) at physical address 0xfff00000. Flash image seems to be a legacy BIOS. Disabling checks. Programming page: 0250 at address: 0x000fa000 Verifying flash... FAILED at 0x000f0000! Expected=0x00, Read=0xff
So I'm a bit stuck... Seems like there are motherboards that need special modifications of flashrom to actually work? I assume Mondrian has a rom writer device thing, so you prolly didn't encounter this problem. But if you did... or if you have a clue on what is going wrong???
Kind Regards,
Samuel Verstraete
Regards, Mondrian
-- Dr. Mondrian Nuessle Phone: +49 621 181 2717 University of Heidelberg Fax: +49 621 181 2713 Computer Architecture Group mailto:nuessle@uni-hd.de http://ra.ziti.uni-heidelberg.de
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
samuel wrote:
Verifying flash... FAILED at 0x000f0000! Expected=0x00, Read=0xff
Looks like the boot block is write protected (by the controller).
yu ning
I wrote:
Looks like the boot block is write protected (by the controller).
SST49LF080A has a #TBL pin deciding whether writes to the top boot block is protected.
If that is the cause of the failure and should you have no choice other than flashrom at the moment, I can see two workarounds.
* if someone has access to the BCM5875(HT1000) datasheet, (s)he may check whether there are registers that control the output to the #TBL pin, then improves flashrom. Or,
* You can insulate the #TBL pin of the flash chip from the corresponding socket contact, and connect #TBL to Vdd. According to the datasheet of SST49LF080A, providing Vih(=Vdd) to #TBL disables write protection on the boot block.
yu ning
FENG Yu Ning wrote:
SST49LF080A has a #TBL pin deciding whether writes to the top boot block is protected.
Correct. It is most likely the cause. But - it would also be interesting if you could measure the voltage Samuel, on pin 8 after having run flashrom in any mode.
- if someone has access to the BCM5875(HT1000) datasheet, (s)he may check whether there are registers that control the output to the #TBL pin, then improves flashrom.
Unfortunately (or fortunately, because that Broadcom data book is probably difficult to find) TBL# (and often WP# too) is usually connected to a GPIO on some chip. (And that chip may be easier to find docs for.) But - this Broadcom chipset could have dedicated pin, I'm not ruling it out.
//Peter
We need to figure out where pin 8 on the flash chip is connected. It is the TBL# pin, which implements hardware write protect for the top 64KB of the chip. Hopefully it connects to a chip which we can find documentation for easily. Then the code is easy to add.
Will check and report back. Machine is sitting at home...
Do you have access to a continuity tester? Please check this connection.
I do not have access to a continuity tester.
- You can insulate the #TBL pin of the flash chip from the corresponding socket contact, and connect #TBL to Vdd. According to the datasheet of SST49LF080A, providing Vih(=Vdd) to #TBL disables write protection on the boot block.
I guess i can try this... I suppose it won't hurt?
Correct. It is most likely the cause. But - it would also be interesting if you could measure the voltage Samuel, on pin 8 after having run flashrom in any mode.
I will get a volt meter... What pin should i use as ground? I tried having a look at page 7 of the LPC data sheet but i didn't see a ground pin...
samuel wrote:
Do you have access to a continuity tester? Please check this connection.
I do not have access to a continuity tester.
..
- You can insulate the #TBL pin of the flash chip from the corresponding socket contact, and connect #TBL to Vdd. According to the datasheet of SST49LF080A, providing Vih(=Vdd) to #TBL disables write protection on the boot block.
I guess i can try this... I suppose it won't hurt?
Yep, it's a good idea. Bend pin 8 up and make sure it doesn't have contact with the socket, then connect it to pin 32 or 25. (Both VDD)
Correct. It is most likely the cause. But - it would also be interesting if you could measure the voltage Samuel, on pin 8 after having run flashrom in any mode.
I will get a volt meter... What pin should i use as ground? I tried having a look at page 7 of the LPC data sheet but i didn't see a ground pin...
16, VSS is ground.
Maybe that volt meter also has an ohm meter function. That works well as a continuity tester too - if two points are connected the resistance will be 0.00 ohm.
//Peter
All this talking about a single pin that is causing this is making me think about something... This mainboard has 2 jumpers. Each next to each other... One is "BIOS RESET" and the other is "CRISIS PARK"... Could that CRISIS PARK maybe connect to pin 8 to disable the flashrom writes??? I guess if i measure the voltage and/or ohm that should tell me?
On Fri, Mar 27, 2009 at 8:55 AM, Peter Stuge peter@stuge.se wrote:
samuel wrote:
Do you have access to a continuity tester? Please check this connection.
I do not have access to a continuity tester.
..
- You can insulate the #TBL pin of the flash chip from the
corresponding socket contact, and connect #TBL to Vdd. According to the datasheet of SST49LF080A, providing Vih(=Vdd) to #TBL disables write protection on the boot block.
I guess i can try this... I suppose it won't hurt?
Yep, it's a good idea. Bend pin 8 up and make sure it doesn't have contact with the socket, then connect it to pin 32 or 25. (Both VDD)
Correct. It is most likely the cause. But - it would also be interesting if you could measure the voltage Samuel, on pin 8 after having run flashrom in any mode.
I will get a volt meter... What pin should i use as ground? I tried having a look at page 7 of the LPC data sheet but i didn't see a ground pin...
16, VSS is ground.
Maybe that volt meter also has an ohm meter function. That works well as a continuity tester too - if two points are connected the resistance will be 0.00 ohm.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Fri, Mar 27, 2009 at 8:59 AM, samuel samuel.verstraete@gmail.com wrote:
All this talking about a single pin that is causing this is making me think about something... This mainboard has 2 jumpers. Each next to each other... One is "BIOS RESET" and the other is "CRISIS PARK"... Could that CRISIS PARK maybe connect to pin 8 to disable the flashrom writes??? I guess if i measure the voltage and/or ohm that should tell me?
reference: http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c00856243/c00... page 63 and page 64 (it's component 18) on page 65:
PARK: "Normal boot" or "Boot block enabled" doesn't sount like bios write protection... so this prolly is nothing...
On Fri, Mar 27, 2009 at 8:55 AM, Peter Stuge peter@stuge.se wrote:
samuel wrote:
Do you have access to a continuity tester? Please check this connection.
I do not have access to a continuity tester.
..
- You can insulate the #TBL pin of the flash chip from the
corresponding socket contact, and connect #TBL to Vdd. According to the datasheet of SST49LF080A, providing Vih(=Vdd) to #TBL disables write protection on the boot block.
I guess i can try this... I suppose it won't hurt?
Yep, it's a good idea. Bend pin 8 up and make sure it doesn't have contact with the socket, then connect it to pin 32 or 25. (Both VDD)
Correct. It is most likely the cause. But - it would also be interesting if you could measure the voltage Samuel, on pin 8 after having run flashrom in any mode.
I will get a volt meter... What pin should i use as ground? I tried having a look at page 7 of the LPC data sheet but i didn't see a ground pin...
16, VSS is ground.
Maybe that volt meter also has an ohm meter function. That works well as a continuity tester too - if two points are connected the resistance will be 0.00 ohm.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
samuel wrote:
All this talking about a single pin that is causing this is making me think about something...
Great!
This mainboard has 2 jumpers. Each next to each other... One is "BIOS RESET" and the other is "CRISIS PARK"... Could that CRISIS PARK maybe connect to pin 8 to disable the flashrom writes???
Note that only the top 64kb of the flash chip is locked now. But yes - it could certainly be controlled a jumper.
I guess if i measure the voltage and/or ohm that should tell me?
Correct. If there is 0 ohm between the middle pin of that jumper and pin 8, move the jumper and try running flashrom again.
To really make sure it's good to verify that voltage between pins 16 and 8 actually changes when you disconnect that jumper.
//Peter
On Fri, Mar 27, 2009 at 9:06 AM, Peter Stuge peter@stuge.se wrote:
samuel wrote:
All this talking about a single pin that is causing this is making me think about something...
Great!
This mainboard has 2 jumpers. Each next to each other... One is "BIOS RESET" and the other is "CRISIS PARK"... Could that CRISIS PARK maybe connect to pin 8 to disable the flashrom writes???
Note that only the top 64kb of the flash chip is locked now. But yes - it could certainly be controlled a jumper.
I guess if i measure the voltage and/or ohm that should tell me?
Correct. If there is 0 ohm between the middle pin of that jumper and pin 8, move the jumper and try running flashrom again.
To really make sure it's good to verify that voltage between pins 16 and 8 actually changes when you disconnect that jumper.
On the channel someone said i could also try to use another mainboard to flash the rom... Is that a possibility with this 'weird' pin there? I still have a couple of nforce2 boards that have the same rom socket so i could prolly test on those too... or doesn't that make any sense?
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
FENG Yu Ning wrote:
- if someone has access to the BCM5875(HT1000) datasheet, (s)he may check whether there are registers that control the output to the #TBL pin, then improves flashrom. Or,
HT1000 has nothing special or dedicated for this. As Peter says, it is probably hooked up to a GPIO on one of a couple different devices.
Hi Samuel,
samuel wrote:
root@kopiluwak ~/bios/flashrom # ./flashrom -wv ../original_bios.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "Broadcom HT-1000", enabling flash write... OK. Found chip "SST SST49LF080A" (1024 KB) at physical address 0xfff00000. Flash image seems to be a legacy BIOS. Disabling checks. Programming page: 0250 at address: 0x000fa000 Verifying flash... FAILED at 0x000f0000! Expected=0x00, Read=0xff
So I'm a bit stuck... Seems like there are motherboards that need special modifications of flashrom to actually work?
Correct. This board needs what is called board enable for flashrom to function completely.
We need to figure out where pin 8 on the flash chip is connected. It is the TBL# pin, which implements hardware write protect for the top 64KB of the chip. Hopefully it connects to a chip which we can find documentation for easily. Then the code is easy to add.
Do you have access to a continuity tester? Please check this connection.
Page 7 of http://www.sst.com/downloads/datasheet/S71235.pdf shows the flash chip pinout.
//Peter
Hi,
as someone already pointed out, we need to enable flashing first on the board using a GPIO pin. I have attached a patch for flashrom that enables flashing on the HP DL145 G3. I tested it on the DL145 I have here.
Please specify the board on the commandline, like in # ./flashrom -m "hp:dl145_g3" -E
The patch is probably not ready for primetime, maybe someone can review it?
Regards, Mondrian
Mondrian Nuessle wrote:
as someone already pointed out, we need to enable flashing first on the board using a GPIO pin. I have attached a patch for flashrom that enables flashing on the HP DL145 G3. I tested it on the DL145 I have here.
That's great!
I think it is better to document some hardware information along so that the code will be more meaningful. For example,
* What super IO is on that board? * Are those configuration IO port numbers default value or board specific? * The function of the bits we are modifying (better all bits in that register).
Hope that is not a silly suggestion.
yu ning
On Fri, Mar 27, 2009 at 3:46 PM, FENG Yu Ning fengyuning1984@gmail.com wrote:
Mondrian Nuessle wrote:
as someone already pointed out, we need to enable flashing first on the board using a GPIO pin. I have attached a patch for flashrom that enables flashing on the HP DL145 G3. I tested it on the DL145 I have here.
Wonderfull patch :) Works like a charm here... I just made a backup from my bios and flashed it into a new rom and booted with that one... just works :) thnx Samuel
and now the coreboot patches ;)
Hi,
good to hear that the flashrom patch worked for you :-)
I am working on the patchset, we have a kernel booting up from a sata driver using a patched FILO...
There are some issues, though. Please stay tuned, I'll come back to you as soon as I can.
Unfortunately, I won't have the possibility to work on that before monday :-( Samuel, I'll try to get you a BIOS image then that you can test ASAP.
Regards, Mondrian
samuel wrote:
On Fri, Mar 27, 2009 at 3:46 PM, FENG Yu Ning fengyuning1984@gmail.com wrote:
Mondrian Nuessle wrote:
as someone already pointed out, we need to enable flashing first on the board using a GPIO pin. I have attached a patch for flashrom that enables flashing on the HP DL145 G3. I tested it on the DL145 I have here.
Wonderfull patch :) Works like a charm here... I just made a backup from my bios and flashed it into a new rom and booted with that one... just works :) thnx Samuel
and now the coreboot patches ;)
Hi,
On Fri, Mar 27, 2009 at 01:11:08PM +0100, Mondrian Nuessle wrote:
as someone already pointed out, we need to enable flashing first on the board using a GPIO pin. I have attached a patch for flashrom that enables flashing on the HP DL145 G3. I tested it on the DL145 I have here.
Please specify the board on the commandline, like in # ./flashrom -m "hp:dl145_g3" -E
The patch is probably not ready for primetime, maybe someone can review it?
I can't test it due to lack of hardware, but otherwise the code looks OK. Please add your Signed-off-by to all patches you send, though.
Uwe.
On Fri, Mar 27, 2009 at 01:11:08PM +0100, Mondrian Nuessle wrote:
Hi,
as someone already pointed out, we need to enable flashing first on the board using a GPIO pin. I have attached a patch for flashrom that enables flashing on the HP DL145 G3. I tested it on the DL145 I have here.
Please specify the board on the commandline, like in # ./flashrom -m "hp:dl145_g3" -E
The patch is probably not ready for primetime, maybe someone can review it?
Regards, Mondrian
Dr. Mondrian Nuessle Phone: +49 621 181 2717 University of Heidelberg Fax: +49 621 181 2713 Computer Architecture Group mailto:nuessle@uni-hd.de http://ra.ziti.uni-heidelberg.de
Index: flashrom/board_enable.c
--- flashrom/board_enable.c (revision 4027) +++ flashrom/board_enable.c (working copy) @@ -633,6 +633,19 @@ int (*enable) (const char *name); };
+static int board_hp_dl145_g3_enable(const char *name) +{
- uint8_t b;
- outb(0x44, 0x0cd6);
- b = inb(0x0cd7) | 0x24;
- outb(b, 0x0cd7);
- return 0;
+}
struct board_pciid_enable board_pciid_enables[] = { { .first_vendor = 0x1106, @@ -1014,6 +1027,20 @@ .enable = ich6_gpio19_raise, }, {
.first_vendor = 0x1166,.first_device = 0x0205,.first_card_vendor = 0x0000,.first_card_device = 0x0000,.second_vendor = 0x1166,.second_device = 0x0234,.second_card_vendor = 0x0000,.second_card_device = 0x0000,.lb_vendor = "hp",.lb_part = "dl145_g3",.name = "HP DL145 G3",.enable = board_hp_dl145_g3_enable,- },
- { .first_vendor = 0, .first_device = 0, .first_card_vendor = 0,
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Are there no subsystem/board ids available?
And man, does that struct stuff still suck. For a 10 line function, a horrible 14 lines get added to what is basically a table. Cute.
Luc Verhaegen.
On 27.03.2009 13:11 Uhr, Mondrian Nuessle wrote:
Hi,
as someone already pointed out, we need to enable flashing first on the board using a GPIO pin. I have attached a patch for flashrom that enables flashing on the HP DL145 G3. I tested it on the DL145 I have here.
Please specify the board on the commandline, like in # ./flashrom -m "hp:dl145_g3" -E
The patch is probably not ready for primetime, maybe someone can review it?
Regards, Mondrian
+static int board_hp_dl145_g3_enable(const char *name) +{
- uint8_t b;
- outb(0x44, 0x0cd6);
- b = inb(0x0cd7) | 0x24;
- outb(b, 0x0cd7);
Any chance to find out what hardware is listening at 0xcd6/0xcd7?
Is that covered by PMBASE or GPIOBASE of the southbridge, or the SuperIO?
Stefan
Stefan Reinauer wrote:
The patch is probably not ready for primetime, maybe someone can review it?
Correct - but we can probably clean it up and commit easily if someone with hardware access comes to #coreboot on irc.freenode.org.
- outb(0x44, 0x0cd6);
- b = inb(0x0cd7) | 0x24;
- outb(b, 0x0cd7);
Any chance to find out what hardware is listening at 0xcd6/0xcd7?
We must. As it stands this is not going in.
Is that covered by PMBASE or GPIOBASE of the southbridge, or the SuperIO?
Did it have Intel south? Will check.
//Peter
Stefan Reinauer wrote:
On 27.03.2009 13:11 Uhr, Mondrian Nuessle wrote:
Hi,
as someone already pointed out, we need to enable flashing first on the board using a GPIO pin. I have attached a patch for flashrom that enables flashing on the HP DL145 G3. I tested it on the DL145 I have here.
Please specify the board on the commandline, like in # ./flashrom -m "hp:dl145_g3" -E
The patch is probably not ready for primetime, maybe someone can review it?
Regards, Mondrian
+static int board_hp_dl145_g3_enable(const char *name) +{
- uint8_t b;
- outb(0x44, 0x0cd6);
- b = inb(0x0cd7) | 0x24;
- outb(b, 0x0cd7);
Any chance to find out what hardware is listening at 0xcd6/0xcd7?
Is that covered by PMBASE or GPIOBASE of the southbridge, or the SuperIO?
Stefan
The hardware listening on these ports is the BCM5785 (HT1000 southbridge). Basically, the code just controls 2 GPIO pins that are connected to WP and TBL of the BIOS chip.
- Sven
Sven Kapferer wrote:
Any chance to find out what hardware is listening at 0xcd6/0xcd7?
The hardware listening on these ports is the BCM5785 (HT1000 southbridge). Basically, the code just controls 2 GPIO pins that are connected to WP and TBL of the BIOS chip.
Sure - but what determines the port - or rather, where can it be probed?
Data from Samuel suggests that the ports are configured by the BIOS, because the PNP0c02 device owns them ("system peripheral: other") according to ACPI tables.
Do you know if the base port is readable from a fixed register such as one in PCI config space?
//Peter
Peter Stuge schrieb:
Sven Kapferer wrote:
Any chance to find out what hardware is listening at 0xcd6/0xcd7?
The hardware listening on these ports is the BCM5785 (HT1000 southbridge). Basically, the code just controls 2 GPIO pins that are connected to WP and TBL of the BIOS chip.
Sure - but what determines the port - or rather, where can it be probed?
Data from Samuel suggests that the ports are configured by the BIOS, because the PNP0c02 device owns them ("system peripheral: other") according to ACPI tables.
Do you know if the base port is readable from a fixed register such as one in PCI config space?
According to the datasheet the ports are fixed.
- Sven
Hi, 0xcd6/cd7 are the Power Management registers of the Southbridge (BCM5785). Actually this is very similar to the way the IBM x3455 is handled in board_enable.c.
I attached a somewhat improved patch including comments and subsytem id. If anybody knows how to do all this more elegantly, that would be great.
Regards, Mondrian
Mondrian Nuessle wrote:
Add support for HP DL145 G3. This is a BCM5785 based machine, WP# and TLB# need to be deasserted using GPIO 0 and 2 from the PM registers of the southbridge. This is very similar to the x3455 implementation.
Signed-off-by: Mondrian nuessle nuessle@uni-hd.de
I grabbed another PCI subsystem ID so that the autodetect should work.
Acked-by: Peter Stuge peter@stuge.se
r4031
-
FENG Yu Ning -
Luc Verhaegen -
Marc Jones -
Mondrian Nuessle -
Peter Stuge -
samuel -
Stefan Reinauer -
Sven Kapferer -
Tom Sylla -
Uwe Hermann