Is any work planned for devuan on the raspberry pi 4?

tuxd3v · 2020-01-19 22:07:33

uther wrote:

Unfortunately beta doesn't work neither. Checked both with arm_control=0x200 and arm_64bit=1. Exactly the same output as with the alpha.

Some things should need to be troubleshooted..

uther wrote:

EDIT:
changed kernel=RPi4_u-boot.bin to kernel=vmlinuz-5.5.0-rc6+ - green led flashed couple times more, but the final output is the same.
Checked both kernel links with arm_control=0x200 and arm_64bit=1 variants.

Can you test with this config below, in '/boot/config.txt?

# Serial console output!
enable_uart=1

# 64bit-mode
arm_64bit=1
# arm_control=0x200

# Use U-Boot
kernel=RPi4_u-boot.bin

device_tree_address=0x100
device_tree_end=0x80000

dtparam=i2c_arm=on
dtparam=spi=on

Also can you attach a serial debugger if you have one, serial to usb converter, and check the output?
to configure the device as root in yout computer:
~# stty -F /dev/your_tty_USB_Serial_converter 115200
then to capture the output:
~# cat /dev/your_tty_USB_Serial_converter

then apply power, to rpi4, and please, post the uart log..
thanks for your testing..

EDIT1: does you have the last bootloader firmware?
RPi4 have a small flash that is used to boot usually..
That flash holds the bootcode.bin binary usually found in /boot...
I deleted it because I though that all RPi4 come with flash bootcode.bin... can you copy the bootcode.bin to /boot and test?

EDIT2: bootcode.bin was put in the share, the idea is copying it to /boot on the beta image sdcard..

1) Copy 'bootcode.bin'..
2) Certify you have in 'config.txt':

# 64bit-mode
arm_64bit=1

# Use U-Boot
kernel=RPi4_u-boot.bin

3) Configure uart to get the bootlog( see above ):
~# stty -F /dev/your_tty_USB_Serial_converter 115200
then to capture the output:
~# cat /dev/your_tty_USB_Serial_converter
4) then powerup rpi4 and see if it boots now with ( bootcode,bin present in /boot ).
5) If it doesn't work, then change 'config.txt', accordingly with above parameters..
6) configure uart,
7) powerup rpi4
8) if it doesn't work,
uboot has a configuration file there boot.cmd..
inside it is configured a environment variable called 'fdtfile' ( setenv fdtfile broadcom/bcm2711-rpi-4-b.dtb )

we need to find a way to tell directly to 'config.txt', what file it should look for..

Last edited by tuxd3v (2020-01-19 23:22:19)

uther · 2020-01-20 00:11:15

tuxd3v wrote:

Can you test with this config below, in '/boot/config.txt?

Will try to find some time during week and post the result. If not, we need to wait until next weekend.

tuxd3v wrote:

Also can you attach a serial debugger if you have one, serial to usb converter, and check the output?

I don't have usb debugger right now. I'll need to buy one, so that will take a while.

tuxd3v wrote:

EDIT1: does you have the last bootloader firmware?

I will need to check this. As far as I know RPi4 is pretty buggy, so there might be firmware update available.
Thanks for guidence.

tuxd3v · 2020-01-20 00:41:57

Hello Uther,
Was a pleasure!

Sad we don't succeed at first try,
But we are not so far away from success, we are almost there..

Thanks for your help on debugging, and trying out this image!
Ok, we will wait until you have some spare time to test, no problem.

EDIT: I think I found out why it doesn't boot
I tried a git pull to update my mainline branch...and I think I forgot to explicitly tell on the Makefile that I want vmlinux uncompressed

The first image was nice on this, but I believe the second as this fault..
I will check everything again.. not that 5.5-rc7 is here..

Best Regards,
tux

Last edited by tuxd3v (2020-01-20 01:25:23)

tuxd3v · 2020-01-25 02:42:55

hello,
In the mean time, if anyone( uther ? ), has some spare time. it would be nice to debug a devuan based image for rpi4
I was thinking in changing the '/etc/default/rng-tools' to point to '/dev/urandom'( as a way to continue the debugging of last weekend ).
It could be that there are no TRNG driver in the kernel for rpi4( kernel 5.5 is the first one to support it.. ).

In this way, we could eliminate a possibility of error on boot..

It can be done also by anyone who has a rpi4,
Burning the image and then going to '/etc/default/rng-tools', and set rng to '/dev/urandom':
HRNGDEVICE=/dev/urandom

Last edited by tuxd3v (2020-01-25 02:44:48)

uther · 2020-01-25 14:20:44

Ok, so I've manage to do followng tests:

1. Changing those didn't do much. I still dont have debugger, so I assume those are unrelevant in that situation.

# Serial console output!
enable_uart=1

# 64bit-mode
arm_64bit=1
# arm_control=0x200

# Use U-Boot
kernel=RPi4_u-boot.bin

device_tree_address=0x100
device_tree_end=0x80000

dtparam=i2c_arm=on
dtparam=spi=on

2. Tried the following too. No result. Boot still hangs on rainbow screen.

tuxd3v wrote:

Burning the image and then going to '/etc/default/rng-tools', and set rng to '/dev/urandom':
HRNGDEVICE=/dev/urandom

Right now I'm starting from factory image. I will extract newest bootloader and repeat the procedure.

It could be helpful if someone else who also have RPi4 check the beta image with provided tweaks and confirm our results here. After reading a little bit about RPI4 I'm not very confident about the hardware itself.

tuxd3v · 2020-01-26 05:31:05

You are right uther,
Any person that has a RaspberryPi4, would be nice to helping us out.
Maybe someone could have a usb-serial adapter( plus rpi4.. ) and can help.

For what I read, the booting process of raspberry pi4 is a lot different from the older versions..
The boot-loader is loaded from flash, as soon ad the processor starts to initialise on boot( what previously was known as 'bootcode.bin'.. now is in that flash.. )..

Indeed, I also read about it, the bootloader is been updated because it was very basic, with only sd-card support( at beginning.. ), but here we are also only using sd-card, anyway..
Nevertheless, could be that the developing of it changes the way things were working..
There are also the fact that its not possible yet to use the 4GB Ram, due to the fact that only the 1st 1GB RAM is dma capable..
So 'config.txt', will need one more thing at least..
total_mem=3072

I updated the share with newer kernels, from linux-mainline to 5.5-rc7( with last week developments.. )

We need at least, has additions, in 'config.txt':
arm_64bit=1
kernel=RPi4_u-boot.bin
total_mem=3072

Tomorrow( ..or Today... 5:24H here.. ) maybe I will release a new Image If I find evidences of what is missing..

Last edited by tuxd3v (2020-01-26 05:32:20)

Camtaf · 2020-01-26 11:05:38

I'm only an end user, not a developer, but I could dig out my RPi4B, & give your image a go, sometime next week, probably.

Where can I download the RPi4 image from?

tuxd3v · 2020-01-26 17:03:28

Camtaf wrote:

I'm only an end user, not a developer, but I could dig out my RPi4B, & give your image a go, sometime next week, probably.
Where can I download the RPi4 image from?

Hello Camtaf, the Image is Here, with the last kernel 5.5-rc7 also in the share and other stuff..

It would be nice if you have a usb-serial converter, to analyse the boot process..

uther · 2020-01-26 17:50:18

Camtaf wrote:

I'm only an end user, not a developer,

Same here.

About serial debugger. I'll have it around wednesday, and I've scheduled free time, so we might accually make some progress.

tuxd3v · 2020-01-27 02:19:07

Kernel 5.5 is out, but not yet on the mirrors..
So I will await its release and will make new kernels..

I read a bit about ARMSTUB... which seems to be a thing that is executed by the graphics card or so..
I start to think that we need it somehow

You guys can comfirm you are able to boot with 'Raspbian Buster Lite' from '2019-09-26' ?
There are no armstub there( at least not visible.. )... maybe in 'start.elf'..don't know..

Without a serial connector we can only guess

Last edited by tuxd3v (2020-01-27 02:28:10)

Camtaf · 2020-01-27 16:06:00

Your link keeps on failing to download for me, tried several times yesterday, & a couple of times today.

tuxd3v · 2020-01-27 18:43:10

Camtaf wrote:

Your link keeps on failing to download for me, tried several times yesterday, & a couple of times today.

what do you mean by keep failing?

You click on the link then,
A shared folder appears, to download something, you need to click on that specific file you want to download, and then the download will start..

Are you still facing problems?

Camtaf · 2020-01-27 19:18:23

I know how to download, but it just fails after a few minutes for some reason, I managed to get about 20MB once.

Edit: Literally just tried again & it failed after downloading just 25MB.

Last edited by Camtaf (2020-01-27 19:21:13)

tuxd3v · 2020-01-27 20:02:41

Camtaf wrote:

I know how to download, but it just fails after a few minutes for some reason, I managed to get about 20MB once.
Edit: Literally just tried again & it failed after downloading just 25MB.

The kernel file only has 25MB, you need to click per file..

Right now I am downloading the Image( 'devuan-ascii-rpi4-arm64-0.1-beta.img.xz' ) which is more than 500MB, and I am going with ~136Mb already..
I am not experiencing that problem..

Is anybody else, experiencing that problem?

Camtaf · 2020-01-27 20:26:30

devuan-ascii-rpi4-arm64-0.1-beta.img.xz is the one I've been trying to get.

tuxd3v · 2020-01-27 22:58:36

Camtaf wrote:

devuan-ascii-rpi4-arm64-0.1-beta.img.xz is the one I've been trying to get.

I succeeded downloading it
Could be that for some reason, after some extent you are limited in MB?

uther · 2020-01-27 23:39:20

I've flashed newest bootloader and double checked it with Raspbian image,
https://www.raspberrypi.org/documentati … teeprom.md
https://www.raspberrypi.org/downloads/
It's working properly, and the results are consistent - that's for the good news.

But, after downloading your recent build and applying:
arm_64bit=1
kernel=RPi4_u-boot.bin
total_mem=3072
we are still stuck at rainbow square. After plugin power, the green led is blinking with a distinctive and consistent pattern. So for my understanding, the hardware is fine, we're just missing something that might be revealed with serial debugger. Hopefully we will know in a couple of days.

And just for confirmation, I didn't have any problems with downloading build image and kernel. Camtaf - check your download speeds with different machine, check different download files on the same machine, and repeat it with different internet service provider.

EDIT:
With the following config green led flashes 7 times (kernel not found according to: https://elinux.org/R-Pi_Troubleshooting … c_pattern)
kernel=RPi4_u-boot.bin
#kernel=vmlinuz-5.5.0-rc6+

And with this one, green led does not flash at all:
#kernel=RPi4_u-boot.bin
kernel=vmlinuz-5.5.0-rc6+

Last edited by uther (2020-01-28 00:42:19)

tuxd3v · 2020-01-28 01:15:58

uther, thanks a lot for the detailed info..
A lot of progress was already made by you!

I will create a new Image with the Last 5.5 kernel, and with a smaller name on the kernel
A possibility could also be check if renaming the kernel to vmlinuz, or kernel.img works..

I will notice you about the new Image.
Thanks a lot!

EDIT:
Updated a new Image to the Share: 'devuan-ascii-rpi4-arm64-0.2-beta.img.xz'
The Image is already with a hand installed 'linux-image-5.5.0-2_arm64.deb'
'Kernel/headers/Libc-dev' deb packages for '5.5.0' is also in the share( in the event of Success, can be copied to sdcard and installed via 'dpkg -i' )..

'/etc/default/rng-tools'
Point automatically to '/dev/urandom'( just in case.. when we managed to boot it, we will see if a driver exists, we will change to it.. ), in the meantime..
HRNGDEVICE=/dev/urandom

'config.txt'
arm_64bit=1
kernel=bootloader.bin
total_mem=3072

'bootloader.bin':
Is the u-boot that then will load the 'vmlinuz'

'boot.cmd'
The same content as 'boot.scr', but is a text readable file

'boot.scr'
Is the binary file uboot will load with all the instructions to start the Linux Kernel for Raspberry Pi4( now..if it just worked would be nice )

'vmlinuz'
Is the Linux Kernel... the name contains a 'z'( vmlinuz ), but the Image is not compressed, so its a 'vmlinux' binary file ( in ARM64 is impossible to boot compressed Kernels, at least for now.. ).
So even tough the name suggests compression its a uncompressed kernel..

The Idea..
config.txt -> bootloader.bin->uboot.scr->vmlinux init=/sbin/init

In this process I don't really know, what happens with the 'start.elf'( till now they were loaded by the Graphics card, in charge of the boot-up process..don't know if that remains the same, or we will need the 'armstubs' compiled for 64 bits to run in the graphics card.. ).

One thing is for sure.. 'start.elf' binaries are 32 bits files..
I don't know if when we do arm_64bit=1 in 'config.txt', the 'start.elf' can be loaded has they are armhf( 32bits.. )..

So we have 2 possibilities at least,
The flashing leds informing a 'kernel.img' file is missing, or informing 'start.elf' cannot be loaded by the graphics.. and so neither the kernel will..

Last edited by tuxd3v (2020-01-28 03:27:23)

Camtaf · 2020-01-28 09:37:16

tuxd3v wrote:

Camtaf wrote:
devuan-ascii-rpi4-arm64-0.1-beta.img.xz is the one I've been trying to get.
I succeeded downloading it
Could be that for some reason, after some extent you are limited in MB?

No problem downloading other distros, even DVD images, but just can't get passed 20~30MB from your storage site, even had another go just before writing this. So, I guess, that's it, I won't be able to help.

uther · 2020-01-28 13:19:48

tuxd3v, I could use some help with the debugger.

I bought USB-TTL USB-STC-ISP, exactly this one: https://www.instructables.com/id/Usb-to … L-adapter/

I've connected it to RPi according to pin layout:
GND-GND
TxD-RxD
RxD-TxD

In config.txt:

# Serial console output!
enable_uart=1

# 64bit-mode
arm_64bit=1
# arm_control=0x200

# Use U-Boot
kernel=RPi4_u-boot.bin    <--------- file is present in /boot/, and have correct file name

device_tree_address=0x100
device_tree_end=0x80000

dtparam=i2c_arm=on
dtparam=spi=on

total_mem=3072

gpu_mem=16
#kernel=vmlinuz-5.5.0-rc6+

Next, I've followed your instructions, setted up the connection as root with:
stty -F /dev/ttyUSB0 115200, and output with cat /dev/ttyUSB0.
The connection is estabilished, but there's no output to the console, when Im plugging power to the RPi.
I've tried to troubleshoot with this guide: https://elinux.org/RPi_Serial_Connection and added my user to dialout group.
Whether I'm accesing tty as user with correct group, or as root, theres no output after powering RPi.
Tried with:
cat /dev/ttyUSB0
screen /dev/ttyUSB0
screen /dev/ttyUSB0 115200

On the machine I'm using for capturing, kernel has the PL2303 driver installed.
CONFIG_USB_SERIAL_PL2303=m

sudo dmesg | grep tty gives:

[ 1209.718430] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 1221.092566] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 1468.621269] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 1594.576567] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 1715.481278] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3050.089986] pl2303 ttyUSB0: error sending break = -19
[ 3050.090129] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3098.506171] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3255.185416] pl2303 ttyUSB0: error sending break = -19
[ 3255.185575] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3257.841291] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3268.828574] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3270.869657] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3387.865337] pl2303 ttyUSB0: error sending break = -19
[ 3387.865493] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3389.352299] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3487.065227] pl2303 ttyUSB0: pl2303_set_control_lines - failed: -19
[ 3487.065233] pl2303 ttyUSB0: error sending break = -19
[ 3487.065388] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3590.681308] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3772.265710] pl2303 ttyUSB0: pl2303_set_control_lines - failed: -19
[ 3772.265715] pl2303 ttyUSB0: error sending break = -19
[ 3772.265865] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 6065.041277] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 6200.681839] pl2303 ttyUSB0: error sending break = -19
[ 6200.681993] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 6202.233228] usb 1-2: pl2303 converter now attached to ttyUSB0

Also tried with minicom. Followed this setup guide: https://www.tincantools.com/minicom/
And theres no output either.

tuxd3v · 2020-01-28 16:16:16

Hello uther,
Thanks a lot for the effort..

If you unplug and plug it again in your computer what is the 'dmesg' output( last information of it )?
try debugging the output of the boot process with the Raspbian image..to test it..
( If you succeed, then try with the new Image 'devuan-ascii-rpi4-arm64-0.2-beta.img.xz' )

And see if you get something..
Maybe the USB device is numbered differently.. I usually get on my device 'ttyUSB0'.

Edit: I forgot,
The RX of Converter is connected to the TX, of the Board
The TX of Converter is connected to the RX of the board

Last edited by tuxd3v (2020-01-28 16:41:02)

tuxd3v · 2020-01-28 16:43:20

No problem downloading other distros, even DVD images, but just can't get passed 20~30MB from your storage site, even had another go just before writing this. So, I guess, that's it, I won't be able to help.

You should be doing something wrong, or having your bandwidth very restricted so that a timeout occur.. what can I say..

tuxd3v · 2020-01-30 17:10:14

uther wrote:

tuxd3v, I could use some help with the debugger.

I bought USB-TTL USB-STC-ISP, exactly this one: https://www.instructables.com/id/Usb-to … L-adapter/

I've connected it to RPi according to pin layout:
GND-GND
TxD-RxD
RxD-TxD

sudo dmesg | grep tty gives:

[ 1209.718430] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 1221.092566] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 1468.621269] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 1594.576567] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 1715.481278] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3050.089986] pl2303 ttyUSB0: error sending break = -19
[ 3050.090129] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3098.506171] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3255.185416] pl2303 ttyUSB0: error sending break = -19
[ 3255.185575] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3257.841291] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3268.828574] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3270.869657] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3387.865337] pl2303 ttyUSB0: error sending break = -19
[ 3387.865493] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3389.352299] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3487.065227] pl2303 ttyUSB0: pl2303_set_control_lines - failed: -19
[ 3487.065233] pl2303 ttyUSB0: error sending break = -19
[ 3487.065388] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 3590.681308] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 3772.265710] pl2303 ttyUSB0: pl2303_set_control_lines - failed: -19
[ 3772.265715] pl2303 ttyUSB0: error sending break = -19
[ 3772.265865] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 6065.041277] usb 1-2: pl2303 converter now attached to ttyUSB0
[ 6200.681839] pl2303 ttyUSB0: error sending break = -19
[ 6200.681993] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[ 6202.233228] usb 1-2: pl2303 converter now attached to ttyUSB0

Also tried with minicom. Followed this setup guide: https://www.tincantools.com/minicom/
And theres no output either.

Humm,
maybe trying a modprobe pl2303 debug=1, but I don't know if that will wok anyway, maybe it needs kernel kconfig:
CONFIG_DYNAMIC_DEBUG=y

Sometimes not seeing information have nothing to do with the adapter, but with the bootloader..
I get that same behaviour, on OrangePi OnePlus, that is a pita for it to work..
sometimes 10 restarts are not enough for it, to start printing info to the serial..

Last edited by tuxd3v (2020-01-30 17:14:04)

uther · 2020-01-31 17:55:10

The cables are fine, I've triple-check them.
But I think, I've found the answer:
https://raspberrypi.stackexchange.com/q … e-of-no-os
https://www.raspberrypi.org/documentati … _config.md

It looks that BOOT_UART=1 needs to be set in EEPROM config.

EDIT:
And we have ~~partial~~ a success!
Raspbian boot process. I've included poweroff at the end.

PM_RSTS: 0x00001000

RPi: BOOTLOADER release VERSION:5e86aac5 Jan 17 2020 17:37:13 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1579282631 0x4fb027ee 0x00c03111

uSD voltage 3.3V 1

SD_BOOT

SD HOST: 200000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2000 (1000) status: 0x1fff0000 delay: 1080

SD HOST: 200000000 CTL0: 0x00000f00 BUS: 100000 Hz actual: 100000 HZ div: 2000 (1000) status: 0x1fff0000 delay: 1080

CID: 000353445343313647805210374a0119

CSD: 400e00325b59000076b27f800a404000

CSD: VER: 1 logical blocks: 30386 mult: 1024 rd(len: 512 partial: 0 misalign: 0) sectors: 31116288

SD: bus-width: 4 spec: 2 SCR: 0x02358443 0x00000000

SD HOST: 200000000 CTL0: 0x00000f04 BUS: 40000000 Hz actual: 33333333 HZ div: 6 (3) status: 0x1fff0000 delay: 2

MBR: 0x00000800,  523343 type: 0x0e

MBR: 0x0008044f,30590897 type: 0x05

MBR: 0x00000000,       0 type: 0x00

MBR: 0x00000000,       0 type: 0x00

part-offset: 2048 oem:  MSWIN4.1 volume:  NO NAME    

rsc: 16 sectors-per-fat: 256 clusters: 65347 cluster-size: 8 root-dir: 1 root-sectors: 32

WEL: 0x00000a10 0x0008044e

PM_RSTS: 0x00001000

Partition: 0

part-offset: 2048 oem:  MSWIN4.1 volume:  NO NAME    

rsc: 16 sectors-per-fat: 256 clusters: 65347 cluster-size: 8 root-dir: 1 root-sectors: 32

Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200

Loading recover4.elf hnd: 0x00008b9c

Loading fixup4rc.dat hnd: 0x00000000

Missing/empty 'fixup4rc.dat' - continuing boot (6)

MEM GPU: 76 ARM: 948 TOTAL: 1024

Starting recover4.elf @ 0xcfa00200

PM_RSTS: 0x00001034

RPi: BOOTLOADER release VERSION:5e86aac5 Jan 17 2020 17:37:13 BOOTMODE: 0x00000006 part: 6 BUILD_TIMESTAMP=1579282631 0x4fb027ee 0x00c03111

uSD voltage 3.3V 1

SD_BOOT

SD HOST: 200000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2000 (1000) status: 0x1fff0000 delay: 1080

SD HOST: 200000000 CTL0: 0x00000f00 BUS: 100000 Hz actual: 100000 HZ div: 2000 (1000) status: 0x1fff0000 delay: 1080

CID: 000353445343313647805210374a0119

CSD: 400e00325b59000076b27f800a404000

CSD: VER: 1 logical blocks: 30386 mult: 1024 rd(len: 512 partial: 0 misalign: 0) sectors: 31116288

SD: bus-width: 4 spec: 2 SCR: 0x02358443 0x00000000

SD HOST: 200000000 CTL0: 0x00000f04 BUS: 40000000 Hz actual: 33333333 HZ div: 6 (3) status: 0x1fff0000 delay: 2

MBR: 0x00000800,  523343 type: 0x0e

MBR: 0x0008044f,30590897 type: 0x05

MBR: 0x00000000,       0 type: 0x00

MBR: 0x00000000,       0 type: 0x00

part-offset: 2048 oem:  MSWIN4.1 volume:  NO NAME    

rsc: 16 sectors-per-fat: 256 clusters: 65347 cluster-size: 8 root-dir: 1 root-sectors: 32

WEL: 0x00000a10 0x0008044e

PM_RSTS: 0x00001034

Partition: 6

EBR: 0x0008044f 0x00001bb1,   65534 0x00011baf,30518274 signature: aa55

EBR: 0x00091ffe 0x00000002,  524286 0x00091baf,29993986 signature: aa55

MBR: 0x00000002,  524286 type: 0x0c

part-offset: 598016 oem:  mkfs.fat volume:  boot       

rsc: 32 sectors-per-fat: 4033 clusters: 516188 cluster-size: 1 root-dir: 2 root-sectors: 0

WEL: 0x00093fa2 0x00111ffd

Loading config.txt hnd: 0x00033fb9

Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200

Loading recover4.elf hnd: 0x00000000

Failed to read recover4.elf error: 6

Loading recovery.elf hnd: 0x00000000

Failed to read recovery.elf error: 6

Loading start4.elf hnd: 0x0002e632

Loading fixup4.dat hnd: 0x00033f79

MEM GPU: 76 ARM: 948 TOTAL: 1024

FIXUP src: 128 256 dst: 948 1024

Starting start4.elf @ 0xfec00200

=========================================================
POWEROFF
=========================================================

PM_RSTS: 0x00000575

RPi: BOOTLOADER release VERSION:5e86aac5 Jan 17 2020 17:37:13 BOOTMODE: 0x00000006 part: 63 BUILD_TIMESTAMP=1579282631 0x4fb027ee 0x00c03111

Halt: wake: 1 power_off: 0

=========================================================
devuan-ascii-rpi4-arm64-0.2-beta.img boot

PM_RSTS: 0x00001000

RPi: BOOTLOADER release VERSION:5e86aac5 Jan 17 2020 17:37:13 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1579282631 0x4fb027ee 0x00c03111

uSD voltage 3.3V 1

SD_BOOT

SD HOST: 200000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2000 (1000) status: 0x1fff0000 delay: 1080

SD HOST: 200000000 CTL0: 0x00000f00 BUS: 100000 Hz actual: 100000 HZ div: 2000 (1000) status: 0x1fff0000 delay: 1080

CID: 000353445343313647805210374a0119

CSD: 400e00325b59000076b27f800a404000

CSD: VER: 1 logical blocks: 30386 mult: 1024 rd(len: 512 partial: 0 misalign: 0) sectors: 31116288

SD: bus-width: 4 spec: 2 SCR: 0x02358443 0x00000000

SD HOST: 200000000 CTL0: 0x00000f04 BUS: 40000000 Hz actual: 33333333 HZ div: 6 (3) status: 0x1fff0000 delay: 2

MBR: 0x00002000,  524288 type: 0x0b

MBR: 0x00082000, 2867200 type: 0x83

MBR: 0x00000000,       0 type: 0x00

MBR: 0x00000000,       0 type: 0x00

part-offset: 8192 oem:  mkfs.fat volume:  boot       

rsc: 32 sectors-per-fat: 4033 clusters: 516190 cluster-size: 1 root-dir: 2 root-sectors: 0

WEL: 0x00003fa2 0x00081fff

PM_RSTS: 0x00001000

Partition: 0

part-offset: 8192 oem:  mkfs.fat volume:  boot       

rsc: 32 sectors-per-fat: 4033 clusters: 516190 cluster-size: 1 root-dir: 2 root-sectors: 0

Loading config.txt hnd: 0x000400a2

Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200

Loading recover4.elf hnd: 0x00000000

Failed to read recover4.elf error: 6

Loading recovery.elf hnd: 0x00000000

Failed to read recovery.elf error: 6

Loading start4.elf hnd: 0x0000f80a

Loading fixup4.dat hnd: 0x000002e5

MEM GPU: 76 ARM: 948 TOTAL: 1024

FIXUP src: 128 256 dst: 948 1024

Starting start4.elf @ 0xfec00200

Last edited by uther (2020-01-31 19:12:08)

tuxd3v · 2020-01-31 19:12:01

uther wrote:

The cables are fine, I've triple-check them.
But I think, I've found the answer:
https://raspberrypi.stackexchange.com/q … e-of-no-os
https://www.raspberrypi.org/documentati … _config.md
It looks that BOOT_UART=1 needs to be set in EEPROM config.
EDIT:
And we have partial success!
Raspbian boot process. I've included poweroff at the end.

Nice Job!!

The first link you showed it prints a emmc controller, arasan-emmc0,
I don't know If I included this driver, in Kernel Image..
I will check, and if its not there I will update image!

In the mean time , can you please test image 'devuan-ascii-rpi4-arm64-0.2-beta.img.xz' ?

Last edited by tuxd3v (2020-01-31 19:12:34)

The officially official Devuan Forum!

#26 2020-01-19 22:07:33

Re: Is any work planned for devuan on the raspberry pi 4?

#27 2020-01-20 00:11:15

Re: Is any work planned for devuan on the raspberry pi 4?

#28 2020-01-20 00:41:57

Re: Is any work planned for devuan on the raspberry pi 4?

#29 2020-01-25 02:42:55

Re: Is any work planned for devuan on the raspberry pi 4?

#30 2020-01-25 14:20:44

Re: Is any work planned for devuan on the raspberry pi 4?

#31 2020-01-26 05:31:05

Re: Is any work planned for devuan on the raspberry pi 4?

#32 2020-01-26 11:05:38

Re: Is any work planned for devuan on the raspberry pi 4?

#33 2020-01-26 17:03:28

Re: Is any work planned for devuan on the raspberry pi 4?

#34 2020-01-26 17:50:18

Re: Is any work planned for devuan on the raspberry pi 4?

#35 2020-01-27 02:19:07

Re: Is any work planned for devuan on the raspberry pi 4?

#36 2020-01-27 16:06:00

Re: Is any work planned for devuan on the raspberry pi 4?

#37 2020-01-27 18:43:10

Re: Is any work planned for devuan on the raspberry pi 4?

#38 2020-01-27 19:18:23

Re: Is any work planned for devuan on the raspberry pi 4?

#39 2020-01-27 20:02:41

Re: Is any work planned for devuan on the raspberry pi 4?

#40 2020-01-27 20:26:30

Re: Is any work planned for devuan on the raspberry pi 4?

#41 2020-01-27 22:58:36

Re: Is any work planned for devuan on the raspberry pi 4?

#42 2020-01-27 23:39:20

Re: Is any work planned for devuan on the raspberry pi 4?

#43 2020-01-28 01:15:58

Re: Is any work planned for devuan on the raspberry pi 4?

#44 2020-01-28 09:37:16

Re: Is any work planned for devuan on the raspberry pi 4?

#45 2020-01-28 13:19:48

Re: Is any work planned for devuan on the raspberry pi 4?

#46 2020-01-28 16:16:16

Re: Is any work planned for devuan on the raspberry pi 4?

#47 2020-01-28 16:43:20

Re: Is any work planned for devuan on the raspberry pi 4?

#48 2020-01-30 17:10:14

Re: Is any work planned for devuan on the raspberry pi 4?

#49 2020-01-31 17:55:10

Re: Is any work planned for devuan on the raspberry pi 4?

#50 2020-01-31 19:12:01

Re: Is any work planned for devuan on the raspberry pi 4?

Board footer