linux-kernel - Re: [rfc] exposing MMR's of on-chip peripherals for debugging purposes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 28 Jan 2008 18:40:11 +0800
From:	Bryan Wu <bryan.wu@...log.com>
To:	Mike Frysinger <vapier.adi@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Bryan Wu <cooloney.lkml@...il.com>
Subject: Re: [rfc] exposing MMR's of on-chip peripherals for debugging
	purposes


On Mon, 2008-01-28 at 05:16 -0500, Mike Frysinger wrote:
> we have guys who maintain xml descriptions of all Blackfin processors.
>  these include an exhaustive list of all the peripherals and their
> MMRs.  for example, there is an element that binds the address, the
> MMR name (as described in the processor's hardware manual), the bit
> size of it, and all those fun details.  i feed these xml files through
> an xsl to generate a C file that populates /sys/kernel/debug/blackfin/
> by using the standard debugfs functions.  so when i'm debugging the
> watchdog driver, i can simply go into
> /sys/kernel/debug/blackfin/watchdog/ and see the watchdog-specific
> MMRs and cat/echo them on the fly.  it's been quite handy and feedback
> from customers/developers is that it's nicely filled a small void in
> the development process.
> 

Mike is a quick developer, I am trying to keep up with him.
Exactly, the MMR debug FS interface helps very much for developers and
customers.

> the trouble is that this file currently weighs in at ~1.8 megs.  this
> is because it contains all the information for all Blackfin processors
> we support (which currently, is about ~23 variants).  it's only going
> to get bigger as we support more.  Bryan cringes at the thought of
> submitting it to LKML :).  so i'm fishing around for alternatives ...
> the code was originally developed against 2.6.21, so UIO was not a
> possibility.  i'm still not sure if it is ... i'd have to research it
> a bit more and play with things.
> 

The main reason I am not willing to submit this to mainline is the file
size. It's almost the biggest file in the kernel source. And it will be
bigger and bigger when more and more new Blackfin processors supported
by Linux kernel.

My suggestion is:
 - move the large MMR table to user space
 - add an interface of debug FS which let uses space app to send the large table to debug FS
 - debug FS will take care of the rest HW things according to each architecture. 

Or more deeper thought:
 - we don't need all the MMR setup at the same time for debugging. for example, maybe for some developer, he/she only needs one driver MMR for debugging such as watchdog/usb/spi/i2c ....
 - How about split the debug MMR table to each drivers or processors?
 - watchdog driver implements a debug FS interface for debugging watchdog MMR and other drivers implement their own things.

I am not familiar with UIO, is it easy interactive with debug FS?

Thanks
-Bryan Wu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/