[U-Boot] [PATCH] Trimslice config: update for Trimslice so SPI flash works
From: Steve Arnold stephen.arnold42@gmail.com
This updates the defaults for trimslice so it matches the last vendor config. Use the tegra-uboot-flasher tools to create mmc and spi flash images and flash to the device. Can optionally replace boot.scr with extlinux.conf configuration. Tested on Trimslice Diskless (with SSD).
Signed-off-by: Stephen L Arnold nerdboy@gentoo.org Cc: Tom Warren TWarren@nvidia.com --- Assumptions, caveats, and unknowns: - changes should be isolated to Trimslice - unknown if other Trimslice models use different values - only one Compulab dts u-boot release, so probably not - only tested on a single model, Trimslice Diskless
include/configs/tegra-common-post.h | 2 ++ include/configs/tegra20-common.h | 6 ++++++ include/configs/trimslice.h | 14 ++++++++++++++ 3 files changed, 22 insertions(+) ---
diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h index b206ce4..3021d8e 100644 --- a/include/configs/tegra-common-post.h +++ b/include/configs/tegra-common-post.h @@ -75,7 +75,9 @@ #define BOARD_EXTRA_ENV_SETTINGS #endif
+#ifndef CONFIG_SYS_LOAD_ADDR #define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR +#endif
#ifndef CONFIG_CHROMEOS_EXTRA_ENV_SETTINGS #define CONFIG_CHROMEOS_EXTRA_ENV_SETTINGS diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index 00e85c4..b1b8819 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -32,7 +32,9 @@ /*----------------------------------------------------------------------- * Physical Memory Map */ +#ifndef CONFIG_TARGET_TRIMSLICE #define CONFIG_SYS_TEXT_BASE 0x00110000 +#endif
/* * Memory layout for where various images get loaded by boot scripts: @@ -58,6 +60,7 @@ * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows * for the FDT/DTB to be up to 1M, which is hopefully plenty. */ +#ifndef CONFIG_TARGET_TRIMSLICE #define CONFIG_LOADADDR 0x01000000 #define MEM_LAYOUT_ENV_SETTINGS \ "scriptaddr=0x10000000\0" \ @@ -65,6 +68,7 @@ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ "fdt_addr_r=0x02000000\0" \ "ramdisk_addr_r=0x02100000\0" +#endif
/* Defines for SPL */ #define CONFIG_SPL_TEXT_BASE 0x00108000 @@ -92,7 +96,9 @@ */ #define CONFIG_USB_EHCI_TXFIFO_THRESH 10 #define CONFIG_EHCI_IS_TDI +#ifndef CONFIG_TARGET_TRIMSLICE #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 1 +#endif
#define CONFIG_SYS_NAND_SELF_INIT #define CONFIG_SYS_NAND_ONFI_DETECTION diff --git a/include/configs/trimslice.h b/include/configs/trimslice.h index b761640..47149eb 100644 --- a/include/configs/trimslice.h +++ b/include/configs/trimslice.h @@ -14,6 +14,20 @@ /* High-level configuration options */ #define CONFIG_TEGRA_BOARD_STRING "Compulab Trimslice"
+/* default trimslice settings (different than tegra20-common.h) */ +#define CONFIG_SYS_LOAD_ADDR 0x00A00800 +#define CONFIG_SYS_TEXT_BASE 0x0010E000 + +#define CONFIG_LOADADDR 0x00408000 +#define MEM_LAYOUT_ENV_SETTINGS \ + "scriptaddr=0x10000000\0" \ + "pxefile_addr_r=0x10100000\0" \ + "kernel_addr_r=0x01000000\0" \ + "fdt_addr_r=0x02000000\0" \ + "ramdisk_addr_r=0x02100000\0" + +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 2 + /* Board-specific serial config */ #define CONFIG_TEGRA_ENABLE_UARTA #define CONFIG_TEGRA_UARTA_GPU
On 07/25/2016 01:02 PM, Stephen Arnold wrote:
From: Steve Arnold stephen.arnold42@gmail.com
This updates the defaults for trimslice so it matches the last vendor config. Use the tegra-uboot-flasher tools to create mmc and spi flash images and flash to the device. Can optionally replace boot.scr with extlinux.conf configuration. Tested on Trimslice Diskless (with SSD).
There should be no need for any of the values to be specific to Trimslice. What issues does this patch attempt to solve? Note: I'm looking for a specific debugged problem, not a generic "it doesn't work" explanation. To work out what's wrong, you likely need to connect to the serial port on Trimslice and view its output. At least my Trimslice came with the required cable for this, assuming you have a regular RS-232 level DB-9/DE-9 UART on some other PC to connect it to.
diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h
+#ifndef CONFIG_TARGET_TRIMSLICE #define CONFIG_SYS_TEXT_BASE 0x00110000 +#endif
I can't think why you'd need to change this; it's a value that's internal to U-Boot, and the only reason to change it would be if the delta between CONFIG_SPL_TEXT_BASE and this value isn't large enough to fit SPL text+data+bss. If that's the case, this value should be changed for all Tegra20 boards, perhaps even all Tegra SoCs.
+#ifndef CONFIG_TARGET_TRIMSLICE #define CONFIG_LOADADDR 0x01000000 #define MEM_LAYOUT_ENV_SETTINGS \ "scriptaddr=0x10000000\0" \ @@ -65,6 +68,7 @@ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ "fdt_addr_r=0x02000000\0" \ "ramdisk_addr_r=0x02100000\0" +#endif
Those values should work just fine for Trimslice; again they're entirely internal to U-Boot and simply control where U-Boot loads various images into RAM. Everything U-Boot loads (kernel, DTB, initrd) can be loaded at a variety of addresses without issue, so there's no need for these values to exactly match the original U-Boot that Compulab published.
+#ifndef CONFIG_TARGET_TRIMSLICE #define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 1 +#endif
I believe this controls the number of ports within a USB controller, not the number of USB controllers. If so, the correct number is 1 for all Tegra SoCs, and the value isn't board-specific.
I did mention it was black and showed nothing on serial console with the default values, ie, building as-is doesn't even show u-boot trying to load (after flashing it to the SPI flash the last thing you see is "Resetting..."). Power it back up and nothing happens, no u-boot, nada.
U-Boot 2016.07-dirty (Jul 22 2016 - 22:02:41 -0700)
TEGRA20 Model: Compulab TrimSlice board Board: Compulab Trimslice DRAM: 1 GiB MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1 SF: Detected W25Q80BL with page size 256 Bytes, erase size 4 KiB, total 1 MiB In: serial Out: serial Err: serial Net: No ethernet found.
Verifying image in RAM...
crc32 for 001b6000 ... 00236fff ==> d3ffb253
Selecting SPI device...
SF: Detected W25Q80BL with page size 256 Bytes, erase size 4 KiB, total 1 MiB
Erasing SPI...
SF: 1048576 bytes @ 0x0 Erased: OK
Writing image back to SPI...
device 0 offset 0x0, size 0x81000 SF: 528384 bytes @ 0x0 Written: OK
Reading image back from SPI...
device 0 offset 0x0, size 0x81000 SF: 528384 bytes @ 0x0 Read: OK
Verifying image from flash...
crc32 for 00237000 ... 002b7fff ==> d3ffb253
Setting up environment...
## Resetting to default environment Saving Environment to SPI Flash... Erasing SPI flash...Writing to SPI flash...done
Flashing OK, rebooting...
resetting ...
When I download and and "exec" u-boot it ignores the mmc (with new u-boot on the sdcard) and falls back to USB, then reads the (old) boot.scr and boots. The mmc errors depend on whether the sdcard has a boot.scr or not, as it ignores the the extlinux.conf settings and then fails to read the kernel. Essentially it can't read the mmc device correctly; it starts but then fails.
U-Boot 2016.07-dirty (Jul 22 2016 - 22:02:41 -0700)
TEGRA20 Model: Compulab TrimSlice board Board: Compulab Trimslice DRAM: 1 GiB MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1 SF: Detected W25Q80BL with page size 256 Bytes, erase size 4 KiB, total 1 MiB In: serial Out: serial Err: serial Net: No ethernet found. Hit any key to stop autoboot: 2 1 0 Scanning MMC card ... switch to partitions #0, OK mmc0 is current device Scanning fat mmc 0 on prefix / ... ** Unrecognized filesystem type ** Scanning ext2 mmc 0 on prefix / ... 419 bytes read in 45 ms (8.8 KiB/s) boot.scr found! Executing ... ## Executing script at 00408000 ** Bad device specification : zImage ** ** Bad device specification : tegra20-trimslice ** Bad Linux ARM zImage magic! Scanning fat mmc 0 on prefix /boot/ ... ** Unrecognized filesystem type ** Scanning ext2 mmc 0 on prefix /boot/ ... ** File not found /boot/boot.scr ** Scanning USB key ... starting USB... USB0: USB EHCI 1.00 scanning bus 1 for devices... 2 USB Device(s) found Scanning fat usb 0 on prefix / ... ** Unrecognized filesystem type ** Scanning ext2 usb 0 on prefix / ... 488 bytes read in 81 ms (5.9 KiB/s) boot.scr found! Executing ... ## Executing script at 00408000 5314344 bytes read in 538 ms (9.4 MiB/s) 21172 bytes read in 269 ms (76.2 KiB/s) Kernel image @ 0x408000 [ 0x000000 - 0x511728 ] ## Flattened Device Tree blob at 2c000000 Booting using the fdt blob at 0x2c000000 Loading Device Tree to 2bff7000, end 2bfff2b3 ... OK
If you have any specific suggestions on what to change/test (besides "don't do that") I'm all ears...
Steve
On Tue, Jul 26, 2016 at 11:17 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/25/2016 01:02 PM, Stephen Arnold wrote:
From: Steve Arnold stephen.arnold42@gmail.com
This updates the defaults for trimslice so it matches the last vendor config. Use the tegra-uboot-flasher tools to create mmc and spi flash images and flash to the device. Can optionally replace boot.scr with extlinux.conf configuration. Tested on Trimslice Diskless (with SSD).
There should be no need for any of the values to be specific to Trimslice. What issues does this patch attempt to solve? Note: I'm looking for a specific debugged problem, not a generic "it doesn't work" explanation. To work out what's wrong, you likely need to connect to the serial port on Trimslice and view its output. At least my Trimslice came with the required cable for this, assuming you have a regular RS-232 level DB-9/DE-9 UART on some other PC to connect it to.
diff --git a/include/configs/tegra20-common.h
b/include/configs/tegra20-common.h
+#ifndef CONFIG_TARGET_TRIMSLICE
#define CONFIG_SYS_TEXT_BASE 0x00110000 +#endif
I can't think why you'd need to change this; it's a value that's internal to U-Boot, and the only reason to change it would be if the delta between CONFIG_SPL_TEXT_BASE and this value isn't large enough to fit SPL text+data+bss. If that's the case, this value should be changed for all Tegra20 boards, perhaps even all Tegra SoCs.
+#ifndef CONFIG_TARGET_TRIMSLICE
#define CONFIG_LOADADDR 0x01000000 #define MEM_LAYOUT_ENV_SETTINGS \ "scriptaddr=0x10000000\0" \ @@ -65,6 +68,7 @@ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ "fdt_addr_r=0x02000000\0" \ "ramdisk_addr_r=0x02100000\0" +#endif
Those values should work just fine for Trimslice; again they're entirely internal to U-Boot and simply control where U-Boot loads various images into RAM. Everything U-Boot loads (kernel, DTB, initrd) can be loaded at a variety of addresses without issue, so there's no need for these values to exactly match the original U-Boot that Compulab published.
+#ifndef CONFIG_TARGET_TRIMSLICE
#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 1 +#endif
I believe this controls the number of ports within a USB controller, not the number of USB controllers. If so, the correct number is 1 for all Tegra SoCs, and the value isn't board-specific.
On 07/26/2016 12:49 PM, Steve Arnold wrote:
I did mention it was black and showed nothing on serial console with the default values, ie, building as-is doesn't even show u-boot trying to load (after flashing it to the SPI flash the last thing you see is "Resetting..."). Power it back up and nothing happens, no u-boot, nada.
It looks like there's some issue if the total flash image size is over 512KiB. (The physical flash chip is 1MiB). I'm investigating whether this is expected and what to do about it. The change to CONFIG_SYS_TEXT_BASE accidentally solves this, since it currently happens to shrink the image size enough not to hit this apparent limit.
So is there a fix to be had by maybe shifting both CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE a little bit?
Steve
On Tue, Jul 26, 2016 at 2:14 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/26/2016 12:49 PM, Steve Arnold wrote:
I did mention it was black and showed nothing on serial console with the default values, ie, building as-is doesn't even show u-boot trying to load (after flashing it to the SPI flash the last thing you see is "Resetting..."). Power it back up and nothing happens, no u-boot, nada.
It looks like there's some issue if the total flash image size is over 512KiB. (The physical flash chip is 1MiB). I'm investigating whether this is expected and what to do about it. The change to CONFIG_SYS_TEXT_BASE accidentally solves this, since it currently happens to shrink the image size enough not to hit this apparent limit.
On 07/26/2016 03:45 PM, Steve Arnold wrote:
So is there a fix to be had by maybe shifting both CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE a little bit?
Steve
On Tue, Jul 26, 2016 at 2:14 PM, Stephen Warren <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org> wrote:
On 07/26/2016 12:49 PM, Steve Arnold wrote: I did mention it was black and showed nothing on serial console with the default values, ie, building as-is doesn't even show u-boot trying to load (after flashing it to the SPI flash the last thing you see is "Resetting..."). Power it back up and nothing happens, no u-boot, nada. It looks like there's some issue if the total flash image size is over 512KiB. (The physical flash chip is 1MiB). I'm investigating whether this is expected and what to do about it. The change to CONFIG_SYS_TEXT_BASE accidentally solves this, since it currently happens to shrink the image size enough not to hit this apparent limit.
Changing CONFIG_SPL_TEXT_BASE won't have any effect on this; size matters not location.
As I mentioned, changing CONFIG_SYS_TEXT_BASE currently avoids the issue, but hopefully we can find something better.
Steve/Stephen,
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Tuesday, July 26, 2016 2:57 PM To: Steve Arnold nerdboy422@gmail.com Cc: Stephen Arnold sarnold@vctlabs.com; u-boot@lists.denx.de; Stephen L Arnold nerdboy@gentoo.org; Tom Warren TWarren@nvidia.com; Simon Glass sjg@chromium.org Subject: Re: [U-Boot] [PATCH] Trimslice config: update for Trimslice so SPI flash works
On 07/26/2016 03:45 PM, Steve Arnold wrote:
So is there a fix to be had by maybe shifting both CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE a little bit?
Steve
On Tue, Jul 26, 2016 at 2:14 PM, Stephen Warren <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org> wrote:
On 07/26/2016 12:49 PM, Steve Arnold wrote: I did mention it was black and showed nothing on serial console with the default values, ie, building as-is doesn't even show u-boot trying to load (after flashing it to the SPI flash the last thing you see is "Resetting..."). Power it back up and nothing happens, no u-boot, nada. It looks like there's some issue if the total flash image size is over 512KiB. (The physical flash chip is 1MiB). I'm investigating whether this is expected and what to do about it. The change to CONFIG_SYS_TEXT_BASE accidentally solves this, since it currently happens to shrink the image size enough not to hit this apparent limit.Changing CONFIG_SPL_TEXT_BASE won't have any effect on this; size matters not location.
As I mentioned, changing CONFIG_SYS_TEXT_BASE currently avoids the issue, but hopefully we can find something better.
Was this ever resolved? If so please post an updated patch. I' like to get this out of my Patchwork queue.
Thanks,
Tom -- nvpublic
On 09/01/2016 04:36 PM, Tom Warren wrote:
Steve/Stephen,
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Tuesday, July 26, 2016 2:57 PM To: Steve Arnold nerdboy422@gmail.com Cc: Stephen Arnold sarnold@vctlabs.com; u-boot@lists.denx.de; Stephen L Arnold nerdboy@gentoo.org; Tom Warren TWarren@nvidia.com; Simon Glass sjg@chromium.org Subject: Re: [U-Boot] [PATCH] Trimslice config: update for Trimslice so SPI flash works
On 07/26/2016 03:45 PM, Steve Arnold wrote:
So is there a fix to be had by maybe shifting both CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE a little bit?
Steve
On Tue, Jul 26, 2016 at 2:14 PM, Stephen Warren <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org> wrote:
On 07/26/2016 12:49 PM, Steve Arnold wrote: I did mention it was black and showed nothing on serial console with the default values, ie, building as-is doesn't even show u-boot trying to load (after flashing it to the SPI flash the last thing you see is "Resetting..."). Power it back up and nothing happens, no u-boot, nada. It looks like there's some issue if the total flash image size is over 512KiB. (The physical flash chip is 1MiB). I'm investigating whether this is expected and what to do about it. The change to CONFIG_SYS_TEXT_BASE accidentally solves this, since it currently happens to shrink the image size enough not to hit this apparent limit.Changing CONFIG_SPL_TEXT_BASE won't have any effect on this; size matters not location.
As I mentioned, changing CONFIG_SYS_TEXT_BASE currently avoids the issue, but hopefully we can find something better.
Was this ever resolved? If so please post an updated patch. I' like to get this out of my Patchwork queue.
It was superseded by "ARM: tegra: fix trimslice environment location", which is already applied.
Stephen,
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Thursday, September 01, 2016 3:47 PM To: Tom Warren TWarren@nvidia.com; Steve Arnold nerdboy422@gmail.com Cc: Stephen Arnold sarnold@vctlabs.com; u-boot@lists.denx.de; Stephen L Arnold nerdboy@gentoo.org; Simon Glass sjg@chromium.org Subject: Re: [U-Boot] [PATCH] Trimslice config: update for Trimslice so SPI flash works
On 09/01/2016 04:36 PM, Tom Warren wrote:
Steve/Stephen,
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Tuesday, July 26, 2016 2:57 PM To: Steve Arnold nerdboy422@gmail.com Cc: Stephen Arnold sarnold@vctlabs.com; u-boot@lists.denx.de; Stephen L Arnold nerdboy@gentoo.org; Tom Warren TWarren@nvidia.com; Simon Glass sjg@chromium.org Subject: Re: [U-Boot] [PATCH] Trimslice config: update for Trimslice so SPI flash works
On 07/26/2016 03:45 PM, Steve Arnold wrote:
So is there a fix to be had by maybe shifting both CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE a little bit?
Steve
On Tue, Jul 26, 2016 at 2:14 PM, Stephen Warren <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org> wrote:
On 07/26/2016 12:49 PM, Steve Arnold wrote: I did mention it was black and showed nothing on serial console with the default values, ie, building as-is doesn't even show u-boot trying to load (after flashing it to the SPI flash the last thing you see is "Resetting..."). Power it back up and nothing happens, no u-boot, nada. It looks like there's some issue if the total flash image size is over 512KiB. (The physical flash chip is 1MiB). I'm investigating whether this is expected and what to do about it. The change to CONFIG_SYS_TEXT_BASE accidentally solves this, since it currently happens to shrink the image size enough not to hit this apparent limit.Changing CONFIG_SPL_TEXT_BASE won't have any effect on this; size matters not location.
As I mentioned, changing CONFIG_SYS_TEXT_BASE currently avoids the issue, but hopefully we can find something better.
Was this ever resolved? If so please post an updated patch. I' like to get this
out of my Patchwork queue.
It was superseded by "ARM: tegra: fix trimslice environment location", which is already applied.
Ah, missed that. Thanks!
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
Thanks again, that's one more device truly on mainline for the most important bits. I probably said that already, but I still like pointing it out ;)
Steve
On Thu, Sep 1, 2016 at 4:11 PM, Tom Warren TWarren@nvidia.com wrote:
Stephen,
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Thursday, September 01, 2016 3:47 PM To: Tom Warren TWarren@nvidia.com; Steve Arnold nerdboy422@gmail.com Cc: Stephen Arnold sarnold@vctlabs.com; u-boot@lists.denx.de; Stephen
L
Arnold nerdboy@gentoo.org; Simon Glass sjg@chromium.org Subject: Re: [U-Boot] [PATCH] Trimslice config: update for Trimslice so
SPI flash
works
On 09/01/2016 04:36 PM, Tom Warren wrote:
Steve/Stephen,
-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Tuesday, July 26, 2016 2:57 PM To: Steve Arnold nerdboy422@gmail.com Cc: Stephen Arnold sarnold@vctlabs.com; u-boot@lists.denx.de; Stephen L Arnold nerdboy@gentoo.org; Tom Warren TWarren@nvidia.com; Simon Glass sjg@chromium.org Subject: Re: [U-Boot] [PATCH] Trimslice config: update for Trimslice so SPI flash works
On 07/26/2016 03:45 PM, Steve Arnold wrote:
So is there a fix to be had by maybe shifting both CONFIG_SPL_TEXT_BASE and CONFIG_SYS_TEXT_BASE a little bit?
Steve
On Tue, Jul 26, 2016 at 2:14 PM, Stephen Warren <swarren@wwwdotorg.org mailto:swarren@wwwdotorg.org> wrote:
On 07/26/2016 12:49 PM, Steve Arnold wrote: I did mention it was black and showed nothing on serialconsole
with the default values, ie, building as-is doesn't even show u-boot trying to load (after flashing it to the SPI flash the last thing yousee is
"Resetting..."). Power it back up and nothing happens, no u-boot, nada. It looks like there's some issue if the total flash image size is over 512KiB. (The physical flash chip is 1MiB). I'm investigating whether this is expected and what to do about it. The change to CONFIG_SYS_TEXT_BASE accidentally solves this, since it currently happens to shrink the image size enough not to hit this apparentlimit.
Changing CONFIG_SPL_TEXT_BASE won't have any effect on this; size matters not location.
As I mentioned, changing CONFIG_SYS_TEXT_BASE currently avoids the issue, but hopefully we can find something better.
Was this ever resolved? If so please post an updated patch. I' like to
get this
out of my Patchwork queue.
It was superseded by "ARM: tegra: fix trimslice environment location",
which is
already applied.
Ah, missed that. Thanks!
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
participants (4)
-
Stephen Arnold -
Stephen Warren -
Steve Arnold -
Tom Warren