Re: [linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Henrik Nordström]

fre 2015-05-22 klockan 15:51 +0200 skrev Hans de Goede:

> What info do we need when we're only reading ? If the BROM can get away with 
> a fixed
> way of reading the nand for booting, we should be able to make the SPL get
> away with it too ...

BROM tries at least 4 different strategies in reading the NAND boot
blocks. Two different NAND protocol strategies and two different format
strategies have been observed (4 different access patterns). And ontop
of this it tries both randomizer scrambled and plain access.

> Distros already need to build and distribute a u-boot-with-spl.bin per 
> supported
> board. This doubles the number of builds they have to do and the number of
> files they need to distribute. If at all possible I would really like
> to have a unified SPL binary.

The SPL shrinks considerably in size if built in thumbs mode.

What I envisioned for sunix u-boot SPL was board-agnostic SPL binaries
with a little configuration header. This way you only need two (or three
is SPI is added) binaries, a list of board configurations and tool for
applying the config and write the resulting binary to the boot device
(NAND/MMC/SPI)

There isn't really that many board specific parameters.

Regards
Henrik

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Daniel Kochmański]

Hello Alexander,

you have to put correct nand configuration in devicetree in
arch/arm/boot/dts/sun5i-a13-olinuxino.dts of your board. For comparision
you may check sun7i-a20-cubieboard2.dts which has appropriate
definitions. sunxi-nand-wip branch works on a20.

Good luck!
Daniel

Alexander Kaplan writes:

> Hi,
>
> I tried both the kernel from
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment
>
> and u-boot from
> https://gitlab.com/turtle-solutions/u-boot/commits/sunxi-nand-wip
>
> I can successfully compile and boot them on my A13-OLinuXino but there is
> no NAND available. Neither in kernel log nor in the u-boot output there is
> anything mentioned about NAND. I tried to enable all the NAND options,
> especially the "Support for NAND on Allwinner SoCs" in nconfig but I'm
> afraid I still have not found the right configuration.
>
> Would it be possible to share the build configuration files?
>
> Thanks in advance
> Alex
>
> On Tue, May 26, 2015 at 7:52 AM, Hans de Goede  wrote:
>
>> Hi,
>>
>>
>> On 05/26/2015 09:34 AM, Roy Spliet wrote:
>>
>>> Hello Hans,
>>>
>>> Re-sent to everybody instead of just you. Reply inline.
>>>
>>> Op 25-05-15 om 22:39 schreef Hans de Goede:
>>>
 Hi,

 On 25-05-15 20:35, Hans de Goede wrote:

> Hi,
>
> On 22-05-15 09:04, Roy Spliet wrote:
>
>> Hello,
>>
>> For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or
>> actually I rebased his patches on top of 4.0rc7. This basically adds
>> support for NAND-chip partitioning, ECC and randomisation. Docs for the 
>> DT
>> specification in Documentation/devicetree/bindings/mtd/sunxi-nand.txt , 
>> and
>> an example can be found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . 
>> [2]
>> lists the acceptable configuration options for the boot and boot_rescue
>> partitions, make sure to pick one of these (which should be no problem 
>> for
>> MLC-type nand). The ECC mode for these boot partitions is called
>> hw_syndrome.
>>
>> Assuming you now have a Linux set-up kernel based on this tree with
>> NAND support on an MMC, for U-boot what you should currently do is:
>> 1) in include/configs/sunxi-common.h, adjust the parameters
>> PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND
>> chip and DT configuration.
>> 2) Build
>> 3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
>> # flash_erase /dev/mtd0
>> # nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
>> 4) Reboot without the MMC card and see U-boot load
>>
>
> Ok, it took me way longer then I wanted (see below) but I've this
> working now. It is cool to see u-boot load from nand :)
>
>>
>> That should be all.
>>
>> @Alex: To answer your question specifically: It's likely that the
>> parameters in sunxi-common.h mentioned above might not match your 
>> NAND-chip
>> configuration in the Linux kernel. I can't tell you precisely how to 
>> fetch
>> these details from the 3.4 kernel, sorry. I recall Daniel using 24-bit
>> strength ECC with otherwise equal parameters, but perhaps he can help you
>> with this better than I can.
>>
>
> Alex, could it be that you are writing the nand using
> a (rebased) version of bbrezillon's sunxi-nand-next branch ?
>
> I started with that too because it is much newer and contains
> various bug fixes, but it seems that it also contains a new
> bug causing it to write the NAND in such a way that the BROM
> and u-boot SPL code will not read it.
>
> I've just pushed a rebased version of the sunxi-nand branch of
> Boris here:
>
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment
>
> And that works for me, where as before I got the exact same errors
> trying to fel load a nand enabled spl.
>
> I'm working on merging over all the changes from the sunxi-nand-next
> branch onto my working sunxi-nand-experiment branch 1 by 1 until
> I find the one which causes the breakage...
>

 Ok, so quick update the breakage was caused by this commit:


 https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c

 When it was rebased someone (Boris I guess) forgot to remove the
 "chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the
 patch) and
 likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);"
 line at
 line 1161. With these 2 lines removed the sunxi-nand-next branch from
 Boris,
 rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can
 load
 the spl / resp. u-boot.bin from there (on a cubieboard2).

>>> You're right... I did spot this, but assumed this was my own mistake in
>>> merging these patches with our 4.0RC7 tree. Sorry, could have saved you
>>> some trouble if I were sh

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Alexander Kaplan]

Hi,

I tried both the kernel from
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

and u-boot from
https://gitlab.com/turtle-solutions/u-boot/commits/sunxi-nand-wip

I can successfully compile and boot them on my A13-OLinuXino but there is
no NAND available. Neither in kernel log nor in the u-boot output there is
anything mentioned about NAND. I tried to enable all the NAND options,
especially the "Support for NAND on Allwinner SoCs" in nconfig but I'm
afraid I still have not found the right configuration.

Would it be possible to share the build configuration files?

Thanks in advance
Alex

On Tue, May 26, 2015 at 7:52 AM, Hans de Goede  wrote:

> Hi,
>
>
> On 05/26/2015 09:34 AM, Roy Spliet wrote:
>
>> Hello Hans,
>>
>> Re-sent to everybody instead of just you. Reply inline.
>>
>> Op 25-05-15 om 22:39 schreef Hans de Goede:
>>
>>> Hi,
>>>
>>> On 25-05-15 20:35, Hans de Goede wrote:
>>>
 Hi,

 On 22-05-15 09:04, Roy Spliet wrote:

> Hello,
>
> For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or
> actually I rebased his patches on top of 4.0rc7. This basically adds
> support for NAND-chip partitioning, ECC and randomisation. Docs for the DT
> specification in Documentation/devicetree/bindings/mtd/sunxi-nand.txt , 
> and
> an example can be found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . 
> [2]
> lists the acceptable configuration options for the boot and boot_rescue
> partitions, make sure to pick one of these (which should be no problem for
> MLC-type nand). The ECC mode for these boot partitions is called
> hw_syndrome.
>
> Assuming you now have a Linux set-up kernel based on this tree with
> NAND support on an MMC, for U-boot what you should currently do is:
> 1) in include/configs/sunxi-common.h, adjust the parameters
> PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND
> chip and DT configuration.
> 2) Build
> 3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
> # flash_erase /dev/mtd0
> # nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
> 4) Reboot without the MMC card and see U-boot load
>

 Ok, it took me way longer then I wanted (see below) but I've this
 working now. It is cool to see u-boot load from nand :)

>
> That should be all.
>
> @Alex: To answer your question specifically: It's likely that the
> parameters in sunxi-common.h mentioned above might not match your 
> NAND-chip
> configuration in the Linux kernel. I can't tell you precisely how to fetch
> these details from the 3.4 kernel, sorry. I recall Daniel using 24-bit
> strength ECC with otherwise equal parameters, but perhaps he can help you
> with this better than I can.
>

 Alex, could it be that you are writing the nand using
 a (rebased) version of bbrezillon's sunxi-nand-next branch ?

 I started with that too because it is much newer and contains
 various bug fixes, but it seems that it also contains a new
 bug causing it to write the NAND in such a way that the BROM
 and u-boot SPL code will not read it.

 I've just pushed a rebased version of the sunxi-nand branch of
 Boris here:

 https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

 And that works for me, where as before I got the exact same errors
 trying to fel load a nand enabled spl.

 I'm working on merging over all the changes from the sunxi-nand-next
 branch onto my working sunxi-nand-experiment branch 1 by 1 until
 I find the one which causes the breakage...

>>>
>>> Ok, so quick update the breakage was caused by this commit:
>>>
>>>
>>> https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c
>>>
>>> When it was rebased someone (Boris I guess) forgot to remove the
>>> "chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the
>>> patch) and
>>> likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);"
>>> line at
>>> line 1161. With these 2 lines removed the sunxi-nand-next branch from
>>> Boris,
>>> rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can
>>> load
>>> the spl / resp. u-boot.bin from there (on a cubieboard2).
>>>
>> You're right... I did spot this, but assumed this was my own mistake in
>> merging these patches with our 4.0RC7 tree. Sorry, could have saved you
>> some trouble if I were sharper.
>>
>>>
>>> I've also tried to get this code running on a cubieboard (non 2 so A10
>>> rather then
>>> A20), the SPL loads fine there (indicating that the kernel bits work),
>>> but then
>>> I get:
>>>
>>> U-Boot SPL 2015.07-rc1-00287-g050de86-dirty (May 25 2015 - 22:28:19)
>>> DRAM: 1024 MiB
>>> CPU: 100800Hz, AXI/AHB/APB: 3/2/2
>>> Nand initialised
>>> NAND timeout reading data
>>> NAND timeout reading data
>>> NAND timeout reading data
>>> NAND timeo

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Hans de Goede]

Hi,

On 05/26/2015 09:34 AM, Roy Spliet wrote:

Hello Hans,

Re-sent to everybody instead of just you. Reply inline.

Op 25-05-15 om 22:39 schreef Hans de Goede:

Hi,

On 25-05-15 20:35, Hans de Goede wrote:

Hi,

On 22-05-15 09:04, Roy Spliet wrote:

Hello,

For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or actually I 
rebased his patches on top of 4.0rc7. This basically adds support for NAND-chip 
partitioning, ECC and randomisation. Docs for the DT specification in 
Documentation/devicetree/bindings/mtd/sunxi-nand.txt , and an example can be 
found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . [2] lists the acceptable 
configuration options for the boot and boot_rescue partitions, make sure to 
pick one of these (which should be no problem for MLC-type nand). The ECC mode 
for these boot partitions is called hw_syndrome.

Assuming you now have a Linux set-up kernel based on this tree with NAND 
support on an MMC, for U-boot what you should currently do is:
1) in include/configs/sunxi-common.h, adjust the parameters 
PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND chip 
and DT configuration.
2) Build
3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
# flash_erase /dev/mtd0
# nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
4) Reboot without the MMC card and see U-boot load


Ok, it took me way longer then I wanted (see below) but I've this
working now. It is cool to see u-boot load from nand :)


That should be all.

@Alex: To answer your question specifically: It's likely that the parameters in 
sunxi-common.h mentioned above might not match your NAND-chip configuration in 
the Linux kernel. I can't tell you precisely how to fetch these details from 
the 3.4 kernel, sorry. I recall Daniel using 24-bit strength ECC with otherwise 
equal parameters, but perhaps he can help you with this better than I can.


Alex, could it be that you are writing the nand using
a (rebased) version of bbrezillon's sunxi-nand-next branch ?

I started with that too because it is much newer and contains
various bug fixes, but it seems that it also contains a new
bug causing it to write the NAND in such a way that the BROM
and u-boot SPL code will not read it.

I've just pushed a rebased version of the sunxi-nand branch of
Boris here:

https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

And that works for me, where as before I got the exact same errors
trying to fel load a nand enabled spl.

I'm working on merging over all the changes from the sunxi-nand-next
branch onto my working sunxi-nand-experiment branch 1 by 1 until
I find the one which causes the breakage...


Ok, so quick update the breakage was caused by this commit:

https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c

When it was rebased someone (Boris I guess) forgot to remove the
"chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the patch) and
likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);" line at
line 1161. With these 2 lines removed the sunxi-nand-next branch from Boris,
rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can load
the spl / resp. u-boot.bin from there (on a cubieboard2).

You're right... I did spot this, but assumed this was my own mistake in merging 
these patches with our 4.0RC7 tree. Sorry, could have saved you some trouble if 
I were sharper.


I've also tried to get this code running on a cubieboard (non 2 so A10 rather 
then
A20), the SPL loads fine there (indicating that the kernel bits work), but then
I get:

U-Boot SPL 2015.07-rc1-00287-g050de86-dirty (May 25 2015 - 22:28:19)
DRAM: 1024 MiB
CPU: 100800Hz, AXI/AHB/APB: 3/2/2
Nand initialised
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
...

Thanks for testing this. I don't own an A10 myself, so I haven't observed this 
behaviour.
First thing I would verify personally is whether all the clocks are properly configured. 
Could you make U-boot print &ccm->ahb_gate0 and &ccm->nand0_clk_cfg? For the 
first, bits 6 (DMA) and 13 (NAND) must be set, the second must have bit 31 set, bits 24 and 
25 cleared (and otherwise, the accompanying PLL must be configured too... probably easier to 
use the OSC24M), and the divide ratios set to 0 (although a small divider, like 1, shouldn't 
be a problem either).
I am assuming these values should be correct, but only because BROM initialised 
part of it. I am aware of the fact that the SPL driver doesn't control the DMA 
gating reg and the NAND post-dividers. It might be a good idea to do so for as 
long as we don't have a full DMA driver, so I'll patch that up today.


I've just tried the prelimary v4 of your patch-set from:
https://gitlab.com/turtle-solutions/u-boot/commits/sunxi-nand-wip

And the changes you've made fix these errors on the A10, good job.

Regards,

Hans

--
You received this m

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Roy Spliet]

Hello Hans,

Re-sent to everybody instead of just you. Reply inline.

Op 25-05-15 om 22:39 schreef Hans de Goede:

Hi,

On 25-05-15 20:35, Hans de Goede wrote:

Hi,

On 22-05-15 09:04, Roy Spliet wrote:

Hello,

For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or 
actually I rebased his patches on top of 4.0rc7. This basically adds 
support for NAND-chip partitioning, ECC and randomisation. Docs for 
the DT specification in 
Documentation/devicetree/bindings/mtd/sunxi-nand.txt , and an 
example can be found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . 
[2] lists the acceptable configuration options for the boot and 
boot_rescue partitions, make sure to pick one of these (which should 
be no problem for MLC-type nand). The ECC mode for these boot 
partitions is called hw_syndrome.


Assuming you now have a Linux set-up kernel based on this tree with 
NAND support on an MMC, for U-boot what you should currently do is:
1) in include/configs/sunxi-common.h, adjust the parameters 
PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your 
NAND chip and DT configuration.

2) Build
3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
# flash_erase /dev/mtd0
# nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
4) Reboot without the MMC card and see U-boot load


Ok, it took me way longer then I wanted (see below) but I've this
working now. It is cool to see u-boot load from nand :)


That should be all.

@Alex: To answer your question specifically: It's likely that the 
parameters in sunxi-common.h mentioned above might not match your 
NAND-chip configuration in the Linux kernel. I can't tell you 
precisely how to fetch these details from the 3.4 kernel, sorry. I 
recall Daniel using 24-bit strength ECC with otherwise equal 
parameters, but perhaps he can help you with this better than I can.


Alex, could it be that you are writing the nand using
a (rebased) version of bbrezillon's sunxi-nand-next branch ?

I started with that too because it is much newer and contains
various bug fixes, but it seems that it also contains a new
bug causing it to write the NAND in such a way that the BROM
and u-boot SPL code will not read it.

I've just pushed a rebased version of the sunxi-nand branch of
Boris here:

https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

And that works for me, where as before I got the exact same errors
trying to fel load a nand enabled spl.

I'm working on merging over all the changes from the sunxi-nand-next
branch onto my working sunxi-nand-experiment branch 1 by 1 until
I find the one which causes the breakage...


Ok, so quick update the breakage was caused by this commit:

https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c 



When it was rebased someone (Boris I guess) forgot to remove the
"chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the 
patch) and
likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);" 
line at
line 1161. With these 2 lines removed the sunxi-nand-next branch from 
Boris,
rebased on 4.1-rc1 can write the nand boot parts and the brom / spl 
can load

the spl / resp. u-boot.bin from there (on a cubieboard2).
You're right... I did spot this, but assumed this was my own mistake in 
merging these patches with our 4.0RC7 tree. Sorry, could have saved you 
some trouble if I were sharper.


I've also tried to get this code running on a cubieboard (non 2 so A10 
rather then
A20), the SPL loads fine there (indicating that the kernel bits work), 
but then

I get:

U-Boot SPL 2015.07-rc1-00287-g050de86-dirty (May 25 2015 - 22:28:19)
DRAM: 1024 MiB
CPU: 100800Hz, AXI/AHB/APB: 3/2/2
Nand initialised
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
...
Thanks for testing this. I don't own an A10 myself, so I haven't 
observed this behaviour.
First thing I would verify personally is whether all the clocks are 
properly configured. Could you make U-boot print &ccm->ahb_gate0 and 
&ccm->nand0_clk_cfg? For the first, bits 6 (DMA) and 13 (NAND) must be 
set, the second must have bit 31 set, bits 24 and 25 cleared (and 
otherwise, the accompanying PLL must be configured too... probably 
easier to use the OSC24M), and the divide ratios set to 0 (although a 
small divider, like 1, shouldn't be a problem either).
I am assuming these values should be correct, but only because BROM 
initialised part of it. I am aware of the fact that the SPL driver 
doesn't control the DMA gating reg and the NAND post-dividers. It might 
be a good idea to do so for as long as we don't have a full DMA driver, 
so I'll patch that up today.


Roy


Which seems to indicate a problem with the SPL nand code on the A10. 
I'll investigate

this further tomorrow evening.

A cleaned up version of my kernel work on this is available in my
sunxi-wip branch.

Regards,

Hans



--


IMAGINE IT >> MAKE IT

Meet u

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Hans de Goede]

Hi,

On 25-05-15 20:35, Hans de Goede wrote:

Hi,

On 22-05-15 09:04, Roy Spliet wrote:

Hello,

For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or actually I 
rebased his patches on top of 4.0rc7. This basically adds support for NAND-chip 
partitioning, ECC and randomisation. Docs for the DT specification in 
Documentation/devicetree/bindings/mtd/sunxi-nand.txt , and an example can be 
found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . [2] lists the acceptable 
configuration options for the boot and boot_rescue partitions, make sure to 
pick one of these (which should be no problem for MLC-type nand). The ECC mode 
for these boot partitions is called hw_syndrome.

Assuming you now have a Linux set-up kernel based on this tree with NAND 
support on an MMC, for U-boot what you should currently do is:
1) in include/configs/sunxi-common.h, adjust the parameters 
PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND chip 
and DT configuration.
2) Build
3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
# flash_erase /dev/mtd0
# nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
4) Reboot without the MMC card and see U-boot load


Ok, it took me way longer then I wanted (see below) but I've this
working now. It is cool to see u-boot load from nand :)


That should be all.

@Alex: To answer your question specifically: It's likely that the parameters in 
sunxi-common.h mentioned above might not match your NAND-chip configuration in 
the Linux kernel. I can't tell you precisely how to fetch these details from 
the 3.4 kernel, sorry. I recall Daniel using 24-bit strength ECC with otherwise 
equal parameters, but perhaps he can help you with this better than I can.


Alex, could it be that you are writing the nand using
a (rebased) version of bbrezillon's sunxi-nand-next branch ?

I started with that too because it is much newer and contains
various bug fixes, but it seems that it also contains a new
bug causing it to write the NAND in such a way that the BROM
and u-boot SPL code will not read it.

I've just pushed a rebased version of the sunxi-nand branch of
Boris here:

https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

And that works for me, where as before I got the exact same errors
trying to fel load a nand enabled spl.

I'm working on merging over all the changes from the sunxi-nand-next
branch onto my working sunxi-nand-experiment branch 1 by 1 until
I find the one which causes the breakage...


Ok, so quick update the breakage was caused by this commit:

https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c

When it was rebased someone (Boris I guess) forgot to remove the
"chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the patch) and
likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);" line at
line 1161. With these 2 lines removed the sunxi-nand-next branch from Boris,
rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can load
the spl / resp. u-boot.bin from there (on a cubieboard2).

I've also tried to get this code running on a cubieboard (non 2 so A10 rather 
then
A20), the SPL loads fine there (indicating that the kernel bits work), but then
I get:

U-Boot SPL 2015.07-rc1-00287-g050de86-dirty (May 25 2015 - 22:28:19)
DRAM: 1024 MiB
CPU: 100800Hz, AXI/AHB/APB: 3/2/2
Nand initialised
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
NAND timeout reading data
...

Which seems to indicate a problem with the SPL nand code on the A10. I'll 
investigate
this further tomorrow evening.

A cleaned up version of my kernel work on this is available in my
sunxi-wip branch.

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Hans de Goede]

Hi,

On 22-05-15 09:04, Roy Spliet wrote:

Hello,

For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or actually I 
rebased his patches on top of 4.0rc7. This basically adds support for NAND-chip 
partitioning, ECC and randomisation. Docs for the DT specification in 
Documentation/devicetree/bindings/mtd/sunxi-nand.txt , and an example can be 
found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . [2] lists the acceptable 
configuration options for the boot and boot_rescue partitions, make sure to 
pick one of these (which should be no problem for MLC-type nand). The ECC mode 
for these boot partitions is called hw_syndrome.

Assuming you now have a Linux set-up kernel based on this tree with NAND 
support on an MMC, for U-boot what you should currently do is:
1) in include/configs/sunxi-common.h, adjust the parameters 
PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND chip 
and DT configuration.
2) Build
3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
# flash_erase /dev/mtd0
# nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
4) Reboot without the MMC card and see U-boot load


Ok, it took me way longer then I wanted (see below) but I've this
working now. It is cool to see u-boot load from nand :)


That should be all.

@Alex: To answer your question specifically: It's likely that the parameters in 
sunxi-common.h mentioned above might not match your NAND-chip configuration in 
the Linux kernel. I can't tell you precisely how to fetch these details from 
the 3.4 kernel, sorry. I recall Daniel using 24-bit strength ECC with otherwise 
equal parameters, but perhaps he can help you with this better than I can.


Alex, could it be that you are writing the nand using
a (rebased) version of bbrezillon's sunxi-nand-next branch ?

I started with that too because it is much newer and contains
various bug fixes, but it seems that it also contains a new
bug causing it to write the NAND in such a way that the BROM
and u-boot SPL code will not read it.

I've just pushed a rebased version of the sunxi-nand branch of
Boris here:

https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment

And that works for me, where as before I got the exact same errors
trying to fel load a nand enabled spl.

I'm working on merging over all the changes from the sunxi-nand-next
branch onto my working sunxi-nand-experiment branch 1 by 1 until
I find the one which causes the breakage...

Regards,

Hans




Cheers,

Roy

[1] https://github.com/bbrezillon/linux-sunxi/commits/sunxi-nand
[2] https://linux-sunxi.org/NAND#More_information_on_BROM_NAND

Op 22-05-15 om 04:23 schreef kaplan2...@gmail.com:

Hi Roy,

I could definitely use such a howto. I have applied the patches to the current 
mainline u-boot head and try to boot my A13-OlinXino Wifi board in FEL mode.
I can compile and boot into u-boot via FEL. However, I get these errors when I 
have CONFIG_SPL_NAND_SUPPORT defined:

U-Boot SPL 2015.07-rc1-00276-g77792f9-dirty (May 21 2015 - 19:15:54)
DRAM: 512 MiB
Failed to set core voltage! Can't set CPU frequency
sunxi board_nand_init()
Nand initialised
Error: 1 ECC failures detected
Error: 512 ECC failures detected

This is my configs/A13-OLinuXino_defconfig looks like this:
CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,AXP209_POWER,USB_EHCI,SYS_MAX_NAND_DEVICE=1,SYS_NAND_BASE=0x00"
CONFIG_NAND=y
CONFIG_SUNXI_NAND=y
CONFIG_SUNXI_DMA=y
CONFIG_CMD_NAND=y
CONFIG_SPL_NAND_SUPPORT=y
CONFIG_SPL=y
CONFIG_FDTFILE="sun5i-a13-olinuxino.dtb"
CONFIG_USB1_VBUS_PIN="PG11"
CONFIG_VIDEO_HDMI=n
CONFIG_VIDEO_VGA_VIA_LCD=y
CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
# For use with the Olimex 7" LCD module, adjust timings for other displays
# Set video-mode=sunxi:800x600-24@60,monitor=lcd in the env. to enable
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
CONFIG_VIDEO_LCD_POWER="AXP0-0"
CONFIG_VIDEO_LCD_BL_PWM="PB2"
CONFIG_ARM=y
CONFIG_ARCH_SUNXI=y
CONFIG_MACH_SUN5I=y
CONFIG_DRAM_CLK=408
CONFIG_DRAM_ZQ=123
CONFIG_DRAM_EMR1=0
CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"

I just found out in the sun5i-a13-olinuxino.dts file are no nand settings.
I guess I can find the information in the linux-sunxi 3.4 kernels fex file for 
the olinuxio and need to convert to dts, correct?

I am happy about any hints / comments.

Thanks
Alex



On Thursday, May 21, 2015 at 11:08:24 AM UTC-7, Hans de Goede wrote:

Hi Roy,

On 21-05-15 15:59, Roy Spliet wrote:
> The following patches take the work by Daniel Kochmánski, and
make some
> heavy modifications for readability and functionality, based on
Boris
> Brezillon's Linux driver. Tested on an Olimex Lime w/ A20.
> Patches are sent as RFC. Open questions:
> - Config options added are partially NAND-chip specific. Some
options can
> be autodetected based on the NAND ID, others require either
brute-forcing
> or config options like these. Do they belong in sunxi-common?
  

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Daniel Kochmański]

Hello,

sorry for delay. Comments inline.

Hans de Goede writes:

> Hi Roy,
>
> It seems you've accidentally dropped the mailinglist
> from the Cc (I don't see anything private in here),
> so I've readded it.
>
> On 24-05-15 15:30, Roy Spliet wrote:
>> Hello Hans,
>>
>> Comments inline.
>>
>> Op 22-05-15 om 15:51 schreef Hans de Goede:
>>> Hello Roy,
>>>
>>> On 22-05-15 12:12, Roy Spliet wrote:
 Hello Hans,

 Sorry for ignoring the second half of your question so far. Here's what's 
 on my mind.
 Op 21-05-15 om 20:08 schreef Hans de Goede:
> Hi Roy,
>
> 2) What is the plan to add support for loading files from nand in u-boot 
> proper,
> so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on 
> nand ?

 For the full U-boot I agree we want both MMC and NAND support, regardless 
 of where it was loaded from. From what I can tell U-boot already has UBI 
 support. It sounds like a logical step to try and construct a proper NAND 
 driver for U-boot that either co-exists with this SPL driver or, even 
 better, shares code. That way, I only assume that the UBI and UBIFS layers 
 will take care of all the rest.
>>>
>>> Ack.
>>>
 The NAND framework in u-boot resembles Linux in many ways. I'm currently 
 in doubt whether we should take Boris' driver as a starting point, or 
 rather use something heavily reduced that re-uses this SPL code. Either 
 way, in U-boot we can perform a clean NAND-chip detection, preferably 
 based on DT definitions as we also use on Linux, and take care of 
 everything proper like PLL settings and a bunch of parameters which are 
 now hard-coded or a configuration option in sunxi-common.h.
>>>
>>> Have you seen Yassin Jaffer's work porting Boris' code to u-boot ?
>>>
>>> https://github.com/yassinjaffer/u-boot/commits/sunxi-nand
>>>
>>> Last time I mailed with Yassin (added to the Cc) he was ok with someone
>>> else picking this up and continuing with it as the does not have time
>>> to work on it.
>> I have seen the pointer to it, but I have the "nasty" habit of preferring to 
>> look at simple work rather than complex. Hence I ended up with leveraging 
>> Daniel's patches. Considering space limitations, perhaps it would be best if 
>> this SPL driver co-exists with a full NAND driver.
>
> Yes I think that given the space limitations that will be the way to go.
>
>> Even if that means sacrificing code-sharing...?
>
> Yes, as much as I dislike that I think dragging the entire mtd work into
> the SPL simply is not going to fly.
>
>> I might have to get back to you on this once I understand the level of code 
>> sharing between the NAND framework for SPL and for U-boot.
>
> Ok.
>
>> If I were to pick up from Yassin's tree: are there strong reasons why this 
>> work hasn't been merged already?
>
> Not that I can remember, the main problem was lack of time from both the
> reviewer and submitter side IIRC. ATM I'm quite interested in getting
> nand working, so the reviewer side should be covered and I've the
> feeling the same goes for the submitter side, so we should be able
> to make good progress here.
>
>>>
 SPL is a different story. I don't know the exact size restriction, but for 
 A10 I've heard it might be as little as 30KB.
>>> > Current SPL with my patches and without MMC is already 23KiB.
>>>
>>> The BROM loads the SPL to a 32K sram and the stack sits in that same SRAM. 
>>> Note
>>> I've some patches which switch the SPL from using a fill blown malloc to 
>>> using
>>> simple-malloc.c which saves a significant amount of space, and the mmc code
>>> is not really that big, so I think we should be able to cram this all into
>>> the SPL.
>> That sounds like a good plan, it's good enough for SPL.
>>>
 I personally think we can reduce it slightly by taking out support for 
 reading everything other than the bootloader partition from SPL (so remove 
 non-syndrome mode, remove the random seeds table...),
>>>
>>> I agree that removing (#if 0 it for now?) non boot partition support makes
>>> sense as a space saving measure.

That would disable possibility of preloading multiimage with packed boot
script, kernel and devicetree, right? I think code which adds support
for all partitions isn't that big. Or maybe rather loading anything else
then u-boot from u-boot is undesirable?
>>>
 but it certainly doesn't leave any room for the full NAND framework to do 
 ID-based NAND chip detection.
>>>
>>> What info do we need when we're only reading ? If the BROM can get away 
>>> with a fixed
>>> way of reading the nand for booting, we should be able to make the SPL get
>>> away with it too ...  I do really believe that we should be able to deal
>>> with different nand chips from a single binaries, with cheap chinese
>>> devices like the mk802 the chances are simply to big that the nand
>>> will differ from one revision to the next.
>> If we look solely at function

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Hans de Goede]

Hi,

On 25-05-15 11:29, Daniel Kochmański wrote:

Hello,

sorry for delay. Comments inline.

Hans de Goede writes:


Hi Roy,

It seems you've accidentally dropped the mailinglist
from the Cc (I don't see anything private in here),
so I've readded it.

On 24-05-15 15:30, Roy Spliet wrote:

Hello Hans,

Comments inline.

Op 22-05-15 om 15:51 schreef Hans de Goede:

Hello Roy,

On 22-05-15 12:12, Roy Spliet wrote:

Hello Hans,

Sorry for ignoring the second half of your question so far. Here's what's on my 
mind.
Op 21-05-15 om 20:08 schreef Hans de Goede:

Hi Roy,

2) What is the plan to add support for loading files from nand in u-boot proper,
so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ?


For the full U-boot I agree we want both MMC and NAND support, regardless of 
where it was loaded from. From what I can tell U-boot already has UBI support. 
It sounds like a logical step to try and construct a proper NAND driver for 
U-boot that either co-exists with this SPL driver or, even better, shares code. 
That way, I only assume that the UBI and UBIFS layers will take care of all the 
rest.


Ack.


The NAND framework in u-boot resembles Linux in many ways. I'm currently in 
doubt whether we should take Boris' driver as a starting point, or rather use 
something heavily reduced that re-uses this SPL code. Either way, in U-boot we 
can perform a clean NAND-chip detection, preferably based on DT definitions as 
we also use on Linux, and take care of everything proper like PLL settings and 
a bunch of parameters which are now hard-coded or a configuration option in 
sunxi-common.h.


Have you seen Yassin Jaffer's work porting Boris' code to u-boot ?

https://github.com/yassinjaffer/u-boot/commits/sunxi-nand

Last time I mailed with Yassin (added to the Cc) he was ok with someone
else picking this up and continuing with it as the does not have time
to work on it.

I have seen the pointer to it, but I have the "nasty" habit of preferring to 
look at simple work rather than complex. Hence I ended up with leveraging Daniel's 
patches. Considering space limitations, perhaps it would be best if this SPL driver 
co-exists with a full NAND driver.


Yes I think that given the space limitations that will be the way to go.


Even if that means sacrificing code-sharing...?


Yes, as much as I dislike that I think dragging the entire mtd work into
the SPL simply is not going to fly.


I might have to get back to you on this once I understand the level of code 
sharing between the NAND framework for SPL and for U-boot.


Ok.


If I were to pick up from Yassin's tree: are there strong reasons why this work 
hasn't been merged already?


Not that I can remember, the main problem was lack of time from both the
reviewer and submitter side IIRC. ATM I'm quite interested in getting
nand working, so the reviewer side should be covered and I've the
feeling the same goes for the submitter side, so we should be able
to make good progress here.




SPL is a different story. I don't know the exact size restriction, but for A10 
I've heard it might be as little as 30KB.
Current SPL with my patches and without MMC is already 23KiB.


The BROM loads the SPL to a 32K sram and the stack sits in that same SRAM. Note
I've some patches which switch the SPL from using a fill blown malloc to using
simple-malloc.c which saves a significant amount of space, and the mmc code
is not really that big, so I think we should be able to cram this all into
the SPL.

That sounds like a good plan, it's good enough for SPL.



I personally think we can reduce it slightly by taking out support for reading 
everything other than the bootloader partition from SPL (so remove non-syndrome 
mode, remove the random seeds table...),


I agree that removing (#if 0 it for now?) non boot partition support makes
sense as a space saving measure.


That would disable possibility of preloading multiimage with packed boot
script, kernel and devicetree, right? I think code which adds support
for all partitions isn't that big. Or maybe rather loading anything else
then u-boot from u-boot is undesirable?


I guess you mean "loading anything else then u-boot from the spl is 
undesirable?"

So what you're talking about using a multi-image directly from the SPL, is
basically what is falcon mode, and given the restrictions we've in the SPL
I do not think that supporting something like that for nand is a good idea,
in order to access the non boot partitions we need to know some more
nand parameters, and as said I would really like to avoid coding things
like ecc size into Kconfig since different production runs of the same board
(e.g. the famous mk802 boards) may very well use different nand chips,
and I do not want users to need know which production run they exactly have ...

This means we need to get info like this from the nand id, and I'm not sure
that that is doable from the spl.

So for starters I suggest we simply #if 0 the code, with a comment th

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Hans de Goede]

Hi Roy,

It seems you've accidentally dropped the mailinglist
from the Cc (I don't see anything private in here),
so I've readded it.

On 24-05-15 15:30, Roy Spliet wrote:

Hello Hans,

Comments inline.

Op 22-05-15 om 15:51 schreef Hans de Goede:

Hello Roy,

On 22-05-15 12:12, Roy Spliet wrote:

Hello Hans,

Sorry for ignoring the second half of your question so far. Here's what's on my 
mind.
Op 21-05-15 om 20:08 schreef Hans de Goede:

Hi Roy,

2) What is the plan to add support for loading files from nand in u-boot proper,
so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ?


For the full U-boot I agree we want both MMC and NAND support, regardless of 
where it was loaded from. From what I can tell U-boot already has UBI support. 
It sounds like a logical step to try and construct a proper NAND driver for 
U-boot that either co-exists with this SPL driver or, even better, shares code. 
That way, I only assume that the UBI and UBIFS layers will take care of all the 
rest.


Ack.


The NAND framework in u-boot resembles Linux in many ways. I'm currently in 
doubt whether we should take Boris' driver as a starting point, or rather use 
something heavily reduced that re-uses this SPL code. Either way, in U-boot we 
can perform a clean NAND-chip detection, preferably based on DT definitions as 
we also use on Linux, and take care of everything proper like PLL settings and 
a bunch of parameters which are now hard-coded or a configuration option in 
sunxi-common.h.


Have you seen Yassin Jaffer's work porting Boris' code to u-boot ?

https://github.com/yassinjaffer/u-boot/commits/sunxi-nand

Last time I mailed with Yassin (added to the Cc) he was ok with someone
else picking this up and continuing with it as the does not have time
to work on it.

I have seen the pointer to it, but I have the "nasty" habit of preferring to 
look at simple work rather than complex. Hence I ended up with leveraging Daniel's 
patches. Considering space limitations, perhaps it would be best if this SPL driver 
co-exists with a full NAND driver.


Yes I think that given the space limitations that will be the way to go.


Even if that means sacrificing code-sharing...?


Yes, as much as I dislike that I think dragging the entire mtd work into
the SPL simply is not going to fly.


I might have to get back to you on this once I understand the level of code 
sharing between the NAND framework for SPL and for U-boot.


Ok.


If I were to pick up from Yassin's tree: are there strong reasons why this work 
hasn't been merged already?


Not that I can remember, the main problem was lack of time from both the
reviewer and submitter side IIRC. ATM I'm quite interested in getting
nand working, so the reviewer side should be covered and I've the
feeling the same goes for the submitter side, so we should be able
to make good progress here.




SPL is a different story. I don't know the exact size restriction, but for A10 
I've heard it might be as little as 30KB.

> Current SPL with my patches and without MMC is already 23KiB.

The BROM loads the SPL to a 32K sram and the stack sits in that same SRAM. Note
I've some patches which switch the SPL from using a fill blown malloc to using
simple-malloc.c which saves a significant amount of space, and the mmc code
is not really that big, so I think we should be able to cram this all into
the SPL.

That sounds like a good plan, it's good enough for SPL.



I personally think we can reduce it slightly by taking out support for reading 
everything other than the bootloader partition from SPL (so remove non-syndrome 
mode, remove the random seeds table...),


I agree that removing (#if 0 it for now?) non boot partition support makes
sense as a space saving measure.


but it certainly doesn't leave any room for the full NAND framework to do 
ID-based NAND chip detection.


What info do we need when we're only reading ? If the BROM can get away with a 
fixed
way of reading the nand for booting, we should be able to make the SPL get
away with it too ...  I do really believe that we should be able to deal
with different nand chips from a single binaries, with cheap chinese
devices like the mk802 the chances are simply to big that the nand
will differ from one revision to the next.

If we look solely at functionality I agree. It doesn't even make sense giving SPL 
broader support than BROM. The technical half of me is complaining about their 
approach though, because as it stands it does not allow booting from <4GB SLC 
NAND chips. The parameters they try simply don't match what these chips have to 
offer in terms of page size and OOB area.


I do not think that support things which the BROM does not support makes
sense for the FEL code. OTOH no need to cripple it explicitly if the
same code can support more.

For the full u-boot.bin nand driver supporting more then the BROM does
is fine.


Maybe I should try and add an ID read function to at least obtain the page size 
and access 

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Hans de Goede]

Hello Roy,

On 22-05-15 12:12, Roy Spliet wrote:

Hello Hans,

Sorry for ignoring the second half of your question so far. Here's what's on my 
mind.
Op 21-05-15 om 20:08 schreef Hans de Goede:

Hi Roy,

2) What is the plan to add support for loading files from nand in u-boot proper,
so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ?


For the full U-boot I agree we want both MMC and NAND support, regardless of 
where it was loaded from. From what I can tell U-boot already has UBI support. 
It sounds like a logical step to try and construct a proper NAND driver for 
U-boot that either co-exists with this SPL driver or, even better, shares code. 
That way, I only assume that the UBI and UBIFS layers will take care of all the 
rest.


Ack.


The NAND framework in u-boot resembles Linux in many ways. I'm currently in 
doubt whether we should take Boris' driver as a starting point, or rather use 
something heavily reduced that re-uses this SPL code. Either way, in U-boot we 
can perform a clean NAND-chip detection, preferably based on DT definitions as 
we also use on Linux, and take care of everything proper like PLL settings and 
a bunch of parameters which are now hard-coded or a configuration option in 
sunxi-common.h.


Have you seen Yassin Jaffer's work porting Boris' code to u-boot ?

https://github.com/yassinjaffer/u-boot/commits/sunxi-nand

Last time I mailed with Yassin (added to the Cc) he was ok with someone
else picking this up and continuing with it as the does not have time
to work on it.


SPL is a different story. I don't know the exact size restriction, but for A10 
I've heard it might be as little as 30KB.

> Current SPL with my patches and without MMC is already 23KiB.

The BROM loads the SPL to a 32K sram and the stack sits in that same SRAM. Note
I've some patches which switch the SPL from using a fill blown malloc to using
simple-malloc.c which saves a significant amount of space, and the mmc code
is not really that big, so I think we should be able to cram this all into
the SPL.


I personally think we can reduce it slightly by taking out support for reading 
everything other than the bootloader partition from SPL (so remove non-syndrome 
mode, remove the random seeds table...),


I agree that removing (#if 0 it for now?) non boot partition support makes
sense as a space saving measure.


but it certainly doesn't leave any room for the full NAND framework to do 
ID-based NAND chip detection.


What info do we need when we're only reading ? If the BROM can get away with a 
fixed
way of reading the nand for booting, we should be able to make the SPL get
away with it too ...  I do really believe that we should be able to deal
with different nand chips from a single binaries, with cheap chinese
devices like the mk802 the chances are simply to big that the nand
will differ from one revision to the next.


I personally think it's acceptable if NAND-SPL does not have MMC support and 
vice-versa.


Distros already need to build and distribute a u-boot-with-spl.bin per supported
board. This doubles the number of builds they have to do and the number of
files they need to distribute. If at all possible I would really like
to have a unified SPL binary.


For NAND, SPL is only loaded when there is no first-level bootloader found on 
the MMC, so I safely dare to assume U-boot isn't there. MMCs are generally not 
so tiny that SPL fits but U-boot doesn't.


Right, this is mostly for distro / end-user convenience (and also to
avoid needing to build all boards twice when preparing a pull-req).

Regards,

hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Roy Spliet]

Hello Hans,

Sorry for ignoring the second half of your question so far. Here's 
what's on my mind.

Op 21-05-15 om 20:08 schreef Hans de Goede:

Hi Roy,

2) What is the plan to add support for loading files from nand in 
u-boot proper,
so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on 
nand ?


For the full U-boot I agree we want both MMC and NAND support, 
regardless of where it was loaded from. From what I can tell U-boot 
already has UBI support. It sounds like a logical step to try and 
construct a proper NAND driver for U-boot that either co-exists with 
this SPL driver or, even better, shares code. That way, I only assume 
that the UBI and UBIFS layers will take care of all the rest.
The NAND framework in u-boot resembles Linux in many ways. I'm currently 
in doubt whether we should take Boris' driver as a starting point, or 
rather use something heavily reduced that re-uses this SPL code. Either 
way, in U-boot we can perform a clean NAND-chip detection, preferably 
based on DT definitions as we also use on Linux, and take care of 
everything proper like PLL settings and a bunch of parameters which are 
now hard-coded or a configuration option in sunxi-common.h.


SPL is a different story. I don't know the exact size restriction, but 
for A10 I've heard it might be as little as 30KB. Current SPL with my 
patches and without MMC is already 23KiB. I personally think we can 
reduce it slightly by taking out support for reading everything other 
than the bootloader partition from SPL (so remove non-syndrome mode, 
remove the random seeds table...), but it certainly doesn't leave any 
room for the full NAND framework to do ID-based NAND chip detection.
I personally think it's acceptable if NAND-SPL does not have MMC support 
and vice-versa. For NAND, SPL is only loaded when there is no 
first-level bootloader found on the MMC, so I safely dare to assume 
U-boot isn't there. MMCs are generally not so tiny that SPL fits but 
U-boot doesn't.


Questions, comments?
Cheers,

Roy



Regards,

Hans



--


IMAGINE IT >> MAKE IT

Meet us online at Twitter , Facebook 
, Google+ 


www.ultimaker.com

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Michal Suchanek]

On 21 May 2015 at 20:08, Hans de Goede  wrote:
> Hi Roy,
>
> On 21-05-15 15:59, Roy Spliet wrote:
>>
>> The following patches take the work by Daniel Kochmánski, and make some
>> heavy modifications for readability and functionality, based on Boris
>> Brezillon's Linux driver. Tested on an Olimex Lime w/ A20.
>> Patches are sent as RFC. Open questions:
>> - Config options added are partially NAND-chip specific. Some options can
>> be autodetected based on the NAND ID, others require either brute-forcing
>> or config options like these. Do they belong in sunxi-common? Should

I did not look at the u-boot patches but on the kernel side this is
not completely solved I think.

AFAIK the BROM reads the nand in blocks and takes 1k from the start of
block and discards the rest regardless of block size. On the other
hand, the partition size in the DT is in bytes, not blocks. A person
soldered an uncommon nand chip on an Olinuxino board without nand and
the whole driver fell apart probably due to uncommon block size of the
chip.

>> we make a Kconfig option for this? If bikeshedding is desired, are defines
>> in sunxi-common.h good enough for now?
>> - Style is mostly kernel-like. Satisfied?
>> - Daniel: do you think we can work from here?
>>
>> Please comment away!
>
>
> Cool stuff. Overall this looks good I'll reply with more detailed feedback
> to your individual patches, 2 questions:
>
> 1) Can you provide a quick howto (at developer level) on how to actually
> get the spl and u-boot into the nand, what I'm looking for is unstructions
> like this:
>
> a) Take this git repo + branch, build a kernel from it

I have some extra nand patches here:
https://github.com/hramrach/linux-sunxi/commits/sunxi-nand-next

Unfortunately, this branch does not boot on a20 atm, at least from
mmc. I suspect I picked a few too many clock patches but have to
figure out what exactly breaks it.

However, you can cherry-pick

nand IDs
nand partitions on cubieboards
patch to ignore BBMs in case you have Allwinner formatted nand and it
appears 90%+ bad.

with the bbrezillion sunxi-nand-next and these you should be able to
access the cubieboard nand from Linux.

> b) Look at this dts file for a nand settings example, adjust it for your
> board
> c) Once booted into the kernel using an updated dts you should have these
> block devices, dd spl to this one, and u-boot to this one.

You will probably need mtd-utils mtd_debug/nandwrite/ubiformat/ubiattach/...

There are some tutorials on how to use these but I personally did not
try booting from nand so have no definitive answer what to write
where.

Thanks

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Roy Spliet]

Hello,

For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or 
actually I rebased his patches on top of 4.0rc7. This basically adds 
support for NAND-chip partitioning, ECC and randomisation. Docs for the 
DT specification in Documentation/devicetree/bindings/mtd/sunxi-nand.txt 
, and an example can be found in 
arch/arm/boot/dts/sun7i-a20-cubietruck.dts . [2] lists the acceptable 
configuration options for the boot and boot_rescue partitions, make sure 
to pick one of these (which should be no problem for MLC-type nand). The 
ECC mode for these boot partitions is called hw_syndrome.


Assuming you now have a Linux set-up kernel based on this tree with NAND 
support on an MMC, for U-boot what you should currently do is:
1) in include/configs/sunxi-common.h, adjust the parameters 
PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND 
chip and DT configuration.

2) Build
3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND:
# flash_erase /dev/mtd0
# nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin
4) Reboot without the MMC card and see U-boot load

That should be all.

@Alex: To answer your question specifically: It's likely that the 
parameters in sunxi-common.h mentioned above might not match your 
NAND-chip configuration in the Linux kernel. I can't tell you precisely 
how to fetch these details from the 3.4 kernel, sorry. I recall Daniel 
using 24-bit strength ECC with otherwise equal parameters, but perhaps 
he can help you with this better than I can.


Cheers,

Roy

[1] https://github.com/bbrezillon/linux-sunxi/commits/sunxi-nand
[2] https://linux-sunxi.org/NAND#More_information_on_BROM_NAND

Op 22-05-15 om 04:23 schreef kaplan2...@gmail.com:

Hi Roy,

I could definitely use such a howto. I have applied the patches to the 
current mainline u-boot head and try to boot my A13-OlinXino Wifi 
board in FEL mode.
I can compile and boot into u-boot via FEL. However, I get these 
errors when I have CONFIG_SPL_NAND_SUPPORT defined:


U-Boot SPL 2015.07-rc1-00276-g77792f9-dirty (May 21 2015 - 19:15:54)
DRAM: 512 MiB
Failed to set core voltage! Can't set CPU frequency
sunxi board_nand_init()
Nand initialised
Error: 1 ECC failures detected
Error: 512 ECC failures detected

This is my configs/A13-OLinuXino_defconfig looks like this:
CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,AXP209_POWER,USB_EHCI,SYS_MAX_NAND_DEVICE=1,SYS_NAND_BASE=0x00"
CONFIG_NAND=y
CONFIG_SUNXI_NAND=y
CONFIG_SUNXI_DMA=y
CONFIG_CMD_NAND=y
CONFIG_SPL_NAND_SUPPORT=y
CONFIG_SPL=y
CONFIG_FDTFILE="sun5i-a13-olinuxino.dtb"
CONFIG_USB1_VBUS_PIN="PG11"
CONFIG_VIDEO_HDMI=n
CONFIG_VIDEO_VGA_VIA_LCD=y
CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
# For use with the Olimex 7" LCD module, adjust timings for other 
displays

# Set video-mode=sunxi:800x600-24@60,monitor=lcd in the env. to enable
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
CONFIG_VIDEO_LCD_POWER="AXP0-0"
CONFIG_VIDEO_LCD_BL_PWM="PB2"
CONFIG_ARM=y
CONFIG_ARCH_SUNXI=y
CONFIG_MACH_SUN5I=y
CONFIG_DRAM_CLK=408
CONFIG_DRAM_ZQ=123
CONFIG_DRAM_EMR1=0
CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"

I just found out in the sun5i-a13-olinuxino.dts file are no nand settings.
I guess I can find the information in the linux-sunxi 3.4 kernels fex 
file for the olinuxio and need to convert to dts, correct?


I am happy about any hints / comments.

Thanks
Alex



On Thursday, May 21, 2015 at 11:08:24 AM UTC-7, Hans de Goede wrote:

Hi Roy,

On 21-05-15 15:59, Roy Spliet wrote:
> The following patches take the work by Daniel Kochmánski, and
make some
> heavy modifications for readability and functionality, based on
Boris
> Brezillon's Linux driver. Tested on an Olimex Lime w/ A20.
> Patches are sent as RFC. Open questions:
> - Config options added are partially NAND-chip specific. Some
options can
> be autodetected based on the NAND ID, others require either
brute-forcing
> or config options like these. Do they belong in sunxi-common?
Should
> we make a Kconfig option for this? If bikeshedding is desired,
are defines
> in sunxi-common.h good enough for now?
> - Style is mostly kernel-like. Satisfied?
> - Daniel: do you think we can work from here?
>
> Please comment away!

Cool stuff. Overall this looks good I'll reply with more detailed
feedback
to your individual patches, 2 questions:

1) Can you provide a quick howto (at developer level) on how to
actually
get the spl and u-boot into the nand, what I'm looking for is
unstructions
like this:

a) Take this git repo + branch, build a kernel from it
b) Look at this dts file for a nand settings example, adjust it
for your board
c) Once booted into the kernel using an updated dts you should
have these
block devices, dd spl to this one, and u-boot to this one.

No more to go more detailed then that :)

2) What is the plan to add 

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[kaplan2539]

Hi Roy,

I could definitely use such a howto. I have applied the patches to the 
current mainline u-boot head and try to boot my A13-OlinXino Wifi board in 
FEL mode.
I can compile and boot into u-boot via FEL. However, I get these errors 
when I have CONFIG_SPL_NAND_SUPPORT defined:

U-Boot SPL 2015.07-rc1-00276-g77792f9-dirty (May 21 2015 - 19:15:54)
DRAM: 512 MiB
Failed to set core voltage! Can't set CPU frequency
sunxi board_nand_init()
Nand initialised
Error: 1 ECC failures detected
Error: 512 ECC failures detected

This is my configs/A13-OLinuXino_defconfig looks like this:
CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,AXP209_POWER,USB_EHCI,SYS_MAX_NAND_DEVICE=1,SYS_NAND_BASE=0x00"
CONFIG_NAND=y   

CONFIG_SUNXI_NAND=y 

CONFIG_SUNXI_DMA=y  

CONFIG_CMD_NAND=y   

CONFIG_SPL_NAND_SUPPORT=y   

CONFIG_SPL=y

CONFIG_FDTFILE="sun5i-a13-olinuxino.dtb"

CONFIG_USB1_VBUS_PIN="PG11" 

CONFIG_VIDEO_HDMI=n 

CONFIG_VIDEO_VGA_VIA_LCD=y  

CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y   

# For use with the Olimex 7" LCD module, adjust timings for other 
displays  
# Set video-mode=sunxi:800x600-24@60,monitor=lcd in the env. to 
enable  
CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
CONFIG_VIDEO_LCD_POWER="AXP0-0" 

CONFIG_VIDEO_LCD_BL_PWM="PB2"   

CONFIG_ARM=y

CONFIG_ARCH_SUNXI=y 

CONFIG_MACH_SUN5I=y 

CONFIG_DRAM_CLK=408 

CONFIG_DRAM_ZQ=123  

CONFIG_DRAM_EMR1=0  

CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino" 

I just found out in the sun5i-a13-olinuxino.dts file are no nand settings.
I guess I can find the information in the linux-sunxi 3.4 kernels fex file 
for the olinuxio and need to convert to dts, correct?

I am happy about any hints / comments.

Thanks
Alex



On Thursday, May 21, 2015 at 11:08:24 AM UTC-7, Hans de Goede wrote:
>
> Hi Roy, 
>
> On 21-05-15 15:59, Roy Spliet wrote: 
> > The following patches take the work by Daniel Kochmánski, and make some 
> > heavy modifications for readability and functionality, based on Boris 
> > Brezillon's Linux driver. Tested on an Olimex Lime w/ A20. 
> > Patches are sent as RFC. Open questions: 
> > - Config options added are partially NAND-chip specific. Some options 
> can 
> > be autodetected based on the NAND ID, others require either 
> brute-forcing 
> > or config options like these. Do they belong in sunxi-common? Should 
> > we make a Kconfig option for this? If bikeshedding is desired, are 
> defines 
> > in sunxi-common.h good enough for now? 
> > - Style is mostly kernel-like. Satisfied? 
> > - Daniel: do you think we can work from here? 
> > 
> > Please comment away! 
>
> Cool stuff. Overall this looks good I'll reply with more detailed feedback 
> to your individual patches, 2 questions: 
>
> 1) Can you provide a quick howto (at developer level) on how to actually 
> get the spl and u-boot into the nand, what I'm looking for is unstructions 
> like this: 
>
> a) Take this git repo + branch, build a kernel from it 
> b) Look at this dts file for a nand settings example, adjust it for your 
> board 
> c) Once booted into the kernel using an updated dts you should have these 
> block devices, dd spl to this one, and u-boot to this one. 
>
> No more to go more detailed then that :) 
>
> 2) What is the plan to add support for loading files from nand in u-boot 
> proper, 
> so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand 
> ? 
>
> Regards, 
>
> Hans 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL

[Hans de Goede]

Hi Roy,

On 21-05-15 15:59, Roy Spliet wrote:

The following patches take the work by Daniel Kochmánski, and make some
heavy modifications for readability and functionality, based on Boris
Brezillon's Linux driver. Tested on an Olimex Lime w/ A20.
Patches are sent as RFC. Open questions:
- Config options added are partially NAND-chip specific. Some options can
be autodetected based on the NAND ID, others require either brute-forcing
or config options like these. Do they belong in sunxi-common? Should
we make a Kconfig option for this? If bikeshedding is desired, are defines
in sunxi-common.h good enough for now?
- Style is mostly kernel-like. Satisfied?
- Daniel: do you think we can work from here?

Please comment away!


Cool stuff. Overall this looks good I'll reply with more detailed feedback
to your individual patches, 2 questions:

1) Can you provide a quick howto (at developer level) on how to actually
get the spl and u-boot into the nand, what I'm looking for is unstructions
like this:

a) Take this git repo + branch, build a kernel from it
b) Look at this dts file for a nand settings example, adjust it for your board
c) Once booted into the kernel using an updated dts you should have these
block devices, dd spl to this one, and u-boot to this one.

No more to go more detailed then that :)

2) What is the plan to add support for loading files from nand in u-boot proper,
so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ?

Regards,

Hans

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.