[U-Boot] 85xx: MPC8536DS board does not build
Dear Kumar,
I cannot build the MPC8536DS board any more using the ELDK 4.2 tool chain (gcc 4.2.2):
ppc_85xx-ld: section .bootpg [effff000 -> effff1cb] overlaps section .data.rel.local [efffe5d0 -> effff c7b] ppc_85xx-ld: section .resetvec [effffffc -> efffffff] overlaps section .u_boot_cmd [effffc9c -> f00003e b] ppc_85xx-ld: u-boot: section .bootpg lma 0xeffff000 overlaps previous sections ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xeffffc7c overlaps previous sections ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xeffffc9c overlaps previous sections ppc_85xx-ld: u-boot: section .resetvec lma 0xeffffffc overlaps previous sections
Could you please have a look?
Best regards,
Wolfgang Denk
On Aug 10, 2009, at 2:56 AM, Wolfgang Denk wrote:
Dear Kumar,
I cannot build the MPC8536DS board any more using the ELDK 4.2 tool chain (gcc 4.2.2):
ppc_85xx-ld: section .bootpg [effff000 -> effff1cb] overlaps section .data.rel.local [efffe5d0 -> effff c7b] ppc_85xx-ld: section .resetvec [effffffc -> efffffff] overlaps section .u_boot_cmd [effffc9c -> f00003e b] ppc_85xx-ld: u-boot: section .bootpg lma 0xeffff000 overlaps previous sections ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xeffffc7c overlaps previous sections ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xeffffc9c overlaps previous sections ppc_85xx-ld: u-boot: section .resetvec lma 0xeffffffc overlaps previous sections
Could you please have a look?
The e1000 driver updates seem to contribute a bit to code bloat.
text data bss dec hex filename 427664 52160 300093 779917 be68d u-boot new e1000 417628 51980 300093 769701 bbea5 u-boot old e1000
Not sure what we can do about it.
- k
Kumar Gala wrote:
On Aug 10, 2009, at 2:56 AM, Wolfgang Denk wrote:
Dear Kumar,
I cannot build the MPC8536DS board any more using the ELDK 4.2 tool chain (gcc 4.2.2):
ppc_85xx-ld: section .bootpg [effff000 -> effff1cb] overlaps section .data.rel.local [efffe5d0 -> effff c7b] ppc_85xx-ld: section .resetvec [effffffc -> efffffff] overlaps section .u_boot_cmd [effffc9c -> f00003e b] ppc_85xx-ld: u-boot: section .bootpg lma 0xeffff000 overlaps previous sections ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xeffffc7c overlaps previous sections ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xeffffc9c overlaps previous sections ppc_85xx-ld: u-boot: section .resetvec lma 0xeffffffc overlaps previous sections
Could you please have a look?
The e1000 driver updates seem to contribute a bit to code bloat.
text data bss dec hex filename427664 52160 300093 779917 be68d u-boot new e1000 417628 51980 300093 769701 bbea5 u-boot old e1000
Not sure what we can do about it.
- k
Adding PCI-E support to this driver added an astounding 3000+ lines to the driver. I asked Roy to pare it back, but it was still pretty huge. If this size increase is a serious issue, I support backing this patch out and refactoring it to include only the features that are necessary for a bootloader.
regards, Ben
Dear Kumar Gala,
In message 0E1A5EEB-51E5-488D-9457-993F95553506@kernel.crashing.org you wrote:
Could you please have a look?
The e1000 driver updates seem to contribute a bit to code bloat.
...
Not sure what we can do about it.
Allocate more space for U-Boot?
Best regards,
Wolfgang Denk
On Aug 10, 2009, at 12:59 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message 0E1A5EEB-51E5-488D-9457-993F95553506@kernel.crashing.org you wrote:
Could you please have a look?
The e1000 driver updates seem to contribute a bit to code bloat.
...
Not sure what we can do about it.
Allocate more space for U-Boot?
I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
- k
Dear Kumar Gala,
In message 0EB7516A-2F14-42F7-A6ED-555ADFAB3105@kernel.crashing.org you wrote:
Allocate more space for U-Boot?
I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector, and that's it.
Best regards,
Wolfgang Denk
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote:
Allocate more space for U-Boot?
I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector, and that's it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem to be able to fit the size in 512k.
- k
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Monday, August 10, 2009 13:41 PM To: Wolfgang Denk Cc: U-Boot-Users ML; Zang Roy-R61911 Subject: Re: 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote:
Allocate more space for U-Boot?
I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector,
and that's
it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem to be able to fit the size in 512k.
We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have some plan for this? Roy
On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Monday, August 10, 2009 13:41 PM To: Wolfgang Denk Cc: U-Boot-Users ML; Zang Roy-R61911 Subject: Re: 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote:
Allocate more space for U-Boot?
I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector,
and that's
it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem to be able to fit the size in 512k.
We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have some plan for this?
So if we are going to increase the limit from 512k do we go to 768k or 1M? (Sector size on the board appears to 128k)
I would also like to know how big the flashes are on some of the other 85xx boards that u-boot supports.
- k
Kumar Gala wrote:
On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Monday, August 10, 2009 13:41 PM To: Wolfgang Denk Cc: U-Boot-Users ML; Zang Roy-R61911 Subject: Re: 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote:
Allocate more space for U-Boot?
I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector,
and that's
it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem to be able to fit the size in 512k.
We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have some plan for this?
So if we are going to increase the limit from 512k do we go to 768k or 1M? (Sector size on the board appears to 128k)
I would also like to know how big the flashes are on some of the other 85xx boards that u-boot supports.
- k
Hi Kumar, Roy,
512K is pretty big for u-boot (not unheard of, but still...). Is it really 512K or is it using a full page to hold the boot page (top 4K of memory) and one page for the env (unavoidable):
+-------------------------------------------------------- 0x1_0000_0000 | One sector dedicated for the power up page (only using 4K) +-------------------------------------------------------- 0x0_F800_0000 | One sector dedicated for the env +-------------------------------------------------------- 0x0_F000_0000 | Two sectors of u-boot +---- 0x0_E800_0000 | +-------------------------------------------------------- 0x0_E000_0000
If that is the case, you can gain a sector (less 4K) by rearranging your memory map: +-------------------------------------------------------- 0x1_0000_0000 | One page (4K) of power up vector, the rest is u-boot +---- 0x0_F800_0000 | +---- 0x0_F000_0000 | Three sectors (less 4K) of u-boot +-------------------------------------------------------- 0x0_E800_0000 | One sector dedicated for the env +-------------------------------------------------------- 0x0_E000_0000
This also makes reprogramming u-boot nicer because your power up vector and u-boot itself are contiguous.
Best regards, gvb
On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Monday, August 10, 2009 13:41 PM To: Wolfgang Denk Cc: U-Boot-Users ML; Zang Roy-R61911 Subject: Re: 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote:
> Allocate more space for U-Boot? I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector,
and that's
it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem to be able to fit the size in 512k.
We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have some plan for this?
So if we are going to increase the limit from 512k do we go to 768k or 1M? (Sector size on the board appears to 128k)
I would also like to know how big the flashes are on some of the other 85xx boards that u-boot supports.
- k
Hi Kumar, Roy,
512K is pretty big for u-boot (not unheard of, but still...). Is it really 512K or is it using a full page to hold the boot page (top 4K of memory) and one page for the env (unavoidable):
+-------------------------------------------------------- 0x1_0000_0000 | One sector dedicated for the power up page (only using 4K) +-------------------------------------------------------- 0x0_F800_0000 | One sector dedicated for the env +-------------------------------------------------------- 0x0_F000_0000 | Two sectors of u-boot +---- 0x0_E800_0000 | +-------------------------------------------------------- 0x0_E000_0000
If that is the case, you can gain a sector (less 4K) by rearranging your memory map: +-------------------------------------------------------- 0x1_0000_0000 | One page (4K) of power up vector, the rest is u-boot +---- 0x0_F800_0000 | +---- 0x0_F000_0000 | Three sectors (less 4K) of u-boot +-------------------------------------------------------- 0x0_E800_0000 | One sector dedicated for the env +-------------------------------------------------------- 0x0_E000_0000
This also makes reprogramming u-boot nicer because your power up vector and u-boot itself are contiguous.
Hi Jerry, Currently a sector shouldn't be wasted just for the 4K boot page. Your second diagram above is similar to current operation - a chunk of the 4k bootpage is wasted/unused, but other u-boot code shares the same flash sector with the 4K boot page. So a little space may be wasted, but not too much (ie less than 4K).
Best, Peter
On Aug 10, 2009, at 3:00 PM, Peter Tyser wrote:
On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Monday, August 10, 2009 13:41 PM To: Wolfgang Denk Cc: U-Boot-Users ML; Zang Roy-R61911 Subject: Re: 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote: >> Allocate more space for U-Boot? > I might turn of BEDBUG as its never been properly enabled on > e500/85xx > platforms. Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector,
and that's
it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem to be able to fit the size in 512k.
We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have some plan for this?
So if we are going to increase the limit from 512k do we go to 768k or 1M? (Sector size on the board appears to 128k)
I would also like to know how big the flashes are on some of the other 85xx boards that u-boot supports.
- k
Hi Kumar, Roy,
512K is pretty big for u-boot (not unheard of, but still...). Is it really 512K or is it using a full page to hold the boot page (top 4K of memory) and one page for the env (unavoidable):
+-------------------------------------------------------- 0x1_0000_0000 | One sector dedicated for the power up page (only using 4K) +-------------------------------------------------------- 0x0_F800_0000 | One sector dedicated for the env +-------------------------------------------------------- 0x0_F000_0000 | Two sectors of u-boot +---- 0x0_E800_0000 | +-------------------------------------------------------- 0x0_E000_0000
If that is the case, you can gain a sector (less 4K) by rearranging your memory map: +-------------------------------------------------------- 0x1_0000_0000 | One page (4K) of power up vector, the rest is u-boot +---- 0x0_F800_0000 | +---- 0x0_F000_0000 | Three sectors (less 4K) of u-boot +-------------------------------------------------------- 0x0_E800_0000 | One sector dedicated for the env +-------------------------------------------------------- 0x0_E000_0000
This also makes reprogramming u-boot nicer because your power up vector and u-boot itself are contiguous.
Hi Jerry, Currently a sector shouldn't be wasted just for the 4K boot page. Your second diagram above is similar to current operation - a chunk of the 4k bootpage is wasted/unused, but other u-boot code shares the same flash sector with the 4K boot page. So a little space may be wasted, but not too much (ie less than 4K).
Here's a readelf dump for the MPC8536DS built w/gcc 4.3.2:
Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS eff80000 000080 0596f0 00 AX 0 0 16 [ 2] .rodata PROGBITS effd96f0 059770 00f158 00 A 0 0 4 [ 3] .reloc PROGBITS effe8900 068980 002d24 00 WA 0 0 4 [ 4] .data PROGBITS effeb628 06b6a8 004d84 00 WA 0 0 8 [ 5] .data.rel.ro.loca PROGBITS efff03ac 07042c 00003c 00 WA 0 0 4 [ 6] .data.rel PROGBITS efff03e8 070468 003378 00 WA 0 0 4 [ 7] .data.rel.local PROGBITS efff3760 0737e0 0016ac 00 WA 0 0 4 [ 8] .data.rel.ro PROGBITS efff4e0c 074e8c 000020 00 WA 0 0 4 [ 9] .u_boot_cmd PROGBITS efff4e2c 074eac 000750 00 WA 0 0 4 [10] .bootpg PROGBITS effff000 07f080 0001cc 00 AX 0 0 1 [11] .resetvec PROGBITS effffffc 08007c 000004 00 AX 0 0 1
We do waste a bit of space in the bootpg (~3.5k). Here's an idea on where space is being used:
u-boot:0000053c T radeon_setmode_9200 u-boot:00000568 T ft_cpu_setup u-boot:0000058c T compute_lowest_common_dimm_parameters u-boot:000005ac t ehci_submit_async u-boot:000005b8 T nand_scan_ident u-boot:000005c8 T ext2fs_read_file u-boot:000005e4 t huft_build u-boot:00000620 D spr_map u-boot:00000640 T malloc u-boot:00000644 T ehci_submit_root u-boot:00000668 t write_bbt u-boot:0000068c t fsl_ata_exec_ata_cmd u-boot:000006dc t parse_stream_outer u-boot:00000780 T do_nand u-boot:00000810 T fsl_pci_init u-boot:0000081c T flash_get_size u-boot:00000834 T pci_header_show u-boot:00000834 t run_list_real u-boot:000008d8 T readline_into_buffer u-boot:000008f8 T compute_fsl_memctl_config_regs u-boot:00000900 T vsprintf u-boot:000009c0 T do_fat_read u-boot:00000b30 T do_fdt u-boot:00001000 d video_fontdata u-boot:00001900 D linux_logo u-boot:00001aa8 T inflate u-boot:00001d48 t e1000_init_hw u-boot:000029d8 D opcodes
- k
On Mon, 10 Aug 2009, Peter Tyser wrote:
On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote:
Kumar Gala wrote:
On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Monday, August 10, 2009 13:41 PM To: Wolfgang Denk Cc: U-Boot-Users ML; Zang Roy-R61911 Subject: Re: 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote: >> Allocate more space for U-Boot? > I might turn of BEDBUG as its never been properly enabled on > e500/85xx > platforms. Is there any problem with the bigger image which I don't
understand
yet? Normally we just move down the TEXT_BASE by a sector,
and that's
it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem
to
be able to fit the size in 512k.
We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have some
plan
for this?
So if we are going to increase the limit from 512k do we go to 768k
or
1M? (Sector size on the board appears to 128k)
I would also like to know how big the flashes are on some of the
other
85xx boards that u-boot supports.
- k
Hi Kumar, Roy,
512K is pretty big for u-boot (not unheard of, but still...). Is it really 512K or is it using a full page to hold the boot page (top 4K
of
memory) and one page for the env (unavoidable):
+--------------------------------------------------------
0x1_0000_0000
| One sector dedicated for the power up page (only using 4K) +--------------------------------------------------------
0x0_F800_0000
| One sector dedicated for the env +--------------------------------------------------------
0x0_F000_0000
| Two sectors of u-boot +----
0x0_E800_0000
| +--------------------------------------------------------
0x0_E000_0000
If that is the case, you can gain a sector (less 4K) by rearranging
your
memory map: +--------------------------------------------------------
0x1_0000_0000
| One page (4K) of power up vector, the rest is u-boot +----
0x0_F800_0000
| +----
0x0_F000_0000
| Three sectors (less 4K) of u-boot +--------------------------------------------------------
0x0_E800_0000
| One sector dedicated for the env +--------------------------------------------------------
0x0_E000_0000
This also makes reprogramming u-boot nicer because your power up
vector
and u-boot itself are contiguous.
Hi Jerry, Currently a sector shouldn't be wasted just for the 4K boot page. Your second diagram above is similar to current operation - a chunk of the 4k bootpage is wasted/unused, but other u-boot code shares the same flash sector with the 4K boot page. So a little space may be wasted, but not too much (ie less than 4K).
That is where top boot block flashes come handy... It is not just that 128K sector is a huge waste for 4K boot block, the same is true for environment...
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Monday, August 10, 2009 14:06 PM To: Zang Roy-R61911 Cc: Wolfgang Denk; U-Boot-Users ML Subject: Re: 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
-----Original Message----- From: Kumar Gala [mailto:galak@kernel.crashing.org] Sent: Monday, August 10, 2009 13:41 PM To: Wolfgang Denk Cc: U-Boot-Users ML; Zang Roy-R61911 Subject: Re: 85xx: MPC8536DS board does not build
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote:
Allocate more space for U-Boot?
I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
Is there any problem with the bigger image which I don't
understand
yet? Normally we just move down the TEXT_BASE by a sector,
and that's
it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like
gcc-4.3 seem to
be able to fit the size in 512k.
We may have more requirements to support graphic in u-boot. Sooner and later, the size will exceed 512K. Should we have
some plan
for this?
So if we are going to increase the limit from 512k do we go to 768k or 1M? (Sector size on the board appears to 128k)
If there is no special reason, I'd like to expand it to 768K. But my concern here is that it is better to limit 8536DS image to 512K. For SD/NAND boot code, the u-boot will be copy to L2 cache. It is only 512K.
I would also like to know how big the flashes are on some of the other 85xx boards that u-boot supports. From 8540ads board, at lease we may have 4M flash to use considering the
swap. Roy
On Mon, 10 Aug 2009, Kumar Gala wrote:
On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
Dear Kumar Gala,
In message <0EB7516A-2F14-42F7- A6ED-555ADFAB3105@kernel.crashing.org> you wrote:
Allocate more space for U-Boot?
I might turn of BEDBUG as its never been properly enabled on e500/85xx platforms.
Is there any problem with the bigger image which I don't understand yet? Normally we just move down the TEXT_BASE by a sector, and that's it.
Not specifically, its just that ever 85xx image to date has been 512k. I'm just trying to avoid this being the first one that changes that historic fact. Especially since compilers like gcc-4.3 seem to be able to fit the size in 512k.
Off of 512K something like 1/3 is empty in e.g. MPC8548CDS. The very last sector contains fixed location power-on boot vector, the beginning of those 512K has actual U-Boot code and the hole between them is big enough to fit an entire sector for environment.
--- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
participants (7)
-
Ben Warren -
Jerry Van Baren -
ksi＠koi8.net -
Kumar Gala -
Peter Tyser -
Wolfgang Denk -
Zang Roy-R61911