From mboxrd@z Thu Jan 1 00:00:00 1970 From: Przemyslaw Marczak Date: Thu, 17 Jul 2014 16:59:43 +0200 Subject: [U-Boot] uboot/odroid test report In-Reply-To: References: Message-ID: <53C7E4DF.4020404@samsung.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Daniel, On 07/17/2014 02:31 PM, Daniel Drake wrote: > Hi, > > Thanks a lot for working on getting ODROID support upstream in uboot. > I'm testing with v4 of your patches on uboot 2014.07 and ODROID-U2. > Thank you for testing this. > > I'd like to understand the SPL/BL2 situation a bit better. > README.odroid says that we should use the blob from hardkernel. > However, as far as I can see, this blob is generated by taking the > first 14kb of hardkernel's u-boot.bin from 2012 and signing it. > > So, the suggestion of using hardkernel's bl2 (which I am following) > seems odd. That means we run some early code from hardkernel's 2012 > uboot and then magically jump into uboot-2014.07? That sounds fragile, > unless this magic 14kb division is somehow represented in the output > uboot binary too? > We can use bl1/bl2 binaries from hardkernel because those are some independent bootloader parts, the same like SPL in current u-boot. Each binary has its own job to do, so: - BL1 - is some kind of a public key - it is used by iROM - BL2 - is a low level initialization - CPU, DRAM, and also tzsw and u-boot loading from eMMC/SD - it is also used by iROM So BL1, BL2 are running in iRAM(required small size), and u-boot is running from a RAM. The main reason for using existing BL1 and BL2 binaries is that bl1 and bl2 are just working proper. > > I'm also curious that these patches run the SoC at 1000MHz. Isn't the > SoC on these boards clocked at 1.7GHz? Does this 1000MHz carry over > into Linux once booted, or does Linux re-clock it at a faster speed? > Hardkernels u-boot also sets the CPU frequency to 1000 MHz. > > Onto the testing - uboot loads and detects my u2 as a u3 (good). > Booting into Linux, works but not quite - loads of memory corruption > is detected during early boot. > > Easiest way to reproduce this is to take linux-next from today, then: > # make exynos_defconfig > > Now enable CONFIG_DEBUG_PAGEALLOC and CONFIG_BLK_DEV_DRBD. Boot with > exynos4412-odroidu3.dtb from the same kernel tree. During boot this > happens: > > 13800000.serial: ttySAC0 at MMIO 0x13800000 (irq = 84, base_baud = 0) > is a S3C6400/10 > 13810000.serial: ttySAC1 at MMIO 0x13810000 (irq = 85, base_baud = 0) > is a S3C6400/10 > console [ttySAC1] enabled > brd: module loaded > loop: module loaded > pagealloc: memory corruption > ffc10000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > ffc10010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > <> > CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc5-next-20140716-dirty #310 > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > [] (show_stack) from [] (dump_stack+0x80/0xc0) > [] (dump_stack) from [] (kernel_map_pages+0x18c/0x1a0) > [] (kernel_map_pages) from [] > (get_page_from_freelist.isra.73+0x27c/0x5d0) > [] (get_page_from_freelist.isra.73) from [] > (__alloc_pages_nodemask+0x128/0x978) > [] (__alloc_pages_nodemask) from [] (drbd_init+0x278/0x418) > [] (drbd_init) from [] (do_one_initcall+0x8c/0x1c4) > > I don't think this is a DRBD problem because: > - same kernel binary works on hardkernel uboot > - with my actual product kernel, with DRBD disabled, I still get a > load of memory corruption during early boot coming from other areas > > Any ideas? Can you reproduce? > > Thanks! > Daniel > I've tested this u-boot with tizen.org kernel on a Debian and also with the ubuntu14.04 LTS image with ramdisk - both works fine on odroid U3 and X2. Now I tested todays kernel 3.16.0-rc5-next-20140717 and it looks fine with the ubuntu (console). Thanks, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marczak at samsung.com