[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Sandy Patterson]

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 <sjg at chromium.org> wrote:

> HI Sandy,
>
> On 13 July 2016 at 11:51, Sandy Patterson <apatterson at 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 <
> apatterson at 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
> >>
> >
>