lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190816083403.GB1952@darkstar.musicnaut.iki.fi>
Date:   Fri, 16 Aug 2019 11:34:03 +0300
From:   Aaro Koskinen <aaro.koskinen@....fi>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Tony Lindgren <tony@...mide.com>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        linux-omap <linux-omap@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 14/22] ARM: omap1: use pci_ioremap_io() for omap_cf

Hi,

On Wed, Aug 14, 2019 at 12:36:40PM +0200, Arnd Bergmann wrote:
> On Wed, Aug 14, 2019 at 9:49 AM Tony Lindgren <tony@...mide.com> wrote:
> > * Arnd Bergmann <arnd@...db.de> [190813 19:34]:
> > > -#define OMAP1_IO_OFFSET                0x01000000      /* Virtual IO
> > > = 0xfefb0000 */
> > > +#define OMAP1_IO_OFFSET                0x00fb0000      /* Virtual IO
> > > = 0xff000000 */
> > >  #define OMAP1_IO_ADDRESS(pa)   IOMEM((pa) - OMAP1_IO_OFFSET)
> >
> > Oh OK yeah sounds like that's the issue.
> >
> > > There may be additional locations that hardcode the virtual address.
> >
> > Those should be in mach-omap1/io.c, and I recall innovator had some
> > hardcoded fpga address that should also be checked.
> 
> I see four boards with hardcoded I/O addresses, but they are all below
> the PCI I/O virtual address range, and are not affected by that change.
> 
> For the innovator FPGA access, this was ok, it uses the correct address
> in the OMAP1_IO_OFFSET range.

I tried testing this on OSK board. If I boot with earlyprintk disabled,
it boots OK and everything works (also CF card) with your playground
commit 5723b6686943.

However with earlyprintk it seems to hang as soon as kernel tries to print
something. So something goes wrong with early DEBUG_LL mapping code when
CONFIG_DEBUG_UART_VIRT=0xff000000 is used?

A.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ