Re: [U-Boot] [linux-sunxi] Re: Problems to Allwinner H3's eFUSE/SID

[Hans de Goede]

Hi,

On 22-12-16 11:31, Chen-Yu Tsai wrote:

On Tue, Dec 20, 2016 at 12:17 AM, Hans de Goede <hdego...@redhat.com> wrote:

Hi,


On 19-12-16 17:06, Icenowy Zheng wrote:




19.12.2016, 23:30, "Hans de Goede" <hdego...@redhat.com>:


Hi,

On 19-12-16 16:22, Icenowy Zheng wrote:


 Hi everyone,

 Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
 controller of H3 (incl. H2+).

 See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

 Two read method of the H3 eFUSE is used in the BSP: by register
accessing, or
 directly access 0x01c14200.

 From http://linux-sunxi.org/SID_Register_Guide we can see a difference
between
 the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2
(in
 legacy kernel).

 According to the source of H2+ BSP[1], H2+ and H3 can be differed by
the last
 byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is
H3,
 0x58 is H3D (currently not known SoC) )

 However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3,
start
 with 0x02004620, which do not match this rule.

 The readout by devmem2 is satisfying this rule: their first word is
 0x02c00081, matches H3.

 Then I found the SID-reading code from BSP U-Boot[2], which is based on
 register operations. With this kind of code (I wrote one prototype in
 userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e"
on
 my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel
sid)
 And, after accessing to the SID by registers, the value of *0x01c14200
become
 also "02c00081".

 With direct access to 0x01c14200 after boot with mainline kernel, I got
also
 "02004620".

 Then I altered the program to do the register operations with
sunxi-fel, the
 result is also "02c00081", and changed `sunxi-fel sid` result to
"02c00081".

 Summary:

 +---++
 | Read situation | The first word |
 +---++
 | Direct read by sunxi-fel | 02004620 |
 | Direct read in mainline /dev/mem | 02004620 |
 | Direct read in legacy /dev/mem | 02c00081 |
 | Register access in FEL | 02c00081 |
 | Register access in mainline | 02c00081 |
 | Direct read after register access in FEL | 02c00081 |
 | Direct read after register access in mainline | 02c00081 |
 +---++

 According to some facts:
 - The register based access to SID is weird: it needs ~5 register
   operations per word of SID.
 - Reading via register access will change the value when reading by
accessing
   0x01c14200.
 - In the u-boot code[2] there's some functions which read out the SID
by
   registers and then abandoned the value.
 - This mismatch do not exist on A64.

 I think that: Allwinner designed a "cache" to the SID to make the
simplify the
 code to read it, and it automatically loaded the cache when booting;
however,
 when doing first cache on H3, some byte shifts occured, and the value
become
 wrong. A manual read on H3 can make the cache right again. This is a
silicon
 bug, and fixed in A64.

 This raises a problem: currently many systems has used the misread SID
value to
 generated lots of MAC addresses, and workaround this SID bug will
change them.

 However, if this bug is not workarounded, the sun8i-ths driver won't
work well
 (as some calibartion value lies in eFUSE). I think some early user of
this
 driver has already experienced bad readout value.
 (The calibration value differs on my opi1 and KotCzarny's opipc)

 And many wrong SID values have been generated by `sunxi-fel sid`.
(Although I
 think sunxi-fel must have the workaround)

 Note: in this email, "SID" and "eFUSE" both indicate the controller on
H3/A64
 at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

 Furthermore, A83T may also have this problem, testers are welcome!

 [1]
http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
 [2]
http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

 Experiments:
 - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
   A SID readout shell script via FEL with register access.
 - https://31.135.195.151:20281/d/efuse/
   A SID readout program via /dev/mem with register access by KotCzarny.
   (with statically compiled binary)



Good detective work!

I believe this would best be fixed by making u-boot use the register
access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.



Yes.

However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.



I know, but I think we will just need to accept this onetime change
of the fixed MAC addresses to fix this bug. I don't think this is
a big problem since the driver

Re: [U-Boot] Problems to Allwinner H3's eFUSE/SID

[Hans de Goede]

Hi,

On 19-12-16 17:25, Icenowy Zheng wrote:



20.12.2016, 00:17, "Hans de Goede" <hdego...@redhat.com>:

Hi,

On 19-12-16 17:06, Icenowy Zheng wrote:

 19.12.2016, 23:30, "Hans de Goede" <hdego...@redhat.com>:

 Hi,

 On 19-12-16 16:22, Icenowy Zheng wrote:

  Hi everyone,

  Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
  controller of H3 (incl. H2+).

  See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

  Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
  directly access 0x01c14200.

  From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
  the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
  legacy kernel).

  According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
  byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
  0x58 is H3D (currently not known SoC) )

  However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
  with 0x02004620, which do not match this rule.

  The readout by devmem2 is satisfying this rule: their first word is
  0x02c00081, matches H3.

  Then I found the SID-reading code from BSP U-Boot[2], which is based on
  register operations. With this kind of code (I wrote one prototype in
  userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
  my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel sid)
  And, after accessing to the SID by registers, the value of *0x01c14200 become
  also "02c00081".

  With direct access to 0x01c14200 after boot with mainline kernel, I got also
  "02004620".

  Then I altered the program to do the register operations with sunxi-fel, the
  result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".

  Summary:

  +---++
  | Read situation | The first word |
  +---++
  | Direct read by sunxi-fel | 02004620 |
  | Direct read in mainline /dev/mem | 02004620 |
  | Direct read in legacy /dev/mem | 02c00081 |
  | Register access in FEL | 02c00081 |
  | Register access in mainline | 02c00081 |
  | Direct read after register access in FEL | 02c00081 |
  | Direct read after register access in mainline | 02c00081 |
  +---++

  According to some facts:
  - The register based access to SID is weird: it needs ~5 register
operations per word of SID.
  - Reading via register access will change the value when reading by accessing
0x01c14200.
  - In the u-boot code[2] there's some functions which read out the SID by
registers and then abandoned the value.
  - This mismatch do not exist on A64.

  I think that: Allwinner designed a "cache" to the SID to make the simplify the
  code to read it, and it automatically loaded the cache when booting; however,
  when doing first cache on H3, some byte shifts occured, and the value become
  wrong. A manual read on H3 can make the cache right again. This is a silicon
  bug, and fixed in A64.

  This raises a problem: currently many systems has used the misread SID value 
to
  generated lots of MAC addresses, and workaround this SID bug will change them.

  However, if this bug is not workarounded, the sun8i-ths driver won't work well
  (as some calibartion value lies in eFUSE). I think some early user of this
  driver has already experienced bad readout value.
  (The calibration value differs on my opi1 and KotCzarny's opipc)

  And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
  think sunxi-fel must have the workaround)

  Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
  at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

  Furthermore, A83T may also have this problem, testers are welcome!

  [1] 
http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
  [2] 
http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

  Experiments:
  - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
A SID readout shell script via FEL with register access.
  - https://31.135.195.151:20281/d/efuse/
A SID readout program via /dev/mem with register access by KotCzarny.
(with statically compiled binary)


 Good detective work!

 I believe this would best be fixed by making u-boot use the register access
 method to get the SID on affected chips, and make sure u-boot reads the
 SID at-least once.


 Yes.

 However, what I considered is that fixing this bug will change H3 devices'
 MAC addresses, as they are derived from SID.


I know, but I think we will just need to accept this onetime change
of the fixed M

Re: [U-Boot] Problems to Allwinner H3's eFUSE/SID

[Hans de Goede]

Hi,

On 19-12-16 17:06, Icenowy Zheng wrote:



19.12.2016, 23:30, "Hans de Goede" <hdego...@redhat.com>:

Hi,

On 19-12-16 16:22, Icenowy Zheng wrote:

 Hi everyone,

 Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
 controller of H3 (incl. H2+).

 See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

 Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
 directly access 0x01c14200.

 From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
 the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
 legacy kernel).

 According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
 byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
 0x58 is H3D (currently not known SoC) )

 However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
 with 0x02004620, which do not match this rule.

 The readout by devmem2 is satisfying this rule: their first word is
 0x02c00081, matches H3.

 Then I found the SID-reading code from BSP U-Boot[2], which is based on
 register operations. With this kind of code (I wrote one prototype in
 userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
 my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel sid)
 And, after accessing to the SID by registers, the value of *0x01c14200 become
 also "02c00081".

 With direct access to 0x01c14200 after boot with mainline kernel, I got also
 "02004620".

 Then I altered the program to do the register operations with sunxi-fel, the
 result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".

 Summary:

 +---++
 | Read situation | The first word |
 +---++
 | Direct read by sunxi-fel | 02004620 |
 | Direct read in mainline /dev/mem | 02004620 |
 | Direct read in legacy /dev/mem | 02c00081 |
 | Register access in FEL | 02c00081 |
 | Register access in mainline | 02c00081 |
 | Direct read after register access in FEL | 02c00081 |
 | Direct read after register access in mainline | 02c00081 |
 +---++

 According to some facts:
 - The register based access to SID is weird: it needs ~5 register
   operations per word of SID.
 - Reading via register access will change the value when reading by accessing
   0x01c14200.
 - In the u-boot code[2] there's some functions which read out the SID by
   registers and then abandoned the value.
 - This mismatch do not exist on A64.

 I think that: Allwinner designed a "cache" to the SID to make the simplify the
 code to read it, and it automatically loaded the cache when booting; however,
 when doing first cache on H3, some byte shifts occured, and the value become
 wrong. A manual read on H3 can make the cache right again. This is a silicon
 bug, and fixed in A64.

 This raises a problem: currently many systems has used the misread SID value to
 generated lots of MAC addresses, and workaround this SID bug will change them.

 However, if this bug is not workarounded, the sun8i-ths driver won't work well
 (as some calibartion value lies in eFUSE). I think some early user of this
 driver has already experienced bad readout value.
 (The calibration value differs on my opi1 and KotCzarny's opipc)

 And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
 think sunxi-fel must have the workaround)

 Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
 at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

 Furthermore, A83T may also have this problem, testers are welcome!

 [1] 
http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
 [2] 
http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

 Experiments:
 - https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
   A SID readout shell script via FEL with register access.
 - https://31.135.195.151:20281/d/efuse/
   A SID readout program via /dev/mem with register access by KotCzarny.
   (with statically compiled binary)


Good detective work!

I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.


Yes.

However, what I considered is that fixing this bug will change H3 devices'
MAC addresses, as they are derived from SID.


I know, but I think we will just need to accept this onetime change
of the fixed MAC addresses to fix this bug. I don't think this is
a big problem since the driver for the H3 ethernet has not been
merged into the mainline kernel yet.


Maybe we should add #ifdef's to MAC generation code afte

Re: [U-Boot] Problems to Allwinner H3's eFUSE/SID

[Hans de Goede]

Hi,

On 19-12-16 16:22, Icenowy Zheng wrote:

Hi everyone,

Today, I and KotCzarny on IRC of linux-sunxi found a problem in the SID
controller of H3 (incl. H2+).

See https://irclog.whitequark.org/linux-sunxi/2016-12-19 .

Two read method of the H3 eFUSE is used in the BSP: by register accessing, or
directly access 0x01c14200.

From http://linux-sunxi.org/SID_Register_Guide we can see a difference between
the H3 SIDs read out by sunxi-fel and the H3 SIDs read out by devmem2 (in
legacy kernel).

According to the source of H2+ BSP[1], H2+ and H3 can be differed by the last
byte of the first word of SID. (0x42 and 0x83 is H2+, 0x00 and 0x81 is H3,
0x58 is H3D (currently not known SoC) )

However, all the SIDs retrieved by `sunxi-fel sid`, both H2+ and H3, start
with 0x02004620, which do not match this rule.

The readout by devmem2 is satisfying this rule: their first word is
0x02c00081, matches H3.

Then I found the SID-reading code from BSP U-Boot[2], which is based on
register operations. With this kind of code (I wrote one prototype in
userspace with /dev/mem), I got "02c00081 74004620 50358720 3c27048e" on
my Orange Pi One. ("02004620 74358720 5027048e 3cc3" with sunxi-fel sid)
And, after accessing to the SID by registers, the value of *0x01c14200 become
also "02c00081".

With direct access to 0x01c14200 after boot with mainline kernel, I got also
"02004620".

Then I altered the program to do the register operations with sunxi-fel, the
result is also "02c00081", and changed `sunxi-fel sid` result to "02c00081".

Summary:

+---++
| Read situation| The first word |
+---++
| Direct read by sunxi-fel  | 02004620   |
| Direct read in mainline /dev/mem  | 02004620   |
| Direct read in legacy /dev/mem| 02c00081   |
| Register access in FEL| 02c00081   |
| Register access in mainline   | 02c00081   |
| Direct read after register access in FEL  | 02c00081   |
| Direct read after register access in mainline | 02c00081   |
+---++

According to some facts:
- The register based access to SID is weird: it needs ~5 register
  operations per word of SID.
- Reading via register access will change the value when reading by accessing
  0x01c14200.
- In the u-boot code[2] there's some functions which read out the SID by
  registers and then abandoned the value.
- This mismatch do not exist on A64.

I think that: Allwinner designed a "cache" to the SID to make the simplify the
code to read it, and it automatically loaded the cache when booting; however,
when doing first cache on H3, some byte shifts occured, and the value become
wrong. A manual read on H3 can make the cache right again. This is a silicon
bug, and fixed in A64.

This raises a problem: currently many systems has used the misread SID value to
generated lots of MAC addresses, and workaround this SID bug will change them.

However, if this bug is not workarounded, the sun8i-ths driver won't work well
(as some calibartion value lies in eFUSE). I think some early user of this
driver has already experienced bad readout value.
(The calibration value differs on my opi1 and KotCzarny's opipc)

And many wrong SID values have been generated by `sunxi-fel sid`. (Although I
think sunxi-fel must have the workaround)

Note: in this email, "SID" and "eFUSE" both indicate the controller on H3/A64
at 0x01c14000, which is a OTP memory implemented by eFUSE technique.

Furthermore, A83T may also have this problem, testers are welcome!

[1] 
http://filez.zoobab.com/allwinner/h2/201609022/lichee/linux-3.4/arch/arm/mach-sunxi/sun8i.c
[2] 
http://filez.zoobab.com/allwinner/h2/201609022/lichee/brandy/u-boot-2011.09/arch/arm/cpu/armv7/sun8iw7/efuse.c

Experiments:
- https://gist.github.com/Icenowy/2f4859ab1bc05814522fc7445179a8c9
  A SID readout shell script via FEL with register access.
- https://31.135.195.151:20281/d/efuse/
  A SID readout program via /dev/mem with register access by KotCzarny.
  (with statically compiled binary)


Good detective work!

I believe this would best be fixed by making u-boot use the register access
method to get the SID on affected chips, and make sure u-boot reads the
SID at-least once.

Can you write a patch for this ?

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 0/3] sunxi: video: Add support for HDMI output on H3

[Hans de Goede]

Hi,

On 13-12-16 21:28, Simon Glass wrote:

Hi,

On 12 December 2016 at 19:36, Jernej Skrabec  wrote:

This patch series add support for HDMI output. Support for other,
newer, SoCs, which also uses DE2 and same or similar HDMI controller
and PHY can be easily added later (A83T/A64/H5/R40). Current driver
can also be easily extended with TV out support, just like video
driver for older Allwinner SoCs.

While driver works, I would like to get few opinions first.
- From what I understand, drivers which supports DT are preferred.
  Would it be better to rewrite this driver to support device tree?


Yes I think so, and in fact it should use driver model also.

The rockchip driver provides a reasonable example of how to split the
driver up as you suggest below. The VIDEO driver provides the
top-level video interface, DISPLAY drivers provide display output for
the video, and you have PANEL as well for receiving the display
output. VIDCONSOLE works automatically to display text.

I actually took a bit of a look at this a few weeks ago so am happy to
help with review or discussions.


I'm all in favor of moving to the driver-model, but I believe that
we first need proper support for the DE2 and new HMDI encoder in
the kernel, so that the dt bindings are clear.

Once that is in place it would be good to look into converting the
u-boot code to the driver-model. Since that likely is going to
take a while I think it would be good to move ahead with this
patch set as is (with review comments addressed) and later replace
it with a driver-model based implementation. But that is no longer
my call :)

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

[Hans de Goede]

Hi,

On 30-11-16 11:50, Olliver Schinagl wrote:

Hey maime,

Sorry for constantly getting your e-mail address wrong! Sorry!

On 30-11-16 10:12, maxime.rip...@free-electrons.com wrote:

On Wed, Nov 30, 2016 at 09:00:51AM +, Marcel Ziswiler wrote:

Hi Olliver

On Fri, 2016-11-25 at 16:30 +0100, Olliver Schinagl wrote:

This patch adds a method for the board to set the MAC address if the
environment is not yet set. The environment based MAC addresses are
not
touched, but if the fdt has an alias set, it is parsed and put into
the
environment.

E.g. The environment contains ethaddr and eth1addr, and the fdt
contains
an ethernet1 nothing happens. If the fdt contains ethernet2 however,
it
is parsed and inserted into the environment as eth2addr.

My humble understanding of device tree fixup is that it works the other
way around (e.g. it is the device tree that usually gets fixed up). So
the least I would advice for this patch is to change its naming but
most possibly such code also does not belong into the common
fdt_support implementation.

First, yes I noticed this as well, the nameing is the wrong way around. It took 
me a few reading times as well. I guess I did not full understand Hans's 
suggestion comment. So there's some work needed here.

I don't really have the context of this patch, but in the DT at least,
you can specify the mac address using the local-mac-address
property. I guess we should honor that too. But I don't really know
how that's related to an alias. If the device is probed and the
property is there, use it, otherwise don't.

This came from the sdio_realtek module on some sunxi boards, where the device 
tree has configured it obviously for linux, but u-boot has no notion of it. But 
u-boot IS responsible to generate (the same) MAC address for the device. So 
yes, u-boot inserts a mac address into the device-tree for a found alias.

E.g. ethernet2 is an alias without a MAC address configured for it. Thus u-boot 
is used to generate the MAC address for this node and inserts it into the dtb. 
What I haven't double checked (just blindly assumed, which is the mother) if 
this code also inserts the mac into the environment, but the kernel only gets 
this information via the dtb anyway, right? Either via the dtb, or via the MAC 
register bytes where it is stored in some drivers.


About the setting of the MAC in the environment for devices u-boot
knows nothing about, but which have an alias in the dt, this is
not necessary, it was done in the old code as a way to make the
u-boot fdt code pick up the MAC and inject it into the dtb
passed to the kernel. If this can now happen without setting
it in the env that step can be skipped.

Regards,

Hans

p.s.

I've NOT been following these (and related threads). If anyone
has any questions for me, please send me a direct mail which
does not have "PATCH" in the subject, otherwise I will likely
not seeing as I'm mostly ignoring these threads (sorry -ENOTIME).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: move CONFIG_SATAPWR to Kconfig option

[Hans de Goede]

HI,

On 28-11-16 13:42, Maxime Ripard wrote:

Hi Hans,

On Fri, Nov 25, 2016 at 09:12:30AM +0100, Hans de Goede wrote:

Hi,

On 24-11-16 22:22, Maxime Ripard wrote:

On Wed, Nov 23, 2016 at 07:28:16PM +0100, Jelle van der Waa wrote:

Introduce a new CONFIG_SATAPWR Kconfig option to replace the
option in CONFIG_SYS_EXTRA_OPTIONS.

Signed-off-by: Jelle van der Waa <je...@vdwaa.nl>
---
 board/sunxi/Kconfig|  7 +++
 board/sunxi/board.c| 11 ++-
 configs/A10-OLinuXino-Lime_defconfig   |  3 ++-
 configs/A20-OLinuXino-Lime2_defconfig  |  3 ++-
 configs/A20-OLinuXino-Lime_defconfig   |  3 ++-
 configs/A20-OLinuXino_MICRO_defconfig  |  3 ++-
 configs/A20-Olimex-SOM-EVB_defconfig   |  3 ++-
 configs/Cubieboard2_defconfig  |  3 ++-
 configs/Cubieboard_defconfig   |  3 ++-
 configs/Cubietruck_defconfig   |  3 ++-
 configs/Itead_Ibox_A20_defconfig   |  3 ++-
 configs/Lamobo_R1_defconfig|  3 ++-
 configs/Linksprite_pcDuino3_Nano_defconfig |  3 ++-
 configs/Linksprite_pcDuino3_defconfig  |  3 ++-
 configs/Sinovoip_BPI_M3_defconfig  |  2 +-
 configs/orangepi_plus_defconfig|  3 ++-
 16 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ae2fba1..fe2f7b4 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -667,6 +667,13 @@ config GMAC_TX_DELAY
---help---
Set the GMAC Transmit Clock Delay Chain value.

+config SATAPWR
+   string "power pin for SATA"
+   default ""
+   ---help---
+   Set the power pin for SATA. This takes a string in the format
+   understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+


This looks like a rather generic option. Can't this be in
drivers/block instead?


The proper solution would be to get the info from devicetree,
which requires regulator support, which we don't have yet
for sunxi. In the mean time getting rid of the need for
CONFIG_SYS_EXTRA_OPTIONS is a worthwhile goal in itself
IMHO.


Yes, but a GPIO to enable the SATA 5V rail seems like a rather common
thing, and definitely not Allwinner specific.

Moving that option to drivers/block would make more sense I guess.


Hmm, but in the end this should be removed, as everything should'
be using devicetree, so I'm not convinced it is a good idea
to introduce a generic option for this.

Anyways either way is fine with me.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd: usb: run 'usb start' when USB is stopped

[Hans de Goede]

Hi,

On 28-11-16 07:54, Minkyu Kang wrote:

Hi Jaehoon,

On 28/11/16 14:08, Jaehoon Chung wrote:

Hi Marek,

On 09/23/2016 01:15 PM, Simon Glass wrote:

+Marek

On 9 September 2016 at 04:20, Jaehoon Chung  wrote:

If USB is stopped, just run 'usb start' instead of printing message.
Then user didn't consider whether usb is started or stopped.


Do you have any other opinion for this? :)

Best Regards,
Jaehoon Chung



Signed-off-by: Jaehoon Chung 
---
 cmd/usb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/cmd/usb.c b/cmd/usb.c
index 455127c..4970851 100644
--- a/cmd/usb.c
+++ b/cmd/usb.c
@@ -651,8 +651,8 @@ static int do_usb(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return 0;
}
if (!usb_started) {
-   printf("USB is stopped. Please issue 'usb start' first.\n");
-   return 1;
+   printf("USB is stopped. Running 'usb start' first.\n");
+   do_usb_start();
}


It seems to ambiguous whether initialization was succeed or not.


Right at a minimum it should detect that do_usb_start succeeds. E.g.
on an otg port without an otg -> usb-host cable plugged in it will not
succeed.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: move CONFIG_SATAPWR to Kconfig option

[Hans de Goede]

Hi,

On 24-11-16 22:22, Maxime Ripard wrote:

On Wed, Nov 23, 2016 at 07:28:16PM +0100, Jelle van der Waa wrote:

Introduce a new CONFIG_SATAPWR Kconfig option to replace the
option in CONFIG_SYS_EXTRA_OPTIONS.

Signed-off-by: Jelle van der Waa 
---
 board/sunxi/Kconfig|  7 +++
 board/sunxi/board.c| 11 ++-
 configs/A10-OLinuXino-Lime_defconfig   |  3 ++-
 configs/A20-OLinuXino-Lime2_defconfig  |  3 ++-
 configs/A20-OLinuXino-Lime_defconfig   |  3 ++-
 configs/A20-OLinuXino_MICRO_defconfig  |  3 ++-
 configs/A20-Olimex-SOM-EVB_defconfig   |  3 ++-
 configs/Cubieboard2_defconfig  |  3 ++-
 configs/Cubieboard_defconfig   |  3 ++-
 configs/Cubietruck_defconfig   |  3 ++-
 configs/Itead_Ibox_A20_defconfig   |  3 ++-
 configs/Lamobo_R1_defconfig|  3 ++-
 configs/Linksprite_pcDuino3_Nano_defconfig |  3 ++-
 configs/Linksprite_pcDuino3_defconfig  |  3 ++-
 configs/Sinovoip_BPI_M3_defconfig  |  2 +-
 configs/orangepi_plus_defconfig|  3 ++-
 16 files changed, 40 insertions(+), 19 deletions(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index ae2fba1..fe2f7b4 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -667,6 +667,13 @@ config GMAC_TX_DELAY
---help---
Set the GMAC Transmit Clock Delay Chain value.

+config SATAPWR
+   string "power pin for SATA"
+   default ""
+   ---help---
+   Set the power pin for SATA. This takes a string in the format
+   understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
+


This looks like a rather generic option. Can't this be in
drivers/block instead?


The proper solution would be to get the info from devicetree,
which requires regulator support, which we don't have yet
for sunxi. In the mean time getting rid of the need for
CONFIG_SYS_EXTRA_OPTIONS is a worthwhile goal in itself
IMHO.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-spi/sunxi

[Hans de Goede]

Hi,

On 24-11-16 15:55, Maxime Ripard wrote:

On Thu, Nov 24, 2016 at 08:05:55PM +0530, Jagan Teki wrote:

Hi Tom,

These are the pending patches, from u-boot-sunxi/next.

Will send sunxi PR on top of u-boot-sunxi repo once I get the access,
meanwhile please take this PR.

Hans, Let me know if I miss any patches from next.

thanks!
Jagan.

The following changes since commit fc127d184aea293ec415dd66e3282dba0b66c5f3:

  colibri_pxa270: drop edit, elf, fpga, hush, regex et al. for space reason 
(2016-11-23 13:53:20 +0100)

are available in the git repository at:

  git://git.denx.de/u-boot-spi.git sunxi

for you to fetch changes up to e68a831cacc85ea1da274f3c8d19bb98c1141a97:

  nand: sunxi: Add options for the SPL NAND configuration (2016-11-24 19:40:49 
+0530)


Boris Brezillon (1):
  mtd: nand: add support for the TC58NVG2S0H chip

Chen-Yu Tsai (9):
  ARM: PSCI: Set ARMV7_PSCI_NR_CPUS default to 8 for sun9i/A80
  sunxi: Add CCI-400 and CPUCFG registers base address for sun9i/A80
  sunxi: Add base address of secure SRAM B for sun9i/A80
  sunxi: Use secure SRAM B for secure RAM for sun9i/A80
  sunxi: Add PRCM register definition for sun9i/A80
  sunxi: Add CPUCFG register definitions for sun9i/A80
  sunxi: Add support for TZPC on sun9i/A80
  sunxi: Add basic PSCI implementation for A80
  sunxi: Enable PSCI on sun9i/A80

Emmanuel Vadot (1):
  sunxi: mmc: Set CONFIG_SYS_MMC_MAX_DEVICE

Hans de Goede (1):
  sunxi: Mele_M5_defconfig: Drop non existing STATUSLED setting

Jelle van der Waa (1):
  sunxi: Use the available Kconfig option for AHCI

Marcel Ziswiler (1):
  colibri_pxa270: transition to driver model for serial

Maxime Ripard (3):
  sunxi: Sync GR8 DTS and AXP209 with the kernel
  tools: sunxi: Add spl image builder
  nand: sunxi: Add options for the SPL NAND configuration


Hmmm, I'm not sure why it's in though.

I sent an update version of those since the first iteration had
issues.


Probably my bad, I put this in u-boot-sunxi/next before I stepped
down as maintainer. Which of these 3 patches need to be dropped
exactly?

Otherwise this pull-req looks good. Jagan, thank you for your
work on this!

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Mele_M5_defconfig: Drop non existing STATUSLED setting

[Hans de Goede]

Hi,

On 21-11-16 11:05, Jagan Teki wrote:

On Mon, Nov 14, 2016 at 12:24 AM, Hans de Goede <hdego...@redhat.com> wrote:

And also remove it from scripts/config_whitelist.txt as the
Mele_M5_defconfig was the only one defining it.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 configs/Mele_M5_defconfig| 2 +-
 scripts/config_whitelist.txt | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/configs/Mele_M5_defconfig b/configs/Mele_M5_defconfig
index fffc332..09addc5 100644
--- a/configs/Mele_M5_defconfig
+++ b/configs/Mele_M5_defconfig
@@ -9,7 +9,7 @@ CONFIG_VIDEO_COMPOSITE=y
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-m5"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_AHCI=y
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,STATUSLED=234"


Still exist in boards.cfg?


boards.cfg is generated for backward-compat with some
scripts now a days, it is not part of the git repo.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Stepping down as sunxi u-boot custodian (for real this time)

[Hans de Goede]

Hi,

On 18-11-16 16:48, Jagan Teki wrote:

On Fri, Nov 18, 2016 at 8:03 PM, Andre Przywara <andre.przyw...@arm.com> wrote:

Hi,

On 18/11/16 13:02, Jagan Teki wrote:

On Fri, Nov 18, 2016 at 3:48 AM, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:

Hi Hans,

On Mon, Nov 14, 2016 at 12:53:13PM +0100, Hans de Goede wrote:

Hi All,

A while back I wrote:

"Between my $dayjob, linux-sunxi, other foss projects and last but
not least spending time with my wife and children I'm way too
busy lately.

So I've decided to seriously scale back my involvement in
linux-sunxi, as such I'm going to step down as u-boot sunxi
custodian."


Hans, thanks for all your great work.


+1 for Hans' good work!



After that I did get some breathing room, and kept doing
sunxi u-boot maintenance until now, but this still feels
too much like a job rather then a hobby. The problem is
that I don't want to think during the weekend:
"Oh !@#$ I still need to prep a u-boot sunxi pull-req"

This is nothing against the u-boot community, I think
you're all great and I still love thinkering with this
kind of stuff, but when a hobby starts feeling as a chore
something is wrong.

So after this mail I'm going to send a mail updating
the MAINTAINERS status of sunxi to orphan and I will also
unsubscribe myself from the u-boot list to protect myself
against getting dragged in again.

I do expect (after taking a break for a couple of weeks)
that I will likely submit the occasional patch, but at
this point in time I do not want any maintainer
responsibilities.

Yesterday and today I've gone over my pending patches
queue, reviewed then all and I've merged all the ones
which looked good into u-boot-sunxi/next, so that
should be a good starting point for the next
maintainer.


Thanks a lot for the great work you did over those years :)


Jagan (in the Cc) has indicated in the past that he is
interested in taking over as sunxi custodian, Jagan already
is the SPI custodian, so I believe that he will do well.

So Jagan, if you still want the job, go for it.


OK, Hans thanks for believing my work - will try my best.



As I said before, I can help whoever is willing to take over by
becoming co-maintainer for some time, in order to make the transition
as smooth as possible.

Jagan, are you still willing to do this?


Yes, Maxime I will do this, please help me for initial transition and
technical details if any.
Can I get any board sample from any all-winner or related communities?


Feel free to send any 64-bit (A64, H64, H5) related questions/patches
into my direction. I can test stuff, also give advice and do reviews.


Thanks.

Hans, I see few redundant commits on next wrt latest master in b/w,
can you point me diff commits which needs to send PR? I tried of
comparing but not get the exact result.


If you checkout u-boot-sunxi/next and then do a "git rebase u-boot/master"
git should give you a new next branch, with the already merged commits
removed.

Regards,

Hans

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Stepping down as sunxi u-boot custodian (for real this time)

[Hans de Goede]

Hi,

On 17-11-16 20:50, Simon Glass wrote:

Hi Hans,

On 14 November 2016 at 04:53, Hans de Goede <hdego...@redhat.com> wrote:

Hi All,

A while back I wrote:

"Between my $dayjob, linux-sunxi, other foss projects and last but
not least spending time with my wife and children I'm way too
busy lately.

So I've decided to seriously scale back my involvement in
linux-sunxi, as such I'm going to step down as u-boot sunxi
custodian."


Thanks for everything you have done, Hans! Are there really 100 sunxi
boards?


[hans@shalem u-boot]$ grep -l SUNXI configs/*_defconfig | wc -l
100

> You have been busy.

Yep.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 07/11] net: sunxi: Do not inject ethernet addresses into the env

[Hans de Goede]

Hi,

On 15-11-16 11:29, Olliver Schinagl wrote:

Hey Hans,

I guess I have to contradict something here ...

On 15-11-16 11:17, Olliver Schinagl wrote:

Hey Hans,

I was hopeing and expecting this :)


As you will be able to tell below, I need to learn a bit more as to why
we do things and discuss this proper I guess.


On 15-11-16 10:26, Hans de Goede wrote:

Hi,

On 15-11-16 04:25, Joe Hershberger wrote:

On Tue, Nov 8, 2016 at 9:54 AM, Olliver Schinagl <oli...@schinagl.nl>
wrote:

Currently we inject 5 ethernet addresses into the environment, just in
case we may need them. We do this because some boards have no eeprom
(programmed) with a proper ethernet address. With the recent
addition of
reading actual ethernet addresses from the eeprom via the net_op we
should not inject environment variables any more.

Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>


Acked-by: Joe Hershberger <joe.hershber...@ni.com>



Erm, this patch seems wrong to me: NACK, let me
explain:

1) It does not do what its commit message says, it only
removes the second step for setting ethernet addresses
from the env, but it keeps the existing code to set them
AFAICT, it only does it once now.

2) "Currently we inject 5 ethernet addresses into the environment",
this is not true, we only inject ethernet addresses into the
environment for devices which have an ethernet alias in dt,
so maximum 2 for devices with both wired ethernet and wifi

If we want the fdt to do mac things, shouldn't that be done at a higher
level? This is not really board specific is it?


3) The second attempt at setting ethernet addresses in
the environment after loading the kernel dt is necessary
because the kernel dt may be newer and contain more
ethernet aliases, e.g. the u-boot dt may only contain the
nodes + alias for the wired, while the (newer) kernel dt
may also contain a dt-node + alias for the wireless

I agree with you here, but I still don't think this should be board
specific


4) We cannot solely rely on the ethernet driver to set
mac-addresses, because the ethernet driver may not be enabled
while the kernel does have the ethernet driver enabled; and
the kernel relies on u-boot to generate fixed mac-addresses
based on the SID independent whether or not u-boot has
ethernet enabled, this is especially relevant for wifi
chips where the kernel also relies on u-boot generated
fixed mac-addresses on e.g. the recent orange-pi boards,
which come with a realtek rtl8189etv chip which does not
have a mac address programmed.

I agree, and I'll fix that in my new patch series proper by making
rtl8189etv also read rom hook which IS board specific


Of course I didn't realize that the rtl8189etv does not have a u-boot driver, 
and thus does not get to call its hook and thus nothing sunxi specific will 
ever be invoked.

So I guess in the case of the rtl8189 we have to figure out something (probably 
near the same as you did) to make it work.

It does feel somewhat nasty/hackish of course. I would expect that the linux 
driver sorts this out for itself and not simply assume u-boot supplies this 
info on non-existing hardware (to u-boot).


We've the same with e.g. the wobo-i5 which has its emac routed to
an other set of pins then which are usually used which u-boot does
not support. Yet the kernel emac driver relies on u-boot to set a
MAC, or it will fall back to a random-MAC (which is undesirable).

Likewise if someone configures u-boot without network support
to make it boot faster, we get the same problem with the emac /
gmac driver.

The logic here really goes like this:

1) When u-boot does have network support, and picks a MAC-address
that MAC-address should be propagated to the kernel so that it
uses the same MAC (this is esp. important with switches which
allow only 1 MAC per port as a security setting).

2) 1. means that u-boot has some algorithm to pick a fixed MAC
in a SoC specific manner. Since we do not want booting with an
u-boot with networking enabled resulting in a different fixed
MAC then booting on a u-boot without networking support, this
means that this algorithm should be used even when networking
support in u-boot is disabled (e.g. the wobo-i5 case).

3) Given 2. it makes sense to simply have u-boot generate
MACs for all NICs in the system.


I need some time to think this over, so I'm hoping smarter people then me come 
with great suggestions here :)


I still think that my suggestion for having fdt_fixup_ethernet()
from common/fdt_support.c call a board specific function instead
of the "continue" here:

tmp = getenv(mac);
if (!tmp)
continue;

for (j = 0; j < 6; j++) {
mac_addr[j] = tmp ?
  simple_strtoul(tmp, , 16) : 0;
if (tmp)
   

Re: [U-Boot] [PATCH 07/11] net: sunxi: Do not inject ethernet addresses into the env

[Hans de Goede]

Hi,

On 15-11-16 11:17, Olliver Schinagl wrote:

Hey Hans,

I was hopeing and expecting this :)


As you will be able to tell below, I need to learn a bit more as to why we do 
things and discuss this proper I guess.


On 15-11-16 10:26, Hans de Goede wrote:

Hi,

On 15-11-16 04:25, Joe Hershberger wrote:

On Tue, Nov 8, 2016 at 9:54 AM, Olliver Schinagl <oli...@schinagl.nl> wrote:

Currently we inject 5 ethernet addresses into the environment, just in
case we may need them. We do this because some boards have no eeprom
(programmed) with a proper ethernet address. With the recent addition of
reading actual ethernet addresses from the eeprom via the net_op we
should not inject environment variables any more.

Signed-off-by: Olliver Schinagl <oli...@schinagl.nl>


Acked-by: Joe Hershberger <joe.hershber...@ni.com>



Erm, this patch seems wrong to me: NACK, let me
explain:

1) It does not do what its commit message says, it only
removes the second step for setting ethernet addresses
from the env, but it keeps the existing code to set them
AFAICT, it only does it once now.

2) "Currently we inject 5 ethernet addresses into the environment",
this is not true, we only inject ethernet addresses into the
environment for devices which have an ethernet alias in dt,
so maximum 2 for devices with both wired ethernet and wifi

If we want the fdt to do mac things, shouldn't that be done at a higher level? 
This is not really board specific is it?


We want to put mac addresses into the fdt, and this is done at
a higher level, by existing dt code, which looks at ethernet
aliases in dt and then for any which are present, checks
the corresponding ethaddr env setting and if set, injects
that mac address into the dt-node the alias points to.

What is sunxi specific is setting the environment variables
based on the SID. The sunxi specific code also checks the
aliases, exactly to avoid the "inject 5 ethernet addresses"
thing you are describing, as we don't want to inject
ethernet addresses for non existent NICs as that may confuse
the user.


3) The second attempt at setting ethernet addresses in
the environment after loading the kernel dt is necessary
because the kernel dt may be newer and contain more
ethernet aliases, e.g. the u-boot dt may only contain the
nodes + alias for the wired, while the (newer) kernel dt
may also contain a dt-node + alias for the wireless

I agree with you here, but I still don't think this should be board specific


Instead of doing this through the environment I guess you
could have the u-boot dt code which is injecting the MACs
into the dt call some board specific callback when there
is no MAC set in the environment, and implement a weak
stub for this. Then all the sunxi environment mangling
code can go away, and sunxi can simply:
1) Try eeprom if present
2) Do the current SID based thing


4) We cannot solely rely on the ethernet driver to set
mac-addresses, because the ethernet driver may not be enabled
while the kernel does have the ethernet driver enabled; and
the kernel relies on u-boot to generate fixed mac-addresses
based on the SID independent whether or not u-boot has
ethernet enabled, this is especially relevant for wifi
chips where the kernel also relies on u-boot generated
fixed mac-addresses on e.g. the recent orange-pi boards,
which come with a realtek rtl8189etv chip which does not
have a mac address programmed.

I agree, and I'll fix that in my new patch series proper by making rtl8189etv 
also read rom hook which IS board specific


The problem is that u-boot may not have a driver for one
of the NICs at all, so no place to call the rom hook at all.

Anyways I believe this is solved by my suggestion for making
the u-boot dt code which injects the MAC call a board specific
callback when no ethaddr is set in the env.


5) AFAIK the dt code for passing mac-addresses to the kernel
relies on the environment variables, so even if we get the
mac-address from a ROM we should still store it in the
environment variable.

The new patch series does that, as the net core layer does that.

What happens is (note code is mangled and might not be 100% accurate, i reduced 
it the bares):

eth_read_eeprom_hwaddr(dev);
first read from the eeprom, which may return all zero's if it is 
unconfigured/missconfigured or should not be used from the eeprom.
if (is_zero_ethaddr(pdata->enetaddr))
if (eth_get_ops(dev)->read_rom_hwaddr)
eth_get_ops(dev)->read_rom_hwaddr(dev);
if the eeprom failed to produce a mac, we check the read_rom_hwaddr callback, 
which hooks into the driver. The driver can be overridden by a board (such as 
sunxi) where the MAC is generated from the SID.

so at this point we may have a hwaddress actually obtained from the hardware, 
via the eeprom (or some fixed rom even) or from the hardware itself
next we allow 'software' overrides. e.g. u-boot env (and i think this is where 
the fdt method should live as we

Re: [U-Boot] [PATCH 07/11] net: sunxi: Do not inject ethernet addresses into the env

[Hans de Goede]

Hi,

On 15-11-16 04:25, Joe Hershberger wrote:

On Tue, Nov 8, 2016 at 9:54 AM, Olliver Schinagl  wrote:

Currently we inject 5 ethernet addresses into the environment, just in
case we may need them. We do this because some boards have no eeprom
(programmed) with a proper ethernet address. With the recent addition of
reading actual ethernet addresses from the eeprom via the net_op we
should not inject environment variables any more.

Signed-off-by: Olliver Schinagl 


Acked-by: Joe Hershberger 



Erm, this patch seems wrong to me: NACK, let me
explain:

1) It does not do what its commit message says, it only
removes the second step for setting ethernet addresses
from the env, but it keeps the existing code to set them
AFAICT, it only does it once now.

2) "Currently we inject 5 ethernet addresses into the environment",
this is not true, we only inject ethernet addresses into the
environment for devices which have an ethernet alias in dt,
so maximum 2 for devices with both wired ethernet and wifi

3) The second attempt at setting ethernet addresses in
the environment after loading the kernel dt is necessary
because the kernel dt may be newer and contain more
ethernet aliases, e.g. the u-boot dt may only contain the
nodes + alias for the wired, while the (newer) kernel dt
may also contain a dt-node + alias for the wireless

4) We cannot solely rely on the ethernet driver to set
mac-addresses, because the ethernet driver may not be enabled
while the kernel does have the ethernet driver enabled; and
the kernel relies on u-boot to generate fixed mac-addresses
based on the SID independent whether or not u-boot has
ethernet enabled, this is especially relevant for wifi
chips where the kernel also relies on u-boot generated
fixed mac-addresses on e.g. the recent orange-pi boards,
which come with a realtek rtl8189etv chip which does not
have a mac address programmed.

5) AFAIK the dt code for passing mac-addresses to the kernel
relies on the environment variables, so even if we get the
mac-address from a ROM we should still store it in the
environment variable.

Regards,

Hans

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Stepping down as sunxi u-boot custodian (for real this time)

[Hans de Goede]

Hi,

On 14-11-16 18:00, Yann E. MORIN wrote:

Hans, Ian, All,

On 2016-11-14 12:53 +0100, Hans de Goede spake thusly:

A while back I wrote:

"Between my $dayjob, linux-sunxi, other foss projects and last but
not least spending time with my wife and children I'm way too
busy lately.

So I've decided to seriously scale back my involvement in
linux-sunxi, as such I'm going to step down as u-boot sunxi
custodian."


So long, and thanks for all the fish! :-)


So after this mail I'm going to send a mail updating
the MAINTAINERS status of sunxi to orphan and I will also
unsubscribe myself from the u-boot list to protect myself
against getting dragged in again.


Don't forget to update (or get updated) the list of custodians on the
website (which is where I found the info):
http://www.denx.de/wiki/U-Boot/Custodians


I don't believe I have a denx.de wiki account.

Tom can you fix this please?

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Hans de Goede]

Hi,

On 14-11-16 15:12, Maxime Ripard wrote:

On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:

 #ifdef CONFIG_SPL_SPI_SUNXI
@@ -143,7 +157,14 @@
 #define CONFIG_GENERIC_MMC
 #define CONFIG_MMC_SUNXI
 #define CONFIG_MMC_SUNXI_SLOT  0
-#define CONFIG_ENV_IS_IN_MMC
+#endif
+
+#if defined(CONFIG_ENV_IS_IN_NAND)
+#define CONFIG_ENV_OFFSET  0xc0
+#define CONFIG_ENV_SIZE0x40
+#elif defined(CONFIG_ENV_IS_IN_MMC)
+#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) 
KiB */
+#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB 
*/
 #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
controller */
 #endif


Oh, and this part is broken. It relies on the fact that all board
define ENV_IS_IN_MMC (which they should), while obviously they
don't. I'm not exactly sure about what the proper fix would be.


Yes, this has been a known problem for a while, but never
became an issue due to lack of NAND support.

My preferred way for dealing with this be would for the
environment code in u-boot allowing to build in multiple
back-ends and use spl_boot_device() which then would need
to loose its spl prefix. For the CHIP devices I'm sure
you can come up with a simpler fix since those don't
have an sdcard-slot. But for other boards this will be
necessary as we really don't want to have separate
nand and mmc u-boot.bin files.

Anyways this is something for whomever will take over
as sunxi custodian from me. Maybe someone from free-electrons
can co-maintain with Jagan ?

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Do not force master mode on unaffected PHY's

[Hans de Goede]

Hi,

On 14-11-16 15:11, Olliver Schinagl wrote:

Hey Hans,


On 14-11-16 12:26, Hans de Goede wrote:

Hi,

On 08-11-16 17:38, Olliver Schinagl wrote:

The current implementation to force the PHY into master mode is to have a
define which affects all realtek PHY's. This is not needed as the problem
only exists in the RTL8211C chips. Let us thus turn this into a quirk flag
instead.


Series looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Thanks, but keep your eye on the thread. I'm working on a v3 where i'm pulling 
the eeprom stuff out of the sunxi stuff, and in the net-uclass layer!


Erm, this is another series :)

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Hans de Goede]

Hi,

On 14-11-16 15:09, Maxime Ripard wrote:

Hi,

On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:

 #ifdef CONFIG_SPL_SPI_SUNXI
@@ -143,7 +157,14 @@
 #define CONFIG_GENERIC_MMC
 #define CONFIG_MMC_SUNXI
 #define CONFIG_MMC_SUNXI_SLOT  0
-#define CONFIG_ENV_IS_IN_MMC
+#endif
+
+#if defined(CONFIG_ENV_IS_IN_NAND)
+#define CONFIG_ENV_OFFSET  0xc0
+#define CONFIG_ENV_SIZE0x40
+#elif defined(CONFIG_ENV_IS_IN_MMC)
+#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) 
KiB */
+#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB 
*/
 #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
controller */
 #endif



I would greatly prefer putting the env in an UBI partition,
I thought that we had agreed on doing that ?


That was mentionned a few times, but I didn't remember having a final
decision. I'm not really sure that putting the environment in UBI
would be a good idea.

Attaching the UBI volume takes a very significant time. Doing so
before the user can see that something is happening in the system
feels pretty bad.


So maybe we need to print a message before doing so ?

We really need bad-block management for the environment, AFAICT
the current non UBI implementation does not even have a backup ?

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Hans de Goede]

Hi,

On 14-11-16 14:53, Maxime Ripard wrote:

On Mon, Nov 14, 2016 at 12:29:25PM +0100, Hans de Goede wrote:

Hi,

On 14-11-16 12:18, Hans de Goede wrote:

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

This program generates raw SPL images that can be flashed on the NAND with
the ECC and randomizer properly set up.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>


Note this causes a cpu_to_be32 redefine compiler warning
I've fixed this up locally.


I'll have to send a v2 based on Tom's comments. How did you fix this?


I added an undef above the define, if you use the
pre-existing macro you get problems later
because it gets called as cpu_to_be32(*addr++)
and the pre-existing macro references its argument
multiple times.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] MAINTAINERS: mark sunxi status as Orphan

[Hans de Goede]

Ian has not had any time for sunxi for some time now and I'm
in the same situation now, so I'm stepping down as sunxi
custodian and marking the sunxi support as Orphan.

Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Chen-Yu Tsai <w...@csie.org>
Cc: Ian Campbell <i...@hellion.org.uk>
Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 MAINTAINERS | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0bd8995..83a70df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -167,9 +167,7 @@ F:  arch/arm/cpu/armv7/stv0991/
 F: arch/arm/include/asm/arch-stv0991/
 
 ARM SUNXI
-M: Ian Campbell <i...@hellion.org.uk>
-M: Hans De Goede <hdego...@redhat.com>
-S: Maintained
+S: Orphan
 T: git git://git.denx.de/u-boot-sunxi.git
 F: arch/arm/cpu/armv7/sunxi/
 F: arch/arm/include/asm/arch-sunxi/
-- 
2.9.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Stepping down as sunxi u-boot custodian (for real this time)

[Hans de Goede]

Hi All,

A while back I wrote:

"Between my $dayjob, linux-sunxi, other foss projects and last but
not least spending time with my wife and children I'm way too
busy lately.

So I've decided to seriously scale back my involvement in
linux-sunxi, as such I'm going to step down as u-boot sunxi
custodian."

After that I did get some breathing room, and kept doing
sunxi u-boot maintenance until now, but this still feels
too much like a job rather then a hobby. The problem is
that I don't want to think during the weekend:
"Oh !@#$ I still need to prep a u-boot sunxi pull-req"

This is nothing against the u-boot community, I think
you're all great and I still love thinkering with this
kind of stuff, but when a hobby starts feeling as a chore
something is wrong.

So after this mail I'm going to send a mail updating
the MAINTAINERS status of sunxi to orphan and I will also
unsubscribe myself from the u-boot list to protect myself
against getting dragged in again.

I do expect (after taking a break for a couple of weeks)
that I will likely submit the occasional patch, but at
this point in time I do not want any maintainer
responsibilities.

Yesterday and today I've gone over my pending patches
queue, reviewed then all and I've merged all the ones
which looked good into u-boot-sunxi/next, so that
should be a good starting point for the next
maintainer.

Jagan (in the Cc) has indicated in the past that he is
interested in taking over as sunxi custodian, Jagan already
is the SPI custodian, so I believe that he will do well.

So Jagan, if you still want the job, go for it.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] scripts: sunxi: Build an raw SPL image

[Hans de Goede]

Hi,

On 14-11-16 12:19, Hans de Goede wrote:

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

Introduce a new sunxi-spl-with-ecc.bin image with already the right header,
ECC, randomizer and padding for the BROM to be able to read it.

It needs to be flashed using a raw access to the NAND so that the
controller doesn't change a thing to it, since we already have all the
right parameters.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>


Scrap that, this causes all sunxi boars to fail to build:

+--page is missing
+sunxi-nand-image-builder 2016.11-rc3-00069-gabe4d57
+Usage: sunxi-nand-image-builder [OPTIONS] source-image output-image
+Creates a raw NAND image that can be read by the sunxi NAND controller.
+-h   --help   Display this help and exit
+-c /  --ecc=/   ECC config (strength/step-size)
+-p --page=Page size
+-o --oob= OOB size
+-u --usable=  Usable page size
+-e --eraseblock=  Erase block size
+-b   --boot0  Build a boot0 image.
+-s   --scramble   Scramble data
+  Valid ECC strengths: 16, 24, 28, 32, 40, 48, 56, 60 and 64
+  Valid ECC step size: 512 and 1024
+If you are building a boot0 image, you'll have specify extra options.
+These options should be chosen based on the layouts described here:
+  http://linux-sunxi.org/NAND#More_information_on_BROM_NAND
+  --usable should be assigned the 'Hardware page' value
+  --ecc should be assigned the 'ECC capacity'/'ECC page' values
+  --usable should be smaller than --page
+The --address option is only required for non-boot0 images that are
+meant to be programmed at a non eraseblock aligned offset.
+Examples:
+  The H27UCG8T2BTR-BC NAND exposes
+  * 16k pages
+  * 1280 OOB bytes per page
+  * 4M eraseblocks
+  * requires data scrambling
+  * expects a minimum ECC of 40bits/1024bytes
+  A normal image can be generated with
+sunxi-nand-image-builder -p 16384 -o 1280 -e 0x40 -s -c 40/1024
+  A boot0 image can be generated with
+sunxi-nand-image-builder -p 16384 -o 1280 -e 0x40 -s -b -u 4096 -c 
64/1024
+make[2]: *** [spl/sunxi-spl-with-ecc.bin] Error 255
+make[1]: *** [spl/u-boot-spl] Error 2

I've dropped this patch.


Regards,

Hans




Regards,

Hans




---
 Makefile |  3 +++
 scripts/Makefile.spl | 12 
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 37cbcb28f75e..12a248e297b5 100644
--- a/Makefile
+++ b/Makefile
@@ -1345,6 +1345,9 @@ spl/u-boot-spl: tools prepare \
 spl/sunxi-spl.bin: spl/u-boot-spl
 @:

+spl/sunxi-spl-with-ecc.bin: spl/sunxi-spl.bin
+@:
+
 spl/u-boot-spl.sfp: spl/u-boot-spl
 @:

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index e0b0117dc9b6..b41b4e427cc5 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -168,6 +168,7 @@ endif

 ifdef CONFIG_ARCH_SUNXI
 ALL-y+= $(obj)/sunxi-spl.bin
+ALL-y+= $(obj)/sunxi-spl-with-ecc.bin
 endif

 ifeq ($(CONFIG_SYS_SOC),"at91")
@@ -276,6 +277,17 @@ cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
 $(call if_changed,mksunxiboot)

+quiet_cmd_sunxi_spl_image_builder = SUNXI_SPL_IMAGE_BUILDER $@
+cmd_sunxi_spl_image_builder = $(objtree)/tools/sunxi-spl-image-builder \
+-c 
$(CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH)/$(CONFIG_NAND_SUNXI_SPL_ECC_SIZE) \
+-p $(CONFIG_SYS_NAND_PAGE_SIZE) \
+-o $(CONFIG_SYS_NAND_OOBSIZE) \
+-u $(CONFIG_NAND_SUNXI_SPL_USABLE_PAGE_SIZE) \
+-e $(CONFIG_SYS_NAND_BLOCK_SIZE) \
+-s -b $< $@
+$(obj)/sunxi-spl-with-ecc.bin: $(obj)/sunxi-spl.bin
+$(call if_changed,sunxi_spl_image_builder)
+
 # Rule to link u-boot-spl
 # May be overridden by arch/$(ARCH)/config.mk
 quiet_cmd_u-boot-spl ?= LD  $@


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Hans de Goede]

Hi,

On 14-11-16 12:18, Hans de Goede wrote:

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

This program generates raw SPL images that can be flashed on the NAND with
the ECC and randomizer properly set up.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>


Note this causes a cpu_to_be32 redefine compiler warning
I've fixed this up locally.

Regards,

Hans




Regards,

Hans




---
 tools/.gitignore|1 +-
 tools/Makefile  |1 +-
 tools/sunxi-spl-image-builder.c | 1113 -
 3 files changed, 1115 insertions(+), 0 deletions(-)
 create mode 100644 tools/sunxi-spl-image-builder.c

diff --git a/tools/.gitignore b/tools/.gitignore
index cb1e722d4575..16574467544c 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -15,6 +15,7 @@
 /mkexynosspl
 /mxsboot
 /mksunxiboot
+/sunxi-spl-image-builder
 /ncb
 /proftool
 /relocate-rela
diff --git a/tools/Makefile b/tools/Makefile
index 400588cf0f5c..dfeeb23484ce 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -171,6 +171,7 @@ hostprogs-$(CONFIG_MX28) += mxsboot
 HOSTCFLAGS_mxsboot.o := -pedantic

 hostprogs-$(CONFIG_ARCH_SUNXI) += mksunxiboot
+hostprogs-$(CONFIG_ARCH_SUNXI) += sunxi-spl-image-builder

 hostprogs-$(CONFIG_NETCONSOLE) += ncb
 hostprogs-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1
diff --git a/tools/sunxi-spl-image-builder.c b/tools/sunxi-spl-image-builder.c
new file mode 100644
index ..0f915eb2bdf5
--- /dev/null
+++ b/tools/sunxi-spl-image-builder.c
@@ -0,0 +1,1113 @@
+/*
+ * Generic binary BCH encoding/decoding library
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * For the BCH implementation:
+ *
+ * Copyright © 2011 Parrot S.A.
+ *
+ * Author: Ivan Djelic <ivan.dje...@parrot.com>
+ *
+ * See also:
+ * http://lxr.free-electrons.com/source/lib/bch.c
+ *
+ * For the randomizer and image builder implementation:
+ *
+ * Copyright © 2016 NextThing Co.
+ * Copyright © 2016 Free Electrons
+ *
+ * Author: Boris Brezillon <boris.brezil...@free-electrons.com>
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_BCH_CONST_PARAMS)
+#define GF_M(_p)   (CONFIG_BCH_CONST_M)
+#define GF_T(_p)   (CONFIG_BCH_CONST_T)
+#define GF_N(_p)   ((1 << (CONFIG_BCH_CONST_M))-1)
+#else
+#define GF_M(_p)   ((_p)->m)
+#define GF_T(_p)   ((_p)->t)
+#define GF_N(_p)   ((_p)->n)
+#endif
+
+#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+
+#define BCH_ECC_WORDS(_p)  DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 32)
+#define BCH_ECC_BYTES(_p)  DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 8)
+
+#ifndef dbg
+#define dbg(_fmt, args...) do {} while (0)
+#endif
+
+#define cpu_to_be32 htobe32
+#define kfree free
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+#define BCH_PRIMITIVE_POLY0x5803
+
+struct image_info {
+int ecc_strength;
+int ecc_step_size;
+int page_size;
+int oob_size;
+int usable_page_size;
+int eraseblock_size;
+int scramble;
+int boot0;
+off_t offset;
+const char *source;
+const char *dest;
+};
+
+/**
+ * struct bch_control - BCH control structure
+ * @m:  Galois field order
+ * @n:  maximum codeword size in bits (= 2^m-1)
+ * @t:  error correction capability in bits
+ * @ecc_bits:   ecc exact size in bits, i.e. generator polynomial degree 
(<=m*t)
+ * @ecc_bytes:  ecc max size (m*t bits) in bytes
+ * @a_pow_tab:  Galois field GF(2^m) exponentiation lookup table
+ * @a_log_tab:  Galois field GF(2^m) log lookup table
+ * @mod8_tab:   remainder generator polynomial lookup tables
+ * @ecc_buf:ecc parity words buffer
+ * @ecc_buf2:   ecc parity words buffer
+ * @xi_tab: GF(2^m) base for solving degree 2 polynomial roots
+ * @syn:syndrome buffer
+ * @cache:  log-based polynomial representation buffer
+ * @elp:error locator polynomial
+ * @poly_2t:temporary polynomials of degree 2t
+ */
+struct bch_control {
+unsigned intm;
+unsigned intn;
+unsigned intt;
+unsigned intecc_bits;
+unsigned intecc_bytes;
+/* private: */
+uint16_t   *a_pow_tab;
+uint16_t  

Re: [U-Boot] [PATCH] Do not force master mode on unaffected PHY's

[Hans de Goede]

Hi,

On 08-11-16 17:38, Olliver Schinagl wrote:

The current implementation to force the PHY into master mode is to have a
define which affects all realtek PHY's. This is not needed as the problem
only exists in the RTL8211C chips. Let us thus turn this into a quirk flag
instead.


Series looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 7/7] sunxi: Add support for the CHIP Pro

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

The CHIP Pro is a SoM that features the GR8 SIP, an AXP209, a BT/WiFi chip
and a 512MiB SLC NAND.

This it's an SLC NAND, it doesn't suffer the same drawbacks than found on
the MLC NANDs, and we can enable it right away.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Patch 3/3 needs a v3 before this can be merged, otherwise this
looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans


---
 configs/CHIP_pro_defconfig | 27 +++
 1 file changed, 27 insertions(+), 0 deletions(-)
 create mode 100644 configs/CHIP_pro_defconfig

diff --git a/configs/CHIP_pro_defconfig b/configs/CHIP_pro_defconfig
new file mode 100644
index ..6008f44f485c
--- /dev/null
+++ b/configs/CHIP_pro_defconfig
@@ -0,0 +1,27 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_SPL_I2C_SUPPORT=y
+# CONFIG_SPL_MMC_SUPPORT is not set
+CONFIG_MACH_SUN5I=y
+CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y
+# CONFIG_MMC is not set
+CONFIG_USB0_VBUS_PIN="PB10"
+CONFIG_DEFAULT_DEVICE_TREE="ntc-gr8-chip-pro"
+CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,SYS_NAND_BLOCK_SIZE=0x4,SYS_NAND_PAGE_SIZE=4096,SYS_NAND_OOBSIZE=256,ENV_IS_IN_NAND"
+CONFIG_SPL=y
+# CONFIG_CMD_IMLS is not set
+CONFIG_CMD_DFU=y
+CONFIG_CMD_USB_MASS_STORAGE=y
+CONFIG_DFU_RAM=y
+CONFIG_AXP_ALDO3_VOLT=3300
+CONFIG_AXP_ALDO4_VOLT=3300
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Allwinner Technology"
+CONFIG_G_DNL_VENDOR_NUM=0x1f3a
+CONFIG_G_DNL_PRODUCT_NUM=0x1010
+CONFIG_NAND_SUNXI=y
+CONFIG_SPL_NAND_SUPPORT=y
+CONFIG_MTD_UBI=y


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] nand: sunxi: Add options for the SPL NAND configuration

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

The SPL image needs to be built with a different ECC configuration than the
U-Boot binary.

Add Kconfig options with defaults to provide a value that should work for
anyone, but is still configurable if needs be.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans




---
 drivers/mtd/nand/Kconfig | 16 
 1 file changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index df154bfd32b9..a60abb625ee5 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -73,6 +73,22 @@ config NAND_SUNXI
The SPL driver only supports reading from the NAND using DMA
transfers.

+if NAND_SUNXI
+
+config NAND_SUNXI_SPL_ECC_STRENGTH
+   int "Allwinner NAND SPL ECC Strength"
+   default 64
+
+config NAND_SUNXI_SPL_ECC_SIZE
+   int "Allwinner NAND SPL ECC Step Size"
+   default 1024
+
+config NAND_SUNXI_SPL_USABLE_PAGE_SIZE
+   int "Allwinner NAND SPL Usable Page Size"
+   default 1024
+
+endif
+
 config NAND_ARASAN
bool "Configure Arasan Nand"
help


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/7] scripts: sunxi: Build an raw SPL image

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

Introduce a new sunxi-spl-with-ecc.bin image with already the right header,
ECC, randomizer and padding for the BROM to be able to read it.

It needs to be flashed using a raw access to the NAND so that the
controller doesn't change a thing to it, since we already have all the
right parameters.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans




---
 Makefile |  3 +++
 scripts/Makefile.spl | 12 
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/Makefile b/Makefile
index 37cbcb28f75e..12a248e297b5 100644
--- a/Makefile
+++ b/Makefile
@@ -1345,6 +1345,9 @@ spl/u-boot-spl: tools prepare \
 spl/sunxi-spl.bin: spl/u-boot-spl
@:

+spl/sunxi-spl-with-ecc.bin: spl/sunxi-spl.bin
+   @:
+
 spl/u-boot-spl.sfp: spl/u-boot-spl
@:

diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index e0b0117dc9b6..b41b4e427cc5 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -168,6 +168,7 @@ endif

 ifdef CONFIG_ARCH_SUNXI
 ALL-y  += $(obj)/sunxi-spl.bin
+ALL-y  += $(obj)/sunxi-spl-with-ecc.bin
 endif

 ifeq ($(CONFIG_SYS_SOC),"at91")
@@ -276,6 +277,17 @@ cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
 $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mksunxiboot)

+quiet_cmd_sunxi_spl_image_builder = SUNXI_SPL_IMAGE_BUILDER $@
+cmd_sunxi_spl_image_builder = $(objtree)/tools/sunxi-spl-image-builder \
+   -c 
$(CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH)/$(CONFIG_NAND_SUNXI_SPL_ECC_SIZE) \
+   -p $(CONFIG_SYS_NAND_PAGE_SIZE) \
+   -o $(CONFIG_SYS_NAND_OOBSIZE) \
+   -u $(CONFIG_NAND_SUNXI_SPL_USABLE_PAGE_SIZE) \
+   -e $(CONFIG_SYS_NAND_BLOCK_SIZE) \
+   -s -b $< $@
+$(obj)/sunxi-spl-with-ecc.bin: $(obj)/sunxi-spl.bin
+   $(call if_changed,sunxi_spl_image_builder)
+
 # Rule to link u-boot-spl
 # May be overridden by arch/$(ARCH)/config.mk
 quiet_cmd_u-boot-spl ?= LD  $@


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/7] tools: sunxi: Add spl image builder

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

This program generates raw SPL images that can be flashed on the NAND with
the ECC and randomizer properly set up.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans




---
 tools/.gitignore|1 +-
 tools/Makefile  |1 +-
 tools/sunxi-spl-image-builder.c | 1113 -
 3 files changed, 1115 insertions(+), 0 deletions(-)
 create mode 100644 tools/sunxi-spl-image-builder.c

diff --git a/tools/.gitignore b/tools/.gitignore
index cb1e722d4575..16574467544c 100644
--- a/tools/.gitignore
+++ b/tools/.gitignore
@@ -15,6 +15,7 @@
 /mkexynosspl
 /mxsboot
 /mksunxiboot
+/sunxi-spl-image-builder
 /ncb
 /proftool
 /relocate-rela
diff --git a/tools/Makefile b/tools/Makefile
index 400588cf0f5c..dfeeb23484ce 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -171,6 +171,7 @@ hostprogs-$(CONFIG_MX28) += mxsboot
 HOSTCFLAGS_mxsboot.o := -pedantic

 hostprogs-$(CONFIG_ARCH_SUNXI) += mksunxiboot
+hostprogs-$(CONFIG_ARCH_SUNXI) += sunxi-spl-image-builder

 hostprogs-$(CONFIG_NETCONSOLE) += ncb
 hostprogs-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1
diff --git a/tools/sunxi-spl-image-builder.c b/tools/sunxi-spl-image-builder.c
new file mode 100644
index ..0f915eb2bdf5
--- /dev/null
+++ b/tools/sunxi-spl-image-builder.c
@@ -0,0 +1,1113 @@
+/*
+ * Generic binary BCH encoding/decoding library
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 51
+ * Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * For the BCH implementation:
+ *
+ * Copyright © 2011 Parrot S.A.
+ *
+ * Author: Ivan Djelic <ivan.dje...@parrot.com>
+ *
+ * See also:
+ * http://lxr.free-electrons.com/source/lib/bch.c
+ *
+ * For the randomizer and image builder implementation:
+ *
+ * Copyright © 2016 NextThing Co.
+ * Copyright © 2016 Free Electrons
+ *
+ * Author: Boris Brezillon <boris.brezil...@free-electrons.com>
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#if defined(CONFIG_BCH_CONST_PARAMS)
+#define GF_M(_p)   (CONFIG_BCH_CONST_M)
+#define GF_T(_p)   (CONFIG_BCH_CONST_T)
+#define GF_N(_p)   ((1 << (CONFIG_BCH_CONST_M))-1)
+#else
+#define GF_M(_p)   ((_p)->m)
+#define GF_T(_p)   ((_p)->t)
+#define GF_N(_p)   ((_p)->n)
+#endif
+
+#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+
+#define BCH_ECC_WORDS(_p)  DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 32)
+#define BCH_ECC_BYTES(_p)  DIV_ROUND_UP(GF_M(_p)*GF_T(_p), 8)
+
+#ifndef dbg
+#define dbg(_fmt, args...) do {} while (0)
+#endif
+
+#define cpu_to_be32 htobe32
+#define kfree free
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+#define BCH_PRIMITIVE_POLY 0x5803
+
+struct image_info {
+   int ecc_strength;
+   int ecc_step_size;
+   int page_size;
+   int oob_size;
+   int usable_page_size;
+   int eraseblock_size;
+   int scramble;
+   int boot0;
+   off_t offset;
+   const char *source;
+   const char *dest;
+};
+
+/**
+ * struct bch_control - BCH control structure
+ * @m:  Galois field order
+ * @n:  maximum codeword size in bits (= 2^m-1)
+ * @t:  error correction capability in bits
+ * @ecc_bits:   ecc exact size in bits, i.e. generator polynomial degree 
(<=m*t)
+ * @ecc_bytes:  ecc max size (m*t bits) in bytes
+ * @a_pow_tab:  Galois field GF(2^m) exponentiation lookup table
+ * @a_log_tab:  Galois field GF(2^m) log lookup table
+ * @mod8_tab:   remainder generator polynomial lookup tables
+ * @ecc_buf:ecc parity words buffer
+ * @ecc_buf2:   ecc parity words buffer
+ * @xi_tab: GF(2^m) base for solving degree 2 polynomial roots
+ * @syn:syndrome buffer
+ * @cache:  log-based polynomial representation buffer
+ * @elp:error locator polynomial
+ * @poly_2t:temporary polynomials of degree 2t
+ */
+struct bch_control {
+   unsigned intm;
+   unsigned intn;
+   unsigned intt;
+   unsigned intecc_bits;
+   unsigned intecc_bytes;
+/* private: */
+   uint16_t   *a_pow_tab;
+   uint16_t   *a_log_tab;
+   uint32_t   *mod8_tab;
+   uint32_t   *ecc_buf;
+   uint

Re: [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

From: Hans de Goede <hdego...@redhat.com>

Enable the NAND and UBI support in the configuration header so that we can
(finally) use it.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>
---
 include/configs/sunxi-common.h | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 8363414828fa..1733767ba53b 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -129,9 +129,23 @@
 #define CONFIG_SERIAL_TAG

 #ifdef CONFIG_NAND_SUNXI
+#define CONFIG_SYS_NAND_U_BOOT_OFFS(8 << 20) /* 8 MiB */


As Boris already said, please put this in Kconfig.


 #define CONFIG_SYS_NAND_MAX_ECCPOS 1664
 #define CONFIG_SYS_NAND_ONFI_DETECTION
 #define CONFIG_SYS_MAX_NAND_DEVICE 8
+
+/* Requirements for UBI */
+#define CONFIG_RBTREE
+#define CONFIG_LZO
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_CMD_UBI
+#define CONFIG_CMD_UBIFS
+#define CONFIG_MTD_DEVICE
+
+#define CONFIG_MTD_PARTITIONS
+
+#define CONFIG_CMD_NAND
+#define CONFIG_CMD_NAND_TRIMFFS
 #endif

 #ifdef CONFIG_SPL_SPI_SUNXI
@@ -143,7 +157,14 @@
 #define CONFIG_GENERIC_MMC
 #define CONFIG_MMC_SUNXI
 #define CONFIG_MMC_SUNXI_SLOT  0
-#define CONFIG_ENV_IS_IN_MMC
+#endif
+
+#if defined(CONFIG_ENV_IS_IN_NAND)
+#define CONFIG_ENV_OFFSET  0xc0
+#define CONFIG_ENV_SIZE0x40
+#elif defined(CONFIG_ENV_IS_IN_MMC)
+#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) 
KiB */
+#define CONFIG_ENV_SIZE(128 << 10) /* 128 KiB 
*/
 #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
controller */
 #endif



I would greatly prefer putting the env in an UBI partition,
I thought that we had agreed on doing that ?

Regards,

Hans




@@ -175,9 +196,6 @@

 #define CONFIG_SYS_MONITOR_LEN (768 << 10)   /* 768 KiB */

-#define CONFIG_ENV_OFFSET  (544 << 10) /* (8 + 24 + 512) KiB */
-#define CONFIG_ENV_SIZE(128 << 10)   /* 128 KiB */
-
 #define CONFIG_FAT_WRITE   /* enable write access */

 #define CONFIG_SPL_FRAMEWORK


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/7] mtd: nand: add support for the TC58NVG2S0H chip

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

From: Boris Brezillon <boris.brezil...@free-electrons.com>

Add the description of the Toshiba TC58NVG2S0H SLC nand to the nand_ids
table so we can use the NAND ECC infos and the ONFI timings.

Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans




---
 drivers/mtd/nand/nand_ids.c | 3 +++
 1 file changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/nand_ids.c b/drivers/mtd/nand/nand_ids.c
index ce0a14e28abb..d36f9006c99d 100644
--- a/drivers/mtd/nand/nand_ids.c
+++ b/drivers/mtd/nand/nand_ids.c
@@ -46,6 +46,9 @@ struct nand_flash_dev nand_flash_ids[] = {
{"TC58NVG2S0F 4G 3.3V 8-bit",
{ .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x15, 0x01, 0x08} },
  SZ_4K, SZ_512, SZ_256K, 0, 8, 224, NAND_ECC_INFO(4, SZ_512) },
+   {"TC58NVG2S0H 4G 3.3V 8-bit",
+   { .id = {0x98, 0xdc, 0x90, 0x26, 0x76, 0x16, 0x08, 0x00} },
+ SZ_4K, SZ_512, SZ_256K, 0, 8, 256, NAND_ECC_INFO(8, SZ_512) },
{"TC58NVG3S0F 8G 3.3V 8-bit",
{ .id = {0x98, 0xd3, 0x90, 0x26, 0x76, 0x15, 0x02, 0x08} },
  SZ_4K, SZ_1K, SZ_256K, 0, 8, 232, NAND_ECC_INFO(4, SZ_512) },


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/7] sunxi: Sync GR8 DTS and AXP209 with the kernel

[Hans de Goede]

Hi,

On 08-11-16 17:21, Maxime Ripard wrote:

Those DT will be part of 4.10, sync them so we can have our own config.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


Looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 arch/arm/dts/Makefile |1 +-
 arch/arm/dts/axp209.dtsi  |6 +-
 arch/arm/dts/ntc-gr8-chip-pro.dts |  266 +++-
 arch/arm/dts/ntc-gr8.dtsi | 1132 ++-
 4 files changed, 1405 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/dts/ntc-gr8-chip-pro.dts
 create mode 100644 arch/arm/dts/ntc-gr8.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 836a8c4d1ee2..932dbe07cf14 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -180,6 +180,7 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-pcduino2.dtb \
sun4i-a10-pov-protab2-ips9.dtb
 dtb-$(CONFIG_MACH_SUN5I) += \
+   ntc-gr8-chip-pro.dtb \
sun5i-a10s-auxtek-t003.dtb \
sun5i-a10s-auxtek-t004.dtb \
sun5i-a10s-mk802.dtb \
diff --git a/arch/arm/dts/axp209.dtsi b/arch/arm/dts/axp209.dtsi
index afbe89c01df5..675bb0f30825 100644
--- a/arch/arm/dts/axp209.dtsi
+++ b/arch/arm/dts/axp209.dtsi
@@ -53,6 +53,12 @@
interrupt-controller;
#interrupt-cells = <1>;

+   axp_gpio: gpio {
+   compatible = "x-powers,axp209-gpio";
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
regulators {
/* Default work frequency for buck regulators */
x-powers,dcdc-freq = <1500>;
diff --git a/arch/arm/dts/ntc-gr8-chip-pro.dts 
b/arch/arm/dts/ntc-gr8-chip-pro.dts
new file mode 100644
index ..c4be912df481
--- /dev/null
+++ b/arch/arm/dts/ntc-gr8-chip-pro.dts
@@ -0,0 +1,266 @@
+/*
+ * Copyright 2016 Free Electrons
+ * Copyright 2016 NextThing Co
+ *
+ * Maxime Ripard <maxime.rip...@free-electrons.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "ntc-gr8.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "NextThing C.H.I.P. Pro";
+   compatible = "nextthing,chip-pro", "nextthing,gr8";
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   status {
+   label = "chip-pro:white:status";
+   gpios = <_gpio 2 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
+   mmc0_pwrseq: mmc0_pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+ 

Re: [U-Boot] [PATCH RESEND 0/9] sunxi: chip: Enable the DIP auto-detection

[Hans de Goede]

Hi,

On 08-11-16 11:19, Maxime Ripard wrote:

The NextThing's C.H.I.P. can have expansion boards called DIPs. Those DIPs
are connected through the external headers, and comes with an
identification mechanism based on 1-Wire EEPROMs.

That auto-detection works great, because 1-Wire allows the enumeration, and
the EEPROMs are guaranteed to have different addresses, which allows us to
stack as many DIPs as possible, without any constraints.

Since those DIPs can be close to anything, ranging from a simple PWM-based
buzzer to a full featured device such as the PocketCHIP (which comes with a
touchscreen, a keyboard, a battery, etc), some adjustments might be needed
in U-Boot to be able to present something that just works to the user.

In particular, we need to:
  - Apply an overlay if the device is something that should be dealt with
early in the boot process (display, storage device)
  - Adjust the U-Boot environment if the DIP has a display to change the
default video output
  - Adjust the kernel command line in previous case for Linux to have the
same default

In order to achieve that, we introduced some logic optionally hooked into
the sunxi board, two new uclasses for 1-Wire and EEPROMs, and a bunch of
new environment variables:
  - dip-auto-video to control the automatic video set up (default to yes)
  - dip_overlay_cmd that is a script to load the overlay $dip_overlay_name
to $dip_addr_r, from whatever place it was stored in, and later apply
it.
  - kernelarg_video to host the default kernel output in the kernel
command line

I think the biggest drawback at the moment is that we maintain a list of
DIPs and the actions needed directly into the C code, which will make it
quite hard to customise for end users and tedious to maintain in the long
term. I couldn't really get my head around a better solution, so feel free
to suggest alternative approaches.

Let me know what you think,


The sunxi specific bits look fine to me. I will leave reviewing of the
uclass bits to Simon.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] mmc: Retry the switch command

[Hans de Goede]

Hi,

On 14-11-16 01:34, Jaehoon Chung wrote:

On 11/14/2016 07:50 AM, Tom Rini wrote:

On Sun, Nov 13, 2016 at 07:50:53PM +0100, Hans de Goede wrote:

Hi,

On 04-11-16 16:18, Maxime Ripard wrote:

Some eMMC will fail at the first switch, but would succeed in a subsequent
one.

Make sure we try several times to cover those cases. The number of retries
(and the behaviour) is currently what is being used in Linux.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>


Reviewed-by: Tom Rini <tr...@konsulko.com>


Pantelis or Tom, can you pick this up please ?


Want to just pick it up with the rest of the series in the sunxi tree?


Sorry for late..If you are ok, i will pick these on today.


Go ahead and pick these up please.


If you already picked this..let me know, plz.


Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tools: fix mksunxiboot build for tools-all target

[Hans de Goede]

Hi,

On 10-11-16 13:13, Andre Przywara wrote:

Commit fed329aebe3a ("tools: add mksunxiboot to tools-all target") added
mksunxiboot to the tools-all target, but used the CONFIG_SUNXI symbol
to enable its build. Now commit aec9a0f19f64 ("sunxi: Rename CONFIG_SUNXI
to CONFIG_ARCH_SUNXI"), merged before that, renamed that symbol, so that
the first patch basically gets ineffective.
Adjust the symbol name in tools/Makefile to make it build again.

Signed-off-by: Andre Przywara <andre.przyw...@arm.com>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 tools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index 400588c..9edb504 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -13,7 +13,7 @@ CONFIG_CMD_NET = y
 CONFIG_XWAY_SWAP_BYTES = y
 CONFIG_NETCONSOLE = y
 CONFIG_SHA1_CHECK_UB_IMG = y
-CONFIG_SUNXI = y
+CONFIG_ARCH_SUNXI = y
 endif

 subdir-$(HOST_TOOLS_ALL) += easylogo


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/10] sunxi: Add basic PSCI implementation for A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

The A80 is a big.LITTLE multi-cluster SoC, with a different layout for
the PRCM and CPUCFG registers. As such it needs a different PSCI
implementation.

This patch adds a basic version that allows bringing up the four cores
in the first cluster. The structure is based on existing sunxi PSCI code.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 arch/arm/cpu/armv7/sunxi/Makefile|   4 +
 arch/arm/cpu/armv7/sunxi/psci-mcpm.c | 234 +++
 2 files changed, 238 insertions(+)
 create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index 239c659ec032..b18e5f1fa974 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -14,8 +14,12 @@ obj-$(CONFIG_MACH_SUN8I_H3)  += tzpc.o
 obj-$(CONFIG_MACH_SUN9I)   += tzpc.o

 ifndef CONFIG_SPL_BUILD
+ifdef CONFIG_MACH_SUN9I
+obj-$(CONFIG_ARMV7_PSCI)   += psci-mcpm.o
+else
 obj-$(CONFIG_ARMV7_PSCI)   += psci.o
 endif
+endif

 ifdef CONFIG_SPL_BUILD
 obj-y  += fel_utils.o
diff --git a/arch/arm/cpu/armv7/sunxi/psci-mcpm.c 
b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
new file mode 100644
index ..3ede07cace2c
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/psci-mcpm.c
@@ -0,0 +1,234 @@
+/*
+ * Copyright (C) 2016
+ * Author: Chen-Yu Tsai <w...@csie.org>
+ *
+ * Based on assembly code by Marc Zyngier <marc.zyng...@arm.com>,
+ * which was based on code by Carl van Schaik <c...@ok-labs.com>.
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/*
+ * NOTE dense CPU IDs (0~3 for first cluster of 4 cores, 4~7 for the
+ * second cluster) are used throughout the PSCI code. Any MPIDR style
+ * values must be converted.
+ */
+
+/*
+ * Provide a dense CPU ID for 2-cluster systems. This must be coded in
+ * assembly as it gets called from psci_stack_setup, when the stack isn't
+ * available yet.
+ *
+ * Only r0 and r3 is usable. r8 - r12 are available if this function is
+ * only called from psci_stack_setup, which we cannot guarantee.
+ */
+u32 __secure __naked psci_get_cpu_id(void)
+{
+   asm volatile (
+   "mrc   p15, 0, r3, c0, c0, 5   @ Get MPIDR\n"
+   "lsr   r0, r3, #6\n"
+   "and   r3, r3, #3\n"
+   "and   r0, r0, #4\n"
+   "orr   r0, r0, r3\n"
+   "bxlr\n"
+   );
+
+   /*
+* The last five lines are the compiler generated assembly code for
+*
+*  return (reg & 0x3) | (((reg >> 8) & 0x1) << 2);
+*
+* We can't guarantee that all compilers correctly use only r0 and
+* r3, so we use inline assembly here.
+*/
+}
+
+static void __secure cp15_write_cntp_tval(u32 tval)
+{
+   asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
+}
+
+static void __secure cp15_write_cntp_ctl(u32 val)
+{
+   asm volatile ("mcr p15, 0, %0, c14, c2, 1" : : "r" (val));
+}
+
+static u32 __secure cp15_read_cntp_ctl(void)
+{
+   u32 val;
+
+   asm volatile ("mrc p15, 0, %0, c14, c2, 1" : "=r" (val));
+
+   return val;
+}
+
+#define ONE_US (CONFIG_TIMER_CLK_FREQ / 100)
+
+/* Use a different name to avoid clashing with the non-secure function */
+static void __secure __udelay_sec(unsigned long us)
+{
+   u32 reg = ONE_US * us;
+
+   cp15_write_cntp_tval(reg);
+   isb();
+   cp15_write_cntp_ctl(3);
+
+   do {
+   isb();
+   reg = cp15_read_cntp_ctl();
+   } while (!(reg & BIT(2)));
+
+   cp15_write_cntp_ctl(0);
+   isb();
+}
+
+static void __secure clamp_release(u32 *clamp)
+{
+   writel(0xff, clamp);
+   __udelay_sec(10);
+   writel(0xfe, clamp);
+   __udelay_sec(10);
+   writel(0xf8, clamp);
+   __udelay_sec(10);
+   writel(0xf0, clamp);
+   __udelay_sec(10);
+   writel(0x00, clamp);
+}
+
+static void __secure clamp_set(u32 *clamp)
+{
+   writel(0xff, clamp);
+}
+
+static void __secure sunxi_core_power_switch(u32 *clamp, u32 *pwroff,
+bool on, int cpu)
+{
+   if (on) {
+   /* Release power clamp */
+   clamp_release(clamp);
+
+   __udelay_sec(20);
+
+   /* Clear power gating */
+   clrbits_le32(pwroff, BIT(cpu));
+   } else {
+   /* Set power gating */
+   setbits_le32(pwroff, BIT(cpu));
+
+   __udelay_sec(20);
+
+   /* Activate power clamp */
+   clamp_set(clamp);
+   }
+}
+
+sta

Re: [U-Boot] [PATCH 09/10] sunxi: Enable PSCI on sun9i/A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

Now that we have a basic version of PSCI firmware, enable non-secure
boot and PSCI on the A80.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 board/sunxi/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e1d4ab148f08..ae2fba1368cc 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -118,8 +118,12 @@ config MACH_SUN8I_H3
 config MACH_SUN9I
bool "sun9i (Allwinner A80)"
select CPU_V7
+   select CPU_V7_HAS_NONSEC
+   select CPU_V7_HAS_VIRT
+   select ARCH_SUPPORT_PSCI
select SUNXI_GEN_SUN6I
select SUPPORT_SPL
+   select ARMV7_BOOT_SEC_DEFAULT if OLD_SUNXI_KERNEL_COMPAT

 config MACH_SUN50I
bool "sun50i (Allwinner A64)"


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 07/10] sunxi: Add support for TZPC on sun9i/A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

The A80 also has the TrustZone Protection Controller (TZPC), called
the Secure Memory Touch Arbiter (SMTA).

Enable non-secure access to all the peripherals at boot time.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans




---
 arch/arm/cpu/armv7/sunxi/Makefile   | 1 +
 arch/arm/cpu/armv7/sunxi/tzpc.c | 6 ++
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 1 +
 arch/arm/include/asm/arch-sunxi/tzpc.h  | 4 
 arch/arm/mach-sunxi/board.c | 3 ++-
 5 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile 
b/arch/arm/cpu/armv7/sunxi/Makefile
index b35b9df4a9d6..239c659ec032 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-y += timer.o

 obj-$(CONFIG_MACH_SUN6I)   += tzpc.o
 obj-$(CONFIG_MACH_SUN8I_H3)+= tzpc.o
+obj-$(CONFIG_MACH_SUN9I)   += tzpc.o

 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_ARMV7_PSCI)   += psci.o
diff --git a/arch/arm/cpu/armv7/sunxi/tzpc.c b/arch/arm/cpu/armv7/sunxi/tzpc.c
index 6c8a0fd9a25b..2a2cf363b99c 100644
--- a/arch/arm/cpu/armv7/sunxi/tzpc.c
+++ b/arch/arm/cpu/armv7/sunxi/tzpc.c
@@ -24,4 +24,10 @@ void tzpc_init(void)
writel(SUN8I_H3_TZPC_DECPORT1_ALL, >decport1_set);
writel(SUN8I_H3_TZPC_DECPORT2_ALL, >decport2_set);
 #endif
+
+#ifdef CONFIG_MACH_SUN9I
+   writel(SUN9I_TZPC_DECPORT0_ALL, >decport0_set);
+   writel(SUN9I_TZPC_DECPORT1_ALL, >decport1_set);
+   writel(SUN9I_TZPC_DECPORT2_ALL, >decport2_set);
+#endif
 }
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
index e9839eecaa92..25114174f395 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
@@ -90,6 +90,7 @@
 #define SUNXI_TIMER_BASE   (REGS_APB0_BASE + 0x0C00)
 #define SUNXI_PWM_BASE (REGS_APB0_BASE + 0x1400)
 #define SUNXI_LRADC_BASE   (REGS_APB0_BASE + 0x1800)
+#define SUNXI_TZPC_BASE(REGS_APB0_BASE + 0x3400)

 /* APB1 Module */
 #define SUNXI_UART0_BASE   (REGS_APB1_BASE + 0x)
diff --git a/arch/arm/include/asm/arch-sunxi/tzpc.h 
b/arch/arm/include/asm/arch-sunxi/tzpc.h
index 95c55cd4d130..3425d00edd97 100644
--- a/arch/arm/include/asm/arch-sunxi/tzpc.h
+++ b/arch/arm/include/asm/arch-sunxi/tzpc.h
@@ -29,6 +29,10 @@ struct sunxi_tzpc {
 #define SUN8I_H3_TZPC_DECPORT1_ALL  0xff
 #define SUN8I_H3_TZPC_DECPORT2_ALL  0x7f

+#define SUN9I_TZPC_DECPORT0_ALL 0xfe
+#define SUN9I_TZPC_DECPORT1_ALL 0x7f
+#define SUN9I_TZPC_DECPORT2_ALL 0x00
+
 void tzpc_init(void);

 #endif /* _SUNXI_TZPC_H */
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 0f8ead980cdc..0053f562e00d 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -190,7 +190,8 @@ void s_init(void)
"orr r0, r0, #1 << 6\n"
"mcr p15, 0, r0, c1, c0, 1\n");
 #endif
-#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
+#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3 || \
+defined CONFIG_MACH_SUN9I
/* Enable non-secure access to some peripherals */
tzpc_init();
 #endif


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 05/10] sunxi: Add PRCM register definition for sun9i/A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

The A80 has a different PRCM register layout.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 arch/arm/include/asm/arch-sunxi/prcm_sun9i.h | 55 
 1 file changed, 55 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun9i.h

diff --git a/arch/arm/include/asm/arch-sunxi/prcm_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/prcm_sun9i.h
new file mode 100644
index ..f4732335fbcc
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/prcm_sun9i.h
@@ -0,0 +1,55 @@
+/*
+ * Sunxi A80 Power Reset and Clock Module register definition
+ *
+ * (C) Copyright 2016 Chen-Yu Tsai <w...@csie.org>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_PRCM_SUN9I_H
+#define _SUNXI_PRCM_SUN9I_H
+
+struct __packed sunxi_prcm_reg {
+   u32 cpus_rst;   /* 0x000 */
+   u32 cpu_rst[2]; /* 0x004 */
+   u8 res0[0x4];   /* 0x00c */
+   u32 cpus_cfg;   /* 0x010 */
+   u8 res1[0x8];   /* 0x014 */
+   u32 apbs_ratio; /* 0x01c */
+   u8 res2[0x8];   /* 0x020 */
+   u32 apbs_gate;  /* 0x028 */
+   u8 res3[0x18];  /* 0x02c */
+   u32 pll_ctrl1;  /* 0x044 */
+   u8 res4[0xc];   /* 0x048 */
+   u32 clk_cir;/* 0x054 */
+   u32 clk_i2s0;   /* 0x058 */
+   u32 clk_i2s1;   /* 0x05c */
+   u8 res5[0x50];  /* 0x060 */
+   u32 apb0_reset; /* 0x0b0 */
+   u8 res6[0x4c];  /* 0x0b4 */
+   u32 cpu_pwroff[2];  /* 0x100 */
+   u8 res7[0x8];   /* 0x108 */
+   u32 vdd_sys_pwroff; /* 0x110 */
+   u8 res8[0x4];   /* 0x114 */
+   u32 gpu_pwroff; /* 0x118 */
+   u8 res9[0x4];   /* 0x11c */
+   u32 vdd_sys_rst;/* 0x120 */
+   u8 res10[0x1c]; /* 0x124 */
+   u32 cpu_pwr_clamp[2][4]; /* 0x140 */
+   u32 super_standby_flag; /* 0x160 */
+   u32 cpu_soft_entry; /* 0x164 */
+   u32 super_standby_entry; /* 0x168 */
+   u8 res11[0x34]; /* 0x16c */
+   u32 nmi_irq_ctrl;   /* 0x1a0 */
+   u32 nmi_irq_en; /* 0x1a4 */
+   u32 nmi_irq_status; /* 0x1a8 */
+   u8 res12[0x14]; /* 0x1ac */
+   u32 pll_audio_ctrl; /* 0x1c0 */
+   u32 pll_audio_bias; /* 0x1c4 */
+   u32 pll_audio_pat_cfg;  /* 0x1c8 */
+   u32 pll_audio_ctrl_sw;  /* 0x1cc */
+   u8 res13[0x20]; /* 0x1d0 */
+   u32 osc24m_ctrl;/* 0x1f0 */
+};
+
+#endif /* _SUNXI_PRCM_SUN9I_H */


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 04/10] sunxi: Use secure SRAM B for secure RAM for sun9i/A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

The A80 has a 256 kiB secure SRAM. However the first 4 kiB are reserved
for CPU0 hotplug flags.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 include/configs/sun9i.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/sun9i.h b/include/configs/sun9i.h
index cd9e08d8b1b9..e751c5e05c14 100644
--- a/include/configs/sun9i.h
+++ b/include/configs/sun9i.h
@@ -13,6 +13,10 @@
  * A80 specific configuration
  */

+/* First 4 kiB is reserved for CPU0 hotplug flags */
+#define CONFIG_ARMV7_SECURE_BASE   (SUNXI_SRAM_B_BASE + 4 * 1024)
+#define CONFIG_ARMV7_SECURE_MAX_SIZE   (252 * 1024) /* 252 KB */
+
 /*
  * Include common sunxi configuration where most the settings are
  */


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 06/10] sunxi: Add CPUCFG register definitions for sun9i/A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

The A80 has a different CPUCFG register layout, likely due to having
2 clusters.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h | 51 ++
 1 file changed, 51 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h

diff --git a/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
new file mode 100644
index ..0ee6a63e441b
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
@@ -0,0 +1,51 @@
+/*
+ * Sunxi A80 CPUCFG register definition.
+ *
+ * (C) Copyright 2016 Chen-Yu Tsai <w...@csie.org>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_CPUCFG_SUN9I_H
+#define _SUNXI_CPUCFG_SUN9I_H
+
+#include 
+#include 
+
+#define CPUCFG_CX_CTRL0_L1_RST_DISABLE(core)   BIT(core)
+
+#define CPUCFG_CX_STATUS_STANDBYWFI(core)  BIT(16 + core)
+
+#define CPUCFG_CX_RST_CORE(core)   BIT(core)
+#define CPUCFG_CX_RST_NEON(core)   BIT(4 + core) /* A15 only */
+#define CPUCFG_CX_RST_L2   BIT(8)
+#define CPUCFG_CX_RST_HRESET   BIT(12)
+#define CPUCFG_CX_RST_DBG(core)BIT(16 + core)
+#define CPUCFG_CX_RST_ETM(core)BIT(20 + core)
+#define CPUCFG_CX_RST_SOC_DBG  BIT(24)
+
+#ifndef __ASSEMBLY__
+
+struct __packed sunxi_cpucfg_cluster {
+   u32 ctrl0;  /* base + 0x0 */
+   u32 ctrl1;  /* base + 0x4 */
+   u32 adb400_pwrdnreqn;   /* base + 0x8 */
+   u8 res[0x4];/* base + 0xc */
+};
+
+struct __packed sunxi_cpucfg_reg {
+   struct sunxi_cpucfg_cluster cluster[2]; /* 0x00 */
+   u8 res0[0x8];   /* 0x20 */
+   u32 gen_ctrl0;  /* 0x28 */
+   u32 gen_ctrl1;  /* 0x2c */
+   u32 cluster_status[2];  /* 0x30 */
+   u8 res1[0x4];   /* 0x38 */
+   u32 irq_fiq_status; /* 0x3c */
+   u32 irq_fiq_mask;   /* 0x40 */
+   u8 res2[0x3c];  /* 0x44 */
+   u32 cluster_reset[2];   /* 0x80 */
+   u32 gic_jtag_reset; /* 0x88 */
+};
+
+#endif /* __ASSEMBLY__ */
+#endif /* _SUNXI_CPUCFG_SUN9I_H */


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/10] sunxi: Add base address of secure SRAM B for sun9i/A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

The A80 has a 256 kiB secure SRAM. However the first 4 kiB are reserved
for CPU0 hotplug flags.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
index 88b48c644c06..e9839eecaa92 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
@@ -20,6 +20,7 @@
 #define SUNXI_CPUCFG_BASE  0x0170
 #define SUNXI_CCI400_BASE  0x0179

+#define SUNXI_SRAM_B_BASE  0x0002
 #define SUNXI_SRAM_D_BASE  0x0810

 /* AHB0 Module */


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 02/10] sunxi: Add CCI-400 and CPUCFG registers base address for sun9i/A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

The A80, having 2 clusters of 4 cores each, has an ARM CCI-400 hardware
block for cache coherency.

Add the base address for CCI-400, and also add the base address for CPUCFG.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans

---
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
index c775bcc515a0..88b48c644c06 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
@@ -17,6 +17,9 @@
 #define REGS_APB1_BASE 0x0700
 #define REGS_RCPUS_BASE0x0800

+#define SUNXI_CPUCFG_BASE  0x0170
+#define SUNXI_CCI400_BASE  0x0179
+
 #define SUNXI_SRAM_D_BASE  0x0810

 /* AHB0 Module */


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/10] ARM: PSCI: Set ARMV7_PSCI_NR_CPUS default to 8 for sun9i/A80

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

The A80 is a big.LITTLE SoC with 4x Cortex-A7 in cluster 0 and 4x
Cortex-A15 in cluster 1.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 arch/arm/cpu/armv7/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index b9c4f4e79b9b..e37f1f328a34 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -44,6 +44,7 @@ config ARMV7_PSCI
 config ARMV7_PSCI_NR_CPUS
int "Maximum supported CPUs for PSCI"
depends on ARMV7_NONSEC
+   default 8 if MACH_SUN9I
default 4
help
  The maximum number of CPUs supported in the PSCI firmware.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sunxi: Mele_M5_defconfig: Drop non existing STATUSLED setting

[Hans de Goede]

And also remove it from scripts/config_whitelist.txt as the
Mele_M5_defconfig was the only one defining it.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 configs/Mele_M5_defconfig| 2 +-
 scripts/config_whitelist.txt | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/configs/Mele_M5_defconfig b/configs/Mele_M5_defconfig
index fffc332..09addc5 100644
--- a/configs/Mele_M5_defconfig
+++ b/configs/Mele_M5_defconfig
@@ -9,7 +9,7 @@ CONFIG_VIDEO_COMPOSITE=y
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-m5"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_AHCI=y
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,STATUSLED=234"
+CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index d476367..5a471fe 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4329,7 +4329,6 @@ CONFIG_STAMP_CF
 CONFIG_STANDALONE_LOAD_ADDR
 CONFIG_STATIC_BOARD_REV
 CONFIG_STATIC_RELA
-CONFIG_STATUSLED
 CONFIG_STATUS_LED
 CONFIG_STD_DEVICES_SETTINGS
 CONFIG_STK52XX
-- 
2.9.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] sunxi: sina33: Enable the eMMC

[Hans de Goede]

Hi,

On 04-11-16 16:18, Maxime Ripard wrote:

The SinA33 has an 4GB Toshiba eMMC connected to the MMC2 controller.
Enable it.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 configs/Sinlinx_SinA33_defconfig | 1 +
 1 file changed, 1 insertion(+), 0 deletions(-)

diff --git a/configs/Sinlinx_SinA33_defconfig b/configs/Sinlinx_SinA33_defconfig
index 2a5f985dd303..f4719db2d501 100644
--- a/configs/Sinlinx_SinA33_defconfig
+++ b/configs/Sinlinx_SinA33_defconfig
@@ -4,6 +4,7 @@ CONFIG_MACH_SUN8I_A33=y
 CONFIG_DRAM_CLK=552
 CONFIG_DRAM_ZQ=15291
 CONFIG_MMC0_CD_PIN="PB4"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_USB0_ID_DET="PH8"
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] sunxi: sina33: Enable the LCD

[Hans de Goede]

Hi,

On 04-11-16 16:18, Maxime Ripard wrote:

The SinA33 comes with an optional 7" display. Enable it in the
configuration.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans




---
 configs/Sinlinx_SinA33_defconfig | 4 
 1 file changed, 4 insertions(+), 0 deletions(-)

diff --git a/configs/Sinlinx_SinA33_defconfig b/configs/Sinlinx_SinA33_defconfig
index f4719db2d501..26b119a9b92f 100644
--- a/configs/Sinlinx_SinA33_defconfig
+++ b/configs/Sinlinx_SinA33_defconfig
@@ -6,6 +6,10 @@ CONFIG_DRAM_ZQ=15291
 CONFIG_MMC0_CD_PIN="PB4"
 CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 CONFIG_USB0_ID_DET="PH8"
+CONFIG_VIDEO_LCD_MODE="x:1024,y:600,depth:18,pclk_khz:66000,le:90,ri:160,up:3,lo:127,hs:70,vs:20,sync:3,vmode:0"
+CONFIG_VIDEO_LCD_DCLK_PHASE=0
+CONFIG_VIDEO_LCD_BL_EN="PH6"
+CONFIG_VIDEO_LCD_BL_PWM="PH0"
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL=y


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] mmc: Retry the switch command

[Hans de Goede]

Hi,

On 04-11-16 16:18, Maxime Ripard wrote:

Some eMMC will fail at the first switch, but would succeed in a subsequent
one.

Make sure we try several times to cover those cases. The number of retries
(and the behaviour) is currently what is being used in Linux.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Pantelis or Tom, can you pick this up please ?

Regards,

Hans



---
 drivers/mmc/mmc.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 4380c7c195a6..d6b7e4f510c9 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -494,6 +494,7 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 value)
 {
struct mmc_cmd cmd;
int timeout = 1000;
+   int retries = 3;
int ret;

cmd.cmdidx = MMC_CMD_SWITCH;
@@ -502,11 +503,17 @@ int mmc_switch(struct mmc *mmc, u8 set, u8 index, u8 
value)
 (index << 16) |
 (value << 8);

-   ret = mmc_send_cmd(mmc, , NULL);
+   while (retries > 0) {
+   ret = mmc_send_cmd(mmc, , NULL);

-   /* Waiting for the ready status */
-   if (!ret)
-   ret = mmc_send_status(mmc, timeout);
+   /* Waiting for the ready status */
+   if (!ret) {
+   ret = mmc_send_status(mmc, timeout);
+   return ret;
+   }
+
+   retries--;
+   }

return ret;



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] mmc: sunxi: Enable 8bits bus width for sun8i

[Hans de Goede]

Hi,

On 04-11-16 16:18, Maxime Ripard wrote:

The sun8i SoCs also have a 8 bits capable MMC2 controller. Enable the
support for those too.

Signed-off-by: Maxime Ripard <maxime.rip...@free-electrons.com>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 drivers/mmc/sunxi_mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 6953accce123..b8716c93cb06 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -463,7 +463,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)

cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
cfg->host_caps = MMC_MODE_4BIT;
-#ifdef CONFIG_MACH_SUN50I
+#if defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUN8I)
if (sdc_no == 2)
cfg->host_caps = MMC_MODE_8BIT;
 #endif


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: mmc: Set CONFIG_SYS_MMC_MAX_DEVICE

[Hans de Goede]

Hi,

On 05-11-16 20:51, Emmanuel Vadot wrote:

Set CONFIG_SYS_MMC_MAX_DEVICE to 4 for sunxi SoC.
This define is needed in the API code.

Signed-off-by: Emmanuel Vadot <m...@bidouilliste.com>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 include/configs/sunxi-common.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 8363414..edb3ff7 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -145,6 +145,7 @@
 #define CONFIG_MMC_SUNXI_SLOT  0
 #define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 0   /* first detected MMC 
controller */
+#define CONFIG_SYS_MMC_MAX_DEVICE  4
 #endif

 /* 64MB of malloc() pool */


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: sunxi: do not force USB for arch-sunxi

[Hans de Goede]

Hi,

On 31-10-16 22:33, Yann E. MORIN wrote:

Currently, USB is forced-enabled for the sunxi familly, and there is no
way to disable it.

However, USB takes a long time to initiliase, delaying the boot by up to
5 seconds (without any USB device attached!). This is a very long delay,
especially in cases where USB booting is not wanted at all, and where
the device is expected to boot relatively often (even in production).

Change the way the dependencies are handled, by only forcibly selecting
USB when CONFIG_DISTRO_DEFAULTS ("defaults suitable for booting general
purpose Linux distributions") is set. This option defaults to y for the
sunxi familly, so the current default behaviour is kept unchanged. Users
interested in boot time and/or size will be able to disable this to
further disable USB.

With USB disabled, the time spent in U-Boot before handing control to
the Linux kernel is about 1s now, down from ~5s (Nanopi Neo, sunxi H3).

Signed-off-by: "Yann E. MORIN" <yann.morin.1...@free.fr>
Cc: Ian Campbell <i...@hellion.org.uk>
Cc: Hans De Goede <hdego...@redhat.com>

---
This is a tentative patch, acting as an RFC (unless it is good to go as
is, of course!).


I cannot come up with a better approach either, so this LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



This has been discussed on IRC with  and , and this
solution is what emerged from the discussions as a first step.

The second step would be to defer intialisation of drivers until they
are actually needed, i.e. if main boot is not from USB, then don't
initiliase USB; if main boot fails, then initialise addtional drivers,
like USB... Or something along those lines... That's a much tougher
work for me, though...

There are other features that are currently forced like USB, but USB
is by far the worst "offender" and a low-hanging fruit. Those other
"offenders" can be handled in follow up changes.
---
 arch/arm/Kconfig | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..c13f60f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -561,22 +561,22 @@ config ARCH_SUNXI
bool "Support sunxi (Allwinner) SoCs"
select CMD_GPIO
select CMD_MMC if MMC
-   select CMD_USB
+   select CMD_USB if DISTRO_DEFAULTS
select DM
select DM_ETH
select DM_GPIO
select DM_KEYBOARD
select DM_SERIAL
-   select DM_USB
+   select DM_USB if DISTRO_DEFAULTS
select OF_BOARD_SETUP
select OF_CONTROL
select OF_SEPARATE
select SPL_STACK_R if SUPPORT_SPL
select SPL_SYS_MALLOC_SIMPLE if SUPPORT_SPL
select SYS_NS16550
-   select USB
-   select USB_STORAGE
-   select USB_KEYBOARD
+   select USB if DISTRO_DEFAULTS
+   select USB_STORAGE if DISTRO_DEFAULTS
+   select USB_KEYBOARD if DISTRO_DEFAULTS
select USE_TINY_PRINTF

 config TARGET_TS4800


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] drivers: SPI: sunxi SPL: fix warning

[Hans de Goede]

Hi,

On 03-11-16 01:58, Andre Przywara wrote:

Somehow an int returning function without a return statement sneaked
in. Fix it.

Signed-off-by: Andre Przywara <andre.przyw...@arm.com>


LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 drivers/mtd/spi/sunxi_spi_spl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/sunxi_spi_spl.c b/drivers/mtd/spi/sunxi_spi_spl.c
index 67c7edd..7502314 100644
--- a/drivers/mtd/spi/sunxi_spi_spl.c
+++ b/drivers/mtd/spi/sunxi_spi_spl.c
@@ -158,9 +158,10 @@ static void spi0_disable_clock(void)
 (1 << AHB_RESET_SPI0_SHIFT));
 }

-static int spi0_init(void)
+static void spi0_init(void)
 {
unsigned int pin_function = SUNXI_GPC_SPI0;
+
if (IS_ENABLED(CONFIG_MACH_SUN50I))
pin_function = SUN50I_GPC_SPI0;



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Use the available Kconfig option for AHCI

[Hans de Goede]

Hi,

On 31-10-16 21:05, Jelle van der Waa wrote:

Use the already available Kconfig option for AHCI. Tested on the
BananaPi.

Signed-off-by: Jelle van der Waa <je...@vdwaa.nl>


Patch LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans



---
 configs/A10-OLinuXino-Lime_defconfig   | 3 ++-
 configs/A20-OLinuXino-Lime2_defconfig  | 3 ++-
 configs/A20-OLinuXino-Lime_defconfig   | 3 ++-
 configs/A20-OLinuXino_MICRO_defconfig  | 3 ++-
 configs/A20-Olimex-SOM-EVB_defconfig   | 3 ++-
 configs/Bananapi_defconfig | 3 ++-
 configs/Bananapro_defconfig| 3 ++-
 configs/Cubieboard2_defconfig  | 3 ++-
 configs/Cubieboard_defconfig   | 3 ++-
 configs/Cubietruck_defconfig   | 3 ++-
 configs/Itead_Ibox_A20_defconfig   | 3 ++-
 configs/Lamobo_R1_defconfig| 3 ++-
 configs/Linksprite_pcDuino3_Nano_defconfig | 3 ++-
 configs/Linksprite_pcDuino3_defconfig  | 3 ++-
 configs/Marsboard_A10_defconfig| 3 ++-
 configs/Mele_A1000_defconfig   | 3 ++-
 configs/Mele_M5_defconfig  | 3 ++-
 configs/Orangepi_defconfig | 3 ++-
 configs/Orangepi_mini_defconfig| 3 ++-
 configs/Wits_Pro_A20_DKT_defconfig | 3 ++-
 20 files changed, 40 insertions(+), 20 deletions(-)

diff --git a/configs/A10-OLinuXino-Lime_defconfig 
b/configs/A10-OLinuXino-Lime_defconfig
index 04b720d..bb7eaf8 100644
--- a/configs/A10-OLinuXino-Lime_defconfig
+++ b/configs/A10-OLinuXino-Lime_defconfig
@@ -8,7 +8,8 @@ CONFIG_SYS_CLK_FREQ=91200
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun4i-a10-olinuxino-lime"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC,AHCI,SATAPWR=SUNXI_GPC(3)"
+CONFIG_AHCI=y
+CONFIG_SYS_EXTRA_OPTIONS="SUNXI_EMAC,SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index 4751fe0..d48e35d 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -8,7 +8,8 @@ CONFIG_USB0_VBUS_PIN="PC17"
 CONFIG_USB0_VBUS_DET="PH5"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime2"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
+CONFIG_AHCI=y
+CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/A20-OLinuXino-Lime_defconfig 
b/configs/A20-OLinuXino-Lime_defconfig
index 024dc2d..7c5d84d 100644
--- a/configs/A20-OLinuXino-Lime_defconfig
+++ b/configs/A20-OLinuXino-Lime_defconfig
@@ -6,7 +6,8 @@ CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPC(3)"
+CONFIG_AHCI=y
+CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/A20-OLinuXino_MICRO_defconfig 
b/configs/A20-OLinuXino_MICRO_defconfig
index 5809345..9eb5f1b 100644
--- a/configs/A20-OLinuXino_MICRO_defconfig
+++ b/configs/A20-OLinuXino_MICRO_defconfig
@@ -9,7 +9,8 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=3
 CONFIG_VIDEO_VGA=y
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-micro"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8)"
+CONFIG_AHCI=y
+CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,SATAPWR=SUNXI_GPB(8)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/A20-Olimex-SOM-EVB_defconfig 
b/configs/A20-Olimex-SOM-EVB_defconfig
index 7a14a7b..a6bf45f 100644
--- a/configs/A20-Olimex-SOM-EVB_defconfig
+++ b/configs/A20-Olimex-SOM-EVB_defconfig
@@ -11,7 +11,8 @@ CONFIG_USB0_VBUS_PIN="PB9"
 CONFIG_USB0_VBUS_DET="PH5"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olimex-som-evb"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
+CONFIG_AHCI=y
+CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/Bananapi_defconfig b/configs/Bananapi_defconfig
index 366ef24..3da1cf7 100644
--- a/configs/Bananapi_defconfig
+++ b/configs/Bananapi_defconfig
@@ -7,7 +7,8 @@ CONFIG_VIDEO_COMPOSITE=y
 CONFIG_GMAC_TX_DELAY=3
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-bananapi"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,MACPWR=SUNXI_GPH(23),AHCI"
+CONFIG

Re: [U-Boot] sunxi board: why MMC dev are swapped ?

[Hans de Goede]

Hi,

On 11-11-16 19:33, Mylene Josserand wrote:

Hi everyone,


I am currently using FEL and Fastboot to flash a sunxi-device with SPL and 
u-boot.


In my board, I have two MMC devices: a MMC slot and an eMMC.

My use-case is to flash an empty device. I want to use FEL to boot a u-boot and 
then, use fastboot to flash u-boot into eMMC.

When I am using an u-boot via FEL, the eMMC is configured as MMC1. To be able 
to flash u-boot on it, I need to set CONFIG_FASTBOOT_FLASH_MMC_DEV to 1. Thanks 
to that, the flashboot command is working fine.
But when I am booting on my fresh u-boot from eMMC, it is now configured as 
MMC0 and not MMC1 anymore.

It produces some problems in my case as I configured the 
CONFIG_FASTBOOT_FLASH_MMC_DEV to 1 so I can not use fastboot anymore to flash 
the eMMC (as, now, fastboot is trying to flash u-boot on my MMC slot and not my 
eMMC). This is clearly not what I wanted to. I would like to use fastboot to 
flash the same MMC device: eMMC.

This issue is located in this part of the code:
http://git.denx.de/?p=u-boot.git;a=blob;f=board/sunxi/board.c;h=53656383d512199338dcdc1d4fdc4f7f939c9b61;hb=HEAD#l377

Do you know why sunxi boards have this behavior ? Why this MMC device's swap is 
implemented ?


Most boards with emmc can boot from either the external mmc slot (sdc0 / port F)
or the emmc (sdc2 / port C).

Depending on the boot source, we map these as follows in u-boot:

Boot source sdc2:

MMC0: sdc2
MMC1: sdc0

Other boot source (including sdc0):

MMC0: sdc0
MMC1: sdc2

There are a number of reasons for this:

1) The loading of u-boot proper (the 3th boot stage) by the SPL (the 2nd boot 
stage,
with the SoCs BootROM being the 1st stage), the SPL mmc code used to always 
load from
MMC0, I believe this has been fixed now, so this is mainly historical.

2) The standard bootscripts from u-boot/include/config_distro_bootcmd.h start by
looking for extlinux/extlinux.conf / boot.scr in MMC0, clearly if we booted 
from sdc2,
the first place to look for these files should be sdc2, and not some random 
non-bootable
sdcard in the external slot. As is explained in the comment above the code for 
this you
already found.

I would certainly welcome some patches where some early init code would set a 
bootdev
environment variable and modify the boot_targets env variable to do the 
swapping there,
but include/config_distro_bootcmd.h does not make this easy. The best solution 
I can come
up with would be something like the attached patch.

I'm not 100% sure that the "if test ${bootdev} = sdc2;" bit will work, as I'm 
not sure
if the u-boot build-in "test" command supports comparing strings. Other then 
that
you would need to add some code to set bootdev in the env based on the return 
value
of readb(SPL_ADDR + 0x28), or maybe a more generic helper function using the 
standardized
return value from spl_boot_device(), as that may be useful for other boards too.

Once you're setting bootdev in the environement correctly, my patch should do 
the
trick to try and boot from sdc2 first when booting from the eMMC with the 
swapping
code you pointed out removed.

Then we can simply always map the devices as:

MMC0: sdc0
MMC1: sdc2

and we would still try to load extlinux/extlinux.conf from sdc2 first if that 
is the
boot source.

If you can get this to work then I would be happy to merge this, note the
include/config_distro_bootcmd.h bit should be submitted upstream as a separate
patch.

Regards,

Hans

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 9ecaf38..44047cf 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -314,6 +314,10 @@
 #define BOOTENV_BOOT_TARGETS \
"boot_targets=" BOOT_TARGET_DEVICES(BOOTENV_DEV_NAME) "\0"
 
+#ifndef BOOTENV_BOOTCMD_PRE_BOOT
+#define BOOTENV_BOOTCMD_PRE_BOOT
+#endif
+
 #define BOOTENV_DEV(devtypeu, devtypel, instance) \
BOOTENV_DEV_##devtypeu(devtypeu, devtypel, instance)
 #define BOOTENV \
@@ -384,7 +388,9 @@
\
BOOT_TARGET_DEVICES(BOOTENV_DEV)  \
\
-   "distro_bootcmd=" BOOTENV_SET_SCSI_NEED_INIT  \
+   "distro_bootcmd=" \
+   BOOTENV_SET_SCSI_NEED_INIT\
+   BOOTENV_BOOTCMD_PRE_BOOT  \
"for target in ${boot_targets}; do "  \
"run bootcmd_${target}; " \
"done\0"
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 8363414..b0e6a2a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -448,6 +448,24 @@ extern int soft_i2c_gpio_scl;
func(PXE, pxe, na) \
func(DHCP, dhcp, na)
 
+#if CONFIG_MMC_SUNXI_SLOT_EXTRA == 2
+
+#define BOOT_TARGET_DEVICES_MMC_SWAP(func) \
+   func(FEL, fel, na) \
+ 

Re: [U-Boot] [PATCH] arm: sunxi: do not force USB for arch-sunxi

[Hans de Goede]

Hi,

On 10-11-16 19:00, Yann E. MORIN wrote:

Ian, Hans, All,

On 2016-10-31 22:33 +0100, Yann E. MORIN spake thusly:

Currently, USB is forced-enabled for the sunxi familly, and there is no
way to disable it.

However, USB takes a long time to initiliase, delaying the boot by up to
5 seconds (without any USB device attached!). This is a very long delay,
especially in cases where USB booting is not wanted at all, and where
the device is expected to boot relatively often (even in production).

Change the way the dependencies are handled, by only forcibly selecting
USB when CONFIG_DISTRO_DEFAULTS ("defaults suitable for booting general
purpose Linux distributions") is set. This option defaults to y for the
sunxi familly, so the current default behaviour is kept unchanged. Users
interested in boot time and/or size will be able to disable this to
further disable USB.

With USB disabled, the time spent in U-Boot before handing control to
the Linux kernel is about 1s now, down from ~5s (Nanopi Neo, sunxi H3).


Just a gentle ping... ;-)


10 days is a bit short in between ping times for a volunteer maintained
subsys :)  Anyways I've this on my todo and hopefully will get around
to it soonish.

Regards,

Hans






Regards,
Yann E. MORIN.


Signed-off-by: "Yann E. MORIN" <yann.morin.1...@free.fr>
Cc: Ian Campbell <i...@hellion.org.uk>
Cc: Hans De Goede <hdego...@redhat.com>

---
This is a tentative patch, acting as an RFC (unless it is good to go as
is, of course!).

This has been discussed on IRC with  and , and this
solution is what emerged from the discussions as a first step.

The second step would be to defer intialisation of drivers until they
are actually needed, i.e. if main boot is not from USB, then don't
initiliase USB; if main boot fails, then initialise addtional drivers,
like USB... Or something along those lines... That's a much tougher
work for me, though...

There are other features that are currently forced like USB, but USB
is by far the worst "offender" and a low-hanging fruit. Those other
"offenders" can be handled in follow up changes.
---
 arch/arm/Kconfig | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..c13f60f 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -561,22 +561,22 @@ config ARCH_SUNXI
bool "Support sunxi (Allwinner) SoCs"
select CMD_GPIO
select CMD_MMC if MMC
-   select CMD_USB
+   select CMD_USB if DISTRO_DEFAULTS
select DM
select DM_ETH
select DM_GPIO
select DM_KEYBOARD
select DM_SERIAL
-   select DM_USB
+   select DM_USB if DISTRO_DEFAULTS
select OF_BOARD_SETUP
select OF_CONTROL
select OF_SEPARATE
select SPL_STACK_R if SUPPORT_SPL
select SPL_SYS_MALLOC_SIMPLE if SUPPORT_SPL
select SYS_NS16550
-   select USB
-   select USB_STORAGE
-   select USB_KEYBOARD
+   select USB if DISTRO_DEFAULTS
+   select USB_STORAGE if DISTRO_DEFAULTS
+   select USB_KEYBOARD if DISTRO_DEFAULTS
select USE_TINY_PRINTF

 config TARGET_TS4800
--
2.7.4




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/10] sunxi: Add basic PSCI support to enable SMP on the A80's first cluster

[Hans de Goede]

Hi,

On 09-11-16 11:21, Chen-Yu Tsai wrote:

Hi everyone,

This series adds basic PSCI support for the A80 to enable SMP on the
first cluster. This at least allows people to use more than one core.
The term "basic" is used because the series does not add support for
multi-cluster cache and power management.

The PSCI code is based on existing code for all the single cluster
SoCs, and the kernel patches for MCPM SMP I did some time ago.

Unfortunately only SMP works at this time. The last patch does not
actually work. While the system is indeed booted non-secure, tested
by trying to write to secure SRAM and the results not sticking, reads
from the GIC CPU interface shows that it's still returning the secure
copy of registers, and since we use a secure monitor FIQ to do core
power down, the FIQ gets passed to the kernel. The patch is included
so people with in-depth ARM knowledge could probably help work out
what is wrong.


Cools stuff, when I find some time I will review and merge
patches 1-9 to sunxi-next.

First a question though, do you see any chance that merging this might
get in the way of enabling support for both clusters in the future?

Since the interface between u-boot and the kernel here is well defined
(and outside our control) I guess in the worst case, we would need to
revert some bits of this series from u-boot if they turn out to be non
suitable, right?

Regards,

Hans






Regards
ChenYu

Chen-Yu Tsai (10):
  ARM: PSCI: Set ARMV7_PSCI_NR_CPUS default to 8 for sun9i/A80
  sunxi: Add CCI-400 and CPUCFG registers base address for sun9i/A80
  sunxi: Add base address of secure SRAM B for sun9i/A80
  sunxi: Use secure SRAM B for secure RAM for sun9i/A80
  sunxi: Add PRCM register definition for sun9i/A80
  sunxi: Add CPUCFG register definitions for sun9i/A80
  sunxi: Add support for TZPC on sun9i/A80
  sunxi: Add basic PSCI implementation for A80
  sunxi: Enable PSCI on sun9i/A80
  sunxi: Add PSCI core power off support for A80's first cluster

 arch/arm/cpu/armv7/Kconfig |   1 +
 arch/arm/cpu/armv7/sunxi/Makefile  |   5 +
 arch/arm/cpu/armv7/sunxi/psci-mcpm.c   | 322 +
 arch/arm/cpu/armv7/sunxi/tzpc.c|   6 +
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h|   5 +
 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h |  51 
 arch/arm/include/asm/arch-sunxi/prcm_sun9i.h   |  55 +
 arch/arm/include/asm/arch-sunxi/tzpc.h |   4 +
 arch/arm/mach-sunxi/board.c|   3 +-
 board/sunxi/Kconfig|   4 +
 include/configs/sun9i.h|   4 +
 11 files changed, 459 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/cpu/armv7/sunxi/psci-mcpm.c
 create mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg_sun9i.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/prcm_sun9i.h


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [bug report] sunxi: booting from eMMC

[Hans de Goede]

Hi,

On 04-11-16 23:57, Alexandr Bochkarev wrote:

I have found problem place, this patch with hotfix allows to boot Allwinner A20 
from eMMC.
Dont know how to full fix it.


Maxime posted a proper fix for this issue yesterday:

https://patchwork.ozlabs.org/patch/691284/

Can you give that one a try and see if it fixes things for you
as well ?

Regards,

Hans



commit 9fa5bf30e95ead17eb0c50375b305fb8615427a9
Author: root >
Date:   Sat Nov 5 04:41:30 2016 +0600

allow to boot A20 from eMMC, fix

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 6953acc..87cf964 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -293,11 +293,17 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct 
mmc_data *data)
 }

 static int mmc_rint_wait(struct mmc *mmc, unsigned int timeout_msecs,
-unsigned int done_bit, const char *what)
+unsigned int done_bit, const char *what, struct 
mmc_cmd *cmd)
 {
struct sunxi_mmc_host *mmchost = mmc->priv;
unsigned int status;

+   if (cmd->cmdidx == MMC_CMD_SWITCH)
+   {
+   printf("mmc_rint_wait: fix me\n");
+   return 0;
+   }
+
do {
status = readl(>reg->rint);
if (!timeout_msecs-- ||
@@ -380,7 +386,7 @@ static int sunxi_mmc_send_cmd(struct mmc *mmc, struct 
mmc_cmd *cmd,
}
}

-   error = mmc_rint_wait(mmc, 1000, SUNXI_MMC_RINT_COMMAND_DONE, "cmd");
+   error = mmc_rint_wait(mmc, 1000, SUNXI_MMC_RINT_COMMAND_DONE, "cmd", 
cmd);
if (error)
goto out;

@@ -391,7 +397,7 @@ static int sunxi_mmc_send_cmd(struct mmc *mmc, struct 
mmc_cmd *cmd,
  data->blocks > 1 ?
  SUNXI_MMC_RINT_AUTO_COMMAND_DONE :
  SUNXI_MMC_RINT_DATA_OVER,
- "data");
+ "data", cmd);
if (error)
goto out;
}




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 00/10] sunxi: Allwinner A64 SPL support

[Hans de Goede]

Hi,

On 03-11-16 11:36, Alexander Graf wrote:

On 11/03/2016 10:51 AM, Andre Przywara wrote:

Hi,

On 03/11/16 09:34, Hans de Goede wrote:



Hi,

First of all cool stuff! Thank you Andre and all others
involved for making this happen.

On 03-11-16 09:49, Alexander Graf wrote:

On 11/03/2016 02:36 AM, Andre Przywara wrote:

Hi,

this is my first take on the SPL support for the Allwinner A64 SoC.
The actual meat - the DRAM initialization code - has been provided
by Jens - many thanks for that!
The rest of the patches mostly deal with the 32-bit/64-bit switch.

While it is possible and seems natural to let the SPL also run in
64-bit,
this creates a really large binary (32600 Bytes in my case). With some
hacks (plus some fixes to make the SPL 64-bit safe) I got this to work,

So how about we merge the 64bit version first (since that's *way*
easier to compile for everyone) and then consider the move to 32bit
afterwards? I don't even want to start to imagine how to squeeze a
32bit SPL build into the build process for our U-Boot binaries.


but any addition will probably break it and exceed the 32KB limit that
the BROM imposes. Debug is the first obvious victim here.

Do you have some section size comparisons between the two?

Later down in the mail Andre says that in 32 bit (thumb) mode
the size goes down to 20KB which gives us a lot more head-room
then the 32600 out of 32768 bytes available for the 64 bit
version.

With that said I agree with you (Alex) that having a 32 bit
SPL + 64 bit u-boot proper is worry-some from a distro pov.

What's even nastier is the requirement of a cross compiler even for a
native build. Do Fedora and Suse offer packaged cross-compilers for the
other ARM bitness, respectively?


Andreas Faerber was working on cross compilers in openSUSE, but I don't think 
they're part of the distribution yet.


Fedora does have cross-compilers (for kernel and u-boot use, no
support for userland stuff). But as I outlined in my other mail,
with modern rpm you can do a build on all archs (which you want
to do anyways to get a native mkimage everywhere) and then use
%ifarch armv7hl / %ifarch aarch64 to build u-boot binaries
when doing a native build on armv7 / aarch64 and store all the
build binaries (one binary per supported board) under
/usr/share/u-boot and put /usr/share/u-boot in a noarch sub-pkg,
and Fedora's compose tools will then make that noarch sub-pkg from
that one specific arch build available in the repos for all archs.

Combine this with an extra noarch package which depends on the
noarch u-boot-images rpms generated by both the 32 and 64 bit build
and that extra package can generate a combined img ready for
dd-ing to a sdcard. If you solve it like this you do not need
cross compilation. Yes this is not pretty, but it will work
(at least for Fedora, I do not know how Suse's tools deal
with noarch sub-packages of a non noarch rpm, rpm itself can
handle this, but something needs to copy the generated noarch
sub-rpm to the other archs).

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 00/10] sunxi: Allwinner A64 SPL support

[Hans de Goede]

Hi,

On 03-11-16 10:38, Andre Przywara wrote:

Hi,

On 03/11/16 08:49, Alexander Graf wrote:

On 11/03/2016 02:36 AM, Andre Przywara wrote:

Hi,

this is my first take on the SPL support for the Allwinner A64 SoC.
The actual meat - the DRAM initialization code - has been provided
by Jens - many thanks for that!
The rest of the patches mostly deal with the 32-bit/64-bit switch.

While it is possible and seems natural to let the SPL also run in 64-bit,
this creates a really large binary (32600 Bytes in my case). With some
hacks (plus some fixes to make the SPL 64-bit safe) I got this to work,


So how about we merge the 64bit version first (since that's *way* easier
to compile for everyone) and then consider the move to 32bit afterwards?


Mmmh, interesting idea, may be worth a try alone for the sake of the
64-bit fixes to the SPL code I have done in this process.
But I am not sure it doesn't already break for people using just a
different compiler. I even started to chop of some bytes here and there
to bring the size down (I gained 200 Bytes at the ctype implementation,
yeah!)


I don't even want to start to imagine how to squeeze a 32bit SPL build
into the build process for our U-Boot binaries.


I totally agree, even for me it's quite a pain, because a "make clean"
(which you need in between) removes the build result of that other
bitness, so you always have to remember to copy the binaries first (and
then up using stale copies afterwards).


but any addition will probably break it and exceed the 32KB limit that
the BROM imposes. Debug is the first obvious victim here.


Do you have some section size comparisons between the two?


I spent some time into looking at readelf dumps to find the reason for
the bigger size, but nothing really stood out. Still it is a bit odd,
since the size ratio for U-Boot proper is much better (like +20% for
64-bit).


IIRC we build the SPL as thumb2, and u-boot proper as regular armv7,
which may explain why the impact on the SPL for going 64 bit is much
larger.

Anyways I'm a fan of just going with 64 bits for now + trying to
squeeze some bytes of the size left and right too.

Have you looked at the size(s) of the C-string sections? In the past
we've had linker bugs where unused C-strings where kept in the final
linked binary, and even if you're not hitting that bug then strings
may make up for a significant chunk of the size and we could try
to make various (error) messages less verbose (or add some CONFIG
option to do so) to make things smaller.

Regards,

Hans



A promising approach I then tried was to use -mabi=ilp32, which GCC
itself supports for quite a while already. But that was running into
ICEs, with no obviously bogus code. If someone more compiler-savvy could
take a look later, I'd be grateful.

That being said I will try to revive the AArch64 port tonight and push
this somewhere, so that people can have a look.

Cheers,
Andre.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 03/10] sunxi: provide default DRAM config for sun50i in Kconfig

[Hans de Goede]

Hi,

On 03-11-16 10:17, Andre Przywara wrote:

Hi Hans,

thanks for having a look.

On 03/11/16 09:13, Hans de Goede wrote:

Hi,

On 03-11-16 10:10, Andre Przywara wrote:

Hi,

On 03/11/16 08:54, Alexander Graf wrote:

On 11/03/2016 02:36 AM, Andre Przywara wrote:

To avoid enumerating the very same DRAM values in defconfig files
for each and every Allwinner A64 board out there, let's put some sane
default values in the Kconfig file.
Boards with different needs can override them at any time.

Signed-off-by: Andre Przywara <andre.przyw...@arm.com>
---
  board/sunxi/Kconfig   | 3 +++
  configs/pine64_plus_defconfig | 2 --
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e1d4ab1..d281a65 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -145,6 +145,7 @@ config DRAM_CLK
  default 792 if MACH_SUN9I
  default 312 if MACH_SUN6I || MACH_SUN8I
  default 360 if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
+default 672 if MACH_SUN50I
  ---help---
  Set the dram clock speed, valid range 240 - 480 (prior to sun9i),
  must be a multiple of 24. For the sun9i (A80), the tested values
@@ -164,6 +165,7 @@ config DRAM_ZQ
  default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I ||
MACH_SUN8I
  default 127 if MACH_SUN7I
  default 4145117 if MACH_SUN9I
+default 3881915 if MACH_SUN50I
  ---help---
  Set the dram zq value.
  @@ -171,6 +173,7 @@ config DRAM_ODT_EN
  bool "sunxi dram odt enable"
  default n if !MACH_SUN8I_A23
  default y if MACH_SUN8I_A23
+default y if MACH_SUN50I


This change isn't obvious. It's not mentioned in the patch description
or removed from the defconfig.


Oh, right, looks like a rebase artifact, since I juggled the patches
around quite a bit. It belongs to patch 10/10, I guess.


It is setting a DRAM default, so it is fine, as for it not being
removed from the defconfig, it is not yet present in the one defconfig
we have for a64. OTOH it would be food to remove the


No breakfast yet?   ;-) 


DRAM_CLK and DRAM_ZQ values from configs/pine64_plus_defconfig as
part of this patch.


Like the hunk below?


Ugh, yes like that one, so from my pov this patch is good to go :)

Regards.

Hans



Cheers,
Andre.


  ---help---
  Select this to enable dram odt (on die termination).
  diff --git a/configs/pine64_plus_defconfig
b/configs/pine64_plus_defconfig
index 6d0198f..a53e968 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -2,8 +2,6 @@ CONFIG_ARM=y
  CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
  CONFIG_ARCH_SUNXI=y
  CONFIG_MACH_SUN50I=y
-CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881915
  CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_CONSOLE_MUX=y



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 00/10] sunxi: Allwinner A64 SPL support

[Hans de Goede]

Hi,

First of all cool stuff! Thank you Andre and all others
involved for making this happen.

On 03-11-16 09:49, Alexander Graf wrote:

On 11/03/2016 02:36 AM, Andre Przywara wrote:

Hi,

this is my first take on the SPL support for the Allwinner A64 SoC.
The actual meat - the DRAM initialization code - has been provided
by Jens - many thanks for that!
The rest of the patches mostly deal with the 32-bit/64-bit switch.

While it is possible and seems natural to let the SPL also run in 64-bit,
this creates a really large binary (32600 Bytes in my case). With some
hacks (plus some fixes to make the SPL 64-bit safe) I got this to work,


So how about we merge the 64bit version first (since that's *way* easier to 
compile for everyone) and then consider the move to 32bit afterwards? I don't 
even want to start to imagine how to squeeze a 32bit SPL build into the build 
process for our U-Boot binaries.


but any addition will probably break it and exceed the 32KB limit that
the BROM imposes. Debug is the first obvious victim here.


Do you have some section size comparisons between the two?


Later down in the mail Andre says that in 32 bit (thumb) mode
the size goes down to 20KB which gives us a lot more head-room
then the 32600 out of 32768 bytes available for the 64 bit
version.

With that said I agree with you (Alex) that having a 32 bit
SPL + 64 bit u-boot proper is worry-some from a distro pov.

What I would like to see is:

1) Ensure we keep a pure 64 bit build working, which should
lead to a fully functional u-boot-sunxi-with-spl.bin just like
how things work for current 32 bit boards. This will give
distros an easy way to deal with this and is also easier
for users who built from source (like people who to the
occasional contribution but are not really into u-boot).

2) Offer the 32 bit option in the do 2 builds, combine 32 bit
SPL with 64 bit u-boot proper (and ATF) as Andre is suggesting
as an option.

We may need to strip some features from "1" in the future,
e.g. no NAND support.

For distros we could then still opt to use 2, to e.g. get
NAND support. One solution I have in mind is:

a) Do a native 32 bit build for the 32 bit SPL, store the SPL
somewhere (just like we store u-boot-sunxi-with-spl.bin for
end users to dd for other 32 bit boards), on Fedora this
build would generate uboot-images-armv7.noarch.rpm
(we already put all the generated u-boot-sunxi-with-spl.bin
files in this noarch rpm).

b) Do a native 64 bit build which stores both a 64 bit
u-boot-sunxi-with-spl.bin as well as just a u-boot.bin
(unless we can extract the latter easy enough), on fedora
this build would generate uboot-images-armv8.noarch.rpm
(as we already do).

c) Have a separate noarch (in rpm terms) package which
depends on the 2 packages build from a. and b. this is
This can then just combine the results from a. and b.
into a mixed 32 + 64 bit u-boot-sunxi-with-spl.bin
we could call this uboot-images-arm-mixed.noarch.rpm :)

So although not pretty from the Fedora pov I can see
ways to work around things and even be able to use "2"
in Fedora.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 03/10] sunxi: provide default DRAM config for sun50i in Kconfig

[Hans de Goede]

Hi,

On 03-11-16 10:10, Andre Przywara wrote:

Hi,

On 03/11/16 08:54, Alexander Graf wrote:

On 11/03/2016 02:36 AM, Andre Przywara wrote:

To avoid enumerating the very same DRAM values in defconfig files
for each and every Allwinner A64 board out there, let's put some sane
default values in the Kconfig file.
Boards with different needs can override them at any time.

Signed-off-by: Andre Przywara 
---
  board/sunxi/Kconfig   | 3 +++
  configs/pine64_plus_defconfig | 2 --
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index e1d4ab1..d281a65 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -145,6 +145,7 @@ config DRAM_CLK
  default 792 if MACH_SUN9I
  default 312 if MACH_SUN6I || MACH_SUN8I
  default 360 if MACH_SUN4I || MACH_SUN5I || MACH_SUN7I
+default 672 if MACH_SUN50I
  ---help---
  Set the dram clock speed, valid range 240 - 480 (prior to sun9i),
  must be a multiple of 24. For the sun9i (A80), the tested values
@@ -164,6 +165,7 @@ config DRAM_ZQ
  default 123 if MACH_SUN4I || MACH_SUN5I || MACH_SUN6I || MACH_SUN8I
  default 127 if MACH_SUN7I
  default 4145117 if MACH_SUN9I
+default 3881915 if MACH_SUN50I
  ---help---
  Set the dram zq value.
  @@ -171,6 +173,7 @@ config DRAM_ODT_EN
  bool "sunxi dram odt enable"
  default n if !MACH_SUN8I_A23
  default y if MACH_SUN8I_A23
+default y if MACH_SUN50I


This change isn't obvious. It's not mentioned in the patch description
or removed from the defconfig.


Oh, right, looks like a rebase artifact, since I juggled the patches
around quite a bit. It belongs to patch 10/10, I guess.


It is setting a DRAM default, so it is fine, as for it not being
removed from the defconfig, it is not yet present in the one defconfig
we have for a64. OTOH it would be food to remove the
DRAM_CLK and DRAM_ZQ values from configs/pine64_plus_defconfig as
part of this patch.

Regards,

Hans





Cheers,
Andre.


  ---help---
  Select this to enable dram odt (on die termination).
  diff --git a/configs/pine64_plus_defconfig
b/configs/pine64_plus_defconfig
index 6d0198f..a53e968 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -2,8 +2,6 @@ CONFIG_ARM=y
  CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
  CONFIG_ARCH_SUNXI=y
  CONFIG_MACH_SUN50I=y
-CONFIG_DRAM_CLK=672
-CONFIG_DRAM_ZQ=3881915
  CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_CONSOLE_MUX=y



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-sunxi sun9i-a80-spl

[Hans de Goede]

Hi Tom,

Here is another sunxi pull-req, this one is to be applied on top of the
bug-fix one I send out a few seconds ago. I'm sending this one as
a separate pull-req since it contains non-bugfix changes which were
first submitted outside the merge window.

The entire set of patches in this pull-req enables DRAM controller init
and SPL for the Allwinner A80 SoC. These changes are isolated to the A80
SoC and should not impact other (sunxi) SoCs. Without SPL u-boot was never
really usable on the A80 SoC, so in a sense this is a bug-fix pull-req,
as it makes u-boot fully functional on the A80 for the first time.

Anyways I've deliberately put this in a separate pull-req to make it
easy for you to nack this one as being too late in the cycle, and I'm
fine with keeping these in my tree until the next merge-window opens.

I assume it is clear that my preference (and judgement call on this
being safe) is to get these into v2016.11, otherwise I would not have
send the pull-req.

The following changes since commit fed329aebe3aaac0928c73547ac6316af2adf0cd:

  tools: add mksunxiboot to tools-all target (2016-10-30 11:38:04 +0100)

are available in the git repository at:

  http://git.denx.de/u-boot-sunxi.git sun9i-a80-spl

for you to fetch changes up to fda9d5d327302e2e5a45ade25e88edc0002336ec:

  sunxi: Add support for Cubieboard4 (2016-10-30 11:38:05 +0100)


Chen-Yu Tsai (5):
  sunxi: Set default CPU clock rate to 1008 MHz for sun9i (A80)
  sunxi: Add support for SID e-fuses on sun9i
  sunxi: Add default zq value for sun9i (A80)
  sunxi: Enable SPL support for A80 Optimus board
  sunxi: Add support for Cubieboard4

Philipp Tomsich (6):
  sunxi: DRAM initialisation for sun9i
  sunxi: add gtbus-initialisation for sun9i
  sunxi: Enable SMP mode for the boot CPU on sun9i (A80)
  sunxi: add initial clock setup for sun9i for SPL
  sunxi: enable SPL for sun9i
  sunxi: add MMC pinmux setup for SDC2 on sun9i

 arch/arm/include/asm/arch-sunxi/clock_sun9i.h | 116 +++-
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h   |  10 +
 arch/arm/include/asm/arch-sunxi/dram.h|   2 +
 arch/arm/include/asm/arch-sunxi/dram_sun9i.h  | 278 
 arch/arm/include/asm/arch-sunxi/gtbus.h   |  21 +
 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h |  92 +++
 arch/arm/mach-sunxi/Makefile  |   3 +-
 arch/arm/mach-sunxi/board.c   |   3 +-
 arch/arm/mach-sunxi/clock.c   |   6 +
 arch/arm/mach-sunxi/clock_sun9i.c | 146 +++-
 arch/arm/mach-sunxi/dram_sun9i.c  | 961 ++
 arch/arm/mach-sunxi/gtbus_sun9i.c |  48 ++
 board/sunxi/Kconfig   |  10 +-
 board/sunxi/MAINTAINERS   |  10 +
 board/sunxi/board.c   |   7 +
 configs/Cubieboard4_defconfig |  18 +
 configs/Merrii_A80_Optimus_defconfig  |  15 +-
 17 files changed, 1718 insertions(+), 28 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun9i.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/gtbus.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h
 create mode 100644 arch/arm/mach-sunxi/dram_sun9i.c
 create mode 100644 arch/arm/mach-sunxi/gtbus_sun9i.c
 create mode 100644 configs/Cubieboard4_defconfig

Regards,

Hans

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-sunxi master

[Hans de Goede]

Hi Tom,

Here is a pull request with some small sunxi cleanups / fixes
for v2016.11.

Note I expect you to merge this after Marek's usb pull-req. If you don't
nothing will break, but you will get a whole bunch of new compiler warnings
when building the pine64_plus defconfig.

The following changes since commit 4d6afd69babafbf6580cb04dacd9479df03a5de0:

  configs/chromebox_panther_defconfig: Re-enable CONFIG_DM_PCI (2016-10-29 
09:00:01 -0400)

are available in the git repository at:

  http://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to fed329aebe3aaac0928c73547ac6316af2adf0cd:

  tools: add mksunxiboot to tools-all target (2016-10-30 11:38:04 +0100)


Amit Singh Tomar (1):
  sunxi: A64: enable USB support

Andre Przywara (1):
  sunxi: dts: Pine64: add Ethernet alias

Jagan Teki (1):
  sunxi: Rename CONFIG_SUNXI to CONFIG_ARCH_SUNXI

Masahiro Yamada (1):
  sunxi: remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defines

Stefan Brüns (1):
  tools: add mksunxiboot to tools-all target

Stefan Mavrodiev (1):
  sunxi: Update DRAM clock for Olimex A20 boards

 Makefile|  2 +-
 arch/arm/cpu/armv7/Makefile |  2 +-
 arch/arm/dts/sun50i-a64-pine64-common.dtsi  | 13 +
 arch/arm/dts/sun50i-a64.dtsi| 29 +
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h |  2 +-
 arch/arm/mach-sunxi/usb_phy.c   |  5 +++--
 configs/A20-Olimex-SOM-EVB_defconfig|  2 +-
 configs/pine64_plus_defconfig   |  1 +
 drivers/i2c/mvtwsi.c|  6 +++---
 drivers/usb/host/ehci-sunxi.c   |  7 ---
 drivers/usb/host/ohci-sunxi.c   |  1 +
 include/configs/sun4i.h |  1 -
 include/configs/sun50i.h|  5 +
 include/configs/sun5i.h |  1 -
 include/configs/sun6i.h |  1 -
 include/configs/sun7i.h |  1 -
 include/configs/sun8i.h |  1 -
 include/configs/sunxi-common.h  |  1 -
 scripts/Makefile.spl|  2 +-
 scripts/config_whitelist.txt|  1 -
 tools/Makefile  |  3 ++-
 tools/mksunxiboot.c |  2 +-
 22 files changed, 67 insertions(+), 22 deletions(-)

Regards,

Hans

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [U-Boot, 2/2] sunxi: A64: enable USB support

[Hans de Goede]

Hi,

On 29-10-16 14:52, Hans de Goede wrote:

Hi,

On 21-10-16 03:24, Andre Przywara wrote:

From: Amit Singh Tomar <amittome...@gmail.com>

Mostly by adding MACH_SUN50I to some existing #ifdefs enable support
for the the HCI0 USB host controller on the A64.
Fix up some minor 64-bit hiccups on the way.
Add the bare minimum DT bits to the A64 .dtsi and enable the controllers
and the PHY on the Pine64.
This is limited to the first USB controller at the moment, which is
connected to the lower USB socket on the Pine64 board.
[Andre: remove unneeded defines, enable OHCI, add commit message]

Signed-off-by: Amit Singh Tomar <amittome...@gmail.com>
Signed-off-by: Andre Przywara <andre.przyw...@arm.com>


Other then CONFIG_USB_MAX_CONTROLLER_COUNT no longer being necessary
(it should be dropped from include/configs/sun50i.h) this patch looks
good to me and is:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Note I cannot merged it till Marek merges the first patch in
the series, which really needs to go through the u-boot-usb tree.


Marek just send out a pull-req with this patch in there so I've
added this patch to my tree and will include it in the pull-req I
will send out later today.

Regards,

Hans


---
 arch/arm/dts/sun50i-a64-pine64-common.dtsi  | 12 
 arch/arm/dts/sun50i-a64.dtsi| 29 +
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h |  2 +-
 arch/arm/mach-sunxi/usb_phy.c   |  5 +++--
 configs/pine64_plus_defconfig   |  1 +
 drivers/usb/host/ehci-sunxi.c   |  7 ---
 drivers/usb/host/ohci-sunxi.c   |  1 +
 include/configs/sun50i.h|  5 +
 8 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi 
b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
index c0fde44..9ec81c6 100644
--- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
+++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
@@ -79,3 +79,15 @@
 pinctrl-0 = <_pins>;
 status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/dts/sun50i-a64.dtsi b/arch/arm/dts/sun50i-a64.dtsi
index 7d0dc76..bef0d00 100644
--- a/arch/arm/dts/sun50i-a64.dtsi
+++ b/arch/arm/dts/sun50i-a64.dtsi
@@ -653,5 +653,34 @@
 #address-cells = <1>;
 #size-cells = <0>;
 };
+
+usbphy: phy@1c1b810 {
+compatible = "allwinner,sun50i-a64-usb-phy",
+ "allwinner,sun8i-a33-usb-phy";
+reg = <0x01c1b810 0x14>, <0x01c1b800 0x4>;
+reg-names = "phy_ctrl", "pmu1";
+status = "disabled";
+#phy-cells = <1>;
+};
+
+ehci1: usb@01c1b000 {
+compatible = "allwinner,sun50i-a64-ehci",
+ "generic-ehci";
+reg = <0x01c1b000 0x100>;
+interrupts = ;
+phys = < 1>;
+phy-names = "usb";
+status = "disabled";
+};
+
+ohci1: usb@01c1b400 {
+compatible = "allwinner,sun50i-a64-ohci",
+ "generic-ohci";
+reg = <0x01c1b400 0x100>;
+interrupts = ;
+phys = < 1>;
+phy-names = "usb";
+status = "enabled";
+};
 };
 };
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 5f93830..7232f6d 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -56,7 +56,7 @@
 #define SUNXI_USB2_BASE0x01c1c000
 #endif
 #ifdef CONFIG_SUNXI_GEN_SUN6I
-#ifdef CONFIG_MACH_SUN8I_H3
+#if defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
 #define SUNXI_USBPHY_BASE0x01c19000
 #define SUNXI_USB0_BASE0x01c1a000
 #define SUNXI_USB1_BASE0x01c1b000
diff --git a/arch/arm/mach-sunxi/usb_phy.c b/arch/arm/mach-sunxi/usb_phy.c
index bd1bbee..278587b 100644
--- a/arch/arm/mach-sunxi/usb_phy.c
+++ b/arch/arm/mach-sunxi/usb_phy.c
@@ -146,12 +146,13 @@ __maybe_unused static void usb_phy_write(struct 
sunxi_usb_phy *phy, int addr,
 }
 }

-#if defined CONFIG_MACH_SUN8I_H3
+#if defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
 static void sunxi_usb_phy_config(struct sunxi_usb_phy *phy)
 {
+#if defined CONFIG_MACH_SUN8I_H3
 if (phy->id == 0)
 clrbits_le32(SUNXI_USBPHY_BASE + REG_PHY_UNK_H3, 0x01);
-
+#endif
 clrbits_le32(phy->base + REG_PMU_UNK_H3, 0x02);
 }
 #elif defined CONFIG_MACH_SUN8I_A83T
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 6f82190..bd3e2e6 100644
--- a/configs/pine64_plus_def

Re: [U-Boot] [PATCH] MAINTAINERS: SUNXI: Add Jagan as Co-Maintainer

[Hans de Goede]

Hi Jagan,

On 29-10-16 21:26, Jagan Teki wrote:

Due to the discussion from thread[1] about the Hans
stepping down as sunix custodian, I would like to
volunteer as a co-maintainer for sunxi and discussed
the same with Hans as well.

[1] http://lists.denx.de/pipermail/u-boot/2016-July/259688.html

Cc: Maxime Ripard <maxime.rip...@free-electrons.com>
Cc: Ian Campbell <i...@hellion.org.uk>
Cc: Hans De Goede <hdego...@redhat.com>
Signed-off-by: Jagan Teki <ja...@openedev.com>


I appreciate all the reviews you've done of sunxi patches,
thank you for that. But I've yet to see any significant
contributions to u-boot sunxi support from you, as such
I do not feel that you are ready to co-maintain the
sunxi code, sorry.

Regards,

Hans




---
 MAINTAINERS| 1 +
 doc/git-mailrc | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0bd8995..c96625a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -169,6 +169,7 @@ F:  arch/arm/include/asm/arch-stv0991/
 ARM SUNXI
 M: Ian Campbell <i...@hellion.org.uk>
 M: Hans De Goede <hdego...@redhat.com>
+M: Jagan Teki <ja...@openedev.com>
 S: Maintained
 T: git git://git.denx.de/u-boot-sunxi.git
 F: arch/arm/cpu/armv7/sunxi/
diff --git a/doc/git-mailrc b/doc/git-mailrc
index d01a8c7..9e26c4d 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -70,7 +70,7 @@ alias s5pc   samsung
 alias samsunguboot, prom
 alias snapdragon uboot, mateusz
 alias socfpgauboot, marex, Dinh Nguyen <dingu...@opensource.altera.com>
-alias sunxi  uboot, ijc, jwrdegoede
+alias sunxi  uboot, ijc, jwrdegoede, jagan
 alias tegra  uboot, sjg, Tom Warren <twar...@nvidia.com>, Stephen Warren 
<swar...@nvidia.com>
 alias tegra2 tegra
 alias ti uboot, trini


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH 00/11] sunxi: Add full SPL support for sun9i (A80)

[Hans de Goede]

Hi,

On 30-10-16 06:30, Chen-Yu Tsai wrote:

On Sat, Oct 29, 2016 at 8:06 PM, Hans de Goede <hdego...@redhat.com> wrote:

Hi,


On 28-10-16 19:30, Hans de Goede wrote:


Hi Chen-Yu,

On 28-10-16 12:21, Chen-Yu Tsai wrote:


Hi everyone,

This series adds full SPL with DRAM initialization for sun9i (A80).
The bulk of the work was done by the people at Theobroma Systems.
Their work can be found here:

https://git.theobroma-systems.com/armadillo-u-boot.git/

I picked the essential patches and cleaned them up a bit more,
and added commit messages if they were missing.

As the DRAM bits are essentially a code dump with some cleanups and
some bits disabled, expect many warnings. Checkpatch is still not
happy with it.

I've tested the series on both my A80 boards, which I've added
defconfigs for in the last 2 patches. My A80 Optimus does not
boot from micro SD, so I'm still FEL booting that one. But my
Cubieboard 4 is now standalone.

As usual, please have a look, test if possible.



Awesome, thanks for doing this and it was good to have
some face2face time at ELCE.

I've merged this into my personal sunxi-wip u-boot branch,
I've made 2 changes:

1) in : ¨sunxi: DRAM initialisation for sun9i" there are a
lot of #if 0 #endif blocks, most of these document some features
which we may want to enable in the future, but a few were just
dead weight IMHO, so I've pruned a few

2) in : "sunxi: Add support for A80 Optimus board", we already
have a configs/Merrii_A80_Optimus_defconfig, so I've made the patch
update that instead of adding a new defconfig

I have not tested this yet, I will do tomorrow, assuming it
works for me too I will include it in my next pull-req (*)



Ok, just finished testing, u-boot seems to work well. I do
seem to have one kernel issue (with the last 4.8 based
sunxi-next kernel, I still need to upgrade that) :

[1.137105] Division by zero in kernel.
[1.140988] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0+ #475
[1.147089] Hardware name: Allwinner sun9i Family
[1.151830] [] (unwind_backtrace) from []
(show_stack+0x18/0x1c)
[1.159596] [] (show_stack) from []
(dump_stack+0x80/0x9c)
[1.166839] [] (dump_stack) from [] (Ldiv0+0x8/0x10)
[1.173558] [] (Ldiv0) from []
(sun4i_a10_get_mod0_factors+0x2c/0x8c)
[1.181758] [] (sun4i_a10_get_mod0_factors) from []
(clk_factors_determine_rate+0xb8/0xf8)
[1.191781] [] (clk_factors_determine_rate) from []
(clk_composite_determine_rate+0x58/0x1cc)
[1.202062] [] (clk_composite_determine_rate) from []
(clk_calc_new_rates+0xa0/0x240)
[1.211647] [] (clk_calc_new_rates) from []
(clk_core_set_rate_nolock+0x4c/0xbc)
[1.220798] [] (clk_core_set_rate_nolock) from []
(clk_set_rate+0x28/0x38)
[1.229432] [] (clk_set_rate) from []
(sunxi_ir_probe+0xfc/0x480)
[1.420454] [] (sunxi_ir_probe) from []
(platform_drv_pro
be+0x58/0xa4)

...

And it fails to find any mmc controllers, but that might be related to
the above oops (maybe it stops probing after that due to a stuck lock).


This is related to the regulators, specifically cold boot default
values for ldo_ios causing the regulators to fail to register. You
actually fixed this for the axp22x's before.

There's also the addressing issue for the axp806.

See the top of https://github.com/wens/linux/commits/sun9i-gmac-wifi
for the bunch of fixes I need to send.


Anyways the u-boot side looks good. One issue I see is that your
optimus has an emmc, where as mine has a nand. We may want to
gave 2 optimus defconfigs for this once we've nand support.


Hmm... This implies the need for 2 versions of dts files as well.
Any ideas on probing for nand/emmc during boot?


If we want to use a single devicetree and use something like quirks
or some such, I'm sure we can up with some way to find out whether
there is an emmc or nand connected during boot (in u-boot), but
this requires a mechanism like dt-quirks to first get merged
upstream. Anyways NAND support is still not here, lets just go
with eMMC support in u-boot + the dts and we can worry about NAND
support later (this will likely cause some kernel errors on optimus
boards with NAND, but I live with that).

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,2/2] sunxi: A64: enable USB support

[Hans de Goede]

Hi,

On 21-10-16 03:24, Andre Przywara wrote:

From: Amit Singh Tomar <amittome...@gmail.com>

Mostly by adding MACH_SUN50I to some existing #ifdefs enable support
for the the HCI0 USB host controller on the A64.
Fix up some minor 64-bit hiccups on the way.
Add the bare minimum DT bits to the A64 .dtsi and enable the controllers
and the PHY on the Pine64.
This is limited to the first USB controller at the moment, which is
connected to the lower USB socket on the Pine64 board.
[Andre: remove unneeded defines, enable OHCI, add commit message]

Signed-off-by: Amit Singh Tomar <amittome...@gmail.com>
Signed-off-by: Andre Przywara <andre.przyw...@arm.com>


Other then CONFIG_USB_MAX_CONTROLLER_COUNT no longer being necessary
(it should be dropped from include/configs/sun50i.h) this patch looks
good to me and is:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Note I cannot merged it till Marek merges the first patch in
the series, which really needs to go through the u-boot-usb tree.

Regards,

Hans



---
 arch/arm/dts/sun50i-a64-pine64-common.dtsi  | 12 
 arch/arm/dts/sun50i-a64.dtsi| 29 +
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h |  2 +-
 arch/arm/mach-sunxi/usb_phy.c   |  5 +++--
 configs/pine64_plus_defconfig   |  1 +
 drivers/usb/host/ehci-sunxi.c   |  7 ---
 drivers/usb/host/ohci-sunxi.c   |  1 +
 include/configs/sun50i.h|  5 +
 8 files changed, 56 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi 
b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
index c0fde44..9ec81c6 100644
--- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
+++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
@@ -79,3 +79,15 @@
pinctrl-0 = <_pins>;
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/dts/sun50i-a64.dtsi b/arch/arm/dts/sun50i-a64.dtsi
index 7d0dc76..bef0d00 100644
--- a/arch/arm/dts/sun50i-a64.dtsi
+++ b/arch/arm/dts/sun50i-a64.dtsi
@@ -653,5 +653,34 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+   usbphy: phy@1c1b810 {
+   compatible = "allwinner,sun50i-a64-usb-phy",
+"allwinner,sun8i-a33-usb-phy";
+   reg = <0x01c1b810 0x14>, <0x01c1b800 0x4>;
+   reg-names = "phy_ctrl", "pmu1";
+   status = "disabled";
+   #phy-cells = <1>;
+   };
+
+   ehci1: usb@01c1b000 {
+   compatible = "allwinner,sun50i-a64-ehci",
+"generic-ehci";
+   reg = <0x01c1b000 0x100>;
+   interrupts = ;
+   phys = < 1>;
+   phy-names = "usb";
+   status = "disabled";
+   };
+
+   ohci1: usb@01c1b400 {
+   compatible = "allwinner,sun50i-a64-ohci",
+"generic-ohci";
+   reg = <0x01c1b400 0x100>;
+   interrupts = ;
+   phys = < 1>;
+   phy-names = "usb";
+   status = "enabled";
+   };
};
 };
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index 5f93830..7232f6d 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -56,7 +56,7 @@
 #define SUNXI_USB2_BASE0x01c1c000
 #endif
 #ifdef CONFIG_SUNXI_GEN_SUN6I
-#ifdef CONFIG_MACH_SUN8I_H3
+#if defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
 #define SUNXI_USBPHY_BASE  0x01c19000
 #define SUNXI_USB0_BASE0x01c1a000
 #define SUNXI_USB1_BASE0x01c1b000
diff --git a/arch/arm/mach-sunxi/usb_phy.c b/arch/arm/mach-sunxi/usb_phy.c
index bd1bbee..278587b 100644
--- a/arch/arm/mach-sunxi/usb_phy.c
+++ b/arch/arm/mach-sunxi/usb_phy.c
@@ -146,12 +146,13 @@ __maybe_unused static void usb_phy_write(struct 
sunxi_usb_phy *phy, int addr,
}
 }

-#if defined CONFIG_MACH_SUN8I_H3
+#if defined(CONFIG_MACH_SUN8I_H3) || defined(CONFIG_MACH_SUN50I)
 static void sunxi_usb_phy_config(struct sunxi_usb_phy *phy)
 {
+#if defined CONFIG_MACH_SUN8I_H3
if (phy->id == 0)
clrbits_le32(SUNXI_USBPHY_BASE + REG_PHY_UNK_H3, 0x01);
-
+#endif
clrbits_le32(phy->base + REG_PMU_UNK_H3, 0x02);
 }

Re: [U-Boot] [U-Boot, 1/2] drivers: USB: OHCI: allow compilation for 64-bit targets

[Hans de Goede]

Hi,

On 21-10-16 03:24, Andre Przywara wrote:

OHCI has a known limitation of allowing only 32-bit DMA buffer
addresses, so we have a lot of u32 variables around, which are assigned
to pointers and vice versa. This obviously creates issues with 64-bit
systems, so the compiler complains here and there.
To allow compilation for 64-bit boards which use only memory below 4GB
anyway (and to avoid more invasive fixes), adjust some casts and types
and assume that the EDs and TDs are all located in the lower 4GB.
This fixes compilation of the OHCI driver for the Pine64.

Signed-off-by: Andre Przywara <andre.przyw...@arm.com>


Patch looks good to me:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Regards,

Hans

p.s.

About the ohci_writel macro changes also giving the macro parameters
more sensible names, I believe it is fine to do this while at it and
that this does not need to be split out.



---
 drivers/usb/host/ohci-hcd.c   | 21 +++--
 drivers/usb/host/ohci-sunxi.c |  2 +-
 drivers/usb/host/ohci.h   | 11 +++
 3 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index ccbfc02..0f6d03e 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -682,7 +682,7 @@ static int ep_link(ohci_t *ohci, ed_t *edi)
ed->hwNextED = 0;
flush_dcache_ed(ed);
if (ohci->ed_controltail == NULL)
-   ohci_writel(ed, >regs->ed_controlhead);
+   ohci_writel((uintptr_t)ed, >regs->ed_controlhead);
else
ohci->ed_controltail->hwNextED =
   m32_swap((unsigned long)ed);
@@ -700,7 +700,7 @@ static int ep_link(ohci_t *ohci, ed_t *edi)
ed->hwNextED = 0;
flush_dcache_ed(ed);
if (ohci->ed_bulktail == NULL)
-   ohci_writel(ed, >regs->ed_bulkhead);
+   ohci_writel((uintptr_t)ed, >regs->ed_bulkhead);
else
ohci->ed_bulktail->hwNextED =
   m32_swap((unsigned long)ed);
@@ -753,7 +753,7 @@ static void periodic_unlink(struct ohci *ohci, volatile 
struct ed *ed,

/* ED might have been unlinked through another path */
while (*ed_p != 0) {
-   if (((struct ed *)
+   if (((struct ed *)(uintptr_t)
m32_swap((unsigned long)ed_p)) == ed) {
*ed_p = ed->hwNextED;
aligned_ed_p = (unsigned long)ed_p;
@@ -762,7 +762,7 @@ static void periodic_unlink(struct ohci *ohci, volatile 
struct ed *ed,
aligned_ed_p + ARCH_DMA_MINALIGN);
break;
}
-   ed_p = &(((struct ed *)
+   ed_p = &(((struct ed *)(uintptr_t)
 m32_swap((unsigned long)ed_p))->hwNextED);
}
}
@@ -798,7 +798,7 @@ static int ep_unlink(ohci_t *ohci, ed_t *edi)
if (ohci->ed_controltail == ed) {
ohci->ed_controltail = ed->ed_prev;
} else {
-   ((ed_t *)m32_swap(
+   ((ed_t *)(uintptr_t)m32_swap(
*((__u32 *)>hwNextED)))->ed_prev = ed->ed_prev;
}
break;
@@ -819,7 +819,7 @@ static int ep_unlink(ohci_t *ohci, ed_t *edi)
if (ohci->ed_bulktail == ed) {
ohci->ed_bulktail = ed->ed_prev;
} else {
-   ((ed_t *)m32_swap(
+   ((ed_t *)(uintptr_t)m32_swap(
 *((__u32 *)>hwNextED)))->ed_prev = ed->ed_prev;
}
break;
@@ -914,12 +914,13 @@ static void td_fill(ohci_t *ohci, unsigned int info,

/* fill the old dummy TD */
td = urb_priv->td [index] =
-(td_t *)(m32_swap(urb_priv->ed->hwTailP) & ~0xf);
+(td_t *)(uintptr_t)
+(m32_swap(urb_priv->ed->hwTailP) & ~0xf);

td->ed = urb_priv->ed;
td->next_dl_td = NULL;
td->index = index;
-   td->data = (__u32)data;
+   td->data = (uintptr_t)data;
 #ifdef OHCI_FILL_TRACE
if (usb_pipebulk(urb_priv->pipe) && usb_pipeout(urb_priv->pipe)) {
for (i = 0; i < len; i++)
@@ -1099,7 +1100,7 @@ static void check_status(td_t *td_list)
  * we reverse the reversed done-list */
 static td_t *dl_reverse_done_list(ohci_t *ohci)
 {
-   __u32 td_list_hc;

Re: [U-Boot] [PATCH v1 1/1] ARM:SUNXI: Update DRAM clock for Olimex A20 boards

[Hans de Goede]

Hi,

On 27-10-16 12:33, Stefan Mavrodiev wrote:

Hi,

I've notice that you've reduced DRAM clock for Lime2 and Lime, but not for 
A20-SOM.

Is there any specific reason for this?


Sorry, as I mentioned I had received a patch similar to
yours and I had already merged that patch. I did not
notice that your patch also modified the A20-SOM
where as the patch I merged did not.

I've added the A20-SOM part of your patch (with you
as the author) to my tree now and will include it
in my next pull-req.

Regards,

Hans





Regards,

Stefan Mavrodiev

Olimex LDT


On 10/11/2016 12:38 PM, Hans de Goede wrote:

Hi,

On 10/11/2016 10:44 AM, Stefan Mavrodiev wrote:

Originally dram clock was set to 480MHz, but this behaves
unstable. To improve stability the clock is reduced to 384MHz

Signed-off-by: Stefan Mavrodiev <stefan.mavrod...@gmail.com>


The exact same change is already in u-boot-sunxi/next, and I've already
send out a pullreq to get this merged.

Regards,

Hans


---
 configs/A20-OLinuXino-Lime2_defconfig | 2 +-
 configs/A20-OLinuXino-Lime_defconfig  | 2 +-
 configs/A20-Olimex-SOM-EVB_defconfig  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index 5688622..4751fe0 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=480
+CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_USB0_VBUS_PIN="PC17"
 CONFIG_USB0_VBUS_DET="PH5"
diff --git a/configs/A20-OLinuXino-Lime_defconfig 
b/configs/A20-OLinuXino-Lime_defconfig
index c4f6e1a..024dc2d 100644
--- a/configs/A20-OLinuXino-Lime_defconfig
+++ b/configs/A20-OLinuXino-Lime_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=480
+CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/configs/A20-Olimex-SOM-EVB_defconfig 
b/configs/A20-Olimex-SOM-EVB_defconfig
index 7a14a7b..3f4e90d 100644
--- a/configs/A20-Olimex-SOM-EVB_defconfig
+++ b/configs/A20-Olimex-SOM-EVB_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=480
+CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_MMC3_CD_PIN="PH0"
 CONFIG_MMC3_PINS="PH"




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tools: add mksunxiboot to tools-all target

[Hans de Goede]

Hi,

On 29-10-16 12:23, Stefan Brüns wrote:

mksunxiboot is useful outside of u-boot, it is e.g. used by sunxi-tools.

Signed-off-by: Stefan Brüns 



Thank you I've applied this to my tree and will
include it in my next pull-req.

Regards,

Hans





---
 tools/Makefile  | 1 +
 tools/mksunxiboot.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/Makefile b/tools/Makefile
index e6f7993..8e6dede 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -13,6 +13,7 @@ CONFIG_CMD_NET = y
 CONFIG_XWAY_SWAP_BYTES = y
 CONFIG_NETCONSOLE = y
 CONFIG_SHA1_CHECK_UB_IMG = y
+CONFIG_SUNXI = y
 endif

 subdir-$(HOST_TOOLS_ALL) += easylogo
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 9c1c5b7..0f0b003 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -15,7 +15,7 @@
 #include 
 #include 
 #include 
-#include "asm/arch/spl.h"
+#include "../arch/arm/include/asm/arch-sunxi/spl.h"

 #define STAMP_VALUE 0x5F0A6C39



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] [PATCH] arm: dts: Pine64: add Ethernet alias

[Hans de Goede]

Hi,

On 21-10-16 02:11, Andre Przywara wrote:

The sun8i-emac driver works fine with the A64 Ethernet IP, but we are
missing an alias entry to trigger the driver instantiation by U-Boot.
Add the line to point U-Boot to the Ethernet DT node.
This enables TFTP boot on the Pine64.

Signed-off-by: Andre Przywara 



Thank you I've applied this to my tree and will
include it in my next pull-req.

Regards,

Hans





---
 arch/arm/dts/sun50i-a64-pine64-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi 
b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
index d5a7249..c0fde44 100644
--- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
+++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
@@ -46,6 +46,7 @@

aliases {
serial0 = 
+   ethernet0 = 
};

soc {


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] ARM: sunxi: remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT defines

[Hans de Goede]

Hi,

On 13-10-16 17:40, Masahiro Yamada wrote:

ARCH_SUNXI selects DM_USB, where CONFIG_USB_MAX_CONTROLLER_COUNT
is not used.

Signed-off-by: Masahiro Yamada 


Thank you I've applied this to my tree and will
include it in my next pull-req.

Regards,

Hans



---

 include/configs/sun4i.h | 1 -
 include/configs/sun5i.h | 1 -
 include/configs/sun6i.h | 1 -
 include/configs/sun7i.h | 1 -
 include/configs/sun8i.h | 1 -
 5 files changed, 5 deletions(-)

diff --git a/include/configs/sun4i.h b/include/configs/sun4i.h
index ea079eb..3dfd95a 100644
--- a/include/configs/sun4i.h
+++ b/include/configs/sun4i.h
@@ -14,7 +14,6 @@

 #ifdef CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_SUNXI
-#define CONFIG_USB_MAX_CONTROLLER_COUNT2
 #endif

 #define CONFIG_SUNXI_USB_PHYS  3
diff --git a/include/configs/sun5i.h b/include/configs/sun5i.h
index d257659..ec8f319 100644
--- a/include/configs/sun5i.h
+++ b/include/configs/sun5i.h
@@ -14,7 +14,6 @@

 #ifdef CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_SUNXI
-#define CONFIG_USB_MAX_CONTROLLER_COUNT1
 #endif

 #define CONFIG_SUNXI_USB_PHYS  2
diff --git a/include/configs/sun6i.h b/include/configs/sun6i.h
index 67a26c2..6c1eca4 100644
--- a/include/configs/sun6i.h
+++ b/include/configs/sun6i.h
@@ -17,7 +17,6 @@

 #ifdef CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_SUNXI
-#define CONFIG_USB_MAX_CONTROLLER_COUNT2
 #endif

 #define CONFIG_SUNXI_USB_PHYS  3
diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h
index d8e6e20..5455901 100644
--- a/include/configs/sun7i.h
+++ b/include/configs/sun7i.h
@@ -15,7 +15,6 @@

 #ifdef CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_SUNXI
-#define CONFIG_USB_MAX_CONTROLLER_COUNT2
 #endif

 #define CONFIG_SUNXI_USB_PHYS  3
diff --git a/include/configs/sun8i.h b/include/configs/sun8i.h
index 011d70f..a4c3fb6 100644
--- a/include/configs/sun8i.h
+++ b/include/configs/sun8i.h
@@ -15,7 +15,6 @@

 #ifdef CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_SUNXI
-#define CONFIG_USB_MAX_CONTROLLER_COUNT1
 #endif

 #ifdef CONFIG_MACH_SUN8I_H3


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Rename CONFIG_SUNXI to CONFIG_ARCH_SUNXI

[Hans de Goede]

Hi,

On 13-10-16 10:49, Jagan Teki wrote:

CONFIG_SUNXI -> CONFIG_ARCH_SUNXI
and removed CONFIG_SUNIX from config_whitelist.txt

Cc: Simon Glass <s...@chromium.org>
Cc: Ian Campbell <i...@hellion.org.uk>
Cc: Hans de Goede <hdego...@redhat.com>
Signed-off-by: Jagan Teki <jt...@openedev.com>


Thank you I've applied this to my tree and will
include it in my next pull-req.

Regards,

Hans



---
 Makefile   | 2 +-
 arch/arm/cpu/armv7/Makefile| 2 +-
 drivers/i2c/mvtwsi.c   | 6 +++---
 include/configs/sunxi-common.h | 1 -
 scripts/Makefile.spl   | 2 +-
 scripts/config_whitelist.txt   | 1 -
 tools/Makefile | 2 +-
 7 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/Makefile b/Makefile
index dcba7db..e88c8b3 100644
--- a/Makefile
+++ b/Makefile
@@ -1096,7 +1096,7 @@ u-boot-x86-16bit.bin: u-boot FORCE
$(call if_changed,objcopy)
 endif

-ifneq ($(CONFIG_SUNXI),)
+ifneq ($(CONFIG_ARCH_SUNXI),)
 OBJCOPYFLAGS_u-boot-sunxi-with-spl.bin = -I binary -O binary \
   --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff
 u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.img FORCE
diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index 0d4bfbc..d182200 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -12,7 +12,7 @@ obj-y += cache_v7.o cache_v7_asm.o
 obj-y  += cpu.o cp15.o
 obj-y  += syslib.o

-ifneq 
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_MX7)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_SUNXI)$(CONFIG_ARCH_SOCFPGA),)
+ifneq 
($(CONFIG_AM43XX)$(CONFIG_AM33XX)$(CONFIG_OMAP44XX)$(CONFIG_OMAP54XX)$(CONFIG_TEGRA)$(CONFIG_MX6)$(CONFIG_MX7)$(CONFIG_TI81XX)$(CONFIG_AT91FAMILY)$(CONFIG_ARCH_SUNXI)$(CONFIG_ARCH_SOCFPGA),)
 ifneq ($(CONFIG_SKIP_LOWLEVEL_INIT),y)
 obj-y  += lowlevel_init.o
 endif
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 60c8ea1..cea3da0 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -29,7 +29,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #include 
 #elif (defined(CONFIG_KIRKWOOD) || defined(CONFIG_ARCH_MVEBU))
 #include 
-#elif defined(CONFIG_SUNXI)
+#elif defined(CONFIG_ARCH_SUNXI)
 #include 
 #else
 #error Driver mvtwsi not supported by SoC or board
@@ -40,7 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
  * TWSI register structure
  */

-#ifdef CONFIG_SUNXI
+#ifdef CONFIG_ARCH_SUNXI

 struct  mvtwsi_registers {
u32 slave_address;
@@ -399,7 +399,7 @@ static int twsi_stop(struct mvtwsi_registers *twsi, uint 
tick)
  */
 static uint twsi_calc_freq(const int n, const int m)
 {
-#ifdef CONFIG_SUNXI
+#ifdef CONFIG_ARCH_SUNXI
return CONFIG_SYS_TCLK / (10 * (m + 1) * (1 << n));
 #else
return CONFIG_SYS_TCLK / (10 * (m + 1) * (2 << n));
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index d261fb3..a6ca80a 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -35,7 +35,6 @@
 /*
  * High Level Configuration Options
  */
-#define CONFIG_SUNXI   /* sunxi family */
 #ifdef CONFIG_SPL_BUILD
 #define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */
 #endif
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index e8cf9f3..e0b0117 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -166,7 +166,7 @@ ifdef CONFIG_ARCH_SOCFPGA
 ALL-y  += $(obj)/$(SPL_BIN).sfp
 endif

-ifdef CONFIG_SUNXI
+ifdef CONFIG_ARCH_SUNXI
 ALL-y  += $(obj)/sunxi-spl.bin
 endif

diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 3621c91..5dc2ed7 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -4372,7 +4372,6 @@ CONFIG_STV0991_HZ
 CONFIG_STV0991_HZ_CLOCK
 CONFIG_ST_SMI
 CONFIG_SUN4
-CONFIG_SUNXI
 CONFIG_SUNXI_AHCI
 CONFIG_SUNXI_EMAC
 CONFIG_SUNXI_GMAC
diff --git a/tools/Makefile b/tools/Makefile
index e6f7993..556f397 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -169,7 +169,7 @@ hostprogs-$(CONFIG_MX23) += mxsboot
 hostprogs-$(CONFIG_MX28) += mxsboot
 HOSTCFLAGS_mxsboot.o := -pedantic

-hostprogs-$(CONFIG_SUNXI) += mksunxiboot
+hostprogs-$(CONFIG_ARCH_SUNXI) += mksunxiboot

 hostprogs-$(CONFIG_NETCONSOLE) += ncb
 hostprogs-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/11] sunxi: Add full SPL support for sun9i (A80)

[Hans de Goede]

Hi,

On 29-10-16 03:16, Chen-Yu Tsai wrote:

On Sat, Oct 29, 2016 at 1:30 AM, Hans de Goede <hdego...@redhat.com> wrote:

Hi Chen-Yu,

On 28-10-16 12:21, Chen-Yu Tsai wrote:


Hi everyone,

This series adds full SPL with DRAM initialization for sun9i (A80).
The bulk of the work was done by the people at Theobroma Systems.
Their work can be found here:

https://git.theobroma-systems.com/armadillo-u-boot.git/

I picked the essential patches and cleaned them up a bit more,
and added commit messages if they were missing.

As the DRAM bits are essentially a code dump with some cleanups and
some bits disabled, expect many warnings. Checkpatch is still not
happy with it.

I've tested the series on both my A80 boards, which I've added
defconfigs for in the last 2 patches. My A80 Optimus does not
boot from micro SD, so I'm still FEL booting that one. But my
Cubieboard 4 is now standalone.

As usual, please have a look, test if possible.



Awesome, thanks for doing this and it was good to have
some face2face time at ELCE.

I've merged this into my personal sunxi-wip u-boot branch,
I've made 2 changes:

1) in : ¨sunxi: DRAM initialisation for sun9i" there are a
lot of #if 0 #endif blocks, most of these document some features
which we may want to enable in the future, but a few were just
dead weight IMHO, so I've pruned a few


Thanks. I suppose some of the testing and verbose debug calls
aren't needed. Most of the #if 0 blocks within data structures
were C99 // comments that I fixed up to get checkpatch happy.

About the features, I was already half way through the clock
code cleanup when Maxime pointed me to Theobroma's repository,
so I could add and test sigma delta modulation for PLL DDR.


If you want to, I would be fine with adding that, but IIRC
we are not doing that on a number of other SoC generations
either, not sure what this would bring it us. So it is up to
you.


For the other types of DRAM we could clean it up, but there's
really no hardware to test it on.


I would not bother with this until someone with the relevant
hardware comes forward.


2) in : "sunxi: Add support for A80 Optimus board", we already
have a configs/Merrii_A80_Optimus_defconfig, so I've made the patch
update that instead of adding a new defconfig


Cool. I didn't notice.


I have not tested this yet, I will do tomorrow, assuming it
works for me too I will include it in my next pull-req (*) and
try to get it included in the 2016.11 release, yes the merge
window has closed, but the changes here are very isolated so
I will try and see what Tom says :)


Do you need me to send a v2 addressing review comments?


No need, I've fixed everything up in my own tree.

Regards,

Hans





Thanks
ChenYu



Regards,

Hans


*) Which I hope to send out this weekend







Regards
ChenYu


Chen-Yu Tsai (5):
  sunxi: Set default CPU clock rate to 1008 MHz for sun9i (A80)
  sunxi: Add support for SID e-fuses on sun9i
  sunxi: Add default zq value for sun9i (A80)
  sunxi: Add support for A80 Optimus board
  sunxi: Add support for Cubieboard4

Philipp Tomsich (6):
  sunxi: DRAM initialisation for sun9i
  sunxi: add gtbus-initialisation for sun9i
  sunxi: Enable SMP mode for the boot CPU on sun9i (A80)
  sunxi: add initial clock setup for sun9i for SPL
  sunxi: enable SPL for sun9i
  sunxi: add MMC pinmux setup for SDC2 on sun9i

 arch/arm/include/asm/arch-sunxi/clock_sun9i.h |  116 ++-
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h   |   10 +
 arch/arm/include/asm/arch-sunxi/dram.h|2 +
 arch/arm/include/asm/arch-sunxi/dram_sun9i.h  |  275 +++
 arch/arm/include/asm/arch-sunxi/gtbus.h   |   21 +
 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h |   89 +++
 arch/arm/mach-sunxi/Makefile  |2 +
 arch/arm/mach-sunxi/board.c   |3 +-
 arch/arm/mach-sunxi/clock.c   |6 +
 arch/arm/mach-sunxi/clock_sun9i.c |  146 +++-
 arch/arm/mach-sunxi/dram_sun9i.c  | 1059
+
 arch/arm/mach-sunxi/gtbus_sun9i.c |   48 ++
 board/sunxi/Kconfig   |   10 +-
 board/sunxi/MAINTAINERS   |   10 +
 board/sunxi/board.c   |7 +
 configs/A80_Optimus_defconfig |   18 +
 configs/Cubieboard4_defconfig |   18 +
 17 files changed, 1818 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun9i.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/gtbus.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h
 create mode 100644 arch/arm/mach-sunxi/dram_sun9i.c
 create mode 100644 arch/arm/mach-sunxi/gtbus_sun9i.c
 create mode 100644 configs/A80_Optimus_defconfig
 create mode 100644 configs/Cubieboard4_defconfig




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/11] sunxi: Add full SPL support for sun9i (A80)

[Hans de Goede]

Hi,

On 28-10-16 19:30, Hans de Goede wrote:

Hi Chen-Yu,

On 28-10-16 12:21, Chen-Yu Tsai wrote:

Hi everyone,

This series adds full SPL with DRAM initialization for sun9i (A80).
The bulk of the work was done by the people at Theobroma Systems.
Their work can be found here:

https://git.theobroma-systems.com/armadillo-u-boot.git/

I picked the essential patches and cleaned them up a bit more,
and added commit messages if they were missing.

As the DRAM bits are essentially a code dump with some cleanups and
some bits disabled, expect many warnings. Checkpatch is still not
happy with it.

I've tested the series on both my A80 boards, which I've added
defconfigs for in the last 2 patches. My A80 Optimus does not
boot from micro SD, so I'm still FEL booting that one. But my
Cubieboard 4 is now standalone.

As usual, please have a look, test if possible.


Awesome, thanks for doing this and it was good to have
some face2face time at ELCE.

I've merged this into my personal sunxi-wip u-boot branch,
I've made 2 changes:

1) in : ¨sunxi: DRAM initialisation for sun9i" there are a
lot of #if 0 #endif blocks, most of these document some features
which we may want to enable in the future, but a few were just
dead weight IMHO, so I've pruned a few

2) in : "sunxi: Add support for A80 Optimus board", we already
have a configs/Merrii_A80_Optimus_defconfig, so I've made the patch
update that instead of adding a new defconfig

I have not tested this yet, I will do tomorrow, assuming it
works for me too I will include it in my next pull-req (*)


Ok, just finished testing, u-boot seems to work well. I do
seem to have one kernel issue (with the last 4.8 based
sunxi-next kernel, I still need to upgrade that) :

[1.137105] Division by zero in kernel.
[1.140988] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0+ #475
[1.147089] Hardware name: Allwinner sun9i Family
[1.151830] [] (unwind_backtrace) from [] 
(show_stack+0x18/0x1c)
[1.159596] [] (show_stack) from [] 
(dump_stack+0x80/0x9c)
[1.166839] [] (dump_stack) from [] (Ldiv0+0x8/0x10)
[1.173558] [] (Ldiv0) from [] 
(sun4i_a10_get_mod0_factors+0x2c/0x8c)
[1.181758] [] (sun4i_a10_get_mod0_factors) from [] 
(clk_factors_determine_rate+0xb8/0xf8)
[1.191781] [] (clk_factors_determine_rate) from [] 
(clk_composite_determine_rate+0x58/0x1cc)
[1.202062] [] (clk_composite_determine_rate) from [] 
(clk_calc_new_rates+0xa0/0x240)
[1.211647] [] (clk_calc_new_rates) from [] 
(clk_core_set_rate_nolock+0x4c/0xbc)
[1.220798] [] (clk_core_set_rate_nolock) from [] 
(clk_set_rate+0x28/0x38)
[1.229432] [] (clk_set_rate) from [] 
(sunxi_ir_probe+0xfc/0x480)
[1.420454] [] (sunxi_ir_probe) from [] (platform_drv_pro
be+0x58/0xa4)

...

And it fails to find any mmc controllers, but that might be related to
the above oops (maybe it stops probing after that due to a stuck lock).

Anyways the u-boot side looks good. One issue I see is that your
optimus has an emmc, where as mine has a nand. We may want to
gave 2 optimus defconfigs for this once we've nand support.

Regards,

Hans



and try to get it included in the 2016.11 release, yes the merge
window has closed, but the changes here are very isolated so
I will try and see what Tom says :)

Regards,

Hans


*) Which I hope to send out this weekend






Regards
ChenYu


Chen-Yu Tsai (5):
  sunxi: Set default CPU clock rate to 1008 MHz for sun9i (A80)
  sunxi: Add support for SID e-fuses on sun9i
  sunxi: Add default zq value for sun9i (A80)
  sunxi: Add support for A80 Optimus board
  sunxi: Add support for Cubieboard4

Philipp Tomsich (6):
  sunxi: DRAM initialisation for sun9i
  sunxi: add gtbus-initialisation for sun9i
  sunxi: Enable SMP mode for the boot CPU on sun9i (A80)
  sunxi: add initial clock setup for sun9i for SPL
  sunxi: enable SPL for sun9i
  sunxi: add MMC pinmux setup for SDC2 on sun9i

 arch/arm/include/asm/arch-sunxi/clock_sun9i.h |  116 ++-
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h   |   10 +
 arch/arm/include/asm/arch-sunxi/dram.h|2 +
 arch/arm/include/asm/arch-sunxi/dram_sun9i.h  |  275 +++
 arch/arm/include/asm/arch-sunxi/gtbus.h   |   21 +
 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h |   89 +++
 arch/arm/mach-sunxi/Makefile  |2 +
 arch/arm/mach-sunxi/board.c   |3 +-
 arch/arm/mach-sunxi/clock.c   |6 +
 arch/arm/mach-sunxi/clock_sun9i.c |  146 +++-
 arch/arm/mach-sunxi/dram_sun9i.c  | 1059 +
 arch/arm/mach-sunxi/gtbus_sun9i.c |   48 ++
 board/sunxi/Kconfig   |   10 +-
 board/sunxi/MAINTAINERS   |   10 +
 board/sunxi/board.c   |7 +
 configs/A80_Optimus_defconfig |   18 +
 configs/Cubieboard4_defconfig |   18 +
 17 files changed, 1818 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm/include

Re: [U-Boot] [PATCH 02/11] sunxi: add gtbus-initialisation for sun9i

[Hans de Goede]

Hi,

On 29-10-16 13:08, Chen-Yu Tsai wrote:

On Sat, Oct 29, 2016 at 2:45 AM, Jagan Teki  wrote:

On Fri, Oct 28, 2016 at 3:51 PM, Chen-Yu Tsai  wrote:

From: Philipp Tomsich 

On sun9i, the GTBUS manages transaction priority and bandwidth
for multiple read ports when accessing DRAM. The initialisation
mirrors the settings from Allwinner's boot0 for now, even though
this may not be optimal for all applications (e.g. headless
systems might want to give priority to IO modules).

Adding a common callout to gtbus_init() from the SPL clock init
with a weakly defined implementation in sunxi/clock.c to fallback
to for platforms that don't require this.

[w...@csie.org: Moved gtbus_sun9i.c to arch/arm/mach-sunxi/; style cleanup]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h   |  2 +
 arch/arm/include/asm/arch-sunxi/gtbus.h   | 21 +++
 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h | 89 +++
 arch/arm/mach-sunxi/Makefile  |  1 +
 arch/arm/mach-sunxi/clock.c   |  6 ++
 arch/arm/mach-sunxi/gtbus_sun9i.c | 48 +++
 6 files changed, 167 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-sunxi/gtbus.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h
 create mode 100644 arch/arm/mach-sunxi/gtbus_sun9i.c

diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
index acbc94f4c3b8..ba18a0f551ad 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
@@ -23,6 +23,8 @@
 #define SUNXI_NFC_BASE (REGS_AHB0_BASE + 0x3000)
 #define SUNXI_TSC_BASE (REGS_AHB0_BASE + 0x4000)

+#define SUNXI_GTBUS_BASE   (REGS_AHB0_BASE + 0x9000)
+
 #define SUNXI_MMC0_BASE(REGS_AHB0_BASE + 0x0f000)
 #define SUNXI_MMC1_BASE(REGS_AHB0_BASE + 0x1)
 #define SUNXI_MMC2_BASE(REGS_AHB0_BASE + 0x11000)
diff --git a/arch/arm/include/asm/arch-sunxi/gtbus.h 
b/arch/arm/include/asm/arch-sunxi/gtbus.h
new file mode 100644
index ..b8308d513545
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/gtbus.h
@@ -0,0 +1,21 @@
+/*
+ * GTBUS initialisation
+ *
+ * (C) Copyright 2016 Theobroma Systems Design und Consulting GmbH
+ *Philipp Tomsich 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_GTBUS_H
+#define _SUNXI_GTBUS_H
+
+#if defined(CONFIG_MACH_SUN9I)
+#include 
+#endif
+
+#ifndef __ASSEMBLY__
+void gtbus_init(void);
+#endif
+
+#endif
diff --git a/arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h
new file mode 100644
index ..91bc2bdb5103
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h
@@ -0,0 +1,89 @@
+/*
+ * GTBUS initialisation for sun9i
+ *
+ * (C) Copyright 2016 Theobroma Systems Design und Consulting GmbH
+ *Philipp Tomsich 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_GTBUS_SUN9I_H
+#define _SUNXI_GTBUS_SUN9I_H
+
+#include 
+
+struct sunxi_gtbus_reg {
+   u32 mst_cfg[36];   /* 0x000 */
+   u8  reserved1[0x70];   /* 0x090 */
+   u32 bw_wdw_cfg;/* 0x100 */
+   u32 mst_read_prio_cfg[2];  /* 0x104 */
+   u32 lvl2_mst_cfg;  /* 0x10c */
+   u32 sw_clk_on; /* 0x110 */
+   u32 sw_clk_off;/* 0x114 */
+   u32 pmu_mst_en;/* 0x118 */
+   u32 pmu_cfg;   /* 0x11c */
+   u32 pmu_cnt[19];   /* 0x120 */
+   u32 reserved2[0x94];   /* 0x16c */
+   u32 cci400_config[3];  /* 0x200 */
+   u32 cci400_status[2];  /* 0x20c */
+};
+
+/* for register GT_MST_CFG_REG(n) */
+#define GT_ENABLE_REQ   (1<<31) /* clock on */
+#define GT_DISABLE_REQ  (1<<30) /* clock off */
+#define GT_QOS_SHIFT28
+#define GT_THD1_SHIFT   16
+#define GT_REQN_MAX 0xf /* max number master requests in one 
cycle */
+#define GT_REQN_SHIFT   12
+#define GT_THD0_SHIFT   0
+
+#define GT_QOS_MAX  0x3
+#define GT_THD_MAX  0xfff
+#define GT_BW_WDW_MAX   0x
+
+/* mst_read_prio_cfg */
+#define GT_PRIO_LOW 0
+#define GT_PRIO_HIGH1
+
+/* GTBUS port ids */
+#define GT_PORT_CPUM1   0
+#define GT_PORT_CPUM2   1
+#define GT_PORT_SATA2
+#defineGT_PORT_USB33
+#defineGT_PORT_FE0 4
+#defineGT_PORT_BE1 5
+#defineGT_PORT_BE2 6
+#defineGT_PORT_IEP07
+#defineGT_PORT_FE1 8
+#defineGT_PORT_BE0 9
+#defineGT_PORT_FE2 10
+#defineGT_PORT_IEP111
+#defineGT_PORT_VED 12
+#define 

Re: [U-Boot] [PATCH 01/11] sunxi: DRAM initialisation for sun9i

[Hans de Goede]

Hi,

On 28-10-16 20:54, Jagan Teki wrote:

On Fri, Oct 28, 2016 at 3:51 PM, Chen-Yu Tsai  wrote:

From: Philipp Tomsich 

This adds DRAM initialisation code for sun9i, which calculates the
appropriate timings based on timing information for the supplied
DDR3 bin and the clock speeds used.

With this DRAM setup, we have verified DDR3 clocks of up to 792MHz
(i.e. DDR3-1600) on the A80-Q7 using a dual-channel configuration.

[w...@csie.org: Moved dram_sun9i.c to arch/arm/mach-sunxi/; style cleanup]
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/include/asm/arch-sunxi/clock_sun9i.h |   34 +-
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h   |6 +
 arch/arm/include/asm/arch-sunxi/dram.h|2 +
 arch/arm/include/asm/arch-sunxi/dram_sun9i.h  |  275 +++
 arch/arm/mach-sunxi/Makefile  |1 +
 arch/arm/mach-sunxi/dram_sun9i.c  | 1059 +
 board/sunxi/Kconfig   |6 +-
 7 files changed, 1368 insertions(+), 15 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun9i.h
 create mode 100644 arch/arm/mach-sunxi/dram_sun9i.c


Checkpatch:
total: 45 errors, 77 warnings, 42 checks, 1464 lines checked


Ugh, ok I've fixed this up locally in my tree, Chen-Yu next time
please remember to run your patches through check-patch.

Jagan, thanks for the review I've addressed all your comments
in my tree.

Regards,

Hans







diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun9i.h 
b/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
index a61934fb3661..82881ff8bdaf 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun9i.h
@@ -37,57 +37,61 @@ struct sunxi_ccm_reg {
u8 reserved3[0x04]; /* 0x7c */
u32 ats_cfg;/* 0x80 ats clock configuration */
u32 trace_cfg;  /* 0x84 trace clock configuration */
-   u8 reserved4[0xf8]; /* 0x88 */
+   u8 reserved4[0x14]; /* 0x88 */
+   u32 pll_stable_status;  /* 0x9c */
+   u8 reserved5[0xe0]; /* 0xa0 */
u32 clk_output_a;   /* 0x180 clk_output_a */
u32 clk_output_b;   /* 0x184 clk_output_a */
-   u8 reserved5[0x278];/* 0x188 */
+   u8 reserved6[0x278];/* 0x188 */

u32 nand0_clk_cfg;  /* 0x400 nand0 clock configuration0 */
u32 nand0_clk_cfg1; /* 0x404 nand1 clock configuration */
-   u8 reserved6[0x08]; /* 0x408 */
+   u8 reserved7[0x08]; /* 0x408 */
u32 sd0_clk_cfg;/* 0x410 sd0 clock configuration */
u32 sd1_clk_cfg;/* 0x414 sd1 clock configuration */
u32 sd2_clk_cfg;/* 0x418 sd2 clock configuration */
u32 sd3_clk_cfg;/* 0x41c sd3 clock configuration */
-   u8 reserved7[0x08]; /* 0x420 */
+   u8 reserved8[0x08]; /* 0x420 */
u32 ts_clk_cfg; /* 0x428 transport stream clock cfg */
u32 ss_clk_cfg; /* 0x42c security system clock cfg */
u32 spi0_clk_cfg;   /* 0x430 spi0 clock configuration */
u32 spi1_clk_cfg;   /* 0x434 spi1 clock configuration */
u32 spi2_clk_cfg;   /* 0x438 spi2 clock configuration */
u32 spi3_clk_cfg;   /* 0x43c spi3 clock configuration */
-   u8 reserved8[0x50]; /* 0x440 */
+   u8 reserved9[0x44]; /* 0x440 */
+   u32 dram_clk_cfg;   /* 0x484 DRAM (controller) clock configuration 
*/
+   u8 reserved10[0x8]; /* 0x488 */
u32 de_clk_cfg; /* 0x490 display engine clock configuration */
-   u8 reserved9[0x04]; /* 0x494 */
+   u8 reserved11[0x04];/* 0x494 */
u32 mp_clk_cfg; /* 0x498 mp clock configuration */
u32 lcd0_clk_cfg;   /* 0x49c LCD0 module clock */
u32 lcd1_clk_cfg;   /* 0x4a0 LCD1 module clock */
-   u8 reserved10[0x1c];/* 0x4a4 */
+   u8 reserved12[0x1c];/* 0x4a4 */
u32 csi_isp_clk_cfg;/* 0x4c0 CSI ISP module clock */
u32 csi0_clk_cfg;   /* 0x4c4 CSI0 module clock */
u32 csi1_clk_cfg;   /* 0x4c8 CSI1 module clock */
u32 fd_clk_cfg; /* 0x4cc FD module clock */
u32 ve_clk_cfg; /* 0x4d0 VE module clock */
u32 avs_clk_cfg;/* 0x4d4 AVS module clock */
-   u8 reserved11[0x18];/* 0x4d8 */
+   u8 reserved13[0x18];/* 0x4d8 */
u32 gpu_core_clk_cfg;   /* 0x4f0 GPU core clock config */
u32 gpu_mem_clk_cfg;/* 0x4f4 GPU memory clock config */
u32 gpu_axi_clk_cfg;/* 0x4f8 GPU AXI clock config */
-   u8 reserved12[0x10];/* 0x4fc */
+   u8 reserved14[0x10];/* 0x4fc */
u32 gp_adc_clk_cfg; /* 0x50c General Purpose ADC clk config */
-   u8 reserved13[0x70];/* 0x510 */
+   u8 reserved15[0x70];/* 0x510 */

u32 ahb_gate0;  /* 0x580 AHB0 Gating Register */
u32 

Re: [U-Boot] [PATCH 00/11] sunxi: Add full SPL support for sun9i (A80)

[Hans de Goede]

Hi Chen-Yu,

On 28-10-16 12:21, Chen-Yu Tsai wrote:

Hi everyone,

This series adds full SPL with DRAM initialization for sun9i (A80).
The bulk of the work was done by the people at Theobroma Systems.
Their work can be found here:

https://git.theobroma-systems.com/armadillo-u-boot.git/

I picked the essential patches and cleaned them up a bit more,
and added commit messages if they were missing.

As the DRAM bits are essentially a code dump with some cleanups and
some bits disabled, expect many warnings. Checkpatch is still not
happy with it.

I've tested the series on both my A80 boards, which I've added
defconfigs for in the last 2 patches. My A80 Optimus does not
boot from micro SD, so I'm still FEL booting that one. But my
Cubieboard 4 is now standalone.

As usual, please have a look, test if possible.


Awesome, thanks for doing this and it was good to have
some face2face time at ELCE.

I've merged this into my personal sunxi-wip u-boot branch,
I've made 2 changes:

1) in : ¨sunxi: DRAM initialisation for sun9i" there are a
lot of #if 0 #endif blocks, most of these document some features
which we may want to enable in the future, but a few were just
dead weight IMHO, so I've pruned a few

2) in : "sunxi: Add support for A80 Optimus board", we already
have a configs/Merrii_A80_Optimus_defconfig, so I've made the patch
update that instead of adding a new defconfig

I have not tested this yet, I will do tomorrow, assuming it
works for me too I will include it in my next pull-req (*) and
try to get it included in the 2016.11 release, yes the merge
window has closed, but the changes here are very isolated so
I will try and see what Tom says :)

Regards,

Hans


*) Which I hope to send out this weekend






Regards
ChenYu


Chen-Yu Tsai (5):
  sunxi: Set default CPU clock rate to 1008 MHz for sun9i (A80)
  sunxi: Add support for SID e-fuses on sun9i
  sunxi: Add default zq value for sun9i (A80)
  sunxi: Add support for A80 Optimus board
  sunxi: Add support for Cubieboard4

Philipp Tomsich (6):
  sunxi: DRAM initialisation for sun9i
  sunxi: add gtbus-initialisation for sun9i
  sunxi: Enable SMP mode for the boot CPU on sun9i (A80)
  sunxi: add initial clock setup for sun9i for SPL
  sunxi: enable SPL for sun9i
  sunxi: add MMC pinmux setup for SDC2 on sun9i

 arch/arm/include/asm/arch-sunxi/clock_sun9i.h |  116 ++-
 arch/arm/include/asm/arch-sunxi/cpu_sun9i.h   |   10 +
 arch/arm/include/asm/arch-sunxi/dram.h|2 +
 arch/arm/include/asm/arch-sunxi/dram_sun9i.h  |  275 +++
 arch/arm/include/asm/arch-sunxi/gtbus.h   |   21 +
 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h |   89 +++
 arch/arm/mach-sunxi/Makefile  |2 +
 arch/arm/mach-sunxi/board.c   |3 +-
 arch/arm/mach-sunxi/clock.c   |6 +
 arch/arm/mach-sunxi/clock_sun9i.c |  146 +++-
 arch/arm/mach-sunxi/dram_sun9i.c  | 1059 +
 arch/arm/mach-sunxi/gtbus_sun9i.c |   48 ++
 board/sunxi/Kconfig   |   10 +-
 board/sunxi/MAINTAINERS   |   10 +
 board/sunxi/board.c   |7 +
 configs/A80_Optimus_defconfig |   18 +
 configs/Cubieboard4_defconfig |   18 +
 17 files changed, 1818 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/dram_sun9i.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/gtbus.h
 create mode 100644 arch/arm/include/asm/arch-sunxi/gtbus_sun9i.h
 create mode 100644 arch/arm/mach-sunxi/dram_sun9i.c
 create mode 100644 arch/arm/mach-sunxi/gtbus_sun9i.c
 create mode 100644 configs/A80_Optimus_defconfig
 create mode 100644 configs/Cubieboard4_defconfig


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: Pine64: add Ethernet alias

[Hans de Goede]

Hi,

On 26-10-16 09:00, Jagan Teki wrote:

On Tue, Oct 25, 2016 at 3:59 AM, André Przywara <andre.przyw...@arm.com> wrote:

On 21/10/16 11:28, Hans de Goede wrote:

Hi,

On 21-10-16 12:06, Andre Przywara wrote:

Hi,

On 21/10/16 10:31, Jagan Teki wrote:

On Fri, Oct 21, 2016 at 5:41 AM, Andre Przywara
<andre.przyw...@arm.com> wrote:

The sun8i-emac driver works fine with the A64 Ethernet IP, but we are
missing an alias entry to trigger the driver instantiation by U-Boot.
Add the line to point U-Boot to the Ethernet DT node.
This enables TFTP boot on the Pine64.

Signed-off-by: Andre Przywara <andre.przyw...@arm.com>
---
 arch/arm/dts/sun50i-a64-pine64-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
index d5a7249..c0fde44 100644
--- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
+++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
@@ -46,6 +46,7 @@

aliases {
serial0 = 
+   ethernet0 = 


I think alias doesn’t require for probing emac, it will straight away
probed like


dm tree


eth [ + ] ethernet@01c3

Did you find any issue while detecting eth?


Yes, it just didn't work ;-) I don't have a board here, but can post the
error message later tonight.



Net:   phy interface7

Error: ethernet@01c3 address not set.
No ethernet found.



In fact I was wondering about that already, maybe it's worth
investigating this further.


So the reason is that CONFIG_NET_RANDOM_ETHADDR isn't defined, so
without the DT alias triggering the SID MAC generation there will be
_no_ MAC address at all, which makes the driver give up.
AFAIK on the A64 the MAC generation from the SID serial number works
just fine, so we should in any case add the alias.


I wondered how the alias related to MAC generation,


See the setup_environment() function in board/sunxi/board.c, we use
the alias-es to determine for which interface we need to generate
a random MAC and set ethaddr / eth1addr in the environment.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: dts: Pine64: add Ethernet alias

[Hans de Goede]

Hi,

On 21-10-16 12:06, Andre Przywara wrote:

Hi,

On 21/10/16 10:31, Jagan Teki wrote:

On Fri, Oct 21, 2016 at 5:41 AM, Andre Przywara  wrote:

The sun8i-emac driver works fine with the A64 Ethernet IP, but we are
missing an alias entry to trigger the driver instantiation by U-Boot.
Add the line to point U-Boot to the Ethernet DT node.
This enables TFTP boot on the Pine64.

Signed-off-by: Andre Przywara 
---
 arch/arm/dts/sun50i-a64-pine64-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/sun50i-a64-pine64-common.dtsi 
b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
index d5a7249..c0fde44 100644
--- a/arch/arm/dts/sun50i-a64-pine64-common.dtsi
+++ b/arch/arm/dts/sun50i-a64-pine64-common.dtsi
@@ -46,6 +46,7 @@

aliases {
serial0 = 
+   ethernet0 = 


I think alias doesn’t require for probing emac, it will straight away
probed like


dm tree


eth [ + ] ethernet@01c3

Did you find any issue while detecting eth?


Yes, it just didn't work ;-) I don't have a board here, but can post the
error message later tonight.
In fact I was wondering about that already, maybe it's worth
investigating this further.

But aside from that I think the MAC address calculation based on the SID
serial number does not get triggered without an alias, so we need this
line anyway.


Correct, the MAC address code relies on the alias.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v1 1/1] ARM:SUNXI: Update DRAM clock for Olimex A20 boards

[Hans de Goede]

Hi,

On 10/11/2016 10:44 AM, Stefan Mavrodiev wrote:

Originally dram clock was set to 480MHz, but this behaves
unstable. To improve stability the clock is reduced to 384MHz

Signed-off-by: Stefan Mavrodiev 


The exact same change is already in u-boot-sunxi/next, and I've already
send out a pullreq to get this merged.

Regards,

Hans


---
 configs/A20-OLinuXino-Lime2_defconfig | 2 +-
 configs/A20-OLinuXino-Lime_defconfig  | 2 +-
 configs/A20-Olimex-SOM-EVB_defconfig  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index 5688622..4751fe0 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=480
+CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_USB0_VBUS_PIN="PC17"
 CONFIG_USB0_VBUS_DET="PH5"
diff --git a/configs/A20-OLinuXino-Lime_defconfig 
b/configs/A20-OLinuXino-Lime_defconfig
index c4f6e1a..024dc2d 100644
--- a/configs/A20-OLinuXino-Lime_defconfig
+++ b/configs/A20-OLinuXino-Lime_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=480
+CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/configs/A20-Olimex-SOM-EVB_defconfig 
b/configs/A20-Olimex-SOM-EVB_defconfig
index 7a14a7b..3f4e90d 100644
--- a/configs/A20-Olimex-SOM-EVB_defconfig
+++ b/configs/A20-Olimex-SOM-EVB_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=480
+CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_MMC3_CD_PIN="PH0"
 CONFIG_MMC3_PINS="PH"


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-sunxi master

[Hans de Goede]

Hi Tom,

Here is a small pull-req for v2016.11, consisting
of 2 small DRAM handling bug-fixes.

The following changes since commit f5fd45ff64e28a73499548358e3d1ceda0de7daf:

  Merge branch 'master' of git://www.denx.de/git/u-boot-imx (2016-10-08 
09:33:37 -0400)

are available in the git repository at:

  http://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to 55cdcdaad3edb24779b76716d5cf9c36db2fed44:

  sunxi: OLinuXino Lime A20 boards: Use 384 MHz DRAM clock (2016-10-10 09:24:00 
+0200)


Jens Kuske (1):
  sunxi: Fix H3 DRAM impedance calibration on rev. A chips

Josh Marshall (1):
  sunxi: OLinuXino Lime A20 boards: Use 384 MHz DRAM clock

 arch/arm/mach-sunxi/dram_sun8i_h3.c   | 64 +++
 configs/A20-OLinuXino-Lime2_defconfig |  2 +-
 configs/A20-OLinuXino-Lime_defconfig  |  2 +-
 3 files changed, 45 insertions(+), 23 deletions(-)

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Patch for OLinuXino Lime boards: default DRAM settings

[Hans de Goede]

Hi,

On 30-09-16 07:19, Josh Marshall wrote:

We have a number of OlinuXino Lime2 boards (both NAND and eMMC versions)
which were experiencing sporadic hangs. After testing with some heavy
benchmarking and help from the Armbian forum, it was pinned down as the
DRAM settings for the board. The default is 480MHz, but this is unstable,
and even the build instructions from the vendor Olimex themselves say to
set the DRAM clock to 384. (See line 96 at:
https://github.com/OLIMEX/OLINUXINO/blob/master/SOFTWARE/A20/A20-build-3.4.103-release-2/BUILD_DESCRIPTION_A20_Olimex_kernel_3.4.103%2B_Jessie_rel_2.txt
)

I’ve attached a patch against master to change this default:


Thank you for the patch. I've applied this patch to my local
tree and it will be part of the pull-request I'm about to send
out.

Regards,

Hans




diff --git a/configs/A20-OLinuXino-Lime2_defconfig
b/configs/A20-OLinuXino-Lime2_defconfig
index 54343de..21c792a 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=480
+CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_USB0_VBUS_PIN="PC17"
 CONFIG_USB0_VBUS_DET="PH5"
diff --git a/configs/A20-OLinuXino-Lime_defconfig
b/configs/A20-OLinuXino-Lime_defconfig
index c4f6e1a..024dc2d 100644
--- a/configs/A20-OLinuXino-Lime_defconfig
+++ b/configs/A20-OLinuXino-Lime_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_MACH_SUN7I=y
-CONFIG_DRAM_CLK=480
+CONFIG_DRAM_CLK=384
 CONFIG_MMC0_CD_PIN="PH1"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olinuxino-lime"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Fix H3 DRAM impedance calibration on rev. A chips

[Hans de Goede]

Hi,

On 21-09-16 20:08, Jens Kuske wrote:

H3 seems to have a silicon bug breaking the impedance calibration.
This is currently worked around in software by multiple steps
combining the results to replace the wrong values.

Revision A chips need a different workaround, which is present in
the vendor bootloader too, but got overlooked in lack of
information and affected boards till now.
This commit adds a simplified version without correction factor,
which would be 1.00 for all known boards anyway.

Signed-off-by: Jens Kuske 


Thank you for the patch. I've applied this patch to my local
tree and it will be part of the pull-request I'm about to send
out.

Regards,

Hans





---

Hi,

This has been tested by an Armbian user:
http://forum.armbian.com/index.php/topic/872-beelink-x2-with-armbian-possible/?p=16061

It looks like only few boards have revision A chips, probably only
non-development boards, otherwise we would have found this earlier.
The idea that these are different chip revision is based on:
https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L341

Regards,
Jens

---
 arch/arm/mach-sunxi/dram_sun8i_h3.c | 64 +
 1 file changed, 43 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
b/arch/arm/mach-sunxi/dram_sun8i_h3.c
index 2020d75..b08b8e6 100644
--- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
+++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
@@ -217,35 +217,57 @@ static void mctl_zq_calibration(struct dram_para *para)
struct sunxi_mctl_ctl_reg * const mctl_ctl =
(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;

-   int i;
-   u16 zq_val[6];
-   u8 val;
+   if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
+   (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {
+   u32 reg_val;

-   writel(0x0a0a0a0a, _ctl->zqdr[2]);
-
-   for (i = 0; i < 6; i++) {
-   u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf;
-
-   writel((zq << 20) | (zq << 16) | (zq << 12) |
-   (zq << 8) | (zq << 4) | (zq << 0),
-   _ctl->zqcr);
+   clrsetbits_le32(_ctl->zqcr, 0x,
+   CONFIG_DRAM_ZQ & 0x);

writel(PIR_CLRSR, _ctl->pir);
mctl_phy_init(PIR_ZCAL);

-   zq_val[i] = readl(_ctl->zqdr[0]) & 0xff;
-   writel(REPEAT_BYTE(zq_val[i]), _ctl->zqdr[2]);
+   reg_val = readl(_ctl->zqdr[0]);
+   reg_val &= (0x1f << 16) | (0x1f << 0);
+   reg_val |= reg_val << 8;
+   writel(reg_val, _ctl->zqdr[0]);

-   writel(PIR_CLRSR, _ctl->pir);
-   mctl_phy_init(PIR_ZCAL);
+   reg_val = readl(_ctl->zqdr[1]);
+   reg_val &= (0x1f << 16) | (0x1f << 0);
+   reg_val |= reg_val << 8;
+   writel(reg_val, _ctl->zqdr[1]);
+   writel(reg_val, _ctl->zqdr[2]);
+   } else {
+   int i;
+   u16 zq_val[6];
+   u8 val;

-   val = readl(_ctl->zqdr[0]) >> 24;
-   zq_val[i] |= bin_to_mgray(mgray_to_bin(val) - 1) << 8;
-   }
+   writel(0x0a0a0a0a, _ctl->zqdr[2]);
+
+   for (i = 0; i < 6; i++) {
+   u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf;
+
+   writel((zq << 20) | (zq << 16) | (zq << 12) |
+   (zq << 8) | (zq << 4) | (zq << 0),
+   _ctl->zqcr);

-   writel((zq_val[1] << 16) | zq_val[0], _ctl->zqdr[0]);
-   writel((zq_val[3] << 16) | zq_val[2], _ctl->zqdr[1]);
-   writel((zq_val[5] << 16) | zq_val[4], _ctl->zqdr[2]);
+   writel(PIR_CLRSR, _ctl->pir);
+   mctl_phy_init(PIR_ZCAL);
+
+   zq_val[i] = readl(_ctl->zqdr[0]) & 0xff;
+   writel(REPEAT_BYTE(zq_val[i]), _ctl->zqdr[2]);
+
+   writel(PIR_CLRSR, _ctl->pir);
+   mctl_phy_init(PIR_ZCAL);
+
+   val = readl(_ctl->zqdr[0]) >> 24;
+   zq_val[i] |= bin_to_mgray(mgray_to_bin(val) - 1) << 8;
+   }
+
+   writel((zq_val[1] << 16) | zq_val[0], _ctl->zqdr[0]);
+   writel((zq_val[3] << 16) | zq_val[2], _ctl->zqdr[1]);
+   writel((zq_val[5] << 16) | zq_val[4], _ctl->zqdr[2]);
+   }
 }

 static void mctl_set_cr(struct dram_para *para)


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: sun7i: dts: add support for Sinovoip/Bananapi BPI-R1

[Hans de Goede]

Hi Stephen,

First of all sorry for not responding sooner, I know there
have been a few versions since this one. But AFAICT those
don't address the get the dt accepted into the kernel thing
first, which really needs to be addressed before this can
be merged, see my comments below.

On 03-10-16 18:42, Stephen Arnold wrote:

On Sun, Oct 2, 2016 at 11:55 PM, Hans de Goede <hdego...@redhat.com> wrote:

Hi,

On 02-10-16 06:36, Stephen Arnold wrote:


From: Steve Arnold <stephen.arnol...@gmail.com>

* needs different GMAC_TX_DELAY than lamobo-r1 (not compatible)



I see why this would need a separate defconfig, but why do you also
need a new dts file ?


I don't have a lamobo to test on, however, several dts things seem
"broken" when trying to run the bananapi with lamobo config, mostly
from memory:

1) uart3 has incorrect pin setting
2) USB host doesn't work (so you get u-boot console but no keyboard)
3) ahci power pin seems to make it less than stable (odd behavior
building native with sata rootfs)
4) missing i2c on the rpi pin header

plus a few more odds and ends.


And if you need just a minor dts tweak, please just include the
existing dts file and make the tweak, rather then writing a
whole new dts file.


What exactly qualifies as a "minor tweak"?  This seems like more than that...


Basically when your copy and pasting an entire dts and then changing
a few lines (say max 15 but that is not a hard limit) then we
prefer using the original dts as a base.


Also have you submitted the dts file to the upstream kernel ?


Not yet, but it kinda needs u-boot in order to work, so I submitted
here first.  The kernel dts needs even more tweaks to make cpufreq and
voltage adjustments correctly; now with a tiny heatsink it idles at ~
42 C instead of 49/50 deg C.


Getting u-boot up and running first is fine / the logical thing todo,
submitting first is fine too, but is generally seen as an RFC until
you actually get the dts accepted into the kernel. For sunxi we strictly
use the kernel dts files and don't want to deviate from what is in the
kernel (we manually sync all sunxi dts files with the kernel aprox. once
every release). Note "accepted in to the kernel" is quite loose here,
if you submit it to Chen-Yu Tsai and Maxime Ripard and either gives
his ack, that is good enough.



Lastly, I could not get "compatible" to do much here; the only way I
could boot my bananapi-r1 test (kernel) dts was to make a symlink from
lamobo-r1.dts to bananapi-r1.dts.  I couldn't find an example of two
similar-enough boards sharing a dts file with two different names as
"compatible".  Is there such an example somewhere and I missed it?


Here is a good example:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun8i-h3-orangepi-pc-plus.dts

And here is another example which deletes one property from the original
dts it includes (yes this is possible too) :

https://github.com/jwrdegoede/linux-sunxi/blob/sunxi-wip/arch/arm/boot/dts/sun8i-h3-orangepi-plus2e.dts

Note I'm not saying you must use #include the lamabo dts and override
various bits, I'm just offering it as a suggestion. You do must submit
whatever dts you come up with to the upstream kernel before we can
accept the dts (and thus the board) into u-boot. Please Cc me when
you submit the dts to the upstream kernel.

Usually this being done is indicated by adding a "The dts is identical to
the one submitted to the upstream kernel" to the u-boot commit msg when
submitting a new board to u-boot.

Regards,

Hans


p.s.

This was probably already mentioned, but please be sure to also update
board/sunxi/MAINTAINERS for the new board.





* tested with 4.8_rc6 b53-mdio and kernel dts switch nodes

Signed-off-by: Steve Arnold <nerd...@gentoo.org>
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/sun7i-a20-bananapi-r1.dts | 321
+
 configs/Bananapi_R1_defconfig  |  19 ++
 3 files changed, 341 insertions(+)
 create mode 100644 arch/arm/dts/sun7i-a20-bananapi-r1.dts
 create mode 100644 configs/Bananapi_R1_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 032c5ae..0cbae00 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -216,6 +216,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-ainol-aw1.dtb \
sun7i-a20-bananapi.dtb \
sun7i-a20-bananapi-m1-plus.dtb \
+   sun7i-a20-bananapi-r1.dtb \
sun7i-a20-bananapro.dtb \
sun7i-a20-cubieboard2.dtb \
sun7i-a20-cubietruck.dtb \
diff --git a/arch/arm/dts/sun7i-a20-bananapi-r1.dts
b/arch/arm/dts/sun7i-a20-bananapi-r1.dts
new file mode 100644
index 000..30a827f
--- /dev/null
+++ b/arch/arm/dts/sun7i-a20-bananapi-r1.dts
@@ -0,0 +1,321 @@
+/*
+ * Copyright 2015 Hans de Goede <hdego...@redhat.com>
+ *
+ * Changes copyright 2015 Stephen Arnold <nerd...@gentoo.org>
+ * This file

Re: [U-Boot] [PATCH v2 0/9] sunxi: sun5/7i: add the psci suspend function

[Hans de Goede]

Hi Antoine,

On 06-10-16 16:33, Antoine Tenart wrote:

Hi all,

This series adds an implementation of the psci suspend function for both
sun5i and sun7i. This was tested on Nextthing's CHIP and on a A20, using
cpuidle in Linux. My tests showed a power consumption reduced by a factor
2 on the CHIP when the system was idle. It went from ~1W without cpuidle
enabled to ~0.45W.

The idea of this suspend function is to put the dram into self-refresh,
cut off some plls and to switch cpuclk to a source with a lower
frequency. Please note the sun7i implementation lacks some parts as
putting the ram into self-refresh and coming back from this state seems
a bit tricky. I made some tests but did not managed yet to have a stable
solution.

As the sun5i does not have a GIC, I needed to remove some code from the
generic psci code. To do this I added an ARM_GIC Kconfig option which
needs to be selected by each SoC having a GIC. I already added the
relevant lines for SoCs using the PSCI ARMv7 code. As this Kconfig
option is currently only used in the psci code, it should be safe to add
it even if all the SoCs having a GIC do not select it, as long as they
don't have psci functions.

Finally the series has a patch to add defines used by the psci code and
another patch to let sun5i SoCs boot the kernel in non-secure mode so
that it can call psci functions.


While doing my laps in the swimming pool this morning I was thinking about
this patch set and I still have some questions.

Since this hooks into cpuidle in Linux, the kernel will call this as soon
as the system is idle, right?

But what happens then if some peripherals are still doing DMA? Have you
tried this on a CHIP with a LCD (or composite video out) attached ?

I would expect things to break when the system goes idle without the
screen being blanked, since the dram is then in self-refresh and
the display engine can no longer dma data from the framebuffer to
display.

Another example would be:

1) Something does a large(ish) mmc block write
2) mmc controller start-s dma sending data to the sdcard
3) sdcard blocks because it needs to do internal housekeeping
4) cpu goes idle -> dram goes into self refresh
5) sdcard is ready mmc-controller tries to dma data to write
to card, but dram is in self-refresh.

So unless I'm mistaken putting the dram in self-refresh when we still
have peripherals running and potentially doing dma, is a bad idea.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: sun7i: dts: add support for Sinovoip/Bananapi BPI-R1

[Hans de Goede]

HI,

On 03-10-16 15:04, Jagan Teki wrote:

On Mon, Oct 3, 2016 at 12:25 PM, Hans de Goede <hdego...@redhat.com> wrote:

Hi,

On 02-10-16 06:36, Stephen Arnold wrote:


From: Steve Arnold <stephen.arnol...@gmail.com>

* needs different GMAC_TX_DELAY than lamobo-r1 (not compatible)



I see why this would need a separate defconfig, but why do you also
need a new dts file ?

And if you need just a minor dts tweak, please just include the
existing dts file and make the tweak, rather then writing a
whole new dts file.

Also have you submitted the dts file to the upstream kernel ?

Regards,

Hans





* tested with 4.8_rc6 b53-mdio and kernel dts switch nodes

Signed-off-by: Steve Arnold <nerd...@gentoo.org>
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/sun7i-a20-bananapi-r1.dts | 321
+
 configs/Bananapi_R1_defconfig  |  19 ++
 3 files changed, 341 insertions(+)
 create mode 100644 arch/arm/dts/sun7i-a20-bananapi-r1.dts
 create mode 100644 configs/Bananapi_R1_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 032c5ae..0cbae00 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -216,6 +216,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-ainol-aw1.dtb \
sun7i-a20-bananapi.dtb \
sun7i-a20-bananapi-m1-plus.dtb \
+   sun7i-a20-bananapi-r1.dtb \
sun7i-a20-bananapro.dtb \
sun7i-a20-cubieboard2.dtb \
sun7i-a20-cubietruck.dtb \
diff --git a/arch/arm/dts/sun7i-a20-bananapi-r1.dts
b/arch/arm/dts/sun7i-a20-bananapi-r1.dts
new file mode 100644
index 000..30a827f
--- /dev/null
+++ b/arch/arm/dts/sun7i-a20-bananapi-r1.dts
@@ -0,0 +1,321 @@
+/*
+ * Copyright 2015 Hans de Goede <hdego...@redhat.com>
+ *
+ * Changes copyright 2015 Stephen Arnold <nerd...@gentoo.org>
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Banana Pi BPI-R1";
+   compatible = "sinovoip,bpi-r1", "allwinner,sun7i-a20";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_bpi_r1>;
+
+   green {
+   label = "bpi-r1:green:usr";
+   gpios = < 7 24 GPIO_ACTIVE_HIGH>; /* PH24 */
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   reg_gmac_3v3: gmac-3v3 {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_power_pin_bpi_r1>;
+

Re: [U-Boot] [PATCH] ARM: sun7i: dts: add support for Sinovoip/Bananapi BPI-R1

[Hans de Goede]

Hi,

On 02-10-16 06:36, Stephen Arnold wrote:

From: Steve Arnold <stephen.arnol...@gmail.com>

* needs different GMAC_TX_DELAY than lamobo-r1 (not compatible)


I see why this would need a separate defconfig, but why do you also
need a new dts file ?

And if you need just a minor dts tweak, please just include the
existing dts file and make the tweak, rather then writing a
whole new dts file.

Also have you submitted the dts file to the upstream kernel ?

Regards,

Hans




* tested with 4.8_rc6 b53-mdio and kernel dts switch nodes

Signed-off-by: Steve Arnold <nerd...@gentoo.org>
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/sun7i-a20-bananapi-r1.dts | 321 +
 configs/Bananapi_R1_defconfig  |  19 ++
 3 files changed, 341 insertions(+)
 create mode 100644 arch/arm/dts/sun7i-a20-bananapi-r1.dts
 create mode 100644 configs/Bananapi_R1_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 032c5ae..0cbae00 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -216,6 +216,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-ainol-aw1.dtb \
sun7i-a20-bananapi.dtb \
sun7i-a20-bananapi-m1-plus.dtb \
+   sun7i-a20-bananapi-r1.dtb \
sun7i-a20-bananapro.dtb \
sun7i-a20-cubieboard2.dtb \
sun7i-a20-cubietruck.dtb \
diff --git a/arch/arm/dts/sun7i-a20-bananapi-r1.dts 
b/arch/arm/dts/sun7i-a20-bananapi-r1.dts
new file mode 100644
index 000..30a827f
--- /dev/null
+++ b/arch/arm/dts/sun7i-a20-bananapi-r1.dts
@@ -0,0 +1,321 @@
+/*
+ * Copyright 2015 Hans de Goede <hdego...@redhat.com>
+ *
+ * Changes copyright 2015 Stephen Arnold <nerd...@gentoo.org>
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Banana Pi BPI-R1";
+   compatible = "sinovoip,bpi-r1", "allwinner,sun7i-a20";
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_bpi_r1>;
+
+   green {
+   label = "bpi-r1:green:usr";
+   gpios = < 7 24 GPIO_ACTIVE_HIGH>; /* PH24 */
+   linux,default-trigger = "heartbeat";
+   };
+   };
+
+   reg_gmac_3v3: gmac-3v3 {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_power_pin_bpi_r1>;
+   regulator-name = "gmac-3v3";
+   regulator-min-microvolt = <33000

Re: [U-Boot] [bug report] sunxi: booting from eMMC

[Hans de Goede]

HI,

On 19-09-16 15:17, Maxime Ripard wrote:

On Wed, Sep 14, 2016 at 12:05:19PM +0200, Hans de Goede wrote:

Hi,

On 13-09-16 13:50, Maxime Ripard wrote:

Hi,

On Mon, Sep 12, 2016 at 04:47:49PM +0200, Hans de Goede wrote:

On 12-09-16 15:56, Maxime Ripard wrote:

Hi,

On Mon, Sep 12, 2016 at 01:53:24PM +0200, Ciprian Manea wrote:

I'm using a SinA33 dev board (Allwinner a33 SoC) and at the moment
I'm trying to boot from the eMMC.

But it fails in the following way:


*Got the following error at boot time:*
*U-Boot SPL 2016.09-rc2-00125-g6e8b42f (Sep 08 2016 - 11:00:46) DRAM: 1024
MiB Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc
device. error: -19 SPL: failed to boot from all boot devices ### ERROR ###
Please RESET the board ###*


So I've been on the same issue for the last couple of days.

Since that board is already supported, adding support for the eMMC
basically came down to that patch on top of 2016.09-rc2.

http://code.bulix.org/kcgxri-106037?raw

(Quite hackish, the 8-Bits part being a separate issue that would need
to be addressed somehow).

However, it doesn't work, neither when flashing u-boot on the eMMC
itself (where there's a timeout error in the SPL) nor when trying to
access the eMMC from a U-Boot loaded from the (external) SD.

In the latter case, even mmc dev 1 fails silently.

I traced that down to the mmc_switch here:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c#l530

Which fails with ETIMEDOUT, and more specifically, it's the call to
mmc_rint_wait here
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/sunxi_mmc.c#l383
that times out.

Increasing the timeout value (to 1) doesn't really change
anything. I guess this is also the reason why we had a timeout error
in the SPL.

This eMMC works fine in Linux, with the same muxing (and I guess the
earlier commands wouldn't be successful if the muxing or power was not
set up appropriately). So I'm kind of running out of ideas on what
could be the root cause of this.

Hans, any ideas?


Maybe the emmc needs external pull-ups ? I don't remember if u-boot
always enables those or not ...


So I pushed this a bit more, and it seems like commenting the call to
mmc_change_freq makes everything just work.

Reading the JEDEC spec, it looks like when you switch to high speed,
you also need to change the controller clock rate, that u-boot doesn't
seem to do at the moment, which obviously will fail, since the
controller will be stuck at the former rate, while the eMMC would be
switched.

If I comment mmc_change_freq, everything works.


Hmm, I'm pretty sure the u-boot sunxi mmc code
does properly change the clock, see mmc_set_mod_clk() in
drivers/mmc/sunxi_mmc.c

This will switch to the right PLL, etc. So there likely is
something else going on making things not work at higher
speeds.


Yep, I noticed that. However, what confuses me more is that the
command seems to be sent here:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c#l530

And set_ios is being called after we check that everything
works. Linux for example calls set_ios right after switching
http://lxr.free-electrons.com/source/drivers/mmc/core/mmc.c#L965


Maybe we need a higher driver strenghts at the mmc io pins, or maybe
we've a completely unrelated issue ?


I've tested that already. It doesn't change the outcome.


I'm pretty sure that the eMMC's on A20 devices work fine in 50MHZ
(SDR) mode.


What emmc was that? Did it support HS? Was it considered an SD (and
went through sd_change_freq), or an MMC?


Here is what "mmc info" in u-boot says on my UTOO P66 tablet (A13)
with 4G eMMC (manually transcribed, no serial console):

Device: SUNXI SD/MMC
Manufacturer ID: 70
OEM: 100
Name: MMC04
Tran Speed: 5200
Rd Block Len: 512
MMC version 4.4.1
High Capacity: Yes
Bus-width: 4-bit


And here is /sys/kernel/debug/mmc1/ios under linux:

clock:  5200 Hz
vdd:21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  3 (8 bits)
timing spec:1 (mmc high-speed)
signal voltage: 0 (3.30 V)
driver type:0 (driver type B)

HTH,

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] A20-OLinuXino-Lime2: Enable USB gadget support

[Hans de Goede]

Hi,

On 19-09-16 17:00, Tom Rini wrote:

On Mon, Sep 19, 2016 at 04:53:04PM +0200, Hans de Goede wrote:

Hi,

On 19-09-16 16:03, Tom Rini wrote:

Based on A13-OLinuXino, enable DFU and UMS support.

Signed-off-by: Tom Rini <tr...@konsulko.com>
---
With this change I've added DFU to my tests on this board, and assuming a
follow up test with the SD image that kicks the board into FEL works, I'll
then enable the UMS tests on this board (and add DFU to SD, not just DFU to
RAM).

configs/A20-OLinuXino-Lime2_defconfig | 8 
1 file changed, 8 insertions(+)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index 23db07380624..54343de7f351 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -12,9 +12,17 @@ 
CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
CONFIG_SPL=y
# CONFIG_CMD_IMLS is not set
# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_DFU=y
+CONFIG_CMD_USB_MASS_STORAGE=y


Do you need CMD_USB_MASS_STORAGE for your tests ? Enabling
CMD_USB_MASS_STORAGE really seems orthogonal to enabling GADGET
mode to me, esp. since it is only useful in host mode AFAICT.


Ah, no, things have bad names perhaps.  CMD_USB_MASS_STORAGE enables
"ums" as a command which is what in turn will export MMC (or something
else) as a USB mass storage gadget over to the host.


Ah, I thought this enabled the (destructive) low level usb mass storage
block read/write test commands, but I guess I'm wrong.

I wonder why Chen-Yu put it in the usb host enabling patch for
an A33 board then...



Chen-Yu did something similar in a patch enabling host mode for a
different sunxi board and here is what I replied:

"
If we want to enable CONFIG_CMD_USB_MASS_STORAGE on sunxi, we really
should do so on all boards (feel free to submit a patch for this).

e.g. add something like this to board/sunxi/Kconfig:

config CMD_USB_MASS_STORAGE
default y


Given the above, that should probably be:

config CMD_USB_MASS_STORAGE
   default y if USB_GADGET


Hmm, I guess we may want to have a bunch of those, so that
simply adding:

CONFIG_USB_MUSB_GADGET=y

To a defconfig enables the relevant related options...

Regards,

Hans





So that we can still disable it in case there are space constraints,
but normally we enable it on all sunxi boards offering a
consistent set of available commands.
"


I think it's a useful command that should be more widely exposed, yes.
IIRC, it's how the Tegra platforms support flashing their dev boards
with official images, and can be a handy "rescue" type option too.



The same goes for this patch, otherwise this patch is:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Ig you want to feel free to apply this directly
(given that I've send out a sunxi pull-req recently).


OK, thanks.  I just might since I really want to move on to grabbing
some fs patches and before I do that I really want to have as much
testing of them as possible.


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] A20-OLinuXino-Lime2: Enable USB gadget support

[Hans de Goede]

Hi,

On 19-09-16 16:03, Tom Rini wrote:

Based on A13-OLinuXino, enable DFU and UMS support.

Signed-off-by: Tom Rini <tr...@konsulko.com>
---
With this change I've added DFU to my tests on this board, and assuming a
follow up test with the SD image that kicks the board into FEL works, I'll
then enable the UMS tests on this board (and add DFU to SD, not just DFU to
RAM).

 configs/A20-OLinuXino-Lime2_defconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/configs/A20-OLinuXino-Lime2_defconfig 
b/configs/A20-OLinuXino-Lime2_defconfig
index 23db07380624..54343de7f351 100644
--- a/configs/A20-OLinuXino-Lime2_defconfig
+++ b/configs/A20-OLinuXino-Lime2_defconfig
@@ -12,9 +12,17 @@ 
CONFIG_SYS_EXTRA_OPTIONS="SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3)"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
+CONFIG_CMD_DFU=y
+CONFIG_CMD_USB_MASS_STORAGE=y


Do you need CMD_USB_MASS_STORAGE for your tests ? Enabling
CMD_USB_MASS_STORAGE really seems orthogonal to enabling GADGET
mode to me, esp. since it is only useful in host mode AFAICT.

Chen-Yu did something similar in a patch enabling host mode for a
different sunxi board and here is what I replied:

"
If we want to enable CONFIG_CMD_USB_MASS_STORAGE on sunxi, we really
should do so on all boards (feel free to submit a patch for this).

e.g. add something like this to board/sunxi/Kconfig:

config CMD_USB_MASS_STORAGE
default y

So that we can still disable it in case there are space constraints,
but normally we enable it on all sunxi boards offering a
consistent set of available commands.
"

The same goes for this patch, otherwise this patch is:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

Ig you want to feel free to apply this directly
(given that I've send out a sunxi pull-req recently).

Regards,

Hans




 # CONFIG_CMD_FPGA is not set
 CONFIG_RTL8211X_PHY_FORCE_MASTER=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_AXP_ALDO3_VOLT=2800
 CONFIG_AXP_ALDO4_VOLT=2800
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_MUSB_GADGET=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_G_DNL_MANUFACTURER="Allwinner Technology"
+CONFIG_G_DNL_VENDOR_NUM=0x1f3a
+CONFIG_G_DNL_PRODUCT_NUM=0x1010


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: musb: Re-init musb controller on repeated probe calls

[Hans de Goede]

Hi,

On 18-09-16 17:00, Ian Campbell wrote:

On Sun, 2016-09-18 at 16:53 +0200, Hans de Goede wrote:

With sunxi-musb musb_lowlevel_init() can fail when a charger; or no
cable
is plugged into the otg port.

To avoid leaking the struct musb allocated by musb_init_controller()
on repeated musb_usb_probe() calls, we were caching its result.
But musb_init_controller() does more, such as calling
sunxi_musb_init()
which enables the clocks.

Not calling sunxi_musb_init() causes the musb controller to stop
working
after a "usb reset" since that calls musb_usb_remove() which disables
the
clocks.

This commit fixes this by removing the caching of the struct returned
from musb_init_controller(), it replaces this by free-ing the
allocated
memory in musb_usb_remove() and calling musb_usb_remove() on
musb_usb_probe() errors to ensure proper cleanup.

While at it also make musb_usb_probe() and musb_usb_remove() static.

Signed-off-by: Hans de Goede <hdego...@redhat.com>


LGTM in so far as it seems like a more normal way to do things,


Yeah my original hack here was bad, and something which I should
never have done, ain't hindsight a wonderful thing :)

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-sunxi master

[Hans de Goede]

Hi Tom,

Here is the first sunxi pull-req for v2016.11.

This consists of a couple of small bug-fixes /
defconfig improvements + 1 new board.

The following changes since commit 8cbb389bb3da80cbf8911f8386cbff92c6a78afe:

  Prepare v2016.09 (2016-09-12 10:05:51 -0400)

are available in the git repository at:

  http://git.denx.de/u-boot-sunxi.git master

for you to fetch changes up to ca7628a91136364235de8fb4bd699944b981c504:

  sunxi: Enable USB gadget support for Sinlinx SinA33 (2016-09-18 14:39:16 
+0200)


Chen-Yu Tsai (4):
  sunxi: musb: Power off OTG port VBUS when disabled
  sunxi: Add mmc0 card detect pin for Sinlinx SinA33
  sunxi: Enable USB host support for Sinlinx SinA33
  sunxi: Enable USB gadget support for Sinlinx SinA33

Hans de Goede (2):
  sunxi: axp2xx: disable ldoio0/1 at boot
  sunxi: musb: Re-init musb controller on repeated probe calls

Jelle van der Waa (1):
  sunxi: Add defconfig and dts for the NanoPi NEO

 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/sun8i-h3-nanopi-neo.dts  | 125 ++
 arch/arm/include/asm/arch-sunxi/usb_phy.h |   1 -
 arch/arm/mach-sunxi/usb_phy.c |   7 --
 board/sunxi/MAINTAINERS   |   5 ++
 configs/Sinlinx_SinA33_defconfig  |  10 +++
 configs/nanopi_neo_defconfig  |  16 
 drivers/power/axp209.c|  16 
 drivers/power/axp221.c|  12 +++
 drivers/usb/musb-new/sunxi.c  |  48 ++--
 10 files changed, 209 insertions(+), 34 deletions(-)
 create mode 100644 arch/arm/dts/sun8i-h3-nanopi-neo.dts
 create mode 100644 configs/nanopi_neo_defconfig

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sunxi: musb: Re-init musb controller on repeated probe calls

[Hans de Goede]

With sunxi-musb musb_lowlevel_init() can fail when a charger; or no cable
is plugged into the otg port.

To avoid leaking the struct musb allocated by musb_init_controller()
on repeated musb_usb_probe() calls, we were caching its result.
But musb_init_controller() does more, such as calling sunxi_musb_init()
which enables the clocks.

Not calling sunxi_musb_init() causes the musb controller to stop working
after a "usb reset" since that calls musb_usb_remove() which disables the
clocks.

This commit fixes this by removing the caching of the struct returned
from musb_init_controller(), it replaces this by free-ing the allocated
memory in musb_usb_remove() and calling musb_usb_remove() on
musb_usb_probe() errors to ensure proper cleanup.

While at it also make musb_usb_probe() and musb_usb_remove() static.

Signed-off-by: Hans de Goede <hdego...@redhat.com>
---
 drivers/usb/musb-new/sunxi.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index dece781..469377f 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -201,7 +201,6 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void 
*__hci)
 
 /* musb_core does not call enable / disable in a balanced manner  */
 static bool enabled = false;
-static struct musb *sunxi_musb;
 
 static int sunxi_musb_enable(struct musb *musb)
 {
@@ -309,7 +308,9 @@ static struct musb_hdrc_platform_data musb_plat = {
 };
 
 #ifdef CONFIG_USB_MUSB_HOST
-int musb_usb_probe(struct udevice *dev)
+static int musb_usb_remove(struct udevice *dev);
+
+static int musb_usb_probe(struct udevice *dev)
 {
struct musb_host_data *host = dev_get_priv(dev);
struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
@@ -317,23 +318,21 @@ int musb_usb_probe(struct udevice *dev)
 
priv->desc_before_addr = true;
 
-   if (!sunxi_musb) {
-   sunxi_musb = musb_init_controller(_plat, NULL,
- (void *)SUNXI_USB0_BASE);
-   }
-
-   host->host = sunxi_musb;
+   host->host = musb_init_controller(_plat, NULL,
+ (void *)SUNXI_USB0_BASE);
if (!host->host)
return -EIO;
 
ret = musb_lowlevel_init(host);
if (ret == 0)
printf("MUSB OTG\n");
+   else
+   musb_usb_remove(dev);
 
return ret;
 }
 
-int musb_usb_remove(struct udevice *dev)
+static int musb_usb_remove(struct udevice *dev)
 {
struct musb_host_data *host = dev_get_priv(dev);
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
@@ -346,6 +345,9 @@ int musb_usb_remove(struct udevice *dev)
 #endif
clrbits_le32(>ahb_gate0, 1 << AHB_GATE_OFFSET_USB0);
 
+   free(host->host);
+   host->host = NULL;
+
return 0;
 }
 
-- 
2.9.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] sunxi: Enable USB host support for Sinlinx SinA33

[Hans de Goede]

Hi,

On 14-09-16 04:26, Chen-Yu Tsai wrote:

Sinlinx SinA33 has 1 USB host port. Enable EHCI_HCD support for it.
Also enable USB mass storage support so we can access USB sticks.

Signed-off-by: Chen-Yu Tsai <w...@csie.org>
---
 configs/Sinlinx_SinA33_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/Sinlinx_SinA33_defconfig b/configs/Sinlinx_SinA33_defconfig
index 77eb05bf251a..673f3210a1b5 100644
--- a/configs/Sinlinx_SinA33_defconfig
+++ b/configs/Sinlinx_SinA33_defconfig
@@ -9,4 +9,6 @@ CONFIG_DEFAULT_DEVICE_TREE="sun8i-a33-sinlinx-sina33"
 CONFIG_SPL=y
 # CONFIG_CMD_IMLS is not set
 # CONFIG_CMD_FLASH is not set
+CONFIG_CMD_USB_MASS_STORAGE=y


If we want to enable CONFIG_CMD_USB_MASS_STORAGE on sunxi, we really
should do so on all boards (feel free to submit a patch for this).

e.g. add something like this to board/sunxi/Kconfig:

config CMD_USB_MASS_STORAGE
default y

So that we can still disable it in case there are space constraints,
but normally we enable it on all sunxi boards offering a
consistent set of available comments.

So I've dropped this bit of the patch.

Otherwise this series LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

I've added this to my local queue and this will go out
with the pull-req I plan todo later today.

Regards,

Hans



 # CONFIG_CMD_FPGA is not set
+CONFIG_USB_EHCI_HCD=y


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: musb: Power off OTG port VBUS when disabled

[Hans de Goede]

Hi,

On 07-09-16 08:25, Chen-Yu Tsai wrote:

The Linux kernel musb driver expects VBUS to be off while initializing
musb. Having it on results in a repeating string of warnings, followed
by an unusable peripheral. The peripheral is only usable after
physically removing the OTG adapter, letting musb reset its state.

This partially reverts commit c9f8947e6604 ("sunxi: usb-phy: Never
power off the usb ports")

Signed-off-by: Chen-Yu Tsai <w...@csie.org>


Thank you, LGTM:

Reviewed-by: Hans de Goede <hdego...@redhat.com>

I've added this to my local queue and this will go out
with the pull-req I plan todo later today.

Regards,

Hans



---
 arch/arm/include/asm/arch-sunxi/usb_phy.h |  1 -
 arch/arm/mach-sunxi/usb_phy.c |  7 ---
 drivers/usb/musb-new/sunxi.c  | 28 
 3 files changed, 12 insertions(+), 24 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/usb_phy.h 
b/arch/arm/include/asm/arch-sunxi/usb_phy.h
index 6a14cad3ff39..cef6c985bc8d 100644
--- a/arch/arm/include/asm/arch-sunxi/usb_phy.h
+++ b/arch/arm/include/asm/arch-sunxi/usb_phy.h
@@ -16,7 +16,6 @@ void sunxi_usb_phy_init(int index);
 void sunxi_usb_phy_exit(int index);
 void sunxi_usb_phy_power_on(int index);
 void sunxi_usb_phy_power_off(int index);
-int sunxi_usb_phy_power_is_on(int index);
 int sunxi_usb_phy_vbus_detect(int index);
 int sunxi_usb_phy_id_detect(int index);
 void sunxi_usb_phy_enable_squelch_detect(int index, int enable);
diff --git a/arch/arm/mach-sunxi/usb_phy.c b/arch/arm/mach-sunxi/usb_phy.c
index f9993d287551..bd1bbee410ba 100644
--- a/arch/arm/mach-sunxi/usb_phy.c
+++ b/arch/arm/mach-sunxi/usb_phy.c
@@ -296,13 +296,6 @@ void sunxi_usb_phy_power_off(int index)
gpio_set_value(phy->gpio_vbus, 0);
 }

-int sunxi_usb_phy_power_is_on(int index)
-{
-   struct sunxi_usb_phy *phy = _usb_phy[index];
-
-   return phy->power_on_count > 0;
-}
-
 int sunxi_usb_phy_vbus_detect(int index)
 {
struct sunxi_usb_phy *phy = _usb_phy[index];
diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index c016a0bb544d..dece7818dc3a 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -205,6 +205,8 @@ static struct musb *sunxi_musb;

 static int sunxi_musb_enable(struct musb *musb)
 {
+   int ret;
+
pr_debug("%s():\n", __func__);

musb_ep_select(musb->mregs, 0);
@@ -217,26 +219,17 @@ static int sunxi_musb_enable(struct musb *musb)
musb_writeb(musb->mregs, USBC_REG_o_VEND0, 0);

if (is_host_enabled(musb)) {
-   int id = sunxi_usb_phy_id_detect(0);
-
-   if (id == 1 && sunxi_usb_phy_power_is_on(0))
-   sunxi_usb_phy_power_off(0);
-
-   if (!sunxi_usb_phy_power_is_on(0)) {
-   int vbus = sunxi_usb_phy_vbus_detect(0);
-   if (vbus == 1) {
-   printf("A charger is plugged into the OTG: ");
-   return -ENODEV;
-   }
+   ret = sunxi_usb_phy_vbus_detect(0);
+   if (ret == 1) {
+   printf("A charger is plugged into the OTG: ");
+   return -ENODEV;
}
-
-   if (id == 1) {
+   ret = sunxi_usb_phy_id_detect(0);
+   if (ret == 1) {
printf("No host cable detected: ");
return -ENODEV;
}
-
-   if (!sunxi_usb_phy_power_is_on(0))
-   sunxi_usb_phy_power_on(0);
+   sunxi_usb_phy_power_on(0); /* port power on */
}

USBC_ForceVbusValidToHigh(musb->mregs);
@@ -252,6 +245,9 @@ static void sunxi_musb_disable(struct musb *musb)
if (!enabled)
return;

+   if (is_host_enabled(musb))
+   sunxi_usb_phy_power_off(0); /* port power off */
+
USBC_ForceVbusValidToLow(musb->mregs);
mdelay(200); /* Wait for the current session to timeout */



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [bug report] sunxi: booting from eMMC

[Hans de Goede]

Hi,

On 13-09-16 13:50, Maxime Ripard wrote:

Hi,

On Mon, Sep 12, 2016 at 04:47:49PM +0200, Hans de Goede wrote:

On 12-09-16 15:56, Maxime Ripard wrote:

Hi,

On Mon, Sep 12, 2016 at 01:53:24PM +0200, Ciprian Manea wrote:

I'm using a SinA33 dev board (Allwinner a33 SoC) and at the moment
I'm trying to boot from the eMMC.

But it fails in the following way:


*Got the following error at boot time:*
*U-Boot SPL 2016.09-rc2-00125-g6e8b42f (Sep 08 2016 - 11:00:46) DRAM: 1024
MiB Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc
device. error: -19 SPL: failed to boot from all boot devices ### ERROR ###
Please RESET the board ###*


So I've been on the same issue for the last couple of days.

Since that board is already supported, adding support for the eMMC
basically came down to that patch on top of 2016.09-rc2.

http://code.bulix.org/kcgxri-106037?raw

(Quite hackish, the 8-Bits part being a separate issue that would need
to be addressed somehow).

However, it doesn't work, neither when flashing u-boot on the eMMC
itself (where there's a timeout error in the SPL) nor when trying to
access the eMMC from a U-Boot loaded from the (external) SD.

In the latter case, even mmc dev 1 fails silently.

I traced that down to the mmc_switch here:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c#l530

Which fails with ETIMEDOUT, and more specifically, it's the call to
mmc_rint_wait here
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/sunxi_mmc.c#l383
that times out.

Increasing the timeout value (to 1) doesn't really change
anything. I guess this is also the reason why we had a timeout error
in the SPL.

This eMMC works fine in Linux, with the same muxing (and I guess the
earlier commands wouldn't be successful if the muxing or power was not
set up appropriately). So I'm kind of running out of ideas on what
could be the root cause of this.

Hans, any ideas?


Maybe the emmc needs external pull-ups ? I don't remember if u-boot
always enables those or not ...


So I pushed this a bit more, and it seems like commenting the call to
mmc_change_freq makes everything just work.

Reading the JEDEC spec, it looks like when you switch to high speed,
you also need to change the controller clock rate, that u-boot doesn't
seem to do at the moment, which obviously will fail, since the
controller will be stuck at the former rate, while the eMMC would be
switched.

If I comment mmc_change_freq, everything works.


Hmm, I'm pretty sure the u-boot sunxi mmc code
does properly change the clock, see mmc_set_mod_clk() in
drivers/mmc/sunxi_mmc.c

This will switch to the right PLL, etc. So there likely is
something else going on making things not work at higher
speeds. Maybe we need a higher driver strenghts at the
mmc io pins, or maybe we've a completely unrelated issue ?

I'm pretty sure that the eMMC's on A20 devices work fine
in 50MHZ (SDR) mode.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [bug report] sunxi: booting from eMMC

[Hans de Goede]

Hi,

On 12-09-16 15:56, Maxime Ripard wrote:

Hi,

On Mon, Sep 12, 2016 at 01:53:24PM +0200, Ciprian Manea wrote:

I'm using a SinA33 dev board (Allwinner a33 SoC) and at the moment
I'm trying to boot from the eMMC.

But it fails in the following way:


*Got the following error at boot time:*
*U-Boot SPL 2016.09-rc2-00125-g6e8b42f (Sep 08 2016 - 11:00:46) DRAM: 1024
MiB Trying to boot from MMC2 MMC Device 1 not found spl: could not find mmc
device. error: -19 SPL: failed to boot from all boot devices ### ERROR ###
Please RESET the board ###*


So I've been on the same issue for the last couple of days.

Since that board is already supported, adding support for the eMMC
basically came down to that patch on top of 2016.09-rc2.

http://code.bulix.org/kcgxri-106037?raw

(Quite hackish, the 8-Bits part being a separate issue that would need
to be addressed somehow).

However, it doesn't work, neither when flashing u-boot on the eMMC
itself (where there's a timeout error in the SPL) nor when trying to
access the eMMC from a U-Boot loaded from the (external) SD.

In the latter case, even mmc dev 1 fails silently.

I traced that down to the mmc_switch here:
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/mmc.c#l530

Which fails with ETIMEDOUT, and more specifically, it's the call to
mmc_rint_wait here
http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/sunxi_mmc.c#l383
that times out.

Increasing the timeout value (to 1) doesn't really change
anything. I guess this is also the reason why we had a timeout error
in the SPL.

This eMMC works fine in Linux, with the same muxing (and I guess the
earlier commands wouldn't be successful if the muxing or power was not
set up appropriately). So I'm kind of running out of ideas on what
could be the root cause of this.

Hans, any ideas?


Maybe the emmc needs external pull-ups ? I don't remember if u-boot
always enables those or not ...

I've not tried booting from eMMC on A33 boards (-ENOHARDWARE) but it
does work on A13 and A20 boards (last time I tried).

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot