Re: [opensuse-arm] How to use gpio pins via sysfs

[Frank Kunz]

Am 31.12.2017 um 12:17 schrieb Alexander Graf:




Am 30.12.2017 um 23:26 schrieb Frank Kunz :

I try to control a few gpio pins via bash script. Board and OS version is:

cat /proc/device-tree/compatible
olimex,a13-olinuxinoallwinner,sun5i-a13

cat /etc/os-release
NAME="openSUSE Leap"
VERSION="42.3"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="42.3"
PRETTY_NAME="openSUSE Leap 42.3"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:42.3"
BUG_REPORT_URL="https://bugs.opensuse.org;
HOME_URL="https://www.opensuse.org/;


In /sys/class/gpio I do:
echo 3 > export
ls
export  gpio3  gpiochip0  unexport
ls gpio3/
active_low  device/ direction   power/  subsystem/  uevent value
cat gpio3/direction
in

So when I want to change the pin direction:
echo out > gpio3/direction
bash: echo: write error: Unknown error 517

That is EPROBE_DEFER. The kernel signals that the requested device might be 
probed later, ...or never. I guess that there might be some device tree item 
missing, but from the kernel documentation I haven't found a solution for that. 
Does anybody have an idea how to get that working?


Usually changing gpio direction is the responsibility of the pinmux driver. Can 
you check if you have one loaded?


Thanks, that was the right hint. I analyzed it deeper and by using the 
correct pin (35 instead of 3) it works. This sysfs entry has the pin 
mapping:


/sys/kernel/debug/pinctrl/1c20800.pinctrl/pinmux-pins 
   Pinmux settings per pin 



Format: pin (name): mux_owner gpio_owner hog? 

pin 35 (PB3): (MUX UNCLAIMED) 1c20800.pinctrl:35 



Br,
Frank
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] rock64

[Andreas Färber]

Am 02.01.2018 um 16:59 schrieb Matwey V. Kornilov:
> 2018-01-02 18:27 GMT+03:00 Andreas Färber :
>> Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:
>>> Why didn't we allocate separate GPT partition for each bootloader
>>> image? It seems to be generic way to denote that specific place at SD
>>> card is allocated and used by something.
>>
>> Kiwi only supports a few partitioning schemes, it does not allow to add
>> random other partitions AFAIK. Every scheme needs to be defined in the
>> XML Schema and needs a matching implementation in Kiwi.
>>
>> Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?
> 
> Nope. Where can I find it?
> 
> https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Pine64
> 
> This one?

https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:Pine64/pine64-instsd

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] rock64

[Matwey V. Kornilov]

2018-01-02 18:27 GMT+03:00 Andreas Färber :
> Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:
>> 2017-09-02 13:25 GMT+03:00 Andreas Färber :
>>> Hi,
>>>
>>> Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:
 1. Tools from https://github.com/rockchip-linux/rkbin are required to
 prepare u-boot binary to be deployed into sd-card. The tools are
 permitted to be redistributed, but they are x86_64-only binary blobs.
 I think we could package them in RPM package and wrap them using
 qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64
 architecture).
>>>
>>> Negative. Same topic came up for Amlogic, and I had to develop the
>>> native Open Source meson-tools instead.
>>>
>>> For creating a JeOS image we need to use U-Boot SPL, which as I already
>>> pointed out should avoid all those binary-only x86 tools.
>>>
>>> If that is not working yet (you did not say), then we can just document
>>> the x86-only steps to keep them out of OBS.
>>>
 2. bootloader are required to be placed at +16MB offset from the
 beginning of SD card. We have to find a way to specify KIWI to place
 EFI partition not at 2048sector as default.
>>>
>>> Yousaf gave a presentation on how to accomplish that for RK3399.
>>>
>>> If this reservation is implemented, then similar to my JeOS-nanopik2
>>> image we could just leave out U-Boot and give users Wiki instructions on
>>> how to place U-Boot there themselves.
>>
>> Why didn't we allocate separate GPT partition for each bootloader
>> image? It seems to be generic way to denote that specific place at SD
>> card is allocated and used by something.
>
> Kiwi only supports a few partitioning schemes, it does not allow to add
> random other partitions AFAIK. Every scheme needs to be defined in the
> XML Schema and needs a matching implementation in Kiwi.
>
> Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?

Nope. Where can I find it?

https://build.opensuse.org/project/show/devel:ARM:Factory:Contrib:Pine64

This one?

> That should allow to create custom bootloader partitions. Just keep in
> mind that U-Boot might check only the first partition if none is flagged
> as bootable, so you may want to keep EFI first even if physically second.
>
> Regards,
> Andreas
>
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)



-- 
With best regards,
Matwey V. Kornilov
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] rock64

[Andreas Färber]

Am 01.01.2018 um 16:20 schrieb Matwey V. Kornilov:
> 2017-09-02 13:25 GMT+03:00 Andreas Färber :
>> Hi,
>>
>> Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:
>>> 1. Tools from https://github.com/rockchip-linux/rkbin are required to
>>> prepare u-boot binary to be deployed into sd-card. The tools are
>>> permitted to be redistributed, but they are x86_64-only binary blobs.
>>> I think we could package them in RPM package and wrap them using
>>> qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64
>>> architecture).
>>
>> Negative. Same topic came up for Amlogic, and I had to develop the
>> native Open Source meson-tools instead.
>>
>> For creating a JeOS image we need to use U-Boot SPL, which as I already
>> pointed out should avoid all those binary-only x86 tools.
>>
>> If that is not working yet (you did not say), then we can just document
>> the x86-only steps to keep them out of OBS.
>>
>>> 2. bootloader are required to be placed at +16MB offset from the
>>> beginning of SD card. We have to find a way to specify KIWI to place
>>> EFI partition not at 2048sector as default.
>>
>> Yousaf gave a presentation on how to accomplish that for RK3399.
>>
>> If this reservation is implemented, then similar to my JeOS-nanopik2
>> image we could just leave out U-Boot and give users Wiki instructions on
>> how to place U-Boot there themselves.
> 
> Why didn't we allocate separate GPT partition for each bootloader
> image? It seems to be generic way to denote that specific place at SD
> card is allocated and used by something.

Kiwi only supports a few partitioning schemes, it does not allow to add
random other partitions AFAIK. Every scheme needs to be defined in the
XML Schema and needs a matching implementation in Kiwi.

Have you checked out Alex' new non-Kiwi approach for RPi3 and Pine64?
That should allow to create custom bootloader partitions. Just keep in
mind that U-Boot might check only the first partition if none is flagged
as bootable, so you may want to keep EFI first even if physically second.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org

Re: [opensuse-arm] rock64

[Matwey V. Kornilov]

2018-01-01 18:20 GMT+03:00 Matwey V. Kornilov :
> 2017-09-02 13:25 GMT+03:00 Andreas Färber :
>> Hi,
>>
>> Am 02.09.2017 um 12:06 schrieb Matwey V. Kornilov:
>>> 1. Tools from https://github.com/rockchip-linux/rkbin are required to
>>> prepare u-boot binary to be deployed into sd-card. The tools are
>>> permitted to be redistributed, but they are x86_64-only binary blobs.
>>> I think we could package them in RPM package and wrap them using
>>> qemu-linux-x86_64 to execute them at JeOS building phase (at aarch64
>>> architecture).
>>
>> Negative. Same topic came up for Amlogic, and I had to develop the
>> native Open Source meson-tools instead.
>>
>> For creating a JeOS image we need to use U-Boot SPL, which as I already
>> pointed out should avoid all those binary-only x86 tools.
>>
>> If that is not working yet (you did not say), then we can just document
>> the x86-only steps to keep them out of OBS.
>>
>>> 2. bootloader are required to be placed at +16MB offset from the
>>> beginning of SD card. We have to find a way to specify KIWI to place
>>> EFI partition not at 2048sector as default.
>>
>> Yousaf gave a presentation on how to accomplish that for RK3399.
>>
>> If this reservation is implemented, then similar to my JeOS-nanopik2
>> image we could just leave out U-Boot and give users Wiki instructions on
>> how to place U-Boot there themselves.
>
> Why didn't we allocate separate GPT partition for each bootloader
> image? It seems to be generic way to denote that specific place at SD
> card is allocated and used by something.

And there is one thing which I can't understand. Currently, u-boot
based TPL/SPL located at 0x40 sector for rk3328. Why SPL u-boot loader
can't read u-boot.itb from the filesystem? As far as I understand
there is no "return to bootrom" step after SPL. So there should be no
reason to find u-boot.itb at specific place at SD card. Could somebody
explain me how this is supposed to work?

>
>>
>> You had forgotten to create an HCL Wiki page - I stubbed one out:
>>
>> https://en.opensuse.org/HCL:Rock64
>>
>> Regards,
>> Andreas
>>
>> --
>> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> GF: Felix Imendörffer, Jane Smithard, Graham Norton
>> HRB 21284 (AG Nürnberg)
>
>
>
> --
> With best regards,
> Matwey V. Kornilov



-- 
With best regards,
Matwey V. Kornilov
--
To unsubscribe, e-mail: opensuse-arm+unsubscr...@opensuse.org
To contact the owner, e-mail: opensuse-arm+ow...@opensuse.org