Lenovo T410 Coreboot
by A. Veek
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
5 months, 1 week
Re: [coreboot] On Intel Boot Guard
by Alexander Couzens
Hi Iru,
we aren't still sure which boards use Intel Boot Guard and which doesn't use it. But we expect most board use it,
because it's "recommended" by intel - as we dont recommend it.
Also there isn't yet a test script for Intel Boot Guard.
Can you post a link to that forum post?
I would like to look into a x240 flash image. If you have such board it would be nice
if you can send me a copy of the flash image via private mail.
Cheers,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)jabber.ccc.de
mobile: +4915123277221
3 years, 1 month
FOSDEM deadlines now!
by Carl-Daniel Hailfinger
Hi,
we obviously want to participate in FOSDEM.
https://fosdem.org/2016/news/2015-09-24-call-for-participation/
ACT NOW!
Some deadlines already expired. Some can still be managed.
Main track talks: Deadline 2015-10-30 (10 days left)
One hour of entertainment, huge audience.
Anyone up for the challenge?
Stands: Deadline 2015-11-13 (24 days left)
I can send in the proposal if I'm not going to be alone there.
How many tables do we want for our stand/booth(s)?
Who is coming?
Lightning talks: Deadline 2015-11-27 (38 days left)
Short and to the point. Your 15-minute elevator pitch.
Can you sell the project?
All deadlines are at 23.59 UTC
Developer room proposal: Deadline EXPIRED
Maybe some developer room will accept talks/demos from us.
Regards,
Carl-Daniel
3 years, 4 months
Porting Libreboot to the C201 Chromebook (veyron_speedy)
by Paul Kocialkowski
Over the past week or so, I've been working to get Libreboot running on
the latest ARM Chromebook: the C201, manufactured by Asus (codename
veyron_speedy). The laptop is running with a RK3288 SoC and ships with
Google's version of Coreboot preinstalled. It should require no
proprietary code nor any proprietary firmware load or microcode update
to boot, thus it would be a good fit for Libreboot, as a fully free
distribution of Coreboot.
In addition to that, the device's embedded controller (that handles
aspects of power management as well as the keyboard and a few other
things) is a microcontroller that is also running free software: the
free embedded controller firmware from Google.
Aside from that, it has a soldered Wi-Fi/bluetooth BCM4354 chip (cannot
be removed) that has a free driver but requires to load a proprietary
firmware on the chip. However, it is easy to work around that issue and
not use that chip at all, e.g. using an ath9k_htc dongle on one of the
two USB ports.
The GPU is a Mali T764, on which Luc has been doing some early work to
have free software support for it. It is uncertain[0] how long it will
take to have an usable free replacement for it, but now that there is
that hardware available, free graphics for Mali T GPUs would mean having
a recent laptop running fully free software, down to the firmware level,
without losing any major hardware feature, something that has hardly
ever been achieved yet. Thus, I believe it is of the utmost importance
to back Luc up on this, even if big players like ARM are trying hard to
make Lima not happen and to make it difficult for Luc to keep going.
Another aspect that I still have to look at in-depth is the ability to
use hardware video encoding/decoding. The RK3288 has an auxiliary
processor for that task, but it is unclear whether it can be used with
free software or not, though the first indications that I've gathered
are positive.
At this point, I've been able to boot up Debian on the device, and the
xfce4 interface is quite usable. It even runs big programs like
Iceweasel/Firefox and LibreOffice without inconveniences.
However, it cannot run desktop environments that depend on GL
acceleration, such as gnome-shell, which is a shame since those would be
a good fit for it. The CPU is simply too slow for offering a decent
experience with software rendering (llvmpipe).
Overall, I truly hope this device creates an incentive to free the last
remaining parts that can only work with proprietary software to this
day. Its potential would be huge, especially since it's a good fit for
travellers. With the security model inherited from Chromium OS, this
would be one of the safest laptops to be used by journalists or
activists. If Tails was to be ported to it, it would become easy to have
a secure and anonymous setup.
I have successfully fixed and compiled Coreboot and all the necessary
bits and pieces for the C201, so I'll be spending the next few days
sending patches, discussing how to integrate it to Libreboot and getting
the actual work done.
I also plan on documenting all my findings (especially things like how
to access UART, how to remove the SPI flash's write protect, how to
reflash it externally, etc) on my coding blog, for now.
Cheers!
References:
[0]: http://libv.livejournal.com/27461.html
--
Paul Kocialkowski, Replicant developer
Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.
Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
3 years, 5 months
Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Stefan Reinauer
* Martin Roth <gaumless(a)gmail.com> [151026 22:51]:
> I'd like to start a discussion about boards, chipsets, drivers, or
> other code that can be removed from the tree.
>
> At the coreboot conference in Bonn, we discussed this some. I believe
> that we decided to wait until the next release/branch of the coreboot
> tree before removing anything. By planning ahead and deleting the
> components immediately after the release, we can list the things that
> have been end-of-lifed in the branch release notes.
>
> By discussing this on the mailing list instead of just pushing commits
> to the tree, we can get better buy in from all interested parties.
>
>
> I'd request that these be boards & chips that are no longer being
> produced, and haven't been updated in a few years.
>
> These seem like good candidates to start the discussion:
> mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
> northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
>
> As far as I can tell, the last real contributions to these came in
> 2009 - all the changes since then have been cleanup and modifications
> for other changes across the coreboot tree.
Since 2009 is really only 6ys ago, I'm a bit hesitant about the VX800
stuff (while leaving the older CN700 / CX700 in the tree)
It also seems VIA gave up on coreboot at this point, so it might not
matter, unless we want to work on bringing them back?
Is anybody in contact with VIA at this point?
> What other directories should be removed from the tree after the next release?
I want to add the following boards (and their chipsets and super ios)
that have been in the tree and basically unmaintained for 10+ys:
* arima/hdama
* digitallogic/adl855pc
* ibm/e325
* ibm/e326
* iwill/dk8s2
* iwill/dk8x
* newisys/khepri
* tyan/s2735
* tyan/s2850
* tyan/s2875
* tyan/s2880
* tyan/s2881
* tyan/s2882
* tyan/s2885
* tyan/s2891
* tyan/s2892
* tyan/s2895
* tyan/s4880
* tyan/s4882
> Eventually it would be nice to be able to use submissions to
> board-status repo to determine what's being used. We're just not at
> that point yet.
I think this is a hard problem. Churn on a board's or chipset's code
does not necessarily coincide with a board being used or the other way
around. A target might just be stable and working well.
We need to get to the point where 100% of the boards in the tree are
boot tested 100% of the time.
Stefan
3 years, 6 months
Re: [coreboot] Announcing coreboot 4.2
by ron minnich
Nice job all. Patrick, I'm looking forward t the next release detailing how
many files and lines were removed :-)
include, oh sad, the 440lx :-)
ron
On Fri, Oct 30, 2015 at 1:38 PM Patrick Georgi <pgeorgi(a)google.com> wrote:
> (Halloween 2015 release - just as scary as that sounds)
>
> Dear coreboot community,
>
> today marks the release of coreboot 4.2, the second release on our
> time based release schedule.
> Since 4.1 there were 936 commits by 90 authors, increasing the code
> base by approximately 17000 lines of code. We saw 35 new contributors
> - welcome to coreboot! More than 34 developers were active as
> reviewers in that period.
> Thanks go to all contributors who helped shape this release.
>
> As with 4.1, the release tarballs are available at
> http://www.coreboot.org/releases/. There's also a 4.2 tag and branch
> in the git repository.
>
> This marks the first release that features a changelog comparing it to
> the previous release. There was some limited testing to make sure that
> the code is usable, and it boots on some devices. A structured test
> plan will only become part of the release procedure of future
> versions.
> I'm grateful to Martin for assembling this release's changelog.
>
> This is also the first release that will be followed by the removal of
> old, unused code. There will be a policy on how to announce
> deprecation and removal of mainboard and chipset code for future
> releases.
>
> Regards,
> Patrick
>
> Log of commit d5e6618a4f076610e683b174c4dd5108d960c785 to
> commit 439a527014fa0cb3e4ef60ba59e5c57c737b4444
>
> Changes between 4.1 and 4.2
> ---------------------------
> Build system:
> - Store a minimized coreboot config file in cbfs instead of the full config
> - Store the payload config and revision in CBFS when that info is available
> - Add -compression option for cbfs-files-y. Valid entries are now -file,
> -type, -align, and -compression
> - Change Microcode inclusion method from building .h files to pre-built
> binaries
> - Update Builder tests for each commit to test utilities and run lint tools
> - Many other small makefile and build changes and fixes
> - Remove expert mode as a Kconfig option
>
> Utilities:
> - Many fixes and updates to many utilities (158 total commits)
> - ifdtool: Update for skylake, handle region masks correctly
> - crossgcc: Update to gcc 5.2.0
> - kconfig: Add strict mode to fail on kconfig errors and warnings
> - vgabios: Significant fixes to remove issues in linking into coreboot code
> - Add script to parse MAINTAINERS file
> - Add Kconfig lint tool
> - Create a common library to share coreboot routines with utilities
> - Significant changes and cleanup to cbfstool (81 commits). Major changes:
> - Update cbfstool to change the internal location of FSP binaries when
> adding
> them
> - Decompress stage files on extraction and turn them into ELF binaries
> - Header sizes are now variable, containing extended attributes
> - Add compression tags to all cbfs headers so all cbfs files can be
> compressed
> - Add and align CBFS components in one pass instead of two
> - Add XIP support for X86 to relocate the romstage when it's added
> - Removed locate command as it's no longer needed
> - Add bootblock and cbfs_header file types so the master header knows about
> them
> - Prefer FMAP data to CBFS master header if FMAP data exists
> - Add hashes to cbfs file metadata for verification of images
>
> Payloads:
> - SeaBIOS: update stable release from 1.7.5 to 1.8.2
> - Libpayload had some significant changes (61 commits). Major changes:
> - Add support for fmap tables
> - Add support for SuperSpeed (3.0) USB hubs
> - Updates and bugfixes for DesignWare OTG controller (DWC2)
> - Add video_printf to print text with specified foreground & background
> colors
> - Updates to match changes to cbfs/cbfstool
> - Add cbgfx, a library to show graphics and text on a display
> - Read cbfs offset and size from sysinfo when available
>
> Vendorcode:
> - fsp_baytrail: Support Baytrail FSP Gold 4 release
> - AMD binary PI: add support for fan control
> - Work to get AMD AGESA to compile correctly as 64-bit code
> - Add standalone (XIP) verstage support for x86 to verify romstage
>
> Mainboards:
> - New Mainboards:
> - apple/macbookair4_2 - Sandy/Ivy Bridge with Panther / Cougar point
> chipset
> - asus/kgpe-d16 - AMD Family 10, SB700/SR5650 platform
> - emulation/spike-riscv - RISCV virtualized platform
> - google/chell - Intel Skylake chrome platform
> - google/cyan - Intel Braswell chrome platform
> - google/glados - Intel Skylake chrome platform
> - google/lars - Intel Skylake chrome platform
> - intel/kunimitsu - Intel Skylake chrome platform
> - intel/sklrvp - Intel Skylake reference platform
> - intel/strago - Intel Braswell chrome platform
> - Cleanups of many mainboards - several patches each for:
> - amd/bettong
> - getac/p470
> - google/auron, google/smaug and google/veyron_rialto
> - pcengines/apu1
> - siemens/mc_tcu3
> - Combine the google/veyron_(jerry, mighty, minnie, pinkie, shark &
> speedy)
> mainboards into the single google/veyron mainboard directory
>
> Console:
> - Add EM100 'hyper term' spi console support in ramstage & smm
> - Add console support for verstage
>
> ARM:
> - armv7: use asm coded memory operations for 32/16 bit read/write
> - Many cleanups to the nvidia tegra chips (40 patches)
>
> RISC-V:
> - Add trap handling
> - Add virtual Memory setup
>
> X86:
> - Remove and re-add Rangeley and Ivy Bridge / panther point FSP platforms
> - Update microcode update parser to use stock AMD microcode blobs from CBFS
> - ACPI: Align FACS to 64 byte boundary. Fixes FWTS error
> - AMD/SB700: Init devices in early boot, restore power state after power
> failure. Add IDE/SATA asl code
> - Add initial support for AMD Socket G34 processors
> - Add tick frequency to timestamp table to calculate boot times more
> accurately
> - Unify X86 romstage / ramstage linking to match other platforms
> - Start preparing X86 bootblock for non-memory-mapped BIOS media
> - cpu/amd/car: Add Suspend to RAM (S3) support
> - Native VGA init fixes on several platforms
> - Significant updates to FSP 1.1 code for cleanup and cbfstool changes
> - SMMhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG to
> prevent
> the memory sinkhole smm hack
> Drivers:
> - Add native text mode support for the Aspeed AST2050
> - w83795: Add support for for fan control and voltage monitoring
> - Intel GMA ACPI consolidation and improvements
> - Set up the 8254 timer before running option ROMs
> - Resource allocator: Page align memory mapped PCI resources
>
> Lib:
> - Derive fmap name from offset/size
> - Several edid fixes
> - Updates to cbfs matching changes in cbfstool
>
> Submodules:
> -----------
> 3rdparty/blobs:
> Total commits: 16
> Log of commit 61d663e39bc96530900c3232ccea7365ab9dad0b to
> commit aab093f0824b6d26b57a1ce220ba0d577e37ad49
> - AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)
> - AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1)
> - Update microcode to binary blobs. Remove old .h microcode files
>
> 3rdparty/arm-trusted-firmware:
> - No Changes
>
> 3rdparty/vboot:
> Total commits: 41
> Log of commit fbf631c845c08299f0bcbae3f311c5807d34c0d6 to
> commit d6723ed12b429834c2627c009aab58f0db20ce73
> - Update the code to determine the write protect line gpio value
> - Several updates to futility and image_signing scripts
> - Update crossystem to accommodate Android mosys location
> - Support reboot requested by secdata
> - Add NV flag to default boot legacy OS
>
> util/nvidia/cbootimage:
> - No Changes
>
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
3 years, 6 months
Re: [coreboot] coreboot binary policy
by Stefan Reinauer
* Alex Gagniuc <mr.nuke.me(a)gmail.com> [151030 18:59]:
> On Fri, Oct 30, 2015 at 9:03 AM, Marc Jones <marcj303(a)gmail.com> wrote:
> > It might be a good idea, but that might be too limiting
>
> I think historically, it has been assumed that everything in blobs is
> open up for RE and modification. There are plenty of examples of
> people reverse-engineering stuff in blobs, and also modifying the blob
> itself [1]. First and foremost, we should protect the project, and
> with that, our contributors.
Alex, I think this is a great suggestion, but as I have explained to you
in person before, from a perspective of reaching a legal agreement this
is almost equivalent (if not more effort) than working on an agreement
to open source that code to begin with. The coreboot project's objective
is not to reimplement what other people have done, but to change the
industry to create more open computing devices.
That said, if you want to drive an example terms of use with your
employer that fulfills your advanced criteria, you are more than welcome
to do so, and I believe it would serve as a role model in the silicon
industry.
I am happy to help with such an arrangement, and would be even happier
if we could just open source the code in question. But we can take this
offline.
> We can have a process where we might grant exceptions from these
> (proposed) rules to certain non-ISA blobs. For example, we might
> exempt microcode on the basis that (we believe) It's impractical to
> RE, and keeping that avenue open is not of any particular value.
Reverse engineering is impractical in all cases. Specifically this
document is focussing on what BLOBs we can ship in the 3rdparty/blobs
directory, not generally which BLOBs are allowed in coreboot.
In terms of many blobs (like FSP, hint hint), we are not even at the
point where we can redistribute them in 3rdparty/blobs yet. Adding
additional restrictions would, if anything, change nothing at all
(except that our users will have to get their own collection of BLOBs if
they want to participate).
> We can grandfather in existing blobs, or we can have a process where
> we keep them for a while (a year?) while we try to work out
> appropriate licensing terms with the power-that-be of said blob.
I would like to get the existing BLOBs into 3rdparty/blobs first before
we talk about removing them in a year (e.g. FSP, hint hint).
All the best,
Stefan
3 years, 6 months
Announcing coreboot 4.2
by Patrick Georgi
(Halloween 2015 release - just as scary as that sounds)
Dear coreboot community,
today marks the release of coreboot 4.2, the second release on our
time based release schedule.
Since 4.1 there were 936 commits by 90 authors, increasing the code
base by approximately 17000 lines of code. We saw 35 new contributors
- welcome to coreboot! More than 34 developers were active as
reviewers in that period.
Thanks go to all contributors who helped shape this release.
As with 4.1, the release tarballs are available at
http://www.coreboot.org/releases/. There's also a 4.2 tag and branch
in the git repository.
This marks the first release that features a changelog comparing it to
the previous release. There was some limited testing to make sure that
the code is usable, and it boots on some devices. A structured test
plan will only become part of the release procedure of future
versions.
I'm grateful to Martin for assembling this release's changelog.
This is also the first release that will be followed by the removal of
old, unused code. There will be a policy on how to announce
deprecation and removal of mainboard and chipset code for future
releases.
Regards,
Patrick
Log of commit d5e6618a4f076610e683b174c4dd5108d960c785 to
commit 439a527014fa0cb3e4ef60ba59e5c57c737b4444
Changes between 4.1 and 4.2
---------------------------
Build system:
- Store a minimized coreboot config file in cbfs instead of the full config
- Store the payload config and revision in CBFS when that info is available
- Add -compression option for cbfs-files-y. Valid entries are now -file,
-type, -align, and -compression
- Change Microcode inclusion method from building .h files to pre-built binaries
- Update Builder tests for each commit to test utilities and run lint tools
- Many other small makefile and build changes and fixes
- Remove expert mode as a Kconfig option
Utilities:
- Many fixes and updates to many utilities (158 total commits)
- ifdtool: Update for skylake, handle region masks correctly
- crossgcc: Update to gcc 5.2.0
- kconfig: Add strict mode to fail on kconfig errors and warnings
- vgabios: Significant fixes to remove issues in linking into coreboot code
- Add script to parse MAINTAINERS file
- Add Kconfig lint tool
- Create a common library to share coreboot routines with utilities
- Significant changes and cleanup to cbfstool (81 commits). Major changes:
- Update cbfstool to change the internal location of FSP binaries when adding
them
- Decompress stage files on extraction and turn them into ELF binaries
- Header sizes are now variable, containing extended attributes
- Add compression tags to all cbfs headers so all cbfs files can be compressed
- Add and align CBFS components in one pass instead of two
- Add XIP support for X86 to relocate the romstage when it's added
- Removed locate command as it's no longer needed
- Add bootblock and cbfs_header file types so the master header knows about
them
- Prefer FMAP data to CBFS master header if FMAP data exists
- Add hashes to cbfs file metadata for verification of images
Payloads:
- SeaBIOS: update stable release from 1.7.5 to 1.8.2
- Libpayload had some significant changes (61 commits). Major changes:
- Add support for fmap tables
- Add support for SuperSpeed (3.0) USB hubs
- Updates and bugfixes for DesignWare OTG controller (DWC2)
- Add video_printf to print text with specified foreground & background
colors
- Updates to match changes to cbfs/cbfstool
- Add cbgfx, a library to show graphics and text on a display
- Read cbfs offset and size from sysinfo when available
Vendorcode:
- fsp_baytrail: Support Baytrail FSP Gold 4 release
- AMD binary PI: add support for fan control
- Work to get AMD AGESA to compile correctly as 64-bit code
- Add standalone (XIP) verstage support for x86 to verify romstage
Mainboards:
- New Mainboards:
- apple/macbookair4_2 - Sandy/Ivy Bridge with Panther / Cougar point
chipset
- asus/kgpe-d16 - AMD Family 10, SB700/SR5650 platform
- emulation/spike-riscv - RISCV virtualized platform
- google/chell - Intel Skylake chrome platform
- google/cyan - Intel Braswell chrome platform
- google/glados - Intel Skylake chrome platform
- google/lars - Intel Skylake chrome platform
- intel/kunimitsu - Intel Skylake chrome platform
- intel/sklrvp - Intel Skylake reference platform
- intel/strago - Intel Braswell chrome platform
- Cleanups of many mainboards - several patches each for:
- amd/bettong
- getac/p470
- google/auron, google/smaug and google/veyron_rialto
- pcengines/apu1
- siemens/mc_tcu3
- Combine the google/veyron_(jerry, mighty, minnie, pinkie, shark & speedy)
mainboards into the single google/veyron mainboard directory
Console:
- Add EM100 'hyper term' spi console support in ramstage & smm
- Add console support for verstage
ARM:
- armv7: use asm coded memory operations for 32/16 bit read/write
- Many cleanups to the nvidia tegra chips (40 patches)
RISC-V:
- Add trap handling
- Add virtual Memory setup
X86:
- Remove and re-add Rangeley and Ivy Bridge / panther point FSP platforms
- Update microcode update parser to use stock AMD microcode blobs from CBFS
- ACPI: Align FACS to 64 byte boundary. Fixes FWTS error
- AMD/SB700: Init devices in early boot, restore power state after power
failure. Add IDE/SATA asl code
- Add initial support for AMD Socket G34 processors
- Add tick frequency to timestamp table to calculate boot times more accurately
- Unify X86 romstage / ramstage linking to match other platforms
- Start preparing X86 bootblock for non-memory-mapped BIOS media
- cpu/amd/car: Add Suspend to RAM (S3) support
- Native VGA init fixes on several platforms
- Significant updates to FSP 1.1 code for cleanup and cbfstool changes
- SMMhandler: on i945..nehalem, crash if LAPIC overlaps with ASEG to prevent
the memory sinkhole smm hack
Drivers:
- Add native text mode support for the Aspeed AST2050
- w83795: Add support for for fan control and voltage monitoring
- Intel GMA ACPI consolidation and improvements
- Set up the 8254 timer before running option ROMs
- Resource allocator: Page align memory mapped PCI resources
Lib:
- Derive fmap name from offset/size
- Several edid fixes
- Updates to cbfs matching changes in cbfstool
Submodules:
-----------
3rdparty/blobs:
Total commits: 16
Log of commit 61d663e39bc96530900c3232ccea7365ab9dad0b to
commit aab093f0824b6d26b57a1ce220ba0d577e37ad49
- AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)
- AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1)
- Update microcode to binary blobs. Remove old .h microcode files
3rdparty/arm-trusted-firmware:
- No Changes
3rdparty/vboot:
Total commits: 41
Log of commit fbf631c845c08299f0bcbae3f311c5807d34c0d6 to
commit d6723ed12b429834c2627c009aab58f0db20ce73
- Update the code to determine the write protect line gpio value
- Several updates to futility and image_signing scripts
- Update crossystem to accommodate Android mosys location
- Support reboot requested by secdata
- Add NV flag to default boot legacy OS
util/nvidia/cbootimage:
- No Changes
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
3 years, 6 months
