Re: [J-core] [PATCH v5 00/22] sh: LANDISK and R2Dplus convert to device tree

[Rich Felker]

On Fri, Jan 05, 2018 at 04:28:57PM -0500, Rich Felker wrote:
> On Fri, Nov 17, 2017 at 08:54:47PM +0100, John Paul Adrian Glaubitz wrote:
> > On 11/17/2017 08:17 PM, Rich Felker wrote:
> > > There were significant problems that I don't think were ever
> > > addressed, including incompatible changes in how boot command line was
> > > handled and possibly ambiguity about what a physical address means
> > > (zero based vs based in the zone SH3/4 excludes from MMU mapping) in
> > > the contract for how the bootloader passes a DTB pointer in to the
> > > kernel, or something similar.
> > 
> > I see, thanks for the heads-up.
> > 
> > > This is a large part of why I want to get to the point where I can
> > > build and boot a kernel on the LANDISK -- not being able to test any
> > > of this is a blocker for moving everything to device tree.
> > 
> > I can actually help you with that. I know what to do to get the kernel
> > to boot on the LANDISK device. I've got everything working except
> > being unable to detect the IDE controller. The attached config builds
> > a kernel which boots with the attached output.
> > 
> > Furthermore, in order to install the kernel, you need to use the
> > cross-LILO version from [1] which allows to install the bootloader
> > on an x86 machine into the SuperH LANDISK image.
> > 
> > Instructions can be found in [2]. A base filesystem can be found in [3].
> > 
> > And I could also send you an USL-5P which is also a LANDISK device,
> > just in a different form-factor.
> > 
> > Adrian
> > 
> > > [1]http://iohack.osdn.jp/kogiidena/debian26/base/landisk-tools-20070612.tgz
> > > [2] https://www.with.de/fw/pub/Computing/PlextorPX-EH/LANDISKdebian.pdf
> > > [3] http://iohack.osdn.jp/kogiidena/debian26/base/
> 
> I'm trying to reproduce this but can't find any documentation for
> cross-LILO in [2], much less any code except possibly the binary
> "lilo.x86" in [1]. Googling cross-lilo isn't finding anything
> meaningful except this thread. Is there anywhere to find source and
> information on what it's doing, or is this going to be something I
> have to reverse-engineer?

Progress on all this! I've got my LANDISK working again, but with the
disk image Sato-san provided me, which is using (a patched?) U-Boot
and a kernel based on this patch series. I don't know how to recreate
the U-Boot setup from scratch, but I might be able to figure out how
to replace the kernel image it's using. It's possible I may be able to
get lilo working too -- I tried building it but I'm still not sure how
to use it, and in any case I need to image the existing system before
I clobber it since I'm not sure I have the original image.

On a better note, I've reviewed this patch series in more depth and
understand it pretty well now, and have classified the patches as
follows:

01-04 -- about P1 vs absolute interpretation of "physical addresses",
and can be completely dropped if we just use the latter. The former
does not work with full-32-bit address space.

05 -- change in command line interpretation. Something like this might
be desired at some point, if we make it non-conflicting with current
use, but it's independent and not needed.

06-09 -- extending arch/sh device tree support with functionality
needed to get traditional sh systems using it. These look roughly ok,
but might need minor cleanup. Just applying these and linking in a
minimal DTB, I should be able to get a non-board-specific kernel that
boots and shows console messages until it gets stuck with no interrupt
controller or devices. This is the milestone I'm looking to get to
first.

10 -- LANDISK board-specific init stuff, moved into of-generic.c. This
is not where it belongs, but I don't know where it should be, or if we
can get it to book without this. If not, it can be applied as a hack
for testing.

11-13,19 -- new style device tree drivers for clock, pci bus, and irq
controller. They'll have to go through subsystem maintainers unless we
want to move them into arch/sh/drivers. Without these the system is
not going to be usable to the point of reaching userspace.

14,20 -- device trees. The evt2irq/irq2evt macros probably don't make
sense and should be either irqdomain mappings or just removed. But
these can be used out-of-tree anyway to make a DTB while testing.

15-17 -- might also be needed for PCI to work. Not sure about them.

Rich