[opensuse-arm] Adding new board: No boot device
Hello, I try to add a new ARM board (JeOS-socfpgade0nanosoc) to factory ARM. Now I have some problems to get the image [1] to work on the target. It cannot find a boot device during first startup (see appended serial console output). To debug that I did a setenv append kiwidebug=1 saveenv on u-boot console and by that the boot process should start a console. But problem 1: [1483747199.877840] Starting boot shell on /dev/tty2 [1483747200.888525] Searching for boot device... [1483747233.661872] Failed to find boot device ! Press Enter for maintenance (or press Control-D to continue): after that no input is accepted, neither Enter nor Control-D. I tried to reconfigure my serial terminal to test with CR, LF and CRLF line endings, all the same result. I guess that it has to do with the console on /dev/tty2, which is not the serial console. How can this be changed? Problem 2: The system immediately restarts with the latest images when it reached that point, that was not the case one week ago or so. How to debug or change that? Br, Frank [1] https://build.opensuse.org/package/show/home:frank_kunz:branches:openSUSE:Fa... Serial output: U-Boot SPL 2017.01-rc3 (Jan 06 2017 - 14:29:12) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Trying to boot from MMC1 U-Boot 2017.01-rc3 (Jan 06 2017 - 14:29:12 +0000) CPU: Altera SoCFPGA Platform FPGA: Altera Cyclone V, SE/A4 or SX/C4, version 0x0 BOOT: SD/MMC Internal Transceiver (3.0V) Watchdog enabled I2C: ready DRAM: 1 GiB MMC: dwmmc0@ff704000: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Terasic DE0-Nano(Atlas) Net: Error: ethernet@ff702000 address not set. No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:2... Found U-Boot script /boot.scr 2767 bytes read in 11 ms (245.1 KiB/s) ## Executing script at 02100000 switch to partitions #0, OK mmc0 is current device 7667392 bytes read in 545 ms (13.4 MiB/s) 41831930 bytes read in 2871 ms (13.9 MiB/s) 17507 bytes read in 73 ms (233.4 KiB/s) ## Loading init Ramdisk from Legacy Image at 07000000 ... Image Name: Initrd Created: 2017-01-07 21:42:27 UTC Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 41831866 Bytes = 39.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 reserving fdt memory region: addr=0 size=1000 Loading Device Tree to 03ff8000, end 03fff462 ... OK Starting kernel ... setterm: cannot (un)set powersave mode: Inappropriate ioctl for device Sat Jan 7 00:00:00 UTC 2017 [1483747200.768671] Searching for boot device... [1483747233.594935] Failed to find boot device ! KIWI Log: KIWI .profile contents: kiwi_align='1048576' kiwi_bootkernel='custom' kiwi_bootloader='uboot' kiwi_bootprofile='default' kiwi_cmdline='loglevel=3 splash=silent plymouth.enable=0 rootflags=size=100% console=ttyS0,115200n8' kiwi_cpio_name='initrd-oemboot-suse-tumbleweed' kiwi_delete='Mesa cracklib-dict-full fillup gdbm info insserv make mingetty openSUSE-release pam pam-modules perl perl-Bootload er permissions python python-base' kiwi_displayname='openSUSE' kiwi_drivers='crypto/*,drivers/acpi/*,drivers/acpi/dock.ko,drivers/ata/*,drivers/block/brd.ko,drivers/block/cciss.ko,drivers/bl ock/loop.ko,drivers/block/virtio_blk.ko,drivers/cdrom/*,drivers/char/hw_random/virtio-rng.ko,drivers/char/lp.ko,drivers/dma/*,d rivers/firmware/edd.ko,drivers/gpio/*,drivers/gpu/*,drivers/gpu/drm/*,drivers/hid/*,drivers/hwmon/*,drivers/ide/*,drivers/input /keyboard/*,drivers/input/mouse/*,drivers/md/*,drivers/message/fusion/*,drivers/mmc/*,drivers/mmc/card/*,drivers/mmc/host/*,dri vers/net/*,drivers/parport/*,drivers/phy/*,drivers/regulator/*,drivers/scsi/*,drivers/staging/hv/*,drivers/thermal/*,drivers/us b/*,drivers/virtio/*,fs/binfmt_aout.ko,fs/binfmt_misc.ko,fs/btrfs/*,fs/exportfs/*,fs/ext2/*,fs/ext3/*,fs/ext4/*,fs/fat/*,fs/fus e/*,fs/hfs/*,fs/isofs/*,fs/jbd/*,fs/jbd2/*,fs/mbcache.ko,fs/nls/nls_cp437.ko,fs/nls/nls_iso8859-1.ko,fs/nls/nls_utf8.ko,fs/over layfs/*,fs/quota_v1.ko,fs/quota_v2.ko,fs/squashfs/*,fs/udf/*,fs/vfat/*,fs/xfs/*,lib/crc-t10dif.ko,lib/crc16.ko,lib/libcrc32c.ko ,lib/zlib_deflate/zlib_deflate.ko,net/packet/*' kiwi_firmware='ofw' kiwi_fsmountoptions='noatime,nobarrier' kiwi_iname='initrd-oemboot-suse-tumbleweed' kiwi_iversion='2.7.1' kiwi_language='en_US' kiwi_loader_theme='openSUSE' kiwi_oemataraid_scan='true' kiwi_oemmultipath_scan='true' kiwi_oemskipverify='true' kiwi_oemswap='true' kiwi_oemswapMB='500' kiwi_profiles='default,custom' kiwi_revision='0845f334f23450ad03841febae8ddd10cb3b4a0b' kiwi_sectorsize='512' kiwi_splash_theme='openSUSE' kiwi_startsector='2048' kiwi_strip_delete='/etc/services /etc/udev/hwdb.bin /lib/firmware/brcm/*-pcie.bin /lib/firmware/radeon /lib/i686/nosegneg /lib/ modules/*/kernel/crypto /lib/modules/*/kernel/drivers/infiniband /lib/modules/*/kernel/drivers/isdn /lib/modules/*/kernel/drive rs/md /lib/modules/*/kernel/drivers/media /lib/modules/*/kernel/drivers/net /lib/modules/*/kernel/drivers/scsi /lib/modules/*/k ernel/net /lib/modules/*/kernel/sound /usr/bin/busybox /usr/bin/curl /usr/bin/diff /usr/bin/fbiterm /usr/bin/gawk /usr/bin/host /usr/bin/journalctl /usr/bin/rsync /usr/lib*/gconv /usr/lib/genisoimage /usr/lib/grub2 /usr/lib/ldscripts /usr/lib/perl5 /usr/ lib/rpm /usr/lib/systemd/catalog /usr/lib/systemd/system/busnames.target.wants /usr/lib/systemd/system/local-fs.target.wants /u sr/lib/systemd/system/multi-user.target.wants /usr/lib/systemd/system/poweroff.target.wants /usr/lib/systemd/systemd-backlight /usr/lib/systemd/systemd-bus-proxyd /usr/lib/systemd/systemd-coredump /usr/lib/systemd/systemd-localed /usr/lib/systemd/systemd -logind /usr/lib/systemd/systemd-machined /usr/lib/systemd/systemd-networkd /usr/lib/systemd/systemd-timesyncd /usr/lib/systemd /user /usr/lib/systemd/user-generators /usr/lib/udev/hwdb.d /usr/lib/wicked /usr/lib64/ldscripts /usr/sbin/wicked /usr/share/X1 1/locale /usr/share/backgrounds /usr/share/fbiterm /usr/share/fonts /usr/share/grub2/backgrounds /usr/share/help /usr/share/icu /usr/share/info /usr/share/kbd /usr/share/locale /usr/share/misc/magic /usr/share/pci.ids /usr/share/pci.ids.d /usr/share/spla shy /usr/share/tc /usr/share/wicked /usr/src/packages /var/adm /var/cache/zypp /var/log/* usr/share/bash-completion usr/share/b ash/helpfiles usr/share/emacs usr/share/sgml usr/share/zoneinfo usr/share/zsh' kiwi_strip_libs='libaio libdevmapper libdmraid-events-isw libdrm libfontenc libfreetype libgcc_s libjpeg libkmod libkms libnsl libnss_compat libnss_dns libnss_files libply-boot-client libply-splash-graphics libpng libresolv librt libselinux libsepol libs plashy libsplashycnf libsysfs libutempter libutil' kiwi_strip_tools='arch ata_id atftp atftpd awk basename bash bc blkid blockdev blogd btrfs btrfsck btrfsctl btrfstune b U-Boot SPL 2017.01-rc3 (Jan 06 2017 - 14:29:12) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Trying to boot from MMC1 -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Frank, Am 08.01.2017 um 13:35 schrieb Frank Kunz:
[1] https://build.opensuse.org/package/show/home:frank_kunz:branches:openSUSE:Fa...
Please delete _multibuild until you're ready to submit, otherwise you are wasting build power rebuilding all other images, too. Images.kiwi.in: firmware="ofw" sounds wrong? dtb-sun7i is obviously copy&paste, waiting for your pull to be merged. Better drop the line and add a to-do comment. For the gfx command line you may want to add a second console=tty or so? uboot-image-setup.in: Please don't set so many U-Boot variables for a new board. You should probably set use_fdt_addr_r and not duplicate the variables that modern U-Boot should already be providing for you, including fdtfile. Compare my in-progress nanopineo with just three lines: https://build.opensuse.org/package/show/home:a_faerber:branches:openSUSE:Fac... Does EFI not work yet or have you not tried? uboot-image-install.in: Better check for file presence than for image name (think "sockit"). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
firmware="ofw" sounds wrong? The soc first stage bootloader (ROM) reads the first sector of the SD card and scans the partition table for a partition with the ID 0xa2. If
Better check for file presence than for image name (think "sockit"). The file is not present since it is not copied by KIWIBoot.pm sub copyBootCode { ... KIWIQX::qxx ("mv $dest/boot/*.bin $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.dat $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.img $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.imx $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.elf $target &>/dev/null"); ... } The header+spl+uboot image file name is u-boot-with-spl.sfp and that
Hello Andreas, thanks for your feedback. this is found it loads a header + spl loader from that partition. The upstream u-boot spl configuration for that board expects the uboot also copied to that special partition and it expects that it needs to be the first partition. firmware="ofw" creates a small extra partition at the beginning of the partition table. This is used for header+spl+uboot. The uboot install script is adjusting the partition type and copies the spl with uboot into it. pattern is not copied. Therefore I used the image name instead of the file presence. The file is copied by cp /usr/src/packages/KIWIROOT-oem/boot/u-boot-with-spl.sfp boot/ in the uboot install script, which is just a hack. The clean solution would be a upstream patch for kiwi.
For the gfx command line you may want to add a second console=tty or so? That did not help so far so solve my login problem. In the mean time I started to modify the initrd that the /boot/mbrid file does not match. But no idea yet what could be wrong. I haven't found out where it is set during the image build process, how to debug that?
Does EFI not work yet or have you not tried? No, I have not tried yet. Not sure if that will work.
Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 08/01/2017 21:30, Frank Kunz wrote:
Hello Andreas,
thanks for your feedback.
firmware="ofw" sounds wrong? The soc first stage bootloader (ROM) reads the first sector of the SD card and scans the partition table for a partition with the ID 0xa2. If this is found it loads a header + spl loader from that partition. The upstream u-boot spl configuration for that board expects the uboot also copied to that special partition and it expects that it needs to be the first partition. firmware="ofw" creates a small extra partition at the beginning of the partition table. This is used for header+spl+uboot. The uboot install script is adjusting the partition type and copies the spl with uboot into it.
Better check for file presence than for image name (think "sockit"). The file is not present since it is not copied by KIWIBoot.pm sub copyBootCode { ... KIWIQX::qxx ("mv $dest/boot/*.bin $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.dat $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.img $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.imx $target &>/dev/null"); KIWIQX::qxx ("mv $dest/boot/*.elf $target &>/dev/null"); ... } The header+spl+uboot image file name is u-boot-with-spl.sfp and that pattern is not copied. Therefore I used the image name instead of the file presence. The file is copied by
cp /usr/src/packages/KIWIROOT-oem/boot/u-boot-with-spl.sfp boot/
in the uboot install script, which is just a hack. The clean solution would be a upstream patch for kiwi.
We basically moved away from copying random files magically within kiwi to explicitly moving things around inside the u-boot-install/setup scripts. It's much more maintainable that way. So if you already do it inside the u-boot-install script, that sounds like a perfectly valid solution.
For the gfx command line you may want to add a second console=tty or so? That did not help so far so solve my login problem. In the mean time I started to modify the initrd that the /boot/mbrid file does not match. But no idea yet what could be wrong. I haven't found out where it is set during the image build process, how to debug that?
The mbrid file gets generated by kiwi when it writes the MBR ID field in the MBR of the target device. So they really should be in sync. If they are not, something goes wrong in the u-boot-install/setup scripts. Also, have you verified that the target device is actually visible from within the kiwi initrd? Maybe the module is missing? To verify, just boot with kiwidebug=1 as kernel parameter and you should get into a shell after kiwi failed to find its boot device.
Does EFI not work yet or have you not tried? No, I have not tried yet. Not sure if that will work.
EFI booting makes it much easier to modify things like the kernel command line. It also allows you to install and select multiple kernel versions in parallel. To make use of it, all you need is a valid "$fdtfile" variable in the U-Boot default environment. Then set the respective define in the Images.kiwi.in file for your board and you should be set. You might need to convert the GPT that kiwi generates to an MBR. See existing snippets in the u-boot scripts for that. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 08.01.2017 um 22:29 schrieb Alexander Graf:
For the gfx command line you may want to add a second console=tty or so? That did not help so far so solve my login problem. In the mean time I started to modify the initrd that the /boot/mbrid file does not match. But no idea yet what could be wrong. I haven't found out where it is set during the image build process, how to debug that?
The mbrid file gets generated by kiwi when it writes the MBR ID field in the MBR of the target device. So they really should be in sync. If they are not, something goes wrong in the u-boot-install/setup scripts.
Also, have you verified that the target device is actually visible from within the kiwi initrd? Maybe the module is missing?
I modified the initrd init/include scripts to print the device names that were used for the search run, and the mmcblk0 is there, and some value is read out. So the driver seems to be ok. The value read from /boot/mbrid is a different value.
To verify, just boot with kiwidebug=1 as kernel parameter and you should get into a shell after kiwi failed to find its boot device.
That is the problem I have. The shell is started on /dev/tty2, but I need it on the same tty as the serial console is. How can this be configured?
Does EFI not work yet or have you not tried? No, I have not tried yet. Not sure if that will work.
EFI booting makes it much easier to modify things like the kernel command line. It also allows you to install and select multiple kernel versions in parallel.
To make use of it, all you need is a valid "$fdtfile" variable in the U-Boot default environment. Then set the respective define in the Images.kiwi.in file for your board and you should be set. You might need to convert the GPT that kiwi generates to an MBR. See existing snippets in the u-boot scripts for that.
That sounds interesting. I quick tested that by just setting the environment variable and by that two partitions are generated. First partition is a EFI-System partition and the second one a Linux filesystem. This cannot be booted by the soc first stage loader. It expects a partition with ID 0xa2 that has a header+spl loader. For the upstream uboot it has to be the first partition on the SD card. How to add an arbitrary first partition with KIWI oem? Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 09/01/2017 21:20, Frank Kunz wrote:
Am 08.01.2017 um 22:29 schrieb Alexander Graf:
For the gfx command line you may want to add a second console=tty or so? That did not help so far so solve my login problem. In the mean time I started to modify the initrd that the /boot/mbrid file does not match. But no idea yet what could be wrong. I haven't found out where it is set during the image build process, how to debug that?
The mbrid file gets generated by kiwi when it writes the MBR ID field in the MBR of the target device. So they really should be in sync. If they are not, something goes wrong in the u-boot-install/setup scripts.
Also, have you verified that the target device is actually visible from within the kiwi initrd? Maybe the module is missing?
I modified the initrd init/include scripts to print the device names that were used for the search run, and the mmcblk0 is there, and some value is read out. So the driver seems to be ok. The value read from /boot/mbrid is a different value.
That sounds to me like something is messing with the MBR after it got created. The MBR ID inside the raw image's MBR and the mbrid file are both created by kiwi and usually well aligned.
To verify, just boot with kiwidebug=1 as kernel parameter and you should get into a shell after kiwi failed to find its boot device.
That is the problem I have. The shell is started on /dev/tty2, but I need it on the same tty as the serial console is. How can this be configured?
You should get the terminal on the serial console if the serial console is the default output (console=ttyS0 / ttyAMA0 / whatever only, no console=tty)
Does EFI not work yet or have you not tried? No, I have not tried yet. Not sure if that will work.
EFI booting makes it much easier to modify things like the kernel command line. It also allows you to install and select multiple kernel versions in parallel.
To make use of it, all you need is a valid "$fdtfile" variable in the U-Boot default environment. Then set the respective define in the Images.kiwi.in file for your board and you should be set. You might need to convert the GPT that kiwi generates to an MBR. See existing snippets in the u-boot scripts for that.
That sounds interesting. I quick tested that by just setting the environment variable and by that two partitions are generated. First partition is a EFI-System partition and the second one a Linux filesystem. This cannot be booted by the soc first stage loader. It expects a partition with ID 0xa2 that has a header+spl loader. For the upstream uboot it has to be the first partition on the SD card. How to add an arbitrary first partition with KIWI oem?
Now it gets tricky. To simplify the code, U-Boot's internal scripts assume that the EFI partition is always the first partition. So we need to keep it there. What SoC exactly are you targetting? Usually most of them have some way to put the SPL at a magic offset on the SD card. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 10.01.2017 um 00:04 schrieb Alexander Graf:
On 09/01/2017 21:20, Frank Kunz wrote:
Am 08.01.2017 um 22:29 schrieb Alexander Graf:
For the gfx command line you may want to add a second console=tty or so? That did not help so far so solve my login problem. In the mean time I started to modify the initrd that the /boot/mbrid file does not match. But no idea yet what could be wrong. I haven't found out where it is set during the image build process, how to debug that?
The mbrid file gets generated by kiwi when it writes the MBR ID field in the MBR of the target device. So they really should be in sync. If they are not, something goes wrong in the u-boot-install/setup scripts.
Also, have you verified that the target device is actually visible from within the kiwi initrd? Maybe the module is missing?
I modified the initrd init/include scripts to print the device names that were used for the search run, and the mmcblk0 is there, and some value is read out. So the driver seems to be ok. The value read from /boot/mbrid is a different value.
That sounds to me like something is messing with the MBR after it got created.
He's calling parted in uboot-image-install.in: https://build.opensuse.org/package/rdiff/home:frank_kunz:branches:openSUSE:Factory:ARM/JeOS?opackage=JeOS&oproject=openSUSE%3AFactory%3AARM&rev=19 (Any reason for that placement of the hunk instead of adding in the bottom?) You may need to save and restore mbrid as done some lines up. #========================================== +# install socfpga u-boot into special boot partition +#------------------------------------------ +if [[ "$flavor" = "socfpga"* ]];then + echo "Installing All-in-one U-Boot/SPL to u-boot partition..." + LINE=$(kpartx -asv $diskname | head -n1) + PART=$(echo "$LINE" | awk '{print $3}') + LOOPDEV=$(echo "/dev/$PART" | sed 's/p[0-9][0-9]*$//') + parted -s $LOOPDEV set 1 type 0xa2 + cp /usr/src/packages/KIWIROOT-oem/boot/u-boot-with-spl.sfp boot/ + if ! dd if=boot/u-boot-with-spl.sfp of=/dev/mapper/$PART; then + echo "Couldn't install SPL on /dev/mapper/$PART" + exit 1 + fi + # "kpartx -dv $diskname" does not work if $diskname + # is longer than 64 characters + kpartx -dv $LOOPDEV + losetup -d $LOOPDEV +fi
The MBR ID inside the raw image's MBR and the mbrid file are both created by kiwi and usually well aligned.
Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 01/10/2017 12:51 PM, Andreas Färber wrote:
Am 10.01.2017 um 00:04 schrieb Alexander Graf:
On 09/01/2017 21:20, Frank Kunz wrote:
For the gfx command line you may want to add a second console=tty or so? That did not help so far so solve my login problem. In the mean time I started to modify the initrd that the /boot/mbrid file does not match. But no idea yet what could be wrong. I haven't found out where it is set during the image build process, how to debug that? The mbrid file gets generated by kiwi when it writes the MBR ID field in the MBR of the target device. So they really should be in sync. If they are not, something goes wrong in the u-boot-install/setup scripts.
Also, have you verified that the target device is actually visible from within the kiwi initrd? Maybe the module is missing? I modified the initrd init/include scripts to print the device names
Am 08.01.2017 um 22:29 schrieb Alexander Graf: that were used for the search run, and the mmcblk0 is there, and some value is read out. So the driver seems to be ok. The value read from /boot/mbrid is a different value. That sounds to me like something is messing with the MBR after it got created. He's calling parted in uboot-image-install.in:
(Any reason for that placement of the hunk instead of adding in the bottom?)
You may need to save and restore mbrid as done some lines up.
Ah, that explains the missing mbrid, yes :). I see two potential options according to the boot documentation: https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/a... 1) Use raw offset According to the documentation you can not use a partition table when using the raw format. Maybe you can trick around with abusing the first 440 bytes for the boot loader and leave the actual partition table and MBRID intact: https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout Maybe there's some way to use Preloader 1 instead of 0? 2) Create a partition in the "hole" before the first partition MBR partitions don't have to be sorted. You can easily create a partition number 4 for example that fills 1kb-1M. That region is unused in images created by kiwi in the MBR case. If you want to use a GPT, the hole starts a bit later (I keep forgetting where - just try 128kb): https://en.wikipedia.org/wiki/GUID_Partition_Table That space should be enough to fit your boot loader (SPL as well as U-Boot) in hopefully. Keep in mind that you need to restore that special partition after the firstboot resize. The contents will still be there, you merely need to add the partition. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 10.01.2017 um 13:13 schrieb Alexander Graf:
On 01/10/2017 12:51 PM, Andreas Färber wrote:
Am 10.01.2017 um 00:04 schrieb Alexander Graf:
On 09/01/2017 21:20, Frank Kunz wrote:
> For the gfx command line you may want to add a second console=tty > or so? That did not help so far so solve my login problem. In the mean time I started to modify the initrd that the /boot/mbrid file does not match. But no idea yet what could be wrong. I haven't found out where it is set during the image build process, how to debug that? The mbrid file gets generated by kiwi when it writes the MBR ID field in the MBR of the target device. So they really should be in sync. If they are not, something goes wrong in the u-boot-install/setup scripts.
Also, have you verified that the target device is actually visible from within the kiwi initrd? Maybe the module is missing? I modified the initrd init/include scripts to print the device names
Am 08.01.2017 um 22:29 schrieb Alexander Graf: that were used for the search run, and the mmcblk0 is there, and some value is read out. So the driver seems to be ok. The value read from /boot/mbrid is a different value. That sounds to me like something is messing with the MBR after it got created. He's calling parted in uboot-image-install.in:
(Any reason for that placement of the hunk instead of adding in the bottom?)
You may need to save and restore mbrid as done some lines up.
Ah, that explains the missing mbrid, yes :).
I see two potential options according to the boot documentation:
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/a...
1) Use raw offset
According to the documentation you can not use a partition table when using the raw format. Maybe you can trick around with abusing the first 440 bytes for the boot loader and leave the actual partition table and MBRID intact:
https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
Maybe there's some way to use Preloader 1 instead of 0?
Good idea. It is possible. The rom loader first checks for a partition 0xa2. From there it tries to load the spl, where there is one and three backups. If that fails it tries to load in raw mode from sector 0 and does the same. If the loading and crc check of spl from offset 0 fails, it automatically continues at sector offset 0x80 with the first backup spl. So when copy the spl+uboot image to the disk by dd if=u-boot-with-spl.sfp of=/dev/sdX bs=64k skip=1 seek=1 the rom loader loads the spl from preloader 1 location in raw mode and starts it. But the spl has a bug to load the attached uboot from the location 0x200 then. So I need to prepare some upstream patches for uboot to get that fixed and enabled in the defconfig (let us see if it will be accepted). Anyway the environment does not have the distro_boot variables in place, so I will upstream that as well. By that no special partition is needed anymore then, but the "hole" between partition table and first partition needs to be big enough to store the spl images and the uboot (approx. 700kiB). Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 10.01.2017 um 22:08 schrieb Frank Kunz <mailinglists@kunz-im-inter.net>:
Am 10.01.2017 um 13:13 schrieb Alexander Graf:
On 01/10/2017 12:51 PM, Andreas Färber wrote:
Am 10.01.2017 um 00:04 schrieb Alexander Graf:
>> For the gfx command line you may want to add a second console=tty >> or so? > That did not help so far so solve my login problem. In the mean > time I > started to modify the initrd that the /boot/mbrid file does not > match. > But no idea yet what could be wrong. I haven't found out where it is > set > during the image build process, how to debug that? The mbrid file gets generated by kiwi when it writes the MBR ID field in the MBR of the target device. So they really should be in sync. If they are not, something goes wrong in the u-boot-install/setup scripts.
Also, have you verified that the target device is actually visible from within the kiwi initrd? Maybe the module is missing? I modified the initrd init/include scripts to print the device names
On 09/01/2017 21:20, Frank Kunz wrote: Am 08.01.2017 um 22:29 schrieb Alexander Graf: that were used for the search run, and the mmcblk0 is there, and some value is read out. So the driver seems to be ok. The value read from /boot/mbrid is a different value. That sounds to me like something is messing with the MBR after it got created. He's calling parted in uboot-image-install.in:
(Any reason for that placement of the hunk instead of adding in the bottom?)
You may need to save and restore mbrid as done some lines up.
Ah, that explains the missing mbrid, yes :).
I see two potential options according to the boot documentation:
https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/a...
1) Use raw offset
According to the documentation you can not use a partition table when using the raw format. Maybe you can trick around with abusing the first 440 bytes for the boot loader and leave the actual partition table and MBRID intact:
https://en.wikipedia.org/wiki/Master_boot_record#Sector_layout
Maybe there's some way to use Preloader 1 instead of 0?
Good idea. It is possible. The rom loader first checks for a partition 0xa2. From there it tries to load the spl, where there is one and three backups. If that fails it tries to load in raw mode from sector 0 and does the same. If the loading and crc check of spl from offset 0 fails, it automatically continues at sector offset 0x80 with the first backup spl. So when copy the spl+uboot image to the disk by
dd if=u-boot-with-spl.sfp of=/dev/sdX bs=64k skip=1 seek=1
the rom loader loads the spl from preloader 1 location in raw mode and starts it. But the spl has a bug to load the attached uboot from the location 0x200 then. So I need to prepare some upstream patches for uboot to get that fixed and enabled in the defconfig (let us see if it will be accepted). Anyway the environment does not have the distro_boot variables in place, so I will upstream that as well.
By that no special partition is needed anymore then, but the "hole" between partition table and first partition needs to be big enough to store the spl images and the uboot (approx. 700kiB).
That is always the case, as parted aligns partitions to at least MB boundaries. Please double-check where the GPT contains values and that none of them are beyond 64kb. You will want to make this GPT future proof ;) Alex
Br, Frank -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (3)
-
Alexander Graf -
Andreas Färber -
Frank Kunz