Hi, I have a cubox with 4go of RAM and I hit the following panic in ubldr: panic: Not enough DRAM to load kernel loader> sysinfo U-Boot system info: sys info: start = 0x10000000 size = 0xf0000000 type = DRAM in sys/boot/uboot/lib/copy.c, after this line: eblock = rounddown2(si->mr[i].start + si->mr[i].size, KERN_ALIGN); eblock is equal to zero and the panic occurs. Any help on this problem would be greatly appreciated! Thanks, Mikaël
The same problem occurs with Tegra Jetson TK1 Reason is error in handling upper memory limit of 0xffffffff (+1) with 32 bit arithmetic. This error occurs in 2 places: 1. in sys/boot/uboot/lib/copy.c 2. the kernel seems to be unable to handle it as well. Fixing 1. and reducing the upper memory limit in the dts file does not help as fdt_fixup_memory changes the upper memory limit again.
A commit references this bug: Author: ian Date: Sat Jan 2 18:16:24 UTC 2016 New revision: 293053 URL: https://svnweb.freebsd.org/changeset/base/293053 Log: Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. This is a fix for one of the two problems mentioned in the PR. Something similar will need to be done on the kernel side before the PR is closed. PR: 201614 Changes: head/sys/boot/uboot/lib/copy.c
A commit references this bug: Author: ian Date: Sat Jan 2 22:00:52 UTC 2016 New revision: 293061 URL: https://svnweb.freebsd.org/changeset/base/293061 Log: Use 64-bit math when processing the lists of physical and excluded memory to generate the phys_avail and dump_avail arrays. This is a partial fix for the kernel side of the problem mentioned in the PR. This part handles the cases where comparing start and end addresses of a block would fail because 32-bit wrap caused the end address to come out zero if the end of the region is the end of the address space (0xffffffff with 32-bit vm_paddr_t, but now the code should also work right if we ever support LPAE with 36-bit addresses). More work is necessary to make systems with ram at the end of the physical address space usable, but at least initially it's going to be more like a workaround than a fix, so this non-hacky part is being committed first. PR: 201614 Changes: head/sys/arm/arm/physmem.c
A commit references this bug: Author: ian Date: Sat Jan 2 23:14:53 UTC 2016 New revision: 293065 URL: https://svnweb.freebsd.org/changeset/base/293065 Log: Reword the comment to better describe what I found while researching the problem that led to this temporary workaround (and also so I can properly cite the PR in the commit this time). In general this is intended to be a temporary workaround until we can figure out why including any ram from the last megabyte of the physical address space leads to a NULL pointer deref. Debugging that is made trickier by the fact that I couldn't even get a backtrace in ddb. PR: 201614 Changes: head/sys/arm/arm/physmem.c
A commit references this bug: Author: ian Date: Sun Jan 24 22:00:36 UTC 2016 New revision: 294685 URL: https://svnweb.freebsd.org/changeset/base/294685 Log: MFC r293053, r293061, r293063, r293064, r293065, r293775, r293792: Use 64-bit math when finding a block of ram to hold the kernel. This fixes a problem on 32-bit systems which have ram occupying the end of the physical address space -- for example, a block of ram at 0x80000000 with a size of 0x80000000 was overflowing 32 bit math and ending up with a calculated size of zero. Use 64-bit math when processing the lists of physical and excluded memory to generate the phys_avail and dump_avail arrays. Work around problems that happen when there is ram at the end of the physical address space. Cast pointer through uintptr_t on the way to uint64_t to squelch a warning. Reword the comment to better describe what I found while researching the problem that led to this temporary workaround (and also so I can properly cite the PR in the commit this time). Cast using uintfptr_t and eliminate the cast to uint64_t which is uneeded because rounding down cannot increase the number of bits needed to express the result. Go back to using uintptr_t, because code that actually compiles is infinitely less buggy than code that is theoretically correct in some alternate universe. PR: 201614 Changes: _U stable/10/ stable/10/sys/arm/arm/physmem.c stable/10/sys/boot/uboot/lib/copy.c