| Message ID | 20160725190230.13937-1-sarnold@vctlabs.com |
|---|---|
| State | Deferred |
| Delegated to: | Tom Warren |
| Headers | show |
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.
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.
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 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. > ------------------------------------------------------------ > ----------------------- >
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