<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>Kumar,
<div><br>
</div>
<div>Sorry, i should have posted to the ml.</div>
<div><br>
</div>
<div>Thank you, I was looking in the wrong spot.</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div>-Bryan</div>
<br>
<br>
<br>
Kumar Gala <galak@kernel.crashing.org> wrote:<br>
<br>
<br>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
On Mar 29, 2012, at 2:26 AM, Sebastian Andrzej Siewior wrote:<br>
<br>
> On 03/28/2012 10:30 PM, Bryan Hundven wrote:<br>
>> > It is not at 0xffa00000. According to current u-boot source the NAND<br>
>> > controller is always at 0xff800000 and it is either at CS0 or CS1<br>
>> > depending on NAND or NAND+NOR mode. In 36bit mode it is shifted to<br>
>> > 0xfff800000 but it has always an eight there and never an A.<br>
>> ><br>
>> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de><br>
>> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org><br>
>> <br>
>> I am having a hard time verifying this change. I don't think you are<br>
>> wrong, I'm just having a hard time following.<br>
>> <br>
>> I do not see where this has always been 0xff800000 in u-boot.<br>
> <br>
> <cut><br>
> <br>
>> But while I was checking changes in arch/powerpc/, I found this change<br>
>> and wanted to understand why 0xffa00000 has worked for us for so long?<br>
> <br>
> Kumar, I wasn't wrong entirely I just missed one detail. U-Boot<br>
> provides two different configs, not just one define like its for<br>
> SPL/SPI/...:<br>
> <br>
> - include/configs/P1_P2_RDB.h<br>
> <br>
> #ifndef CONFIG_NAND_SPL<br>
> #define CONFIG_SYS_NAND_BASE 0xffa00000<br>
> #ifdef CONFIG_PHYS_64BIT<br>
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfffa00000ull<br>
> #else<br>
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE<br>
> #endif<br>
> #else<br>
> #define CONFIG_SYS_NAND_BASE 0xfff00000<br>
> #ifdef CONFIG_PHYS_64BIT<br>
> #define CONFIG_SYS_NAND_BASE_PHYS 0xffff00000ull<br>
> #else<br>
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE<br>
> #endif<br>
> #endif<br>
> <br>
> - include/configs/p1_p2_rdb_pc.h<br>
> <br>
> #ifdef CONFIG_NAND_FSL_ELBC<br>
> #define CONFIG_SYS_NAND_BASE 0xff800000<br>
> #ifdef CONFIG_PHYS_64BIT<br>
> #define CONFIG_SYS_NAND_BASE_PHYS 0xfff800000ull<br>
> #else<br>
> #define CONFIG_SYS_NAND_BASE_PHYS CONFIG_SYS_NAND_BASE<br>
> #endif<br>
> <br>
> and for kernel they use both the same device tree. So with the change,<br>
> the _pc variant finds its flash. Before that it worked for the non-pc<br>
> variant only if NAND_SPL wasn't used.<br>
> Any suggestion on fixing that? Providing a new dt for _pc would "fix"<br>
> it but the non pc variant won't find it in the case of NAND_SPL.<br>
<br>
There are two (well 3 since rdb-pc has both 32b & 36b) in the tree now:<br>
<br>
arch/powerpc/boot/dts/p2020rdb.dts<br>
arch/powerpc/boot/dts/p2020rdb-pc_32b.dts<br>
arch/powerpc/boot/dts/p2020rdb-pc_36b.dts<br>
<br>
> <br>
> Since both system have the same SoC and the NAND_SPL is always linked<br>
> against 0xfff00000 I don't see anything wrong to relocate the NAND CS<br>
> later to 0xff800000 (or to 0xffa00000) and having it consistent among<br>
> both configs.<br>
<br>
<br>
- k<br>
</div>
</span></font>
</body>
</html>