Discussion:
[PATCH 0/3] uboot sata support
Ian Campbell
2014-02-07 16:14:51 UTC
Permalink
This is the result of my afternoons hacking at the urlab hacklab in
Brussels before FOSDEM, thanks for hosting us guys!

This uses the existing ahci platform support in u-boot. Most of the
siunxi specific code comes from the Linux platform patches.

I've tested this only on cubietruck.

Ian.
Ian Campbell
2014-02-07 16:15:33 UTC
Permalink
This allow the platform to register the platform ahci device.

Signed-off-by: Ian Campbell <ijc-***@public.gmane.org>
---
In theory this could go into mainline now and perhaps be used by
highbank.
---
arch/arm/lib/board.c | 6 ++++++
drivers/block/ahci.c | 5 +++++
2 files changed, 11 insertions(+)

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 34f50b0..fe381a3 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -33,6 +33,7 @@
#include <nand.h>
#include <onenand_uboot.h>
#include <mmc.h>
+#include <scsi.h>
#include <libfdt.h>
#include <fdtdec.h>
#include <post.h>
@@ -593,6 +594,11 @@ void board_init_r(gd_t *id, ulong dest_addr)
mmc_initialize(gd->bd);
#endif

+#ifdef CONFIG_CMD_SCSI
+ puts("SCSI: ");
+ scsi_init();
+#endif
+
#ifdef CONFIG_HAS_DATAFLASH
AT91F_DataflashInit();
dataflash_print_info();
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 0daad36..d5370fa 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -924,6 +924,11 @@ int ahci_init(u32 base)
err_out:
return rc;
}
+
+void __weak scsi_init(void)
+{
+}
+
#endif

/*
--
1.8.5.3
Ian Campbell
2014-02-07 16:15:34 UTC
Permalink
I have observed timeouts on a cubietruck.

The increase to 40ms is completely arbitrary and Works For Me(tm). I
couldn't find a good reference for how long you are supposed to wait.

Signed-off-by: Ian Campbell <ijc-***@public.gmane.org>
---
drivers/block/ahci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index d5370fa..90a0719 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -41,7 +41,7 @@ u16 *ataid[AHCI_MAX_PORTS];
#define WAIT_MS_SPINUP 20000
#define WAIT_MS_DATAIO 5000
#define WAIT_MS_FLUSH 5000
-#define WAIT_MS_LINKUP 4
+#define WAIT_MS_LINKUP 40

static inline u32 ahci_port_base(u32 base, u32 port)
{
--
1.8.5.3
Oliver Schinagl
2014-02-09 12:50:52 UTC
Permalink
Post by Ian Campbell
I have observed timeouts on a cubietruck.
The increase to 40ms is completely arbitrary and Works For Me(tm). I
couldn't find a good reference for how long you are supposed to wait.
---
drivers/block/ahci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index d5370fa..90a0719 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -41,7 +41,7 @@ u16 *ataid[AHCI_MAX_PORTS];
#define WAIT_MS_SPINUP 20000
#define WAIT_MS_DATAIO 5000
#define WAIT_MS_FLUSH 5000
-#define WAIT_MS_LINKUP 4
+#define WAIT_MS_LINKUP 40
wont this affect every platform? I don't know what u-boot's rules are
with regards to that, as it will come as 'a' patch in a big series when
we upstream it ...

oliver

P.S. Awesome job :D and was nice to meet you! even though it was very
briefly.
Post by Ian Campbell
static inline u32 ahci_port_base(u32 base, u32 port)
{
Ian Campbell
2014-02-10 11:20:37 UTC
Permalink
Post by Oliver Schinagl
Post by Ian Campbell
-#define WAIT_MS_LINKUP 4
+#define WAIT_MS_LINKUP 40
wont this affect every platform?
Yes. I figured that since this was a timeout it was pretty harmless to
increase it, the only downside seems to be that if the AHCI is actually
broken you wait a bit longer before figuring that out.

Although I didn't find a good reference 4ms did seem short compared with
what I think Linux was doing (but it's all a bit async as well as
abstracted into common infra there so I may not be following it
correctly) and what other google'd up bits and bobs showed -- they seems
to be more in the 100-150ms range.
Post by Oliver Schinagl
I don't know what u-boot's rules are
with regards to that, as it will come as 'a' patch in a big series when
we upstream it ...
I was a bit torn over what to do with this and the first patch ("Provide
a weak scsi_init hook") since they are both essentially upstream fodder
already _except_ that they wouldn't be being presented at the same time
as a consumer of the change.

I have a feeling that for upstreaming these sorts of changes might need
to be cherry-picked into their own changeset, the massive patch approach
doesn't seem likely to succeed even if it only touches sunxi code, but
including random changes to the common code in that patch is sure to
fail IMHO. I was looking at the mainline vs sunxi diff and there are a
few other similar changes which would need pulling out too.
Post by Oliver Schinagl
oliver
P.S. Awesome job :D and was nice to meet you! even though it was very
briefly.
Likewise!
Post by Oliver Schinagl
Post by Ian Campbell
static inline u32 ahci_port_base(u32 base, u32 port)
{
Hans de Goede
2014-02-10 19:15:06 UTC
Permalink
Hi,

On 02/10/2014 12:20 PM, Ian Campbell wrote:

<snip>
Post by Ian Campbell
I was a bit torn over what to do with this and the first patch ("Provide
a weak scsi_init hook") since they are both essentially upstream fodder
already _except_ that they wouldn't be being presented at the same time
as a consumer of the change.
I met one of the core u-boot developers, Marek Vasut at decvonf.cz and
ended up talking quite a bit with him about upstreaming sunxi-u-boot.

I think that it is safe to say that they are definitively interested in
fixes like this going upstream immediately. So please do submit these
upstream as soon as you feel they are ready to go upstream.

Upstream also is the proper place to discuss whether making the ahci
probe delay longer makes sense for all boards, or if we need to make it
an #ifdef SUXNI thing.

BTW Oliver, the same goes for your 2G mem support patches, if you could
submit the non sunxi specific bits of that upstream asap that would be great.

So now that the cat is out of the bag wrt me talking to Marek, yes there
now is something resembling a plan for upstreaming u-boot sunxi. I won't
start working on this until I've finished getting all the kernel bits
I've currently in-flight upstream as I don't want to open yet another
"battle front". If anyone wants to beat me working on this they are
very much invited to do so (*).

Regards,

Hans




*) Oliver this sounds like it may be something for you, we could get
together soon-ish for some drinks in a bar and discuss this in detail.

p.s. It was good to meet you at Fosdem, even though it was way too short.
Oliver Schinagl
2014-02-11 21:26:57 UTC
Permalink
Post by Hans de Goede
Hi,
<snip>
Post by Ian Campbell
I was a bit torn over what to do with this and the first patch ("Provide
a weak scsi_init hook") since they are both essentially upstream fodder
already _except_ that they wouldn't be being presented at the same time
as a consumer of the change.
I met one of the core u-boot developers, Marek Vasut at decvonf.cz and
ended up talking quite a bit with him about upstreaming sunxi-u-boot.
I think that it is safe to say that they are definitively interested in
fixes like this going upstream immediately. So please do submit these
upstream as soon as you feel they are ready to go upstream.
Upstream also is the proper place to discuss whether making the ahci
probe delay longer makes sense for all boards, or if we need to make it
an #ifdef SUXNI thing.
BTW Oliver, the same goes for your 2G mem support patches, if you could
submit the non sunxi specific bits of that upstream asap that would be great.
I'm happy you have rememberd it, I have actually, TWICE.

The first time there was some talk about it being required at all, which
Wolfgang even said it might/should [1].

The second time there was even less interest [2]. I've hoped Henrik
would pick up on it as he should have some weight in the u-boot
community ... but alas ..

Oliver

[1] http://lists.denx.de/pipermail/u-boot/2013-October/164145.html
[2] http://patchwork.ozlabs.org/patch/281094/
http://patchwork.ozlabs.org/patch/291247/

P.S. That's all i could find in a quick google search, I think there may
have been more messages from me on this subject ...
Post by Hans de Goede
So now that the cat is out of the bag wrt me talking to Marek, yes there
now is something resembling a plan for upstreaming u-boot sunxi. I won't
start working on this until I've finished getting all the kernel bits
I've currently in-flight upstream as I don't want to open yet another
"battle front". If anyone wants to beat me working on this they are
very much invited to do so (*).
Regards,
Hans
*) Oliver this sounds like it may be something for you, we could get
together soon-ish for some drinks in a bar and discuss this in detail.
p.s. It was good to meet you at Fosdem, even though it was way too short.
Hans de Goede
2014-02-12 08:42:14 UTC
Permalink
Hi,
Post by Oliver Schinagl
Post by Hans de Goede
Hi,
<snip>
Post by Ian Campbell
I was a bit torn over what to do with this and the first patch ("Provide
a weak scsi_init hook") since they are both essentially upstream fodder
already _except_ that they wouldn't be being presented at the same time
as a consumer of the change.
I met one of the core u-boot developers, Marek Vasut at decvonf.cz and
ended up talking quite a bit with him about upstreaming sunxi-u-boot.
I think that it is safe to say that they are definitively interested in
fixes like this going upstream immediately. So please do submit these
upstream as soon as you feel they are ready to go upstream.
Upstream also is the proper place to discuss whether making the ahci
probe delay longer makes sense for all boards, or if we need to make it
an #ifdef SUXNI thing.
BTW Oliver, the same goes for your 2G mem support patches, if you could
submit the non sunxi specific bits of that upstream asap that would be great.
I'm happy you have rememberd it, I have actually, TWICE.
The first time there was some talk about it being required at all, which Wolfgang even said it might/should [1].
The second time there was even less interest [2]. I've hoped Henrik would pick up on it as he should have some weight in the u-boot community ... but alas ..
Bummer, well I guess I'll just send it upstream with the rest of the sunxi
support then when I get around to it. Note that it may be a while before
I get around to this (if you're up to doing this my invite for discussing
this over some drinks still stands).

Regards,

Hans
Ian Campbell
2014-02-12 10:29:36 UTC
Permalink
Post by Hans de Goede
Hi,
<snip>
Post by Ian Campbell
I was a bit torn over what to do with this and the first patch ("Provide
a weak scsi_init hook") since they are both essentially upstream fodder
already _except_ that they wouldn't be being presented at the same time
as a consumer of the change.
I met one of the core u-boot developers, Marek Vasut at decvonf.cz and
ended up talking quite a bit with him about upstreaming sunxi-u-boot.
I think that it is safe to say that they are definitively interested in
fixes like this going upstream immediately. So please do submit these
upstream as soon as you feel they are ready to go upstream.
Upstream also is the proper place to discuss whether making the ahci
probe delay longer makes sense for all boards, or if we need to make it
an #ifdef SUXNI thing.
[...]

OK, I'll copy the series to the mainline list as I resend.
Post by Hans de Goede
So now that the cat is out of the bag wrt me talking to Marek, yes there
now is something resembling a plan for upstreaming u-boot sunxi.
Can you share the details?
Post by Hans de Goede
I won't
start working on this until I've finished getting all the kernel bits
I've currently in-flight upstream as I don't want to open yet another
"battle front". If anyone wants to beat me working on this they are
very much invited to do so (*).
FWIW I've been mulling this over since it was discussed over dinner at
FOSDEM.

What I've thought of doing is creating a rebasing git branch based on
the current mainline base used in the sunxi branch.

The contents of the mainlining branch would be a series of cleaned up
commits suitable for sending upstream.

The mainlining and sunxi branches can then be diffed against each other
to see what still remains to be done, which anyone can do in parallel
for the stuff they care about.

Any clean ups would need to appear in the sunxi branch, but this would
happen naturally as things got upstreamed and merged back or could
happen explicitly by patching sunxi too.

When some portion of the mainlining branch gets upstreamed then sunxi
merges a new upstream and the mainlining branch is rebased, repeat until
the diff is uninteresting.

What I've actually got right now is a branch which can FEL boot on
exactly sun7i cubietruck i.e. no sun[1234556]i, single board, bare
minimum drivers, not even MMC boot yet, but including the core SPL
framework, clocks, timers, board.c etc.

Functionalitywise it's not very interesting but it is a baseline
discussion/review and for others to run git diff against and extract the
bits they care about (and/or have hardware for etc), which can then be
added to the branch. IOW it's intended as a seed and I'm not offering to
do all the work myself ;-).

I haven't yet turned it into a potentially upstreamable series of
commits, I was waiting till I got round to writing this mail to see if
that would be worthwhile.

Ian.
Ian Campbell
2014-02-12 10:42:29 UTC
Permalink
Post by Ian Campbell
What I've actually got right now is a branch which can FEL boot on
I should say that I haven't actually invested more than 1 hours time and
energy into this so far, so if the approach doesn't work or the plan is
different feel free to tell me to stop, I won't mind.

Ian.
Marek Vasut
2014-02-12 10:44:46 UTC
Permalink
Post by Ian Campbell
Post by Hans de Goede
Hi,
<snip>
Post by Ian Campbell
I was a bit torn over what to do with this and the first patch
("Provide a weak scsi_init hook") since they are both essentially
upstream fodder already _except_ that they wouldn't be being presented
at the same time as a consumer of the change.
I met one of the core u-boot developers, Marek Vasut at decvonf.cz and
ended up talking quite a bit with him about upstreaming sunxi-u-boot.
I think that it is safe to say that they are definitively interested in
fixes like this going upstream immediately. So please do submit these
upstream as soon as you feel they are ready to go upstream.
Upstream also is the proper place to discuss whether making the ahci
probe delay longer makes sense for all boards, or if we need to make it
an #ifdef SUXNI thing.
[...]
OK, I'll copy the series to the mainline list as I resend.
Post by Hans de Goede
So now that the cat is out of the bag wrt me talking to Marek, yes there
now is something resembling a plan for upstreaming u-boot sunxi.
Can you share the details?
Post by Hans de Goede
I won't
start working on this until I've finished getting all the kernel bits
I've currently in-flight upstream as I don't want to open yet another
"battle front". If anyone wants to beat me working on this they are
very much invited to do so (*).
FWIW I've been mulling this over since it was discussed over dinner at
FOSDEM.
What I've thought of doing is creating a rebasing git branch based on
the current mainline base used in the sunxi branch.
The current u-boot-sunxi is completely un-rebasable as far as I can tell.

Like discussed with Hans, I'd suggest you submit a bare minimal machine upstream
so there's some starting point and add the remaining bits later on. You might
also end up re-engineering the fundamentals of the sunxi port, which seem to be
rotting a little (all those custom linker scripts, custom base addresses that
might be unified, weird position of the stack etc).

THanks!

Best regards,
Marek Vasut
Ian Campbell
2014-02-12 11:05:48 UTC
Permalink
Post by Marek Vasut
Post by Ian Campbell
What I've thought of doing is creating a rebasing git branch based on
the current mainline base used in the sunxi branch.
The current u-boot-sunxi is completely un-rebasable as far as I can tell.
What I meant was to create a completely fresh branch based on mainline
u-boot. It should use the same base revision as the latest upstream
version merged into the sunxi branch, to facilitate diffing, but
otherwise has basically nothing to do with it so far as git history goes
(other than taking care about crediting the right people).
Post by Marek Vasut
Like discussed with Hans, I'd suggest you submit a bare minimal machine upstream
so there's some starting point and add the remaining bits later on.
Right, that was what I was suggesting too, and in fact what I've made a
start on doing.
Post by Marek Vasut
You might also end up re-engineering the fundamentals of the sunxi
port, which seem to be rotting a little (all those custom linker
scripts, custom base addresses that might be unified, weird position
of the stack etc).
Sure, I think it is inevitable that upstream review will result in some,
possibly even major, changes.

Ian.
Marek Vasut
2014-02-12 11:14:27 UTC
Permalink
Post by Ian Campbell
Post by Marek Vasut
Post by Ian Campbell
What I've thought of doing is creating a rebasing git branch based on
the current mainline base used in the sunxi branch.
The current u-boot-sunxi is completely un-rebasable as far as I can tell.
What I meant was to create a completely fresh branch based on mainline
u-boot. It should use the same base revision as the latest upstream
version merged into the sunxi branch, to facilitate diffing, but
otherwise has basically nothing to do with it so far as git history goes
(other than taking care about crediting the right people).
Post by Marek Vasut
Like discussed with Hans, I'd suggest you submit a bare minimal machine
upstream so there's some starting point and add the remaining bits later
on.
Right, that was what I was suggesting too, and in fact what I've made a
start on doing.
Post by Marek Vasut
You might also end up re-engineering the fundamentals of the sunxi
port, which seem to be rotting a little (all those custom linker
scripts, custom base addresses that might be unified, weird position
of the stack etc).
Sure, I think it is inevitable that upstream review will result in some,
possibly even major, changes.
OK, thanks.

Best regards,
Marek Vasut
Henrik Nordström
2014-02-12 13:26:31 UTC
Permalink
Post by Marek Vasut
The current u-boot-sunxi is completely un-rebasable as far as I can tell.
Indeed. It's an incremental branch over a very long time with repeated
merges from master.

The sunxi-patchqueue branch should be considerably easier to rebase, but
it lags behind a bit as I haven't had time to update it since august.

The normal work procedure is that changes are cherry-picked from sunxi
to sunxi-patchqueue, then squashed into their relevant patchsets and
whole patchset rebased. Then diffed to sunxi to make sure the two are
aligned (minus some stuff that is not meant to be mainlined)

Regards
Henrik
Henrik Nordström
2014-02-12 13:32:06 UTC
Permalink
Post by Henrik Nordström
The sunxi-patchqueue branch should be considerably easier to rebase, but
it lags behind a bit as I haven't had time to update it since august.
Looking again it's not really that old. Last rebase of sunxi-patchqueue
was v2014.01-rc1.

But it does lag behind the sunxi branch a bit at the moment.

Regards
Henrik
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Hans de Goede
2014-02-12 15:59:47 UTC
Permalink
Hi,
Post by Henrik Nordström
Post by Henrik Nordström
The sunxi-patchqueue branch should be considerably easier to rebase, but
it lags behind a bit as I haven't had time to update it since august.
Looking again it's not really that old. Last rebase of sunxi-patchqueue
was v2014.01-rc1.
But it does lag behind the sunxi branch a bit at the moment.
Ah, cool that is a very useful branch!

So I've been looking at the output of
git diff v2014.01-rc1..HEAD > diff

In a u-boot-sunxi sunxi branch checkout a bit, and this has lead to some
questions:

1) Is the addition of arch/arm/cpu/armv7/cmd_boot.c really necessary,
it is the same as common/cmd_boot.c except for the invalidate_icache_all()
call which according to Marek should not be necessary.

2) Is the addition of the empty arch/arm/cpu/armv7/sunxi/start.c really
necessary? Certainly there must be a cleaner way to deal with this ?

Regards,

Hans
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Henrik Nordström
2014-02-13 17:51:10 UTC
Permalink
Post by Hans de Goede
1) Is the addition of arch/arm/cpu/armv7/cmd_boot.c really necessary,
it is the same as common/cmd_boot.c except for the invalidate_icache_all()
call which according to Marek should not be necessary.
It is for standalone programs started by go. But it's discussed
separately from sunxi, see u-boot archives.

On armv7 the icache is enabled.
Post by Hans de Goede
2) Is the addition of the empty arch/arm/cpu/armv7/sunxi/start.c really
necessary? Certainly there must be a cleaner way to deal with this ?
It's to simplify the FEL target which don't need start.o.

Regards
Henrik
Hans de Goede
2014-02-14 19:13:52 UTC
Permalink
Hi,
Post by Henrik Nordström
Post by Hans de Goede
1) Is the addition of arch/arm/cpu/armv7/cmd_boot.c really necessary,
it is the same as common/cmd_boot.c except for the invalidate_icache_all()
call which according to Marek should not be necessary.
It is for standalone programs started by go. But it's discussed
separately from sunxi, see u-boot archives.
So if this is a generic u-boot problem, only affecting the go command,
I guess getting this upstream is a low priority thing ?

Maybe we should have 2 patch queues one with generic bug fixes, and one
with sunxi specific bits ?
Post by Henrik Nordström
Post by Hans de Goede
2) Is the addition of the empty arch/arm/cpu/armv7/sunxi/start.c really
necessary? Certainly there must be a cleaner way to deal with this ?
It's to simplify the FEL target which don't need start.o.
I was thinking that the whole thing of having separate board configs for
fex / non fex is ugly. What we ought to do is just build 2 versions of
the SPL, so do 3 instead of 2 build rounds.

Regards,

Hans
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Henrik Nordström
2014-02-14 23:42:01 UTC
Permalink
Post by Hans de Goede
So if this is a generic u-boot problem, only affecting the go command,
I guess getting this upstream is a low priority thing ?
Maybe we should have 2 patch queues one with generic bug fixes, and one
with sunxi specific bits ?
I try to keep the number of non-sunxi stuff at a minimum.
Post by Hans de Goede
I was thinking that the whole thing of having separate board configs for
fex / non fex is ugly. What we ought to do is just build 2 versions of
the SPL, so do 3 instead of 2 build rounds.
That would work, but is a rather intrusive change to the common build
system and did not feel warranted for such special target.

Additionally the default environment in main u-boot differs slightly to
support direct RAM boots in FEL mode which makes no sense to have in
other u-boot builds.

Regards
Henrik

Henrik Nordström
2014-02-12 13:19:13 UTC
Permalink
Post by Ian Campbell
What I've thought of doing is creating a rebasing git branch based on
the current mainline base used in the sunxi branch.
The contents of the mainlining branch would be a series of cleaned up
commits suitable for sending upstream.
We do have a sunxi-patchqueu branch in the u-boot-sunxi repository where
the changes are being bundled up in suitable chunks. It's lagging behind
a bit compared to the sunxi branch and the patch split is not 100% yet.

https://github.com/linux-sunxi/u-boot-sunxi/tree/sunxi-patchqueue

It is based on the cleanup work done earlier together with Hans and
others.
Post by Ian Campbell
The mainlining and sunxi branches can then be diffed against each other
to see what still remains to be done, which anyone can do in parallel
for the stuff they care about.
Yes, this is done...
Post by Ian Campbell
When some portion of the mainlining branch gets upstreamed then sunxi
merges a new upstream and the mainlining branch is rebased, repeat until
the diff is uninteresting.
Yes..
Post by Ian Campbell
What I've actually got right now is a branch which can FEL boot on
exactly sun7i cubietruck i.e. no sun[1234556]i, single board, bare
minimum drivers, not even MMC boot yet, but including the core SPL
framework, clocks, timers, board.c etc.
Great!

Regards
Henrik
Ian Campbell
2014-02-12 13:50:29 UTC
Permalink
Post by Henrik Nordström
Post by Ian Campbell
What I've thought of doing is creating a rebasing git branch based on
the current mainline base used in the sunxi branch.
The contents of the mainlining branch would be a series of cleaned up
commits suitable for sending upstream.
We do have a sunxi-patchqueu branch in the u-boot-sunxi repository where
the changes are being bundled up in suitable chunks.
I wasn't aware of that branch. I'll check it out.

Ian.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Hans de Goede
2014-02-12 15:55:53 UTC
Permalink
Hi Ian,
<snip>
Post by Ian Campbell
Post by Hans de Goede
So now that the cat is out of the bag wrt me talking to Marek, yes there
now is something resembling a plan for upstreaming u-boot sunxi.
Can you share the details?
So my / our plan was to do a:
git diff v2014.01-rc1..HEAD > diff

In a u-boot-sunxi sunxi branch checkout, and then clean up diff, hack
it into pieces, remove all boards except for one reference board for
each of sun4i / sun5i / sun7i. Run git blame on all the new files
to be able to do proepr attribution, create commit messages with
author + extra attribution based on git blame results and go from
there.

But hno's sunxi-patchqueue branch probably is a much better start!

Regards,

Hans
Marek Vasut
2014-02-12 16:00:37 UTC
Permalink
Post by Hans de Goede
Hi Ian,
<snip>
Post by Ian Campbell
Post by Hans de Goede
So now that the cat is out of the bag wrt me talking to Marek, yes there
now is something resembling a plan for upstreaming u-boot sunxi.
Can you share the details?
git diff v2014.01-rc1..HEAD > diff
In a u-boot-sunxi sunxi branch checkout, and then clean up diff, hack
it into pieces, remove all boards except for one reference board for
each of sun4i / sun5i / sun7i. Run git blame on all the new files
to be able to do proepr attribution, create commit messages with
author + extra attribution based on git blame results and go from
there.
But hno's sunxi-patchqueue branch probably is a much better start!
You need to sync the two branches you have first though ...

Best regards,
Marek Vasut
Henrik Nordström
2014-02-13 21:37:48 UTC
Permalink
Post by Marek Vasut
You need to sync the two branches you have first though ...
Sure. But you need to do most of the same work anyway to preserve
reasonable pieces of history on who have contributed to what.

Regards
Henrik
Hans de Goede
2014-02-12 16:02:07 UTC
Permalink
Hi,
<snip>
Post by Ian Campbell
Post by Hans de Goede
So now that the cat is out of the bag wrt me talking to Marek, yes there
now is something resembling a plan for upstreaming u-boot sunxi.
Can you share the details?
p.s.

I think it is great that you've been looking into this, please continue
doing so and feel free to go full steam ahead on this. I put this on
my todo list because someone had to, but to be honest I really don't have
the time for this in the foreseeable future, so I say check with hno
what his plans are and then go for it!

I can probably make a couple of hours available for this here and then,
so if you need help with something specific, ie testing on some boards
you don't have or whatever feel free to ask for help and I'll do my best.

Regards,

Hans
Marek Vasut
2014-02-12 10:41:35 UTC
Permalink
Post by Hans de Goede
Hi,
<snip>
Post by Ian Campbell
I was a bit torn over what to do with this and the first patch ("Provide
a weak scsi_init hook") since they are both essentially upstream fodder
already _except_ that they wouldn't be being presented at the same time
as a consumer of the change.
I met one of the core u-boot developers, Marek Vasut at decvonf.cz and
ended up talking quite a bit with him about upstreaming sunxi-u-boot.
I think that it is safe to say that they are definitively interested in
fixes like this going upstream immediately. So please do submit these
upstream as soon as you feel they are ready to go upstream.
Upstream also is the proper place to discuss whether making the ahci
probe delay longer makes sense for all boards, or if we need to make it
an #ifdef SUXNI thing.
Thanks.

Just make sure you don't bring in another DWC AHCI driver ;-) I think we have
three already and someone should start looking into cleaning this up too.

Best regards,
Marek Vasut
Ian Campbell
2014-02-12 12:29:23 UTC
Permalink
Post by Marek Vasut
Just make sure you don't bring in another DWC AHCI driver ;-) I think we have
three already and someone should start looking into cleaning this up too.
FWIW I was just reusing the existing "platform AHCI" stuff, no new
driver here ;-).

Ian.
Ian Campbell
2014-02-07 16:15:35 UTC
Permalink
This enables the necessary clocks, in AHB0 and in PLL6_CFG.

The bulk of the code is taken from the Linux ahci sunxi platform driver
patches, adjusted for u-boot.

This adds the "PORT_DMA" tweaks to the core driver, under a suitable
ifdef.

Tested on and enabled for the cubietruck.

Signed-off-by: Ian Campbell <ijc-***@public.gmane.org>
---
arch/arm/cpu/armv7/sunxi/clock.c | 4 ++
boards.cfg | 4 +-
drivers/block/Makefile | 1 +
drivers/block/ahci.c | 15 ++++++-
drivers/block/ahci_sunxi.c | 95 ++++++++++++++++++++++++++++++++++++++++
include/ahci.h | 9 ++++
include/configs/sunxi-common.h | 10 +++++
7 files changed, 135 insertions(+), 3 deletions(-)
create mode 100644 drivers/block/ahci_sunxi.c

diff --git a/arch/arm/cpu/armv7/sunxi/clock.c b/arch/arm/cpu/armv7/sunxi/clock.c
index 06bc283..2cc274b 100644
--- a/arch/arm/cpu/armv7/sunxi/clock.c
+++ b/arch/arm/cpu/armv7/sunxi/clock.c
@@ -51,6 +51,10 @@ static void clock_init_safe(void)
#ifdef CONFIG_SUN7I
writel(0x1 << 6 | readl(&ccm->ahb_gate0), &ccm->ahb_gate0);
writel(0x1 << 31 | readl(&ccm->pll6_cfg), &ccm->pll6_cfg);
+#ifdef CONFIG_SCSI_AHCI_SUNXI
+ writel(0x1 << 25 |readl(&ccm->ahb_gate0), &ccm->ahb_gate0);
+ writel(0x1 << 14 | readl(&ccm->pll6_cfg), &ccm->pll6_cfg);
+#endif
#endif
}
#endif
diff --git a/boards.cfg b/boards.cfg
index 100acc8..c94d3f2 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -366,8 +366,8 @@ Active arm armv7 sunxi - sunxi
Active arm armv7 sunxi - sunxi Cubieboard sun4i:CUBIEBOARD,SPL,SUNXI_EMAC,STATUSLED=244,STATUSLED1=245 -
Active arm armv7 sunxi - sunxi Cubieboard2 sun7i:CUBIEBOARD2,SPL,SUNXI_GMAC,STATUSLED=244,STATUSLED1=245,FAST_MBUS -
Active arm armv7 sunxi - sunxi Cubieboard2_FEL sun7i:CUBIEBOARD2,SPL_FEL,SUNXI_GMAC,STATUSLED=244,STATUSLED1=245,FAST_MBUS -
-Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,SUNXI_GMAC,RGMII,STATUSLED=245,STATUSLED1=244,STATUSLED2=235,STATUSLED3=231,FAST_MBUS -
-Active arm armv7 sunxi - sunxi Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL,SUNXI_GMAC,RGMII,STATUSLED=245,STATUSLED1=244,STATUSLED2=235,STATUSLED3=231,FAST_MBUS -
+Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,SUNXI_GMAC,RGMII,STATUSLED=245,STATUSLED1=244,STATUSLED2=235,STATUSLED3=231,FAST_MBUS,SATAPWR=SUNXI_GPH(12) -
+Active arm armv7 sunxi - sunxi Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL,SUNXI_GMAC,RGMII,STATUSLED=245,STATUSLED1=244,STATUSLED2=235,STATUSLED3=231,FAST_MBUS,SATAPWR=SUNXI_GPH(12) -
Active arm armv7 sunxi - sunxi Cubieboard_512 sun4i:CUBIEBOARD_512,SPL,SUNXI_EMAC,STATUSLED=244,STATUSLED1=245 -
Active arm armv7 sunxi - sunxi Cubieboard_FEL sun4i:CUBIEBOARD,SPL_FEL,SUNXI_EMAC,STATUSLED=244,STATUSLED1=245 -
Active arm armv7 sunxi - sunxi DNS_M82 sun4i:DNS_M82,SPL -
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 4e94378..e77188b 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -6,6 +6,7 @@
#

obj-$(CONFIG_SCSI_AHCI) += ahci.o
+obj-$(CONFIG_SCSI_AHCI_SUNXI) += ahci_sunxi.o
obj-$(CONFIG_ATA_PIIX) += ata_piix.o
obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
obj-$(CONFIG_FSL_SATA) += fsl_sata.o
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 90a0719..32be726 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -213,6 +213,13 @@ static int ahci_host_init(struct ahci_probe_ent *probe_ent)
msleep(500);
}

+#ifdef CONFIG_SCSI_AHCI_SUNXI
+ tmp = readl(port_mmio + PORT_DMA);
+ tmp &= ~PORT_DMA_SETUP_MASK;
+ tmp |= PORT_DMA_SETUP_INIT;
+ writel_with_flush(tmp, port_mmio + PORT_DMA);
+#endif
+
/* Add the spinup command to whatever mode bits may
* already be on in the command register.
*/
@@ -490,7 +497,7 @@ static int ahci_port_start(u8 port)
struct ahci_ioports *pp = &(probe_ent->port[port]);
volatile u8 *port_mmio = (volatile u8 *)pp->port_mmio;
u32 port_status;
- u32 mem;
+ u32 mem, tmp;

debug("Enter start port: %d\n", port);
port_status = readl(port_mmio + PORT_SCR_STAT);
@@ -540,6 +547,12 @@ static int ahci_port_start(u8 port)

writel_with_flush(pp->rx_fis, port_mmio + PORT_FIS_ADDR);

+#ifdef CONFIG_SCSI_AHCI_SUNXI
+ tmp = readl(port_mmio + PORT_DMA);
+ tmp &= ~PORT_DMA_SETUP_MASK;
+ tmp |= PORT_DMA_SETUP_INIT;
+ writel_with_flush(tmp, port_mmio + PORT_DMA);
+#endif
writel_with_flush(PORT_CMD_ICC_ACTIVE | PORT_CMD_FIS_RX |
PORT_CMD_POWER_ON | PORT_CMD_SPIN_UP |
PORT_CMD_START, port_mmio + PORT_CMD);
diff --git a/drivers/block/ahci_sunxi.c b/drivers/block/ahci_sunxi.c
new file mode 100644
index 0000000..2ae742d
--- /dev/null
+++ b/drivers/block/ahci_sunxi.c
@@ -0,0 +1,95 @@
+#include <common.h>
+#include <ahci.h>
+#include <scsi.h>
+#include <asm/io.h>
+#include <asm/gpio.h>
+
+#define AHCI_BISTAFR 0x00a0
+#define AHCI_BISTCR 0x00a4
+#define AHCI_BISTFCTR 0x00a8
+#define AHCI_BISTSR 0x00ac
+#define AHCI_BISTDECR 0x00b0
+#define AHCI_DIAGNR0 0x00b4
+#define AHCI_DIAGNR1 0x00b8
+#define AHCI_OOBR 0x00bc
+#define AHCI_PHYCS0R 0x00c0
+#define AHCI_PHYCS1R 0x00c4
+#define AHCI_PHYCS2R 0x00c8
+#define AHCI_TIMER1MS 0x00e0
+#define AHCI_GPARAM1R 0x00e8
+#define AHCI_GPARAM2R 0x00ec
+#define AHCI_PPARAMR 0x00f0
+#define AHCI_TESTR 0x00f4
+#define AHCI_VERSIONR 0x00f8
+#define AHCI_IDR 0x00fc
+#define AHCI_RWCR 0x00fc
+#define AHCI_P0DMACR 0x0170
+#define AHCI_P0PHYCR 0x0178
+#define AHCI_P0PHYSR 0x017c
+
+#define BIT(x) (1<<x)
+static u32 sunxi_getbits(u8 *reg, u8 mask, u8 shift)
+{
+ return (readl(reg) >> shift) & mask;
+}
+
+static int sunxi_ahci_phy_init(u32 base)
+{
+ u8 *reg_base = (u8 *)base;
+ u32 reg_val;
+ int timeout;
+
+ /* This magic is from the original code */
+ writel(0, reg_base + AHCI_RWCR);
+ mdelay(5);
+
+ setbits_le32(reg_base + AHCI_PHYCS1R, BIT(19));
+ clrsetbits_le32(reg_base + AHCI_PHYCS0R,
+ (0x7 << 24),
+ (0x5 << 24) | BIT(23) | BIT(18));
+ clrsetbits_le32(reg_base + AHCI_PHYCS1R,
+ (0x3 << 16) | (0x1f << 8) | (0x3 << 6),
+ (0x2 << 16) | (0x6 << 8) | (0x2 << 6));
+ setbits_le32(reg_base + AHCI_PHYCS1R, BIT(28) | BIT(15));
+ clrbits_le32(reg_base + AHCI_PHYCS1R, BIT(19));
+ clrsetbits_le32(reg_base + AHCI_PHYCS0R,
+ (0x7 << 20), (0x3 << 20));
+ clrsetbits_le32(reg_base + AHCI_PHYCS2R,
+ (0x1f << 5), (0x19 << 5));
+ mdelay(5);
+
+ setbits_le32(reg_base + AHCI_PHYCS0R, (0x1 << 19));
+
+ timeout = 0x100000;
+ do {
+ reg_val = sunxi_getbits(reg_base + AHCI_PHYCS0R, 0x7, 28);
+ } while (--timeout && (reg_val != 0x2));
+ if (!timeout)
+ printf("PHY power up failed.\n");
+
+ setbits_le32(reg_base + AHCI_PHYCS2R, (0x1 << 24));
+
+ timeout = 0x100000;
+ do {
+ reg_val = sunxi_getbits(reg_base + AHCI_PHYCS2R, 0x1, 24);
+ } while (--timeout && reg_val);
+ if (!timeout)
+ printf("PHY calibration failed.\n");
+ mdelay(15);
+
+ writel(0x7, reg_base + AHCI_RWCR);
+
+ return 0;
+}
+
+void scsi_init(void)
+{
+ printf("SUNXI SCSI INIT\n");
+#ifdef CONFIG_SATAPWR
+ gpio_direction_output(CONFIG_SATAPWR, 1);
+#endif
+
+ sunxi_ahci_phy_init(SUNXI_SATA_BASE);
+
+ ahci_init(SUNXI_SATA_BASE);
+}
diff --git a/include/ahci.h b/include/ahci.h
index 90e8509..c94689c 100644
--- a/include/ahci.h
+++ b/include/ahci.h
@@ -58,6 +58,15 @@
#define PORT_SCR_ERR 0x30 /* SATA phy register: SError */
#define PORT_SCR_ACT 0x34 /* SATA phy register: SActive */

+#ifdef CONFIG_SCSI_AHCI_SUNXI
+#define PORT_DMA 0x70 /* SUNXI specific "DMA register" */
+
+#define PORT_DMA_SETUP_OFFSET 8 /* dma setup offset */
+#define PORT_DMA_SETUP_MASK (0xff << PORT_DMA_SETUP_OFFSET) /* dma mask */
+#define PORT_DMA_SETUP_INIT (0x44 << PORT_DMA_SETUP_OFFSET)
+#endif
+
+
/* PORT_IRQ_{STAT,MASK} bits */
#define PORT_IRQ_COLD_PRES (1 << 31) /* cold presence detect */
#define PORT_IRQ_TF_ERR (1 << 30) /* task file error */
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index d46a43f..dbfbba9 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -88,6 +88,16 @@
#define CONFIG_SYS_NAND_BASE 0x00
#endif

+#define CONFIG_LIBATA
+#define CONFIG_SCSI_AHCI
+#define CONFIG_SCSI_AHCI_PLAT
+#define CONFIG_SCSI_AHCI_SUNXI
+#define CONFIG_SYS_SCSI_MAX_SCSI_ID 1
+#define CONFIG_SYS_SCSI_MAX_LUN 1
+#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \
+ CONFIG_SYS_SCSI_MAX_LUN)
+#define CONFIG_CMD_SCSI
+
#define CONFIG_CMD_MEMORY
#define CONFIG_CMD_SETEXPR
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
Hans de Goede
2014-02-07 16:36:12 UTC
Permalink
Hi,
Post by Ian Campbell
This is the result of my afternoons hacking at the urlab hacklab in
Brussels before FOSDEM, thanks for hosting us guys!
This uses the existing ahci platform support in u-boot. Most of the
siunxi specific code comes from the Linux platform patches.
I've tested this only on cubietruck.
Hmm, I notice that you unconditionally define CONFIG_SUNXI_AHCI for
all sunxi boards. This is very wrong for sun5i since there never is
an AHCI controller there, wrong for sun4i since you've not added
any sata clock setup for sun4i, and somewhat wrong for sun7i since
there enabling it only makes sense on boards which have a sata connector.

Can you please respin this patch-set and make the enabling of AHCI done
something through boards.cfg ?

With that fixed I think it looks good, and if there are no objections I'll
happily merge a fixed version into u-boot-sunxi.

Thanks,

Hans
Ian Campbell
2014-02-10 11:13:11 UTC
Permalink
Post by Hans de Goede
Hi,
Post by Ian Campbell
This is the result of my afternoons hacking at the urlab hacklab in
Brussels before FOSDEM, thanks for hosting us guys!
This uses the existing ahci platform support in u-boot. Most of the
siunxi specific code comes from the Linux platform patches.
I've tested this only on cubietruck.
Hmm, I notice that you unconditionally define CONFIG_SUNXI_AHCI for
all sunxi boards. This is very wrong for sun5i since there never is
an AHCI controller there, wrong for sun4i since you've not added
any sata clock setup for sun4i, and somewhat wrong for sun7i since
there enabling it only makes sense on boards which have a sata connector.
Damn, I knew there was something else I meant to go back and cleanup.
Post by Hans de Goede
Can you please respin this patch-set and make the enabling of AHCI done
something through boards.cfg ?
Sure!

Ian.
Post by Hans de Goede
With that fixed I think it looks good, and if there are no objections I'll
happily merge a fixed version into u-boot-sunxi.
Thanks,
Hans
Continue reading on narkive:
Loading...