Re: Enable Display/Splash on Phycore am335x with barebox 2020.01.0
Hello Holger, On 8/12/20 11:51 AM, Sascha Hauer wrote: > On Wed, Aug 12, 2020 at 07:36:58AM +, Koelle, Holger wrote: >> So my Question : Is it possible to enable the drm (gpu) unit in Sidenote: you usually don't touch the GPU in the bootloader, only the display controller. >> Barebox 2020.01.0 at the am335x phycore board or is it not supported? > > We don't have a framebuffer driver for am335x, so you won't have any > luck getting a picture out of the hardware with barebox. Unless *hint* someone *hint* feels like implementing support. :-) Cheers Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Enable Display/Splash on Phycore am335x with barebox 2020.01.0
Hi Holger, On Wed, Aug 12, 2020 at 07:36:58AM +, Koelle, Holger wrote: > Hi everybody, > > This week i've tried to enable our Display (which working without > problems in Linuxkernel 4.19.94) in Barebox without success. > > I've patched the Devicetree similar to am335x-evm.dts with our display > timings and the other values. But I got no fb0 device or a matching > driver for the panel/gpu. > In the drivers section I can't find any driver which matching tilcdc > and am335x-tilcdc like described in the barebox documentation. > > Of_dump shows that the panel is there, but drvinfo says there is no > driver.I've tried to use the simple-panel driver but without > success... > > So my Question : Is it possible to enable the drm (gpu) unit in > Barebox 2020.01.0 at the am335x phycore board or is it not supported? We don't have a framebuffer driver for am335x, so you won't have any luck getting a picture out of the hardware with barebox. The simple-panel driver is only for the panel itself, but not for the framebuffer. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Enable Display/Splash on Phycore am335x with barebox 2020.01.0
Hi everybody, This week i've tried to enable our Display (which working without problems in Linuxkernel 4.19.94) in Barebox without success. I've patched the Devicetree similar to am335x-evm.dts with our display timings and the other values. But I got no fb0 device or a matching driver for the panel/gpu. In the drivers section I can't find any driver which matching tilcdc and am335x-tilcdc like described in the barebox documentation. Of_dump shows that the panel is there, but drvinfo says there is no driver.I've tried to use the simple-panel driver but without success... So my Question : Is it possible to enable the drm (gpu) unit in Barebox 2020.01.0 at the am335x phycore board or is it not supported? Regards, H.Kölle ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Barebox 2020.01.0 and Device Tree from Linux Kernel 5.4
Hello,
(please keep the barebox mailing list in CC)
On 1/27/20 3:02 PM, gianluca wrote:
> On 01/24/2020 05:13 PM, Ahmad Fatoum wrote:
>> Hello,
>>
>> On 1/24/20 4:32 PM, gianluca wrote:
>>> I was wondering if the device tree from (latest) Linux Kernel can be used
>>> when building Barebox 2020.01.0 for iMX6 compatible custom board.
>>> For sure the include path and other stuff are quite different (kernel and
>>> barebox), so I am pretty sure it will fail to build with some sort of
>>> "foreign" device-tree.
>>
>> barebox already regularly imports Linux's device tree directories into its
>> dts/ directory.
>> v2020.01.0 contains the v5.4-rc7 state.
>>
>
> Good to hear...
>
>> Another issue, will be the drivers to have full access from
>> Barebox-Point-Of-View. If the device-tree properties and compatible strings
>> are quite different, Barebox will fail to activating/probing/using the
>> internal driver.
>>
>> barebox driver compatibles should be aligned with the kernel's.
>> If a barebox driver lacks handling for a property, the driver can be
>> extended.
>>
>>> So I am asking:
>>> There is a "official" way to manage those differencies?
>>
>> I recently added a short section about this in the Documentation
>> (https://barebox.org/doc/latest/devicetree/index.html):
>>
>> "For supporting architectures, barebox device trees are located in
>> arch/$ARCH/dts.
>> Usually the barebox board.dts imports the upstream device tree under
>> dts/src/$ARCH
>> with #include "$ARCH/board.dts" and then extends it with
>> barebox-specifics like
>> Barebox state, environment or boot-time device configuration."
>>
>> Take a look at arch/arm/dts/imx6q-marsboard.dts to see how that looks in
>> practice.
>> The kernel device tree is reused as is and extended slightly for barebox use.
>
> So, basically the device-tree stuff in Barebox are different from the Linux
> kernel one only for the #include path?
The barebox device trees for ARM are in arch/arm/dts. Best practice
is that these device trees include the upstream device tree with just
the barebox changes custom.
> The biggest issue I've found here, is the compatibility of the device-tree
> nodes for my board referring the standard imx6 board. For example:
>
> {
> status = "okay";
> };
>
> is good as you are using the standard pinout for uart3.
>
> But, if I am using a different pinout layout for the same device, this is not
> working at all.
>
> Maybe I have to find the device-node parent, then looking for its
> configuration, and if it fits my needs, ok I will use it.
>
> Otherwise I have to redefine a new configuration node:
>
> uart3 {
> pinctrl =
> interrupts = ...
> };
>
> But this does not work. uart3 is already defined into the parent node of
> imx6q.dtsi.
>
> In that case I need to redefine a new name:
>
> my_uart3 {
> pinctrl = ...
> interrupts = ...
> };
>
> _uart3 {
> status = "okay";
> };
>
> I hope you understand what I am trying to tell you.
You don't need to do this, you can just write
{
pinctrl = ...;
status = "okay";
};
These properties will override the properties from earlier in the preprocessed
file.
Cheers
Ahmad
>
> Best regards,
> Gianluca
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Barebox 2020.01.0 and Device Tree from Linux Kernel 5.4
Hello,
On 1/24/20 4:32 PM, gianluca wrote:
> I was wondering if the device tree from (latest) Linux Kernel can be used
> when building Barebox 2020.01.0 for iMX6 compatible custom board.
> For sure the include path and other stuff are quite different (kernel and
> barebox), so I am pretty sure it will fail to build with some sort of
> "foreign" device-tree.
barebox already regularly imports Linux's device tree directories into its dts/
directory.
v2020.01.0 contains the v5.4-rc7 state.
Another issue, will be the drivers to have full access from
Barebox-Point-Of-View. If the device-tree properties and compatible strings are
quite different, Barebox will fail to activating/probing/using the internal
driver.
barebox driver compatibles should be aligned with the kernel's.
If a barebox driver lacks handling for a property, the driver can be extended.
> So I am asking:
> There is a "official" way to manage those differencies?
I recently added a short section about this in the Documentation
(https://barebox.org/doc/latest/devicetree/index.html):
"For supporting architectures, barebox device trees are located in
arch/$ARCH/dts.
Usually the barebox board.dts imports the upstream device tree under
dts/src/$ARCH
with #include "$ARCH/board.dts" and then extends it with barebox-specifics
like
Barebox state, environment or boot-time device configuration."
Take a look at arch/arm/dts/imx6q-marsboard.dts to see how that looks in
practice.
The kernel device tree is reused as is and extended slightly for barebox use.
> Am I forced to use TWO device-tree dts files (almost identical each other) ???
>
> It seems it is like re-inventing the wheel...
No, as you can can extend the kernel device tree (see below).
> I think this procedure can be used with ALL supported boards present in
> barebox source tree.
>
> Actually I am using a slightly modified device-tree for my boards from
> kernel, then adapted to be compiled for Barebox.
> Some nodes are "disabled" by default as status, so Barebox will activate them
> when probing the real-hardware.
I think
#include
{
status = "okay";
};
is what you're after.
> I would like to keep my code to activate/deactivate device-tree drivers, but
> without modifying the Kernel device-tree each time when I do a Kernel update.
>
> Any hint will be very accepted.
HTH,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Barebox 2020.01.0 and Device Tree from Linux Kernel 5.4
Hello list! I was wondering if the device tree from (latest) Linux Kernel can be used when building Barebox 2020.01.0 for iMX6 compatible custom board. For sure the include path and other stuff are quite different (kernel and barebox), so I am pretty sure it will fail to build with some sort of "foreign" device-tree. Another issue, will be the drivers to have full access from Barebox-Point-Of-View. If the device-tree properties and compatible strings are quite different, Barebox will fail to activating/probing/using the internal driver. So I am asking: There is a "official" way to manage those differencies? Am I forced to use TWO device-tree dts files (almost identical each other) ??? It seems it is like re-inventing the wheel... I think this procedure can be used with ALL supported boards present in barebox source tree. Actually I am using a slightly modified device-tree for my boards from kernel, then adapted to be compiled for Barebox. Some nodes are "disabled" by default as status, so Barebox will activate them when probing the real-hardware. I would like to keep my code to activate/deactivate device-tree drivers, but without modifying the Kernel device-tree each time when I do a Kernel update. Any hint will be very accepted. Regards, -- Eurek s.r.l. | Electronic Engineering| http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
barebox-2020.01.0
Hi All, We have the first release in this decade ;) >From the amount of patches it seems most of the work for this release has gone into the SDHCI driver. A good bunch of the different implementations for the same functionalities has been merged to a common code base. Other than that Layerscape now has PCIe support, there are some more Layerscape improvements as well. As usual, see below for more details about the changes in this release. Have Fun! Sascha Ahmad Fatoum (42): ARM: i.MX6: Embedsky E9: remove inaccurate comment ARM: i.MX6: sabresd: remove inaccurate comment watchdog: always populate watchdog priority from device tree if possible watchdog: implement generic support for .running device parameter watchdog: imxwd: support .running device parameter on i.MX2+ watchdog: f71808e: support .running device parameter ARM: dts: stm32mp: move alias to SoC device tree ARM: stm32mp157c-dk2: add optional DEBUG_LL print to entry point mfd: stpmic1: use register define from header watchdog: stm32_iwdg: return -ENOSYS on attempt to disable i2c: stm32: use device_reset_us helper instead of open-coding Documentation: boards: stm32mp: document boot error LED ARM: stm32mp: add helper for querying ram size ARM: stm32mp: add basic DDR controller driver ARM: stm32mp: add stm32mp_cpu_lowlevel_init with stack set up ARM: stm32mp: dk2: don't hard-code memory size nvmem: bsec: fix typo in function name (s/st32/stm32/) ARM: psci: factor out smc command into commands/ ARM: psci: properly wire in command help commands: psci: make locally-used function static commands: smc: verify PSCI_POWER_ON with interprocessor handshake commands: smc: make command usable when ARM_PSCI is undefined mci: dove: fix dereference of nullable pointer ARM: cpu: dtb: remove unused declaration remoteproc: register a device for new remoteproc instances remoteproc: add support for starting st,stm32mp1-m4 watchdog: stm32_iwdg: explicitly set .running to UNSUPPORTED scripts: imx: report file where error occurred net: designware: eqos: remove done TODO param: add dev_add_param_tristate(_ro) helpers watchdog: core: use new dev_add_param_tristate helper for .running param images: i.MX: rearrange image rules in preparation for boilerplate removal efi: add and use new efi_device_has_guid helper driver: add missing parentheses around macro argument efi: fix off-by-one in mem_malloc_init(..., end) x86: efi: lds: don't discard any relocation sections PCI: add driver_data member to struct pci_device_id PCI: copy over some Linux PCI helpers efi: turn set of defines into enumerations serial: add support for PCI NS16550 UARTs bus: efi: add basic ACPI bus infrastructure misc: add ACPI test driver Andrey Smirnov (13): ARM: VFxxx: Display UID information on boot mci: imx-esdhc: Drop unnecessary type conversion mci: imx-esdhc: Drop unused type definition mci: imx-esdhc: Drop extra helper varaible mci: imx-esdhc-pbl: Don't setup DMA registers mci: imx-esdhc-pbl: Share initialization code mci: imx-esdhc-pbl: Drop 'wrap_wml' flag mci: imx-esdhc-pbl: Share IO accessors with regular driver mci: imx-esdhc-pbl: Use sdhci_transfer_data() mci: imx-esdhc-pbl: Use sdhci_set_cmd_xfer_mode() mci: imx-esdhc: Share code for esdhc_(setup|do)_data operations mci: imx-esdhc: Introduce esdhc_poll() mci: imx-esdhc: Share code for esdhc_send_cmd() Antony Pavlov (1): i2c: gpio: use of_get_named_gpio() instead of of_get_named_gpio_flags() Clement Leger (1): mtd: spi-nor: Add support for is25lp01g Du Huanpeng (1): MIPS: Makefile: minor codingstyle fix Florian Klink (4): scripts: use #!/usr/bin/env bash shebang instead of #!/bin/bash dts/scripts: use #!/usr/bin/env bash shebang instead of #!/bin/bash docs: use #!/usr/bin/env bash shebang instead of #!/bin/bash docs: use #!/usr/bin/env python shebang instead of #!/usr/bin/python Lucas Stach (58): ARM: zynq: zedboard: enable MACB driver in defconfig ARM: zynq: add trivial image build mechanism ARM: zynq: use getopt in zynq_mkimage ARM: zynq: move header generation to zynq_mkimage ARM: zynq: add size check in zynq_mkimage ARM: zynq: zedboard: provide DTB net: macb: handle more clocks net: macb: add Zynq compatible ARM: zynq: move clock controller driver to drivers/clk clk: zynq: use base address of clock controller clk: zynq: improve PLL enable handling clk: zynq: fix up address from DT clk: zynq: partially sync with Linux ARM: zynq: switch to DT based probing clk: zynq: remove clkdevs ARM: zynq: switch to
