How can I tell Debian on a Raspberry Pi 4B (4GB) which kernel image to load at boot time?

[Rick Thomas]

I have a set of three Raspberry-Pi 4B (4GB) machines.  They all are running the 
Debian for Rpi from [1].

They all were happily running the kernel from package 
"linux-image-6.1.0-9-arm64". But, recently, a passing "apt upgrade" installed 
"linux-image-6.1.0-10-arm64" on them.  On all three of them, the "needrestart" 
command pointed out that there was a new kernel and I needed to reboot.  On two 
of them, I rebooted and it came up running the new kernel (6.1.0-10).  On the 
third, however, reboot came up running the old kernel (6.1.0-9) ?!?  The only 
difference that I can think of between the pair where the upgrade worked and 
the one where the upgrade didn't work, is that the singleton had been running 
Bullseye and was upgraded in-place to Bookworm, while the other two had been 
initially installed with Bookworm.  So maybe there was something left-over from 
Bullseye that caused it?

So, the bottom line for me is: How can I now tell the boot scripts to use 
(6.1.0-10) instead of (6.1.0-9)  And what do I have to do to make sure this 
doesn't happen again the next time there's a kernel upgrade?

[1] https://raspi.debian.net/tested-images/

Thanks for any clues you can give me!
Rick

[SOLVED} Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

[Rick Thomas]

Turns out that the PiHut has a tutorial webpage for just this problem!


https://thepihut.com/blogs/raspberry-pi-tutorials/17209332-adding-a-real-time-clock-to-your-raspberry-pi

Thanks for all the help!
Rick

On Tue, Apr 18, 2023, at 11:06 PM, Rick Thomas wrote:
> Thanks very much, Pabs!  I will follow up on those links and hopefully 
> get a better understanding of what is going on and why.  Perhaps the 
> next time someone has a question like mine, I'll be able to be as 
> helpful to them as the folks here have been to me!
>
> Rick
>
> On Tue, Apr 18, 2023, at 4:57 PM, Paul Wise wrote:
>> On Mon, 2023-04-17 at 22:21 -0700, Rick Thomas wrote:
>>
>>> What would have been even greater is if the error messages include
>>> references to some documentation that explained the problem and gave
>>> some clues to the larger context in which the problem arose.
>>
>> The messages I sent that patch adding are for very simple issues;
>> "/proc not mounted", "/sys not mounted" and "i2c-dev not loaded" and
>> since they all have very simple solutions, I just added the commands
>> to fix them instead of pointers to documentation about each error.
>>
>> Probably the i2c manual pages should get some links to the Linux kernel
>> documentation and wiki for I2C. I'm unlikely to work on that though,
>> hopefully someone else is willing to do that.
>>
>>> For example, I'd like to know why it chose bus3 rather than one of
>>> the other busses (0,1,2,4)?
>>
>> I expect that depends on the bus driver code for your device,
>> those do not seem to document their ordering though and it
>> looks like your particular i2c bus driver has no documentation.
>>
>> https://www.kernel.org/doc/html/latest/i2c/busses/index.html
>>
>>> I'd also like to know what the various modules do and what kinds of
>>> parameters there are to influence the detailed behavior?
>>
>> Looks like the devices are defined by DeviceTree, ACPI, board files,
>> dynamically by drivers for other devices, hardware probing or sysfs:
>>
>> https://www.kernel.org/doc/html/latest/i2c/instantiating-devices.html
>>
>>> And where is the documentation for the magic writing into /sys ?
>>
>> Seems to be here:
>>
>> https://www.kernel.org/doc/html/latest/i2c/instantiating-devices.html#method-4-instantiate-from-user-space
>> https://www.kernel.org/doc/html/latest/i2c/i2c-sysfs.html
>>
>> These may also be useful:
>>
>> https://www.kernel.org/doc/html/latest/i2c/
>> https://archive.kernel.org/oldwiki/i2c.wiki.kernel.org/
>>
>> PS: I am subscribed, no need to CC me, please respect Reply-To.
>>
>> -- 
>> bye,
>> pabs
>>
>> https://wiki.debian.org/PaulWise
>>
>> Attachments:
>> * signature.asc

Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

[Rick Thomas]

Thanks very much, Pabs!  I will follow up on those links and hopefully get a 
better understanding of what is going on and why.  Perhaps the next time 
someone has a question like mine, I'll be able to be as helpful to them as the 
folks here have been to me!

Rick

On Tue, Apr 18, 2023, at 4:57 PM, Paul Wise wrote:
> On Mon, 2023-04-17 at 22:21 -0700, Rick Thomas wrote:
>
>> What would have been even greater is if the error messages include
>> references to some documentation that explained the problem and gave
>> some clues to the larger context in which the problem arose.
>
> The messages I sent that patch adding are for very simple issues;
> "/proc not mounted", "/sys not mounted" and "i2c-dev not loaded" and
> since they all have very simple solutions, I just added the commands
> to fix them instead of pointers to documentation about each error.
>
> Probably the i2c manual pages should get some links to the Linux kernel
> documentation and wiki for I2C. I'm unlikely to work on that though,
> hopefully someone else is willing to do that.
>
>> For example, I'd like to know why it chose bus3 rather than one of
>> the other busses (0,1,2,4)?
>
> I expect that depends on the bus driver code for your device,
> those do not seem to document their ordering though and it
> looks like your particular i2c bus driver has no documentation.
>
> https://www.kernel.org/doc/html/latest/i2c/busses/index.html
>
>> I'd also like to know what the various modules do and what kinds of
>> parameters there are to influence the detailed behavior?
>
> Looks like the devices are defined by DeviceTree, ACPI, board files,
> dynamically by drivers for other devices, hardware probing or sysfs:
>
> https://www.kernel.org/doc/html/latest/i2c/instantiating-devices.html
>
>> And where is the documentation for the magic writing into /sys ?
>
> Seems to be here:
>
> https://www.kernel.org/doc/html/latest/i2c/instantiating-devices.html#method-4-instantiate-from-user-space
> https://www.kernel.org/doc/html/latest/i2c/i2c-sysfs.html
>
> These may also be useful:
>
> https://www.kernel.org/doc/html/latest/i2c/
> https://archive.kernel.org/oldwiki/i2c.wiki.kernel.org/
>
> PS: I am subscribed, no need to CC me, please respect Reply-To.
>
> -- 
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
> Attachments:
> * signature.asc

Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

[Rick Thomas]

On Mon, Apr 17, 2023, at 7:55 PM, Paul Wise wrote:
> On Mon, 2023-04-17 at 13:39 +0300, Reco wrote:
>> On Mon, Apr 17, 2023 at 02:48:44AM -0700, Rick Thomas wrote:
>> > Sadly,   when I do:
>> >     i2cdetect -l
>> > I get nothing back.  Leading me to conclude that there are no busses 
>> > available.
>> 
>> "modprobe i2c-dev" should fix that.
>
> This seems like a usability issue, so I have sent a patch that
> adds a bunch of error messages in situations of silent failure:
>
> https://lore.kernel.org/linux-i2c/20230418023248.250685-1-pa...@bonedaddy.net/T/

That would have been great while I was trying to track down the solution to 
this problem.
What would have been even greater is if the error messages include references 
to some documentation that explained the problem and gave some clues to the 
larger context in which the problem arose.

I'm still hoping that someone here can point me to documentation that can give 
me answers to questions like these:  For example, I'd like to know why it chose 
bus3 rather than one of the other busses (0,1,2,4)?  I'd also like to know what 
the various modules do and what kinds of parameters there are to influence the 
detailed behavior?  And where is the documentation for the magic writing into 
/sys ?

Big Thanks! to all who have contributed to this discussion.
Rick

Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

[Rick Thomas]

That helps some...

root@pi:~# i2cdetect -l
i2c-3   i2c bcm2835 (i2c@7e804000)  I2C 
adapter
i2c-1   i2c Broadcom STB :  I2C 
adapter
i2c-2   i2c bcm2835 (i2c@7e205000)  I2C 
adapter
i2c-0   i2c Broadcom STB :  I2C 
adapter

and:
root@pi:~# i2cdetect -y 3
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:   -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

All other busses (0 1 and 2 as arguments to i2cdetect give no devices)

So, if I change "i2c-1" to "i2c-3" in the "echo > /sys/class ..."  I find that 
the hwclock command now works!

Now all I have to do is get all that into a systemd service file so it is done 
at boot time.

It's late now.  I'll try that tomorrow!

Thanks very much to all who contributed!
Rick

PS:  Anybody who can explain why it has to be bus 3 -- and how I could have 
predicted that -- will get a hundred Internet guru-points!

On Mon, Apr 17, 2023, at 3:39 AM, Reco wrote:
> Hi.
>
> On Mon, Apr 17, 2023 at 02:48:44AM -0700, Rick Thomas wrote:
>> Sadly,   when I do:
>> i2cdetect -l
>> I get nothing back.  Leading me to conclude that there are no busses 
>> available.
>
> "modprobe i2c-dev" should fix that.
>
> Reco

Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

[Rick Thomas]

Sadly,   when I do:
i2cdetect -l
I get nothing back.  Leading me to conclude that there are no busses available.

FWIW, when I do:
/sbin/hwclock -vr
I get:
hwclock from util-linux 2.36.1
System Time: 1681724077.614748
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

Also FWIW, when I do:
ls -l /dev/i2c*
I get:
ls: cannot access '/dev/i2c*': No such file or directory

Further confirming that there are no available busses.

Is it possible that I need to modprobe a different (or additional) module than 
"i2c_bcm2835"?

Thanks!
Rick

PS:  I'm still wondering if there is some kind of documentation of these 
modules and what they do that would give me a bit of background for this 
project.


On Mon, Apr 17, 2023, at 1:10 AM, Reco wrote:
> Hi.
>
> On Sun, Apr 16, 2023 at 06:41:53PM -0700, Rick Thomas wrote:
>> I found this in journalctl :
>> Apr 16 18:23:33 pi kernel: rtc-ds1307: probe of 1-0068 failed with error 
>> -121
>> Apr 16 18:23:33 pi kernel: i2c i2c-1: new_device: Instantiated device 
>> ds1307 at 0x68
>> 
>> Is rtc_ds1307 the wrong module for my DS3231 rtc hardware?
>
> No, because ds1307 kernel module should work with DS3231.
> But the address of the device (0x68) on I2C bus could be different,
> or the device is actually connected to another I2C bus (i.e. - not 1st).
>
> Consider running i2cdetect to clarify things.
>
> Reco

Re: Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

[Rick Thomas]

Thanks for your response, Georg!

Is there somewhere that these modules are documented that I can read-up for a 
more detailed understanding?

As an experiment, I tried running the following  (It didn't work, but maybe you 
can suggest a modification that will.  I'm probably not fully understanding 
something!):
modprobe i2c_bcm2835 &&
modprobe rtc_ds1307 &&
sleep 1 &&
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device &&
/sbin/hwclock -r
This is what I got when I tried it:
hwclock: Cannot access the Hardware Clock via any known method.

and when I tried:
i2cdetect -y 1
I got"
Error: Could not open file `/dev/i2c-1' or `/dev/i2c/1': No such file or 
directory

I found this in journalctl :
Apr 16 18:23:33 pi kernel: rtc-ds1307: probe of 1-0068 failed with error 
-121
Apr 16 18:23:33 pi kernel: i2c i2c-1: new_device: Instantiated device 
ds1307 at 0x68

Is rtc_ds1307 the wrong module for my DS3231 rtc hardware?

Thanks!
Rick

=
On Sun, Apr 16, 2023, at 2:17 AM, Georg Gast wrote:
> Am Sun, 16 Apr 2023 10:01:08 +0200
> schrieb Diederik de Haas :
>
>> On Sunday, 16 April 2023 04:47:37 CEST Rick Thomas wrote:
>> > I've got a Raspberry Pi 4B (4GB) with a DS3231 RTC module.  I can
>> > make the combo work with Ubuntu and RaspberryPI-OS.  I'd like to
>> > try it with the plain-vanilla Debian from
>> > <https://raspi.debian.net/tested-images/> but I can't find
>> > instructions for activating the I2C and RTC hardware in that OS.  
>> 
>> Documentation/devicetree/bindings/rtc/rtc-ds1307.yaml in the kernel
>> source describes how one could use it ('compatible = "maxim,ds3231"'
>> for DS3231). I think you should make a DeviceTree Overlay, but I
>> don't know how to do that.
>
> I got this working with that systemd unit on a Rpi3 but should also
> work on a RPi4. Maybe you need to adjust the modprobe sequence. I guess
> the 2708 is 2835 on the Pi4.
>
> cat /etc/systemd/system/hwclock-pi.service
> [Unit]
> Description=HWClock at the I2C Bus of the Raspberry pi
> Before=basic.target
> Conflicts=shutdown.target
> DefaultDependencies=no
>
> [Service]
> Type=oneshot
> ExecStart=/bin/sh -c "modprobe i2c_bcm2835 && modprobe i2c_bcm2708 &&
> modprobe rtc_ds1307 && sleep 1 && echo ds1307 0x68 >
> /sys/class/i2c-adapter/i2c-1/new_device && /sbin/hwclock -s"
> ExecStop=/sbin/hwclock -w RemainAfterExit=yes
>
> [Install]
> WantedBy=basic.target

Activate a Real Time Clock chip on I2C in Raspberry Pi 4B with Debian (not Raspbian)

[Rick Thomas]

I've got a Raspberry Pi 4B (4GB) with a DS3231 RTC module.  I can make the 
combo work with Ubuntu and RaspberryPI-OS.  I'd like to try it with the 
plain-vanilla Debian from  but I can't 
find instructions for activating the I2C and RTC hardware in that OS.

Any suggestions?  Thanks!

Rick

Re: What happened to "u-boot" package for Debian testing distribution on Cubox-i

[Rick Thomas]

Please... Anyone with experience here, please speak up.  I don't want to do 
anything stupid, but I *do* need to get this issue straightened out.

Thanks in advance for any help!
Rick

On Thu, Feb 23, 2023, at 10:36 PM, Rick Thomas wrote:
> On Thu, Feb 23, 2023, at 8:02 PM, Vagrant Cascadian wrote:
>> On 2023-02-23, Rick Thomas wrote:
>>> I just noticed that there are no versions of the package "u-boot" available 
>>> on my SolidRun CuBox-i.
>>> However there is a version of "u-boot-imx" available which contains the 
>>> actual binary
>>> code for this machine.
>>> Interestingly, I have other arm-based boxes and none of them have this 
>>> problem.
>>
>> u-boot (2023.01~rc4+dfsg-2) unstable; urgency=medium
>> ...
>>   * debian/control: Drop u-boot meta-package for armhf and mips.
>> ...
>>  -- Vagrant Cascadian   Thu, 05 Jan 2023 19:38:24 -0800
>>
>> I had meant to deprecate it back in ... maybe 2016 or 2018 and finally
>> remembered to do it this release cycle!
>>
>> The actual binaries you are using come from u-boot-imx since u-boot
>> 2014.x versions...
>>
>>
>> live well,
>>   vagrant
>
> Ahhh... thanks!  That explains it.
>
> So...  Is it true that all I need to do is:
> aptitude unmarkauto u-boot-imx
> aptitude purge u-boot
> ?
>
> Do I need to do that on all of my arm based machines?  If so, is there 
> an approved way to figure out, for any given machine type, which of the 
> "uboot-*" packages I should "unmarkauto?"?
>
> Rick

Re: What happened to "u-boot" package for Debian testing distribution on Cubox-i

[Rick Thomas]

On Thu, Feb 23, 2023, at 8:02 PM, Vagrant Cascadian wrote:
> On 2023-02-23, Rick Thomas wrote:
>> I just noticed that there are no versions of the package "u-boot" available 
>> on my SolidRun CuBox-i.
>> However there is a version of "u-boot-imx" available which contains the 
>> actual binary
>> code for this machine.
>> Interestingly, I have other arm-based boxes and none of them have this 
>> problem.
>
> u-boot (2023.01~rc4+dfsg-2) unstable; urgency=medium
> ...
>   * debian/control: Drop u-boot meta-package for armhf and mips.
> ...
>  -- Vagrant Cascadian   Thu, 05 Jan 2023 19:38:24 -0800
>
> I had meant to deprecate it back in ... maybe 2016 or 2018 and finally
> remembered to do it this release cycle!
>
> The actual binaries you are using come from u-boot-imx since u-boot
> 2014.x versions...
>
>
> live well,
>   vagrant

Ahhh... thanks!  That explains it.

So...  Is it true that all I need to do is:
aptitude unmarkauto u-boot-imx
aptitude purge u-boot
?

Do I need to do that on all of my arm based machines?  If so, is there an 
approved way to figure out, for any given machine type, which of the "uboot-*" 
packages I should "unmarkauto?"?

Rick

What happened to "u-boot" package for Debian testing distribution on Cubox-i

[Rick Thomas]

I just noticed that there are no versions of the package "u-boot" available on 
my SolidRun CuBox-i.
However there is a version of "u-boot-imx" available which contains the actual 
binary
code for this machine.
Interestingly, I have other arm-based boxes and none of them have this problem.

See attached text capture for details.
Let me know if there's anything else I can provide that will be helpful.

Thanks in advance,
Rick
rbthomas@half:~$ aptitude versions --disable-columns '?name(u-boot)'
Package u-boot:
i  2022.04+dfsg-2+b1  100

Package u-boot-exynos:
i A 2023.01+dfsg-2 testing 500

Package u-boot-imx:
i  2023.01+dfsg-2 testing 500

Package u-boot-menu:
p  4.2.1 testing 500

Package u-boot-omap:
i A 2023.01+dfsg-2 testing 500

Package u-boot-qemu:
p  2023.01+dfsg-2 testing 500

Package u-boot-rockchip:
p  2023.01+dfsg-2 testing 500

Package u-boot-rpi:
p  2023.01+dfsg-2 testing 500

Package u-boot-stm32:
p  2023.01+dfsg-2 testing 500

Package u-boot-sunxi:
i A 2023.01+dfsg-2 testing 500

Package u-boot-tegra:
p  2023.01+dfsg-2 testing 500

Package u-boot-tools:
i  2023.01+dfsg-2 testing 500


rbthomas@half:~$ grep -v '^#' /etc/apt/sources.list

deb http://deb.debian.org/debian/ bookworm main non-free contrib 
non-free-firmware

deb http://security.debian.org/debian-security bookworm-security main contrib 
non-free non-free-firmware

deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware

deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free 
non-free-firmware


rbthomas@half:~$ arch
armv7l
rbthomas@half:~$ 

Re: Bug#1016963: Help with testing u-boot!

[Rick Thomas]

Here's another Cubox-i.  This one's running Bookworm.
 shows a surprising number of u-boot- 
packages installed, ( = exynos, imx, omap, sunxi)  as well as plain 
"u-boot".  All of them are version 2022.04+dfsg-2+b1.

Rebooting while watching the serial console output says "U-Boot SPL 
2016.05-rc2+dfsg0~20160423~1-1 (Apr 24 2016 - 04:24:21)"  So the firmware does 
not correspond to what aptitude says.   

Should I try installing the "22.04" version in the firmware?   If so, are there 
directions for doing that available somewhere?

HTH
Rick

On Wed, Dec 28, 2022, at 3:21 PM, Vagrant Cascadian wrote:
> On 2022-12-22, Vagrant Cascadian wrote:
>> On 2022-08-20, Vagrant Cascadian wrote:
>>> On 2022-08-10, Vagrant Cascadian wrote:
 This bug is just to delay migration to testing while more platforms get
 tested. If you have a relevent board, please consider testing and
 reporting the status:

   https://wiki.debian.org/U-boot/Status
>
> I have not received many test results for current or even remotely
> recent u-boot platforms in Debian, and u-boot has been blocked from
> migration to testing partly because of this.
>
> As the bookworm freeze approaches, this is getting to be... worrysome!
>
> If you have access to any of these boards, please consider testing
> u-boot versions as packaged in debian for versions from debian stable
> (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
> (2023.01-rc*) and updating the wiki page if successful and/or replying
> to 1016...@bugs.debian.org with a positive confirmation...
>
> ...and if not successful, filing bugs against the relevent u-boot-*
> packages and marking them as blocking 1016963.
>
> # arm64
> khadas-vim
> khadas-vim2
> libretech-cc
> nanopi-k2
> odroid-c2
> odroid-n2
> mvebu_espressobin-88f3720
> dragonboard410c
> dragonboard820c
> firefly-rk3399
> nanopc-t4-rk3399
> nanopi-neo4-rk3399
> pinebook-pro-rk3399
> puma-rk3399
> roc-pc-rk3399
> rock-pi-4-rk3399
> rock-pi-e-rk3328
> rock64-rk3328
> rockpro64-rk3399
> rpi_3
> rpi_4
> rpi_arm64
> a64-olinuxino
> a64-olinuxino-emmc
> nanopi_neo2
> nanopi_neo_plus2
> orangepi_one_plus
> orangepi_zero_plus2
> pine64-lts
> pine64_plus
> pinebook
> pinephone
> pinetab
> sopine_baseboard
> teres_i
> p2371-2180
>
> # armel
> dockstar
> dreamplug
> guruplug
> sheevaplug
> rpi
> rpi_0_w
>
> # armhf
> arndale
> odroid
> odroid-xu3
> colibri_imx6
> dh_imx6
> mx53loco
> mx6cuboxi
> mx6qsabrelite
> nitrogen6q
> novena
> novena-rawsd
> udoo
> usbarmory
> wandboard
> am335x_boneblack
> am335x_evm
> am57xx_evm
> dra7xx_evm
> igep00x0
> nokia_rx51
> omap3_beagle
> omap4_panda
> firefly-rk3288
> rpi_2
> rpi_3_32b
> rpi_4_32b
> stm32mp157c-dk2
> A10-OLinuXino-Lime
> A10s-OLinuXino-M
> A20-OLinuXino-Lime
> A20-OLinuXino-Lime2
> A20-OLinuXino-Lime2-eMMC
> A20-OLinuXino_MICRO
> A20-OLinuXino_MICRO-eMMC
> A20-Olimex-SOM-EVB
> Bananapi
> Bananapi_M2_Ultra
> Bananapro
> CHIP
> Cubieboard
> Cubieboard2
> Cubieboard4
> Cubietruck
> Cubietruck_plus
> Lamobo_R1
> Linksprite_pcDuino
> Linksprite_pcDuino3
> Mini-X
> Sinovoip_BPI_M3
> bananapi_m2_berry
> nanopi_neo
> nanopi_neo_air
> orangepi_plus
> orangepi_zero
> jetson-tk1
>
>
> Thanks!
>
>
> live well,
>   vagrant
>
> Attachments:
> * signature.asc

Re: Bug#1016963: Help with testing u-boot!

[Rick Thomas]

A Cubox-i running Debian bullseye (11.6).  According to  It 
has "u-boot-tools" (version 2021.01+dfsg-5) installed, but none of the 
u-boot-  packages installed.

If I reboot it and watch the serial console, I see it showing "U-boot 
2021.01-dfsg-5" so that version must have gotten into the firmware somehow 
without telling Linux about it... 
Other info that might be helpful that shows with the reboot is
CPU: Freescale i.MX6Q rev 1.3
Board: MX6 Cubox-i

HTH,
Rick

On Wed, Dec 28, 2022, at 3:21 PM, Vagrant Cascadian wrote:
> On 2022-12-22, Vagrant Cascadian wrote:
>> On 2022-08-20, Vagrant Cascadian wrote:
>>> On 2022-08-10, Vagrant Cascadian wrote:
 This bug is just to delay migration to testing while more platforms get
 tested. If you have a relevent board, please consider testing and
 reporting the status:

   https://wiki.debian.org/U-boot/Status
>
> I have not received many test results for current or even remotely
> recent u-boot platforms in Debian, and u-boot has been blocked from
> migration to testing partly because of this.
>
> As the bookworm freeze approaches, this is getting to be... worrysome!
>
> If you have access to any of these boards, please consider testing
> u-boot versions as packaged in debian for versions from debian stable
> (2021.01*), testing (2022.04*), unstable (2022.10*) and experimental
> (2023.01-rc*) and updating the wiki page if successful and/or replying
> to 1016...@bugs.debian.org with a positive confirmation...
>
> ...and if not successful, filing bugs against the relevent u-boot-*
> packages and marking them as blocking 1016963.
>
> # arm64
> khadas-vim
> khadas-vim2
> libretech-cc
> nanopi-k2
> odroid-c2
> odroid-n2
> mvebu_espressobin-88f3720
> dragonboard410c
> dragonboard820c
> firefly-rk3399
> nanopc-t4-rk3399
> nanopi-neo4-rk3399
> pinebook-pro-rk3399
> puma-rk3399
> roc-pc-rk3399
> rock-pi-4-rk3399
> rock-pi-e-rk3328
> rock64-rk3328
> rockpro64-rk3399
> rpi_3
> rpi_4
> rpi_arm64
> a64-olinuxino
> a64-olinuxino-emmc
> nanopi_neo2
> nanopi_neo_plus2
> orangepi_one_plus
> orangepi_zero_plus2
> pine64-lts
> pine64_plus
> pinebook
> pinephone
> pinetab
> sopine_baseboard
> teres_i
> p2371-2180
>
> # armel
> dockstar
> dreamplug
> guruplug
> sheevaplug
> rpi
> rpi_0_w
>
> # armhf
> arndale
> odroid
> odroid-xu3
> colibri_imx6
> dh_imx6
> mx53loco
> mx6cuboxi
> mx6qsabrelite
> nitrogen6q
> novena
> novena-rawsd
> udoo
> usbarmory
> wandboard
> am335x_boneblack
> am335x_evm
> am57xx_evm
> dra7xx_evm
> igep00x0
> nokia_rx51
> omap3_beagle
> omap4_panda
> firefly-rk3288
> rpi_2
> rpi_3_32b
> rpi_4_32b
> stm32mp157c-dk2
> A10-OLinuXino-Lime
> A10s-OLinuXino-M
> A20-OLinuXino-Lime
> A20-OLinuXino-Lime2
> A20-OLinuXino-Lime2-eMMC
> A20-OLinuXino_MICRO
> A20-OLinuXino_MICRO-eMMC
> A20-Olimex-SOM-EVB
> Bananapi
> Bananapi_M2_Ultra
> Bananapro
> CHIP
> Cubieboard
> Cubieboard2
> Cubieboard4
> Cubietruck
> Cubietruck_plus
> Lamobo_R1
> Linksprite_pcDuino
> Linksprite_pcDuino3
> Mini-X
> Sinovoip_BPI_M3
> bananapi_m2_berry
> nanopi_neo
> nanopi_neo_air
> orangepi_plus
> orangepi_zero
> jetson-tk1
>
>
> Thanks!
>
>
> live well,
>   vagrant
>
> Attachments:
> * signature.asc

Re: Bug#1016963: Help with testing u-boot!

[Rick Thomas]

Raspberry Pi 4B (8GB) running bullseye, but does not seem to have any version 
of u-boot installed.  Weird?
Running   tells me that the following (among 
lots of others) versions are available.  Should I install one of them and see 
what happens?

Package u-boot-rpi:
p  2021.01+dfsg-5 stable 500

Package u-boot-rpi:armhf:
p  2021.01+dfsg-5 stable 500

HTH
Rick

Re: Any suggestions for a Debian(based/like) OS for the Orange Pi zero2

[Rick Thomas]

Thanks, Andy!  I'll try the ftp.debian.org link tonight.  It looks like exactly 
what I'm looking for.

Rick

On Mon, Oct 10, 2022, at 3:32 AM, Andrew M.A. Cater wrote:
> On Sun, Oct 09, 2022 at 07:17:44PM -0700, Rick Thomas wrote:
>> He Debian Arm folks,
>> 
>> Out of curiosity, I recently bought a couple of Orange Pi zero2 kits because 
>> I wanted to see what could be done with such a really inexpensive board.
>> 
>> Now I'm looking for an OS.  The Orange Pi web site claims that it supports 
>> Debian and Ubuntu among others, but I can't find any links to where to 
>> download Debian or Ubuntu for this hardware.  So far the best I've been able 
>> to do is a Bullseye-based version of Armbian.  But I'd really like to have 
>> an un-modified Debian, if such a thing is possible.
>> 
>> Anybody got any suggestions?
>> 
>> Thanks in advance!
>> Rick
>>
>
> Hi Rick,
>
> It looks as if it might not be supported by Debian - yet - in the SD 
> card
> images but the download link is here - 
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-Zero-2.html
>
> There is at least a Bullseye image with desktop and a Bullseye server image.
>
> Orange Pi zero 2 Debian into a search engine found it for me quickly.
>
> Aha - found it - 
> http://ftp.debian.org/debian/dists/stable/main/installer-arm64/current/images/netboot/SD-card-images/
>  
> shows a current Debian image for it.
>
> Debian SD card images found me that one.
>
> Hope this helps,
>
> With every good wish, as ever,
>
> Andy Cater

Re: Any suggestions for a Debian(based/like) OS for the Orange Pi zero2

[Rick Thomas]

On Mon, Oct 10, 2022, at 3:31 AM, RobJE wrote:
> Hi Rick,
>
> On 10-10-2022 04:17, Rick Thomas wrote:
>> He Debian Arm folks,
>> 
>> Out of curiosity, I recently bought a couple of Orange Pi zero2 kits because 
>> I wanted to see what could be done with such a really inexpensive board.
>> 
>> Now I'm looking for an OS.  The Orange Pi web site claims that it supports 
>> Debian and Ubuntu among others, but I can't find any links to where to 
>> download Debian or Ubuntu for this hardware.  So far the best I've been able 
>> to do is a Bullseye-based version of Armbian.  But I'd really like to have 
>> an un-modified Debian, if such a thing is possible.
>> 
>> Anybody got any suggestions?
>
> did you try the link on the Orange Pi wiki?  [1]
>
> [1] 
> <http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-Pi-Zero-2.html>
>
>> Thanks in advance!
>> Rick
>
> GRTNX,
> RobJE

Yes, in fact I discovered that one after I had written my original post.  It 
works pretty well.  But there's some rather strange things about it:
The /etc/apt/sources.list file is directed to 
http://mirrors.tuna.tsinghua.edu.cn/debian
rather than
https://deb.debian.org/debian
Is there something special about the Chinese mirror that I should know?  If 
not, can I replace it with the stock debian mirror?
And there are a few .deb packages that come pre-installed but are not 
present on that mirror.  Most of them have "orangepi" as part of their package 
name.  Their purpose seems to be to help in configuring the system.  Many of 
them are borrowed almost verbatim from the Armbian distribution for Orange Pi 
with "armbian" replaced by "orangepi".
Also, the installed system uses zram files for swap and /var/log .  This is 
probably to limit the space the distro takes up on an SD card, and it works OK, 
but it's not what I'd expect from a "stock" Debian install.  It would be 
interesting to know where those .deb files reside when their at home (i.e. is 
there a repository that could/should have been included in the sources.list ?)

In any case, my next try will be the stock Debian AArch64 installer image as 
recommended by Marcin.

Thanks to everyone for all the good answers so far -- keep 'em coming!
Rick

Any suggestions for a Debian(based/like) OS for the Orange Pi zero2

[Rick Thomas]

He Debian Arm folks,

Out of curiosity, I recently bought a couple of Orange Pi zero2 kits because I 
wanted to see what could be done with such a really inexpensive board.

Now I'm looking for an OS.  The Orange Pi web site claims that it supports 
Debian and Ubuntu among others, but I can't find any links to where to download 
Debian or Ubuntu for this hardware.  So far the best I've been able to do is a 
Bullseye-based version of Armbian.  But I'd really like to have an un-modified 
Debian, if such a thing is possible.

Anybody got any suggestions?

Thanks in advance!
Rick

Re: failure trying to install bullseye on Cubox-i

[Rick Thomas]

Well, I re-downloaded and re-copied the resulting complete image to a micro-SD 
card by a different manufacturer, and lo and behold, it all works this time!

Sigh!
Sorry for all the noise,
Rick

On Sun, Jul 17, 2022, at 6:47 PM, Rick Thomas wrote:
> On Sun, Jul 17, 2022, at 6:37 PM, Rick Thomas wrote:
>> I'm experimenting with installing Bullseye on a Cubox-i4Pro I keep 
>> around for testing purposes.
>>
>> I followed the instructions at:
>> 
>> 
>> http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images
>>
>> Then I dd'ed the resulting complete image onto an 8GB microSD card, 
>> which I then inserted into the microSD slot in the Cubox-I.  When I 
>> applied power, I got the attached log on the serial console.
>>
>> Does anyone know what I'm doing wrong?  Is this a bug in the installer? 
>>  If so, what's the best way for me to volunteer to help as a tester in 
>> debugging it.
>>
>> Rick
>> Attachments:
>> * screenlog
>
> In case it helps, the two components I used in this experiment are:
>
> 
> http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/20210731+deb11u4/images/netboot/SD-card-images/firmware.MX6_Cubox-i.img.gz
>
> and
>
> 
> http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/20210731+deb11u4/images/netboot/SD-card-images/partition.img.gz
>
> On the web page, these files are dated 2022-07-05 15:57 .
>
> Any clues are appreciated!
> Rick

Re: failure trying to install bullseye on Cubox-i

[Rick Thomas]

On Sun, Jul 17, 2022, at 6:37 PM, Rick Thomas wrote:
> I'm experimenting with installing Bullseye on a Cubox-i4Pro I keep 
> around for testing purposes.
>
> I followed the instructions at:
> 
> 
> http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images
>
> Then I dd'ed the resulting complete image onto an 8GB microSD card, 
> which I then inserted into the microSD slot in the Cubox-I.  When I 
> applied power, I got the attached log on the serial console.
>
> Does anyone know what I'm doing wrong?  Is this a bug in the installer? 
>  If so, what's the best way for me to volunteer to help as a tester in 
> debugging it.
>
> Rick
> Attachments:
> * screenlog

In case it helps, the two components I used in this experiment are:


http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/20210731+deb11u4/images/netboot/SD-card-images/firmware.MX6_Cubox-i.img.gz

and


http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/20210731+deb11u4/images/netboot/SD-card-images/partition.img.gz

On the web page, these files are dated 2022-07-05 15:57 .

Any clues are appreciated!
Rick

failure trying to install bullseye on Cubox-i

[Rick Thomas]

I'm experimenting with installing Bullseye on a Cubox-i4Pro I keep around for 
testing purposes.

I followed the instructions at:

http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images

Then I dd'ed the resulting complete image onto an 8GB microSD card, which I 
then inserted into the microSD slot in the Cubox-I.  When I applied power, I 
got the attached log on the serial console.

Does anyone know what I'm doing wrong?  Is this a bug in the installer?  If so, 
what's the best way for me to volunteer to help as a tester in debugging it.

Rick

screenlog
Description: Binary data

Re: SheevaPlug -- first phase results successful.

[Rick Thomas]

Hi Martin,

On Wed, Jun 8, 2022, at 10:17 PM, Martin Michlmayr wrote:
>> Indeed, I do have two OpenRD machines running right now, an
>> "Ulitmate" and a "Client".  Both are available for testing.  Let me
>> know what you would like me to do and I'll get to it ASAP.   I also
>> have a SheevaPlug currently running and available for testing if
>> that's of any interest.
>
> Hi Rick,
>
> If the SheevaPlug is available for testing, can you do two things:
>
> 1) Install bullseye

Worked fine and checked OK (yeah, it's Bullseye).  I installed a minimal 
setup (no GUIs no network servers) with only ssh and an otherwise basic system.
I put the installation "uI*" files on a 64GB micro-SD card (in a micro -> 
full-size adapter) formatted as ext2 then installed to that same SD card.  No 
USB involved.  Let me know if you want me to try a USB stick as well.
I allowed the guided partitioner to put everything in one partition.  I 
didn't try anything fancy like LVM or manual partitioning.  Again, let me know 
if you want me to try something else.

> * Boot into u-boot and check the version: type "version"

U-Boot 2016.01-rc3+dfsg1-3 (Jan 02 2016 - 23:19:11 +)
Marvell-Sheevaplug

>
> * Install bullseye according to the instructions here:
> http://www.cyrius.com/debian/kirkwood/sheevaplug/install/
> Note that the download links point to buster.  You have to replace
> buster with bullseye in the link.

No problem.  Worked fine with "buster" -> "bullseye")
>
> * Check if the installation is okay and you have Debian bullseye at the
> end (/etc/debian_version).

See above.  results as expected.

> 2) Try u-boot from bullseye
>
> Basically, follow
> http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/
> but replace stretch with bullseye in the download link

Haven't tried this yet -- see below...

>
> Warning: if this fails, you need OpenOCD to recover.  I can't help
> with this. (I haven't touched these devices in years!)  But I think
> you've used OpenOCD before.

I have indeed used OpenOCD before, but it was a long time ago in a galaxy 
far, far away.
Can you point me at instructions for using OpenOCD?Thanks!
I've got a second sheevaplug that I bricked a long time ago, but I wonder 
if OpenOCD might bring it back to life.  I'll try that one first.

>
> If it works, check if USB, etc work (i.e. boot from the USB stick into
> Debian).  You could also do another installation of Debian just in
> case but that's not needed.

It's fun!Let me know if you want to see any log files or so on.

>
> If you have time for this, great!  But if not, no worries.
>
> -- 
> Martin Michlmayr
> https://www.cyrius.com/

More results later!
Rick

Re: Debian 11 on Sheevaplug?

[Rick Thomas]

Hi Giles,
It really looks like the version of uboot you're using only understands ext2 
(and fat, most likely, but I'm not sure that helps you in this situation)

Try dropping back to ext2 for anything that needs to be accessed by uboot.
Enjoy!
Rick

On Thu, Jun 9, 2022, at 6:26 AM, Gilles wrote:
> Forgot to write that I tried this line manually:
>
> Marvell>> setenv bootcmd_usb 'usb start; ext4load usb 0:1 0x0080 
> /uImage; ext4load usb 0:1 0x0110 /uInitrd'
>
>
> Marvell>> print
> baudrate=115200
> bootargs=console=ttyS0,115200
> bootargs_console=console=ttyS0,115200
> bootcmd=setenv bootargs $(bootargs_console); run bootcmd_usb; bootm 
> 0x0080 0x0110
> bootcmd_usb=usb start; ext4load usb 0:1 0x0080 /uImage; ext4load usb 
> 0:1 0x0110 /uInitrd
> bootdelay=3
> ethact=egiga0
> ethaddr=02:50:43:e7:5c:e1
> ipaddr=192.168.0.10
> serverip=192.168.0.12
> stderr=serial
> stdin=serial
> stdout=serial
> x_bootargs=console=ttyS0,115200 
> mtdparts=orion_nand:512k(uboot),4m@1m(kernel),507m@5m(rootfs) rw
> x_bootargs_root=ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
> x_bootcmd_kernel=nand read 0x640 0x10 0x40
> x_bootcmd_sata=ide reset;
> x_bootcmd_usb=usb start;
> Environment size: 706/131068 bytes
>
> Marvell>> run bootcmd
>
> (Re)start USB...
> USB:   Register 10011 NbrPorts 1
> USB EHCI 1.00
> scanning bus for devices... 2 USB Device(s) found
>     scanning bus for storage devices... 1 Storage Device(s) found
> Unknown command 'ext4load' - try 'help'
> Unknown command 'ext4load' - try 'help'
> ## Booting kernel from Legacy Image at 0080 ...
>     Image Name:   kernel 4.9.0-18-marvell
>     Image Type:   ARM Linux Kernel Image (uncompressed)
>     Data Size:    2080634 Bytes = 2 MiB
>     Load Address: 8000
>     Entry Point:  8000
>     Verifying Checksum ... Bad Data CRC
> ERROR: can't get kernel image!
> Marvell>>
>
> On 09/06/2022 15:14, Gilles wrote:
>> I used another USB stick, with the root+boot formated in ext4, the 
>> install completed, but… Uboot fails loading:
>>
>> =
>> U-Boot 2011.12 (Mar 11 2012 - 18:59:46)
>> Marvell-Sheevaplug - eSATA - SD/MMC
>>
>> SoC:   Kirkwood 88F6281_A0
>> DRAM:  512 MiB
>> WARNING: Caches not enabled
>> NAND:  512 MiB
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Net:   egiga0
>> 88E1116 Initialized on egiga0
>> Hit any key to stop autoboot:  0
>> (Re)start USB...
>> USB:   Register 10011 NbrPorts 1
>> USB EHCI 1.00
>> scanning bus for devices... 2 USB Device(s) found
>>    scanning bus for storage devices... 1 Storage Device(s) found
>> Loading file "/uImage" from usb device 0:1 (usbda1)
>> Failed to mount ext2 filesystem...
>> ** Bad ext2 partition or disk - usb 0:1 **
>> Loading file "/uInitrd" from usb device 0:1 (usbda1)
>> Failed to mount ext2 filesystem...
>> ** Bad ext2 partition or disk - usb 0:1 **
>> ## Booting kernel from Legacy Image at 0080 ...
>>    Image Name:   kernel 4.9.0-18-marvell
>>    Image Type:   ARM Linux Kernel Image (uncompressed)
>>    Data Size:    2080634 Bytes = 2 MiB
>>    Load Address: 8000
>>    Entry Point:  8000
>>    Verifying Checksum ... Bad Data CRC
>> ERROR: can't get kernel image!
>> Marvell>>
>> =
>>
>> That was with the original settings:
>> setenv bootargs_console console=ttyS0,115200
>> setenv bootcmd_usb 'usb start; ext2load usb 0:1 0x0080 /uImage; 
>> ext2load usb 0:1 0x0110 /uInitrd'
>> setenv bootcmd 'setenv bootargs $(bootargs_console); run bootcmd_usb; 
>> bootm 0x0080 0x0110'
>>
>> => Does Uboot support ext4, or just ext2? Or is the 2011.12 release 
>> too old, and I should either upgrade or go back to ext2 instead?
>>
>> On 08/06/2022 15:36, Philip Hands wrote:
>>> Gilles  writes:
>>>
>>>> On 08/06/2022 00:54, Rick Thomas wrote:
>>>>> On Tue, Jun 7, 2022, at 6:32 AM, Gilles wrote:
>>>>>> It ends with a single error : "partman: mkswap: can't open 
>>>>>> '/dev/sda5':
>>>>>> No such file or directory":
>>>>>>
>>>>>> https://pastebin.com/raw/h0beZWnP
>>>>> It looks like /dev/sd5 doesn't actually exist.  This is probably 
>>>>> because the USB stick has an MBR partition table which by default 
>>>>> only provides partitions 1-4.  You may need to pre-partition it 
>>>>> with a GUID partition table.
>>>>>
&g

Re: Debian 11 on Sheevaplug?

[Rick Thomas]

On Tue, Jun 7, 2022, at 6:32 AM, Gilles wrote:
> It ends with a single error : "partman: mkswap: can't open '/dev/sda5': 
> No such file or directory":
>
> https://pastebin.com/raw/h0beZWnP

It looks like /dev/sd5 doesn't actually exist.  This is probably because the 
USB stick has an MBR partition table which by default only provides partitions 
1-4.  You may need to pre-partition it with a GUID partition table.

Rick

Re: Debian 11 on Sheevaplug?

[Rick Thomas]

On Thu, Jun 2, 2022, at 5:15 AM, Gilles wrote:
> Hello,
>
> A search in the archives returned no hits.
>
> Martin Michlmayr's page* shows how to install Debian 10 on a USB 
> keydrive to run on a Sheevaplug.
>
> Does it mean Debian 11 still isn't available for that device?
>
> Thank you.
>
> * https://www.cyrius.com/debian/kirkwood/sheevaplug/install/

Have you tried just following Martin's instructions for 10 using the 
corresponding components for 11?

I'd like to do the same thing (upgrade to 11) on my SheevaPlug.  Maybe I'll try 
that.

Enjoy!
Rick

Re: Debian armhf test system?

[Rick Thomas]

On Sat, Sep 25, 2021, at 6:59 AM, Jeffrey Walton wrote:
> Hi Everyone,
>
> We are trying to track down the cause of a build failure on Debian;
> see [1]. I want to setup a Debian armhf system for testing. (I have
> about 6 testing boards, but they are other OSes).
>
> I found the relevant area of the manual that says Debian supports
> armel, armhf and arm64,[2] but I have not found a list of supported
> hardware like a specific SBC.
>
> Can someone provide a recommendation for a readily available armhf
> device? Like something I can order from Amazon?
>
> Thanks in advance.
>
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B=armhf=8.6.0-1=1632566181=0
> [2] https://www.debian.org/releases/stable/arm64/ch02s01.en.html

The Cubox-i4Pro will do what you want:
https://shop.solid-run.com/product/SRMX6QDWT1D02GE008X00CE/

Hope it helps!
Rick

How to install Bullseye on Cubox-i4Pro on USB or eSATA disk?

[Rick Thomas]

I recently tried installing the two-part image for MX6_Cubox-i from [1] on my 
Cubox-i4Pro.

It worked fine when I installed to an SD card -- I used a 32 GB card for the 
installer and installed to that same card.  But that's kinda limited.  The box 
has USB and eSATA ports that I'd like to be able to use, if only because they 
should be faster than the SD card.

Ideally, the configuration I would like to have is system (root and /home) 
reside on a 32GB USB flash stick, if necessary with /boot on an SD card, but 
ideally with /boot on the USB stick as well.

I tried doing an "expert" install with manual disk partitioning -- putting  
/boot on the SD card and root and /home on the USB stick -- but when it 
rebooted it just hung, even after power-cycling.

Same thing happened when I did a "guided" partitioning install with all 
partitions (/boot, root, and /home) on the USB stick.

What am I missing?

Rick

[1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/

Re: on OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working.

[Rick Thomas]

On Sat, Mar 27, 2021, at 1:07 PM, Vagrant Cascadian wrote:
> On 2021-03-14, Rick Thomas wrote:
> > I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to 
> > Bullseye and now haveged crashes.
> >
> > $ sudo service haveged status
> > * haveged.service - Entropy Daemon based on the HAVEGE algorithm
> >  Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor 
> > preset: enabled)
> >  Active: failed (Result: signal) since Sat 2021-03-13 05:06:23 PST; 19h 
> > ago
> >Docs: man:haveged(8)
> >  http://www.issihosts.com/haveged/
> > Process: 1610 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
> > $DAEMON_ARGS (code=killed, signal=SYS)
> >Main PID: 1610 (code=killed, signal=SYS)
> > CPU: 247ms
> >
> > Mar 13 05:06:23 client systemd[1]: haveged.service: Scheduled restart job, 
> > restart counter is at 5.
> > Mar 13 05:06:23 client systemd[1]: Stopped Entropy Daemon based on the 
> > HAVEGE algorithm.
> > Mar 13 05:06:23 client systemd[1]: haveged.service: Start request repeated 
> > too quickly.
> > Mar 13 05:06:23 client systemd[1]: haveged.service: Failed with result 
> > 'signal'.
> > Mar 13 05:06:23 client systemd[1]: Failed to start Entropy Daemon based on 
> > the HAVEGE algorithm.
> 
> Wild guess here, but maybe try the workaround from:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866306#59
> 
> e.g. pass --data=16 (or maybe some other value) to haveged.

Thanks for taking a look at this!   Unfortunately, it doesn't seem to work.
Here's what I did to try it:

I changed /etc/default/haveged as follows --
< #DAEMON_ARGS=""
---
> DAEMON_ARGS="--data=16"

Then as root did
service haveged restart
and
service haveged status

Results same as above.

I also tried --
< #DAEMON_ARGS=""
---
> DAEMON_ARGS="--data=16 --inst=16"

which does not seem to work, either.

Interestingly, running haveged in the foreground, without any cache size hints, 
seems to work fine:

root@client:~# haveged -n 2048 -f - > /tmp/sample
haveged: command socket is listening at fd 3
Writing 2 K byte output to stdout
root@client:~# ls -l /tmp/sample
-rw-r--r-- 1 root root 2048 Mar 31 00:15 /tmp/sample

Rick

Re: on OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working.

[Rick Thomas]

Bug#985196


On Sun, Mar 14, 2021, at 12:41 AM, Rick Thomas wrote:
> I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster 
> to Bullseye and now haveged crashes.
> 
> $ sudo service haveged status
> * haveged.service - Entropy Daemon based on the HAVEGE algorithm
>  Loaded: loaded (/lib/systemd/system/haveged.service; enabled; 
> vendor preset: enabled)
>  Active: failed (Result: signal) since Sat 2021-03-13 05:06:23 PST; 
> 19h ago
>Docs: man:haveged(8)
>  http://www.issihosts.com/haveged/
> Process: 1610 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
> $DAEMON_ARGS (code=killed, signal=SYS)
>Main PID: 1610 (code=killed, signal=SYS)
> CPU: 247ms
> 
> Mar 13 05:06:23 client systemd[1]: haveged.service: Scheduled restart 
> job, restart counter is at 5.
> Mar 13 05:06:23 client systemd[1]: Stopped Entropy Daemon based on the 
> HAVEGE algorithm.
> Mar 13 05:06:23 client systemd[1]: haveged.service: Start request 
> repeated too quickly.
> Mar 13 05:06:23 client systemd[1]: haveged.service: Failed with result 
> 'signal'.
> Mar 13 05:06:23 client systemd[1]: Failed to start Entropy Daemon based 
> on the HAVEGE algorithm.
> 
> I have submitted a bugreport. I'll update to the list when I get the 
> bug number...
> 
> Anybody know a fix?
> Thanks!
> Rick
>

on OpenRD "client" ( arch = armv5tel ) Upgraded from Buster to Bullseye and haveged stoped working.

[Rick Thomas]

I recently updated my OpenRD "client" ( arch = armv5tel ) from Buster to 
Bullseye and now haveged crashes.

$ sudo service haveged status
* haveged.service - Entropy Daemon based on the HAVEGE algorithm
 Loaded: loaded (/lib/systemd/system/haveged.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: signal) since Sat 2021-03-13 05:06:23 PST; 19h ago
   Docs: man:haveged(8)
 http://www.issihosts.com/haveged/
Process: 1610 ExecStart=/usr/sbin/haveged --Foreground --verbose=1 
$DAEMON_ARGS (code=killed, signal=SYS)
   Main PID: 1610 (code=killed, signal=SYS)
CPU: 247ms

Mar 13 05:06:23 client systemd[1]: haveged.service: Scheduled restart job, 
restart counter is at 5.
Mar 13 05:06:23 client systemd[1]: Stopped Entropy Daemon based on the HAVEGE 
algorithm.
Mar 13 05:06:23 client systemd[1]: haveged.service: Start request repeated too 
quickly.
Mar 13 05:06:23 client systemd[1]: haveged.service: Failed with result 'signal'.
Mar 13 05:06:23 client systemd[1]: Failed to start Entropy Daemon based on the 
HAVEGE algorithm.

I have submitted a bugreport. I'll update to the list when I get the bug 
number...

Anybody know a fix?
Thanks!
Rick

Re: RPi customization utility [Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]]

[Rick Thomas]

Thanks Andy and Alan, for the clarification.

This is an experimental system, so I felt there was no long-term harm (it being 
a short-term installation, anyway) in installing rapsi-config from the raspian 
archives just to see what it looked like and explore what it could do.  Having 
verified that it really doesn't do anything I can't do just as easily manually 
(all the things Andy listed and a few more) I will probably take the manual 
approach in the future.

Enjoy!
Rick

On Sun, Feb 28, 2021, at 3:49 AM, Alan Corey wrote:
> Right, I wasn't exactly recommending running raspi-config on a non-raspian 
> system but looking at how it does things and doing them manually.  One of the 
> things I dislike about Debian (I haven't looked at others) is that there's an 
> ever-increasing hodgepodge of specialized little scripts.  If you've been 
> using it awhile you're probably not in the habit of re-reading documentation 
> to see if somebody changed how you're officially supposed to do something.
> 
> But raspi-config is a place to look up things like how to boot to a command 
> line, or how to configure locales or change your keyboard layout.  And it's 
> maintained, unlike some ancient documentation that should be banished but is 
> still out there.
> 
> 
> On Sun, Feb 28, 2021, 6:17 AM Andrew M.A. Cater  wrote:
>> On Sun, Feb 28, 2021 at 02:16:29AM -0800, Rick Thomas wrote:
>> > 
>> > On Thu, Feb 25, 2021, at 10:10 PM, Alan Corey wrote:
>> > > There are scripts for those, keyboard and language too.  Also WiFi 
>> > > country, I forget what else.  Locales is in there.
>> > > 
>> > > Take a look at a recent raspi-config.  I think Odroid, maybe the Pine64 
>> > > bunch has a generic-ized version of that.  Armbian probably does too.  
>> > > Raspi-config is just a Bash script that uses Whiptail for its menus.  
>> > > Parts of it are useful on other things.  It's on Github somewhere.
>> > > 
>> > > 
>> > > On Thu, Feb 25, 2021, 11:09 PM Rick Thomas  wrote:
>> > >>  
>> > 
>> > Thanks! Alan...
>> > 
>> > So, here's what I found...
>> > 
>> > Immediately after the first boot of the SD card, as root, do the following:
>> > 
>> > #Get the raspi-config utility:
>> > wget 
>> > https://archive.raspberrypi.org/debian/pool/main/r/raspi-config/raspi-config_20200601_all.deb
>> >  -P /tmp
>> > #Install packages it needs:
>> > apt-get install libnewt0.52 whiptail parted triggerhappy lua5.1 
>> > alsa-utils -y
>> > sudo apt-get install -fy
>> > #Install the utility itself:
>> > dpkg -i /tmp/raspi-config_20200601_all.deb
>> > #And run it
>> > raspi-config
>> > 
>> > It will give you a bunch of customizations you might want to do.  I can 
>> > personally vouch that you'll need to at least do options (1) change the 
>> > root password and set up a non-root user,  (2) Configure the network, and 
>> > (4) set localizations (timezone, keyboard, locale, and a few others).
>> > 
>> > The 20200601 version happens to be the latest as of this writing.  But 
>> > just to be sure, you can use the tool itself (option 8) to check for and 
>> > install any updated version.
>> > Easy!
>> > 
>> > Rick
>> 
>> And whoosh - you've created a FrankenDebian and dependencies on a Raspberry 
>> Pi OS that you don't run.. Raspi-config is a collection of 
>> shell scripts. Gunnar's Raspberry Pi images are deliberately small. 
>> 
>> If you want to reconfigure locale - 
>> 
>> apt-get install locales ; dpkg-reconfigure locales 
>> 
>> (this last as root / root equivalent using sudo)
>> 
>> Timezone: dpkg-reconfigure tzdata
>> 
>> There are good Debian commands that will work on every Debian system you
>> come across :-)
>> 
>> All the very best, as ever,
>> 
>> Andy C.
>> 

RPi customization utility [Re: More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]]

[Rick Thomas]

On Thu, Feb 25, 2021, at 10:10 PM, Alan Corey wrote:
> There are scripts for those, keyboard and language too.  Also WiFi country, I 
> forget what else.  Locales is in there.
> 
> Take a look at a recent raspi-config.  I think Odroid, maybe the Pine64 bunch 
> has a generic-ized version of that.  Armbian probably does too.  Raspi-config 
> is just a Bash script that uses Whiptail for its menus.  Parts of it are 
> useful on other things.  It's on Github somewhere.
> 
> 
> On Thu, Feb 25, 2021, 11:09 PM Rick Thomas  wrote:
>>  

Thanks! Alan...

So, here's what I found...

Immediately after the first boot of the SD card, as root, do the following:

#Get the raspi-config utility:
wget 
https://archive.raspberrypi.org/debian/pool/main/r/raspi-config/raspi-config_20200601_all.deb
 -P /tmp
#Install packages it needs:
apt-get install libnewt0.52 whiptail parted triggerhappy lua5.1 alsa-utils 
-y
sudo apt-get install -fy
#Install the utility itself:
dpkg -i /tmp/raspi-config_20200601_all.deb
#And run it
raspi-config

It will give you a bunch of customizations you might want to do.  I can 
personally vouch that you'll need to at least do options (1) change the root 
password and set up a non-root user,  (2) Configure the network, and (4) set 
localizations (timezone, keyboard, locale, and a few others).

The 20200601 version happens to be the latest as of this writing.  But just to 
be sure, you can use the tool itself (option 8) to check for and install any 
updated version.
Easy!

Rick

More progress to report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Rick Thomas]

I installed the most recent Bullseye image [1] on my Pi4B (4GB) a few days ago. 
 It's happily running on the table next to me right now.

Here's what I found:

It loads and boots just as expected.  Apt and tasksel work and I was able to 
install all the utilities I need to make it useful on my network.

However, I noticed a couple of things that I should have expected, but 
nevertheless caused me some confusion at first:
1) The default timezone is set to UTC.  I had to manually set it to account for 
the fact that I live on the US West Coast.
2) When I tried to use aptitude, it complained about not having "locale" info.  
I would have expected default locale to be set to something like "C" that would 
avoid the error messages, even if some/most users would want to re-set it to 
their own preferences, later on.

It would be nice if there was a README describing these quirks (and any others 
I've missed), and how to deal with them after the first boot.  Even better 
would be if there was a script that automatically ran on the first boot that 
asked a bunch of questions and made the appropriate customizations 
automatically.  I'd be willing to write such a script if someone else would 
first write the README so I knew exactly what the script needed to do.

Great work!  Looking forward to the next iteration.

Enjoy!
Rick


[1]  "2021.02.1011 (Bullseye)4"   
https://raspi.debian.net/tested-images/

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Rick Thomas]

On Mon, Feb 22, 2021, at 2:45 AM, Leigh Brown wrote:
> Hi Rick,
... 
> Take a look at the following. No soldering required, and they fit in the
> case nicely (for Pi4 at least).
> 
> Adafruit PiRTC - PCF8523 Real Time Clock for Raspberry Pi
> (https://www.adafruit.com/product/3386)
> 
> Adafruit PiRTC - Precise DS3231 Real Time Clock for Raspberry Pi
> (https://www.adafruit.com/product/4282)

I've ordered one of the high precision modules from adafruit.  It looks like it 
will fit inside the case and hence be protected from accidental damage or 
exposure to the elements.

I'll report back when I've got it installed.

Thanks for the pointers!
Rick

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Rick Thomas]

On Tue, Feb 23, 2021, at 11:45 AM, Gunnar Wolf wrote:
> LinAdmin dijo [Sat, Feb 20, 2021 at 07:30:35PM +0100]:
> > I am not convinced that all images listed on [1] do work as
> > advertized.
> > (...)
> > > [1] https://raspi.debian.net/tested-images/
> 
> 
> Right. I'm only one person responsible for the builds, and quite
> time-starved myself. I did test on real hardware all of the provided
> images, and verified basic functionality for everything I'm claiming
> there... But help is most welcome to improve!
> 
> (and, yes, the great raspi-team has helped quite a bit, but all in
> all, the final step of image building and creation is down to my ten
> fingers and pair of eyes)

I'm here to help test.  I don't have the developer skills (anymore -- last time 
I did that kind of stuff was 30 years or more ago.  The world has seen a lot of 
changes since then!)

Please feel free to email me off list if there's anything I can do to help.

Rick

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Rick Thomas]

On Sun, Feb 21, 2021, at 11:49 AM, Reco wrote:
> On Sun, Feb 21, 2021 at 02:36:52PM -0500, Alan Corey wrote:
> > That's why when you get a real time you adjust the times on your logged
> > events.  There's the time you got the time fix, everything else is N
> > microseconds before that back to when you started recording. So you record
> > back to  minus .
> 
> Yup. But by the time you get this "real time" you have other processes
> (rpc.gssd, for instance) which already have managed to communicate with
> someone (KDC), and are in the wrong state (krb5 time difference).
> 
> RTC solves this, "fake RTC" (i.e. storing a timestamp on reboot) solves
> it to some extent, but nothing else does.
> 
> Reco

My goal is to replace my aging sheevaplug with something more modern.  The 
sheevaplug exists for the purpose of providing network services (in particular, 
for the purposes of this discussion, NTP) to the 20 or so computers on my home 
LAN.  To do that, it needs to have a reliable source of accurate time (to a few 
tens of milliseconds) as soon after boot as possible.

The machine I'd like to use is a Raspberry Pi4B or a Pi0W.  But without an RTC 
it won't do the job.

Hence, I'm looking for an RTC module that can be easily added to a Pi4B or Pi0W 
with minimal (ideally none) soldering, and with Debian kernel support.  If the 
module also does GPS, so much the better!  But that's not strictly necessary.  
It would be very nice if it fits inside the existing case for the Pi4B.

Do any of the devices that folks have mentioned here fit that bill?

Thanks!
Rick

Re: Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Rick Thomas]

On Sat, Feb 20, 2021, at 11:14 PM, Reco wrote:
>   Hi.
> 
> On Sat, Feb 20, 2021 at 10:53:18PM -0800, Rick Thomas wrote:
> > root@pi:~# ls -l /dev/rtc*
> > ls: cannot access '/dev/rtc*': No such file or directory
> > 
> > What package should I file a bug report against for this problem?
> 
> There's nothing to report. No model of Raspberry PI has RTC, so this is
> expected.

Hmmm... A little googling turns up a GPS hat from Adafruit which fits the Pi4B. 
 It can double as both a battery backed hardware clock and an NMEA-PPS source 
for ntp, which would be very cool.  Cost is about $40 which is well within the 
budget for this project.

Thanks for the encouragement!
Rick

Progress report [Re: Debian Bullseye on Raspberry Pi 4 4GB?]

[Rick Thomas]

I downloaded the pre-installed SD card image from 

https://raspi.debian.net/tested-images/

I used the "2021.02.10  10 (Buster) 4"   image.  I

Here's what I did:

Downloaded the img.xz file and the sha256 file, and used the sha  file to check 
the integrity of the img file.

Uncompressed the img.xz and used dd to copy it to a 32GB micro-SD card.  I 
noticed that it left a lot of unused space on the card. (I'll come back to that 
in a later report)

Powered off the RPi4;  disconnected all the USB components (except keyboard and 
mouse) that were attached to it; replaced the old SD card with the one I had 
just created; and re-applied power.  It booted and gave me a console login 
prompt.

Logged in as "root" (As shipped, the root account has no password); changed the 
root password to something slightly less insecure.  Created a user account and 
verified that I could use the user account to ssh to the RPi from another 
computer.  Thus verifying that the system had drivers for the RJ45 ethernet 
port.

Ran "apt update && apt upgrade" which worked fine. 

Noticed that the system as shipped is very "bare bones", so I was glad that apt 
worked and I could install several utilities I would need later.

Since one of my goals is to run this as an NTP server, I was somewhat surprised 
to note that "hwclock" didn't work (Missing driver, maybe?) :
root@pi:~# hwclock --verbose --show
hwclock from util-linux 2.33.1
System Time: 1613889592.600667
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

root@pi:~# ls -l /dev/rtc*
ls: cannot access '/dev/rtc*': No such file or directory

What package should I file a bug report against for this problem?

That's it for now.  Next I'll try the "2021.02.10   11 (Bullseye)   4"
image.

Enjoy!
Rick

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Rick Thomas]

Thanks, yes that does help a lot.  

I'm always amazed by the helpfulness and depth of knowledge shown by the folks 
on the Debian lists!
Rick

On Sat, Feb 20, 2021, at 11:22 AM, Diederik de Haas wrote:
> On zaterdag 20 februari 2021 13:46:00 CET Rick Thomas wrote:
> > Hmmm...   The "tested images" page [1] lists images for both Buster and
> > Bullseye that reportedly boot on the RPi 0W.  I don't know what they had to
> > do to make it work.  They're cheap enough that I may just buy one and try
> > it, for fun.
> 
> What Ian said is entirely correct.
> The images for the Pi 0/0w/1 are build from raspi_1_bullseye.yaml (for 
> Bullseye ofc) and use armel
> The images for RPi 2 use armhf
> The images for RPi 3 and 4 use arm64
> 
> On zaterdag 20 februari 2021 12:27:34 CET Matthias Klein wrote:
> > The prebuild images use the armel baseline:
> > https://salsa.debian.org/raspi-team/image-specs/-/blob/master/Makefile#L70
> 
> And Matthias pointed to the solution that was taken for the 'tested images'.
> (Responding as your question came after Matthias posted his response)
> 
> HTH
> 
> Attachments:
> * signature.asc

OT: SBBR Broadcom etc [New Subject]

[Rick Thomas]

Please continue this discussion under a different Subject.  It has nothing to 
do with my original question.

Thanks!
Rick

On Sat, Feb 20, 2021, at 4:18 AM, Pete Batard wrote:
> Hi Luke,
> 
> On 2021.02.20 04:16, Luke Kenneth Casson Leighton wrote:
> > 
> > 
> > On Friday, February 19, 2021, Pete Batard  > > wrote:
> > 
> >  > Why, when it is absolutely possible to achieve it, as was 
> > demonstrated on a cheap platform like the Pi (that actually comes with 
> > horrible quirks to be able to accomplish so, especially in terms of xHCI 
> > support), should end users have to juggle with heteroclitic means of 
> > configuring their system for OS installation?
> > 
> > because the product, designed by Broadcom, is not in the slightest bit 
> > targetted at end-users, and Broadcom do not give a flying f*** about 
> > such a tiny market of only 1 million a year in sales.  their profit 
> > margins are too small to bother with us.
> 
> I appreciate that you feel the desire to express your candid opinion.
> 
> But I am afraid you are shoehorning the topic in order to be able to do 
> so as this was never a discussion about specific SoC manufacturers.
> 
> This section was a discussion about how we used *whatever* ARM64 SoC 
> platform we saw as fitting (on account of it being cheap and widespread, 
> and nothing else) to demonstrate that SBBR is not just for vendors who 
> design server platforms and have a significant amount of resources.
> 
> > Broadcom's Minimum Order Quantity for these processors, which are 
> > designed for mass-volume IPTV, Set Top Box and other multimedia 
> > computing appliances, is 5 million units and above.
> 
> Irrelevant.
> 
> > Normally Broadcom would provide the full software stack for the customer 
> > placing 5, 10, 50, 100 million orders for a complete solution.  That 
> > customer *does not care* about the software boot process or some xHCI 
> > incompatibility.
> > 
> > Have people forgotten already that the only reason the original PI 
> > exists is because Eben Upton was an employee who, having access to 
> > normally NDA'd documentation, worked on the PCB in his spare time?  This 
> > was the only exception to Broadcom's normal MOQ rules, they could not 
> > exactly tell him to stop when he told them it was for educational 
> > purposes, could they?
> 
> Still irrelevant.
> 
> > please understand: the manufacturers of these SoCs consider you, all 
> > Free Software idiots (including me) to be an absolute nuisance.
> 
> Yes. We know.
> 
> But, and here's the kicker that you appear to ignore in order to go on 
> this tangent, we have demonstrated that one can *still* provide an SBBR 
> UEFI implementation for platforms where vendors are less than cooperative.
> 
> And this is kind of the point: If we could achieve it for a platform 
> where we got little cooperation (for the record, even if it's in their 
> interest, I wouldn't say that the Raspberry Pi Foundation are exactly 
> onboard with the SBBR effort, which may have to do with it having been 
> developed externally), then it means it should also be achievable for 
> others.
> 
> The point is: It is possible to get SBBR even from relatively 
> uncooperative vendors.
> 
> And the fact that Broadcom are, per your description, one of the less 
> friendly manufacturers when it comes to Open Source software helps bring 
> the point home.
> 
> But please understand, we could also have picked the manufacturer that's 
> friendliest for FLOSS, and it wouldn't have made much of a difference.
> 
> With the goal of demonstrating that you can pick this or that ARM64 SoC 
> based platform out there, and produce an SBBR-compliant UEFI firmware 
> for it, the choice or what platform was picked becomes largely 
> irrelevant and out of scope for this topic (except for the fact that it 
> coincided with the platform OP plans to use).
> 
> > i showed the manufacturers of my laptop the linux kernel boot process at 
> > Computex, they told me it looked like i was spying on their product!
> > 
> > we are "lapping at the heels" of these massive Corporations.  we are 
> > nothing to them.
> 
> I don't know who that "we" is, but if your idea is that the people who 
> are interested in showcasing SBBR went with a Broadcom-based platform, 
> with some desire to help their business, you are missing the mark.
> 
> Again, we, as developers of this specific SBBR showcase, couldn't have 
> cared less about the SoC manufacturer (as long as we could obtain a 
> minimum level of information to allow for development, as, obviously, 
> "we" can't do miracles for a fully closed platform) and could have 
> picked the Librest SoC implementation just as well, if it made a good 
> showcase.
> 
> But then, and that is part of the point, had we done just that, we 
> probably would have faced some pushback of "Well, your SBBR 
> implementation only works because the SoC manufacturer was open and 
> cooperative. But that's never going to work 

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Rick Thomas]

Hmmm...   The "tested images" page [1] lists images for both Buster and 
Bullseye that reportedly boot on the RPi 0W.  I don't know what they had to do 
to make it work.  They're cheap enough that I may just buy one and try it, for 
fun.
Rick

On Sat, Feb 20, 2021, at 2:10 AM, Ian Campbell wrote:
> On Fri, 2021-02-19 at 18:42 -0800, Rick Thomas wrote:
> > If I can get the Pi4 working with either of the Debian alternatives,
> > I will probably buy a Pi zero W as the actual replacement for the
> > Sheeva, and keep the Pi4 for experimentation.
> 
> I'm sure someone who follows rpi closer than I will correct if not, but
> isn't the whole Pi Zero range based the older ARMv6 (i.e. not armhf)
> processor which requires the Raspbian rebuild because it is not
> compatible with the armhf baseline used by Debian (and most other
> distros I think)?
> 
> If so then any experiments/learnings on a Pi4 (a full ARMv7 CPU
> supported by the arm64 Debian arch) with full Debian  aren't likely to
> be very transferable.
> 
> Ian.

[1] https://raspi.debian.net/tested-images/

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Rick Thomas]

If I can get the Pi4 working with either of the Debian alternatives, I will 
probably buy a Pi zero W as the actual replacement for the Sheeva, and keep the 
Pi4 for experimentation.

Enjoy!
Rick

Re: Debian Bullseye on Raspberry Pi 4 4GB?

[Rick Thomas]

On Thu, Feb 18, 2021, at 3:02 PM, Rick Thomas wrote:
> Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) 
> from a CD/DVD or USB Flash stick or uSDcard?
> 
> If so, where would I look for instructions for doing so?

A couple of folks have asked for clarification from the OP.  Well, as the OP 
here, I offer the following clarification of my goals for this project.

I recently bought a Raspberry Pi4 (4GB) to experiment with.  It's currently 
running Ubuntu 20.04.2 LTS, because at the time I was installing it, that was 
the closest distro I could find to a vanilla Debian.  It works pretty well and 
I'd be willing to stay with it for the long term if nothing better shows up.  
But, since I bought it to experiment with, I wondered if there was an 
experimental pure Debian installer I could test and report on my experiences.  
Sort of as a way of contributing back to the community that has been so helpful 
to me.

Meanwhile, in another part of the woods, I've been using a sheevaplug for 12 
years or so to serve DNS, DHCP, NTP and other  network services to my home 
network.  It's running Debian Buster at the moment.  I'm looking forward to 
upgrading it to Bullseye in the near future.  Which is fine, but I've heard 
tell that sheevaplug support is planned to be dropped in the release after 
Bullseye.

Which got me to thinking, maybe I could use the Raspberry Pi to replace the 
Sheevaplug when support is finally dropped.

So the goal in my OP is to find a bare-bones Debian-like (real Debian,  if 
possible) distro that I could install and administer to provide network 
services the way I'd been doing with the Sheevaplug.

The upshot is that my first attempt will be with one of the "ready-made" 
installation images, and see how much post-installation customization it 
allows.  Then I'll try the more conventional Debian Installer and see how that 
works.

I will, of course, share my experiences with the list.

Thanks for listening...
Rick

Debian Bullseye on Raspberry Pi 4 4GB?

[Rick Thomas]

Is it possible to install Debian Bullseye on a Raspberry Pi 4 (4GB) from a 
CD/DVD or USB Flash stick or uSDcard?

If so, where would I look for instructions for doing so?

ADVthANanksCE!
Rick

Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... No ethernet detected

[Rick Thomas]

On Fri, Jan 29, 2021, at 7:18 PM, Rick Thomas wrote:
> Hi!
> 
> On Fri, Jan 29, 2021, at 1:03 AM, Holger Wansing wrote:
> > On https://www.debian.org/devel/debian-installer/
> > you should look under the daily snapshots.
> > For armhf that would be
> > https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
> 
> I downloaded the two-part image from [1] dated 2021-01-30 and tried to 
> install it on my Cubox-i4.
> 
> It booted fine but when it got to the "Detect network hardware" phase, 
> it failed and said:
> 
> No Ethernet card was detected. If you know the name of the driver 
> needed by your Ethernet card, you can select it from the list. 
> Driver needed by your Ethernet card:  
> and gave a long list of available ethernet drivers.
> 
> I couldn't find anything that looked like an Atheros 8035 driver, which 
> seems to be the one in use when I boot with a working system.
> 
> Any suggestions?
> Thanks!
> Rick
> 
> [1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
>  dated 2021-01-30

I tried it again, this time with the components dated 2021-02-06 (today).
I was hoping that the problem was transient and might have been fixed in the 
intervening week, but I still got the same result: "No Ethernet card was 
detected."

Do I need to file a bug report?  If so, to which package?  If I do, is there 
any chance it will be fixed before Bullseye is released into the wild?
Is there a known workaround that I can apply?

Thanks for any help!
Rick

Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... No ethernet detected

[Rick Thomas]

Hi!

On Fri, Jan 29, 2021, at 1:03 AM, Holger Wansing wrote:
> On https://www.debian.org/devel/debian-installer/
> you should look under the daily snapshots.
> For armhf that would be
> https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/

I downloaded the two-part image from [1] dated 2021-01-30 and tried to install 
it on my Cubox-i4.

It booted fine but when it got to the "Detect network hardware" phase, it 
failed and said:

No Ethernet card was detected. If you know the name of the driver 
needed by your Ethernet card, you can select it from the list. 
Driver needed by your Ethernet card:  
and gave a long list of available ethernet drivers.

I couldn't find anything that looked like an Atheros 8035 driver, which seems 
to be the one in use when I boot with a working system.

Any suggestions?
Thanks!
Rick

[1] https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/
 dated 2021-01-30

Re: Installing Debian Buster on Cubox-i4 with eSATA drive.

[Rick Thomas]

On Thu, Jan 28, 2021, at 12:08 AM, Rick Thomas wrote:
> On Wed, Jan 27, 2021, at 11:15 PM, Vagrant Cascadian wrote:
> > On 2021-01-27, Rick Thomas wrote:
> > > I'm trying to install Debian Buster [1] on my Cubox-i4P with an eSATA
> > > drive. Everything seems to be fine, but when it comes time to reboot,
> > > it boots into the installer again, rather than the installed system.
> > >
> > > Here's what I did, and what I observed:
> > >
> > > *) I downloaded the two parts of the SDcard install image from [1] and 
> > > followed the instructions in the README to create a 4GB (I didn't have 
> > > anything smaller) SDcard installer.
> > > *) I connected the eSATA disk and plugged the SDcard into the Cubox and 
> > > powered it up.
> > > *) It booted off the SD-card into the installer as expected.
> > ...
> > > *) But when the reboot happened, I found myself back in the installer.
> > > *) I tried removing the SDcard and rebooting, but it failed to boot -- 
> > > after power-on nothing happened.
> > 
> > > What I hoped would happen with the eSATA drive was that the installer
> > > would write the boot firmware (u-boot, etc) to the SDcard, and
> > > configure it to get /boot, root, /home, swap off the eSATA.
> > 
> > U-boot can only be loaded from microSD on that platform, as far as I'm
> > aware.
> > 
> > You can use the bootloader from the installer image, just delete the
> > boot.scr and/or extlinux.conf from the partition on the installer image,
> > or make another partition on the microSD card, and mark it bootable, but
> > don't put anything on it. Then u-boot should fall back to loading the
> > kernel+initrd+device-tree off of the eSATA.
> > 
> > If you interrupt the boot process and get to a u-boot prompt, you should
> > be able to see the order of devices u-boot tries to boot from with:
> > 
> >   printenv boot_targets
> > 
> > 
> > Now that bullseye is in the early phases of freeze, please consider
> > testing bullseye, too, if you can! :)
> 
> Thanks!  This sounds like it ought to work.  I'll give it a try.
> 
> For bullseye, where should I download the latest installer image from?  
> I'd love to give it a try as well!
> Rick

That worked!

Specifically, what I did was:
*) on a different machine, I mounted the installer SDcard first partition
*) renamed boot.scr to oboot.scr
*) sync and umount the SDcard.
*) inserted it in the Cubox
*) powered up and watched it boot from the eSATA disk.

Whoopie!

Observations:
*) => printenv boot_targets
   boot_targets=mmc0 sata0 usb0 pxe dhcp

*) It located the /boot partition on the eSATA drive without any help from me.  
I assume that means it goes down the list of boot_targets one by one looking 
for an active bootable partition containing a file called "boot.scr" which it 
then executes to perform the remainder of the boot process (mostly to load the 
kernel and initrd , then pass control to them).

*) I wonder if it would be possible to change the "boot_targets" environment 
variable to put "sata0" first?  Would that work, if it could be done?  If that 
were done, would it mess up booting from the SDcard when there was no eSATA 
drive?

So now, the next question is: how do we convince the debian installer to 
recognize that it's installing to the eSATA drive and either set "boot_targets" 
appropriately, or mark the boot partition on the SDcard as not bootable.

I've added "debian-boot" to the CC list of this email.  Should I file a bug 
report?  If so, what package should I file it against?

Next thing to test -- can I install bullseye the same way?

Thanks very much to everyone for all your help!
Rick

Re: Installing Debian Buster on Cubox-i4 with eSATA drive.

[Rick Thomas]

On Wed, Jan 27, 2021, at 11:15 PM, Vagrant Cascadian wrote:
> On 2021-01-27, Rick Thomas wrote:
> > I'm trying to install Debian Buster [1] on my Cubox-i4P with an eSATA
> > drive. Everything seems to be fine, but when it comes time to reboot,
> > it boots into the installer again, rather than the installed system.
> >
> > Here's what I did, and what I observed:
> >
> > *) I downloaded the two parts of the SDcard install image from [1] and 
> > followed the instructions in the README to create a 4GB (I didn't have 
> > anything smaller) SDcard installer.
> > *) I connected the eSATA disk and plugged the SDcard into the Cubox and 
> > powered it up.
> > *) It booted off the SD-card into the installer as expected.
> ...
> > *) But when the reboot happened, I found myself back in the installer.
> > *) I tried removing the SDcard and rebooting, but it failed to boot -- 
> > after power-on nothing happened.
> 
> > What I hoped would happen with the eSATA drive was that the installer
> > would write the boot firmware (u-boot, etc) to the SDcard, and
> > configure it to get /boot, root, /home, swap off the eSATA.
> 
> U-boot can only be loaded from microSD on that platform, as far as I'm
> aware.
> 
> You can use the bootloader from the installer image, just delete the
> boot.scr and/or extlinux.conf from the partition on the installer image,
> or make another partition on the microSD card, and mark it bootable, but
> don't put anything on it. Then u-boot should fall back to loading the
> kernel+initrd+device-tree off of the eSATA.
> 
> If you interrupt the boot process and get to a u-boot prompt, you should
> be able to see the order of devices u-boot tries to boot from with:
> 
>   printenv boot_targets
> 
> 
> Now that bullseye is in the early phases of freeze, please consider
> testing bullseye, too, if you can! :)

Thanks!  This sounds like it ought to work.  I'll give it a try.

For bullseye, where should I download the latest installer image from?  I'd 
love to give it a try as well!
Rick

Installing Debian Buster on Cubox-i4 with eSATA drive.

[Rick Thomas]

I'm trying to install Debian Buster [1] on my Cubox-i4P with an eSATA drive. 
Everything seems to be fine, but when it comes time to reboot, it boots into 
the installer again, rather than the installed system.

Here's what I did, and what I observed:

*) I downloaded the two parts of the SDcard install image from [1] and followed 
the instructions in the README to create a 4GB (I didn't have anything smaller) 
SDcard installer.
*) I connected the eSATA disk and plugged the SDcard into the Cubox and powered 
it up.
*) It booted off the SD-card into the installer as expected.
*) Everything went as expected, until it got to the partition-disks phase.
*) I chose to use the eSATA disk as the installation target.  I told it to use 
the whole disk and use the LVM method of partitioning.
*) It created the /boot ext2 partition in /dev/sda1 and put root, /home and 
swap in the LVM on /dev/sda5.  This is (I think) exactly what I wanted.
*) There was no mention of the SDcard /dev/mmcblk1 (except when initially 
choosing the target disk -- I did explicitly NOT choose it at this time)
*) I allowed it to wipe and re-partition the eSATA disk, which it did without 
incident.
*) Everything proceeded as expected.  I chose a minimal (ssh and base packages) 
in tasksel.
*) When it came to "make it bootable" I said go ahead.  There was no mention of 
/dev/mmcblk1 at this stage.
*) It proceeded from there without any apparent errors.
*) When it came time to reboot, I said go ahead.
*) But when the reboot happened, I found myself back in the installer.
*) I tried removing the SDcard and rebooting, but it failed to boot -- after 
power-on nothing happened.

What I hoped would happen with the eSATA drive was that the installer would 
write the boot firmware (u-boot, etc) to the SDcard, and configure it to get 
/boot, root, /home, swap off the eSATA.

What I suspect has happened is that the boot firmware (u-boot, etc) was written 
to the eSATA drive and so it can't be found by the power-up routine without 
some reconfiguration to tell it to look at the eSATA, but that isn't happening.

Anybody know what I can do to either:
1) Tell the power-up routines to look at the eSATA?
   or
2) Write the boot firmware to the SD card and configure it to get the rest of 
the system from the eSATA?

Debug logs were saved, and can be provided upon request.

Thanks in advance for any help!
Rick

PS:   In a previous attempt, I used a 64GB SDcard without the eSATA disk -- 
putting everything onto the SDcard.  That worked fine (It put the boot stuff on 
the SDcard) but it's horribly slow due to the very low speed of data transfer 
to and from the SDcard.

[1] 
http://http.us.debian.org/debian/dists/bullseye/main/installer-armhf/current/images/netboot/SD-card-images/

Re: SheevaPlug, hctosys: unable to open rtc device, after Buster upgrade

[Rick Thomas]

> On Sep 30, 2019, at 12:41 AM, Alexandre Belloni 
>  wrote:
> 
> My opinion is that distributions should stop relying on HCTOSYS and do
> the RTC read from userspace. This is especially important because
> distros are hardcoding rtc0 as the RTC to read from which is most likely
> to not be the correct one on any embedded device.
> 
> This is not Lennart's opinion though:
> https://lkml.org/lkml/2019/8/14/248
> 
> He later dismisses your use case in:
> https://lkml.org/lkml/2019/8/14/454
> 
> "I'd argue that in the vast majority of cases the person building the
> kernel for a device knows very well which RTC is connected to the
> device they are interested in, and should just build that driver in,
> and don't bother with userspace complexity, later userspace module
> loading or anything like that."
> 
> -- 
> Alexandre Belloni, Bootlin

Lennart’s argument fails, however, if you are on a machine like the Raspberry 
Pi where the hardware clock (and its driver) are provided (or not) by the 
end-user (or the supplier who sold them the clock) In that case, there’s no way 
for the kernel to know at compile time what clock is installed.

Another case where this argument falls down is the Cubox-iPro which has two 
hardware clocks.  The first, labeled /dev/rtc0 by the Debian kernel, is 
accurate as long as the power is up, but it has no battery backup, so when the 
power fails they clock fails as well.  The second, labeled /dev/rtc1 by Debian, 
has an optional battery backup, so it can (but may not depending on whether the 
battery is installed) ride thru a power failure.  It’s a user option whether to 
install the battery, so again, not something the kernel can know at compile 
time.

Rick

Re: SheevaPlug, hctosys: unable to open rtc device, after Buster upgrade

[Rick Thomas]

Thanks for the explanation!

> On Sep 30, 2019, at 12:22 AM, Uwe Kleine-König  wrote:
> 
> IIRC systemd-timesyncd fast forwards the time at boot time to be not
> earlier than before the last shutdown. Maybe this is not active for you?
> (There is
> /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
> on my system that disables timesyncd when ntpd or similar software is
> installed.)

Ahhh… So the fact that I have ntp installed is what’s saving me?

FWIW, I also have fake-hwclock installed on tis machine.  I don’t recall 
exactly what made me do that, but maybe I was already having this problem back 
then, and solved it that way?

Curiouser and curiouser, cried Alice!
Rick

PS:  So AIUI from your explanation, under systemd the setting of the system 
clock from the hardware clock is being done in the kernel, and not in user 
space at all?  Was this (moving it out of user space) done to get the clock set 
before the first entries were written to the system log?  Or am I missing 
something…

Enjoy!

Re: SheevaPlug, hctosys: unable to open rtc device, after Buster upgrade

[Rick Thomas]

> On Sep 29, 2019, at 1:05 PM, Uwe Kleine-König  wrote:
> 
> The step from 4.19.67-2 to 4.19.67-2+deb10u1 is harmless for this
> problem. The issue that John is describing comes from a change by Roger
> Shimizu to reduce the kernel size[1]. I guess there is some difference
> in userspace that is relevant for the problem not occuring for Rick.
> https://bugs.debian.org/855203 seems relevant here.
> 
>>> yet installed on this machine.  I think I’ll hold off on installing
>>> that update for a while!
>>> 
>>> And, FWIW:
>>> 
>>> rbthomas@sheeva:~$ grep RTC_DRV_CMOS /boot/config-4.19.0-6-marvell
>>> CONFIG_RTC_DRV_CMOS=m
> 
> Note that CONFIG_RTC_DRV_CMOS isn't relevant for the Sheevaplug. The
> relevant symbol is CONFIG_RTC_DRV_MV there.

So here’s what I get for that:
rbthomas@sheeva:~$ grep RTC_DRV_MV /boot/config-4.19.0-6-marvell
CONFIG_RTC_DRV_MV=m

> I wonder if it would be sensible to implement the logic for hctosys
> (the "during boot" part that is) in rtc_register instead. This way it
> would not trigger to early if the relevant driver was modular (as is the
> case here).

Could you fill in the details a bit more here?  I assume this is something to 
do with the systemd way of initializing the system, which I’m afraid I don’t 
understand as well as I probably should… please forgive my ignorance!

In particular, where/when is the “hwclock hctosys” being done during boot 
currently?  And where/when would it be done under your proposal?

And, finally, would the suggested change work for other types of hardware than 
armel?


Thanks for your help!
Rick

Re: SheevaPlug, hctosys: unable to open rtc device, after Buster upgrade

[Rick Thomas]

I do not have this problem on my sheevaplug running kernel ‘4.19.67-2’ .  I see 
that ‘4.19.67-2+deb10u1’ is available, but not yet installed on this machine.  
I think I’ll hold off on installing that update for a while!

And, FWIW:

rbthomas@sheeva:~$ grep RTC_DRV_CMOS /boot/config-4.19.0-6-marvell
CONFIG_RTC_DRV_CMOS=m


Rick

> On Sep 28, 2019, at 1:14 PM, John Blake  wrote:
> 
> After upgrading my Sheevaplug from Stretch to Buster, it would not set the 
> system time from the RTC at boot.  Here is what I see in dmesg output:
> 
> (kernel 4.19.67-2+deb10u1)
> # dmesg | grep rtc
> [2.088797] hctosys: unable to open rtc device (rtc0)
> [2.535171] rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
> 
> This results in the system time being way off until after NTP starts and 
> syncs.
> 
> If I revert to the kernel from Stretch, it works fine:
> 
> (kernel 4.9.168-1+deb9u5)
> # dmesg | grep rtc
> [2.205994] rtc-mv f1010300.rtc: rtc core: registered f1010300.rtc as rtc0
> [2.238801] rtc-mv f1010300.rtc: setting system clock to 2019-09-07 
> 22:51:49 UTC (1567896709)
> 
> Does anyone know if there is a fix or workaround for this?  I searched the 
> web for this problem and found where someone (on archlinux) had a similar 
> problem, his workaround being to change kernel .config 
> "CONFIG_RTC_DRV_CMOS=m" to "CONFIG_RTC_DRV_CMOS=y" and compile a custom 
> kernel.  It seems to me there should be a simpler solution.
> 
> Thanks in advance for any help,
> John B.
> 

Re: heatsink -- was [Re: Raspberry Pi 4 is announced]

[Rick Thomas]

> On Jun 29, 2019, at 11:51 PM, andreimpope...@gmail.com wrote:
> 
> On Sb, 29 iun 19, 02:18:44, Alan Corey wrote:
>> Thank you, I hadn't looked at that.  So there's Debian for it, not
>> just Ubuntu?  
> 
> I'm only concerned with u-boot/Linux mainline support, as I don't like 
> using vendor provided images.
> 
> Kind regards,
> Andrei
> -- 
> http://wiki.debian.org/FAQsFromDebianUser

Understood.  And thank you for your work!

But the question remains:  Is there a Debian version that runs on the ODroid N2?
And a second question:  Is there likely to be a Debian version for the 
RaspberryPi 4B?

Thanks!
Rick

heatsink -- was [Re: Raspberry Pi 4 is announced]

[Rick Thomas]

So when I buy one of these in a couple of months, do I need to buy the heatsink 
too?  Will the heatsink fit into the standard case?  If not, is there a case 
that will fit?

And, finally, is there a version of Debian that will run on one of these?  Or 
should I just plan on running Raspbian?

Thanks!
Rick

> On Jun 28, 2019, at 12:32 PM, Alan Corey  wrote:
> 
> No big surprise there.  Something about 1500 more on 7/4.  I got on
> the list to get emailed when they get them.  Oh well, time to get
> adapters ordered, and a different power supply.  Looks like they built
> it to bolt a heat sink onto, there's free space around the CPU.
> 
> The real announcement page:
> https://www.raspberrypi.org/products/raspberry-pi-4-model-b/
> 
> On 6/28/19, Mauricio Tavares  wrote:
>> On Fri, Jun 28, 2019 at 2:57 PM Alan Corey  wrote:
>>> 
>>> Tech specs at Element14
>>> https://www.element14.com/community/docs/DOC-92643/l/meet-the-new-raspberry-pi-4-model-b-with-technical-specifications?CMP=e-email-ADH-e14-NA-280619-RPITechSpec-H_tok=eyJpIjoiTldRNE56VTJOVGxqWldabCIsInQiOiIyMllcLzZiS2FQb1NpVWt6Q2pkamNnUTVXSThMTGtISWJMZWVRXC9XQVlOWEFLa3dSMGNIMVA4VGdpWTZTRVlhN0ZZd2t5QysrVFF1Mm80WEpjQmxZVEsya0FyeVRYcTR0Z3pPN3hTMXdzY01UNnVFN0FiTW8zRTBYYzl6SjJESmhsIn0%3D
>>> 
>>> Up to 4 GB RAM, gigbit ethernet, dual micro-HDMI, dual-band wifi,
>>> OpenGL ES 1.1, 2.0, 3.0, 2 USB 3.0 ports (+ 2 USB 2.0), Broadcom 2711,
>>> Quad-core Cortex-A72 64-bit SoC @ 1.5 GHz
>>> 
>>> Element14 doesn't have them in stock yet but the 4 GB is listed at
>>> $55.  Sounds like a Rock64 killer
>>> 
>>  I think they have been out of stock since Monday. Sold out quickly
>> 
>>> --
>>> -
>>> No, I won't  call it "climate change", do you have a "reality problem"? -
>>> AB1JX
>>> Cities are cages built to contain excess people and keep them from
>>> cluttering up nature.
>>> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>>> 
>> 
> 
> 
> -- 
> -
> No, I won't  call it "climate change", do you have a "reality problem"? - 
> AB1JX
> Cities are cages built to contain excess people and keep them from
> cluttering up nature.
> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
> 

Re: Debian Installer on Pine64+ (no serial console)

[Rick Thomas]

Hi Andrei,

Did you get any answer on this?  I’m thinking of replacing my armel hardware (a 
couple of OpenRD boxes and a SheevaPlug) with something more modern, and the 
Pine64+ looks like a good candidate, but I’ll need to be able to install Debian.

More general question —  What is the status of support for the ARM64 at this 
point in time?  Is there an on-going project that I can help test?

Thanks!
Rick

> On May 1, 2019, at 9:27 AM, Andrei POPESCU  wrote:
> 
> [I seem to recall a previous discussion about this but can't find it 
> anymore]
> 
> Hi,
> 
> I've been trying to install Debian on the Pine64+ using the Debian 
> Installer (Buster RC1).
> 
> This is mostly for educational/backup purposes as I already have a 
> working buster installed with debootstrap.
> 
> To make things more interesting, I don't have serial console, only a 
> HDMI screen (TV), USB keyboard and internet access.
> 
> Steps
> 
> 1. Write pine64_plus.img.gz to an SD card
> 2. Write an .iso to a USB stick (I used the netinst)
> 3. Boot from the SD card with the USB stick inserted
> 
> The system boots, successfully probes the USB stick and displays the 
> GRUB menu on the HDMI output (with some strange characters instead of 
> bars, but still readable).
> 
> At this point I'm stuck because the USB keyboard is not active 
> (something missing in GRUB?) and GRUB has no timeout.
> 
> As the filesystem on the stick is ISO9660 I also don't know of an easy 
> method to edit /boot/grub/grub.cfg to add a timeout (I'm assuming the 
> USB keyboard will work as soon as the D-I kernel is booted).
> 
> In theory it should also be possible (and nicer) to just create some 
> filesystem on the SD card (writing the image already creates a 
> partition) and copy the necessary files to start D-I there (which 
> ones?).
> 
> Suggestions?
> 
> Kind regards,
> Andrei
> -- 
> http://wiki.debian.org/FAQsFromDebianUser

Re: How to activate wi-fi on Cubox-i4Pro armhf

[Rick Thomas]

> On Mar 22, 2019, at 9:08 AM, Dominique Dumont  wrote:
> 
> On Saturday, 16 March 2019 03:37:21 CET Rick Thomas wrote:
>> I tried installing the “non-free” firmware package for it 
>> (firmware-brcm80211) 
> but I get this message at boot time on the console:
>>> [   21.050008] brcmfmac mmc0:0001:1: firmware: failed to
>>> loadbrcm/brcmfmac4330-sdio.txt (-2) [   22.067483] brcmfmac:
>>> brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797779
> 
> HTH

Thanks, Dominique!  Yes, that explains a lot.

I guess the conclusion is that Debian does not support wi-fi on these machines. 
 Though the framework for support is there, if the appropriate extremely 
hardware specific firmware blob can be located.  I guess it’s something to take 
up with the manufacturer of the board.

Enjoy!
Rick

Re: How to activate wi-fi on Cubox-i4Pro armhf

[Rick Thomas]

> On Mar 17, 2019, at 9:06 AM, Christopher Barry  wrote:
> 
> On Fri, 15 Mar 2019 19:37:21 -0700
> Rick Thomas  wrote:
> 
>> Does anybody know the magic for getting the wifi on a Cubox-i4Pro to
>> work?
>> 
>> I tried installing the “non-free” firmware package for it
>> (firmware-brcm80211) but I get this message at boot time on the
>> console:
>> 
>>> [   21.050008] brcmfmac mmc0:0001:1: firmware: failed to
>>> loadbrcm/brcmfmac4330-sdio.txt (-2) [   22.067483] brcmfmac:
>>> brcmf_sdio_htclk: HT Avail timeout (100): clkctl 0x50  
>> 
>> I’ve searched for a file by the name of
>>   brcm/brcmfmac4330-sdio.txt
>> and all I can find is
>>   /lib/firmware/brcm/brcmfmac4330-sdio.bin
>> 
>> Am I missing something, or is this a bug?
>> 
>> Thanks for any help!
>> Rick
> 
> 
> Maybe this can be of help:
> https://unix.stackexchange.com/questions/328001/trouble-activating-the-sdio-broadcom-bcm43430-wifi-chip-on-linux-4-8-0#411293

Hi Christopher.  Thanks for the reply.

That link leads to another link which has lots of Broadcom files, but none that 
end in “.txt”
It also warns that there are multiple versions of the chip and the “.txt” files 
are specific to the board as well.

The more I learn, the less I know…  Does anyone know more about the Wifi 
implementation on the Cubox devices?

Thanks for any help you can give!
Rick

How to activate wi-fi on Cubox-i4Pro armhf

[Rick Thomas]

Does anybody know the magic for getting the wifi on a Cubox-i4Pro to work?

I tried installing the “non-free” firmware package for it (firmware-brcm80211) 
but I get this message at boot time on the console:

> [   21.050008] brcmfmac mmc0:0001:1: firmware: failed to 
> loadbrcm/brcmfmac4330-sdio.txt (-2)
> [   22.067483] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (100): clkctl 
> 0x50

I’ve searched for a file by the name of
brcm/brcmfmac4330-sdio.txt
and all I can find is
/lib/firmware/brcm/brcmfmac4330-sdio.bin

Am I missing something, or is this a bug?

Thanks for any help!
Rick

Re: How do I find out where u-boot environment is stored?

[Rick Thomas]

> On Mar 6, 2019, at 7:46 PM, Vagrant Cascadian  wrote:
> 
> On 2019-03-06, Rick Thomas wrote:
>> Anybody know how can I determine where u-boot is storing it’s environment?
>> Is there an environment variable where that info is stored?
>> (-: Any ironic self-reference in the previous question is entirely 
>> un-intentional… ;-)
> 
> At least for recent u-boot packages in Debian:
> 
>  $ zgrep ^C.*ENV_IS_IN /usr/share/doc/u-boot-*/configs/config.*
>  
> /usr/share/doc/u-boot-sunxi/configs/config.a64-olinuxino.gz:CONFIG_ENV_IS_IN_FAT=y
>  
> /usr/share/doc/u-boot-sunxi/configs/config.pine64_plus.gz:CONFIG_ENV_IS_IN_FAT=y
>  /usr/share/doc/u-boot-sunxi/configs/config.pinebook.gz:CONFIG_ENV_IS_IN_FAT=y
> 
> To get more detailed information, you may need to read the source for
> the relevent board.
> 
> 
> live well,
>  vagrant

So on my Cubox-i4Pro, for example, it says:

rbthomas@cube:~$ zgrep ^C.*ENV_IS_IN 
/usr/share/doc/u-boot-imx/configs/config.mx6cuboxi.gz 
CONFIG_ENV_IS_IN_MMC=y

Which confirms that the environment is stored on the mmc/SD card.
But where (at what address) on the mmc card is it stored?

Is that something I’d have to read the code for?
If so, can you point me to the relevant code file?

Thanks for your help!
Rick

How do I find out where u-boot environment is stored?

[Rick Thomas]

Anybody know how can I determine where u-boot is storing it’s environment?
Is there an environment variable where that info is stored?
(-: Any ironic self-reference in the previous question is entirely 
un-intentional… ;-)

Thanks!
Rick

Re: fw_printenv says "Warning: Bad CRC, using default environment"

[Rick Thomas]

On Tue, Feb 26, 2019, at 3:34 PM, Vagrant Cascadian wrote:
> On 2019-02-26, Rick Thomas wrote:
> >> On Feb 26, 2019, at 10:49 AM, Vagrant Cascadian  wrote:
> >> 
> >> On 2019-02-26, Rick Thomas wrote:
> >>> On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools
> >>> package) it says “Warning: Bad CRC, using default environment”.
> ...
> >> fw_printenv will only work if there's an environment saved; it doesn't
> >> read from u-boot’s built-in defaults.
> >
> > So, if fw_printenv can’t see the environment that’s actually in use,
> > what tool do you recommend for examining the u-boot environment from
> > Linux?
> 
> I don't recommend using a tool from linux. Boot into u-boot and run
> "printenv".
> 
> 
> >> I generally recommend to avoid using "saveenv" and "fw_saveenv", since
> >> most modern boards work with distro_bootcmd and there are various
> >> options to configure the system at boot, such as boot scripts.
> >
> > I presume you mean “fw_setenv” (there doesn’t seem to any “fw_saveenv”
> > command in the “u-boot-tools” package)?
> 
> Correct.
> 
> >> Having a saved environment means you're stuck with whatever environment
> >> variables were present when you last ran "saveenv", which means any bugs
> >> fixed in newer versions of u-boot will still be present, and worst case,
> >> they might even be incompatible with the version of u-boot you're
> >> running. It will also happily save auto-detected variables.
> >> 
> >> Additionally, "fw_saveenv" may require you to specify the entire
> >> environment to save, rather than just values you want to change.
> >
> > So please help me understand this… If “saveenv” under u-boot is
> > dangerous, and “fw_setenv” under Linux should not be used, what’s the
> > purpose of having a persistent environment at all?  Is it just a
> > historical relic that has outlived it’s usefulness; or am I missing
> > something subtle (more likely)?
> 
> There are valid uses of it, and if you know exactly what you're doing,
> that's fine.
> 
> In general, I think it's better to use other methods to adjust the
> environment at run-time (e.g. boot scripts).
> 
> 
> >>> A couple of more data points that may shed light on this:
> >>> 
> >>>> root@cube:~# cat /etc/fw_env.config 
> >>>> # Configuration file for fw_(printenv/saveenv) utility.
> >>>> # Up to two entries are valid, in this case the redundant
> >>>> # environment sector is assumed present.
> >>>> #
> >>>> # XXX this configuration might miss a fifth parameter for the "Number of
> >>>> # sectors"
> >>>> 
> >>>> # MTD device name   Device offset   Env. size   Flash sector size
> >>>> /dev/mmcblk1p10x8 0x2000
> >> 
> >> This looks like a bug in your configuration; it should specify the raw
> >> device rather than a partition.
> >
> > This is “fresh out of the box” configuration.  I haven’t changed a
> > thing.  So, if this is wrong (which it clearly is) should I be
> > reporting it as a bug in the “u-boot-tools” package?  Where did this
> > file come from?  It doesn’t seem to be present in either of the
> > “u-boot-tools” or “u-boot-imx” packages according to “dpkg-query -L”.
> 
> None of the u-boot packages install anything into /etc, so it's not a
> bug in any of the u-boot packages. If something else installed it
> without user intervention, it might be a bug in that package, but
> whatever did it doesn't appear to be in any package in Debian:
> 
>   https://codesearch.debian.net/search?q=fw_env.config
> 
> 
> >>>> root@cube:~# cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config 
> >>>> # Configuration file for fw_(printenv/saveenv) utility.
> >>>> # Up to two entries are valid, in this case the redundant
> >>>> # environment sector is assumed present.
> >>>> #
> >>>> # XXX this configuration might miss a fifth parameter for the "Number of
> >>>> # sectors"
> >>>> 
> >>>> # MTD device name   Device offset   Env. size   Flash sector size
> >>>> /dev/mmcblk00x8 0x2000
> >>> 
> >>> FWIW the micro-SD card on this box is identified as /dev/mmcblk1 — not
> >>> as either /dev/mmcblk0 or /dev/mmcblk1p1.
> >> 
> >> Between versions of linux and u-boot 

Re: fw_printenv says "Warning: Bad CRC, using default environment"

[Rick Thomas]

> On Feb 26, 2019, at 10:49 AM, Vagrant Cascadian  wrote:
> 
> On 2019-02-26, Rick Thomas wrote:
>> On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools
>> package) it says “Warning: Bad CRC, using default environment”.
> 
> If when booting, it also gives you this message, that would suggest you
> have no saved environment for fw_printenv to read from, as it's using
> the default environment. I recommend not using "saveenv" or "fw_saveenv"
> for reasons described below...
> 
> 
>> The “default environment” is clearly *not* the environment that u-boot
>> is using to boot the box.  At least the “ethaddr” variable in that
>> environment is clearly a fake one as show here:
>> 
>>> root@cube:~# fw_printenv ethaddr
>>> Warning: Bad CRC, using default environment
>>> ethaddr=00:00:11:22:33:44
>> 
>> This is definitely not the ethernet address that the box is using for dhcp.
> 
> fw_printenv will only work if there's an environment saved; it doesn't
> read from u-boot’s built-in defaults.

So, if fw_printenv can’t see the environment that’s actually in use, what tool 
do you recommend for examining the u-boot environment from Linux?

> 
> I generally recommend to avoid using "saveenv" and "fw_saveenv", since
> most modern boards work with distro_bootcmd and there are various
> options to configure the system at boot, such as boot scripts.

I presume you mean “fw_setenv” (there doesn’t seem to any “fw_saveenv” command 
in the “u-boot-tools” package)?

> Having a saved environment means you're stuck with whatever environment
> variables were present when you last ran "saveenv", which means any bugs
> fixed in newer versions of u-boot will still be present, and worst case,
> they might even be incompatible with the version of u-boot you're
> running. It will also happily save auto-detected variables.
> 
> Additionally, "fw_saveenv" may require you to specify the entire
> environment to save, rather than just values you want to change.

So please help me understand this… If “saveenv” under u-boot is dangerous, and 
“fw_setenv” under Linux should not be used, what’s the purpose of having a 
persistent environment at all?  Is it just a historical relic that has outlived 
it’s usefulness; or am I missing something subtle (more likely)?

>> A couple of more data points that may shed light on this:
>> 
>>> root@cube:~# cat /etc/fw_env.config 
>>> # Configuration file for fw_(printenv/saveenv) utility.
>>> # Up to two entries are valid, in this case the redundant
>>> # environment sector is assumed present.
>>> #
>>> # XXX this configuration might miss a fifth parameter for the "Number of
>>> # sectors"
>>> 
>>> # MTD device name   Device offset   Env. size   Flash sector size
>>> /dev/mmcblk1p10x8 0x2000
> 
> This looks like a bug in your configuration; it should specify the raw
> device rather than a partition.

This is “fresh out of the box” configuration.  I haven’t changed a thing.  So, 
if this is wrong (which it clearly is) should I be reporting it as a bug in the 
“u-boot-tools” package?  Where did this file come from?  It doesn’t seem to be 
present in either of the “u-boot-tools” or “u-boot-imx” packages according to 
“dpkg-query -L”.

>>> root@cube:~# cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config 
>>> # Configuration file for fw_(printenv/saveenv) utility.
>>> # Up to two entries are valid, in this case the redundant
>>> # environment sector is assumed present.
>>> #
>>> # XXX this configuration might miss a fifth parameter for the "Number of
>>> # sectors"
>>> 
>>> # MTD device name   Device offset   Env. size   Flash sector size
>>> /dev/mmcblk00x8 0x2000
>> 
>> FWIW the micro-SD card on this box is identified as /dev/mmcblk1 — not
>> as either /dev/mmcblk0 or /dev/mmcblk1p1.
> 
> Between versions of linux and u-boot the numbering of the devices may
> vary. In general, the numbering of such devices has gotten more stable
> over time, but it’s totally plausible that device numbers may vary.

Ah… I see.  Would it make sense to note this fact in the comments?

>> Does this represent a bug in u-boot-tools, or am I mis-interpreting
>> something?
> 
> My guess is just your misconfiguration above, and hopefully that you
> have no saved environment for the tools to read from.

As it turns out, I did do “saveenv” under u-boot — in hopes that I would be 
able to see it under Linux with fw_printenv.  That didn’t work, of course — 
seemingly because of the above noted mis-configuration.

But not a problem…  This is my “testing” machine — totally dedicated to the 
purpose, so I’ll just re-install from scratch the next time I want to test 
something.

> live well,
>  vagrant

Thanks for all your help and good work!
Enjoy!
Rick

fw_printenv says "Warning: Bad CRC, using default environment"

[Rick Thomas]

On my Cubox-i4Pro when I run fw_printenv (from the u-boot-tools package) it 
says “Warning: Bad CRC, using default environment”.

The “default environment” is clearly *not* the environment that u-boot is using 
to boot the box.  At least the “ethaddr” variable in that environment is 
clearly a fake one as show here:

> root@cube:~# fw_printenv ethaddr
> Warning: Bad CRC, using default environment
> ethaddr=00:00:11:22:33:44

This is definitely not the ethernet address that the box is using for dhcp.

A couple of more data points that may shed light on this:

> root@cube:~# cat /etc/fw_env.config 
> # Configuration file for fw_(printenv/saveenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector is assumed present.
> #
> # XXX this configuration might miss a fifth parameter for the "Number of
> # sectors"
> 
> # MTD device name   Device offset   Env. size   Flash sector size
> /dev/mmcblk1p10x8 0x2000

> root@cube:~# cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config 
> # Configuration file for fw_(printenv/saveenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector is assumed present.
> #
> # XXX this configuration might miss a fifth parameter for the "Number of
> # sectors"
> 
> # MTD device name   Device offset   Env. size   Flash sector size
> /dev/mmcblk00x8 0x2000

FWIW the micro-SD card on this box is identified as /dev/mmcblk1 — not as 
either /dev/mmcblk0 or /dev/mmcblk1p1.

Does this represent a bug in u-boot-tools, or am I mis-interpreting something?

Enjoy!
Rick

Re: Debian Installer Buster Alpha 4 release

[Rick Thomas]

> On Dec 15, 2018, at 2:26 PM, Cyril Brulebois  wrote:
> 
> Hardware support changes
> 
> 
> * debian-installer:
>   - [armel] Disable OpenRD targets, no longer present in u-boot.

Does this mean that my OpenRD hardware will no longer be supported in Buster?
What about SheevaPlug hardware?  Is that still supported by upstream u-boot?
  …
> * u-boot:
  …
>   - [armel] Drop openrd targets (no longer supported upstream).

Nice, physically small, reliable hardware…  A shame to see it go…

>   - u-boot-imx: Remove mx6cuboxi4x4 target, as ram is now properly
> detected with mx6cuboxi.

Good news!  Glad to hear it.

Thanks for all your work!
Rick

Re: armel/marvell kernel size

[Rick Thomas]

On Mar 28, 2018, at 2:22 AM, Rick Thomas <rbtho...@pobox.com> wrote:

>> What filesystems do you use? Do you use any (para)virtualization? What
>> about addon hardware that you have? Any USB dongles? Anything that you
>> can think of? Sound?
>> 
>> Do you use NFS? (I do) What kind of compressed ramdisk do you use? The
>> loaded modules that you have with lsmod would be nice to know.
> 

Filesystems:  ext2 and ext4

Vitrualization: Nope.  These are way too small for anything fancy like that.

Addon hardware:
USB2 ports useful for disk and/or flash drives and other stuff (I don’t 
do the “other stuff” myself but I suppose there are folks who might).
They have 1000BaseT ports.  Two ports on the OpenRD Client, one on the 
SheevaPlug.
They each have a mini-USB serial port that they use for serial console.
The Client has a headphone jack.  I’ve used it in the past for 
listening to streaming radio.  The SheevaPlug has no audio i/o.
Both machines have SD-card slots that can be used in booting or as aux 
data storage.
Both get their uboot from mtd, not mmc, so updating uboot requires 
re-flashing.
The Client has 512MB RAM.  The SheevaPlug has the same.

CPU info for SheevaPlug —
> root@sheeva:~# cat /proc/cpuinfo
> processor : 0
> model name: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS  : 1185.79
> Features  : swp half thumb fastmult edsp 
> CPU implementer   : 0x56
> CPU architecture: 5TE
> CPU variant   : 0x2
> CPU part  : 0x131
> CPU revision  : 1
> 
> Hardware  : Marvell Kirkwood (Flattened Device Tree)
> Revision  : 
> Serial: 

CPU info for OpenRD Client —
> rbthomas@client:~$ cat /proc/cpuinfo 

> processor : 0
> model name: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS  : 1191.93
> Features  : swp half thumb fastmult edsp 
> CPU implementer   : 0x56
> CPU architecture: 5TE
> CPU variant   : 0x2
> CPU part  : 0x131
> CPU revision  : 1
> 
> Hardware  : Marvell Kirkwood (Flattened Device Tree)
> Revision  : 
> Serial: 

Uboot details on SheevaPlug —
> U-Boot 2016.01-rc3+dfsg1-3 (Jan 02 2016 - 23:19:11 +)
> Marvell-Sheevaplug
> 
> SoC:   Kirkwood 88F6281_A0
> DRAM:  512 MiB (ECC not enabled)
> WARNING: Caches not enabled
> NAND:  512 MiB
> MMC:   MVEBU_MMC: 0
> In:serial
> Out:   serial
> Err:   serial
> Net:   egiga0

and on OpenRD Client —
> U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +)
> OpenRD-Client
> 
> SoC:   Kirkwood 88F6281_A0
> DRAM:  512 MiB
> WARNING: Caches not enabled
> NAND:  512 MiB
> MMC:   MVEBU_MMC: 0
> In:serial
> Out:   serial
> Err:   serial
> Net:   egiga0, egiga1
> 


I use the SheevaPlug as a backup DHCP/DNS server for my home network.  The 
Client is reserved for experimenting.

I don’t currently use NFS on either, but I have in the past.

I’m not sure what you mean by “What kind of compressed ramdisk do you use?”.  
As a stab in the dark —

> rbthomas@client:~$ file /boot/initrd.img-4.9.0-6-marvell
> /boot/initrd.img-4.9.0-6-marvell: gzip compressed data, last modified: Sun 
> Mar  4 14:29:43 2018, from Unix

and

> root@sheeva:~# file /boot/initrd.img-4.9.0-6-marvell
> /boot/initrd.img-4.9.0-6-marvell: gzip compressed data, last modified: Sat 
> Mar 10 10:12:39 2018, from Unix

In other words, nothing fancy!

Does that help?
Rick

Re: armel/marvell kernel size

[Rick Thomas]

On Mar 27, 2018, at 2:08 PM, Rogério Brito <rbr...@ime.usp.br> wrote:

> On 2018-03-27 17:29, Rick Thomas wrote:
>> On Mar 27, 2018, at 1:04 PM, Rogério Brito <rbr...@ime.usp.br> wrote:
>>> As a related subject, I could compile a more stripped down version of
>>> the armel kernel, put it for people to download and ask people to
>>> comment if it works for them, so that we can gauge what people actually
>>> need from such a kernel...
>> 
>> Please do!  I have an OpenRD box and a SheevaPlug that I’ll be happy to test 
>> on.
> 
> You're welcome. I don't know much about the OpenRD nor about the
> SheevaPlug, but are they able to run the -marvell kernels? What was the
> last version of the kernel that worked for you?
> 
> What filesystems do you use? Do you use any (para)virtualization? What
> about addon hardware that you have? Any USB dongles? Anything that you
> can think of? Sound?
> 
> Do you use NFS? (I do) What kind of compressed ramdisk do you use? The
> loaded modules that you have with lsmod would be nice to know.

A lot of questions…  I’ll do my best to answer them as best I can sometime this 
weekend (There are an equally large lot of things on my to-do list this week!  
/-: )

In the mean time here’s a start:

OpenRD Client
> rbthomas@client:~$ uname -a
> Linux client 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 (2018-03-02) armv5tel 
> GNU/Linux

SheevaPlug
> rbthomas@sheeva:~$ uname -a
> Linux sheeva 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 (2018-03-02) armv5tel 
> GNU/Linux

Both are running the latest Stretch.

Rick

Re: armel/marvell kernel size

[Rick Thomas]

On Mar 27, 2018, at 1:04 PM, Rogério Brito  wrote:
> As a related subject, I could compile a more stripped down version of
> the armel kernel, put it for people to download and ask people to
> comment if it works for them, so that we can gauge what people actually
> need from such a kernel...

Please do!  I have an OpenRD box and a SheevaPlug that I’ll be happy to test on.

Thanks for keeping these old boxes alive!
Rick

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Rick Thomas]

> On Nov 7, 2017, at 3:27 AM, Christian Seiler <christ...@iwakd.de> wrote:
> 
> Hi,
> 
> Am 2017-11-07 11:49, schrieb Rick Thomas:
>> How do I know if a machine is ARMv4t?  I have a sheevaplug and a
>> couple of openrd machines (one “client”, the other “ultimate”) that
>> are still doing useful work.  Are they v4t?
> 
> cat /proc/cpuinfo should do the trick. It might not show the 't'
> after the 4, but it should definitely show whether it's an ARMv4
> or not. (And Debian's armel doesn't support any non-'t' ARMv4
> CPUs, so if it's ARMv4 and running Debian's armel port, it's
> ARMv4t.)

Thanks!  It looks like my machines are all 5TE — or maybe v5l ??  In any case, 
not v4t.

> rbthomas@client:~$ cat /proc/cpuinfo
> processor : 0
> model name: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS  : 1191.93
> Features  : swp half thumb fastmult edsp 
> CPU implementer   : 0x56
> CPU architecture: 5TE
> CPU variant   : 0x2
> CPU part  : 0x131
> CPU revision  : 1
> 
> Hardware  : Marvell Kirkwood (Flattened Device Tree)
> Revision  : 
> Serial: 

All three show the same output.

Enjoy!
Rick

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Rick Thomas]

How do I know if a machine is ARMv4t?  I have a sheevaplug and a couple of 
openrd machines (one “client”, the other “ultimate”) that are still doing 
useful work.  Are they v4t?

Thanks,
Rick

> On Nov 5, 2017, at 1:32 PM, Adrian Bunk  wrote:
> 
> Hi,
> 
> for the armel port in buster the question of raising the baseline came up.
> 
> 20 years ago you could go into a shop and buy a mobile phone
> with a CPU supported by the armel port in stretch.
> 
> Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug 
> reports from users on ARMv5 hardware in stretch, so it is clear that
> ARMv5 should stay supported (and of course also ARMv6 and ARMv7).
> 
> But while it was mentioned that there exists ARMv4t hardware that works 
> with current mainline kernels [1], it is not clear whether there are any 
> actual users left - and without users we might not even notice if the 
> port is broken on the baseline.
> 
> If anyone is running stretch, buster or sid on ARMv4t hardware,
> then please let us know what device and kernel you are using
> and whether you intend to use buster.
> 
> cu
> Adrian
> 
> [1] https://lists.debian.org/debian-arm/2017/08/msg00046.html
> 
> -- 
> 
>   "Is there not promise of rain?" Ling Tan asked suddenly out
>of the darkness. There had been need of rain for many days.
>   "Only a promise," Lao Er said.
>   Pearl S. Buck - Dragon Seed
> 

Stretch 9.1 installer on MX6 cubox-i4pro fails doing dhcp network config -- must do manual network config

[Rick Thomas]

Just for fun I tried installing Stretch 9.1 on my Cubox-i4Pro.

When it got to configuring the network via DHCP it failed to get any 
configuration info.
I configured the network manually, and it was able to continue.

It appears that the ethernet interface is not getting initialized by the 
auto-configure part of the installer, but manual-configure part is properly 
initializing it.

Before you ask, yes there is a DHCP server on the LAN, and it is found and does 
its job without fail for the very same client machine when booting installed 
Stretch — i.e. it only fails in the installer.

Does anybody have a work-around that would allow me to avoid manual config?

I have reported this as Debian installer bug # 866597, but nobody seems to have 
noticed yet.

Enjoy!
Rick

Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

On Oct 5, 2016, at 1:54 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> On 2016-10-01, Rick Thomas wrote:
>> On Jun 5, 2016, at 1:35 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
>>> On 2016-06-05, Gaudenz Steinlin wrote:
>>>> I have the same problem with my Cubox-i 4x4. Is there any progress on
>>>> this?
> ...
>>>> Are the patches incorporated into the latest version in experimental?
>>> 
>>> No, it requires a patch that does run-time detection. At least the
>>> versions of u-boot in debian currently boot on both cubox-i4x4 and
>>> cubox-i4pro, even if it limits ram to 2gb on the i4x4.
>>> 
>>> 
>>>> Is there anything I could test to get this into Debian?
>>> 
>>> Someone could write a patch acceptible for u-boot upstream that does
>>> run-time detection... there may be folks on #u-boot on irc.freenode.net
>>> willing to help a bit.
>>> 
>>> It also might be good to file a bug report against the u-boot-imx
>>> package in Debian at this point, so that the issue can at least be
>>> tracked appropriately.
> ...
>> Sorry to bring this back up after such a long time, but I had a couple
>> of thoughts that I’d like to bounce off those more knowledgable than
>> I.
>> 
>> Would it be possible to do one or the other of these two:
>> 
>> 1) Put the 2GB vs 4GB setting in the .dtb file.
>> 
>> 2) Put setting in a kernel command line argument.
> 
> I believe it actually requires u-boot to initialize ram timings and
> various other parameters. You can trick the kernel into using more
> memory, but in my experience that just caused crashes when trying to use
> more ram than u-boot initilized.
> 
> It would of course be useful to experiment with alternative methods, but
> my guess is getting proper patches into u-boot may likely be the
> simplest approach. It just takes some work.

scanning the subject lines in the u-boot list, it looks like somebody has
made this work for a different (from the Cubox) architecture.
> Subject: Re: [U-Boot] [PATCH v2 2/3] rk3288: sdram: auto-detect the 
> capacity

Would you be interested in getting it to work on the Cubox i-4x4?
It looks like the next couple of weeks for me will be free enough to do some 
testing, if you’re willing.

Rick

Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

> On Oct 5, 2016, at 11:57 PM, Uwe Kleine-König  wrote:
> 
> Hello,
> 
> On 10/05/2016 10:54 PM, Vagrant Cascadian wrote:
>> I believe it actually requires u-boot to initialize ram timings and
>> various other parameters. You can trick the kernel into using more
> 
> Right, the kernel expects the boot loader to initialize RAM. I don't
> know about u-boot, but barebox edits the dtb that is passed to the
> kernel on the fly to contain the right description for all RAM it
> initialized.
> 
>> It would of course be useful to experiment with alternative methods, but
>> my guess is getting proper patches into u-boot may likely be the
>> simplest approach. It just takes some work.
> 
> So another not too hard possibility is to port barebox to your board :-)
> (This should really be easy, the i.MX6 is well supported in barebox, and
> because barebox probes itself from a device tree that already exists it
> should be really easy.)

I don’t have the skills to participate in the porting, but I’ve got two 
Cubox-I4 devices, one with 2GB, one with 4GB RAM that I can use for testing, if 
somebody else wants to try.

Enjoy!
Rick

Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

> On Oct 5, 2016, at 1:54 PM, Vagrant Cascadian  wrote:
> 
> It would of course be useful to experiment with alternative methods, but
> my guess is getting proper patches into u-boot may likely be the
> simplest approach. It just takes some work.

Anything I can do as a tester to help with that process?  How does one file a 
wishlist bug report to u-boot upstream?  Would that help any?

Rick

Re: Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 4, 2016, at 3:12 AM, Rick Thomas <rbtho...@pobox.com> wrote:

>> On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
>> 
>>> I'd be curious if you re-install and delete each partition individually
>>> and re-create manually vs. using one of the auto-partitioning methods.
> 

Having messed up my first try at this (albeit in a way that shed some light on 
the problem), I resolved to try again.

I followed the standard script and did the Testing install.  This time I did 
the manual partitioning correctly, deleting the first (and only) partition on 
the uSD and creating two partitions in the resulting free space, i.e. /boot and 
root.

As expected, when it came time to reboot from the installer to the installed 
system, it hung and did not reboot.

However, when I un-plugged and re-plugged the Cubox, just to see what would 
happen, lo and behold, It booted! And the installed system appears to be intact.

The only unusual thing is that when it was starting up, u-boot remarked, “*** 
Warning - bad CRC, using default environment”.  What this seems to be saying is 
that the “make bootable” part of the installer is not putting the boot script 
(or, indeed, any of the u-boot environment) where u-boot is expecting to find 
it.

I wonder if it’s possible that the installer is using the wrong version of 
“/etc/fw_env.config”?

Maybe this is a clue — on my machine running testing, I have the following:

> rbthomas@cube:~$ cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config 
> # Configuration file for fw_(printenv/saveenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector is assumed present.
> #
> # XXX this configuration might miss a fifth parameter for the "Number of
> # sectors"
> 
> # MTD device name   Device offset   Env. size   Flash sector size
> /dev/mmcblk00x8 0x2000
> rbthomas@cube:~$ cat /etc/fw_env.config
> # Configuration file for fw_(printenv/saveenv) utility.
> # Up to two entries are valid, in this case the redundant
> # environment sector is assumed present.
> #
> # XXX this configuration might miss a fifth parameter for the "Number of
> # sectors"
> 
> # MTD device name   Device offset   Env. size   Flash sector size
> /dev/mmcblk00x8 0x2000
> rbthomas@cube:~$ ls -ld /dev/mmcblk* 
> brw-rw 1 root disk 179, 0 Jul 25 12:50 /dev/mmcblk1
> brw-rw 1 root disk 179, 1 Jul 25 12:50 /dev/mmcblk1p1
> rbthomas@cube:~$ 

I don’t know why the uSD card is called mmcblk1, not mmcblk0, but it would 
certainly explain what we’re seeing if the same phenomenon is present in the 
installer environment…

Just thinking,

Rick

Re: Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

> On Sep 2, 2016, at 6:33 PM, Rick Thomas <rbtho...@pobox.com> wrote:
> 
> 
> On Sep 2, 2016, at 4:40 PM, Gunnar Wolf <gw...@debian.org> wrote:
> 
>> Can somebody confirm whether the Jessie
>> installer actually works reliably on this machine? (that is, whether
>> it's always been broken or we have a regression)
> 
> I’ll give that a try as well over the weekend.  Let you know what I find.
> 
> Rick

I tried it.  Jessie installs fine and boots into the installed system with no 
problems.

Here’s a .png of the partitions screen.

Rick

Re: Graphical output from iMX6/Cubox-i

[Rick Thomas]

> On Sep 4, 2016, at 1:47 PM, Rainer Dorsch  wrote:
> 
> Hi,
> 
> this is an interesting response
> 
> http://forum.solid-run.com/viewtopic.php?t=2936=21022#p21022
> 
> Seems that I need to build xserver-xorg-video-armada
> 
> https://github.com/xobs/xserver-xorg-video-armada
> 
> to get X up and running on a plain Debian installation on a Cubox-i
> 
> Kind regards
> Rainer

Hi Rainer,

Thanks for tracking this down!
If you get it working, could you post the necessary steps?  Maybe we can get it 
into the Debian cubox wiki?  Or, dare I hope, into the Debian main line release?

Thanks!
Rick

Re: Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 2, 2016, at 6:30 PM, Rick Thomas <rbtho...@pobox.com> wrote:

> 
> On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian <vagr...@debian.org> wrote:
> 
>> I'd be curious if you re-install and delete each partition individually
>> and re-create manually vs. using one of the auto-partitioning methods.
> 
> I’ll give this a try over the weekend and report back what I find.
> 
> Is it possible that the auto-partitioning process during installation has 
> somehow clobbered the u-boot image on the SD card?  How would I test for that?
> 
> Rick

I did the experiment — manual partitioning did not help. But I sorta fumbled it 
in an interesting way that sheds some light on the question I asked in the 
quoted section above.

Here’s what I did:

1) Retrieved the installer and put it on a uSD card as described in

http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images

2) Halted the CuBox-i4 and removed all external peripherals from it (including 
the uSD it boots from) and inserted the installer uSD.

3) Connected to the serial console and re-applied power.

4) Answered questions until it got to partitioning.

5) Chose “manual” partitioning.  Since there was no other storage peripherals 
it only offered me the uSD, which (as a result of 1, above) had a large free 
space.  I told it to use the free space for / and format that as ext2.  I 
failed to delete the installer partition.  (This is the sorta-fumble I 
mentioned earlier.)  

6) I did not create a /boot or swap partition.

I have attached a screen shot of the screen at the end of the process…



After proceeding and answering questions, I ended up with an uSD card with two 
partitions.  The second partition contains the installed system; the first 
partition still contains the installer.

When it got to the end of the installation, it tried to reboot — presumably 
into the newly installed system in partition 2, but did not succeed in 
rebooting.

It’s last words were:

> Sent SIGKILL to all processes
> Requesting system reboot
> [   39.132949] reboot: Restarting system

Then nothing.

This is what we were expecting.  The interesting part comes next.

I pulled the power plug and re-plugged.  It ran u-boot and booted — but not 
into the installed system.  Rather it booted into the installer — which, 
remember, was still present in partition 1.

From this I conclude that the u-boot environment is not getting updated by the 
installer.  And u-boot itself in not getting clobbered by anything in the 
installation process.

Bottom line — the problem is verifiably in the late stages of the installer 
when it’s trying to make the system bootable.  It’s not a problem with the 
auto-partitioning, and it’s not a problem with u-boot.

Hope it helps!
Rick

Re: Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 2, 2016, at 4:40 PM, Gunnar Wolf  wrote:

> Can somebody confirm whether the Jessie
> installer actually works reliably on this machine? (that is, whether
> it's always been broken or we have a regression)

I’ll give that a try as well over the weekend.  Let you know what I find.

Rick

Re: Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

On Sep 2, 2016, at 5:12 PM, Vagrant Cascadian  wrote:

> I'd be curious if you re-install and delete each partition individually
> and re-create manually vs. using one of the auto-partitioning methods.

I’ll give this a try over the weekend and report back what I find.

Is it possible that the auto-partitioning process during installation has 
somehow clobbered the u-boot image on the SD card?  How would I test for that?

Rick

Re: Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

For what it’s worth, I just tried booting with an HDMI monitor connected to see 
if the silence on the serial-port was just a matter of console messages being 
directed to the HDMI video port instead.  Still no go.  Silence all-round.

Rick

> On Aug 22, 2016, at 9:15 PM, Rick Thomas <rbtho...@pobox.com> wrote:
> 
> I can confirm this problem.  I just got thru running a “stretch” install on 
> my test Cuboxi4Pro with ingredients from:
> 
>> wget 
>> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz
>> wget 
>> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/firmware.MX6_Cubox-i.img.gz
>> wget 
>> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images
> 
> To be absolutely clear which components:
>> -rw-r--r-- 1 rbthomas rbthomas  871 Jun 29 15:56 
>> README.concatenateable_images
>> -rw-r--r-- 1 rbthomas rbthomas   187261 Jun 29 15:56 
>> firmware.MX6_Cubox-i.img.gz
>> -rw-r--r-- 1 rbthomas rbthomas 24210806 Jun 29 15:56 partition.img.gz
> 
> I got the same results as Rainer.  System would not boot after installation.  
> There was nothing at all on serial-port the console.
> 
> I also tried power-cycling the device.  Nothing on the serial-port console.
> 
> Can somebody tell me how to find out if there is a bootable u-boot on the SD 
> card?  Maybe the u-boot is getting clobbered by something in the installation 
> process?
> 
> Let me know if you want log files, etc...
> 
> Rick
> 
>> On Aug 21, 2016, at 10:44 AM, Martin Michlmayr <t...@cyrius.com> wrote:
>> 
>> * Rainer Dorsch <m...@bokomoko.de> [2016-08-21 10:41]:
>>> The boot loader installation did not show an error, but the device did not 
>>> boot. 
>>> 
>>> The last "words" of the installer:
>>> 
>>> lqu Finishing the installation tqqk
>>> x x
>>> x   95%   x
>>> x x
>>> The system is going down NOW!ystem...   
>>> x
>>> Sent SIGKILL to all processes   
>>> x
>>> Requesting system 
>>> rebootj
>>>   [ 2730.956106] reboot: Restarting system
>> 
>> Can you 1) attach /var/log/installer/syslog from the SD card and b)
>> show the boot log (after the installer).
>> 
>> -- 
>> Martin Michlmayr
>> http://www.cyrius.com/
>> 
> 

Re: Bug#834974: Installation Report: Stretch Alpha 7 on Cubox-i4pro

[Rick Thomas]

I can confirm this problem.  I just got thru running a “stretch” install on my 
test Cuboxi4Pro with ingredients from:

> wget 
> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/partition.img.gz
> wget 
> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/firmware.MX6_Cubox-i.img.gz
> wget 
> http://ftp.us.debian.org/debian/dists/stretch/main/installer-armhf/current/images/netboot/SD-card-images/README.concatenateable_images

To be absolutely clear which components:
> -rw-r--r-- 1 rbthomas rbthomas  871 Jun 29 15:56 
> README.concatenateable_images
> -rw-r--r-- 1 rbthomas rbthomas   187261 Jun 29 15:56 
> firmware.MX6_Cubox-i.img.gz
> -rw-r--r-- 1 rbthomas rbthomas 24210806 Jun 29 15:56 partition.img.gz

I got the same results as Rainer.  System would not boot after installation.  
There was nothing at all on serial-port the console.

I also tried power-cycling the device.  Nothing on the serial-port console.

Can somebody tell me how to find out if there is a bootable u-boot on the SD 
card?  Maybe the u-boot is getting clobbered by something in the installation 
process?

Let me know if you want log files, etc...

Rick

> On Aug 21, 2016, at 10:44 AM, Martin Michlmayr  wrote:
> 
> * Rainer Dorsch  [2016-08-21 10:41]:
>> The boot loader installation did not show an error, but the device did not 
>> boot. 
>> 
>> The last "words" of the installer:
>> 
>>  lqu Finishing the installation tqqk
>>  x x
>>  x   95%   x
>>  x x
>> The system is going down NOW!ystem...   x
>> Sent SIGKILL to all processes   x
>> Requesting system rebootj
>>[ 2730.956106] reboot: Restarting system
> 
> Can you 1) attach /var/log/installer/syslog from the SD card and b)
> show the boot log (after the installer).
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/
> 

Re: Bug#832713: Systemd version 231-1 (current in Sid) doesn't work on arm

[Rick Thomas]

On Jul 31, 2016, at 2:02 AM, Christian Marillat <maril...@free.fr> wrote:

> On 31 juil. 2016 10:50, Rick Thomas <rbtho...@pobox.com> wrote:
> 
>> Can you send the output of ‘uname -a ; systemd —version’ on that box?
> 
> Linux rpi3.XXX 4.4.0-1-rpi2 #1 SMP Debian 4.4.6-1+rpi14 (2016-05-05) armv7l 
> GNU/Linux
> 
> ,
> | $ systemd -—version 
> | systemd: invalid option -- 'â'
> `——

darn spelling corrector!  changed my double-dash into an m-dash. humph!

But fortunately you figured out what I *meant*.  Thanks!

> 
> Anyway I've downgraded systemd to 230-7 :
> 
> ,
> | $ systemd --version
> | systemd 230
> | +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
> +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
> `
> 
> Christian

So I guess there must be something different between the kernel your raspberry 
pi is using and the one my sheevaplug is using.  I know that the “marvel” 
series of kernels have several optional features turned off to save space.  
Maybe there’s something there.

> rbthomas@sheeva:~$ uname -a
> Linux sheeva 4.6.0-1-marvell #1 Debian 4.6.4-1 (2016-07-18) armv5tel GNU/Linux

On the other hand, my Cubox-iP4 has the problem and it’s running

> rbthomas@cube:~$ uname -a
> Linux cube 4.6.0-1-armmp #1 SMP Debian 4.6.4-1 (2016-07-18) armv7l GNU/Linux

The Cubox, I think, doesn’t have those space limitations.

Thanks for your help!
Rick

Re: Bug#832713: Systemd version 231-1 (current in Sid) doesn't work on arm

[Rick Thomas]

Can you send the output of ‘uname -a ; systemd —version’ on that box?

Thanks!

On Jul 31, 2016, at 12:22 AM, Christian Marillat <maril...@free.fr> wrote:

> On 31 juil. 2016 08:50, Rick Thomas <rbtho...@pobox.com> wrote:
> 
>> Thanks, Christian!
>> 
>> What is your armel box?  I *do* see it on my SheevaPlug (armel), so
>> there may be a clue.  Is your armel kernel customized in some way?
> 
> Raspberry Pi 2 kernel 4.1.12
> 
> Christian

Re: Bug#832713: Systemd version 231-1 (current in Sid) doesn't work on arm

[Rick Thomas]

Thanks, Christian!

What is your armel box?  I *do* see it on my SheevaPlug (armel), so there may 
be a clue.  Is your armel kernel customized in some way?

Enjoy!
Rick

> On Jul 30, 2016, at 11:33 PM, Christian Marillat <maril...@free.fr> wrote:
> 
> On 30 juil. 2016 23:02, Rick Thomas <rbtho...@pobox.com> wrote:
> 
>> Has anyone else noticed this bug?
>> 
>> Bug#832713: systemd: after "systemd (231-1) unstable" update
>> systemd-jurnald.service fails to start
>> 
>> I’ve tried it on armel (SheevaPlug) and armmp (Cubox-i4Pro).  It fails on 
>> both.
>> I’ve also tried it on amd64 and powerpc hardware.  The bug is not present 
>> there.
> 
> I see this bug on a Raspberry Pi3 armhf 4.4.6 but not on a
> Pandaboard ES armhf 4.2.8
> 
> Also I don't see this bug on armel, i386, powerpc, arm64 arches.
> 
> Christian

Systemd version 231-1 (current in Sid) doesn't work on arm

[Rick Thomas]

Has anyone else noticed this bug?

Bug#832713: systemd: after "systemd (231-1) unstable" update 
systemd-jurnald.service fails to start

I’ve tried it on armel (SheevaPlug) and armmp (Cubox-i4Pro).  It fails on both.
I’ve also tried it on amd64 and powerpc hardware.  The bug is not present there.

Anybody got any ideas as to how to track it down?

Thanks!
Rick

How to use the HDMI screen as console on Cubox-i4

[Rick Thomas]

Hi Debian Arm folks!

Does anyone know the necessary magic incantation to make my Cubox-i 4x4 use the 
HDMI port as console so I can run a desktop environment on it?

Thanks!

Rick

Re: Cubox-i 4x4 RAM

[Rick Thomas]

On 05/01/16 10:57, Vagrant Cascadian wrote:

On 2016-04-30, Rick Thomas wrote:

I finally got some time to test the experimental u-boot:
  u-boot-imx_2016.05~rc2+dfsg0~20160423~1-1_armhf.deb

It installs and boots and recognizes 3.8GB RAM on the 4x4.  So I guess I
got a real 4x4 after all!

Yeah, figured that might be the case.



I also have a cubox-i4pro (the 2GB variety).  You suggested that this
would probably not work there.  Would you like me to test it for you?
If that would speed up getting this patch into production, I'm willing
to give it a try!

I tested an older version of the patch on a cubox-i4pro, but if you're
willing to confirm that it also fails on yours, that's more info.

The patch is a one-liner to change from one hard-coded ram configuration
to another. I'm fairly confident that it needs actualy run-time
detection to support both models, as the various models have some
incompatible ram configuration.

In addition to run-time ram detection, solid-run's vendor u-boot branch
also has numerous ram timings that should be updated in mainline u-boot,
but actually getting working patches so far has been beyond me.



I installed it on my i4pro, it booted and ran Linux for a few minutes. 
It didn't crash, but it claimed
I had 3.8GB RAM (both u-boot and Linux thought so).  I suspected I 
_would_ get a crash if I ran it
for long enough for it to try actually using the phantom part, and I 
didn't feel like dealing with the
corrupted file systems that would probably result, so I went back to the 
original u-boot as soon as I

could.

If you like, I'll try to install a test system on a spare USB-stick with 
the new u-boot.  No harm if that

crashes, I guess.

Enjoy!
Rick

Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

On 04/26/16 00:51, Rick Thomas wrote:

On Apr 21, 2016, at 11:54 PM, Rick Thomas <rbtho...@pobox.com> wrote:


I seem to remember that I got roughly the same number (lightly less
than 2.0 GiB) when I booted the manufacturer supplied u-boot and
Ubuntu kernel from the uSD-card that came with it.

Maybe it came with a u-boot that didn't support the cubox-i4x4, as it
wasn't added until relatively recently:

https://github.com/SolidRun/u-boot-imx6

Or, maybe you really did get a cubox-i4pro.

Possible… I’ll have to boot it from the original µSD-card and see what version 
of u-boot it has.  I may have time to do that this weekend.

Here’s the info on the u-boot from the original µSDcard that came with the 
device.


U-Boot 2013.10-rc4-ga06fada (Jul 16 2014 - 10:20:49)

I’ve attached an edited transcript of the console output, if that’s interesting.

I’m pretty sure that u-boot from almost 2 years ago won’t have support for the 
“4x4”.

Next is to try your updated u-boot and see what it says about available RAM.

I finally got some time to test the experimental u-boot:
u-boot-imx_2016.05~rc2+dfsg0~20160423~1-1_armhf.deb

It installs and boots and recognizes 3.8GB RAM on the 4x4.  So I guess I 
got a real 4x4 after all!


I also have a cubox-i4pro (the 2GB variety).  You suggested that this 
would probably not work there.  Would you like me to test it for you?  
If that would speed up getting this patch into production, I'm willing 
to give it a try!


Enjoy!
Rick

Re: creating official Debian images for ARM-based NAS devices

[Rick Thomas]

On Apr 13, 2016, at 10:27 PM, Daniel Pocock  wrote:
> If people are relying upon TFTP, it
> would not be hard to produce a Debian Live DVD that has a
> preconfigured DHCP/BOOTP/TFTP services for people to initialize other
> devices like this.

On Apr 19, 2016, at 2:27 AM, Riku Voipio  wrote:
> On Wed, Apr 13, 2016 at 04:55:53PM +0200, Daniel Pocock wrote:
>> get started.  There is no need for the user to run through all the
>> installer questions, on many devices they can simply log in to the
>> standard admin page, upload the OpenWRT image through a web form and it
>> starts running with default settings.
> 
> The minimum we need to ask from users is for user/password setting. Most
> live-cd / live-image tools just hardcode a default credential, which is
> quite bad for embedded devices that will be running for years... 
> 
> Riku

Riku has a very good point.

So…  Taking Daniels’ idea and adding Riku’s point we get a Debian Live DVD
that has a preconfigured DHCP/BOOTP/TFTP service and a script you can run
from the command line that asks a bunch of questions to build a pre-seed
file.  One of the questions *must* be for user/password settings.

For the use-case of mass-installing a bunch of devices, it would probably be
a good idea for the script to take as input an already configured pre-seed
file to use as defaults.

The script should be interactive if given no parameters, but it should be
able to take enough parameters specifying values that it can be run
non-interactively if desired.

I’d work on such a thing, if somebody else were to lead the project.

Rick

Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

On Apr 21, 2016, at 11:54 PM, Rick Thomas <rbtho...@pobox.com> wrote:

>>> 
>>> I seem to remember that I got roughly the same number (lightly less
>>> than 2.0 GiB) when I booted the manufacturer supplied u-boot and
>>> Ubuntu kernel from the uSD-card that came with it.
>> 
>> Maybe it came with a u-boot that didn't support the cubox-i4x4, as it
>> wasn't added until relatively recently:
>> 
>> https://github.com/SolidRun/u-boot-imx6
>> 
>> Or, maybe you really did get a cubox-i4pro.
> 
> Possible… I’ll have to boot it from the original µSD-card and see what 
> version of u-boot it has.  I may have time to do that this weekend.

Here’s the info on the u-boot from the original µSDcard that came with the 
device.

> U-Boot 2013.10-rc4-ga06fada (Jul 16 2014 - 10:20:49)

I’ve attached an edited transcript of the console output, if that’s interesting.

I’m pretty sure that u-boot from almost 2 years ago won’t have support for the 
“4x4”.

Next is to try your updated u-boot and see what it says about available RAM.

Enjoy!
Rick




uboot.log
Description: Binary data

Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

Any chance I could download a pre-built binary?  (It’s been a couple of decades 
since I actually built any binaries… |-: )

Please forgive my curiosity.  I’m trying to understand how this process works…

Do I understand correctly that this is part of the definition of a structure 
that contains memory config parameters and gets passed from u-boot to the 
kernel when it gets control?  And why is this determined by a compile-time 
value?  Wouldn’t it be more flexible if the kernel (or u-boot) discovered it at 
run-time?  For example, by probing successively higher memory locations until 
it got a men-fault?

Fascinating… What other things, besides memory config, get passed this way? 

Thanks!
Rick

On Apr 22, 2016, at 2:02 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> On 2016-04-21, Rick Thomas wrote:
>> On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian <vagr...@debian.org> wrote:
>>> On 2016-04-21, Rick Thomas wrote:
>>>> But if I were using your patched mainline u-boot, I would get a
>>>> different (larger) number (almost, but not quite, the full 4.0GiB)?
>>> 
>>> That’s how it's worked for me, yes.
>> 
>> Would you be willing to share this modified u-boot with me?  I’d like
>> to try it out on my device to see if it’s really an i4pro or a 4x4.
> 
> It's a one-line patch against u-boot 2016.03~rc1:
> 
> Index: u-boot/board/solidrun/mx6cuboxi/mx6cuboxi.c
> ===
> --- u-boot.orig/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ u-boot/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -563,7 +563,7 @@ static struct mx6_ddr3_cfg mem_ddr_4g =
>   .density = 4,
>   .width = 16,
>   .banks = 8,
> - .rowaddr = 15,
> + .rowaddr = 16,
>   .coladdr = 10,
>   .pagesz = 2,
>   .trcd = 1375,
> 
> I haven't tested on a more recent version, but it would probably work as
> well.
> 
> 
> live well,
>  vagrant

Re: Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

On Apr 21, 2016, at 9:04 AM, Vagrant Cascadian <vagr...@debian.org> wrote:

> On 2016-04-21, Rick Thomas wrote:
>> Are you saying that the amount of RAM seen by Debian Linux is
>> determined by something in u-boot?
> 
> Yes.

How is this information communicated from u-boot to the Linux kernel?  I 
thought I understood (at least in principle) how the hand-off between then 
worked, but clearly I’m missing something.

> 
>> But if I were using your patched mainline u-boot, I would get a
>> different (larger) number (almost, but not quite, the full 4.0GiB)?
> 
> That’s how it's worked for me, yes.

Would you be willing to share this modified u-boot with me?  I’d like to try it 
out on my device to see if it’s really an i4pro or a 4x4.

> 
> There's something about the imx6 that limits it to 3.8GB.
> 
> 
>> I seem to remember that I got roughly the same number (lightly less
>> than 2.0 GiB) when I booted the manufacturer supplied u-boot and
>> Ubuntu kernel from the uSD-card that came with it.
> 
> Maybe it came with a u-boot that didn't support the cubox-i4x4, as it
> wasn't added until relatively recently:
> 
>  https://github.com/SolidRun/u-boot-imx6
> 
> Or, maybe you really did get a cubox-i4pro.

Possible… I’ll have to boot it from the original µSD-card and see what version 
of u-boot it has.  I may have time to do that this weekend.

> live well,
>  vagrant

Cubox-i 4x4 RAM [was Re: Performance of armhf boards]

[Rick Thomas]

[Ooops, the last one got away from me before it was finished!]

On Apr 20, 2016, at 10:26 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> This appears to be a thread forked from a reproducible-builds
> discussion. :)

Yeah… sorry for hijacking the thread…  Please forgive my curiosity (:

> 
> On 2016-04-20, Rick Thomas wrote:
>> On Sun, Apr 17, 2016, at 06:36 PM, Steven Chamberlain wrote:
>>> I was wondering what is the performance of various armhf boards, for
>>> package building.  
>> ...
>>> cbxi4a-armhf-rb.debian.net19962365# 4x,4G;
>>> Cubox-i4x4
>>> cbxi4pro0-armhf-rb.debian.net 19732743# 4x,2G;
>>> CuBox-i4Pro
>> ... 
>>> I don't know whether to believe these figures yet!
>>> 
>>>  * cbxi4a/b seem no faster than cbxi4pro0 despite twice the RAM?
> 
>> One personal experience that may be relevant:
>> 
>> I ordered a Cubox-i4x4 from NewEgg a few months ago.  When it arrived it
>> was clearly marked as a 4x4, and in the original shrink-wrap, But it
>> only had 2GB of RAM.  I notified NewEgg and they tested one of the other
>> one's of that batch they had in stock.  Surprise!  It also had only 2GB
>> RAM...  They gave me a rebate of the difference in price between the
>> i4-Pro and the 4x4 and we considered the matter closed.
> 
> Well, you need to either use the vendor u-boot with support for more
> ram, or patch mainline u-boot to use more. Haven't taken the time to
> write a patch that works with all the various ram configurations, so
> haven't pushed anything mainline.
> 
> The cubox-i4x4 I am running with a one or two line patched mainline
> u-boot but effectively are limited to 3.8GB, but that's still
> significantly more than 2GB.
> 
> 
> live well,
>  vagrant

Let me see if I’ve got this right…

Are you saying that the amount of RAM seen by Debian Linux is determined by 
something in u-boot?

Here’s what I see on the machine in question running Debian:

> rbthomas@half:~$ uname -a
> Linux half 3.16.0-4-armmp #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) armv7l 
> GNU/Linux

and
> U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)

I get

> rbthomas@half:~$ cat /proc/meminfo 
> MemTotal:2069780 kB

But if I were using your patched mainline u-boot, I would get a different 
(larger) number (almost, but not quite, the full 4.0GiB)?

Very interesting!

I seem to remember that I got roughly the same number (lightly less than 2.0 
GiB) when I booted the manufacturer supplied u-boot and Ubuntu kernel from the 
uSD-card that came with it.


Enjoy!
Rick

Cubox-i4x4 - [was Re: Performance of armhf boards]

[Rick Thomas]

On Apr 20, 2016, at 10:26 PM, Vagrant Cascadian <vagr...@debian.org> wrote:

> This appears to be a thread forked from a reproducible-builds
> discussion. :)
> 
> On 2016-04-20, Rick Thomas wrote:
>> On Sun, Apr 17, 2016, at 06:36 PM, Steven Chamberlain wrote:
>>> I was wondering what is the performance of various armhf boards, for
>>> package building.  
>> ...
>>> cbxi4a-armhf-rb.debian.net19962365# 4x,4G;
>>> Cubox-i4x4
>>> cbxi4pro0-armhf-rb.debian.net 19732743# 4x,2G;
>>> CuBox-i4Pro
>> ... 
>>> I don't know whether to believe these figures yet!
>>> 
>>>  * cbxi4a/b seem no faster than cbxi4pro0 despite twice the RAM?
> 
>> One personal experience that may be relevant:
>> 
>> I ordered a Cubox-i4x4 from NewEgg a few months ago.  When it arrived it
>> was clearly marked as a 4x4, and in the original shrink-wrap, But it
>> only had 2GB of RAM.  I notified NewEgg and they tested one of the other
>> one's of that batch they had in stock.  Surprise!  It also had only 2GB
>> RAM...  They gave me a rebate of the difference in price between the
>> i4-Pro and the 4x4 and we considered the matter closed.
> 
> Well, you need to either use the vendor u-boot with support for more
> ram, or patch mainline u-boot to use more. Haven't taken the time to
> write a patch that works with all the various ram configurations, so
> haven't pushed anything mainline.
> 
> The cubox-i4x4 I am running with a one or two line patched mainline
> u-boot but effectively are limited to 3.8GB, but that's still
> significantly more than 2GB.
> 
> 
> live well,
>  vagrant

Re: Performance of armhf boards

[Rick Thomas]

On Sun, Apr 17, 2016, at 06:36 PM, Steven Chamberlain wrote:
> Hi!
> 
> I was wondering what is the performance of various armhf boards, for
> package building.  
...
> cbxi4a-armhf-rb.debian.net19962365# 4x,4G;
> Cubox-i4x4
> cbxi4pro0-armhf-rb.debian.net 19732743# 4x,2G;
> CuBox-i4Pro
... 
> I don't know whether to believe these figures yet!
> 
>   * cbxi4a/b seem no faster than cbxi4pro0 despite twice the RAM?
>   * ff2a/b show USB3 SSD to be no faster than USB2?
... 
> Corrections/suggestions are welcome.

One personal experience that may be relevant:

I ordered a Cubox-i4x4 from NewEgg a few months ago.  When it arrived it
was clearly marked as a 4x4, and in the original shrink-wrap, But it
only had 2GB of RAM.  I notified NewEgg and they tested one of the other
one's of that batch they had in stock.  Surprise!  It also had only 2GB
RAM...  They gave me a rebate of the difference in price between the
i4-Pro and the 4x4 and we considered the matter closed.

But it might be worth checking, anyway.

Also, as for the (lack of) difference between USB2 and USB3 disks, the
Cubox boards all have Gbit Ethernet ports, but they are limited to
480Mbit actual throughput rate.  I assume this is because the SoC
handles everything thru a USB2 driver circuit, though I'm not privy to
any actual design information.  You may be seeing a similar thing here.

Just my two cents.
Rick

Re: marvell_cesa continues to fail on kirkwood with kernel 4.4

[Rick Thomas]

On Feb 15, 2016, at 2:29 AM, JM  wrote:

> Actually, I just remembered that 4.4 kernel will try to load both the
> old and the new module (but without allhwsupport), so please try the
> following:
> 
> rmmod mv_cesa
> rmmod marvell_cesa
> modprobe marvell_cesa allhwsupport=1
> dmesg | grep -i cesa
> 
> Sorry for the confusion
> 
> Jan
> 
> On Mon, Feb 15, 2016 at 11:26 AM, JM  wrote:
>> Thanks for the reply. Can you paste your /proc/crypto as well?
>> 
>> Thanks,
>> Jan

Sure,  hope it helps!

> rbthomas@sheeva:~$ uname -a
> Linux sheeva 4.4.0-trunk-marvell #1 Debian 4.4.1-1~exp1 (2016-02-10) armv5tel 
> GNU/Linux
> rbthomas@sheeva:~$ # System immediately after reboot
> rbthomas@sheeva:~$ dmesg | grep -i cesa
> [   19.425689] MV-CESA:Could not register sha1 driver
> [   19.425706] MV-CESA:Could not register hmac-sha1 driver
> rbthomas@sheeva:~$ sudo -i
> root@sheeva:~# rmmod -v mv_cesa
> root@sheeva:~# rmmod -v marvell_cesa
> root@sheeva:~# modprobe marvell_cesa allhwsupport=1
> root@sheeva:~# dmesg | grep -i cesa
> [   19.425689] MV-CESA:Could not register sha1 driver
> [   19.425706] MV-CESA:Could not register hmac-sha1 driver
> [  155.205238] marvell-cesa: probe of f103.crypto failed with error -12
> root@sheeva:~# cat /proc/crypto
> name : des3_ede
> driver   : des3_ede-generic
> module   : des_generic
> priority : 100
> refcnt   : 1
> selftest : passed
> internal : no
> type : cipher
> blocksize: 8
> min keysize  : 24
> max keysize  : 24
> 
> name : des
> driver   : des-generic
> module   : des_generic
> priority : 100
> refcnt   : 1
> selftest : passed
> internal : no
> type : cipher
> blocksize: 8
> min keysize  : 8
> max keysize  : 8
> 
> name : lzo
> driver   : lzo-generic
> module   : kernel
> priority : 0
> refcnt   : 2
> selftest : passed
> internal : no
> type : compression
> 
> name : crct10dif
> driver   : crct10dif-generic
> module   : kernel
> priority : 100
> refcnt   : 2
> selftest : passed
> internal : no
> type : shash
> blocksize: 1
> digestsize   : 2
> 
> name : aes
> driver   : aes-generic
> module   : kernel
> priority : 100
> refcnt   : 1
> selftest : passed
> internal : no
> type : cipher
> blocksize: 16
> min keysize  : 16
> max keysize  : 32
> 
> name : md5
> driver   : md5-generic
> module   : kernel
> priority : 0
> refcnt   : 1
> selftest : passed
> internal : no
> type : shash
> blocksize: 64
> digestsize   : 16
> 
> name : digest_null
> driver   : digest_null-generic
> module   : kernel
> priority : 0
> refcnt   : 1
> selftest : passed
> internal : no
> type : shash
> blocksize: 1
> digestsize   : 0
> 
> name : compress_null
> driver   : compress_null-generic
> module   : kernel
> priority : 0
> refcnt   : 1
> selftest : passed
> internal : no
> type : compression
> 
> name : ecb(cipher_null)
> driver   : ecb-cipher_null
> module   : kernel
> priority : 100
> refcnt   : 1
> selftest : passed
> internal : no
> type : blkcipher
> blocksize: 1
> min keysize  : 0
> max keysize  : 0
> ivsize   : 0
> geniv: 
> 
> name : cipher_null
> driver   : cipher_null-generic
> module   : kernel
> priority : 0
> refcnt   : 1
> selftest : passed
> internal : no
> type : cipher
> blocksize: 1
> min keysize  : 0
> max keysize  : 0
> 
> root@sheeva:~# 
> 

Re: marvell_cesa continues to fail on kirkwood with kernel 4.4

[Rick Thomas]

> Here you go...
> 
>> root@sheeva:~# rmmod mv_cesa
>> root@sheeva:~# modprobe marvell_cesa allhwsupport=1
>> root@sheeva:~# dmesg | tail -n 20
>> [   16.730426] systemd[1]: Mounted Debug File System.
>> [   16.756783] systemd[1]: Started Load Kernel Modules.
>> [   16.776948] systemd[1]: Started Create list of required static device 
>> nodes for the current kernel.
>> [   16.804146] systemd[1]: Started LSB: Set console font and keymap.
>> [   17.023950] systemd[1]: Started Journal Service.
>> [   18.514731] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
>> [   19.804133] orion_wdt: Initial timeout 21 sec
>> [   19.848469] MV-CESA:Could not register sha1 driver
>> [   19.848485] MV-CESA:Could not register hmac-sha1 driver
>> [   20.379009] systemd-journald[180]: Received request to flush runtime 
>> journal from PID 1
>> [   20.386082] sd 0:0:0:0: Attached scsi generic sg0 type 0
>> [   20.386886] ses 0:0:0:1: Attached scsi generic sg1 type 13
>> [   21.518406] EXT4-fs (mmcblk0p1): mounting ext2 file system using the ext4 
>> subsystem
>> [   21.682097] EXT4-fs (mmcblk0p1): mounted filesystem without journal. 
>> Opts: (null)
>> [   22.402713] Adding 9764860k swap on /dev/mapper/sheeva-swap.  Priority:-1 
>> extents:1 across:9764860k FS
>> [   22.938703] EXT4-fs (dm-2): mounted filesystem with ordered data mode. 
>> Opts: (null)
>> [   23.631978] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [   27.662122] mv643xx_eth_port mv643xx_eth_port.0 eth0: link up, 1000 Mb/s, 
>> full duplex, flow control disabled
>> [   27.662180] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> [   37.350057] warning: process `colord-sane' used the deprecated sysctl 
>> system call with 8.1.2.
>> root@sheeva:~# uname -a
>> Linux sheeva 4.4.0-trunk-marvell #1 Debian 4.4.1-1~exp1 (2016-02-10) 
>> armv5tel GNU/Linux
>> root@sheeva:~# 
> 
> For what it's worth, the system boots fine and appears to run OK with the 4.4 
> kernel.
> 
> Hope it helps!
> 
> Rick

A bit more info, incase it helps...

Rick

> root@sheeva:~# cat /proc/cpuinfo 
> processor : 0
> model name: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS  : 1185.79
> Features  : swp half thumb fastmult edsp 
> CPU implementer   : 0x56
> CPU architecture: 5TE
> CPU variant   : 0x2
> CPU part  : 0x131
> CPU revision  : 1
> 
> Hardware  : Marvell Kirkwood (Flattened Device Tree)
> Revision  : 
> Serial: 
> root@sheeva:~# 

Re: marvell_cesa continues to fail on kirkwood with kernel 4.4

[Rick Thomas]

On Feb 9, 2016, at 4:12 AM, JM  wrote:

> On Fri, Feb 5, 2016 at 5:12 AM, Martin Michlmayr  wrote:
>> * JM  [2016-02-05 04:20]:
>>> To quickly bring you up to speed, the driver for Marvell's hardware
>>> crypto accelerator embedded in their Armada/Kirkwood SoCs has been
>>> rewritten as marvell_cesa and merged in kernel 4.2. The new driver
>>> received a number of patches since and has been enabled in Debian as
>>> a module in 4.4~rc4-1~exp1 (debian bug #807634), coexisting with the
>>> old driver (mv_cesa).
>> 
>> I think it would be best if you directly reported this to
>> linux-arm-ker...@lists.infradead.org
>> and copied:
>> Boris BREZILLON 
>> Arnaud Ebalard 
>> Thomas Petazzoni 
>> Russell King 
>> 
>> --
>> Martin Michlmayr
>> http://www.cyrius.com/
> 
> Update:
> 
> I reported the issue to upstream [1] but they cannot replicate it on
> their hardware. I've built a vanilla 4.4.1 kernel using Debian's
> .config as explained in [2] and the module still fails in the same
> fashion.
> 
> For an independent confirmation, I'd appreciate if someone with a
> Kirkwood device (preferably a QNAP) could test the 4.4 kernel from
> experimental and try the following:
> 
> rmmod mv_cesa
> modprobe marvell_cesa allhwsupport=1
> dmesg | tail -n 1
> 
> I've been asked to build a vanilla kernel again using .config provided
> by Arnaud Ebalard for ReadyNAS Duo [3], but it ends up being too large
> to fit in QNAP's 2MB mtd kernel partition, and I am also not sure if
> it will work with the Debian userland, or which drivers I need to
> enable for the QNAP to work properly (flash, rtc?), any hints would be
> appreciated.
> 
> Best regards,
> Jan
> 
> 1 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/thread.html#405279
> 2 
> http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package
> 3 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405530.html

I have a sheevaplug reserved for testing that I could try installing the 
linux-image-4.4.0-trunk package from Debian experimental, if that would help...

Rick

Odd messages booting Cubox-i4 Pro "imx-gpc 20dc000.gpc: failed to get pu regulator: -517" and "ERROR: could not get clock /usdhc1_pwrseq:ext_clock(0)"

[Rick Thomas]

Does anyone know what the error messages 

Does anybody know what is causing the subject error messages?

It almost looks like the DTB is claiming a couple of devices that don't exist 
on this hardware... But I don't understand enough of that process to be sure.

Anybody got some clues?

I've attached the first several lines of the boot log, up-to and including the 
error messages, in hopes that they may have some information about the hardware.

Thanks!
Rick

> U-Boot 2015.10+dfsg1-3 (Nov 24 2015 - 22:14:29 +)
> 
> CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
> CPU:   Extended Commercial temperature grade (-20C to 105C) at 29C
> Reset cause: WDOG
> Board: MX6 Cubox-i
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0
> No panel detected: default to HDMI
> Display: HDMI (1024x768)
> In:serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0 
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found U-Boot script /boot.scr
> 1474 bytes read in 32 ms (44.9 KiB/s)
> ## Executing script at 1200
> 3415976 bytes read in 371 ms (8.8 MiB/s)
> 33984 bytes read in 98 ms (337.9 KiB/s)
> 17496691 bytes read in 1231 ms (13.6 MiB/s)
> Booting Debian 4.3.0-1-armmp from mmc 0:1...
> Kernel image @ 0x1200 [ 0x00 - 0x341fa8 ]
> ## Flattened Device Tree blob at 1800
>Booting using the fdt blob at 0x1800
>Using Device Tree in place at 1800, end 1800b4bf
> 
> Starting kernel ...
> 
> [0.098389] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> 
> [1.485042] imx-sdma 20ec000.sdma: firmware: failed to load 
> imx/sdma/sdma-imx6q.bin (-2)
> [1.544474] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> [1.551844] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> Loading, please wait...
> [2.221380] imx-gpc 20dc000.gpc: failed to get pu regulator: -517
> [2.257486] ERROR: could not get clock /usdhc1_pwrseq:ext_clock(0)
> 

Re: sheeveplug new u-boot - just to make sure I've got it right...

[Rick Thomas]

On Jan 22, 2016, at 8:09 PM, Martin Michlmayr  wrote:

>> 
>> If this is correct, it needs to be reflected in a README file in,
>> for example, the /usr/share/doc/u-boot-tools/examples directory.
>> And a pointer to that README needs to be placed in
>> /usr/share/doc/u-boot-tools/examples/sheevaplug.config
> 
> I would simply add a comment to
> /usr/share/doc/u-boot-tools/examples/sheevaplug.config about it.

I'll take that as a "yes" and submit a wishlist bug to have that added to the 
"examples" file.

Thanks!
Rick