Re: beaglebone black: is mem=... broken?

[Paolo Pisati]

On Sun, Jan 18, 2015 at 06:38:46PM +0100, Geert Uytterhoeven wrote:
 
 The boot loader copied the DT to the end of real RAM, not to the end of
 the 256 MiB block? Hence the kernel accesses unmapped memory
 when checking the FDT header?

actually everything is below 256M since physical memory starts at
0x8000:

U-Boot# printenv loadaddr
loadaddr=0x8200
U-Boot# printenv fdtaddr
fdtaddr=0x8800
U-Boot# load mmc 0:1 ${loadaddr} zimage
reading zimage
5694816 bytes read in 318 ms (17.1 MiB/s)
U-Boot# load mmc 0:1 ${fdtaddr} am335x-boneblack.dtb
reading am335x-boneblack.dtb
29985 bytes read in 10 ms (2.9 MiB/s)
U-Boot# setenv bootargs console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro
rootfstype=ext4 rootwait debug earlyprintk mem=256M
U-Boot# bootz ${loadaddr} - ${fdtaddr}
Kernel image @ 0x8200 [ 0x00 - 0x56e560 ]
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8fff5000, end 8520 ... OK

Starting kernel ...

hangs there, and after i reset i found the aforementioned oops in __log_buf.

Here is without the mem= argument:

U-Boot SPL 2015.01 (Jan 16 2015 - 10:20:36)
MMC: block number 0x100 exceeds max(0x0)
MMC: block number 0x200 exceeds max(0x0)
*** Error - No Valid Environment Area found
Using default environment



U-Boot 2015.01 (Jan 16 2015 - 10:20:36)

   Watchdog enabled
I2C:   ready
DRAM:  512 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Net:   ethaddr not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0 
U-Boot# load mmc 0:1 ${loadaddr} zimage
reading zimage
5694816 bytes read in 318 ms (17.1 MiB/s)
U-Boot# load mmc 0:1 ${fdtaddr} am335x-boneblack.dtb
reading am335x-boneblack.dtb
29985 bytes read in 11 ms (2.6 MiB/s)
U-Boot# setenv bootargs console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro
rootfstype=ext4 rootwait debug earlyprintk   
U-Boot# bootz ${loadaddr} - ${fdtaddr}
Kernel image @ 0x8200 [ 0x00 - 0x56e560 ]
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8fff5000, end 8520 ... OK

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.19.0-rc4-1-g45aa0b7 (flag@luxor) (gcc 
version 4.8.2 (Ubuntu/Linaro 4.8.2-16ubuntu4) ) #1 SMP Fri Jan 16 10:33:22 CET5
...
-- 
bye,
p.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: beaglebone black: is mem=... broken?

[Geert Uytterhoeven]

On Sun, Jan 18, 2015 at 3:34 PM, Paolo Pisati p.pis...@gmail.com wrote:
 Boot hangs when passing mem=256M to a 3.16 kernel (but i was able to reproduce
 it with multi_v7_defconfig on a 3.19rcX kernel too):

 80e6d694: 0024  65746e49 6c616e72..$.Internal
 80e6d6a4: 72726520 203a726f 73706f4f 2035203a error: Oops: 5
 80e6d6b4: 5d31235b 504d5320 4d524120 [#1] SMP ARM
 80e6d6c4:  0012  75646f4dModu
 80e6d6d4: 2073656c 6b6e696c 69206465 3a6eles linked in:..
 80e6d6e4:    
 80e6d6f4:    6f4320300 Co
 80e6d704: 203a6d6d 70617773 20726570 20746f4emm: swapper Not
 80e6d714: 6e696174 20646574 36312e33 322d302etainted 3.16.0-2
 80e6d724: 65672d38 6972656e 33232063 62552d388-generic #38-Ub
 80e6d734: 75746e75   002duntu..-.
 80e6d744:  6b736174 3063203a 61313964task: c0d91a
 80e6d754: 74203832 63203a69 34386430 2030303028 ti: c0d84000
 80e6d764: 6b736174 3a69742e 64306320 30303438task.ti: c0d8400
 80e6d774: 0030   00220..
 80e6d784:  69204350 74612073 74646620PC is at fdt
 80e6d794: 6568635f 685f6b63 65646165 78302b72_check_header+0x
 80e6d7a4: 78302f30 3437  0/0x74..
 80e6d7b4:    74612073s at

The boot loader copied the DT to the end of real RAM, not to the end of
the 256 MiB block? Hence the kernel accesses unmapped memory
when checking the FDT header?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html