Re: failure trying to install bullseye on Cubox-i
On 2022-07-17, 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. Those sound like reasonable steps... What's confusing is your screen logs shows a u-boot from bookworm/sid: U-Boot SPL 2022.04+dfsg-2+b1 (May 14 2022 - 21:25:25 +) So either the images you downloaded were not the images you thought you downloaded... or you saved the wrong screenlog file... or the bullseye images contain u-boot from the wrong release... or somehow you're loading u-boot from some other media, such as eMMC? I actually need to reinstall a cuboxi4pro maybe by the end of the week, so I will test it myself then. live well, vagrant signature.asc Description: PGP signature
Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... No ethernet detected
On 2021-02-06, Rick Thomas wrote: > 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? Pretty sure it is a kernel bug, since I can make it go away on a similar system by downgrading to linux 5.9.x. Please CC me on the report and I'll try to contribute what I can! live well, vagrant signature.asc Description: PGP signature
Re: Installing Debian Bullseye on Cubox-i4 with eSATA drive... No ethernet detected
On 2021-01-29, 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'm having a similar issue on a hummingboard-i2ex (which is kind of like a single-board-computer variant of the Cubox-i) on an already installed system running linux 5.10.x, while 5.9.x works fine on that system, so seems to be a regression in the kernel. > 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. Pretty sure it is not atheros, but handled by: drivers/net/ethernet/freescale/fec_main.c Not sure what exact module or built-in that ends up in. live well, vagrant signature.asc Description: PGP signature
Re: Installing Debian Buster on Cubox-i4 with eSATA drive.
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! :) live well, vagrant signature.asc Description: PGP signature
Re: Instructions for upgrading U-boot on Marvell OpenRD Base computer?
On 2015-06-02, Rick Thomas wrote: On Jun 2, 2015, at 9:15 AM, Martin Michlmayr t...@cyrius.com wrote: * Rick Thomas rbtho...@pobox.com [2015-05-31 19:11]: No, the Ultimate and Base are different. I just checked and I was going to say that there's support for the Base in DENX. However, I noticed that even the Ultimate target was removed in Debian's u-boot recently: http://anonscm.debian.org/cgit/collab-maint/u-boot.git/commit/debian/targets?id=ea2f6ce84b7788cda2cb7deb29690cb368451e8c So if you want to work out why it doesn't build and whether it boots, I'm sure Vagrant Cascadian would be interested in hearing from you; but it's probably easier to stay with the original u-boot unless that has problems. Thanks for the reply, however discouraging! Currently, I’m running Wheezy on the Base and its sister Ultimate. I haven’t tried Jessie since the formal release, but I will do that and report back soon. I gather from what you say about DTB that that transition does not depend on U-Boot? So I should be able to upgrade to and beyond Jessie without problems? The problem I’m having with Wheezy that makes me think it would be interesting to try a later U-Boot is that the original Marvell U-Boot (from 2009) is balky when booting from USB hard disks and doesn’t support booting from SD at all. If I could boot from SD, I would put /boot there and everything else on the USB disk. As it is, whenever I need to reboot the machine (I’m using it for experimentation, so that happens fairly often.) I need to log in to the serial console so I can watch and restart if booting from the hard drive fails. (Sometimes it fails in a way that requires actual physically re-setting the Base or even power-cycling it, but that’s a different story.) Can you tell me what the most recent U-Boot version is that actually does support the OpenRD Base? I'm able to get both openrd_base and openrd_ultimate to build (no idea if it boots) by disabling MMC support with u-boot 2015.04. But then, it sounds like you're actively looking for MMC support... Another option might be to move where the stored u-boot environment is to allow for a larger u-boot binary, but this breaks backwards compatibility; this may also be an issue for the SheevaPlug and other marvell platforms: https://lists.debian.org/debian-arm/2015/04/msg00023.html https://bugs.debian.org/781874 https://bugs.debian.org/781873 There isn't much traction in upstream u-boot on this, and I suspect u-boot is basically broken on sheevaplug, guruplug and openrd_ultimate in jessie, stretch and sid... With no activity upstream, I'm hesitant to just break backwards compatibility by moving the environment; it might be better to drop support. The choices seem to be between not including features, or breaking backwards compatibility with the environment location, and I'd like to move in whichever direction gets into upstream u-boot on this, which currently is neither... live well, vagrant signature.asc Description: PGP signature
