[linux-sunxi] Re: [PATCH v2 1/3] logos: Add sunxi logo

2020-06-18 Thread Tom Rini
On Thu, Jun 18, 2020 at 09:16:30AM +0200, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Jun 18, 2020 at 01:54:35AM +0530, Jagan Teki wrote:
> > Add sunxi logo which would be used for splash screen support.
> > 
> > The original images were the crapped version from linux-sunxi.org
> > and generated using below step
> > 
> > $ convert sunxi.jpg -type Palette -colors 224 -depth 8 \
> > -compress none -verbose BMP3:tools/logos/sunxi.bmp
> > 
> > Signed-off-by: Jagan Teki 
> 
> I'm not entirely sure what the benefit of that is to be honest.
> 
> U-boot has a logo, why not use it?

I don't have strong feelings here.  Typically, it's a vendor that wants
their logo used rather than the community logo and not the community
bringing in the vendors logo for them.

-- 
Tom

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20200618130447.GK27801%40bill-the-cat.


signature.asc
Description: PGP signature


[linux-sunxi] Re: [PATCH v2 3/3] video: sunxi_display: Convert to DM_VIDEO

2020-06-18 Thread Jagan Teki
On Thu, Jun 18, 2020 at 12:54 PM Maxime Ripard  wrote:
>
> On Thu, Jun 18, 2020 at 01:54:37AM +0530, Jagan Teki wrote:
> > DM_VIDEO migration deadline is already expired, but around
> > 80 Allwinner boards are still using video in a legacy way.
> >
> > = WARNING ==
> > This board does not use CONFIG_DM_VIDEO Please update
> > the board to use CONFIG_DM_VIDEO before the v2019.07 release.
> > Failure to update by the deadline may result in board removal.
> > See doc/driver-model/migration.rst for more info.
> > 
> >
> > So let's live these boards on the tree before the video maintainer
> > removes it by converting in to DM_VIDEO.
> >
> > Tested in Bananapi M1+ Plus 1920x1200 HDMI out.
> >
> > Signed-off-by: Jagan Teki 
> > ---
> > Changes for v2:
> > - add BMP support
> >
> >  arch/arm/mach-sunxi/Kconfig |   4 +-
> >  drivers/video/sunxi/sunxi_display.c | 264 
> >  include/configs/sunxi-common.h  |  17 --
> >  scripts/config_whitelist.txt|   1 -
> >  4 files changed, 157 insertions(+), 129 deletions(-)
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index be0822bfb7..7d2fb55ff0 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -758,8 +758,10 @@ config VIDEO_SUNXI
> >   depends on !MACH_SUN9I
> >   depends on !MACH_SUN50I
> >   depends on !MACH_SUN50I_H6
> > - select VIDEO
> > + select DM_VIDEO
> > + select DISPLAY
> >   imply VIDEO_DT_SIMPLEFB
> > + imply CMD_BMP
> >   default y
> >   ---help---
> >   Say Y here to add support for using a cfb console on the HDMI, LCD
> > diff --git a/drivers/video/sunxi/sunxi_display.c 
> > b/drivers/video/sunxi/sunxi_display.c
> > index f52aba4d21..fb51b0c5ba 100644
> > --- a/drivers/video/sunxi/sunxi_display.c
> > +++ b/drivers/video/sunxi/sunxi_display.c
> > @@ -7,6 +7,8 @@
> >   */
> >
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -28,7 +30,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> > +#include 
> >  #include "../videomodes.h"
> >  #include "../anx9804.h"
> >  #include "../hitachi_tx18d42vm_lcd.h"
> > @@ -45,6 +49,13 @@
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > +enum {
> > + /* Maximum LCD size we support */
> > + LCD_MAX_WIDTH   = 3840,
> > + LCD_MAX_HEIGHT  = 2160,
> > + LCD_MAX_LOG2_BPP= VIDEO_BPP32,
> > +};
>
> Why is that an enum? Those three values don't have any relationship with
> each other.

Not sure I understand your question. These are maximum resolution
followed by maximum bpp supporting. based on these the fbbuffer
allocation happens, please see sunxi_de_bind on this patch.

>
> >  enum sunxi_monitor {
> >   sunxi_monitor_none,
> >   sunxi_monitor_dvi,
> > @@ -59,12 +70,11 @@ enum sunxi_monitor {
> >  #define SUNXI_MONITOR_LAST sunxi_monitor_composite_pal_nc
> >
> >  struct sunxi_display {
> > - GraphicDevice graphic_device;
> >   enum sunxi_monitor monitor;
> >   unsigned int depth;
> >   unsigned int fb_addr;
> >   unsigned int fb_size;
> > -} sunxi_display;
> > +};
>
> This looks unrelated?
>
> >  const struct ctfb_res_modes composite_video_modes[2] = {
> >   /*  x y  hz  pixclk ps/kHz   le   ri  up  lo   hs vs  s  vmode */
> > @@ -214,7 +224,8 @@ static int sunxi_hdmi_edid_get_block(int block, u8 *buf)
> >   return r;
> >  }
> >
> > -static int sunxi_hdmi_edid_get_mode(struct ctfb_res_modes *mode,
> > +static int sunxi_hdmi_edid_get_mode(struct sunxi_display *sunxi_display,
> > + struct ctfb_res_modes *mode,
> >   bool verbose_mode)
> >  {
> >   struct edid1_info edid1;
> > @@ -291,14 +302,14 @@ static int sunxi_hdmi_edid_get_mode(struct 
> > ctfb_res_modes *mode,
> >   }
> >
> >   /* Check for basic audio support, if found enable hdmi output */
> > - sunxi_display.monitor = sunxi_monitor_dvi;
> > + sunxi_display->monitor = sunxi_monitor_dvi;
> >   for (i = 0; i < ext_blocks; i++) {
> >   if (cea681[i].extension_tag != EDID_CEA861_EXTENSION_TAG ||
> >   cea681[i].revision < 2)
> >   continue;
> >
> >   if (EDID_CEA861_SUPPORTS_BASIC_AUDIO(cea681[i]))
> > - sunxi_display.monitor = sunxi_monitor_hdmi;
> > + sunxi_display->monitor = sunxi_monitor_hdmi;
> >   }
> >
> >   return 0;
> > @@ -414,9 +425,9 @@ static void sunxi_frontend_mode_set(const struct 
> > ctfb_res_modes *mode,
> >  static void sunxi_frontend_enable(void) {}
> >  #endif
> >
> > -static bool sunxi_is_composite(void)
> > +static bool sunxi_is_composite(enum sunxi_monitor monitor)
> >  {
> > - switch (sunxi_display.monitor) {
> > + switch (monitor) {
> >   case 

[linux-sunxi] Re: [PATCH v2 3/3] video: sunxi_display: Convert to DM_VIDEO

2020-06-18 Thread Michael Nazzareno Trimarchi
Hi

On Thu, Jun 18, 2020 at 6:07 PM Jagan Teki  wrote:
>
> On Thu, Jun 18, 2020 at 12:54 PM Maxime Ripard  wrote:
> >
> > On Thu, Jun 18, 2020 at 01:54:37AM +0530, Jagan Teki wrote:
> > > DM_VIDEO migration deadline is already expired, but around
> > > 80 Allwinner boards are still using video in a legacy way.
> > >
> > > = WARNING ==
> > > This board does not use CONFIG_DM_VIDEO Please update
> > > the board to use CONFIG_DM_VIDEO before the v2019.07 release.
> > > Failure to update by the deadline may result in board removal.
> > > See doc/driver-model/migration.rst for more info.
> > > 
> > >
> > > So let's live these boards on the tree before the video maintainer
> > > removes it by converting in to DM_VIDEO.
> > >
> > > Tested in Bananapi M1+ Plus 1920x1200 HDMI out.
> > >
> > > Signed-off-by: Jagan Teki 
> > > ---
> > > Changes for v2:
> > > - add BMP support
> > >
> > >  arch/arm/mach-sunxi/Kconfig |   4 +-
> > >  drivers/video/sunxi/sunxi_display.c | 264 
> > >  include/configs/sunxi-common.h  |  17 --
> > >  scripts/config_whitelist.txt|   1 -
> > >  4 files changed, 157 insertions(+), 129 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > > index be0822bfb7..7d2fb55ff0 100644
> > > --- a/arch/arm/mach-sunxi/Kconfig
> > > +++ b/arch/arm/mach-sunxi/Kconfig
> > > @@ -758,8 +758,10 @@ config VIDEO_SUNXI
> > >   depends on !MACH_SUN9I
> > >   depends on !MACH_SUN50I
> > >   depends on !MACH_SUN50I_H6
> > > - select VIDEO
> > > + select DM_VIDEO
> > > + select DISPLAY
> > >   imply VIDEO_DT_SIMPLEFB
> > > + imply CMD_BMP
> > >   default y
> > >   ---help---
> > >   Say Y here to add support for using a cfb console on the HDMI, LCD
> > > diff --git a/drivers/video/sunxi/sunxi_display.c 
> > > b/drivers/video/sunxi/sunxi_display.c
> > > index f52aba4d21..fb51b0c5ba 100644
> > > --- a/drivers/video/sunxi/sunxi_display.c
> > > +++ b/drivers/video/sunxi/sunxi_display.c
> > > @@ -7,6 +7,8 @@
> > >   */
> > >
> > >  #include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -28,7 +30,9 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > > +#include 
> > >  #include "../videomodes.h"
> > >  #include "../anx9804.h"
> > >  #include "../hitachi_tx18d42vm_lcd.h"
> > > @@ -45,6 +49,13 @@
> > >
> > >  DECLARE_GLOBAL_DATA_PTR;
> > >
> > > +enum {
> > > + /* Maximum LCD size we support */
> > > + LCD_MAX_WIDTH   = 3840,
> > > + LCD_MAX_HEIGHT  = 2160,
> > > + LCD_MAX_LOG2_BPP= VIDEO_BPP32,
> > > +};
> >
> > Why is that an enum? Those three values don't have any relationship with
> > each other.
>
> Not sure I understand your question. These are maximum resolution
> followed by maximum bpp supporting. based on these the fbbuffer
> allocation happens, please see sunxi_de_bind on this patch.
>
> >
> > >  enum sunxi_monitor {
> > >   sunxi_monitor_none,
> > >   sunxi_monitor_dvi,
> > > @@ -59,12 +70,11 @@ enum sunxi_monitor {
> > >  #define SUNXI_MONITOR_LAST sunxi_monitor_composite_pal_nc
> > >
> > >  struct sunxi_display {
> > > - GraphicDevice graphic_device;
> > >   enum sunxi_monitor monitor;
> > >   unsigned int depth;
> > >   unsigned int fb_addr;
> > >   unsigned int fb_size;
> > > -} sunxi_display;
> > > +};
> >
> > This looks unrelated?
> >
> > >  const struct ctfb_res_modes composite_video_modes[2] = {
> > >   /*  x y  hz  pixclk ps/kHz   le   ri  up  lo   hs vs  s  vmode 
> > > */
> > > @@ -214,7 +224,8 @@ static int sunxi_hdmi_edid_get_block(int block, u8 
> > > *buf)
> > >   return r;
> > >  }
> > >
> > > -static int sunxi_hdmi_edid_get_mode(struct ctfb_res_modes *mode,
> > > +static int sunxi_hdmi_edid_get_mode(struct sunxi_display *sunxi_display,
> > > + struct ctfb_res_modes *mode,
> > >   bool verbose_mode)
> > >  {
> > >   struct edid1_info edid1;
> > > @@ -291,14 +302,14 @@ static int sunxi_hdmi_edid_get_mode(struct 
> > > ctfb_res_modes *mode,
> > >   }
> > >
> > >   /* Check for basic audio support, if found enable hdmi output */
> > > - sunxi_display.monitor = sunxi_monitor_dvi;
> > > + sunxi_display->monitor = sunxi_monitor_dvi;
> > >   for (i = 0; i < ext_blocks; i++) {
> > >   if (cea681[i].extension_tag != EDID_CEA861_EXTENSION_TAG ||
> > >   cea681[i].revision < 2)
> > >   continue;
> > >
> > >   if (EDID_CEA861_SUPPORTS_BASIC_AUDIO(cea681[i]))
> > > - sunxi_display.monitor = sunxi_monitor_hdmi;
> > > + sunxi_display->monitor = sunxi_monitor_hdmi;
> > >   }
> > >
> > >   return 0;
> > > @@ -414,9 +425,9 @@ 

Re: [linux-sunxi] Boot to FEL mode with fastboot or adb shell

2020-06-18 Thread Matt Krenik
Would you (or someone you know) be interested in (paid) consulting,
contract work, or mentorship? I'm a new engineer working as the sole
firmware developer at a startup, and I feel like I'm in a bit over my head.
Even some small amount of guidance would be invaluable for developing as an
engineer and being able to contribute to the company.

Best,
Matt

On Wed, Jun 3, 2020 at 6:15 AM Arti Zirk  wrote:

> On T, 2020-06-02 at 22:33 -0500, Matt Krenik wrote:
> > Hello Arti,
> >
> > Thanks so much for your detailed reply. I tried the first suggestion
> > of just zeroing out the initial SPL loader. Its not clear if I
> > accessed the correct location, because there is no /dev/mmcblk0.
> > Instead I tried a few different options, including: '/dev/block/by-
> > name/boot'  '/dev/block/by-name/bootloader' and '/dev/block/nanda'.
> > In each of the cases, I believe the device is getting past the
> > initial SPL loader, but is getting stuck on the main bootloader. I'll
> > keep trying to find out what memory device could store the initial
> > SPL loader.
>
> Its possible that SPL is stored in raw NAND or in a SPI Flash chip. You
> probably have to hook up serial console to figure that out.
>
>
> > I did notice that when I probe 'lsusb' when the device is first
> > starting, the device appears in flash mode for a small window of time
> > before loading the bootloader. I have been unable to figure out a way
> > to take advantage of this to flash the device (I tried starting the
> > sunxi-livesuite gui), since it proceeds to the bootloader. This was
> > surprising to me according to the documentation on the Sunxi linux
> > wiki. Its clear that I'm working with some custom/vendor firmware
> > that might differ from what is standard.
> >
> > Again, thanks for your help. It seems that I'm on my own since I'm
> > working with hardware that differs from what this community supports.
> > But if you have any tips on what I can investigate, I would find it
> > extremely helpful.
> >
> > Best,
> > Matt
>
>
> --
> 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.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/linux-sunxi/5281ce053fc8cb663a862c8130a8107abbcf0c44.camel%40gmail.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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/CA%2Bxp7W-NmkAf6tDvKj-fn3rK%3DhgdBME3rgM1UjrLda78%2B1KtRg%40mail.gmail.com.