[U-Boot] [PATCH] video: add cfb console driver for sunxi

[Luc Verhaegen]

This adds a fixed mode hdmi driver (lcd to be added in future) for the
sunxi platform. Current config is such that 8MB is shaved off at the top
of the RAM. Simplefb support is available for kernels that know how to
use it.

Signed-off-by: Luc Verhaegen 
---
 arch/arm/include/asm/arch-sunxi/sunxi_display.h |   21 +
 board/sunxi/board.c |   14 +
 drivers/video/Makefile  |1 +
 drivers/video/sunxi_display.c   |  639 +++
 include/configs/sunxi-common.h  |   34 ++
 5 files changed, 709 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-sunxi/sunxi_display.h
 create mode 100644 drivers/video/sunxi_display.c

diff --git a/arch/arm/include/asm/arch-sunxi/sunxi_display.h 
b/arch/arm/include/asm/arch-sunxi/sunxi_display.h
new file mode 100644
index 000..4456778
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/sunxi_display.h
@@ -0,0 +1,21 @@
+/*
+ * (C) Copyright 2014 Luc Verhaegen 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation's version 2 and any
+ * later version the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#ifndef _SUNXI_DISPLAY_H_
+#define _SUNXI_DISPLAY_H_
+
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+void sunxi_simplefb_setup(void *blob);
+#endif
+
+#endif /* _SUNXI_DISPLAY_H_ */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 2179e23..e819b12 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -26,6 +26,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_VIDEO
+#include 
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 /* add board specific code here */
@@ -185,3 +189,13 @@ int misc_init_r(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+   sunxi_simplefb_setup(blob);
+#endif
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 945f35d..9a25c84 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_VIDEO_SANDBOX_SDL) += sandbox_sdl.o
 obj-$(CONFIG_VIDEO_SED13806) += sed13806.o
 obj-$(CONFIG_VIDEO_SM501) += sm501.o
 obj-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
+obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
 obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
 obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
 obj-$(CONFIG_FORMIKE) += formike.o
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
new file mode 100644
index 000..251fb67
--- /dev/null
+++ b/drivers/video/sunxi_display.c
@@ -0,0 +1,639 @@
+/*
+ * (C) Copyright 2013-2014 Luc Verhaegen 
+ *
+ * Display driver for Allwinner SoCs.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation's version 2 and any
+ * later version the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * This driver does nothing but HDMI at a fixed mode right now. At some
+ * point in the near future, LCD and VGA will be added.
+ *
+ * The display driver infrastructure in uboot does not immediately allow for
+ * modeline creation off of edid. The mode is therefor hardcoded to
+ * 1024x768@60Hz 32bpp. This is acceptable for most HDMI monitors, but far
+ * from ideal. If so desired, alter the modeline in video_hw_init()
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* for simplefb */
+#ifdef CONFIG_OF_BOARD_SETUP
+#include 
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct sunxi_display {
+   GraphicDevice graphic_device[1];
+   int enabled;
+} sunxi_display[1];
+
+/*
+ * Convenience functions to ease readability, and to provide an easy
+ * comparison with the sunxi kms driver.
+ */
+static unsigned int
+sunxi_io_read(void *base, int offset)
+{
+   return readl(base + offset);
+}
+
+static void
+sunxi_io_write(void *base, int offset, unsigned int value)
+{
+   writel(value, base + offset);
+}
+
+static void
+sunxi_io_mask(void *base, int offset, unsigned int value, unsigned int mask)
+{
+   unsigned int tmp = readl(base + offset);
+
+   tmp &= ~mask;
+   tmp |= value & mask;
+
+   writel(tmp, base + offset);
+}
+
+/*
+ * CCMU regs: clocks.
+ */
+#define SUNXI_CCMU_PLL3_CFG0x010
+#define SUNXI_CCMU_PLL5_CFG0x020
+#define S

Re: [U-Boot] [PATCH] video: add cfb console driver for sunxi

[Luc Verhaegen]

ling this code 
will be swapped around. People will have to manually add VIDEO to their 
board config. There's just to many hairy cornercases and tough to answer 
"what if"s here, when you actually start thinking things through, to 
keep this as the default.

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [linux-sunxi] Re: [PATCH] video: add cfb console driver for sunxi

[Luc Verhaegen]

On Mon, Aug 04, 2014 at 05:31:36PM +0200, Henrik Nordström wrote:
> mån 2014-08-04 klockan 17:05 +0200 skrev Luc Verhaegen:
> > But... What do we do when u-boot sets up cfb, without setting up a
> > simplefb node in the dt. Or what do we do when a simplefb node is set 
> > up, but no simplefb code is included in the kernel? Well, we then either 
> > need to claim the clocks, and make sure that nothing else touches the 
> > memory, or we need to cleanly disable the display engine. But which do 
> > we choose, do we keep the u-boot output forever, or do we sync off when 
> > the kernel starts?
> 
> And what happens if we simply ignore it? Is there a risk of anything
> burning beyond software repair? If not, ignore it. There is no need to
> support all incompatible mixes even if it means some people will see
> strange fireworks on their screens when not following the software
> requirements.
> 
> It's really no different from booting a kernel with wrong dt, or using a
> u-boot with wrong DRAM settings etc. An incompatible mix which is not
> meant to function properly.
> 
> If you use a u-boot with this framebuffer support then you must also
> either use a kernel which supports being booted in such state, or make
> sure u-boot shuts things off before handing over to the kernel.
> 
> If we can handle the situation gracefully in the kernel then fine, but
> it's by no means required, or even desired to spend any effort or even
> any serious thoughts on before compatible setups works.
> 
> Regards
> Henrik

We can work around most situations gracefully in kernelspace. We should 
for instance never set a bad mode, and never show random memory content, 
as that is a total no-go. So some code will have to exist to cleanly 
disable the display engine (we're in luck, we only need to poke the ahb 
gating and some clocks).

But if we can overlook some of the above, we also should just consider 
the memory lost until a kms driver kicks in, and ioremaps/whatevers it 
for its own use.

How's this for the sunxi implementation of simplefb:
* u-boot lists used clocks, to allow some code in simplefb.c to grab all 
  clocks. This is necessary as the list of clocks might change with 
  changed cfb-console driver functionality.
* when the clocks get disabled, the existing display engine setup 
  becomes useless. the dt simplefb node has its status set to disabled. 
  The memory range info remains, none of the reserved ram is returned 
  to system. This needs to happen in both simplefb.c and in clk-sunxi.c.
* when the memory range gets mapped by the kms driver (currently, on 
  sunxi-3.4 i just use the full disp driver reserved range directly) in 
  a way that it will be released again at unload, the memory range info 
  remains. This ensures that future kms driver reloads can still grab 
  this memory.
* when however the memory range gets mapped to cma globally, the memory 
  range info is removed.

It makes sense to add the clock handling and the disabling of the
simple-framebuffer node in the actual simplefb driver. The memory 
handling should be considered platform specific behaviour for now, but 
perhaps dt reserved memory infrastructure can come to the rescue in 
future.

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] video: add cfb console driver for sunxi

[Luc Verhaegen]

On Tue, Aug 05, 2014 at 01:56:36PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 08/02/2014 06:14 PM, Luc Verhaegen wrote:
> > This adds a fixed mode hdmi driver (lcd to be added in future) for the
> > sunxi platform. Current config is such that 8MB is shaved off at the top
> > of the RAM. Simplefb support is available for kernels that know how to
> > use it.
> 
> I've been trying to follow all the discussion in this thread, and here
> is what I think we should do:
> 
> 1) There has been some discussion about using this console-driver
> in u-boot without generating the simplefb dt node. This means yet another
> variation in how all the bits fit together, so I don't think we should do
> this. Note I realize that the original patch did not have a specific
> config option for this, but it was mentioned later in the thread.
> TL;DR: Enabling the console driver will always generate the simplefb dt
> node.

When we do not claim clocks, we luckily cleanly disable hw, in our case.

> 2) I think we can worry about what to do with the reserved memory\when not 
> using simplefb
> (or when switching from simplefb to kms) later. For now lets focus on the
> issue with the clocks.

Yes, this was the plan all along.

> 3) To me the issue with clocks seems simple, we should modify the
> devicetree binding for simplefb to support a clocks property, and modify
> the simplefb kernel code to get + prep_and_enable any clocks specified
> in the dt node.

For me, an important part of this discussion was seemingly flawed way in 
which clocks are defined. I was of course not going to completely 
overturn the thinking here, but i had expected that people would've at 
least agreed that something was obviously awry, as there are several 
obvious indicators there.

> This means parsing enough of the dt to find the clocks to be able to
> specify phandles to them in the added node. I don't know how hard it will
> be to do this in u-boot, but IMHO it is simply the right thing to do, so
> this is how it should be done.

No, you do not need to add nodes. This was never the case. &ahb_gates 
is never used like that.

It is either used as <&ahb_gates bit> from the dt, or "ahb_bitname" 
from kernel code which directly references clocks, with the 
ahb_bitnames listed as part of ahb_gates in the "clock-output-names" 
property. This lack of symmetry is one very clear sign.

The fact that only the kernel knows how to map the "clock-output-names" 
list, which is only defined in the dts, to bits only defined in the clk 
driver code in the kernel, that's another very clear sign.

> If others agree that specifying the clocks in the simplefb dt node is
> the right way to ensure that the clocks don't get enabled I'm willing
> at taking a shot on coding this.

I have been on it since last friday, when i started seeing the issues 
here, but haven't done much code til now, and am only uncovering many 
more inconsistencies.

For instance, in the linux kernel, 
Documentation/devicetree/bindings/clock/clock-bindings.txt only adds to 
the confusion.

Now trying to find a working solution from the kernel side, as i already 
manually inserted 6 u32s: {phandle, bit, phandle, bit, phandle, bit}.
Wait and see how that pans out, but i know that this will not provide a 
proper or lasting solution, as the pairs of cells needed now will at one 
point need to be mixed with directly referenced clocks (pll3/pll7, which 
are currently not defined in dts yet).

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

[Luc Verhaegen]

On Wed, Sep 17, 2014 at 09:11:38PM +0200, Hans de Goede wrote:
> Hi Marek, et al,
> 
> I'm working on cleaning up Luc's hdmi out support patchset for
> sunxi.

?

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Need help with u-boot problem with usb-keyboard / kvm switch

[Luc Verhaegen]

On Thu, Sep 18, 2014 at 10:34:04AM +0200, Hans de Goede wrote:
> Hi,
> 
> Cleaning up may not have been the best choice of words, I was
> talking about the rebase on top of upstream u-boot + the various
> fixes you already know about.
> 
> I plan to submit a patch-set to the kernel for the clock resource
> stuff for simplefb to the proper lists for that discussion soon,
> and assuming that gets accepted I would like to land the
> hdmi support in upstream u-boot soon.

Ok, thanks for getting me up to date on this.

As for simplefb, i had given up on that, and wanted to cough up 
an alternate driver that simply wouldn't be called that. But as usual, i 
am all over the place. So let's see how the simplefb route goes. Good 
luck.

Thanks,

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Announcing easy Linux installation on Allwinner devices for non-geek users

[Luc Verhaegen]

 runtime in any way (LCD displays for
> example). So what is the safe subset of hardware, which is
> universally usable in generic u-boot binaries? Basically, we can
> rely on the assumption that everything that is used by BROM, can be
> safely autodetected and used by the universal u-boot binaries too.
> 
> For example, the UART serial console is not really used by BROM, and
> this was a kind of hack in the previous demo. At that time it looked
> like the serial console could be configured correctly according to
> some heuristic rules. However later it turned out that the heuristics
> does not really work on some A13 devices and they may have mutually
> incompatible UART configurations:
> https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg07057.html
> This particular problem just confirms the general rule about
> relying only on what is also used by BROM. Oh, and some functionality
> is also provided by dedicated SoC pins, which are strictly used only
> for a single purpose and can't be re-configured for doing anything
> else. This can be safely used too.
> 
> Anyway, the really missing part was the user friendly output and user
> friendly input for generic u-boot binaries. HDMI is widely used in
> Allwinner hardware and it supports autoconfiguration. USB host ports
> use dedicated pins and only enabling/disabling power can be device
> specific. The missing USB power can be solved by using a powered USB
> hub, which is not very convenient, but still a workable solution.
> 
> After the initial discussion and planning on the IRC, Luc Verhaegen
> stepped in to implement the video driver for u-boot, together
> with simplefb support for the linux kernel:
> http://lists.denx.de/pipermail/u-boot/2014-August/185193.html
> 
> And Roman Byshko stepped in to implement the USB EHCI support:
> http://lists.denx.de/pipermail/u-boot/2014-July/183349.html
> 
> Many thanks to them for spearheading the development of these
> important features! And of course, Hans de Goede did a great
> job bugfixing and further improving this code, probably investing
> even more efforts than the initial contributors. Not to mention
> the participation in lengthy simplefb political battles, which
> looked really scary and discouraging, but ended up well.
> 
> With all these features in place, now we can do something like this:
> 
> https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype
> 
> It is a demo of a universal SD card image, which should be bootable
> on any Allwinner A10/A10s/A20 device. With an installer of u-boot
> v2015.01-rc3 as the initial demo simple payload. By using a
> HDMI monitor for output and a USB keyboard or FEL button for input,
> it offers a menu based user interface. The menu allows to select
> the exact type of the user's Allwinner device and install the
> right bootloader for it.
> 
> In principle, even now it is usable as a base for the SD card distro
> image. Maybe with http://www.berryterminal.com/doku.php/berryboot
> chained as the next installation stage.
> 
> There is of course a huge room for improvements, which are yet to be
> done. Some of the potential improvements are listed below.
> 
> =
> == 3. Relocatable SD card
> =
> 
> Maybe not every user really needs a full-fledged bootloader, so a basic
> device independent bootloader with just SD card support and HDMI can
> be probably used not only for the initial setup of the hardware type,
> but kept indefinitely for booting the linux kernel too. Naturally, in
> order to get good performance, the DRAM parameters need to be patched
> into the SPL, replacing the generic failsafe ones.
> 
> The DRAM parameters can (and should) be tied to the unique chip ID:
> http://linux-sunxi.org/SID_Register_Guide
> So that if anyone tries to move the SD card to a different Allwinner
> device, this situation can be detected and the menu with the device
> type selection can be shown again on the HDMI monitor instead of
> failing in a non-obvious way. Storing SID values and DRAM settings
> for more than one device is also an option, so repeatedly swapping
> between two devices will trigger the device type selection menu
> activation only once for each device.
> 
> =
> == 4. NAND
> =
> 
> NAND is the hardware, which is supported by BROM. Which means that it
> should be usable in a generic way by the universal device independent
> u-boot binary. NAND is a perfect place to store the devi

Re: [U-Boot] Please pull u-boot-sunxi master

[Luc Verhaegen]

On Sat, Oct 03, 2015 at 02:01:53PM +0200, Hans de Goede wrote:
>
> This introduces just 1 new defconfig, we want this new defconfig in v2015.10
> since it is a generic defconfig for so called q8 formfactor sunxi tablets,
> and we want to replace all the PCB revision specific defconfigs with
> a few generic ones since there are just too many variants.

Who is "We" in this sentence?

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 00/16] Add Intel Arria 10 SoC support

[Luc Verhaegen]

On Fri, Apr 14, 2017 at 01:41:09AM +0800, Ley Foon Tan wrote:
>

This is what the mail header says:

Received: by lists.denx.de (Postfix, from userid 105)   
id CF30DC21C35; Thu, 13 Apr 2017 09:41:37 + (UTC)

Add 8h, and you're still on thursday the 13th, but at 17:41.

Please fix your systems clock and use ntp.

Luc Verhaegen.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

FOSDEM Hardware Enablement Devroom: call for speakers.

[Luc Verhaegen]

Hi,

At FOSDEM on sunday the 2nd of february 2020, there will be another 
hardware enablement DevRoom. URL: https://fosdem.org/2020/

This devroom covers topics related to hardware support and enablement 
with free software. It includes the following topics:
* peripheral/controller firmwares
* hw support and drivers in bootloaders
* kernel drivers and hardware interfaces
* hardware-related adaptation in operating systems
* tools for firmware flashing
* tools for low-level development

FOSDEM is very much an open source community event, please refrain from 
turning in a talk that is meant to be purely corporate or a product 
commercial. Also, this is a highly technical devroom on a conference 
aimed at developers and advanced users, so only submit a talk on a 
subject you actually are involved with. Finally, this devrooms focus is 
the technical aspects of the hardware and its enablement in free 
projects, rather than the specific applications and use cases that 
benefit from it.

With the return of the Embedded and Automotive DevRoom, we have the 
ability to schedule full hour talks again, and to go in-depth. If you 
however only need half an hour, then this is of course also possible.

Talk Submission:

The venerable pentabarf system will once again be used for talk 
submission.

https://penta.fosdem.org/submission/FOSDEM20

When in pentabarf, spend some time on the abstract and description, for 
both the event and the speaker. The abstract should be a shortened 
description, and the event abstract will sometimes even be printed 
directly in the booklet. BUT, on the website the abstract is immediately 
followed by the full description. If your abstract is fully descriptive, 
while terse, you might get away with just the abstract. As soon as your 
talk is scheduled by the devroom managers, you can see the result of 
your handiwork on the main website.

Please re-use your old pentabarf account instead of creating a new one: 
lost password: https://penta.fosdem.org/user/forgot_password

Talks are either 50 minutes or 20 minutes long, plus 5 minutes for 
questions.

All talks will be recorded, and will be streamed out live, and will 
later be made available as CC-BY, sometimes minutes after your talk has 
finished.

As for deadlines, the fosdem organizers want to have a finished schedule 
by the 15th of december, but do not count on that deadline, there are 
only a limited number of slots available. Given my belatedness in 
sending out this CFP, i might get a few more days if i am really really 
nice to the core FOSDEM organizers, but again, do not count on that 
(extra hugs only go so far when you're built like i am).

On your personal page:
* General:
  * First and last name
  * Nickname
  * Image
  * Contact:
   * email address
   * mobile number (this is a very hard requirement as there will be no 
other reliable form of emergency communication on the day)
* Description:
  * Abstract
  * Description

Create an event:
* On the General page:
  * Event title
  * Event subtitle.
  * Track: Hardware Enablement Devroom
  * Event type: Lecture (talk) or Meeting (BoF)
* Persons:
  * Add yourself as speaker.
* Description:
  * Abstract:
  * Full Description
* Schedule:
  * select your preferred talk length, either 55 or 25 minutes.
* Links:
  * Add relevant links.

The mobile phone number is the hardest requirement, so you can be 
contacted on-the-day when something comes up. Speakers will all receive 
my mobile number in return.

Neither email nor phonenumber are publicy visible, nor will this 
information be used for anything outside of devroom organization. After 
your talk has been scheduled, i usually only send out a single email 
with some organizational details in the days before the event.

Everything else can be ignored or will be filled in by me or the FOSDEM 
organizers.

I will be keeping a keen eye on your submissions and will come back with 
further questions or make small fixes as needed. Feel free to poke me 
with any questions or anything, both on irc (libv@freenode) and on 
email (hardware-devroom-mana...@fosdem.org).

That's about it. Hope to see you all at FOSDEM :)

Luc Verhaegen.