Re: [linux-sunxi] Latest kernel does not find SD card

[Chris Obbard]

Hi,


>
> > Mmh, I guess it's related to:
> > commit 1396007286b1e2fd5dd10ae6a5ccaaaed51ab762
> > Author: Maxime Ripard 
> > Date:   Mon Oct 9 22:53:39 2017 +0200
> >
> > pinctrl: sunxi: Enforce the strict mode by default
> >
> > This is probably due to the fact that we reference PF6 twice:
> >
> > arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts:
> >>  {
> >> pinctrl-names = "default";
> >> pinctrl-0 = <_pins_a>, <_cd_pin>;
> >
> > Once here:^^
> >
>
> Drop this one.
>
> >> vmmc-supply = <_vcc3v3>;
> >> bus-width = <4>;
> >> cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> >
> > And then again here:  
> >
>
> And keep this one.
>
> ChenYu
>
>
Awesome, removing that line and recompiling sorted it.

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

[linux-sunxi] Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding

[Andre Przywara]

Hi Thierry,

thanks for the reply and having this discussion!

On 24/11/17 13:31, Thierry Reding wrote:
> On Fri, Nov 24, 2017 at 12:04:12PM +, Andre Przywara wrote:
>> Hi,
>>
>> (adding linux-sunxi, which I forgot at the initial post).
>>
>> On 24/11/17 10:52, Thierry Reding wrote:
>>> On Fri, Nov 24, 2017 at 11:19:52AM +0100, Linus Walleij wrote:
 On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara  
 wrote:

> So far all the Allwinner pinctrl drivers provided a table in the
> kernel to describe all the pins and the link between the pinctrl functions
> names (strings) and their respective mux values (register values).
>
> Extend the binding to put those mappings in the DT, so that any SoC can
> describe its pinctrl and GPIO data fully there instead of relying on
> tables.
> This uses a generic compatible name, to be prepended with an SoC
> specific name in the node.
>>>
>>> This seems backwards to me. I'm not sure if Rob has any hard rules on
>>> this, but in the past I've seen a lot of drivers stick this kind of data
>>> into drivers. I personally also prefer that approach because the data is
>>> completely static and there's no way for any specific board to customize
>>> it. So the tables are in fact implied completely by the SoC compatible
>>> string.
>>
>> But this is just *data*, and I believe it is actually package specific.
>> We need the DT to describe the relation between devices and pins anyway,
>> it's just that we use arbitrary strings today instead of the actual
>> register value. This is what the generic pinmux property fixes.
> 
> Register values don't belong in a device tree.

I don't think that's true in a general way. This "pinmux" is already an
accepted property and used for exactly that purpose in other pinctrl
drivers:
$ git grep -l '[^,]pinmux = ' arch/arm{,64}/boot/dts
Plus the fsl,pinmux-ids property, which seems to serve the same purpose.

> And it's totally fine to
> have data in the kernel, too. We do it all the time.

I know, but that does not mean that I need to like it or should avoid
finding better solutions.

>>> Moving all of this data into device tree has a number of disadvantages:
>>>
>>>   * Existing boards already use the static tables in the driver, and the
>>> device trees don't contain any data, so you can't get rid of any of
>>> the existing tables because it would break ABI.
>>
>> Yes, my DeLorean is in the garage, so I can't really change this anymore
>> ;-) But that doesn't mean we have to go on with this forever, I think.
> 
> ABI stability means that, yes, you have to keep maintaining the existing
> tables forever, else old DTBs will stop working if you rip out the
> static tables that drivers depend on.

I think you got me wrong, I am totally not arguing ABI stability and its
consequences. That's why this binding is mostly for newer SoCs, but also
designed to stay compatible with the old binding - that's for other DT
users. Of course we need to keep the tables in the kernel.

>>>   * Moving the table into the DT doesn't actually solve anything because
>>> the driver would have to validate the DT description to make sure it
>>> contains valid data. And in order to validate DT content, the driver
>>> would need a copy of the table anyway.
>>
>> I don't get what the driver would need to validate? We rely on DT
>> information to be correct anyway, otherwise your board just won't work.
>> If the DT is wrong, you have much bigger problems.
> 
> Given that DT is an ABI you should treat it the same way as other ABIs.
> You can't rely on the DT being correct.

But it's not a *user* ABI, where unprivileged users can supply input data.
What else can you rely on then if not on the DT?
By definition you can't be able to validate every bit of it. How would
you know that the reg address of that SATA chip is correct and not
actually pointing to the "set-board-on-fire" device?
And what about those regulators, where it gives you the allowed voltage
range?

> Rather you have to make sure to
> validate it before you hand the content to hardware. If you allow direct
> register access to your hardware via DT and don't validate, it becomes
> really easy for people to exploit it.

If you can change the DT, you already have full control over the system.
Ideally the DT comes as part of the firmware, so if you control this,
there are far less complicated ways to burn down the system. And even if
you supply the DT with your kernel, you must have control and could
trigger the set-fire device via /dev/mem or the like.

> This is not the same as saying we need to be able to fully validate all
> aspects of device tree. We can't, because some information simply does
> not exist outside of DT. However, I think it's a big mistake to trust a
> user to fully know about all intricacies of a pinmux and not make any
> mistake when writing the device tree.

When does a *user* write a device tree? What would 

Re: [linux-sunxi] Latest kernel does not find SD card

[Chen-Yu Tsai]

On Fri, Nov 24, 2017 at 8:24 PM, Andre Przywara  wrote:
> Hi,
>
> adding Maxime.
>
> On 24/11/17 12:15, Chris Obbard wrote:
>> Hi andre,
>>
>> I used the orange pi pc2 dt  from mainline. Which hasn’t changed a while...
>>
>> I’ll try to find the commit I used that found the sd  card from last
>> week when I’m home
>
> Mmh, I guess it's related to:
> commit 1396007286b1e2fd5dd10ae6a5ccaaaed51ab762
> Author: Maxime Ripard 
> Date:   Mon Oct 9 22:53:39 2017 +0200
>
> pinctrl: sunxi: Enforce the strict mode by default
>
> This is probably due to the fact that we reference PF6 twice:
>
> arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts:
>>  {
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins_a>, <_cd_pin>;
>
> Once here:^^
>

Drop this one.

>> vmmc-supply = <_vcc3v3>;
>> bus-width = <4>;
>> cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
>
> And then again here:  
>

And keep this one.

ChenYu

>> status = "okay";
>> };
>
> Maxime, can you say which one should stay?
>
> Cheers,
> Andre.
>
>> On Fri, 24 Nov 2017 at 12:13, Andre Przywara > > wrote:
>>
>> Hi,
>>
>> On 24/11/17 11:58, Chris Obbard wrote:
>> > [2.982523] sun50i-h5-pinctrl 1c20800.pinctrl: pin PF6 already
>> > requested by 1c0f000.mmc; cannot claim for 1c20800.pinctrl:166
>> > [2.993845] sun50i-h5-pinctrl 1c20800.pinctrl: pin-166
>> > (1c20800.pinctrl:166) status -22
>> > [3.002001] sunxi-mmc: probe of 1c0f000.mmc failed with error -22
>>
>> Did you change anything in the DT?
>> Which DT do you actually use? Can you dump it here as well?
>>
>> I will try it later tonight at home.
>>
>> Cheers,
>> Andre.
>>

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

[linux-sunxi] Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding

[Thierry Reding]

On Fri, Nov 24, 2017 at 12:04:12PM +, Andre Przywara wrote:
> Hi,
> 
> (adding linux-sunxi, which I forgot at the initial post).
> 
> On 24/11/17 10:52, Thierry Reding wrote:
> > On Fri, Nov 24, 2017 at 11:19:52AM +0100, Linus Walleij wrote:
> >> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara  
> >> wrote:
> >>
> >>> So far all the Allwinner pinctrl drivers provided a table in the
> >>> kernel to describe all the pins and the link between the pinctrl functions
> >>> names (strings) and their respective mux values (register values).
> >>>
> >>> Extend the binding to put those mappings in the DT, so that any SoC can
> >>> describe its pinctrl and GPIO data fully there instead of relying on
> >>> tables.
> >>> This uses a generic compatible name, to be prepended with an SoC
> >>> specific name in the node.
> > 
> > This seems backwards to me. I'm not sure if Rob has any hard rules on
> > this, but in the past I've seen a lot of drivers stick this kind of data
> > into drivers. I personally also prefer that approach because the data is
> > completely static and there's no way for any specific board to customize
> > it. So the tables are in fact implied completely by the SoC compatible
> > string.
> 
> But this is just *data*, and I believe it is actually package specific.
> We need the DT to describe the relation between devices and pins anyway,
> it's just that we use arbitrary strings today instead of the actual
> register value. This is what the generic pinmux property fixes.

Register values don't belong in a device tree. And it's totally fine to
have data in the kernel, too. We do it all the time.

> > Moving all of this data into device tree has a number of disadvantages:
> > 
> >   * Existing boards already use the static tables in the driver, and the
> > device trees don't contain any data, so you can't get rid of any of
> > the existing tables because it would break ABI.
> 
> Yes, my DeLorean is in the garage, so I can't really change this anymore
> ;-) But that doesn't mean we have to go on with this forever, I think.

ABI stability means that, yes, you have to keep maintaining the existing
tables forever, else old DTBs will stop working if you rip out the
static tables that drivers depend on.

> >   * Moving the table into the DT doesn't actually solve anything because
> > the driver would have to validate the DT description to make sure it
> > contains valid data. And in order to validate DT content, the driver
> > would need a copy of the table anyway.
> 
> I don't get what the driver would need to validate? We rely on DT
> information to be correct anyway, otherwise your board just won't work.
> If the DT is wrong, you have much bigger problems.

Given that DT is an ABI you should treat it the same way as other ABIs.
You can't rely on the DT being correct. Rather you have to make sure to
validate it before you hand the content to hardware. If you allow direct
register access to your hardware via DT and don't validate, it becomes
really easy for people to exploit it.

This is not the same as saying we need to be able to fully validate all
aspects of device tree. We can't, because some information simply does
not exist outside of DT. However, I think it's a big mistake to trust a
user to fully know about all intricacies of a pinmux and not make any
mistake when writing the device tree. What if one of the settings causes
the board to go up in flames?

> Actually we gain something, because we only commit information that can
> actually be tested. Right now we have a lot of information which is
> copied from the manual, and nobody knows if pin H24 on the A10 is really
> PATA-CS1 or not. Plus we have bugs when creating the table, plus
> copy bugs. I found some while grep-ing for patterns - will send
> fixes ASAP.

That's a different matter. If you've got bugs in the tables, then go fix
the tables. However the assumption here is that you've done at least a
minimum of testing and your driver didn't cause your board to go up in
flames. When patches were posted, people had the opportunity to review
the tables for correctness. However, if you put all of the flexibility
into DT, you also put all of the risk there. People may just make some
stupid mistake and cause physical damage to their hardware.

> In the moment all the table gives us is a mapping between a *string* and
> the respective mux register value (per pin), plus the number of pins in
> each bank. This can *easily* be put in the DT and should belong there.

Why? This is data that is implied by the compatible string and static
per SoC. There is no way you can change the mapping in DT. What does
need to go into DT is the configuration of the pinmux, that is, what
function is used for each pin on a given board.

> Actually I believe that the current binding is not correct, because it
> makes those mux strings a part of the binding, though this is not
> documented anywhere. A developer cannot take the 

Re: [linux-sunxi] Latest kernel does not find SD card

[Andre Przywara]

Hi,

adding Maxime.

On 24/11/17 12:15, Chris Obbard wrote:
> Hi andre,
> 
> I used the orange pi pc2 dt  from mainline. Which hasn’t changed a while...
> 
> I’ll try to find the commit I used that found the sd  card from last
> week when I’m home

Mmh, I guess it's related to:
commit 1396007286b1e2fd5dd10ae6a5ccaaaed51ab762
Author: Maxime Ripard 
Date:   Mon Oct 9 22:53:39 2017 +0200

pinctrl: sunxi: Enforce the strict mode by default

This is probably due to the fact that we reference PF6 twice:

arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts:
>  {
> pinctrl-names = "default";
> pinctrl-0 = <_pins_a>, <_cd_pin>;

Once here:^^

> vmmc-supply = <_vcc3v3>;
> bus-width = <4>;
> cd-gpios = < 5 6 GPIO_ACTIVE_LOW>; /* PF6 */

And then again here:  

> status = "okay";
> };

Maxime, can you say which one should stay?

Cheers,
Andre.

> On Fri, 24 Nov 2017 at 12:13, Andre Przywara  > wrote:
> 
> Hi,
> 
> On 24/11/17 11:58, Chris Obbard wrote:
> > [    2.982523] sun50i-h5-pinctrl 1c20800.pinctrl: pin PF6 already
> > requested by 1c0f000.mmc; cannot claim for 1c20800.pinctrl:166
> > [    2.993845] sun50i-h5-pinctrl 1c20800.pinctrl: pin-166
> > (1c20800.pinctrl:166) status -22
> > [    3.002001] sunxi-mmc: probe of 1c0f000.mmc failed with error -22
> 
> Did you change anything in the DT?
> Which DT do you actually use? Can you dump it here as well?
> 
> I will try it later tonight at home.
> 
> Cheers,
> Andre.
> 

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

Re: [linux-sunxi] Latest kernel does not find SD card

[Chris Obbard]

Hi andre,

I used the orange pi pc2 dt  from mainline. Which hasn’t changed a while...

I’ll try to find the commit I used that found the sd  card from last week
when I’m home

Cheers!

On Fri, 24 Nov 2017 at 12:13, Andre Przywara  wrote:

> Hi,
>
> On 24/11/17 11:58, Chris Obbard wrote:
> > [2.982523] sun50i-h5-pinctrl 1c20800.pinctrl: pin PF6 already
> > requested by 1c0f000.mmc; cannot claim for 1c20800.pinctrl:166
> > [2.993845] sun50i-h5-pinctrl 1c20800.pinctrl: pin-166
> > (1c20800.pinctrl:166) status -22
> > [3.002001] sunxi-mmc: probe of 1c0f000.mmc failed with error -22
>
> Did you change anything in the DT?
> Which DT do you actually use? Can you dump it here as well?
>
> I will try it later tonight at home.
>
> Cheers,
> Andre.
>

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

Re: [linux-sunxi] Latest kernel does not find SD card

[Andre Przywara]

Hi,

On 24/11/17 11:58, Chris Obbard wrote:
> [    2.982523] sun50i-h5-pinctrl 1c20800.pinctrl: pin PF6 already
> requested by 1c0f000.mmc; cannot claim for 1c20800.pinctrl:166
> [    2.993845] sun50i-h5-pinctrl 1c20800.pinctrl: pin-166
> (1c20800.pinctrl:166) status -22
> [    3.002001] sunxi-mmc: probe of 1c0f000.mmc failed with error -22

Did you change anything in the DT?
Which DT do you actually use? Can you dump it here as well?

I will try it later tonight at home.

Cheers,
Andre.

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

[linux-sunxi] Re: [RFC PATCH 0/3] pinctrl: sunxi: Add DT-based generic pinctrl driver

[Andre Przywara]

Hi,

On 24/11/17 10:28, Linus Walleij wrote:
> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara  
> wrote:
> 
>> so far the pinctrl driver for supporting a particular Allwinner SoC requires
>> a hardcoded table in the kernel code.
> (...)
>> This series here moves the data encoded in the table so far into the DT 
>> itself,
>> removing the need for a hardcoded table in the kernel.
> (...)
> 
> The DT maintainers have been pretty clear on that they don't like
> using the the DT as a generic fit-all information dump. They
> prefer to look up hardware data from per-soc compatible strings.
> 
> I have been sceptic about it too, on the grounds that I think it
> make configuration and multiplatform kernels easy, while making
> debugging and reading code+device tree hard, also affecting
> maintenance cost.
> 
> I'd like to have Maxime's buy-in before we progress and also some
> discussion on these themes in general.

Indeed this was one of the goals of this series. I can understand were
we came from and that we had those in-kernel tables in the past.
I am just a bit worried that with Allwinner recently playing the SKU
game we end up with tons of tables for only slightly different SoCs (see
the H3 and H5, for instance). And with single image kernels we pile up
quite some *data* in each kernel, which is of little interest for
everyone else.

Also my understanding is that the actual Allwinner pin controller IP
(register map) is very much the same across all SoCs. Mostly the only
difference is the mapping between pins and mux functions, which we
express in the DT already anyway (in the subnodes). And this is really a
poster book example of what DT should be doing: express the specific
mappings of a particular implementation. I don't see why this would need
to be per-board only, if we can pull this up to the SoC level.

>> The approach taken here is to parse the DT and generate the table with
>> the help of additional properties, then hand this table over to the existing
>> driver. This is covered by three basic extensions to the DT binding:
> 
> I adressed this in the bindings patch.
> 
>> The benefit of this series is two-fold:
>> - Future SoCs don't need an in-kernel table anymore. They can describe
>>   everything in the DT,
> 
> It can be debated whether that is really a good thing or actually
> a bad thing for the reasons stated above.

The point is that we already rely on the DT anyway, just that we use a
*string* to specify a certain mux function. The in-kernel table just
maps this to an actual SoC-specific register value. I think the GPIO
subsystem needs the name, hence I am just adding the pinmux property.

> Also an additional bad thing is inconsistency between different
> SoCs.

Well, does that mean that we should never change anything? Consistency
is nice, but should not be an excuse for not improving things. And I
tried to embrace the existing driver by designing this on top of it.

> What we have in the kernel for all-DT is pinctrl-single.c.
> 
> This exists for the case where there is exactly one register per
> pin and all you have is strange macro files from the ASIC people
> that noone understands. OMAP and HiSilicon is using this.
> It's a compromise, I'm not super-happy with that driver at all times
> but it is for a very strongly specified case.
> 
> Would it be possible for you guys to simply use/embrace/extend
> pinctrl-single.c if you want to go this route?

Thanks for the pointer, I will have a look.

> Any higher order of complexity than "one register per pin" I think
> is better handled by open coding it than trying to push things into
> the device tree, because of readability, debuggability and maintenance
> issues.

I don't see how this binding would make this worse.

Cheers,
Andre.

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

[linux-sunxi] Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding

[Andre Przywara]

Hi,

(adding linux-sunxi, which I forgot at the initial post).

On 24/11/17 10:52, Thierry Reding wrote:
> On Fri, Nov 24, 2017 at 11:19:52AM +0100, Linus Walleij wrote:
>> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara  
>> wrote:
>>
>>> So far all the Allwinner pinctrl drivers provided a table in the
>>> kernel to describe all the pins and the link between the pinctrl functions
>>> names (strings) and their respective mux values (register values).
>>>
>>> Extend the binding to put those mappings in the DT, so that any SoC can
>>> describe its pinctrl and GPIO data fully there instead of relying on
>>> tables.
>>> This uses a generic compatible name, to be prepended with an SoC
>>> specific name in the node.
> 
> This seems backwards to me. I'm not sure if Rob has any hard rules on
> this, but in the past I've seen a lot of drivers stick this kind of data
> into drivers. I personally also prefer that approach because the data is
> completely static and there's no way for any specific board to customize
> it. So the tables are in fact implied completely by the SoC compatible
> string.

But this is just *data*, and I believe it is actually package specific.
We need the DT to describe the relation between devices and pins anyway,
it's just that we use arbitrary strings today instead of the actual
register value. This is what the generic pinmux property fixes.

> Moving all of this data into device tree has a number of disadvantages:
> 
>   * Existing boards already use the static tables in the driver, and the
> device trees don't contain any data, so you can't get rid of any of
> the existing tables because it would break ABI.

Yes, my DeLorean is in the garage, so I can't really change this anymore
;-) But that doesn't mean we have to go on with this forever, I think.

>   * Moving the table into the DT doesn't actually solve anything because
> the driver would have to validate the DT description to make sure it
> contains valid data. And in order to validate DT content, the driver
> would need a copy of the table anyway.

I don't get what the driver would need to validate? We rely on DT
information to be correct anyway, otherwise your board just won't work.
If the DT is wrong, you have much bigger problems.

Actually we gain something, because we only commit information that can
actually be tested. Right now we have a lot of information which is
copied from the manual, and nobody knows if pin H24 on the A10 is really
PATA-CS1 or not. Plus we have bugs when creating the table, plus
copy bugs. I found some while grep-ing for patterns - will send
fixes ASAP.

In the moment all the table gives us is a mapping between a *string* and
the respective mux register value (per pin), plus the number of pins in
each bank. This can *easily* be put in the DT and should belong there.

Actually I believe that the current binding is not correct, because it
makes those mux strings a part of the binding, though this is not
documented anywhere. A developer cannot take the binding and write a
working driver or even a DT without looking at the code.
Plus we already changed those names in the past (for instance commit
bc0f566a98c4), basically breaking compatibility.

> I don't think you're going to do yourself any favours by pushing this. I
> also don't see the commit description give any reason why you want to
> move the table into device tree. Do you see any advantages in doing so?

We stop adding tables with SoC specific *data* in the kernel *code*
base. With being boolean Kconfig options, this gets added to every
single-image kernel.

More important: those tables help Linux, but other DT consumers (*BSD,
U-Boot) have to replicate them, which is just wrong, IMHO.

I believe the kernel is a nice collection of really good code for
complicated file systems, high performance network protocols and
sophisticated memory management, among others. It shouldn't be a dumping
ground for arbitrary, very SoC specific information. Cf. LinusT 2011.
DT is out there to fix this, so we should do so.

Cheers,
Andre.

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

Re: [linux-sunxi] Latest kernel does not find SD card

[Chris Obbard]

Hi Andre,

Here's the whole log. I am wondering if changing the cpufreq from u-boot
has messed it up?

U-Boot SPL 2017.09-dirty (Nov 23 2017 - 20:48:36)
> DRAM: 1024 MiB
> Trying to boot from MMC1
> NOTICE:  BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)
> NOTICE:  Configuring SPC Controller
> NOTICE:  BL3-1: v1.0(debug):91f2402
> NOTICE:  BL3-1: Built : 20:35:30, Nov 23 2017
> NOTICE:  SCPI: dummy stub handler, implementation level: 00
> INFO:BL3-1: Initializing runtime services
> INFO:BL3-1: Preparing for EL3 exit to normal world
> INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9
>
> U-Boot 2017.09-dirty (Nov 23 2017 - 20:48:36 +) Allwinner Technology
> CPU:   Allwinner H5 (SUN50I)
> Model: OrangePi PC 2
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
> In:serial
> Out:   serial
> Err:   serial
> Net:   phy interface7
> eth0: ethernet@1c3
> starting USB...
> USB0:   USB EHCI 1.00
> USB1:   USB OHCI 1.0
> scanning bus 0 for devices... 1 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found U-Boot script /boot.scr
> 623 bytes read in 61 ms (9.8 KiB/s)
> ## Executing script at 4fc0
> This is your bootloader speaking.
> ---
> All your sunxi are belong to us.
> ---
> booting...
> 24017408 bytes read in 101840 ms (229.5 KiB/s)
> 14643 bytes read in 95 ms (150.4 KiB/s)
> ## Flattened Device Tree blob at 4fa0
>Booting using the fdt blob at 0x4fa0
>Loading Device Tree to 49ff9000, end 49fff932 ... OK
> Starting kernel ...
> [0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
> [0.00] Linux version 4.14.0-g5a787756b (chris@sunxi-build) (gcc
> version 7.2.0 (Debian 7.2.0-11)) #1 SMP PREEMPT Thu Nov 23 20:25:27 GMT 2017
> [0.00] Machine model: Xunlong Orange Pi PC 2
> [0.00] efi: Getting EFI parameters from FDT:
> [0.00] efi: UEFI not found.
> [0.00] cma: Reserved 16 MiB at 0x7f00
> [0.00] NUMA: No NUMA configuration found
> [0.00] NUMA: Faking a node at [mem
> 0x-0x7fff]
> [0.00] NUMA: NODE_DATA [mem 0x7efe2080-0x7efe3b7f]
> [0.00] Zone ranges:
> [0.00]   DMA  [mem 0x4000-0x7fff]
> [0.00]   Normal   empty
> [0.00] Movable zone start for each node
> [0.00] Early memory node ranges
> [0.00]   node   0: [mem 0x4000-0x7fff]
> [0.00] Initmem setup node 0 [mem
> 0x4000-0x7fff]
> [0.00] psci: probing for conduit method from DT.
> [0.00] psci: PSCIv0.2 detected in firmware.
> [0.00] psci: Using standard PSCI v0.2 function IDs
> [0.00] psci: Trusted OS migration not required
> [0.00] random: fast init done
> [0.00] percpu: Embedded 21 pages/cpu @80003ef87000 s55960 r0
> d30056 u86016
> [0.00] Detected VIPT I-cache on CPU0
> [0.00] CPU features: enabling workaround for ARM erratum 845719
> [0.00] Built 1 zonelists, mobility grouping on.  Total pages:
> 258048
> [0.00] Policy zone: DMA
> [0.00] Kernel command line: console=ttyS0,115200 noinitrd
> root=/dev/mmcblk0p1 rootfstype=ext4 rw rootdelay=5
> [0.00] Memory: 991348K/1048576K available (15100K kernel code,
> 1566K rwdata, 5528K rodata, 1216K init, 484K bss, 40844K reserved, 16384K
> cma-reserved)
> [0.00] Virtual kernel memory layout:
> [0.00] modules : 0x - 0x0800   (
>  128 MB)
> [0.00] vmalloc : 0x0800 - 0x7dffbfff
>  (129022 GB)
> [0.00]   .text : 0x0808 - 0x08f4   (
> 15104 KB)
> [0.00] .rodata : 0x08f4 - 0x094b   (
> 5568 KB)
> [0.00]   .init : 0x094b - 0x095e   (
> 1216 KB)
> [0.00]   .data : 0x095e - 0x09767a00   (
> 1567 KB)
> [0.00].bss : 0x09767a00 - 0x097e0d80   (
>  485 KB)
> [0.00] fixed   : 0x7dfffe7fb000 - 0x7dfffec0   (
> 4116 KB)
> [0.00] PCI I/O : 0x7dfffee0 - 0x7de0   (
>   16 MB)
> [0.00] vmemmap : 0x7e00 - 0x8000   (
> 2048 GB maximum)
> [0.00]   0x7e00 - 0x7e000100   (
>   16 MB actual)
> [0.00] memory  : 0x8000 - 0x80004000   (
> 1024 MB)
> [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
> [0.00] Preemptible hierarchical RCU implementation.
> [0.00]  RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=4.
> [0.00]  Tasks RCU enabled.
> [0.00] 

Re: [linux-sunxi] Latest kernel does not find SD card

[Andre Przywara]

Hi Chris,

On 23/11/17 20:56, Chris Obbard wrote:
> hi guys,
> 
> had a bit of time to debug this tonight. here's my environment:
> 
> u-boot v2017.09 with lower-default-cpufreq-H5.path applied.
> 
> linux mainline, modules built-in, no ramdisk
> 
> it's like it doesn't find the SD card, for whatever reason. 

Can you please dump the whole kernel log? It would be good to see what
the MMC driver has to say and whether there are other issues (pinctrl?
clocks?)

Cheers,
Andre.

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