[PATCH] i.MX6: esdctl: Fix a bug in memory probing code
Old version of imx6_mmdc_add_mem did not use 64-bit arithmetic and
thus was prone to overflow on systems with 4GB of memory. It also did
not take into account the fact that i.MX6 does not support more than
3.8GB of memory and would report incorrect memory size. This commit
fixes both issues.
Signed-off-by: Andrey Smirnov
---
arch/arm/mach-imx/esdctl.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-imx/esdctl.c b/arch/arm/mach-imx/esdctl.c
index f0d2b5b..566ec54 100644
--- a/arch/arm/mach-imx/esdctl.c
+++ b/arch/arm/mach-imx/esdctl.c
@@ -38,6 +38,13 @@
#include
#include
+
+#define MIN(a,b) \
+ ({ __typeof__ (a) _a = (a); \
+ __typeof__ (b) _b = (b);\
+ _a < _b ? _a : _b; })
+
+
struct imx_esdctl_data {
unsigned long base0;
unsigned long base1;
@@ -280,11 +287,28 @@ static void imx_esdctl_v4_add_mem(void *esdctlbase,
struct imx_esdctl_data *data
data->base1, imx_v4_sdram_size(esdctlbase, 1));
}
+/*
+ On i.MX6 the adress space reserved for SDRAM is 0x1000 to 0x
+ which makse the maximum supported RAM size to be 0xF000
+ */
+#define IMX6_MAX_SDRAM_SIZE (0xF000)
+
static void imx6_mmdc_add_mem(void *mmdcbase, struct imx_esdctl_data *data)
{
+ /* It is possible to have a configuration in which both chip
+* selects of the memory controller have 2GB of memory. To
+* account for this case we need to use 64-bit arithmetic and
+* also make sure we do not report more than
+* IMX6_MAX_SDRAM_SIZE bytes of memory availible */
+
+ u64 size_cs0 = imx6_mmdc_sdram_size(mmdcbase, 0);
+ u64 size_cs1 = imx6_mmdc_sdram_size(mmdcbase, 1);
+ u64 total= size_cs0 + size_cs1;
+
+ resource_size_t size = MIN(total, IMX6_MAX_SDRAM_SIZE);
+
arm_add_mem_device("ram0", data->base0,
- imx6_mmdc_sdram_size(mmdcbase, 0) +
- imx6_mmdc_sdram_size(mmdcbase, 1));
+ size);
}
static int imx_esdctl_probe(struct device_d *dev)
--
1.9.3
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP
Hallo Sebastian, On Thu, Nov 13, 2014 at 12:31:08PM +0100, Sebastian Hesselbarth wrote: > >I don't manage to boot via UART. The usual outcome is: > > > >Sending boot message. Please reboot the target...\ > >Sending boot image... > > 0 % > > [..] > > 2 % > > [..] > > 5 % > > [..] > > 7 % > > [..] > > 10 % > > [..] > > 13 % [..xmodem: Connection timed out > > > >If I try to boot a barebox-globalscale-mirabox.img (provided by > >ezequielg in #mvlinux), I get: > > > >$ scripts/kwboot -b ../barebox-globalscale-mirabox.img -t /dev/ttyUSB1 > >Sending boot message. Please reboot the target...\ > >Sending boot image... > > 0 % > > [..] > > 5 % > > [..] > > 10 % > > [..] > > 14 % > > [..] > > 19 % > > [..] > > 24 % [.DDR3 Training Sequence - Ver 2.1.6 > >DDR3 Training Sequence - Number of DIMMs detected: 1 > >+xmodem: Connection timed out > > That indeed is strange and indicates some general problem. Can you retry > with setting the baudrate to 115200 (-b 115200 IIRC). Doesn't change anything. In fact the tty is already configured for 115200 Baud. And I would expect that on a mismatch it wouldn't always die just after the header is uploaded. Just noticed that my binary.0 was corrupted as I extraced it from a nand dump that also included the oob area ... With a proper image I get barebox up now. > >And funny enough, during testing I added > > > > select(fd + 1, &rfds, NULL, NULL, &tv); > > > >to kwboot_tty_recv after the read, this results reproduibly into a > >single NAK and "BootROM: Invalid header checksum". This is still not explained. I would have expected that this select doesn't do anything noticable on the remote end. > >When booting from nand (as shipped by Netgear) the output starts with: > > You need to set boot source byte to UART (0x52 IIRC). Otherwise the NAND Just for the log: UART = 0x69. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 2/2] ARM: omap: Add bootsource serial to xload
Am 13.11.2014 um 08:37 schrieb Sascha Hauer: On Wed, Nov 12, 2014 at 10:24:48AM +0100, Jan Weitzel wrote: Am 12.11.2014 um 09:22 schrieb Sascha Hauer: Hi Jan, On Wed, Nov 12, 2014 at 08:41:54AM +0100, Jan Weitzel wrote: If booted from serial via xmodem, also get barebox.bin per xmodem For first stage you need the .pblx file instead of MLO. Signed-off-by: Jan Weitzel --- arch/arm/mach-omap/Kconfig | 7 +++ arch/arm/mach-omap/xload.c | 46 ++ 2 files changed, 53 insertions(+) diff --git a/arch/arm/mach-omap/Kconfig b/arch/arm/mach-omap/Kconfig index f9b5ec3..953dd8f 100644 --- a/arch/arm/mach-omap/Kconfig +++ b/arch/arm/mach-omap/Kconfig @@ -118,6 +118,13 @@ config OMAP4_USBBOOT You need the utility program omap4_usbboot to boot from USB. Please read omap4_usb_booting.txt for more information. +config OMAP_SERIALBOOT + bool + default y No default y please. Better keep it disabled by default because the OMAP4 xload configs are quiet tight I think. Is adding it to am335x_mlo_defconfig ok? Because of the size I added the ARCH_AM33XX dependency. I overlooked this dependency. So the dependency is only because of the binary size and it's otherwise usable on Omap aswell? In this case I suggest to drop the dependency. And yes, ok to add it to the am335x_mlo_defconfig. Only AM335x set BOOTSOURCE_SERIAL by now Jan Sascha ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH v2] ARM: omap: Add bootsource serial to xload
If booted from serial via xmodem, also get barebox.bin per xmodem
For first stage you need the .pblx file instead of MLO.
Add serial boot to am335x_mlo_defconfig introduce some cleanups
by savedefconfig
Signed-off-by: Jan Weitzel
---
v2: make serialboot configurable
select it in am335x_mlo_defconfig
arch/arm/configs/am335x_mlo_defconfig | 4 +--
arch/arm/mach-omap/Kconfig| 9 +++
arch/arm/mach-omap/xload.c| 46 +++
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/arch/arm/configs/am335x_mlo_defconfig
b/arch/arm/configs/am335x_mlo_defconfig
index d691570..9734da6 100644
--- a/arch/arm/configs/am335x_mlo_defconfig
+++ b/arch/arm/configs/am335x_mlo_defconfig
@@ -1,12 +1,12 @@
CONFIG_ARCH_OMAP=y
CONFIG_OMAP_BUILD_IFT=y
+CONFIG_OMAP_SERIALBOOT=y
CONFIG_OMAP_MULTI_BOARDS=y
CONFIG_MACH_AFI_GF=y
CONFIG_MACH_BEAGLEBONE=y
CONFIG_MACH_PCM051=y
CONFIG_MACH_PFLA03=y
CONFIG_THUMB2_BAREBOX=y
-# CONFIG_CMD_ARM_CPUINFO is not set
# CONFIG_MEMINFO is not set
CONFIG_MMU=y
CONFIG_TEXT_BASE=0x0
@@ -37,10 +37,8 @@ CONFIG_NAND_OMAP_GPMC=y
CONFIG_MCI=y
# CONFIG_MCI_WRITE is not set
CONFIG_MCI_OMAP_HSMMC=y
-CONFIG_PINCTRL=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_BUS_OMAP_GPMC=y
-# CONFIG_FS_RAMFS is not set
# CONFIG_FS_DEVFS is not set
CONFIG_FS_FAT=y
CONFIG_FS_FAT_LFN=y
diff --git a/arch/arm/mach-omap/Kconfig b/arch/arm/mach-omap/Kconfig
index f9b5ec3..0996ed9 100644
--- a/arch/arm/mach-omap/Kconfig
+++ b/arch/arm/mach-omap/Kconfig
@@ -118,6 +118,15 @@ config OMAP4_USBBOOT
You need the utility program omap4_usbboot to boot from USB.
Please read omap4_usb_booting.txt for more information.
+config OMAP_SERIALBOOT
+ bool "enable booting from serial"
+ select XYMODEM
+ select FS_RAMFS
+ depends on ARCH_AM33XX && SHELL_NONE
+ help
+ Say Y here if you want to load the 2nd stage barebox.bin with
+ xmodem after booting from serial line.
+
config OMAP_MULTI_BOARDS
bool "Allow multiple boards to be selected"
select HAVE_DEFAULT_ENVIRONMENT_NEW
diff --git a/arch/arm/mach-omap/xload.c b/arch/arm/mach-omap/xload.c
index e9d7bbb..8d9d84c 100644
--- a/arch/arm/mach-omap/xload.c
+++ b/arch/arm/mach-omap/xload.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
struct omap_barebox_part *barebox_part;
@@ -184,6 +185,45 @@ static void *omap4_xload_boot_usb(void){
return buf;
}
+static void *omap_serial_boot(void){
+ struct console_device *cdev;
+ int ret;
+ void *buf;
+ int len;
+ int fd;
+
+ /* need temporary place to store file */
+ ret = mount("none", "ramfs", "/", NULL);
+ if (ret < 0) {
+ printf("failed to mount ramfs\n");
+ return NULL;
+ }
+
+ cdev = console_get_first_active();
+ if (!cdev) {
+ printf("failed to get console\n");
+ return NULL;
+ }
+
+ fd = open("/barebox.bin", O_WRONLY | O_CREAT);
+ if (fd < 0) {
+ printf("could not create barebox.bin\n");
+ return NULL;
+ }
+
+ ret = do_load_serial_xmodem(cdev, fd);
+ if (ret < 0) {
+ printf("loadx failed\n");
+ return NULL;
+ }
+
+ buf = read_file("/barebox.bin", &len);
+ if (!buf)
+ printf("could not read barebox.bin from serial\n");
+
+ return buf;
+}
+
/*
* Replaces the default shell in xload configuration
*/
@@ -218,6 +258,12 @@ static __noreturn int omap_xload(void)
func = omap_xload_boot_spi(barebox_part->nor_offset,
barebox_part->nor_size);
break;
+ case BOOTSOURCE_SERIAL:
+ if (IS_ENABLED(CONFIG_OMAP_SERIALBOOT)) {
+ printf("booting from serial\n");
+ func = omap_serial_boot();
+ break;
+ }
default:
printf("unknown boot source. Fall back to nand\n");
func = omap_xload_boot_nand(barebox_part->nand_offset,
--
1.9.1
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP
On 11/13/2014 11:46 AM, Uwe Kleine-König wrote: On Thu, Nov 13, 2014 at 10:53:46AM +0100, Sebastian Hesselbarth wrote: On 11/13/2014 10:09 AM, Uwe Kleine-König wrote: On Wed, Nov 12, 2014 at 12:22:22PM +0100, Sebastian Hesselbarth wrote: On 11/12/2014 11:56 AM, Uwe Kleine-König wrote: Hello again, here come the recent insights. [...] It seems to be not possible to easily dump the register space in both U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs somewhere in the middle. A difference between U-Boot and barebox is the location where the internal registers are mapped. Maybe something that depends on U-Boot's memory layout leaks into barebox because I do 2nd stage booting? Out of ideas at the moment. :-( Uwe, Nice comparison, but did you double check caches are disabled? There is no support for Dcache on mvebu SoCs in barebox atm. I would expect that U-Boot disables caches on go. But I remember there was a bug in that area some time ago. Why should U-Boot do anything on go except jumping to that location? Now I saw a different behaviour: Let's start from scratch and change one thing at a time: Can you try to UART boot barebox directly and try both eth interfaces? I don't manage to boot via UART. The usual outcome is: Sending boot message. Please reboot the target...\ Sending boot image... 0 % [..] 2 % [..] 5 % [..] 7 % [..] 10 % [..] 13 % [..xmodem: Connection timed out If I try to boot a barebox-globalscale-mirabox.img (provided by ezequielg in #mvlinux), I get: $ scripts/kwboot -b ../barebox-globalscale-mirabox.img -t /dev/ttyUSB1 Sending boot message. Please reboot the target...\ Sending boot image... 0 % [..] 5 % [..] 10 % [..] 14 % [..] 19 % [..] 24 % [.DDR3 Training Sequence - Ver 2.1.6 DDR3 Training Sequence - Number of DIMMs detected: 1 +xmodem: Connection timed out That indeed is strange and indicates some general problem. Can you retry with setting the baudrate to 115200 (-b 115200 IIRC). And funny enough, during testing I added select(fd + 1, &rfds, NULL, NULL, &tv); to kwboot_tty_recv after the read, this results reproduibly into a single NAK and "BootROM: Invalid header checksum". When booting from nand (as shipped by Netgear) the output starts with: You need to set boot source byte to UART (0x52 IIRC). Otherwise the NAND image will not boot from UART boot mode. Check out kwbimage, it should show you where and how to modify the binary. I cannot recall if kwbimage can convert it for you already, you also need to update the image header CRC. Sebastian ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP
On Thu, Nov 13, 2014 at 10:53:46AM +0100, Sebastian Hesselbarth wrote: > On 11/13/2014 10:09 AM, Uwe Kleine-König wrote: > >On Wed, Nov 12, 2014 at 12:22:22PM +0100, Sebastian Hesselbarth wrote: > >>On 11/12/2014 11:56 AM, Uwe Kleine-König wrote: > >>>Hello again, > >>> > >>>here come the recent insights. > >>[...] > >>> > >>>It seems to be not possible to easily dump the register space in both > >>>U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs > >>>somewhere in the middle. > >>> > >>>A difference between U-Boot and barebox is the location where the > >>>internal registers are mapped. Maybe something that depends on U-Boot's > >>>memory layout leaks into barebox because I do 2nd stage booting? > >>> > >>>Out of ideas at the moment. :-( > >> > >>Uwe, > >> > >>Nice comparison, but did you double check caches are disabled? There is > >>no support for Dcache on mvebu SoCs in barebox atm. > >I would expect that U-Boot disables caches on go. But I remember there > >was a bug in that area some time ago. > > Why should U-Boot do anything on go except jumping to that location? > > >Now I saw a different behaviour: > > Let's start from scratch and change one thing at a time: > > Can you try to UART boot barebox directly and try both eth interfaces? I don't manage to boot via UART. The usual outcome is: Sending boot message. Please reboot the target...\ Sending boot image... 0 % [..] 2 % [..] 5 % [..] 7 % [..] 10 % [..] 13 % [..xmodem: Connection timed out If I try to boot a barebox-globalscale-mirabox.img (provided by ezequielg in #mvlinux), I get: $ scripts/kwboot -b ../barebox-globalscale-mirabox.img -t /dev/ttyUSB1 Sending boot message. Please reboot the target...\ Sending boot image... 0 % [..] 5 % [..] 10 % [..] 14 % [..] 19 % [..] 24 % [.DDR3 Training Sequence - Ver 2.1.6 DDR3 Training Sequence - Number of DIMMs detected: 1 +xmodem: Connection timed out And funny enough, during testing I added select(fd + 1, &rfds, NULL, NULL, &tv); to kwboot_tty_recv after the read, this results reproduibly into a single NAK and "BootROM: Invalid header checksum". When booting from nand (as shipped by Netgear) the output starts with: BootROM 1.08 Booting from NAND flash DDR3 Training Sequence - Ver 2.1.7 DDR3 Training Sequence - Ended Successfully BootROM: Image checksum verification PASSED ... > If that already does not work we have to look at barebox only. That would be great, yes. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP
On 11/13/2014 10:09 AM, Uwe Kleine-König wrote: On Wed, Nov 12, 2014 at 12:22:22PM +0100, Sebastian Hesselbarth wrote: On 11/12/2014 11:56 AM, Uwe Kleine-König wrote: Hello again, here come the recent insights. [...] It seems to be not possible to easily dump the register space in both U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs somewhere in the middle. A difference between U-Boot and barebox is the location where the internal registers are mapped. Maybe something that depends on U-Boot's memory layout leaks into barebox because I do 2nd stage booting? Out of ideas at the moment. :-( Uwe, Nice comparison, but did you double check caches are disabled? There is no support for Dcache on mvebu SoCs in barebox atm. I would expect that U-Boot disables caches on go. But I remember there was a bug in that area some time ago. Why should U-Boot do anything on go except jumping to that location? Now I saw a different behaviour: Let's start from scratch and change one thing at a time: Can you try to UART boot barebox directly and try both eth interfaces? If that already does not work we have to look at barebox only. Sebastian ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Barebox with DT and kernel without DT support
On Thu, Nov 13, 2014 at 09:52:03AM +0100, Wjatscheslaw Stoljarski wrote: > Hi, > > how to provide commandline to kernel without DT support from barebox with DT? Call oftree -f before calling the kernel. This will free the internal devicetree and barebox will pass the ATAGS instead. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP
On Wed, Nov 12, 2014 at 12:22:22PM +0100, Sebastian Hesselbarth wrote: > On 11/12/2014 11:56 AM, Uwe Kleine-König wrote: > >Hello again, > > > >here come the recent insights. > [...] > > > >It seems to be not possible to easily dump the register space in both > >U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs > >somewhere in the middle. > > > >A difference between U-Boot and barebox is the location where the > >internal registers are mapped. Maybe something that depends on U-Boot's > >memory layout leaks into barebox because I do 2nd stage booting? > > > >Out of ideas at the moment. :-( > > Uwe, > > Nice comparison, but did you double check caches are disabled? There is > no support for Dcache on mvebu SoCs in barebox atm. I would expect that U-Boot disables caches on go. But I remember there was a bug in that area some time ago. Now I saw a different behaviour: Marvell>> dhcp BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 28 DHCP client bound to address 192.168.77.133 Marvell>> tftp barebox-netgear-rn104-2nd.img Using egiga1 device TFTP from server 192.168.77.157; our IP address is 192.168.77.133 Filename 'barebox-netgear-rn104-2nd.img'. Load address: 0x200 Loading: done Bytes transferred = 292299 (475cb hex) Marvell>> md 0x01f15000 That is where the descriptor ... 01f15000: 01f15010: 01f15020: 01f15030: 01f15040: 01f15050: 01f15060: 01f15070: 01f15080: 01f15090: 01f150a0: 01f150b0: 01f150c0: 01f150d0: 01f150e0: 01f150f0: Marvell>> md 0x01f12040 ... and the actual data will be located by barebox: 01f12040: 01f12050: 01f12060: 01f12070: 01f12080: 01f12090: 01f120a0: 01f120b0: 01f120c0: 01f120d0: 01f120e0: 01f120f0: 01f12100: 01f12110: 01f12120: 01f12130: Marvell>> go $loadaddr ## Starting application at 0x0200 ... barebox 2014.11.0-00127-g263044f25b47-dirty #14 Thu Nov 13 09:26:54 CET 2014 Board: NETGEAR ReadyNAS 104 SoC: Marvell 6710 rev 1 mdio_bus: miibus0: probed mvneta_setup_tx_rx: port = 0x01f11210, regbase = f107 mvneta_setup_tx_rx: port = 0x01f11520, regbase = f1074000 eth1: got preset MAC address: 28:c6:8e:36:df:57 of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19 of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19 of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19 of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19 malloc space: 0x01f0 -> 0x03df (size 31 MiB) environment load /dev/env0: No such file or directory Maybe you have to create the partition. no valid environment found on /dev/env0. Using default environment running /
Barebox with DT and kernel without DT support
Hi, how to provide commandline to kernel without DT support from barebox with DT? ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
