Hi Simon, I think I screwed up submitting, and didn't cc the maintainers for the reverts. I can resubmit and get patman to behave. What do you suggest?
I still think this is the best patch to getting rock2 to load kernels again. I just retested with a patch specific to my kernel. I think 3.14 linux has some quirks in how it wants the dram setup, and I get instability without some changes to the dram init. I don't have enough of a system to test for this instability using the latest mainline kernel, so I left that patch out. Ziyuan had an alternative fix for efi_loader, but it looks like it may break efi_loader for others, and I don't know how to test the efi functionality, so I think disabling for RK3288 is best. I think I should move the CONFIG_EFI_LOADER patch to somehow patching rk3288_common.h instead (can I #undef config vars in that file?) Sandy On Thu, Jul 14, 2016 at 11:19 PM, Simon Glass <s...@chromium.org> wrote: > HI Sandy, > > On 13 July 2016 at 11:51, Sandy Patterson <apatter...@sightlogix.com> > wrote: > > I did a little more on this, and talked to someone else here. It seems > that > > my problem with loading the kernel including these patches is specific to > > our kernel and after applying a local patch we have, it appears to load > > fine. > > > > So this patchset gets me back to the same functionality in v2016.03. > > > > We're left with the puzzle of what's wrong on the RK3288 regarding > caching > > and memory. > > So what is the status of this patch set? Should it be withdrawn? > > Regards, > Simon > > > > > Sandy Patterson > > > > On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson < > apatter...@sightlogix.com> > > wrote: > >> > >> I wasn't able to load the linux kernel using a Rock2 board > >> using the latest master branch. The board hangs after it has > >> handed executing over to the kernel. I found that the latest release > >> that worked was v2016.03. > >> > >> I did some searching and I suspect the problem may be cache related. > >> > >> This patchset allows the kernel to start by reverting two problem > >> commits and disabling EFI_LOADER which I suspect rubs the caching the > >> wrong way. We also found that the 512M limit for fdt and initrd is now > >> 256M. > >> I'm not sure why this is. > >> > >> This still doesn't work 100%. I think it's not initializing the SD card > >> volages correctly, but at least the Kernel is loading. > >> > >> I also am not sure changing the caching for all armv7 is the right > >> answer. I wasn't too sure about the revert. I am not very familiar with > >> this low level stuff. > >> > >> Sandy Patterson > >> > >> > >> Sandy Patterson (4): > >> Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) > >> with asm code" > >> Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with > >> asm code" > >> Disable CONFIG_EFI_LOADER for rock2. > >> RK3288 needs fdt and initrd below 256M now. > >> > >> arch/arm/cpu/armv7/Makefile | 2 +- > >> arch/arm/cpu/armv7/cache_v7.c | 135 > >> ++++++++++++++++++++++- > >> arch/arm/cpu/armv7/cache_v7_asm.S | 154 > >> --------------------------- > >> arch/arm/mach-uniphier/arm32/lowlevel_init.S | 67 +++++++++++- > >> configs/rock2_defconfig | 1 + > >> include/configs/rk3288_common.h | 6 +- > >> 6 files changed, 201 insertions(+), 164 deletions(-) > >> delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S > >> > >> -- > >> 1.9.1 > >> > > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
