linux-kernel - Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast

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: <20071216215929.GA14278@linux-sh.org>
Date:	Mon, 17 Dec 2007 06:59:29 +0900
From:	Paul Mundt <lethal@...ux-sh.org>
To:	Adrian McMenamin <adrian@...golddream.dyndns.info>
Cc:	Adrian McMenamin <lkmladrian@...il.com>,
	linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org,
	linux-sh@...r.kernel.org, axboe@...nel.dk
Subject: Re: [PATCH 2/3] Add GD-Rom support to the SEGA Dreamcast

On Sun, Dec 16, 2007 at 05:32:51PM +0000, Adrian McMenamin wrote:
> On Sun, 2007-12-16 at 18:50 +0900, Paul Mundt wrote:
> > > +	for (count = 0xa0000000; count < 0xa0200000; count += 4)
> > > +		ctrl_inl(count);
> > 
> > Er? This ranged dummy reading of the P2 space needs some explanation. The
> > GD-ROM isn't even mapped in to this space, so this seems like a hack to
> > either work around a timing issue or a write ordering problem.
> 
> I'll confess to not knowing what it's up to here either, other than it
> looks like a mechanism to cause a G1 bus reset. This is a progressive
> read of the Boot ROM area and that is all under G1 control (as is the GD
> Rom obviously)
> 
Ok, then this should be moved out to a g1_bus_reset() or something
similar with a comment explaining what it's doing, that way it can be
trivially reworked if a saner method of forcing a G1 reset is discovered.

While I realize that this is all undocumented and based entirely on
reverse engineering, you should at least verify that that's precisely
what is going on, and that this is not just a precaution for flushing
posted writes. You can test that by removing the loop and doing a dummy
read after your write (to the same register, rather than the entire ROM
space). If it's a posting issue, then you will have to do your own
read/write_reg routines that handle the flush.
--
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/