Hi, a barebox built with gcc5 hangs in tlb_invalidate() very early. This seems to be caused by an integer overflow: --- arch/arm/cpu/mmu.c: static int arm_mmu_remap_sdram(struct memory_bank *bank) { unsigned long num_ptes = bank->size >> 10; int i; for (i = 0; i < num_ptes; i++) { ptes[i] = (phys + i * PAGE_SIZE) | PTE_TYPE_SMALL | pte_flags_cached; } For 1GiB RAM, 'num_ptes' is 1MiB and due to integer promotion, the 'i * PAGE_SIZE' overflows and causes undefined behavior. A trivial fix is to make 'i' an unsigned int or long. But I wonder whether calculation of 'num_ptes' is really correct. Does barebox really use a 1KiB pagesize for PTEs or should the '>> 10' be a '>> 12'? When it is really 1KiB, the mapping for memory sizes > 1GiB seem to be ambiguous then. For reference; in broken case ('int i'), gcc5 generates: | 4badc: f7b4 fe7e bl 7dc <pr_print> | 4bae0: f8d9 3000 ldr.w r3, [r9] | 4bae4: f1aa 0104 sub.w r1, sl, #4 | 4bae8: f043 0202 orr.w r2, r3, #2 | 4baec: 9b03 ldr r3, [sp, #12] | 4baee: eb04 3303 add.w r3, r4, r3, lsl #12 | | 4baf2: 42a3 cmp r3, r4 | 4baf4: d006 beq.n 4bb04 <mmu_init+0x1c0> | 4baf6: ea42 0004 orr.w r0, r2, r4 | 4bafa: f504 5480 add.w r4, r4, #4096 ; 0x1000 | 4bafe: f841 0f04 str.w r0, [r1, #4]! | 4bb02: e7f6 b.n 4baf2 <mmu_init+0x1ae> Building with 'unsigned long i' generates: | 4bad8: f7b4 fe80 bl 7dc <pr_print> | 4badc: 683b ldr r3, [r7, #0] | 4bade: f043 0202 orr.w r2, r3, #2 | 4bae2: 9b05 ldr r3, [sp, #20] | | 4bae4: 9904 ldr r1, [sp, #16] | 4bae6: 4299 cmp r1, r3 | 4bae8: d006 beq.n 4baf8 <mmu_init+0x1b4> | 4baea: eb0a 3103 add.w r1, sl, r3, lsl #12 | 4baee: 4311 orrs r1, r2 | 4baf0: f849 1023 str.w r1, [r9, r3, lsl #2] | 4baf4: 3301 adds r3, #1 | 4baf6: e7f5 b.n 4bae4 <mmu_init+0x1a0> Enrico -- SIGMA Chemnitz GmbH Registergericht: Amtsgericht Chemnitz HRB 1750 Am Erlenwald 13 Geschaeftsfuehrer: Grit Freitag, Frank Pyritz 09128 Chemnitz _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox