bootloader for quartz64-a

[jyoung]

Okay, lsusb give me:

Code: Select all

Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P

[pingtoo]

Okay, lsusb give me:

Code: Select all

Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P

Indeed, pl2303 use FTDI. so you are OK at your PC end.

Now can you tell us what you see when you connect from your PC to your board when very first time power on?

The idea is u-boot (Not linux kernel) should produce something to serial port (aka "UART Debug ports"). Note you may or may not able to type in anything because connection parameters, but you should be able to see something even gibberish is OK at this point. Because I just want to confirm we have pins connection correctly (So, TX is sending to RX).

If it is possible capture the output from the very first power on (gibberish is OK) so we can get in sync with current condition.

One possibility is everything is OK but the PC end display system is doing funny thing (unlikely but need to rule out).

Please note this is not contradict to my proposal of doing thing with one step at a time. We are not trying to change u-boot, we just want to be able to access console in order for later gentoo install step.

Currently we assume you are booting off SD, can you confirm this? assume the SD card contain armbian, can you tell use what version of armbian or how did you flash the armbian on to the SD card?

Sorry for many questions, but I need to understand the condition in order to research where may have gone wrong.

One more question, the board is a brand new board, not second hand right? just want to be sure it has known quality. usually manufacturer unlikely deliver a bad system board that have no way to connect.

[NeddySeagoon]

pingtoo,

Don't we need the loopback test first?

If the PC cannot talk to itself, it probably can't talk to anything else either.

[pingtoo]

pingtoo,

Don't we need the loopback test first?

If the PC cannot talk to itself, it probably can't talk to anything else either.

I think in previous post we already did some loop back test and proven it did work. The reason I ask to check driver on PC is just in case wrong driver somehow magically worked in loop back mode.

As far as I see the current state is unclear and we should try to get in sync so we eliminate possibility.

[NeddySeagoon]

pingtoo,

I'm confused too.

Code: Select all

CONFIG_USB_SERIAL_PL2303: USB Prolific 2303 Single Port Serial Driver 

is the driver for a PL2303 Serial Port

[pingtoo]

pingtoo,

I'm confused too.

Code: Select all

CONFIG_USB_SERIAL_PL2303: USB Prolific 2303 Single Port Serial Driver 

is the driver for a PL2303 Serial Port

Neddy, I am not sure I understand you. Are you confused if the CONFIG_USB_SERIAL_PL2303 is the right driver? or why it isn't working?

[jyoung]

I'm not sure if this will help, but the full command I'm running is

Code: Select all

lsusb

and the output I get is

Code: Select all

Bus 001 Device 003: ID 413c:2113 Dell Computer Corp. KB216 Wired Keyboard
Bus 001 Device 005: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P
Bus 001 Device 004: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. JMS567 SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

'

If I unplug the UART/USB adapter from my PC's USB port and run this again, the output is the same, except missing the "Device 005"

Relating back to the boot loader, I the armbian image has a folder /boot/extlinux containing extlinux.conf. I think it's using extlinux instead of u-boot, which I'm reading is a variant of syslinux:

https://wiki.gentoo.org/wiki/Syslinux

[NeddySeagoon]

jyoung,

Bus 001 Device 005: ID 067b:2303

The Vendor and Device IDs are supposed to uniquely identify your device.
That needs CONFIG_USB_SERIAL_PL2303 in your kernel.

CONFIG_USB_SERIAL_FTDI_SIO is for a different device. That would have been OK for the other board, which has one of those embedded, so you only need a USB-A to USB-C cable.

For the avoidance of doubt, your PC kernel needs CONFIG_USB_SERIAL_PL2303 as either built in or a module.
Then you can try the loopback test.
Then try for real.

If I seem to me labouring this, it's not clear to me if you have CONFIG_USB_SERIAL_PL2303 in your PC kernel nor if the loopback test worked with the Rx/Tx pins connected.

syslinux is a cross between legacy grub and lilo for configuration files.
I use it on my main PC

[pingtoo]

Relating back to the boot loader, I the armbian image has a folder /boot/extlinux containing extlinux.conf. I think it's using extlinux instead of u-boot, which I'm reading is a variant of syslinux:

https://wiki.gentoo.org/wiki/Syslinux

I think this is actually u-boot function. One of u-boot automate boot feature use extlinux menu to execute boot command sequence.

[jyoung]

The kernel I've been running on the PC has CONFIG_USB_SERIAL_PL2303=y. I just updated it with CONFIG_USB_SERIAL_CP210X=y.

[NeddySeagoon]

jyoung,

Loopback should work with any baud rate, parity and stop bit setting as the PC serial ports were crippled at birth to not support split baud rates.
No, 1200/75 in the USA, like early on line services in Europe. e.g. Prestel in the UK.

As long as hardware and software hand shaking are both off and you are using the kernel with USB_SERIAL_PL2303=y :) , it should work.

[jyoung]

Okay, I just tried the loopback test again, still nothing. Just to double check that I'm doing everything right, here's my procedure:

I plug in the usb/serial uart device to a usb port on the PC, and then run minicom with

Code: Select all

minicom -D /dev/ttyUSB0

I then connect the white and green leads (RX and TX), and then type into minicom. Is that right?

[NeddySeagoon]

jyoung,

You also need to disable handshaking but that's right as far as it goes.

If /dev/ttyUSB0 did not exist, minicom would shout at you.

You need to be in the group that /dev/ttfUSB0 belongs to for it to work as your user.

Code: Select all

$ ls /dev/ttyUS* -l
crw-rw---- 1 root uucp 188,  0 Nov  4  2021 /dev/ttyUSB0

uucp is probably wrong these days.

[jyoung]

NeddySeagoon, thanks for the help with the serial port. I looked back through the thread, and you mentioned earlier that it might not work with hardware flow control on. It was on, and when I disabled it the loopback test work.

I've also been working on the earlier suggestion, of using the bootloader from the working armbian image. I actually just got that to work with gentoo, and I'll shortly write up a thorough description of what worked for future readers.

However, now that I have gentoo running on the quartz64a board, am I seeing a very strange issue: every time it reboot, it has a different mac address. I'm not sure how that's even possible. While that would be really cool if I was hacker, it's kind of a problem for daily use. Does anyone know what might be causing it, or how to stop the mac address from changing?

[pingtoo]

However, now that I have gentoo running on the quartz64a board, am I seeing a very strange issue: every time it reboot, it has a different mac address. I'm not sure how that's even possible. While that would be really cool if I was hacker, it's kind of a problem for daily use. Does anyone know what might be causing it, or how to stop the mac address from changing?

I wonder if it came from u-boot. I seen u-boot source code do MAC setup. however I don't know specific for your board.

[jyoung]

Interesting idea! Since it looks like u-boot is reading the extlinux configuration file, maybe there are some clues there. Here's what boot/extlinux.conf looks like

Code: Select all

label Armbian
  kernel /boot/Image
  initrd /boot/initramfs-6.4.8-gentoo.img
  fdt /boot/dtb/rockchip/rk3566-quartz64-a.dtb
  append root=/dev/mmcblk1p2 console=ttyS02,1500000 console=tty0 rw no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 splash plymouth.ignore-serial-consoles

When I boot up, the hdmi doesn't show anything until the linux kernel loads. But, now that it looks like the uart is working, I'll try rebooting and see if I can get anything from u-boot over the serial port.

[jyoung]

Weird, I'm still getting a random string of code from uart. The procedure I'm using is to start minicom with

Code: Select all

minicom -D /dev/ttyUSB0 -b 115200

Then, I turn off hardware flow control in the menu, and power up the device. I've tried switching the RX/TX pins too. When I switch them, I get nothing (which I think is expected). The 115200 is the speed that minicom inside the quartz64a board gives me for /dev/ttyS0 and /dev/ttyS2.

However, I do not actually think that u-boot is the cause of the changing mac address. When I boot into armbian, the mac address is fixed. The gentoo image is using exactly the same bootloader as armbian, since I created the gentoo image by cloning the armbian image and then modifying the kernel and the extlinux.conf, but I did not alter the bootloader.

Instead, I think that there's something about the gentoo install that's causing the mac address to change.

[pingtoo]

Weird, I'm still getting a random string of code from uart. The procedure I'm using is to start minicom with

Code: Select all

minicom -D /dev/ttyUSB0 -b 115200

Then, I turn off hardware flow control in the menu, and power up the device. I've tried switching the RX/TX pins too. When I switch them, I get nothing (which I think is expected). The 115200 is the speed that minicom inside the quartz64a board gives me for /dev/ttyS0 and /dev/ttyS2.

However, I do not actually think that u-boot is the cause of the changing mac address. When I boot into armbian, the mac address is fixed. The gentoo image is using exactly the same bootloader as armbian, since I created the gentoo image by cloning the armbian image and then modifying the kernel and the extlinux.conf, but I did not alter the bootloader.

Instead, I think that there's something about the gentoo install that's causing the mac address to change.

According to u-boot's DTS for your board it should be 1500000n8(or 1500000 is enough) not 115200.

I am just guessing. Once you got serial console working you should be able to see some messages from u-boot, there sometime include messages about setting MAC.

[jyoung]

I also tried 1500000, and I still just got random code.

[jyoung]

This tutorial on how to change a mac address suggests that in gentoo one could edit /etc/conf.d/net

https://en.wikibooks.org/wiki/Hacking/T ... ress/Linux

That file does not exist on the quartz64a board, but I could create it and make the changes. It's still really weird that the mac address would change randomly on each reboot. I've found several threads about this, but in each case the cause was always networkmanager, which is not installed on the quartz64a.

[pingtoo]

I also tried 1500000, and I still just got random code.

I don't know much about "minicom" so I don't know if there thing need to be configure in order to get it right.

If you can try app-misc/screen

Code: Select all

screen /dev/ttyUSB0 1500000

May be we can get luck there.

[pingtoo]

This tutorial on how to change a mac address suggests that in gentoo one could edit /etc/conf.d/net

https://en.wikibooks.org/wiki/Hacking/T ... ress/Linux

That file does not exist on the quartz64a board, but I could create it and make the changes. It's still really weird that the mac address would change randomly on each reboot. I've found several threads about this, but in each case the cause was always networkmanager, which is not installed on the quartz64a.

If you just want to use gentoo to make it stick, If you are using netifrc (I am guessing you are) just modify/create /etc/conf.d/net and add

Code: Select all

mac_eth0="00:11:22:33:44:55"

Replace "eth0" with your board device name.

[jyoung]

Ah, that did it. The mac address is now unchanging.

[jyoung]

To sum up, here's the strategy that worked for in this case:

I started with a minimal armbian image, and burned it to an emmc and an SD card. Then, I booted the board off the SD card, and attached the emmc via a USB/emmc adapter. The goal was to work within the armbian system on the SD card to transform the armbian image on the emmc card into a gentoo install, basically using the armbian bootloader but nothing else.

Why not just put the emmc in the emmc slot? I wanted the gentoo to be installed on the emmc, but the quartz64 will preferentially boot off the emmc instead of the SD card. The USB/emmc adapter was needed so that I could mount and chroot into the emmc while running of the SD card. The adapter was also inexpensive, and has since turned out to be pretty handy.

Once I logged into the armbian system on the SD card, I could see the armbian install on the emmc. The armbian install is setup as a single partition, with /boot as just a folder in the main file system. For me, the emmc's partition showed up as /dev/sda, which is pretty normal for a device connected via USB. For the next step, mount the emmc's partition (I put it on /mnt/gentoo), and delete every fold except boot.

Personally, I wanted several separate partitions for my gentoo install. I unmounted the emmc's partition, shrank it to 250M, (which was possible since most of its content was deleted), and added several more partitions, including a separate partition for /root and /home.

Next, I remounted the first (original) partition on the emmc. The boot folder has a numerous files and folders. You can actually delete most of those too, but keep file config-6.2.0-rc6-media and the folders dtb and extlinux. The dtb folder has the device-tree-binary files for a large number of devices (so this procedure would work on a lot of different devices, right?), but I only needed the quartz64 model a, so I deleted the rest.

The extlinux folder has a file called extlinux.conf. This is important: This is a human-editable text file that the bootloader reads to determine how to load the kernel image. Here's what it looks like originally:

Code: Select all

label Armbian
  kernel /boot/Image
  initrd /boot/uInitrd
  fdt /boot/dtb/rockchip/rk3566-quartz64-a.dtb
  append root=UUID=7f9c9970-93ba-46ca-9f03-f3241712ead8 console=ttyS02,1500000 console=tty0 rw no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 splash plymouth.ignore-serial-consoles

I've actually only edited the root= bit, which now reads root=/dev/mmcblk1p2

Although the name of the emmc when it's connected via the USB is /dev/sda, it gets the name /dev/mmcblk1 it's plugged into the emmc slot, which it has to be when the board is booting off it. /dev/mmcblk1p2 is the name of the second partition on the emmc, which is where I decided to put /root. If you want a monolithic partition like armbian, it would be /dev/mmcblk1p1, or you could just use the UUID as armbian did.

I did not change the label. Maybe I should? That's probably for a text prompt in the u-boot menu, which I never see anyway.

One other quirky thing about this setup: in a normal install, when the boot folder is a separate partition that's mounted at /boot, the files are just in /boot. But, since /boot was a folder on the original monolithic partition, once this setup is complete the boot partition will be mounted at /boot from within the root file system, so the files in the original /boot folder will appear in /boot/boot/. That's why the extlinux.conf file has things like /boot/Image instead of just /Image. So far this quirk doesn't seem to cause any problems.

Next I followed the standard gentoo install steps to setup an OS on the root partition, skipping the bootloader installation. The armbian system that I was logged into allowed me to chroot into the new gentoo system without trouble. When I got to the step of compiling the kernel, I copied the /boot/boot/config-6.2.0-rc6-media to /usr/src/linux/.config, and ran "make olddefconfig" to create a new .config file that had all the needed drivers turned on. Unfortunately, it probably pulled in a lot of drivers that I didn't need for this specific board. I'm trying to go the other way, and start with a minimal .config and turn things on until the board works, but as of now the only working gentoo kernel I have is the one I created based off the armbian config file.

Compile the kernel with the usual, and copy it to the boot folder

Code: Select all

make && make modules_install
/usr/src/linux/arch/arm64/boot/Image to /boot/boot/Image

Finally, we need an initramfs

Code: Select all

dracut --kver 6.4.8-gentoo

where you replace 6.4.8 with your current kernel version. This will put the initramfs file in the /boot folder, but opted to move it to /boot/boot next to the kernel image, and rename it uInitrd as the armbian version was.

I think that's it for the install! There was that weird issue about the MAC address changing at every boot, which we fixed by adding a line to /etc/conf.d/net.