Missing Kernel Configuration Options For WM8505-Based Device

[Matt Edwards]

Hi guys,

I am trying to compile a working Linux kernel for my WM8505-based Sylvania SYNET07526 7" Smartbook, but am running into some issues.  I've been following the instructions for "Build the source" found at the following link in the wiki: https://github.com/linux-wmt/linux-vtwm/wiki/Build-the-source.  However, when I run:

    make ARCH=arm menuconfig

to configure the kernel, I do not find some of the options listed in the wiki for the 8505 configuration.

For example, the wiki states that for "System Type" there should be options for "VIA/Wondermedia 85xx and WM8650", "Wondermedia WM8750", and "Wondermedia WM8850".  The only one of these three options that appears is "Wondermedia WM8850", but I would assume that my device requires the "VIA/Wondermedia 85xx and WM8650" option.

In addition, the wiki states that for "System Type->Multiple platform selection" I should select "ARMv5" for my WM8505 device.  Unfortunately the only options presented to me are ARMv6 and ARMv7, which the wiki states are for WM8750 and WM8850 devices, respectively.

Can someone tell me what I am doing wrong?  Any help would be greatly appreciated.

Thanks guys!


--Matt

[Alexey Charkov]

2017-09-21 19:06 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
> Hi guys,
>
> I am trying to compile a working Linux kernel for my WM8505-based Sylvania
> SYNET07526 7" Smartbook, but am running into some issues. I've been
> following the instructions for "Build the source" found at the following
> link in the wiki:
> https://github.com/linux-wmt/linux-vtwm/wiki/Build-the-source. However,
> when I run:
>
> make ARCH=arm menuconfig
>
> to configure the kernel, I do not find some of the options listed in the
> wiki for the 8505 configuration.
>
> For example, the wiki states that for "System Type" there should be options
> for "VIA/Wondermedia 85xx and WM8650", "Wondermedia WM8750", and
> "Wondermedia WM8850". The only one of these three options that appears is
> "Wondermedia WM8850", but I would assume that my device requires the
> "VIA/Wondermedia 85xx and WM8650" option.

Hi Matt,

85xx option will only be available when you have ARMv5 support
enabled, and v5 cannot coexist in the same kernel image with v6/v7. So
please disable anything 88xx and 87xx first.

> In addition, the wiki states that for "System Type->Multiple platform
> selection" I should select "ARMv5" for my WM8505 device. Unfortunately the
> only options presented to me are ARMv6 and ARMv7, which the wiki states are
> for WM8750 and WM8850 devices, respectively.

Sounds like you might have some ARMv6 or ARMv7 systems enabled, so
please try first deselecting everything under System Type, then
deselecting ARMv6 and ARMv7, then I believe ARMv5 option should appear
(and so you'll be able to select WM85xx support).

Best regards,
Alexey

[Matt Edwards]

On Monday, September 25, 2017 at 3:18:41 AM UTC-4, Alexey Charkov wrote:

Hi Matt,

85xx option will only be available when you have ARMv5 support
enabled, and v5 cannot coexist in the same kernel image with v6/v7. So
please disable anything 88xx and 87xx first.

Sounds like you might have some ARMv6 or ARMv7 systems enabled, so
please try first deselecting everything under System Type, then
deselecting ARMv6 and ARMv7, then I believe ARMv5 option should appear
(and so you'll be able to select WM85xx support).

Best regards,
Alexey

Thanks Alexey, that did the trick.  I created the .config file following the instructions for the WM8505 in the "Build the source" section of the linux-vtwm wiki.  However, when I attempted to compile the kernel I received a fatal error for a missing header file (linux/compiler-gcc5.h).  I have confirmed that compiler-gcc5.h is nowhere to be found on my PC and, if it matters, my current version of gcc is 5.4.0.  Here is the output from my failed compilation; any idea what might allow me to get past this issue?

bluefish@Redfish ~/Development/Arm-Linux/linux-vtwm $ time make -j2 ARCH=arm zImage modules CROSS_COMPILE=arm-linux-gnueabihf-

  HOSTLD  scripts/kconfig/conf

scripts/kconfig/conf --silentoldconfig Kconfig

  CHK     include/config/kernel.release

  WRAP    arch/arm/include/generated/asm/auxvec.h

  WRAP    arch/arm/include/generated/asm/bitsperlong.h

  WRAP    arch/arm/include/generated/asm/cputime.h

  WRAP    arch/arm/include/generated/asm/current.h

  WRAP    arch/arm/include/generated/asm/emergency-restart.h

  WRAP    arch/arm/include/generated/asm/errno.h

  WRAP    arch/arm/include/generated/asm/exec.h

  WRAP    arch/arm/include/generated/asm/ioctl.h

  WRAP    arch/arm/include/generated/asm/ipcbuf.h

  WRAP    arch/arm/include/generated/asm/irq_regs.h

  WRAP    arch/arm/include/generated/asm/kdebug.h

  WRAP    arch/arm/include/generated/asm/local.h

  WRAP    arch/arm/include/generated/asm/local64.h

  WRAP    arch/arm/include/generated/asm/msgbuf.h

  WRAP    arch/arm/include/generated/asm/param.h

  UPD     include/config/kernel.release

  WRAP    arch/arm/include/generated/asm/parport.h

  WRAP    arch/arm/include/generated/asm/poll.h

  WRAP    arch/arm/include/generated/asm/resource.h

  WRAP    arch/arm/include/generated/asm/sections.h

  CHK     include/generated/uapi/linux/version.h

  WRAP    arch/arm/include/generated/asm/segment.h

  UPD     include/generated/uapi/linux/version.h

  WRAP    arch/arm/include/generated/asm/sembuf.h

  WRAP    arch/arm/include/generated/asm/serial.h

  WRAP    arch/arm/include/generated/asm/shmbuf.h

  WRAP    arch/arm/include/generated/asm/siginfo.h

  WRAP    arch/arm/include/generated/asm/sizes.h

  WRAP    arch/arm/include/generated/asm/simd.h

  WRAP    arch/arm/include/generated/asm/socket.h

  WRAP    arch/arm/include/generated/asm/sockios.h

  WRAP    arch/arm/include/generated/asm/termios.h

  WRAP    arch/arm/include/generated/asm/termbits.h

  WRAP    arch/arm/include/generated/asm/timex.h

  WRAP    arch/arm/include/generated/asm/trace_clock.h

  WRAP    arch/arm/include/generated/asm/unaligned.h

  WRAP    arch/arm/include/generated/asm/preempt.h

  CHK     include/generated/utsrelease.h

  UPD     include/generated/utsrelease.h

  HOSTCC  scripts/dtc/checks.o

  HOSTCC  scripts/dtc/data.o

  SHIPPED scripts/dtc/dtc-lexer.lex.c

  SHIPPED scripts/dtc/dtc-parser.tab.h

  SHIPPED scripts/dtc/dtc-parser.tab.c

  HOSTCC  scripts/dtc/dtc.o

  HOSTCC  scripts/dtc/flattree.o

  HOSTCC  scripts/dtc/fstree.o

  HOSTCC  scripts/dtc/livetree.o

  HOSTCC  scripts/dtc/srcpos.o

  HOSTCC  scripts/dtc/treesource.o

  HOSTCC  scripts/dtc/util.o

  HOSTCC  scripts/dtc/dtc-lexer.lex.o

  Generating include/generated/mach-types.h

  CC      kernel/bounds.s

In file included from include/linux/compiler.h:54:0,

                 from include/uapi/linux/stddef.h:1,

                 from include/linux/stddef.h:4,

                 from /home/bluefish/Development/Arm-Linux/linux-vtwm/include/uapi/linux/posix_types.h:4,

                 from include/uapi/linux/types.h:13,

                 from include/linux/types.h:5,

                 from include/linux/page-flags.h:8,

                 from kernel/bounds.c:9:

include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory

compilation terminated.

/home/bluefish/Development/Arm-Linux/linux-vtwm/./Kbuild:35: recipe for target 'kernel/bounds.s' failed

make[1]: *** [kernel/bounds.s] Error 1

Makefile:859: recipe for target 'prepare0' failed

make: *** [prepare0] Error 2

make: *** Waiting for unfinished jobs....

  HOSTCC  scripts/dtc/dtc-parser.tab.o

  HOSTCC  scripts/genksyms/genksyms.o

  HOSTLD  scripts/dtc/dtc

  SHIPPED scripts/genksyms/lex.lex.c

  SHIPPED scripts/genksyms/keywords.hash.c

  SHIPPED scripts/genksyms/parse.tab.h

  SHIPPED scripts/genksyms/parse.tab.c

  HOSTCC  scripts/genksyms/lex.lex.o

  HOSTCC  scripts/genksyms/parse.tab.o

  CC      scripts/mod/empty.o

  HOSTCC  scripts/mod/mk_elfconfig

  CC      scripts/mod/devicetable-offsets.s

In file included from include/linux/compiler.h:54:0,

                 from include/uapi/linux/stddef.h:1,

                 from include/linux/stddef.h:4,

                 from /home/bluefish/Development/Arm-Linux/linux-vtwm/include/uapi/linux/posix_types.h:4,

                 from include/uapi/linux/types.h:13,

                 from include/linux/types.h:5,

                 from include/linux/mod_devicetable.h:11,

                 from scripts/mod/devicetable-offsets.c:2:

include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory

compilation terminated.

scripts/Makefile.build:204: recipe for target 'scripts/mod/devicetable-offsets.s' failed

make[2]: *** [scripts/mod/devicetable-offsets.s] Error 1

scripts/Makefile.build:455: recipe for target 'scripts/mod' failed

make[1]: *** [scripts/mod] Error 2

make[1]: *** Waiting for unfinished jobs....

  HOSTLD  scripts/genksyms/genksyms

Makefile:521: recipe for target 'scripts' failed

make: *** [scripts] Error 2

real 0m29.686s

user 0m41.848s

sys 0m4.116s

[Alexey Charkov]

2017-09-25 14:12 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
>
>
> On Monday, September 25, 2017 at 3:18:41 AM UTC-4, Alexey Charkov wrote:
>>
>>
>> Hi Matt,
>>
>> 85xx option will only be available when you have ARMv5 support
>> enabled, and v5 cannot coexist in the same kernel image with v6/v7. So
>> please disable anything 88xx and 87xx first.
>>
>> Sounds like you might have some ARMv6 or ARMv7 systems enabled, so
>> please try first deselecting everything under System Type, then
>> deselecting ARMv6 and ARMv7, then I believe ARMv5 option should appear
>> (and so you'll be able to select WM85xx support).
>>
>> Best regards,
>> Alexey
>
>
> Thanks Alexey, that did the trick. I created the .config file following the
> instructions for the WM8505 in the "Build the source" section of the
> linux-vtwm wiki. However, when I attempted to compile the kernel I received
> a fatal error for a missing header file (linux/compiler-gcc5.h). I have
> confirmed that compiler-gcc5.h is nowhere to be found on my PC and, if it
> matters, my current version of gcc is 5.4.0.

This is a known issue: newer GCC versions cannot be used to compile
the old version of the kernel. You'll have to either find an older GCC
(4.x) or manually rebase relevant patches on top of a newer kernel,
unfortunately.

I've started doing the latter a couple of months ago, but ran into
incompatible internal API changes somewhere (serial flash I think)
which I didn't have enough time to resolve. It should be fairly
straightforward, but requires some time to concentrate and wrap the
brain around the changes :)

You may also want to try a pure mainline kernel. One thing that will
be missing for sure is internal keyboard/touchpad support, but you
should be able to boot off SD card with graphics output, network and
USB support. If that works ok, then internal keyboard will only be one
patch away:

https://github.com/linux-wmt/linux-vtwm/commit/3f9af107bfe79cb2b18c4046c01b498b9cba27ed

Best,
Alexey

[Matt Edwards]

On Monday, September 25, 2017 at 7:26:40 AM UTC-4, Alexey Charkov wrote:

This is a known issue: newer GCC versions cannot be used to compile
the old version of the kernel. You'll have to either find an older GCC
(4.x) or manually rebase relevant patches on top of a newer kernel,
unfortunately.

I've started doing the latter a couple of months ago, but ran into
incompatible internal API changes somewhere (serial flash I think)
which I didn't have enough time to resolve. It should be fairly
straightforward, but requires some time to concentrate and wrap the
brain around the changes :)

You may also want to try a pure mainline kernel. One thing that will
be missing for sure is internal keyboard/touchpad support, but you
should be able to boot off SD card with graphics output, network and
USB support. If that works ok, then internal keyboard will only be one
patch away:

https://github.com/linux-wmt/linux-vtwm/commit/3f9af107bfe79cb2b18c4046c01b498b9cba27ed

Best,
Alexey

 

Thanks Alexey; I guess that would explain my problem.  As I am totally new to compiling Linux kernels, I am inclined to follow the path of least resistance, which I assume would be the first method that you described in which I will need to use an older version of GCC.  Would this involve me first removing my current version off GCC, and perhaps arm-linux-gnueabihf-gcc-5, before installing older versions of both?  I apologize for my ignorance; I'm still learning.  :P

[Alexey Charkov]

No worries, everyone begins somewhere - happy to help :-)

The easiest would be to scout the Internet for a pre-compiled cross
toolchain (e.g. from some older Android SDK, or a CodeSourcery one, or
something similar). Those you can just unpack somewhere and run by
specifying full path to gcc in CROSS_COMPILE=... argument. No need to
remove your existing compiler that way.

[Matt Edwards]

On Monday, September 25, 2017 at 11:59:32 AM UTC-4, Alexey Charkov wrote:

No worries, everyone begins somewhere - happy to help :-)

The easiest would be to scout the Internet for a pre-compiled cross
toolchain (e.g. from some older Android SDK, or a CodeSourcery one, or
something similar). Those you can just unpack somewhere and run by
specifying full path to gcc in CROSS_COMPILE=... argument. No need to
remove your existing compiler that way.

Hi Alexey,

I've been quiet the last couple of days because I have been making progress.  :-)

I was able to compile the kernel successfully after following your instructions regarding the use of an older version of GCC (I went with version 4.9).  However, I have reached another impasse.  I think my problem is that I do not have a proper u-boot script for my particular device.  I have been following the instructions provided by D. J. Bernstein here:

https://groups.google.com/forum/#!topic/vt8500-wm8505-linux-kernel/rWjZu4PWmiM

and have been modifying them when I know to do so.  D. J. was creating an SD card for an 8850-based device, and I have an 8505-based Sylvania Smartbook.  D. J.'s instructions for the FAT32 partition on the SD card are as follows:

     mount /dev/${SDCARD}p1 $MOUNT
     (
       echo mmcinit 0
       echo fatload mmc 0 0 FirmwareInstall/uzImage.bin
       echo setenv wmt.gpo.wifi 6:1:6:d8110040:d8110080:d81100C0
       echo setenv bootargs mem=448M root=/dev/mmcblk0p3 rootwait noinitrd rw init=/bin/bash
       echo bootm 0
     ) > /root/wmt_scriptcmd.in
     mkimage -A arm -O linux -T script -C none -a 1 -e 0 -n "Created by Win32" -d /root/wmt_scriptcmd.in $MOUNT/wmt_scriptcmd
     cp $MOUNT/wmt_scriptcmd $MOUNT/scriptcmd
     mkdir -p $MOUNT/FirmwareInstall
     cp $MOUNT/wmt_scriptcmd $MOUNT/FirmwareInstall/autorun.1.wmt
     cp uzImage.bin $MOUNT/FirmwareInstall
     umount $MOUNT

The first thing that jumped out at me is the "mem" setting of 448M.  My device only has 128M of memory, so I know that 448M is not correct for my device.
I also noticed that D. J.'s strategy does not create a "script" directory in the FAT32 partition, which I thought was a requirement.  So far all of my attempts
have failed to produce a working SD card.  Every time I boot up my Smartbook it simply ignores the SD card.  Would you happen to know of any
documentation that can I reference for creating a proper u-boot setup for an 8505-based device?  Once I finally have a properly booting SD card, I'll be glad
to document the entire process for other 8505 users to reference, just as D. J. did for 8850-based devices.

Thank you for all of your ongoing support Alexey; it is very appreciated!


--Matt

[Alexey Charkov]

2017-09-27 13:19 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
> The first thing that jumped out at me is the "mem" setting of 448M. My
> device only has 128M of memory, so I know that 448M is not correct for my
> device.

Just set "mem" to whatever actual amount of memory your device has
(128M sounds about right for 8505). I believe it will default to
either 128M or 64M if you omit it altogether. A lower setting is
required if you use the vendor kernel (the "unused" area goes for a
framebuffer there).

> I also noticed that D. J.'s strategy does not create a "script" directory in
> the FAT32 partition, which I thought was a requirement.

It's a bit hard to tell which particular filename you'll need, but you
seem to be following all the right steps. Just try to copy your
mkimage-wrapped boot script into several common locations
(./wmt_scriptcmd, ./scriptcmd, ./script/scriptcmd and such). They've
changed the required file path in u-boot several times, so it's a bit
hard to recall now. There are probably some old forum posts on the
Internet mentioning the right path, but I don't remember off the top
of my head.

> So far all of my
> attempts
> have failed to produce a working SD card. Every time I boot up my Smartbook
> it simply ignores the SD card. Would you happen to know of any
> documentation that can I reference for creating a proper u-boot setup for an
> 8505-based device? Once I finally have a properly booting SD card, I'll be
> glad
> to document the entire process for other 8505 users to reference, just as D.
> J. did for 8850-based devices.

That would be much appreciated, thank you!

Cheers,
Alexey

[Alexey Charkov]

2017-09-27 13:29 GMT+03:00 Alexey Charkov <alc...@gmail.com>:
> 2017-09-27 13:19 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
>> The first thing that jumped out at me is the "mem" setting of 448M. My
>> device only has 128M of memory, so I know that 448M is not correct for my
>> device.
>
> Just set "mem" to whatever actual amount of memory your device has
> (128M sounds about right for 8505). I believe it will default to
> either 128M or 64M if you omit it altogether. A lower setting is
> required if you use the vendor kernel (the "unused" area goes for a
> framebuffer there).
>
>> I also noticed that D. J.'s strategy does not create a "script" directory in
>> the FAT32 partition, which I thought was a requirement.
>
> It's a bit hard to tell which particular filename you'll need, but you
> seem to be following all the right steps. Just try to copy your
> mkimage-wrapped boot script into several common locations
> (./wmt_scriptcmd, ./scriptcmd, ./script/scriptcmd and such). They've
> changed the required file path in u-boot several times, so it's a bit
> hard to recall now. There are probably some old forum posts on the
> Internet mentioning the right path, but I don't remember off the top
> of my head.

Matt, I've just checked some of the older sources - the filename
should be ./script/scriptcmd on WM8505. Just copy your wmt_scriptcmd
under that name/path.

Let us know if that works out.

Cheers,
Alexey

[Matt Edwards]

Will do Alexey; thank you sir!

Matt

--
You received this message because you are subscribed to a topic in the Google Groups "VT8500/WM8505 Linux Kernel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vt8500-wm8505-linux-kernel/-5V20yDM4jQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vt8500-wm8505-linux-kernel+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Edwards]

On Thursday, September 28, 2017 at 6:28:13 AM UTC-4, Alexey Charkov wrote:2017-09-27 13:29 GMT+03:00 Alexey Charkov <alc...@gmail.com>:

Matt, I've just checked some of the older sources - the filename
should be ./script/scriptcmd on WM8505. Just copy your wmt_scriptcmd
under that name/path.

Let us know if that works out.

Cheers,
Alexey

Hi Alexey,

I found an old SC card in a drawer with a working u-boot script and kernel that someone else had compiled several years ago along with a tarball for the root filesystem.  The card does boot up into a login screen (I no longer remember the default username and password), but as I recall the built-in keyboard and wifi do not work, and it suffers from the screen brightness issue where the screen is almost pitch black.  Anyway, I copied the u-boot script from this old setup over to my new SD card and used it in conjunction with the kernel that I compiled earlier this week.  It has the same screen brightness problem, but when I moved it to a dim room in my house, I found that it did start to boot into Linux.  Unfortunately it hung early in the boot-up process.  I wasn't sure how else to capture the text on the screen so I took a picture of it with my phone (hopefully it appears below).  Does this information give you any clue regarding my underlying issue?  The process never seemed to proceed any further, but I could not be sure as my screen eventually went completely black and would not respond to any key presses using the built-in keyboard or an external USB keyboard that I tried as well.

By the way, I am using a 32GB micro SDHC card with a full-sized SD card adapter for my setup, if that matters.

Thanks Alexey!

Matt

[Alexey Charkov]

On Thu, 28 Sep 2017 at 19:16, Matt Edwards <oasisc...@gmail.com> wrote:

On Thursday, September 28, 2017 at 6:28:13 AM UTC-4, Alexey Charkov wrote:2017-09-27 13:29 GMT+03:00 Alexey Charkov <alc...@gmail.com>:

Matt, I've just checked some of the older sources - the filename
should be ./script/scriptcmd on WM8505. Just copy your wmt_scriptcmd
under that name/path.

Let us know if that works out.

Cheers,
Alexey

Hi Alexey,

I found an old SC card in a drawer with a working u-boot script and kernel that someone else had compiled several years ago along with a tarball for the root filesystem.  The card does boot up into a login screen (I no longer remember the default username and password), but as I recall the built-in keyboard and wifi do not work, and it suffers from the screen brightness issue where the screen is almost pitch black.  Anyway, I copied the u-boot script from this old setup over to my new SD card and used it in conjunction with the kernel that I compiled earlier this week.  It has the same screen brightness problem, but when I moved it to a dim room in my house, I found that it did start to boot into Linux.  Unfortunately it hung early in the boot-up process.  I wasn't sure how else to capture the text on the screen so I took a picture of it with my phone (hopefully it appears below).  Does this information give you any clue regarding my underlying issue?

Please try changing the sdon-inverted attribute in device tree. It detects your SD card, but for some reason can't read partitions on it.

As for the screen brightness issue- it's in fact screen contrast that's 1/8 of what it should be. It's an old issue related to a change in default contrast value to fit wm8650+ (which does RGB565) vs. wm8505 (which only supported ARGB8888). You may work around it by editing the file drivers/video/fbdev/wm8505fb.c and change 0x10 to 0x80 in the line that says:

	fbi->contrast = 0x10;

[Matt Edwards]

On Thursday, September 28, 2017 at 1:33:42 PM UTC-4, Alexey Charkov wrote:

Please try changing the sdon-inverted attribute in device tree. It detects your SD card, but for some reason can't read partitions on it.

As for the screen brightness issue- it's in fact screen contrast that's 1/8 of what it should be. It's an old issue related to a change in default contrast value to fit wm8650+ (which does RGB565) vs. wm8505 (which only supported ARGB8888). You may work around it by editing the file drivers/video/fbdev/wm8505fb.c and change 0x10 to 0x80 in the line that says:

	fbi->contrast = 0x10;

Hi Alexey,

Okay, will do.  I just have one question.  How do I go about changing the sdon-inverted attribute in the device tree?  Is that just a simple change in my .config file?  I know that this must be a real newbie question, but unfortunately that is exactly what I am.  :P

I'll be sure to make the change in the wm8505fb.c file.

Thanks Alexey!

--Matt

[Alexey Charkov]

Perfectly valid question... Go to the file
arch/arm/boot/dts/wm8505.dtsi, find the block titled "sdhc@d800a000",
and at the end within the curly braces add a new line that says
"sdon-inverted;" (without quotes). Save it, run make and you will get
a new wm8505-ref.dtb (device tree blob) that you will need to append
to your kernel.

By the way, was that the dtb file you are using? Just checking ;-)

Best,
Alexey

[Matt Edwards]

On Thursday, September 28, 2017 at 3:31:49 PM UTC-4, Alexey Charkov wrote:

Perfectly valid question... Go to the file
arch/arm/boot/dts/wm8505.dtsi, find the block titled "sdhc@d800a000",
and at the end within the curly braces add a new line that says
"sdon-inverted;" (without quotes). Save it, run make and you will get
a new wm8505-ref.dtb (device tree blob) that you will need to append
to your kernel.

By the way, was that the dtb file you are using? Just checking ;-)

Best,
Alexey

Hi Alexey,

Yes, wm8505-ref.dtb is the file that I have been using.  Based on your instructions, it sounds like I should end up with the following block inside of arch/arm/boot/dts/wm8505.dtsi:

        sdhc@d800a000 {
                compatible = "wm,wm8505-sdhc";
                reg = <0xd800a000 0x1000>;
                interrupts = <20 21>;
                clocks = <&clksdhc>;
                bus-width = <4>;

                sdon-inverted;

        };

Does that look correct?

Also, once I make the code change to wm8505fb.c to address the screen brightness issue, do I need to recompile the kernel, or is that file included in the making of wm8505-ref.dtb?  I really am making it clear how little I know aren't I?  ;)

Thanks a ton Alexey!

Matt

[Alexey Charkov]

On Thu, 28 Sep 2017 at 22:59, Matt Edwards <oasisc...@gmail.com> wrote:

On Thursday, September 28, 2017 at 3:31:49 PM UTC-4, Alexey Charkov wrote:

Perfectly valid question... Go to the file
arch/arm/boot/dts/wm8505.dtsi, find the block titled "sdhc@d800a000",
and at the end within the curly braces add a new line that says
"sdon-inverted;" (without quotes). Save it, run make and you will get
a new wm8505-ref.dtb (device tree blob) that you will need to append
to your kernel.

By the way, was that the dtb file you are using? Just checking ;-)

Best,
Alexey

Hi Alexey,

Yes, wm8505-ref.dtb is the file that I have been using.  Based on your instructions, it sounds like I should end up with the following block inside of arch/arm/boot/dts/wm8505.dtsi:

        sdhc@d800a000 {
                compatible = "wm,wm8505-sdhc";
                reg = <0xd800a000 0x1000>;
                interrupts = <20 21>;
                clocks = <&clksdhc>;
                bus-width = <4>;

                sdon-inverted;

        };

Does that look correct?

Yepp!

Also, once I make the code change to wm8505fb.c to address the screen brightness issue, do I need to recompile the kernel, or is that file included in the making of wm8505-ref.dtb?  I really am making it clear how little I know aren't I?  ;)

Just run make again. Your dtsi changes will then be reflected in the dtb file, and everything that's changed in .c files will be recompiled into a new zImage. Then you concatenate the two and wrap them with mkimage just as you've been doing before.

Cheers,

Alexey

[Matt Edwards]

On Thursday, September 28, 2017 at 4:07:37 PM UTC-4, Alexey Charkov wrote:

Just run make again. Your dtsi changes will then be reflected in the dtb file, and everything that's changed in .c files will be recompiled into a new zImage. Then you concatenate the two and wrap them with mkimage just as you've been doing before.

Cheers,

Alexey

Oh okay gotcha.  The instructions that I have been following actually involve two invocations of "make", one to create a zImage file and another to create the dtb file.  I will rerun both calls to make and will let you know how it goes.  I'm compiling on an old Atom N270-based netbook, so it will be running for several hours.  :P

Thanks so much for your help Alexey.  Without your instructions I would be helplessly lost.

[Matt Edwards]

On Thursday, September 28, 2017 at 4:07:37 PM UTC-4, Alexey Charkov wrote:

Just run make again. Your dtsi changes will then be reflected in the dtb file, and everything that's changed in .c files will be recompiled into a new zImage. Then you concatenate the two and wrap them with mkimage just as you've been doing before.

Cheers,

Alexey

Okay, what I thought would take several hours only took several minutes.  I neglected to consider that I was only changing the one C program, so "make" only had to recompile the one file.  :P

Anyway, my screen brightness issue has definitely gone away!  However, I seem to be stuck in a loop during boot-up.  The following screen images will hopefully mean something to you.  Please let me know if there is anything that you would like for me to try.

Thanks Alexey.  :)

Matt

[Alexey Charkov]

Well, it times out trying to do something to the SD card, so apparently you didn't need sdon-inverted in the first place. Maybe it was hanging somewhere else.

I've noticed you're using the 3.13 branch - could you please try 'git checkout origin/testing-alchark' to get to a slightly fresher kernel version? You'll need to reapply the changes you've made though.

I think people had random hangs with 3.13 that seemed to magically go away after updating.

[Matt Edwards]

On Thursday, September 28, 2017 at 5:30:06 PM UTC-4, Alexey Charkov wrote:

Well, it times out trying to do something to the SD card, so apparently you didn't need sdon-inverted in the first place. Maybe it was hanging somewhere else.

I've noticed you're using the 3.13 branch - could you please try 'git checkout origin/testing-alchark' to get to a slightly fresher kernel version? You'll need to reapply the changes you've made though.

I think people had random hangs with 3.13 that seemed to magically go away after updating.

Sure thing Alexey; I'll be glad to try anything that might work.  Will I still need to use an older version of GCC (pre-5.0) to compile the code in your branch?

[Alexey Charkov]

For now yes unfortunately, as I haven't had chance to update it in a while. It's still newer than 3.13 but not quite enough.

[Matt Edwards]

On Thursday, September 28, 2017 at 5:30:06 PM UTC-4, Alexey Charkov wrote:

Well, it times out trying to do something to the SD card, so apparently you didn't need sdon-inverted in the first place. Maybe it was hanging somewhere else.

I've noticed you're using the 3.13 branch - could you please try 'git checkout origin/testing-alchark' to get to a slightly fresher kernel version? You'll need to reapply the changes you've made though.

I think people had random hangs with 3.13 that seemed to magically go away after updating.

Hi Alexey,

I checked out your "testing-alchark" branch and compiled it, but I'm guessing that it may not have been entirely successful because it did not create a new zImage file (compiler out with error messages appears below).  However, my problem may be in my technique, so let me detail the steps that I took on my end.

• I did not perform a "make clean" before I started compiling.  I thought that this might save me some time for modules that were already up-to-date, but now I'm not sure.  Should I have run a "make clean" first?

• I know you mentioned in your above message that I would need to reapply all of my changes, which I assumed would also include the i-8042 patch file (0001-input-vt8500-Add-support-for-devicetree-to-i8042-dri.patch).  Should I not have applied this patch?

• When I initiated "make" against your branch, the process paused approximately 300 times to ask me questions about new features.  I had no idea what to choose at these prompts (because I had no idea what most of them meant) so I simply hit the enter key for each one without indicating a selection.  Could that have caused a problem?  I have included some examples below.

System V IPC (SYSVIPC) [Y/n/?] y
POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y
Enable process_vm_readv/writev syscalls (CROSS_MEMORY_ATTACH) [Y/n/?] y
open by fhandle syscalls (FHANDLE) [Y/n/?] y
uselib syscall (USELIB) [Y/n/?] (NEW)
Task_based RCU implementation using voluntary context switch (TASKS_RCU) [N/y/?] (NEW)
    Include legacy /proc/<pid>/cpuset file (PROC_PID_CPUSET) [Y/n] y
  Simple CPU accounting cgroup subsystem (CGROUP_CPUACCT) [Y/n/?] y
  Memory Resource Controller for Control Groups (MEMCG) [N/y/?] (NEW)
    Memory Resource Controller Swap Extension (MEMCG_SWAP) [N/y/?] (NEW) 
      Memory Resource Controller Swap Extension enabled by default (MEMCG_SWAP_ENABLED) [Y/n/?] (NEW)
    Memory Resource Controller Kernel Memory accounting (MEMCG_KMEM) [N/y/?] (NEW)

• You had mentioned in a prior message that I simply needed to initiate the "make" command to create both a zImage file and a dtb file.  However, I have been using the make statements that I found in D. J. Bernstein's instructions provided in a prior forum thread (https://groups.google.com/forum/#!topic/vt8500-wm8505-linux-kernel/rWjZu4PWmiM), which are as follows:

For zImage file:  time make -j2 ARCH=arm zImage modules CROSS_COMPILE=arm-linux-gnueabihf-

For dtb file:     time make ARCH=arm dtbs CROSS_COMPILE=arm-linux-gnueabihf-

Could the way that I am using "make" be part of my problem?

By the way, here is the latter portion of my compiler output containing some error messages:

  CC      drivers/input/serio/i8042.o
drivers/input/serio/i8042.c: In function 'i8042_stop':
drivers/input/serio/i8042.c:417:18: error: 'I8042_AUX_IRQ' undeclared (first use in this function)
  synchronize_irq(I8042_AUX_IRQ);
                  ^
drivers/input/serio/i8042.c:417:18: note: each undeclared identifier is reported only once for each function it appears in
drivers/input/serio/i8042.c:418:18: error: ‘I8042_KBD_IRQ' undeclared (first use in this function)
  synchronize_irq(I8042_KBD_IRQ);
                  ^
drivers/input/serio/i8042.c: In function 'i8042_check_aux':
drivers/input/serio/i8042.c:806:18: error: 'I8042_AUX_IRQ' undeclared (first use in this function)
  if (request_irq(I8042_AUX_IRQ, i8042_aux_test_irq, IRQF_SHARED,
                  ^
drivers/input/serio/i8042.c: In function 'i8042_create_kbd_port':
drivers/input/serio/i8042.c:1227:14: error: 'I8042_KBD_IRQ' undeclared (first use in this function)
  port->irq = I8042_KBD_IRQ;
              ^
drivers/input/serio/i8042.c: In function 'i8042_create_aux_port':
drivers/input/serio/i8042.c:1263:14: error: 'I8042_AUX_IRQ' undeclared (first use in this function)
  port->irq = I8042_AUX_IRQ;
              ^
drivers/input/serio/i8042.c: In function 'i8042_free_irqs':
drivers/input/serio/i8042.c:1330:12: error: 'I8042_AUX_IRQ' undeclared (first use in this function)
   free_irq(I8042_AUX_IRQ, i8042_platform_device);
            ^
drivers/input/serio/i8042.c:1332:12: error: 'I8042_KBD_IRQ' undeclared (first use in this function)
   free_irq(I8042_KBD_IRQ, i8042_platform_device);
            ^
drivers/input/serio/i8042.c: In function 'i8042_setup_aux':
drivers/input/serio/i8042.c:1360:22: error: 'I8042_AUX_IRQ' undeclared (first use in this function)
  error = request_irq(I8042_AUX_IRQ, i8042_interrupt, IRQF_SHARED,
                      ^
drivers/input/serio/i8042.c: In function 'i8042_setup_kbd':
drivers/input/serio/i8042.c:1386:22: error: 'I8042_KBD_IRQ' undeclared (first use in this function)
  error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED,
                      ^
scripts/Makefile.build:257: recipe for target 'drivers/input/serio/i8042.o' failed
make[2]: *** [drivers/input/serio/i8042.o] Error 1
scripts/Makefile.build:402: recipe for target 'drivers/input/serio' failed
make[1]: *** [drivers/input/serio] Error 2
Makefile:938: recipe for target 'drivers' failed
make: *** [drivers] Error 2

make: *** Waiting for unfinished jobs....

  CC [M]  fs/udf/balloc.o
  CC [M]  fs/udf/dir.o
  CC [M]  fs/udf/file.o
  LD [M]  fs/ubifs/ubifs.o
  CC [M]  fs/udf/ialloc.o
  CC [M]  fs/ufs/balloc.o
  CC [M]  fs/udf/inode.o
  CC [M]  fs/ufs/cylinder.o
  CC [M]  fs/udf/lowlevel.o
  CC [M]  fs/ufs/dir.o
  CC [M]  fs/udf/namei.o
  CC [M]  fs/ufs/file.o
  CC [M]  fs/ufs/ialloc.o
  CC [M]  fs/udf/partition.o
  CC [M]  fs/ufs/inode.o
  CC [M]  fs/udf/super.o
  CC [M]  fs/ufs/namei.o
  CC [M]  fs/ufs/super.o
  CC [M]  fs/udf/truncate.o
  CC [M]  fs/udf/symlink.o
  CC [M]  fs/udf/directory.o
  CC [M]  fs/ufs/symlink.o
  CC [M]  fs/ufs/truncate.o
  CC [M]  fs/udf/misc.o
  CC [M]  fs/udf/udftime.o
  CC [M]  fs/ufs/util.o
  CC [M]  fs/udf/unicode.o
  LD [M]  fs/ufs/ufs.o
  LD [M]  fs/udf/udf.o
  CC      fs/eventpoll.o
  CC [M]  fs/xfs/xfs_trace.o
  CC [M]  fs/xfs/libxfs/xfs_alloc.o
  CC      fs/anon_inodes.o
  CC [M]  fs/xfs/libxfs/xfs_alloc_btree.o
  CC      fs/signalfd.o
  CC [M]  fs/xfs/libxfs/xfs_attr.o
  CC      fs/timerfd.o
  CC [M]  fs/xfs/libxfs/xfs_attr_leaf.o
  CC      fs/eventfd.o
  CC      fs/aio.o
  CC [M]  fs/xfs/libxfs/xfs_attr_remote.o
  CC      fs/locks.o
  CC [M]  fs/xfs/libxfs/xfs_bmap.o
  CC      fs/binfmt_script.o
  CC      fs/binfmt_elf.o
  CC      fs/mbcache.o
  CC      fs/posix_acl.o
  CC [M]  fs/xfs/libxfs/xfs_bmap_btree.o
  CC [M]  fs/xfs/libxfs/xfs_btree.o
  CC      fs/coredump.o
  CC      fs/drop_caches.o
  CC      fs/fhandle.o
  CC [M]  fs/xfs/libxfs/xfs_da_btree.o
  CC [M]  fs/xfs/libxfs/xfs_da_format.o
  CC      fs/dcookies.o
  CC [M]  fs/binfmt_misc.o
  CC [M]  fs/xfs/libxfs/xfs_dir2.o
  CC [M]  fs/xfs/libxfs/xfs_dir2_block.o
  CC [M]  fs/xfs/libxfs/xfs_dir2_data.o
  CC [M]  fs/xfs/libxfs/xfs_dir2_leaf.o
  CC [M]  fs/xfs/libxfs/xfs_dir2_node.o
  CC [M]  fs/xfs/libxfs/xfs_dir2_sf.o
  CC [M]  fs/xfs/libxfs/xfs_dquot_buf.o
  CC [M]  fs/xfs/libxfs/xfs_ialloc.o
  CC [M]  fs/xfs/libxfs/xfs_ialloc_btree.o
  CC [M]  fs/xfs/libxfs/xfs_inode_fork.o
  CC [M]  fs/xfs/libxfs/xfs_inode_buf.o
  CC [M]  fs/xfs/libxfs/xfs_log_rlimit.o
  CC [M]  fs/xfs/libxfs/xfs_sb.o
  CC [M]  fs/xfs/libxfs/xfs_symlink_remote.o
  CC [M]  fs/xfs/libxfs/xfs_trans_resv.o
  CC [M]  fs/xfs/libxfs/xfs_rtbitmap.o
  CC [M]  fs/xfs/xfs_aops.o
  CC [M]  fs/xfs/xfs_attr_inactive.o
  CC [M]  fs/xfs/xfs_attr_list.o
  CC [M]  fs/xfs/xfs_bit.o
  CC [M]  fs/xfs/xfs_bmap_util.o
  CC [M]  fs/xfs/xfs_buf.o
  CC [M]  fs/xfs/xfs_dir2_readdir.o
  CC [M]  fs/xfs/xfs_discard.o
  CC [M]  fs/xfs/xfs_error.o
  CC [M]  fs/xfs/xfs_export.o
  CC [M]  fs/xfs/xfs_extent_busy.o
  CC [M]  fs/xfs/xfs_file.o
  CC [M]  fs/xfs/xfs_filestream.o
  CC [M]  fs/xfs/xfs_fsops.o
  CC [M]  fs/xfs/xfs_globals.o
  CC [M]  fs/xfs/xfs_icache.o
  CC [M]  fs/xfs/xfs_ioctl.o
  CC [M]  fs/xfs/xfs_iomap.o
  CC [M]  fs/xfs/xfs_iops.o
  CC [M]  fs/xfs/xfs_inode.o
  CC [M]  fs/xfs/xfs_itable.o
  CC [M]  fs/xfs/xfs_message.o
  CC [M]  fs/xfs/xfs_mount.o
  CC [M]  fs/xfs/xfs_mru_cache.o
  CC [M]  fs/xfs/xfs_super.o
  CC [M]  fs/xfs/xfs_symlink.o
  CC [M]  fs/xfs/xfs_sysfs.o
  CC [M]  fs/xfs/xfs_trans.o
  CC [M]  fs/xfs/xfs_xattr.o
  CC [M]  fs/xfs/kmem.o
  CC [M]  fs/xfs/uuid.o
  CC [M]  fs/xfs/xfs_log.o
  CC [M]  fs/xfs/xfs_log_cil.o
  CC [M]  fs/xfs/xfs_buf_item.o
  CC [M]  fs/xfs/xfs_extfree_item.o
  CC [M]  fs/xfs/xfs_icreate_item.o
  CC [M]  fs/xfs/xfs_inode_item.o
  CC [M]  fs/xfs/xfs_log_recover.o
  CC [M]  fs/xfs/xfs_trans_ail.o
  CC [M]  fs/xfs/xfs_trans_buf.o
  CC [M]  fs/xfs/xfs_trans_extfree.o
  CC [M]  fs/xfs/xfs_trans_inode.o
  CC [M]  fs/xfs/xfs_dquot.o
  CC [M]  fs/xfs/xfs_dquot_item.o
  CC [M]  fs/xfs/xfs_trans_dquot.o
  CC [M]  fs/xfs/xfs_qm_syscalls.o
  CC [M]  fs/xfs/xfs_qm_bhv.o
  CC [M]  fs/xfs/xfs_qm.o
  CC [M]  fs/xfs/xfs_quotaops.o
  CC [M]  fs/xfs/xfs_rtalloc.o
  CC [M]  fs/xfs/xfs_acl.o
  CC [M]  fs/xfs/xfs_stats.o
  CC [M]  fs/xfs/xfs_sysctl.o
  LD [M]  fs/xfs/xfs.o
  LD      fs/built-in.o

real    87m39.500s
user    141m52.280s
sys    8m26.612s

[Alexey Charkov]

2017-09-29 19:59 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
> On Thursday, September 28, 2017 at 5:30:06 PM UTC-4, Alexey Charkov wrote:
>>
>>
>> Well, it times out trying to do something to the SD card, so apparently
>> you didn't need sdon-inverted in the first place. Maybe it was hanging
>> somewhere else.
>>
>> I've noticed you're using the 3.13 branch - could you please try 'git
>> checkout origin/testing-alchark' to get to a slightly fresher kernel
>> version? You'll need to reapply the changes you've made though.
>>
>> I think people had random hangs with 3.13 that seemed to magically go away
>> after updating.
>
>
> Hi Alexey,
>
> I checked out your "testing-alchark" branch and compiled it, but I'm
> guessing that it may not have been entirely successful because it did not
> create a new zImage file (compiler out with error messages appears below).
> However, my problem may be in my technique, so let me detail the steps that
> I took on my end.
>
> I did not perform a "make clean" before I started compiling. I thought that
> this might save me some time for modules that were already up-to-date, but
> now I'm not sure. Should I have run a "make clean" first?

It's usually ok to skip the cleaning step unless you've switched
compilers or something of that sort which could make previously
compiled object files not play well with fresh ones.

> I know you mentioned in your above message that I would need to reapply all
> of my changes, which I assumed would also include the i-8042 patch file
> (0001-input-vt8500-Add-support-for-devicetree-to-i8042-dri.patch). Should I
> not have applied this patch?

Just checked the contents of that branch - no i8042 code there, so you
need the patch. It might need some minor modifications though to apply
cleanly, I'll have to check.

> When I initiated "make" against your branch, the process paused
> approximately 300 times to ask me questions about new features. I had no
> idea what to choose at these prompts (because I had no idea what most of
> them meant) so I simply hit the enter key for each one without indicating a
> selection. Could that have caused a problem? I have included some examples
> below.
>
> System V IPC (SYSVIPC) [Y/n/?] y
> POSIX Message Queues (POSIX_MQUEUE) [Y/n/?] y
> Enable process_vm_readv/writev syscalls (CROSS_MEMORY_ATTACH) [Y/n/?] y
> open by fhandle syscalls (FHANDLE) [Y/n/?] y
> uselib syscall (USELIB) [Y/n/?] (NEW)
> Task_based RCU implementation using voluntary context switch (TASKS_RCU)
> [N/y/?] (NEW)
> Include legacy /proc/<pid>/cpuset file (PROC_PID_CPUSET) [Y/n] y
> Simple CPU accounting cgroup subsystem (CGROUP_CPUACCT) [Y/n/?] y
> Memory Resource Controller for Control Groups (MEMCG) [N/y/?] (NEW)
> Memory Resource Controller Swap Extension (MEMCG_SWAP) [N/y/?] (NEW)
> Memory Resource Controller Swap Extension enabled by default
> (MEMCG_SWAP_ENABLED) [Y/n/?] (NEW)
> Memory Resource Controller Kernel Memory accounting (MEMCG_KMEM) [N/y/?]
> (NEW)

These are the new configuration options that appeared between 3.13 and
3.19, for which you didn't have values specified in your .config. So
the build process asked you what you'd like for their values (defaults
are ok)

> You had mentioned in a prior message that I simply needed to initiate the
> "make" command to create both a zImage file and a dtb file. However, I have
> been using the make statements that I found in D. J. Bernstein's
> instructions provided in a prior forum thread
> (https://groups.google.com/forum/#!topic/vt8500-wm8505-linux-kernel/rWjZu4PWmiM),
> which are as follows:
>
> For zImage file: time make -j2 ARCH=arm zImage modules
> CROSS_COMPILE=arm-linux-gnueabihf-
>
> For dtb file: time make ARCH=arm dtbs CROSS_COMPILE=arm-linux-gnueabihf-
>
>
> Could the way that I am using "make" be part of my problem?

It's all right, although a simple make ARCH=arm
CROSS_COMPILE=arm-linux-gnueabihf- would produce the zImage, modules
and dtb in one go. You can also specify CROSS_COMPILE within kernel
config, which would further shorten the required command. -j2 enables
parallel build (two files at a time), which usually speeds up the
process (but not sure that makes a big difference on your Atom
machine).

> By the way, here is the latter portion of my compiler output containing some
> error messages:
>
>
> CC drivers/input/serio/i8042.o
> drivers/input/serio/i8042.c: In function 'i8042_stop':
> drivers/input/serio/i8042.c:417:18: error: 'I8042_AUX_IRQ' undeclared (first
> use in this function)
> synchronize_irq(I8042_AUX_IRQ);
> ^

So here's your problem. The keyboard patch didn't apply cleanly,
leaving the i8042.c file in a broken state. For a starter, try simply
disabling i8042 in kernel configuration and building+booting the
resulting kernel. If that works out, I'll help you out with the patch
(or maybe I'll finally find some time to rebase the whole thing on top
of current master).

Best,
Alexey

[Matt Edwards]

On Friday, September 29, 2017 at 1:18:51 PM UTC-4, Alexey Charkov wrote:

>   CC      drivers/input/serio/i8042.o
> drivers/input/serio/i8042.c: In function 'i8042_stop':
> drivers/input/serio/i8042.c:417:18: error: 'I8042_AUX_IRQ' undeclared (first
> use in this function)
>   synchronize_irq(I8042_AUX_IRQ);
>                   ^

So here's your problem. The keyboard patch didn't apply cleanly,
leaving the i8042.c file in a broken state. For a starter, try simply
disabling i8042 in kernel configuration and building+booting the
resulting kernel. If that works out, I'll help you out with the patch
(or maybe I'll finally find some time to rebase the whole thing on top
of current master).

Best,
Alexey

 

Will do Alexey.  To disable i8042 support in the kernel configuration do I simply comment out the "CONFIG_SERIO_I8042=y" line in my .config file?

[Alexey Charkov]

Yes, that's one way to do it. I usually do "make ARCH=arm menuconfig"
though and browse through the menu (you'll need ncurses installed for
that)

[Matt Edwards]

On Friday, September 29, 2017 at 2:30:53 PM UTC-4, Alexey Charkov wrote:

Yes, that's one way to do it. I usually do "make ARCH=arm menuconfig"
though and browse through the menu (you'll need ncurses installed for
that)

Hi Alexey,

I actually tried it both ways:

1. Commenting out the "CONFIG_SERIO_I8042=y" line in my .config file.
2. Using "make ARCH=arm menuconfig", unselecting "Device Drivers->Input device support->Keyboards" and then unselecting "Device Drivers->Input device support->Hardware I/O ports->i8042 PC Keyboard controller".  However when I did this it just flipped the "i8042 PC Keyboard controller" setting to "M"; it does not allow me to completely unset it.

Using method 1, when I started the compilation process, it uncommented the "# CONFIG_SERIO_I8042=y" line in .config and attempted to compile the i8042 code again (which of course failed).  I did notice that the first few lines of output from the compiler are as follows:

scripts/kconfig/conf --silentoldconfig Kconfig
#
# configuration written to .config
#

which leads me to believe that some Kconfig process is overwriting the .config file and reinstating the "CONFIG_SERIO_I8042=y" directive.  Is there possibly a i8042 file associated with this Kconfig process that I need to modify instead?

Using method 2, it still attempted to compile the i8042 code as a module, which also failed due to the i8042 patch problem.

[Alexey Charkov]

2017-09-29 21:53 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
> On Friday, September 29, 2017 at 2:30:53 PM UTC-4, Alexey Charkov wrote:
>>
>>
>> Yes, that's one way to do it. I usually do "make ARCH=arm menuconfig"
>> though and browse through the menu (you'll need ncurses installed for
>> that)
>
>
> Hi Alexey,
>
> I actually tried it both ways:
>
> Commenting out the "CONFIG_SERIO_I8042=y" line in my .config file.
> Using "make ARCH=arm menuconfig", unselecting "Device Drivers->Input device
> support->Keyboards" and then unselecting "Device Drivers->Input device
> support->Hardware I/O ports->i8042 PC Keyboard controller". However when I
> did this it just flipped the "i8042 PC Keyboard controller" setting to "M";
> it does not allow me to completely unset it.

So there is something in your configuration that depends on this.
Might be easier to just revert this whole part of the kernel tree to
pre-patched state.

Try doing "git checkout -- drivers/input/" from the top of the kernel tree.

[Matt Edwards]

On Friday, September 29, 2017 at 3:15:32 PM UTC-4, Alexey Charkov wrote:

So there is something in your configuration that depends on this.
Might be easier to just revert this whole part of the kernel tree to
pre-patched state.

Try doing "git checkout -- drivers/input/" from the top of the kernel tree.

Okay, I performed the checkout function, but it did not change my results.  It is still failing while trying to compile the i8042 code.  I went and commented out the "CONFIG_SERIO_I8042=y" line in my .config file again and recompiled but the process uncommented the line again and the compilation failed at the same place.  Is there any chance that something in your branch might be causing a conflict?  I'm just not sure why this issue won't seem to go away.  :P

[Alexey Charkov]

Were there any errors during checkout? You may want to try "git
checkout -f -- drivers/input/" (with a force switch)

[Matt Edwards]

On Friday, September 29, 2017 at 3:44:24 PM UTC-4, Alexey Charkov wrote:

Were there any errors during checkout? You may want to try "git
checkout -f -- drivers/input/" (with a force switch)

I did not receive any error messages during my initial checkout, but I reran it anyway using the -f (force) option.  However, it is still failing on the i8042 code at compile time. :(

[Alexey Charkov]

Right... There's also part of the patch that touches arch code. So
"git checkout -f -- arch/" too :-)

[Matt Edwards]

On Friday, September 29, 2017 at 5:02:00 PM UTC-4, Alexey Charkov wrote:

Right... There's also part of the patch that touches arch code. So
"git checkout -f -- arch/" too :-)

Thanks Alexey, that did the trick.  I was able to successfully compile the code again after executing the additional checkout command.

When I boot-up my device now, I no longer appear to be stuck in a loop, at least as far as I can tell from the screen output.  However, I only get so far before the process seems to pause (I have included a screen shot below).  I let the machine sit and found that after approximately 10 minutes of showing the below output with the cursor flashing in the lower left-hand corner, the screen went totally black and did not respond to any input from a USB keyboard or mouse.  Does the screen eventually timeout, or does the screen blacking out actually tell us something?

[Alexey Charkov]

Interesting. It seems to see your SD card, but not the root filesystem on it. What's your partition layout on the SD card, and do you have support for your partitioning scheme enabled in kernel?

The screen going black is just the backlight timing out.

[Matt Edwards]

On Saturday, September 30, 2017 at 11:35:23 AM UTC-4, Alexey Charkov wrote:

Interesting. It seems to see your SD card, but not the root filesystem on it. What's your partition layout on the SD card, and do you have support for your partitioning scheme enabled in kernel?

The screen going black is just the backlight timing out.

Oh okay, gotcha.  I have included a screen shot of my SD card partitions below.  I have a 64MB FAT16 partition for u-boot, a 28.78GB ext4 partition for my filesystem, and a 1.0GB swap partition.

How can I check if I have enabled support for my partitioning scheme in the kernel?

Thanks Alexey!

[Alexey Charkov]

Mind posting your .config as an attachment?

[Matt Edwards]

On Saturday, September 30, 2017 at 12:28:07 PM UTC-4, Alexey Charkov wrote:

Mind posting your .config as an attachment?

 Sure thing Alexey; you should find it attached.

[Alexey Charkov]

You've got:
CONFIG_MMC_BLOCK=m

Try setting it to "y" instead.

[Matt Edwards]

On Saturday, September 30, 2017 at 4:17:16 PM UTC-4, Alexey Charkov wrote:

You've got:
CONFIG_MMC_BLOCK=m

Try setting it to "y" instead.

Thanks Alexey.  That seemed to get me a little further.  I've included another screen shot.  It looks like I'm still getting stuck at the "random: nonblocking pool is initialized" step though.  I also noticed that the screen backlight doesn't seem to be timing out anymore.  Its been stuck on the last step for a half hour or so and the screen still hasn't timed out.

Is the kernel panic section something to be concerned about?  Also, I noticed some other SD card related options in my .config file.  Since I'm using an SDHC card, do I need to set any of the CONFIG_MMC_SDHCI* options to something different?  They are currently set as follows:

CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PLTFM=m
# CONFIG_MMC_SDHCI_OF_ARASAN is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set

[Alexey Charkov]

On Sun, 1 Oct 2017 at 02:21, Matt Edwards <oasisc...@gmail.com> wrote:

On Saturday, September 30, 2017 at 4:17:16 PM UTC-4, Alexey Charkov wrote:

You've got:
CONFIG_MMC_BLOCK=m

Try setting it to "y" instead.

Thanks Alexey.  That seemed to get me a little further.  I've included another screen shot.  It looks like I'm still getting stuck at the "random: nonblocking pool is initialized" step though.  I also noticed that the screen backlight doesn't seem to be timing out anymore.  Its been stuck on the last step for a half hour or so and the screen still hasn't timed out.

"Attempting to kill init" is the problem. It has mounted your root filesystem, but when it tried to execute init it didn't find it or it exited without starting the system userland.

What distro/version did you use for the root filesystem? Also, did you include any override for init= in your kernel command line as part of your scriptcmd?

Default if unspecified is /sbin/init, which is exactly what you need most of the time. To boot with systemd you may need to specify the full path to it. For debugging or emergencies it is sometimes helpful to boot with init=/bin/sh (gets you straight into shell without asking for passwords or starting any services or giving you job control - so no Ctrl+C functionality but helpful if you forgot to set user passwords or filesystem mountpoints).

Is the kernel panic section something to be concerned about?  Also, I noticed some other SD card related options in my .config file.  Since I'm using an SDHC card, do I need to set any of the CONFIG_MMC_SDHCI* options to something different?  They are currently set as follows:

CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PLTFM=m
# CONFIG_MMC_SDHCI_OF_ARASAN is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set

These are for SDHCI, which is the common SD host controller. You don't have it on wm8505, so no use building those parts at all.

Cheers,

Alexey

[Alexey Charkov]

Matt, if your other issues resolve themselves, please try this version
of the i8042 patch on top of a clean version of testing-alchark. It
should apply cleanly, please let me know if it works - then I can push
it to the repo.

It already includes the required device tree node for vt8500 and wm8505.

Best,
Alexey

[Matt Edwards]

On Sunday, October 1, 2017 at 3:35:11 AM UTC-4, Alexey Charkov wrote:

"Attempting to kill init" is the problem. It has mounted your root filesystem, but when it tried to execute init it didn't find it or it exited without starting the system userland.

What distro/version did you use for the root filesystem? Also, did you include any override for init= in your kernel command line as part of your scriptcmd?

Default if unspecified is /sbin/init, which is exactly what you need most of the time. To boot with systemd you may need to specify the full path to it. For debugging or emergencies it is sometimes helpful to boot with init=/bin/sh (gets you straight into shell without asking for passwords or starting any services or giving you job control - so no Ctrl+C functionality but helpful if you forgot to set user passwords or filesystem mountpoints).

Hi Alexey,

I created my filesystem following the instructions that D. J. Bernstein included in the forum thread that I referenced earlier.  His instructions are as follows:

     aptitude install debootstrap debian-archive-keyring debian-ports-archive-keyring
     MOUNT=/root/sdcard
     mkdir -p $MOUNT
     SDCARD=sdb
     mount /dev/${SDCARD}p2 $MOUNT
     packages=openssh-server
     packages=strace,usbutils,$packages
     packages=sudo,less,screen,locales,$packages
     packages=vim,ntp,git,subversion,$packages
     packages=build-essential,gdb,clang,m4,libssl-dev,$packages
     time debootstrap --arch armhf --foreign --verbose --include $packages \
     wheezy $MOUNT http://ftp.us.debian.org/debian
     # 10 minutes on my laptop
     time make ARCH=arm INSTALL_MOD_PATH=$MOUNT modules_install
     # 2 minutes
     time umount $MOUNT
     # 8 minutes

I am not seeing an init directive in my scriptcmd file.  I'm actually using a scriptcmd file that I found on an old SD card; I have attached it for your reference.  I could not get D. J.'s scriptcmd file to boot my card.  When I do a cat on the script file this is what I get:

    �Tg � �� script image_lcdinit
    fatload mmc 0 0 /script/uImage
    setenv bootargs root=/dev/mmcblk0p2 rw rootwait
    bootm 0

And when I run the "file" command on this file I get:

    scriptcmd: u-boot legacy uImage, script image, Linux/ARM, Script File (Not compressed), 103 bytes, Wed Jan 11 14:36:04 2012, Load Address: 0x00000001, Entry Point: 0x00000000, Header CRC: 0x08653F47, Data CRC: 0x8601C9EB

I noticed how the above output is indicating a load address of 0x00000001 and an entry point of 0x00000000, but aren't they both supposed to be set to 0x00008000?  Could that be the reason why the boot process is hanging?

Thanks Alexey!

[Alexey Charkov]

Here's the culprit: --arch armhf will produce a system built for ARMv7
with hardware floating point support (VFPv3d16), while you are trying
to run it on ARMv5 with no floating point unit. Need to use --arch
armel on any WM8750 and older (WM8750 does include a floating point
unit, but it's ARMv6 and VFPv2 similar to first Raspberry Pi's, thus
still unable to run upstream armhf).

You may also want to replace "wheezy" with e.g. "stable", as wheezy is
two versions obsolete already.

Cheers,
Alexey

[Matt Edwards]

On Sunday, October 1, 2017 at 2:26:31 PM UTC-4, Alexey Charkov wrote:

Here's the culprit: --arch armhf will produce a system built for ARMv7
with hardware floating point support (VFPv3d16), while you are trying
to run it on ARMv5 with no floating point unit. Need to use --arch
armel on any WM8750 and older (WM8750 does include a floating point
unit, but it's ARMv6 and VFPv2 similar to first Raspberry Pi's, thus
still unable to run upstream armhf).

You may also want to replace "wheezy" with e.g. "stable", as wheezy is
two versions obsolete already.

Cheers,
Alexey

Oh okay gotcha.  How about the fact that I am compiling the kernel using:

time make -j2 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-

Is the fact that I am using "arm-linux-gnueabihf-" in my CROSS_COMPILE directive a problem as well?  I wasn't sure if the "hf" in "arm-linux-gnueabihf-" means the same thing as the "hf" in "armhf".

[Alexey Charkov]

It does mean the same, but for the kernel it makes no difference, as
it doesn't use any floating point instructions internally, and the
build process ensures correct target instruction sets are selected
regardless of what the compiler has as its default. So no problem
there.

[Matt Edwards]

On Sunday, October 1, 2017 at 2:26:31 PM UTC-4, Alexey Charkov wrote:

Here's the culprit: --arch armhf will produce a system built for ARMv7
with hardware floating point support (VFPv3d16), while you are trying
to run it on ARMv5 with no floating point unit. Need to use --arch
armel on any WM8750 and older (WM8750 does include a floating point
unit, but it's ARMv6 and VFPv2 similar to first Raspberry Pi's, thus
still unable to run upstream armhf).

You may also want to replace "wheezy" with e.g. "stable", as wheezy is
two versions obsolete already.

Cheers,
Alexey

Hi Alexey,

I modified my debootstrap command string from:

    time debootstrap --arch armhf --foreign --verbose --include $packages wheezy $MOUNT http://ftp.us.debian.org/debian

to:

    time debootstrap --arch armel --foreign --verbose --include $packages stable $MOUNT http://ftp.us.debian.org/debian

and recreated the filesystem on my SD card.

It looks like I got a little further; there were a couple of new output messages anyway.  I have included a screen shot below.  I plugged in a USB keyboard to see if I could type anything at the "#" prompt, but it did not work.  What do you think?

[Alexey Charkov]

You'll need USB keyboard support to be compiled in for this to work. Adjust these in your .config (change "m" to "y"):

#

# USB HID support

#

CONFIG_USB_HID=m

CONFIG_HID_PID=y

CONFIG_USB_HIDDEV=y

#

# USB HID Boot Protocol drivers

#

CONFIG_USB_KBD=m

CONFIG_USB_MOUSE=m 

FWIW, I've now rebased and updated testing-alchark branch on Github, and also included the i8042 patch this time. It now builds using recent GCC (tested yesterday on my APC Rock - seems to be ok).

Cheers,

Alexey

[Matt Edwards]

On Monday, October 2, 2017 at 2:13:01 AM UTC-4, Alexey Charkov wrote:

You'll need USB keyboard support to be compiled in for this to work. Adjust these in your .config (change "m" to "y"):

#

# USB HID support

#

CONFIG_USB_HID=m

CONFIG_HID_PID=y

CONFIG_USB_HIDDEV=y

#

# USB HID Boot Protocol drivers

#

CONFIG_USB_KBD=m

CONFIG_USB_MOUSE=m 

FWIW, I've now rebased and updated testing-alchark branch on Github, and also included the i8042 patch this time. It now builds using recent GCC (tested yesterday on my APC Rock - seems to be ok).

Cheers,

Alexey

Hi Alexey,

I changed my CONFIG_USB_HID, CONFIG_USB_KBD, and CONFIG_USB_MOUSE configuration settings from "m" to "y" and recompiled everything, but it ultimately didn't make any difference at boot time.  When I was presented with the "#" prompt my device did not appear to accept any input from my USB keyboard, not visibly anyway.  I disconnected my keyboard and rebooted so as not to clutter the screen output with USB keyboard-related messages.  An updated screen shot appears below.  Does the "/bin/sh: 0: can't access tty; job control turned off" message offer any clue as to why my installation is bailing out early now?  I assume that it's bailing out early anyway; I've certainly never had a linux machine that could boot up in 2.7 seconds.  :P

[Alexey Charkov]

2017-10-02 12:58 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
> updated screen shot appears below. Does the "/bin/sh: 0: can't access tty;
> job control turned off" message offer any clue as to why my installation is
> bailing out early now? I assume that it's bailing out early anyway; I've
> certainly never had a linux machine that could boot up in 2.7 seconds. :P

Makes me wonder if you actually have init=/bin/sh somewhere - are you
sure you are using the scriptcmd you've posted and there's no other
with different contents that could actually get used?

Another possibility is that you are booting into some emergency mode
(e.g. due to unfinished configuration of root fs). Hard to tell
without looking around - mind posting your now-current .config to give
an idea what might be wrong with your USB keyboard? Please also try
the fresh kernel version with i8042 added so that you could get the
internal keyboard to work.

Cheers,
Alexey

[Matt Edwards]

On Monday, October 2, 2017 at 6:29:43 AM UTC-4, Alexey Charkov wrote:

Makes me wonder if you actually have init=/bin/sh somewhere - are you
sure you are using the scriptcmd you've posted and there's no other
with different contents that could actually get used?

Another possibility is that you are booting into some emergency mode
(e.g. due to unfinished configuration of root fs). Hard to tell
without looking around - mind posting your now-current .config to give
an idea what might be wrong with your USB keyboard? Please also try
the fresh kernel version with i8042 added so that you could get the
internal keyboard to work.

Cheers,
Alexey

Hi Alexey,

I've double-checked my SD card and the u-boot partition simply has a script directory containing the scriptcmd file and uImage file.  Does that sound right?

I have attached my latest .config file for your review.  I just looked at it and found the one parameter (CONFIG_USB_HID) that I changed from "m" to "y", but the other two parameters that I changed (CONFIG_USB_KBD and CONFIG_USB_MOUSE) are no longer in the file.  Do you know what might have caused them to be removed?

In order to compile against the fresh kernel version with i8042 support added, do I just perform a "git checkout origin/testing-alchark" again, or (since I already performed a checkout of that branch several days ago) is there a way to just update the branch on my end?

Thanks Alexey!

Matt

[Alexey Charkov]

2017-10-02 18:08 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
> On Monday, October 2, 2017 at 6:29:43 AM UTC-4, Alexey Charkov wrote:
>>
>>
>> Makes me wonder if you actually have init=/bin/sh somewhere - are you
>> sure you are using the scriptcmd you've posted and there's no other
>> with different contents that could actually get used?
>>
>> Another possibility is that you are booting into some emergency mode
>> (e.g. due to unfinished configuration of root fs). Hard to tell
>> without looking around - mind posting your now-current .config to give
>> an idea what might be wrong with your USB keyboard? Please also try
>> the fresh kernel version with i8042 added so that you could get the
>> internal keyboard to work.
>>
>> Cheers,
>> Alexey
>
>
> Hi Alexey,
>
> I've double-checked my SD card and the u-boot partition simply has a script
> directory containing the scriptcmd file and uImage file. Does that sound
> right?

Yepp, sounds right. Then it must be some emergency mode indeed.

> I have attached my latest .config file for your review. I just looked at it
> and found the one parameter (CONFIG_USB_HID) that I changed from "m" to "y",
> but the other two parameters that I changed (CONFIG_USB_KBD and
> CONFIG_USB_MOUSE) are no longer in the file. Do you know what might have
> caused them to be removed?

Those two options provide a limited mode 'boot protocol' support for
USB keyboards and mice. Once you've selected HID support, they must
have been removed altogether.

Sounds like you'll also need the following to be build-in (=y):
CONFIG_HID_GENERIC=m

By the way, it sounds like you're editing .config by hand - have you
tried 'make menuconfig'? It provides an interactive menu with helpful
descriptions for all options and is the usual way to configure the
kernel. The menu hierarchy is a bit daunting the first couple of
decades you use it, but it's still more convenient than hand-editing
;-)

> In order to compile against the fresh kernel version with i8042 support
> added, do I just perform a "git checkout origin/testing-alchark" again, or
> (since I already performed a checkout of that branch several days ago) is
> there a way to just update the branch on my end?

1. Make note of any local changes you've made to the tree (git diff is helpful)
2. Revert to a clean tree state with 'git checkout -f'
3. Update with 'git pull -f'
4. Check which of your local changes you still need to apply, if any
(probably just the display contrast value)

[Alexey Charkov]

2017-10-02 18:36 GMT+03:00 Alexey Charkov <alc...@gmail.com>:
> By the way, it sounds like you're editing .config by hand - have you
> tried 'make menuconfig'? It provides an interactive menu with helpful
> descriptions for all options and is the usual way to configure the
> kernel. The menu hierarchy is a bit daunting the first couple of
> decades you use it, but it's still more convenient than hand-editing
> ;-)

Minor addition: should be 'make ARCH=arm menuconfig' - otherwise it
won't let you configure ARM options on a non-ARM machine.

[Matt Edwards]

On Monday, October 2, 2017 at 11:36:16 AM UTC-4, Alexey Charkov wrote:

Those two options provide a limited mode 'boot protocol' support for
USB keyboards and mice. Once you've selected HID support, they must
have been removed altogether.

Sounds like you'll also need the following to be build-in (=y):
CONFIG_HID_GENERIC=m

By the way, it sounds like you're editing .config by hand - have you
tried 'make menuconfig'? It provides an interactive menu with helpful
descriptions for all options and is the usual way to configure the
kernel. The menu hierarchy is a bit daunting the first couple of
decades you use it, but it's still more convenient than hand-editing
;-)

I used "make ARCH=arm menuconfig" to create my initial configuration file following all of the steps described in "Build the source" from the Wiki.  However, I have been modifying the configuration file manually each time that you have asked me to change something.  Editing the file directly just seems so much easier than trying to find things in the menu hierarchy.  However, as I have already discovered, editing the file directly sometimes leads to settings disappearing on me at compile time.  :P

> In order to compile against the fresh kernel version with i8042 support
> added, do I just perform a "git checkout origin/testing-alchark" again, or
> (since I already performed a checkout of that branch several days ago) is
> there a way to just update the branch on my end?

1. Make note of any local changes you've made to the tree (git diff is helpful)
2. Revert to a clean tree state with 'git checkout -f'
3. Update with 'git pull -f'
4. Check which of your local changes you still need to apply, if any
(probably just the display contrast value)

Okay, I followed your above steps (thank you very much for listing them out BTW), and I received the following output:

bluefish@Redfish ~/Development/Arm-Linux/linux-vtwm $ git checkout -f
bluefish@Redfish ~/Development/Arm-Linux/linux-vtwm $ git branch
* (HEAD detached at origin/testing-alchark)
  testing
bluefish@Redfish ~/Development/Arm-Linux/linux-vtwm $ git pull -f
remote: Counting objects: 1356755, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 1356755 (delta 364539), reused 364540 (delta 364539), pack-reused 992206
Receiving objects: 100% (1356755/1356755), 269.80 MiB | 4.75 MiB/s, done.
Resolving deltas: 100% (1144789/1144789), completed with 33384 local objects.
From git://github.com/linux-wmt/linux-vtwm
 + 4b7ecfc...e225119 testing-alchark -> origin/testing-alchark  (forced update)
You are not currently on a branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

    git pull <remote> <branch>

bluefish@Redfish ~/Development/Arm-Linux/linux-vtwm $

Do I need to add something to my "git pull -f" statement?

[Alexey Charkov]

Looks like another 'git checkout testing-alchark' should help. You
somehow ended up in a detached HEAD state prior to pulling, so git
didn't update the tree (only pulled the objects from the repo).

If it keeps being stubborn, you can also do 'git branch -D
testing-alchark' to delete the local branch, then 'git checkout -t
origin/testing-alchark' to recreate it.

[Matt Edwards]

On Monday, October 2, 2017 at 12:46:24 PM UTC-4, Alexey Charkov wrote:

Looks like another 'git checkout testing-alchark' should help. You
somehow ended up in a detached HEAD state prior to pulling, so git
didn't update the tree (only pulled the objects from the repo).

If it keeps being stubborn, you can also do 'git branch -D
testing-alchark' to delete the local branch, then 'git checkout -t
origin/testing-alchark' to recreate it.

Hi Alexey,

It looks like running "git checkout testing-alchark" did the trick.  I also took the opportunity to switch back to gcc-5.4 and gcc-5.4-arm-linux-gnueabihf.  However, I am back to failing at compile time.  Here is the problem area:

  HOSTCC  scripts/recordmcount
  CHK     include/generated/timeconst.h
  UPD     include/generated/timeconst.h
  CHK     include/generated/bounds.h
  UPD     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  UPD     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  HOSTCC  scripts/sortextable
  HOSTCC  scripts/asn1_compiler
  HOSTCC  scripts/sign-file
scripts/sign-file.c:25:30: fatal error: openssl/opensslv.h: No such file or directory
compilation terminated.
scripts/Makefile.host:101: recipe for target 'scripts/sign-file' failed
make[1]: *** [scripts/sign-file] Error 1
make[1]: *** Waiting for unfinished jobs....
Makefile:561: recipe for target 'scripts' failed
make: *** [scripts] Error 2

real    7m44.695s
user    1m19.560s
sys    0m6.772s

Do you think that I should switch back to the old compiler(s), or do you think that this might be related to a recent change in your branch?

[Alexey Charkov]

On Mon, 2 Oct 2017 at 22:19, Matt Edwards <oasisc...@gmail.com> wrote:

On Monday, October 2, 2017 at 12:46:24 PM UTC-4, Alexey Charkov wrote:

Looks like another 'git checkout testing-alchark' should help. You
somehow ended up in a detached HEAD state prior to pulling, so git
didn't update the tree (only pulled the objects from the repo).

If it keeps being stubborn, you can also do 'git branch -D
testing-alchark' to delete the local branch, then 'git checkout -t
origin/testing-alchark' to recreate it.

Hi Alexey,

It looks like running "git checkout testing-alchark" did the trick.  I also took the opportunity to switch back to gcc-5.4 and gcc-5.4-arm-linux-gnueabihf.  However, I am back to failing at compile time.  Here is the problem area:

  HOSTCC  scripts/recordmcount
  CHK     include/generated/timeconst.h
  UPD     include/generated/timeconst.h
  CHK     include/generated/bounds.h
  UPD     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  UPD     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  HOSTCC  scripts/sortextable
  HOSTCC  scripts/asn1_compiler
  HOSTCC  scripts/sign-file
scripts/sign-file.c:25:30: fatal error: openssl/opensslv.h: No such file or directory
compilation terminated.

Do you actually need cryptographic code signing for your kernel? Frankly, I don't think so :) Just disable all of that stuff and you should be all set.

Alternatively, install openssl dev package, which should provide your missing header.

Cheers,

Alexey

[Matt Edwards]

On Monday, October 2, 2017 at 3:46:32 PM UTC-4, Alexey Charkov wrote:

Do you actually need cryptographic code signing for your kernel? Frankly, I don't think so :) Just disable all of that stuff and you should be all set.

Alternatively, install openssl dev package, which should provide your missing header.

Cheers,

Alexey

Hi Alexey,

Since I have no idea what cryptographic code signing actually is, I'll defer to your judgment and agree that I do not need it.  :)

I used "make ARCH=arm menuconfig" and found a "Crypographic API" option on the main menu.  Unfortunately it does not allow me to simply disable the option outright and when I select the "Cryptographic API" menu it provides me with 81 features and submenus that I can configure.  Do you know if there is a way to just disable cryptographic support outright, or do I need to just go through and set as many options to "n" as I can?  Some options, specifically the ones designated with a {M}, do not let me change them at all.  :(

[Alexey Charkov]

On Mon, 2 Oct 2017 at 23:34, Matt Edwards <oasisc...@gmail.com> wrote:

On Monday, October 2, 2017 at 3:46:32 PM UTC-4, Alexey Charkov wrote:

Do you actually need cryptographic code signing for your kernel? Frankly, I don't think so :) Just disable all of that stuff and you should be all set.

Alternatively, install openssl dev package, which should provide your missing header.

Cheers,

Alexey

Hi Alexey,

Since I have no idea what cryptographic code signing actually is, I'll defer to your judgment and agree that I do not need it.  :)

If you run a "secure boot" system where a trusted boot loader can cryptographically verify that the kernel hasn't been tampered with (or rather that it is signed by a trusted authority and hasn't been modified after signing), then you ideally need all privileged code to be similarly signed, including foremost your kernel modules (otherwise the whole trust in the kernel is moot).

With our machines here we're not even close to even trusting our boot loaders, let alone those boot loaders verifying trust in kernel code :) So no, you don't need that functionality.

I used "make ARCH=arm menuconfig" and found a "Crypographic API" option on the main menu.  Unfortunately it does not allow me to simply disable the option outright and when I select the "Cryptographic API" menu it provides me with 81 features and submenus that I can configure.  Do you know if there is a way to just disable cryptographic support outright, or do I need to just go through and set as many options to "n" as I can?  Some options, specifically the ones designated with a {M}, do not let me change them at all.  :(

That's a different thing: cryptographic API is what the kernel uses for its own purposes and partially exports to userspace for various hashing and encryption functions. It's usually ok to disable what it allows you to disable though.

The config option that causes your trouble though is

CONFIG_MODULE_SIG

(support for cryptographically signed modules). Just comment it out.

Best,

Alexey

[Matt Edwards]

On Monday, October 2, 2017 at 5:08:11 PM UTC-4, Alexey Charkov wrote:

The config option that causes your trouble though is

CONFIG_MODULE_SIG

(support for cryptographically signed modules). Just comment it out.

Best,

Alexey

Hi Alexey.

Okay, I commented out the CONFIG_MODULE_SIG directive in my .config file, and that cleared up my compiler error.  However, I'm now receiving another compiler error, which consists of the following:

  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     scripts/mod/devicetable-offsets.h
  HOSTCC  scripts/extract-cert
scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
compilation terminated.
scripts/Makefile.host:101: recipe for target 'scripts/extract-cert' failed
make[1]: *** [scripts/extract-cert] Error 1

Makefile:561: recipe for target 'scripts' failed
make: *** [scripts] Error 2

make: *** Waiting for unfinished jobs....

real    1m14.868s
user    0m34.080s
sys    0m4.372s

Any idea which directive I need to comment out for this one?

[Alexey Charkov]

CONFIG_SYSTEM_TRUSTED_KEYRING

N.B. I looked these up in scripts/Makefile :)

[Matt Edwards]

On Tuesday, October 3, 2017 at 2:56:35 AM UTC-4, Alexey Charkov wrote:

>Any idea which directive I need to comment out for this one?

CONFIG_SYSTEM_TRUSTED_KEYRING

N.B. I looked these up in scripts/Makefile :)

Hi Alexey,

Thank you for explaining to me how to determine which environment variable corresponds to which C program.  Now I won't have to ask you each time I run into another compilation failure.

Having said that, I've actually run into another compilation error, but this time with the i8042 keyboard code.  Here is the output that I received from the compiler:

  CC [M]  drivers/input/evbug.o
  AR      drivers/input/input-core.o
  AR      drivers/input/built-in.o
  AR      drivers/input/gameport/built-in.o
  CC [M]  drivers/input/gameport/gameport.o
  CC [M]  fs/xfs/xfs_globals.o
  CC [M]  drivers/input/gameport/lightning.o
  CC [M]  fs/xfs/xfs_icache.o
  CC [M]  drivers/input/gameport/ns558.o
  CC      drivers/input/serio/serio.o
  CC      drivers/input/serio/i8042.o
  CC [M]  fs/xfs/xfs_ioctl.o
drivers/input/serio/i8042.c: In function ‘i8042_stop’:
drivers/input/serio/i8042.c:467:18: error: ‘I8042_AUX_IRQ’ undeclared (first use in this function)
  synchronize_irq(I8042_AUX_IRQ);
                  ^
drivers/input/serio/i8042.c:467:18: note: each undeclared identifier is reported only once for each function it appears in
drivers/input/serio/i8042.c:468:18: error: ‘I8042_KBD_IRQ’ undeclared (first use in this function)
  synchronize_irq(I8042_KBD_IRQ);
                  ^
drivers/input/serio/i8042.c: In function ‘i8042_check_aux’:
drivers/input/serio/i8042.c:865:18: error: ‘I8042_AUX_IRQ’ undeclared (first use in this function)
  if (request_irq(I8042_AUX_IRQ, i8042_aux_test_irq, IRQF_SHARED,
                  ^
drivers/input/serio/i8042.c: In function ‘i8042_create_kbd_port’:
drivers/input/serio/i8042.c:1330:14: error: ‘I8042_KBD_IRQ’ undeclared (first use in this function)
  port->irq = I8042_KBD_IRQ;
              ^
drivers/input/serio/i8042.c: In function ‘i8042_create_aux_port’:
drivers/input/serio/i8042.c:1367:14: error: ‘I8042_AUX_IRQ’ undeclared (first use in this function)
  port->irq = I8042_AUX_IRQ;
              ^
drivers/input/serio/i8042.c: In function ‘i8042_free_irqs’:
drivers/input/serio/i8042.c:1422:12: error: ‘I8042_AUX_IRQ’ undeclared (first use in this function)
   free_irq(I8042_AUX_IRQ, i8042_platform_device);
            ^
drivers/input/serio/i8042.c:1424:12: error: ‘I8042_KBD_IRQ’ undeclared (first use in this function)
   free_irq(I8042_KBD_IRQ, i8042_platform_device);
            ^
drivers/input/serio/i8042.c: In function ‘i8042_setup_aux’:
drivers/input/serio/i8042.c:1452:22: error: ‘I8042_AUX_IRQ’ undeclared (first use in this function)
  error = request_irq(I8042_AUX_IRQ, i8042_interrupt, IRQF_SHARED,
                      ^
drivers/input/serio/i8042.c: In function ‘i8042_setup_kbd’:
drivers/input/serio/i8042.c:1478:22: error: ‘I8042_KBD_IRQ’ undeclared (first use in this function)
  error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED,
                      ^
scripts/Makefile.build:311: recipe for target 'drivers/input/serio/i8042.o' failed
make[2]: *** [drivers/input/serio/i8042.o] Error 1
scripts/Makefile.build:570: recipe for target 'drivers/input/serio' failed
make[1]: *** [drivers/input/serio] Error 2
Makefile:1019: recipe for target 'drivers' failed
make: *** [drivers] Error 2

make: *** Waiting for unfinished jobs....

Is there something that I could have missed when I checked out your branch?

[Alexey Charkov]

Is CONFIG_SERIO_I8042_DT enabled in your config?

This whole thing is one of the reasons why our i8042 patch won't be
upstreamed in its current form and needs to be revised...

[Matt Edwards]

On Tuesday, October 3, 2017 at 11:34:07 AM UTC-4, Alexey Charkov wrote:

Is CONFIG_SERIO_I8042_DT enabled in your config?

This whole thing is one of the reasons why our i8042 patch won't be
upstreamed in its current form and needs to be revised...

No, I do not have CONFIG_SERIO_I8042_DT enabled in my configuration.  Is this something that I need to set?  My i8042-specific settings are as follows:

bluefish@Redfish ~/Development/Arm-Linux/linux-vtwm $ grep I8042 .config
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_I8042_DT is not set

[Alexey Charkov]

2017-10-03 19:32 GMT+03:00 Matt Edwards <oasisc...@gmail.com>:
> On Tuesday, October 3, 2017 at 11:34:07 AM UTC-4, Alexey Charkov wrote:
>>
>>
>> Is CONFIG_SERIO_I8042_DT enabled in your config?
>>
>> This whole thing is one of the reasons why our i8042 patch won't be
>> upstreamed in its current form and needs to be revised...
>
>
> No, I do not have CONFIG_SERIO_I8042_DT enabled in my configuration. Is
> this something that I need to set?

Yes, otherwise it falls back to i8042-io implementation and expects
IRQ numbers to be statically defined in architecture-specific
includes, which is not our case (and which won't work anyway). The
patch needs to be refactored to avoid that, but it's a somewhat
non-trivial task.

[Matt Edwards]

On Tuesday, October 3, 2017 at 12:45:22 PM UTC-4, Alexey Charkov wrote:

> No, I do not have CONFIG_SERIO_I8042_DT enabled in my configuration.  Is
> this something that I need to set?

Yes, otherwise it falls back to i8042-io implementation and expects
IRQ numbers to be statically defined in architecture-specific
includes, which is not our case (and which won't work anyway). The
patch needs to be refactored to avoid that, but it's a somewhat
non-trivial task.

Thanks Alexey, that did the trick.  I was able to compile cleanly after enabling CONFIG_SERIO_I8042_DT.  Total compilation time was right at about 6 hours.  :P

I've attached a screen shot of my latest boot-up screen.  The built-in keyboard did not work at the "#" prompt, but I don't know if it was supposed to or not.  I did notice what looked like i8042 error messages in the output (see below).

[Alexey Charkov]

Frankly, I’m running out of ideas. There seems to be an issue with your root filesystem failing to init properly, and another separate issue with your keyboards not working. Both are tricky to debug non-interactively.

Do you happen to have a serial console connection to your device? That would at least give us the full kernel output and a shell to probe stuff.

[ExcellProj]

среда, 4 октября 2017 г., 5:34:54 UTC+3 пользователь Matt Edwards написал:

Hi. My work image kernel 3.16.35 with working i8042 keyboard

[Alexey Charkov]

> Hi. My work image kernel 3.16.35 with working i8042 keyboard

Thanks a lot! Would be great to understand the differences vs. what is
now in testing-alchark, so that I could fix up any omissions. Did you
use Tony's 'testing' branch as the starting point?

I've just had a look at the device tree source in Tony's version.
Looks like there shouldn't be any "mux-ports = <2>;" which doesn't
seem to be used in the code anyway, but instead "init-reset;" which
might actually be relevant to the issue Matt is facing.

Matt, would you mind changing that line in wm8505.dtsi and letting us
know the result?

Cheers,
Alexey

[ExcellProj]

среда, 4 октября 2017 г., 11:23:09 UTC+3 пользователь Alexey Charkov написал:

Вы говорите по-русски?

[Alexey Charkov]

>> >> I've attached a screen shot of my latest boot-up screen. The built-in
>> >> keyboard did not work at the "#" prompt, but I don't know if it was supposed
>> >> to or not. I did notice what looked like i8042 error messages in the output
>> >> (see below).
>> >>
>> > Hi. My work image kernel 3.16.35 with working i8042 keyboard
>>
>> Thanks a lot! Would be great to understand the differences vs. what is
>> now in testing-alchark, so that I could fix up any omissions. Did you
>> use Tony's 'testing' branch as the starting point?
>

> Вы говорите по-русски?

Говорю :) Можно на ты. Единственное - потом для других читающих
желательно всё-таки перевести на английский.

@group: pardon the brief exchange in Russian - we will replay in
English too for everyone's benefit.

Cheers,
Alexey

[Matt Edwards]

On Wednesday, October 4, 2017 at 4:23:09 AM UTC-4, Alexey Charkov wrote:

> Hi. My work image kernel 3.16.35 with working i8042 keyboard

Thanks a lot! Would be great to understand the differences vs. what is
now in testing-alchark, so that I could fix up any omissions. Did you
use Tony's 'testing' branch as the starting point?

I've just had a look at the device tree source in Tony's version.
Looks like there shouldn't be any "mux-ports = <2>;" which doesn't
seem to be used in the code anyway, but instead "init-reset;" which
might actually be relevant to the issue Matt is facing.

Matt, would you mind changing that line in wm8505.dtsi and letting us
know the result?

Cheers,
Alexey

Hi Alexey.  Sure thing.  So are you saying that I should change the following code block in wm8505.dtsi from:

        keyboard@d8008800 {
            compatible = "intel,8042";
            reg = <0xD8008800 0x100>;
            interrupts = <23 4>;
            command-reg = <0x04>;
            status-reg = <0x04>;
            data-reg = <0x00>;
            mux-ports = <2>;
        };

to this:

        keyboard@d8008800 {
            compatible = "intel,8042";
            reg = <0xD8008800 0x100>;
            interrupts = <23 4>;
            command-reg = <0x04>;
            status-reg = <0x04>;
            data-reg = <0x00>;
            init-reset;
        };

So in other words, replace "mux-ports = <2>;" with "init-reset;"?

Thank you for clarifying this for me Alexey!

Matt

[Alexey Charkov]

Right :-)

[Matt Edwards]

Hey guys,

I've been pretty quiet this afternoon because I've been making progress.  Alexey, your previous suggestion in which I replaced "mux-ports = <2>;" with "init-reset;" in wm8505.dtsi totally fixed my keyboard issue.  When I reached the "#" prompt at boot-up I was able to use the built-in keyboard and continue on with the steps from D. J. Bernstein's step-by-step instructions.  I now have an SD card booting up to the linux login prompt and I am able to login with a user name and password that I configured.  I cannot believe that it is finally working.  :)  I'm sure that it might seem like a trivial thing to others, but I have been trying to get to this point off-and-on for the past couple of years.  I still have some smaller issues that I will probably ask you about (for instance I am getting an error message when I try to use the "sudo" command), but I'll save that for tomorrow.  For now I am just ecstatic that it is working.  Thank you so much Alexey for all of the time and effort that you invested in getting me to this point; I cannot thank you enough.  And thank you to ExcellProj for providing his uImage file that led to your final suggestion.

Have a great evening guys!

Matt

[Matt Edwards]

On Wednesday, October 4, 2017 at 4:32:33 PM UTC-4, Matt Edwards wrote:

Hey guys,

I've been pretty quiet this afternoon because I've been making progress.  Alexey, your previous suggestion in which I replaced "mux-ports = <2>;" with "init-reset;" in wm8505.dtsi totally fixed my keyboard issue.  When I reached the "#" prompt at boot-up I was able to use the built-in keyboard and continue on with the steps from D. J. Bernstein's step-by-step instructions.  I now have an SD card booting up to the linux login prompt and I am able to login with a user name and password that I configured.  I cannot believe that it is finally working.  :)  I'm sure that it might seem like a trivial thing to others, but I have been trying to get to this point off-and-on for the past couple of years.  I still have some smaller issues that I will probably ask you about (for instance I am getting an error message when I try to use the "sudo" command), but I'll save that for tomorrow.  For now I am just ecstatic that it is working.  Thank you so much Alexey for all of the time and effort that you invested in getting me to this point; I cannot thank you enough.  And thank you to ExcellProj for providing his uImage file that led to your final suggestion.

Have a great evening guys!

Matt

Hey Alexey,

Thank you again for all of your help; I never would have gotten this far without it.  :)

I am now trying trying to clean up my last few remaining issues.  One issue that I have encountered is with my /etc/apt/sources.list file.  The instructions that D. J. provided said to add the following sources to the file:

     deb http://http.debian.net/debian/ wheezy main contrib non-free
     deb-src http://http.debian.net/debian/ wheezy main contrib non-free
     deb http://security.debian.org/debian-security wheezy/updates main
     deb-src http://security.debian.org/debian-security wheezy/updates main
     deb http://http.debian.net/debian/ wheezy-backports main contrib non-free

I remembered how you had recommended that I substitute "stable" in place of "wheezy" in previous steps, so I did the same thing here to produce the following sources:

     deb http://http.debian.net/debian/ stable main contrib non-free
     deb-src http://http.debian.net/debian/ stable main contrib non-free
     deb http://security.debian.org/debian-security stable/updates main
     deb-src http://security.debian.org/debian-security stable/updates main
     deb http://http.debian.net/debian/ stable-backports main contrib non-free

However, when I execute a "sudo apt-get update" I receive several errors (see screen shot below).  Should I have used something slightly different for my sources list?

[Adrien Destugues]

On Wed, Oct 04, 2017 at 10:13:14PM -0700, Matt Edwards wrote:
> Hey Alexey,

>
> I remembered how you had recommended that I substitute "stable" in place of
> "wheezy" in previous steps, so I did the same thing here to produce the
> following sources:
>
> deb http://http.debian.net/debian/ stable main contrib non-free
> deb-src http://http.debian.net/debian/ stable main contrib non-free

> deb http://http.debian.net/debian/ stable-backports main contrib non-free

all of these should be debian.*org*, not debian.*net*.

> deb http://security.debian.org/debian-security stable/updates main
> deb-src http://security.debian.org/debian-security stable/updates main

It seems the naming for the repositories changed a little and there is
no "security" team anymore. I think the most similar thing would be the
"updates" repository.

Some documentation here:
https://wiki.debian.org/SourcesList

--
Adrien.

[ExcellProj]

Open /etc/resolv.conf and add string
nameserver 8.8.8.8

P.S. On this device, I use Debian 8

четверг, 5 октября 2017 г., 8:13:14 UTC+3 пользователь Matt Edwards написал:

[Alexey Charkov]

On Thu, 5 Oct 2017 at 10:29, ExcellProj <excel...@gmail.com> wrote:

Open /etc/resolv.conf and add string
nameserver 8.8.8.8

You may also want to add the following block to wm8505.dtsi to enable wired Ethernet:

		eth0@d8004000 {
			compatible = "via,velocity-vt6110";
			reg = <0xd8004000 0x400>;
			interrupts = <10>;
			no-eeprom;
		};

(also thanks to ExcellProj for reminding me of this one in a private message!)

Please also check that you have proper IP address and routes assigned for your network.

And congratulations on getting the machine up and running, great job! Would be nice if you could add a wiki entry on Github one your remaining issues are sorted out :)

[Matt Edwards]

On Thursday, October 5, 2017 at 1:25:56 AM UTC-4, Adrien Destugues wrote:

all of these should be debian.*org*, not debian.*net*.

>      deb http://security.debian.org/debian-security stable/updates main
>      deb-src http://security.debian.org/debian-security stable/updates main

It seems the naming for the repositories changed a little and there is
no "security" team anymore. I think the most similar thing would be the
"updates" repository.

Some documentation here:
https://wiki.debian.org/SourcesList

--
Adrien.

Hi Adrien,

Thank you for the heads up.  I have modified my sources list based on information that I read in your link (https://wiki.debian.org/SourcesList).

[Matt Edwards]

On Thursday, October 5, 2017 at 3:29:45 AM UTC-4, ExcellProj wrote:

Open /etc/resolv.conf and add string
nameserver 8.8.8.8

P.S. On this device, I use Debian 8

Hi ExcellProj,

I noticed where /etc/resolv.conf already contains the following nameserver entry:

    nameserver 127.0.1.1

Do I just replace the 127.0.1.1 entry with the new 8.8.8.8 entry, or do I leave them both in the file?  I'm guessing that may be a dumb question, but I just want to be sure.  :P

[Alexey Charkov]

Unless you are running your own DNS server on that little machine, I’d guess you need to replace 127.0.0.1 with 8.8.8.8

Do pings work? Like “ping 8.8.8.8”? I guess you might be missing network connectivity altogether.

What does “ifconfig -a” show?

[Matt Edwards]

On Thursday, October 5, 2017 at 7:12:05 AM UTC-4, Alexey Charkov wrote:

On Thu, 5 Oct 2017 at 10:29, ExcellProj <excel...@gmail.com> wrote:

Open /etc/resolv.conf and add string
nameserver 8.8.8.8

You may also want to add the following block to wm8505.dtsi to enable wired Ethernet:

		eth0@d8004000 {
			compatible = "via,velocity-vt6110";
			reg = <0xd8004000 0x400>;
			interrupts = <10>;
			no-eeprom;
		};

Hi Alexey,

I apologize for following-up yesterday, but I was traveling yesterday and was unable to spend any time working on the machine.

I did follow you advice today and added the above code block to wm8505.dtsi, but it did not appear to enable my ethernet port (see below screen shot).  I did boot up my device in Android and confirmed that the ethernet port is not broken (it worked in Android anyway).  Shouldn't I be able use the built-in wifi on my machine?  Are there any instructions here on the forum for setting up wifi?

(also thanks to ExcellProj for reminding me of this one in a private message!)

Please also check that you have proper IP address and routes assigned for your network.

I tried to confirm that I had not been assigned a valid network address, but apparently "ifconfig" has net yet been loaded on my machine.  :(

And congratulations on getting the machine up and running, great job! Would be nice if you could add a wiki entry on Github one your remaining issues are sorted out :)

Thanks Alexey; I'm really thrilled to have gotten this far.  If I can get networking functions working then I'll really have something.  :)

I'll be glad to write a comprehensive how-to document once everything is in good shape.

[Matt Edwards]

On Friday, October 6, 2017 at 4:14:38 PM UTC-4, Alexey Charkov wrote:

Hi ExcellProj,

I noticed where /etc/resolv.conf already contains the following nameserver entry:

    nameserver 127.0.1.1

Do I just replace the 127.0.1.1 entry with the new 8.8.8.8 entry, or do I leave them both in the file?  I'm guessing that may be a dumb question, but I just want to be sure.  :P

Unless you are running your own DNS server on that little machine, I’d guess you need to replace 127.0.0.1 with 8.8.8.8

Do pings work? Like “ping 8.8.8.8”? I guess you might be missing network connectivity altogether.

What does “ifconfig -a” show?

Hi Alexey,

Okay, that's what I thought (regarding replacing 127.0.1.1 with 8.8.8.8), but I wanted to be sure.

As you'll notice from my previous posting, pings do not work.  I was wondering if that might be something else that I'll need to change to get ethernet working?

[Alexey Charkov]

On Fri, 6 Oct 2017 at 23:18, Matt Edwards <oasisc...@gmail.com> wrote:

On Thursday, October 5, 2017 at 7:12:05 AM UTC-4, Alexey Charkov wrote:

On Thu, 5 Oct 2017 at 10:29, ExcellProj <excel...@gmail.com> wrote:

Open /etc/resolv.conf and add string
nameserver 8.8.8.8

You may also want to add the following block to wm8505.dtsi to enable wired Ethernet:

		eth0@d8004000 {
			compatible = "via,velocity-vt6110";
			reg = <0xd8004000 0x400>;
			interrupts = <10>;
			no-eeprom;
		};

Hi Alexey,

I apologize for following-up yesterday, but I was traveling yesterday and was unable to spend any time working on the machine.

I did follow you advice today and added the above code block to wm8505.dtsi, but it did not appear to enable my ethernet port (see below screen shot).  I did boot up my device in Android and confirmed that the ethernet port is not broken (it worked in Android anyway).  Shouldn't I be able use the built-in wifi on my machine?  Are there any instructions here on the forum for setting up wifi?

(also thanks to ExcellProj for reminding me of this one in a private message!)

Please also check that you have proper IP address and routes assigned for your network.

I tried to confirm that I had not been assigned a valid network address, but apparently "ifconfig" has net yet been loaded on my machine.  :(

I think there must be some ifconfig equivalent- have you tried “ip” or “busybox ifconfig” or something of that sort?

Any kernel messages about the Velocity driver?  Did you have it enabled during kernel build?

You can use internal wifi after toggling one of the GPIO pins to enable its power, but it would be of no use if you can’t assign an address to it.

[ExcellProj]

Hi Matt,

Show please ip link show eth0

For using wifi you should have enabled /sys/gpio support during kernel configuration
If you did this, then to start wifi,
configure the wlan0 network interface in /etc/network/interfaces

allow-hotplug wlan0
iface wlan0 inet dhcp

 use in comand line:

echo "2" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio2/direction
echo "1" > /sys/class/gpio/gpio2/value

Next ip link set wlan0 up

For connect to your wifi AP use wpa_supplicant  (Download to USB flash drive and transfer to your device and install dpkg -i wpasupplicant*.deb)

Configuration and start https://unix.stackexchange.com/questions/283722/how-to-connect-to-wifi-from-command-line


пятница, 6 октября 2017 г., 23:18:31 UTC+3 пользователь Matt Edwards написал:

[Matt Edwards]

On Friday, October 6, 2017 at 5:26:28 PM UTC-4, Alexey Charkov wrote:

I think there must be some ifconfig equivalent- have you tried “ip” or “busybox ifconfig” or something of that sort?

Any kernel messages about the Velocity driver?  Did you have it enabled during kernel build?

You can use internal wifi after toggling one of the GPIO pins to enable its power, but it would be of no use if you can’t assign an address to it.

Hi Alexey,

I was just checking around in the kernel configuration utility and found an entry for "VIA devices" under the "Device Drivers->Network device support->Ethernet driver support" menu as follows:

    [*]    VIA devices

    < >      VIA Rhine support

    <M>      VIA Velocity support

Does that look correct to you, or do I need to change the "M" for VIA Velocity support to a "*"?

[Matt Edwards]

On Friday, October 6, 2017 at 11:14:18 PM UTC-4, ExcellProj wrote:

 

Show please ip link show eth0


Hi ExcellProj,

Please see the below screen shot for the output from "ip link show eth0".

For using wifi you should have enabled /sys/gpio support during kernel configuration
If you did this, then to start wifi,
configure the wlan0 network interface in /etc/network/interfaces

allow-hotplug wlan0
iface wlan0 inet dhcp

 use in comand line:

echo "2" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio2/direction
echo "1" > /sys/class/gpio/gpio2/value

Next ip link set wlan0 up


I followed the above instructions, but when I execute "ip link set wlan0 up" I receive an error message stating:  cannot find device "wlan0" (see below screen shot).  Can you think of anything that I may have missed?

[ExcellProj]

Hi Matt,
You configure the configuration of network interfaces in /etc/network/interfaces or /etc/network/interfaces.d?

Please show:  cat /etc/network/interfaces

I see that eth0 work. You need connect the Ethernet cable and configuration eth0:

nano /etc/network/interfaces and add line:

auto eth0
iface eth0 inet dhcp

Save and (you use debian 7?) /etc/init.d/networking restart
Show ip link show eth0 or ifconfig
ping google.com

понедельник, 9 октября 2017 г., 21:42:35 UTC+3 пользователь Matt Edwards написал:

[Matt Edwards]

On Tuesday, October 10, 2017 at 3:44:36 AM UTC-4, ExcellProj wrote:

Hi Matt,
You configure the configuration of network interfaces in /etc/network/interfaces or /etc/network/interfaces.d?

Please show:  cat /etc/network/interfaces

I see that eth0 work. You need connect the Ethernet cable and configuration eth0:

nano /etc/network/interfaces and add line:

auto eth0
iface eth0 inet dhcp

Save and (you use debian 7?) /etc/init.d/networking restart
Show ip link show eth0 or ifconfig
ping google.com

Hi ExcellProj,

I configured my network interfaces in /etc/network/interfaces.  By the way, your above instructions did the trick.  My wired ethernet connection is now working like a charm.  A screen shot of my /etc/network/interfaces file is as follows:

I'm still not sure about my wifi though (I've attached another screen shot below).  When I execute the GPIO commands from your instructions my wifi card is discovered (it appears to be a USB device?), but when I execute the "ip link set wlan0 up" command I still receive an error message of: Cannot find device "wlan0".  When I execute "ip link show" I do see a new entry for "wlx002243108688", but for some reason it is not naming it "wlan0".  I next tried executing "ip link set wlx002243108688 up" and received the output shown in the 3rd screen shot below.  Based on the screen output I went back into the kernel configuration utility to check my Ralink driver support settings - they are shown in the 4th screen shot below.  Does anything look incorrect with my Ralink settings?

[Alexey Charkov]

2017-10-10 22:55 GMT+05:00 Matt Edwards <oasisc...@gmail.com>:
> I'm still not sure about my wifi though (I've attached another screen shot
> below). When I execute the GPIO commands from your instructions my wifi
> card is discovered (it appears to be a USB device?), but when I execute the
> "ip link set wlan0 up" command I still receive an error message of: Cannot
> find device "wlan0". When I execute "ip link show" I do see a new entry for
> "wlx002243108688", but for some reason it is not naming it "wlan0". I next
> tried executing "ip link set wlx002243108688 up" and received the output
> shown in the 3rd screen shot below. Based on the screen output I went back
> into the kernel configuration utility to check my Ralink driver support
> settings - they are shown in the 4th screen shot below. Does anything look
> incorrect with my Ralink settings?

As the error message says, it can't find the firmware file for your
wireless adapter. Try installing the 'linux-firmware' package which
contains firmware files for most of the stuff. The rest looks alright.

[ExcellProj]

I completely forgot about the firmware ...

вторник, 10 октября 2017 г., 21:12:24 UTC+3 пользователь Alexey Charkov написал:

[ExcellProj]

Hi,
Need http://ftp.us.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-ralink_0.36+wheezy.1_all.deb thx Alexey.

Ethernet work?

вторник, 10 октября 2017 г., 20:55:12 UTC+3 пользователь Matt Edwards написал:

[Alexey Charkov]

2017-10-10 23:32 GMT+05:00 ExcellProj <excel...@gmail.com>:
> Hi,
> Need
> http://ftp.us.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-ralink_0.36+wheezy.1_all.deb
> thx Alexey.

Or you can simply grab this file:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rt2870.bin

and put it under /lib/firmware

[Matt Edwards]

On Tuesday, October 10, 2017 at 2:32:53 PM UTC-4, ExcellProj wrote:

Hi,
Need http://ftp.us.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-ralink_0.36+wheezy.1_all.deb thx Alexey.

Ethernet work?

Hi ExcellProj,

Thank you for providing the firmware file for my Ralink wifi adapter, that did the trick.  I have now gotten both wired (ethernet) and wifi network connections working.

I may be pushing my luck a bit, but do you guys know of a window manager, such as XFCE, that may actually function on these low spec devices?  I don't necessarily want the window manager to load on startup, but I would like the option to invoke it when needed.  Have you guys had any success using a window manager with these devices?

[Adrien Destugues]

11 octobre 2017 19:28 "Matt Edwards" <oasisc...@gmail.com> a écrit:

> I may be pushing my luck a bit, but do you guys know of a window manager, such as XFCE, that may
> actually function on these low spec devices? I don't necessarily want the window manager to load on
> startup, but I would like the option to invoke it when needed. Have you guys had any success using
> a window manager with these devices?

I usually go with IceWM. It is reasonably easy to use (Windows-95 like interface with start menu) and light on memory/CPU.
The default themes are quite ugly, I got used to http://triq.net/theme/icewm-oktan-theme which behaves well even in 256-color displays (I used to run this on standalone X terminals when I was in school).

--
Adrien.

[ExcellProj]

Hi Matt,

It's nice to hear that you have succeeded.

In theory, this is possible, provided that there is a SWAP. In the Internet there are successful settings of the window manager LXDE

Quote from the official site: "Although it could run on the computers with RAM as small as 256MiB, We recommend getting a computer with RAM of 1GiB or above for applications running on it, such as web browser, video player and office suite."

Installation

Let us know about your experiments =)

среда, 11 октября 2017 г., 20:28:33 UTC+3 пользователь Matt Edwards написал:

[Matt Edwards]

On Wednesday, October 11, 2017 at 2:24:57 PM UTC-4, Adrien Destugues wrote:

I usually go with IceWM. It is reasonably easy to use (Windows-95 like interface with start menu) and light on memory/CPU.
The default themes are quite ugly, I got used to http://triq.net/theme/icewm-oktan-theme which behaves well even in 256-color displays (I used to run this on standalone X terminals when I was in school).

--
Adrien.

Hi Adrien,

Thank you for the suggestion.  After a little Google research I decided to follow your lead and give IceWM a try.  My netbook only has 128MB of RAM, so I definitely need to use something that is light on resources.  I'll let you know how it goes.

[Matt Edwards]

On Wednesday, October 11, 2017 at 2:25:38 PM UTC-4, ExcellProj wrote:

Hi Matt,

It's nice to hear that you have succeeded.

In theory, this is possible, provided that there is a SWAP. In the Internet there are successful settings of the window manager LXDE

Quote from the official site: "Although it could run on the computers with RAM as small as 256MiB, We recommend getting a computer with RAM of 1GiB or above for applications running on it, such as web browser, video player and office suite."

Installation

Let us know about your experiments =)

Hi ExcellProj,

Thank you for your words of support.  Without the help of you and Alexey, I never could have gotten this far.  Alexey was extremely patient with me and took time out of his schedule several times a day over a 2+ week period to explain to me what I was doing wrong.  I definitely cannot thank him enough.  :D

As far as a window manager is concerned, I did install the icewm package on my device, but then realized that it wouldn't work because I didn't have xorg installed.  I then installed xorg but my machine froze towards the end of the installation and I had to perform a hard shutdown.  Upon restarting my device it booted up to a login screen but froze again and I could not proceed any further.  I'm going to play with it a bit to see if I can figure out why it is freezing.  Would you guys happen to know why installing xorg would cause my machine to freeze?

[Matt Edwards]

On Thursday, October 12, 2017 at 8:36:47 AM UTC-4, Matt Edwards wrote:

As far as a window manager is concerned, I did install the icewm package on my device, but then realized that it wouldn't work because I didn't have xorg installed.  I then installed xorg but my machine froze towards the end of the installation and I had to perform a hard shutdown.  Upon restarting my device it booted up to a login screen but froze again and I could not proceed any further.  I'm going to play with it a bit to see if I can figure out why it is freezing.  Would you guys happen to know why installing xorg would cause my machine to freeze?

Okay, a quick correction; my machine is not freezing, the built-in keyboard has actually stopped working.  I plugged a USB keyboard into my machine and the USB keyboard started working just fine.  To refine my previous question, would you guys happen to know why installing xorg would cause my built-in keyboard to stop working?

[ExcellProj]

Hi Matt,
It interesting
Debian Wiki say:

Configure X

To reconfigure keyboard settings in Squeeze (and later) run as root in a terminal:

# dpkg-reconfigure keyboard-configuration 

Maybe this will help you


четверг, 12 октября 2017 г., 15:43:50 UTC+3 пользователь Matt Edwards написал:

[Matt Edwards]

On Thursday, October 12, 2017 at 10:11:02 AM UTC-4, ExcellProj wrote:

Hi Matt,
It interesting
Debian Wiki say:

Configure X

To reconfigure keyboard settings in Squeeze (and later) run as root in a terminal:

# dpkg-reconfigure keyboard-configuration 

Maybe this will help you

Hi ExcellProj,

I will definitely give this a try.  FYI, the strangest thing happened just a few minutes ago.  I was trying to install Dropbox on my machine (only to discover that Dropbox does not support Arm architectures) when suddenly the built-in keyboard started working again.  I have included a screen shot below with the screen message that I received when the keyboard came back to life (it's the last line on the screen that printed at 10261.800000).