Re: [linux-sunxi] Olimex A20 SOM EVB + DRM + LCD panel, a (someway working) experience..

[Steffie Chou]

i compiled with the default defconfig for this Graperain linux SOM 
 EVB board and 
booted.

On Tuesday, December 13, 2016 at 10:00:49 AM UTC+8, Jonathan Liu wrote:
>
> Hi Andrea,
>
> On 13 December 2016 at 09:15, Andrea Venturi  > wrote:
>
>>
>>
>> Il giorno lunedì 12 dicembre 2016 03:20:56 UTC+1, Jonathan Liu ha scritto:
>>>
>>> Hi Andrea,
>>>
>>> On 11 December 2016 at 22:48, Andrea Venturi  
>>> wrote:
>>>
 hello,
 
 the only issue is that, after few minutes (10 or so), the display 
 switch to this kind of rendering:

  https://drive.google.com/open?id=0B9QRW6Oy0GmeOGdvM3YyYUtqZHM

 no messages on syslog or console. i'm wondering which kind of "glitch" 
 could bring to this (i suppose some kind of "clock power down"?).

>>> Console blank is 600 seconds by default - kernel will turn off the 
>>> console after 10 minutes of inactivity.
>>> Try adding consoleblank=0 to your kernel command line.
>>>
>>> It is powering down the display engine without powering off the LCD. 
>>>
>>>
>>
>> thanx. indeed it was it. adding 'consoleblank=0'  has made the LCD 
>> rendering stable.
>>
>> BTW i'm wondering if there's eventually a way to turn back on the console.
>>
>  
> Maybe something like this as root?
> setterm --blank poke --term linux < /dev/tty1 > /dev/tty1
>  
>
>>
>> i tried to type something on the serial console /dev/ttyS0 but that 
>> wasn't  enoguh for bringing the display back to life.
>>
>> on the other hand, this setup is unable to power down the display 
>> completely because the backlight is not driven by a GPIO pin but always on.
>>
>> Andrea
>>
>
> Regards,
> Jonathan 
>

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

Re: [linux-sunxi] Re: Recommendations for hardware designer for custom Allwinner based Single Board Computer (SBC)?

[Luc Verhaegen]

On Tue, Jan 03, 2017 at 10:46:42PM -0800, Steffie Chou wrote:
> Graperain Embedded Industrial SBC Single Board Computer 
>  is 8-layer design 
> which makes it more stable. As full as most wanted expansions, the single 
> board computer can be used as final product directly, short time to market. 
> Unlike traditional SBC, Graperain have 32 bit and 64 bit processor, such as 
> Samsung S5P4418(Cortex-A9), S5P6818(Cortex-A53), RK3288(Cortex-A17, coming 
> soon) and other arm single board computer Linux and Android design boards. 
> With it’s full featured I/O, Graperain embedded SBC can be used in a full 
> range of applications, game machines, education board, kiosk etc. In 
> addition of SBC, Graperain offer more services like, custom SBC 
> development, review for custom-design schematic, system engineering tech 
> support, Android, Linux + qt, Ubuntu developing etc, more than you can 
> imagine. 
> 
> On Friday, October 7, 2016 at 7:01:40 PM UTC+8, Senthil Seveelavananan 
> wrote:
> >
> > Hi all,
> >
> > Given this is where people that actually know whats going on hang out, was 
> > hoping people could recommend me companies / people to design a custom 
> > Allwinner based board. 
> >
> > I know about 
> > - Olimex
> > - Banana Pi
> > - Orange Pi
> > - Friendly Pi,
> >
> > all recommendations appreciated. 
> >
> > Many thanks
> >
> > Senthil
> >

Guys. I noticed this a few s too late. This does not sound like 
something that should be propagated on our ML.

What should i do here... block the user?

Luc Verhaegen.

-- 
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: Recommendations for hardware designer for custom Allwinner based Single Board Computer (SBC)?

[Steffie Chou]

Graperain Embedded Industrial SBC Single Board Computer 
 is 8-layer design 
which makes it more stable. As full as most wanted expansions, the single 
board computer can be used as final product directly, short time to market. 
Unlike traditional SBC, Graperain have 32 bit and 64 bit processor, such as 
Samsung S5P4418(Cortex-A9), S5P6818(Cortex-A53), RK3288(Cortex-A17, coming 
soon) and other arm single board computer Linux and Android design boards. 
With it’s full featured I/O, Graperain embedded SBC can be used in a full 
range of applications, game machines, education board, kiosk etc. In 
addition of SBC, Graperain offer more services like, custom SBC 
development, review for custom-design schematic, system engineering tech 
support, Android, Linux + qt, Ubuntu developing etc, more than you can 
imagine. 

On Friday, October 7, 2016 at 7:01:40 PM UTC+8, Senthil Seveelavananan 
wrote:
>
> Hi all,
>
> Given this is where people that actually know whats going on hang out, was 
> hoping people could recommend me companies / people to design a custom 
> Allwinner based board. 
>
> I know about 
> - Olimex
> - Banana Pi
> - Orange Pi
> - Friendly Pi,
>
> all recommendations appreciated. 
>
> Many thanks
>
> Senthil
>

-- 
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: [PATCH 3/5] arm64: dts: sun50i: add MMC nodes

[Chen-Yu Tsai]

On Wed, Jan 4, 2017 at 8:22 AM, André Przywara  wrote:
> On 03/01/17 13:28, Chen-Yu Tsai wrote:
>> On Tue, Jan 3, 2017 at 6:48 PM, André Przywara  
>> wrote:
>>> On 03/01/17 02:52, Chen-Yu Tsai wrote:
>
> Hi Chen-Yu,
>
 On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara  
 wrote:

 A commit message explaining the mmc controllers would be nice.
>>>
>>> OK.
>>>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 
> +++
>  1 file changed, 67 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index e0dcab8..c680566 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -150,6 +150,32 @@
> pins = "PB8", "PB9";
> function = "uart0";
> };
> +
> +   mmc0_pins: mmc0@0 {
> +   pins = "PF0", "PF1", "PF2", "PF3", "PF4", 
> "PF5";
> +   function = "mmc0";
> +   drive-strength = <30>;
> +   };
> +
> +   mmc0_default_cd_pin: mmc0_cd_pin@0 {
> +   pins = "PF6";
> +   function = "gpio_in";
> +   bias-pull-up;
> +   };

 We are starting to drop pinmux nodes for gpio usage.
>>>
>>> And replacing them with what?
>>> Or do you mean they go in the individual board .dts files?
>>> In this case I believe having a default pin defined here would help to
>>> define it in every .dts.
>>
>> Nope. I meant dropping them. Pinmux and gpio are orthogonal. One should not
>> need to specify a gpio pinmux to use it as a gpio. We added them because in
>> the past nothing was preventing someone from claiming an already muxed pin
>> as a gpio. On some platforms this is fine. For sunxi, this breaks the system,
>> as the gpio functions are muxed in.
>>
>> The idea moving forward is that these cases should be guarded in the driver.
>
> Ah, OK, you mean just referencing the pin like:
> cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> in the board DT is enough? And the driver claiming it will (eventually?)
> prevent users from using them via the sysfs interface then?

cd-gpios = 

should be enough to block other devices from claiming a pinmux (pinctrl-N = ...)
on the same pin, or vice versa, whichever claimed it first in kernel space.

Same goes for a pin already claimed by a device through a pinmux. It should
not be claimable as a gpio through the sysfs interface.

>> Of course we would have to deal with existing dtbs, but lets not add any 
>> more.
>>
> +
> +   mmc1_pins: mmc1@0 {
> +   pins = "PG0", "PG1", "PG2", "PG3", "PG4", 
> "PG5";
> +   function = "mmc1";
> +   drive-strength = <30>;
> +   };
> +
> +   mmc2_pins: mmc2@0 {
> +   pins = "PC1", "PC5", "PC6", "PC8", "PC9",
> +  "PC10", "PC11", "PC12", "PC13", 
> "PC14",
> +  "PC15", "PC16";
> +   function = "mmc2";
> +   drive-strength = <30>;
> +   };

 Moreover I think you should split out the pinmux nodes to a separate patch.
>>>
>>> I can surely do, just wondering what's the rationale is behind that?
>>
>> More or less the "do one thing in one patch" rationale. Of course you can
>> claim these are the defaults used in the reference design and pretty much
>> every board out there. Then it makes sense to do them together. :)
>
> Mmmh, probably a misunderstanding, but:
> Those pins are the possible pins that expose the MMC interface. Those
> nodes here name them to allow easy and concise reference by a board DT
> (as in the following patch).
> And in fact in case of the A64 there are _no_ alternative muxes for the
> three MMC controllers: SDC0 is only on PF0-5, SDC1 on PG0-PG5 and SDC2
> on PC1-PC16.
> So it's not a board design question, apart from using a controller or not.
>
> That's why I rather keep them together with the MMC controller nodes.

Cool. Please mention this in the commit log, as in they are the only
possible choice.S ince they are the only choices, please drop the @0
in the node name.

And you might want to rename mmc2_pins to something like
"mmc2_8bit_pins: mmc2_8bit". Who knows, someone might consider using
it for an SD 

[linux-sunxi] Re: [PATCH 3/5] arm64: dts: sun50i: add MMC nodes

[André Przywara]

On 03/01/17 13:28, Chen-Yu Tsai wrote:
> On Tue, Jan 3, 2017 at 6:48 PM, André Przywara  wrote:
>> On 03/01/17 02:52, Chen-Yu Tsai wrote:

Hi Chen-Yu,

>>> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara  
>>> wrote:
>>>
>>> A commit message explaining the mmc controllers would be nice.
>>
>> OK.
>>
 Signed-off-by: Andre Przywara 
 ---
  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 
 +++
  1 file changed, 67 insertions(+)

 diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
 b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
 index e0dcab8..c680566 100644
 --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
 +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
 @@ -150,6 +150,32 @@
 pins = "PB8", "PB9";
 function = "uart0";
 };
 +
 +   mmc0_pins: mmc0@0 {
 +   pins = "PF0", "PF1", "PF2", "PF3", "PF4", 
 "PF5";
 +   function = "mmc0";
 +   drive-strength = <30>;
 +   };
 +
 +   mmc0_default_cd_pin: mmc0_cd_pin@0 {
 +   pins = "PF6";
 +   function = "gpio_in";
 +   bias-pull-up;
 +   };
>>>
>>> We are starting to drop pinmux nodes for gpio usage.
>>
>> And replacing them with what?
>> Or do you mean they go in the individual board .dts files?
>> In this case I believe having a default pin defined here would help to
>> define it in every .dts.
> 
> Nope. I meant dropping them. Pinmux and gpio are orthogonal. One should not
> need to specify a gpio pinmux to use it as a gpio. We added them because in
> the past nothing was preventing someone from claiming an already muxed pin
> as a gpio. On some platforms this is fine. For sunxi, this breaks the system,
> as the gpio functions are muxed in.
> 
> The idea moving forward is that these cases should be guarded in the driver.

Ah, OK, you mean just referencing the pin like:
cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
in the board DT is enough? And the driver claiming it will (eventually?)
prevent users from using them via the sysfs interface then?

> Of course we would have to deal with existing dtbs, but lets not add any more.
> 
 +
 +   mmc1_pins: mmc1@0 {
 +   pins = "PG0", "PG1", "PG2", "PG3", "PG4", 
 "PG5";
 +   function = "mmc1";
 +   drive-strength = <30>;
 +   };
 +
 +   mmc2_pins: mmc2@0 {
 +   pins = "PC1", "PC5", "PC6", "PC8", "PC9",
 +  "PC10", "PC11", "PC12", "PC13", 
 "PC14",
 +  "PC15", "PC16";
 +   function = "mmc2";
 +   drive-strength = <30>;
 +   };
>>>
>>> Moreover I think you should split out the pinmux nodes to a separate patch.
>>
>> I can surely do, just wondering what's the rationale is behind that?
> 
> More or less the "do one thing in one patch" rationale. Of course you can
> claim these are the defaults used in the reference design and pretty much
> every board out there. Then it makes sense to do them together. :)

Mmmh, probably a misunderstanding, but:
Those pins are the possible pins that expose the MMC interface. Those
nodes here name them to allow easy and concise reference by a board DT
(as in the following patch).
And in fact in case of the A64 there are _no_ alternative muxes for the
three MMC controllers: SDC0 is only on PF0-5, SDC1 on PG0-PG5 and SDC2
on PC1-PC16.
So it's not a board design question, apart from using a controller or not.

That's why I rather keep them together with the MMC controller nodes.

>>>
 };

 uart0: serial@1c28000 {
 @@ -240,6 +266,47 @@
 #size-cells = <0>;
 };

 +   mmc0: mmc@1c0f000 {
 +   compatible = "allwinner,sun50i-a64-mmc",
 +"allwinner,sun5i-a13-mmc";
>>>
>>> Given that sun5i doesn't support mmc delay timings, and the A64 has
>>> calibration and delay timings, I wouldn't call them compatible.
>>>
>>> Or are you claiming that for the A64 has a delay of 0 for the
>>> currently supported speeds, so the calibration doesn't really
>>> matter? If so this should be mentioned in the commit message.
>>
>> Yes, that's my observation: Driving it with sun5-a13-mmc just works.
>> This sun5i 

Re: [linux-sunxi] Allwinner H3 without Uboot

[Mark L .]

Thanks Andre,You summed it all.Bye-- Mark13:27, 3 January 2017, "André Przywara" :On 03/01/17 10:34, Mark L. wrote:Hi Mark, I plan not to use U-boot but to take the boot process on charge (after the BROM stage). It means I will write the SPL and the other stuffs to load my custom kernel and simplified OS. Now, according to that page http://linux-sunxi.org/Bootable_SD_card, it means that I will need to put my code at the 8K mark on the SD card. I should have up to the 544K mark to put my code, right?No, at this point there is no DRAM, also the BROM loads only 32KB(starting at 8K). That's why we have the SPL: it initializes DRAM andloads more data from the SD card (using a simple MMC driver).Your "bootloader" would need to do something similar. While this isfeasible, be aware that the DRAM controller is poorly (if at all)documented and in general DRAM controllers are quite "rocket science".Also you would need to drive the MMC controller to load more data.So I'd recommend to use at least the SPL to do that dirty work for you.You should be able to plug your own bootloader instead of the U-Bootproper, I think. Without further changes you would need to wrap it withan U-Boot image header (mkimage).If you are looking for low-level code to be loaded directly by the BROM,uart0-helloworld-sdboot in the sunxi-tools repository would be a goodstart. But you would still need DRAM init and MMC code. Is there something -weird- the CPU will do in my back that prevents me from writing my own boot sequence? (forcing me to use Uboot) I think about a forced jump of some sort.No, it should work as expected. The BROM will load 32KB from 8K to SRAMA1 and jumps to the first instruction if the eGON header matches (seemksunxiboot). From there on you are on your own.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.



-- 
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: [U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support

[jonsm...@gmail.com]

On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki  wrote:
> On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com  wrote:
>> I recently ran into a probably with the UARTs on the A64. Many
>> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT
>> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems
>> set the speed of the BT UART to 3Mb/s.
>>
>> By default the Allwinner UART clock input is OSC24. When using OSC24
>> the maximum speed the UART can be set to is 1.5Mb/s. The clock input
>> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree
>> and 3Mb/s is then supported.
>>
>> But... there's a problem, UART0 (the console) is using the same master
>> clock source. So when you change the clock input over to PERIPH0x2 the
>> console stops working. There is no mechanism in Linux to handle this
>> clock source change and adjust the dividers on active uarts. So it
>> would be best if this master clock was set very early in u-boot and
>> then the console is adjusted to use it.
>>
>> Are there any downsides to making this change in u-boot?
>
> I don't understand, did you find this behaviour with these SPL changes
> or general sunxi u-boot?

Previously the boot console uart0 was getting setup in the SPL code. I
have not been closely following these changes, is that still true?

Changing the clock parent needs to be done before uart0 is
initialized. Changing this parent should have no other impact on
u-boot other than changing the clock divisor uart0 is using.

Once Linux is up, the Linux uart code will see the changed clock
parent and allow higher baud rates to be set.

This clock parent also impacts the I2C clocks, but I don't believe I2C
is enabled in A64 uboot.


>
> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.



-- 
Jon Smirl
jonsm...@gmail.com

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

[linux-sunxi] Re: [PATCH 3/5] arm64: dts: sun50i: add MMC nodes

[Chen-Yu Tsai]

On Tue, Jan 3, 2017 at 6:48 PM, André Przywara  wrote:
> On 03/01/17 02:52, Chen-Yu Tsai wrote:
>
> Hi,
>
>> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara  
>> wrote:
>>
>> A commit message explaining the mmc controllers would be nice.
>
> OK.
>
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 
>>> +++
>>>  1 file changed, 67 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
>>> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> index e0dcab8..c680566 100644
>>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>>> @@ -150,6 +150,32 @@
>>> pins = "PB8", "PB9";
>>> function = "uart0";
>>> };
>>> +
>>> +   mmc0_pins: mmc0@0 {
>>> +   pins = "PF0", "PF1", "PF2", "PF3", "PF4", 
>>> "PF5";
>>> +   function = "mmc0";
>>> +   drive-strength = <30>;
>>> +   };
>>> +
>>> +   mmc0_default_cd_pin: mmc0_cd_pin@0 {
>>> +   pins = "PF6";
>>> +   function = "gpio_in";
>>> +   bias-pull-up;
>>> +   };
>>
>> We are starting to drop pinmux nodes for gpio usage.
>
> And replacing them with what?
> Or do you mean they go in the individual board .dts files?
> In this case I believe having a default pin defined here would help to
> define it in every .dts.

Nope. I meant dropping them. Pinmux and gpio are orthogonal. One should not
need to specify a gpio pinmux to use it as a gpio. We added them because in
the past nothing was preventing someone from claiming an already muxed pin
as a gpio. On some platforms this is fine. For sunxi, this breaks the system,
as the gpio functions are muxed in.

The idea moving forward is that these cases should be guarded in the driver.
Of course we would have to deal with existing dtbs, but lets not add any more.

>>> +
>>> +   mmc1_pins: mmc1@0 {
>>> +   pins = "PG0", "PG1", "PG2", "PG3", "PG4", 
>>> "PG5";
>>> +   function = "mmc1";
>>> +   drive-strength = <30>;
>>> +   };
>>> +
>>> +   mmc2_pins: mmc2@0 {
>>> +   pins = "PC1", "PC5", "PC6", "PC8", "PC9",
>>> +  "PC10", "PC11", "PC12", "PC13", 
>>> "PC14",
>>> +  "PC15", "PC16";
>>> +   function = "mmc2";
>>> +   drive-strength = <30>;
>>> +   };
>>
>> Moreover I think you should split out the pinmux nodes to a separate patch.
>
> I can surely do, just wondering what's the rationale is behind that?

More or less the "do one thing in one patch" rationale. Of course you can
claim these are the defaults used in the reference design and pretty much
every board out there. Then it makes sense to do them together. :)

>
>>
>>> };
>>>
>>> uart0: serial@1c28000 {
>>> @@ -240,6 +266,47 @@
>>> #size-cells = <0>;
>>> };
>>>
>>> +   mmc0: mmc@1c0f000 {
>>> +   compatible = "allwinner,sun50i-a64-mmc",
>>> +"allwinner,sun5i-a13-mmc";
>>
>> Given that sun5i doesn't support mmc delay timings, and the A64 has
>> calibration and delay timings, I wouldn't call them compatible.
>>
>> Or are you claiming that for the A64 has a delay of 0 for the
>> currently supported speeds, so the calibration doesn't really
>> matter? If so this should be mentioned in the commit message.
>
> Yes, that's my observation: Driving it with sun5-a13-mmc just works.
> This sun5i driver version does not (and will never) support higher
> transfer modes anyway, so for that subset they are compatible. This
> opens up the door to other operating systems not having a particular
> driver for the A64, for instance, also older Linux kernels.
> I know that sunxi doesn't use this compatible feature much, but IMHO we
> should really start thinking about the DT not just being Linux specific
> - or even being specific to a certain Linux version. And this case here
> is a good example: An A13 MMC driver can drive this device - if there is
> no better driver (an A64 one) available.

Cool. Please put this in the commit log. :)

>
>>
>>> +   reg = <0x01c0f000 0x1000>;
>>> +   clocks = < 31>, < 75>;
>>
>> The clock / reset index macros are in the tree now.
>> Please switch to them.
>
> The include file is in the tree, but it isn't used in the current 

[linux-sunxi] Allwinner H3 without Uboot

[Mark L .]

Hi, 

I plan not to use U-boot but to take the boot process on charge (after the BROM 
stage).
It means I will write the SPL and the other stuffs to load my custom kernel and 
simplified OS.

Now, according to that page http://linux-sunxi.org/Bootable_SD_card, it means 
that I will need to put my code at the 8K mark on the SD card.
I should have up to the 544K mark to put my code, right?

Is there something -weird- the CPU will do in my back that prevents me from 
writing my own boot sequence? (forcing me to use Uboot)
I think about a forced jump of some sort.

Thanks
-- 
Mark

-- 
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] Allwinner H3 without Uboot

[André Przywara]

On 03/01/17 10:34, Mark L. wrote:

Hi Mark,

> I plan not to use U-boot but to take the boot process on charge (after the 
> BROM stage).
> It means I will write the SPL and the other stuffs to load my custom kernel 
> and simplified OS.
> 
> Now, according to that page http://linux-sunxi.org/Bootable_SD_card, it means 
> that I will need to put my code at the 8K mark on the SD card.
> I should have up to the 544K mark to put my code, right?

No, at this point there is no DRAM, also the BROM loads only 32KB
(starting at 8K). That's why we have the SPL: it initializes DRAM and
loads more data from the SD card (using a simple MMC driver).
Your "bootloader" would need to do something similar. While this is
feasible, be aware that the DRAM controller is poorly (if at all)
documented and in general DRAM controllers are quite "rocket science".
Also you would need to drive the MMC controller to load more data.

So I'd recommend to use at least the SPL to do that dirty work for you.
You should be able to plug your own bootloader instead of the U-Boot
proper, I think. Without further changes you would need to wrap it with
an U-Boot image header (mkimage).

If you are looking for low-level code to be loaded directly by the BROM,
uart0-helloworld-sdboot in the sunxi-tools repository would be a good
start. But you would still need DRAM init and MMC code.


> Is there something -weird- the CPU will do in my back that prevents me from 
> writing my own boot sequence? (forcing me to use Uboot)
> I think about a forced jump of some sort.

No, it should work as expected. The BROM will load 32KB from 8K to SRAM
A1 and jumps to the first instruction if the eGON header matches (see
mksunxiboot). From there on you are on your own.

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: [PATCH 3/5] arm64: dts: sun50i: add MMC nodes

[André Przywara]

On 03/01/17 02:52, Chen-Yu Tsai wrote:

Hi,

> On Tue, Jan 3, 2017 at 7:03 AM, Andre Przywara  wrote:
> 
> A commit message explaining the mmc controllers would be nice.

OK.

>> Signed-off-by: Andre Przywara 
>> ---
>>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 
>> +++
>>  1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
>> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> index e0dcab8..c680566 100644
>> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> @@ -150,6 +150,32 @@
>> pins = "PB8", "PB9";
>> function = "uart0";
>> };
>> +
>> +   mmc0_pins: mmc0@0 {
>> +   pins = "PF0", "PF1", "PF2", "PF3", "PF4", 
>> "PF5";
>> +   function = "mmc0";
>> +   drive-strength = <30>;
>> +   };
>> +
>> +   mmc0_default_cd_pin: mmc0_cd_pin@0 {
>> +   pins = "PF6";
>> +   function = "gpio_in";
>> +   bias-pull-up;
>> +   };
> 
> We are starting to drop pinmux nodes for gpio usage.

And replacing them with what?
Or do you mean they go in the individual board .dts files?
In this case I believe having a default pin defined here would help to
define it in every .dts.

>> +
>> +   mmc1_pins: mmc1@0 {
>> +   pins = "PG0", "PG1", "PG2", "PG3", "PG4", 
>> "PG5";
>> +   function = "mmc1";
>> +   drive-strength = <30>;
>> +   };
>> +
>> +   mmc2_pins: mmc2@0 {
>> +   pins = "PC1", "PC5", "PC6", "PC8", "PC9",
>> +  "PC10", "PC11", "PC12", "PC13", 
>> "PC14",
>> +  "PC15", "PC16";
>> +   function = "mmc2";
>> +   drive-strength = <30>;
>> +   };
> 
> Moreover I think you should split out the pinmux nodes to a separate patch.

I can surely do, just wondering what's the rationale is behind that?

> 
>> };
>>
>> uart0: serial@1c28000 {
>> @@ -240,6 +266,47 @@
>> #size-cells = <0>;
>> };
>>
>> +   mmc0: mmc@1c0f000 {
>> +   compatible = "allwinner,sun50i-a64-mmc",
>> +"allwinner,sun5i-a13-mmc";
> 
> Given that sun5i doesn't support mmc delay timings, and the A64 has
> calibration and delay timings, I wouldn't call them compatible.
> 
> Or are you claiming that for the A64 has a delay of 0 for the
> currently supported speeds, so the calibration doesn't really
> matter? If so this should be mentioned in the commit message.

Yes, that's my observation: Driving it with sun5-a13-mmc just works.
This sun5i driver version does not (and will never) support higher
transfer modes anyway, so for that subset they are compatible. This
opens up the door to other operating systems not having a particular
driver for the A64, for instance, also older Linux kernels.
I know that sunxi doesn't use this compatible feature much, but IMHO we
should really start thinking about the DT not just being Linux specific
- or even being specific to a certain Linux version. And this case here
is a good example: An A13 MMC driver can drive this device - if there is
no better driver (an A64 one) available.

> 
>> +   reg = <0x01c0f000 0x1000>;
>> +   clocks = < 31>, < 75>;
> 
> The clock / reset index macros are in the tree now.
> Please switch to them.

The include file is in the tree, but it isn't used in the current HEAD
(as in #included and the actual macros being used in the .dtsi).
So I was wondering if there is a patch pending for that?

Cheers,
Andre

>> +   clock-names = "ahb", "mmc";
>> +   resets = < 8>;
>> +   reset-names = "ahb";
>> +   interrupts = ;
>> +   status = "disabled";
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   };
>> +
>> +   mmc1: mmc@1c1 {
>> +   compatible = "allwinner,sun50i-a64-mmc",
>> +"allwinner,sun5i-a13-mmc";
>> +   reg = <0x01c1 0x1000>;
>> +   clocks = < 32>, < 76>;
>> +   clock-names = "ahb", "mmc";
>> +   resets = < 9>;
>> +   reset-names = "ahb";
>> +