All of lore.kernel.org
 help / color / mirror / Atom feed
From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: Kirkwood: Add support for Excito Bubba B3
Date: Sat, 11 Jan 2014 00:02:48 +0100	[thread overview]
Message-ID: <20140110230248.GO9681@lunn.ch> (raw)
In-Reply-To: <20140110194437.GJ18269@obsidianresearch.com>

> > So, I'd prefer to handle this more gracefully.  I don't have much
> > experience at the low-level init of the caches, couldn't we enable and
> > flush rather than throwing the error?
> 
> It cannot be solved in cache-feroceon-l2.c.
> 
> In many cases you won't even get that far:
> - It will blow up in head.S when the cache is off: decompressor wrote
>   writeback data to into the L2 and uncached fetches see memory
>   content prior to decompression
> - It will blow up after head.S enables the L1: decompressor wrote
>   data into the L2 but the relocation writes done with the L1 off
>   made changes to memory that were not captured in the L2.

My impression with booting a lot of times while doing i bisect, was
that it got as far as:

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.13.0-rc1-dirty (lunn at laptop) (gcc version 4.4.5 (Debian 4.4.5-8) ) #7 PREEMPT Fri Jan 3 09:25:07 CST 2014           
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family
Memory policy: ECC disabled, Data cache writeback

every time.

It frequently got as far as

Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
Kernel command line: root=/dev/sda2 console=ttyS0,115200 earlyprintk
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512704K/524288K available (4693K kernel code, 247K rwdata, 1264K rodata, 154K init, 616K bss, 11584K reserved)              
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc05d9678   (5958 kB)
      .init : 0xc05da000 - 0xc0600ab0   ( 155 kB)
      .data : 0xc0602000 - 0xc063fcc0   ( 248 kB)
       .bss : 0xc063fccc - 0xc06d9ef0   ( 617 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
NR_IRQS:114  
sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 21474ms

And never made it past

Console: colour dummy device 80x30
Calibrating delay loop... 1587.60 BogoMIPS (lpj=7938048)

with L2 enabled.

Now clearly there is a difference between how far it got before
everything stops, and the point where corruption has occurred and
unavoidable death is going to happen sometime in the future.

It does however seem possible to insert platform specific code soon
after it prints:

Machine: Marvell Kirkwood (Flattened Device Tree), model: QNAP TS219 family

but i never got around to trying to disable and flush L2 at that
point. And the hardware is now also on the other side of the pond, and
i have no way to remotely power cycle it.

  Andrew

  parent reply	other threads:[~2014-01-10 23:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-28 16:12 [PATCH] ARM: Kirkwood: Add support for Excito Bubba B3 Andrew Lunn
2013-12-28 17:01 ` Jason Cooper
2013-12-28 20:59   ` Andrew Lunn
2013-12-28 21:25     ` Jason Cooper
2014-01-02 19:49   ` Jason Gunthorpe
2014-01-02 22:36     ` Ian Campbell
2014-01-02 23:08       ` Jason Gunthorpe
2014-01-03  0:44         ` Andrew Lunn
2014-01-10 19:20         ` Jason Cooper
2014-01-10 19:44           ` Jason Gunthorpe
2014-01-10 19:54             ` Jason Cooper
2014-01-10 23:02             ` Andrew Lunn [this message]
2014-01-11  0:19               ` Jason Gunthorpe
2014-01-11 15:59           ` Russell King - ARM Linux
2014-01-13 14:44             ` Jason Cooper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140110230248.GO9681@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.