Linux does not boot with Q4D20 on certain models

[Quozl]

Reported by Quanta. System does not boot, with following serial console output:

OLPC 1C1, 800 MHz, 1 GiB memory, 8 GB internal storage, S/N SHC143009A9
OpenFirmware  Q4D20   EC Firmware 0.5.00   2012-07-11 05:54:25 UTC
WARNING!  OS image much smaller than internal storage device

Type the Esc key to interrupt automatic startup
Boot device: /sd/disk@3:\boot\olpc.fth  Arguments: 
Boot device: /sd@d4280000/disk@3:\boot\vmlinuz  Arguments: ttyS2
Loading ramdisk image from /sd@d4280000/disk@3:\boot\initrd.img ...
Uncompressing Linux... done, booting the kernel.

model	sku	firmware	operating system	boot test
1b4	sku199	q4d20	11.3.1 build 885	pass
1c1	sku202	q4d20	11.3.1 build 885	fail
1c1	sku202	q4d20	12.1.0 build 17	fail
1c2	1ghz test unit	q4d20	11.3.1 build 885	fail
1c2	1ghz test unit	q4d18	11.3.1 build 885	pass
1c2	1ghz test unit	q4d20	12.1.0 build 17	fail
1c2	1ghz test unit	q4d18	12.1.0 build 17	pass

Q4D20 was released after being tested on SKU199 only, most other units were in runin testing of 12.1.0.

[Quozl]

With the printascii in printk patch in place, this is what is logged:

Uncompressing Linux... done, booting the kernel.
<6>Initializing cgroup subsys cpu
<5>Linux version 3.0.19-01553-g500dfc5-dirty (james@dora) (gcc version 4.6.0 20110226 (experimental) (GCC) ) #209 PREEMPT Thu Jul 12 15:27:02 EST 2012
CPU: ARMv7 Processor [560f5815] revision 5 (ARMv7), cr=10c5387d
CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache

[Quozl]

The systems that do not boot have 1 GB of memory, the systems that do have 512 MB of memory.

Restricting the ramdisk and device tree addresses below the 512 MB border appears to fix it, though we have no idea why the Linux kernel implementation is so picky about it.

Fixed in svn 3051 by moving load-base and using that as the upper bound for the ramdisk.

Test build http://dev.laptop.org/~quozl/q4d20jb.rom

[wmb@…]

My current best guess about why (ARM) Linux is "picky" is because Linux uses virtual addresses above 0xc000.0000 for it' mappings (the lower virtual address space is for user processes). Since there is exactly 1 GiB of virtual address space above 0xc0000000 and some of that has to be reserved for things like I/O mappings and dynamically-allocated mappings, you can't linearly-map all of a 1 GiB physical memory in that space. So, if OFW "floats" the ramdisk and flattened device tree up high in a 1 GiB physical memory, there is a risk that it will end up in an area that the kernel can't linearly map without colliding with the area it reserves for that other stuff.

[Quozl]

Test reports from Quanta

unit no	specifications	build	result
1	1C2, 1GHz, 1GB memory, 4GB storage	os33	PASS
2	1C2, 1GHz, 1GB memory, 4GB storage	os33	PASS
3	1C2, 1GHz, 1GB memory, 8GB storage	os33	PASS
4	1C2, 1GHz, 1GB memory, 8GB storage	os33	PASS
5	1C1, 800MHz, 512MB memory, 4GB storage	os885	PASS
6	1B2, 800MHz, 512MB memory, 4GB storage	os21	FAIL
7	1B2, 800MHz, 512MB memory, 4GB storage	os882	FAIL
8	1C2, 800MHz, 1GB memory, 8GB storage	os26	FAIL
6	1B2, 800MHz, 512MB memory, 4GB storage	os885	PASS
7	1B2, 800MHz, 512MB memory, 4GB storage	os885	PASS
8	1C2, 800MHz, 1GB memory, 8GB storage	os885	PASS
6	1B2, 800MHz, 512MB memory, 4GB storage	os882	FAIL
5	1C1, 800MHz, 512MB memory, 4GB storage	os882	FAIL
1	1C2, 1GHz, 1GB memory, 4GB storage	os882	FAIL

[Quozl]

These results look normal to me. The failures are due to mixing old kernel without device tree support with new firmware that provides device tree.

[Quozl]

Is in Q4D21.