U-boot fw_env.config / initramfs

[Raphael]

Dear all,

I try to make u-boot use a stock debian initramfs to enable cryptroot. The current uImage kernel seems to support initramfs, so I thought the quickest way would be to adjust the u-boot options accordingly, without recompiling either u-boot or the kernel. Unfortunately, fw_printenv / fw_setenv do not work with the presumed fw_env.config values of "/dev/mmcblk0 0x60000 0x2000" (suggested by both ckuethe on github and the u-boot source usbarmory.h). It throws a "Warning: Bad CRC, using default environment". Any advice on the correct fw_env values, and/or straight on enabling initramfs support?

Also, in the long run I'd like to use a LUKS key fused in the SoC. I know you disapprove, but I have my reasons. Anybody succeeded with this yet?

Thanks,
Raphael

[Andrea Barisani]

On Tuesday, July 28, 2015 at 2:23:46 PM UTC+2, Raphael wrote:

Dear all,

I try to make u-boot use a stock debian initramfs to enable cryptroot. The current uImage kernel seems to support initramfs, so I thought the quickest way would be to adjust the u-boot options accordingly, without recompiling either u-boot or the kernel. Unfortunately, fw_printenv / fw_setenv do not work with the presumed fw_env.config values of "/dev/mmcblk0 0x60000 0x2000" (suggested by both ckuethe on github and the u-boot source usbarmory.h). It throws a "Warning: Bad CRC, using default environment". Any advice on the correct fw_env values, and/or straight on enabling initramfs support?

Please try to delete a random (non present) variable with:

fw_setenv foobar

and then try fw_printenv again.

Thanks

[Raphael]

Dear Andrea,

Please try to delete a random (non present) variable with:

fw_setenv foobar

and then try fw_printenv again.

did this, and the fw_setenv gave the same CRC error, but then fw_printenv  returned the standard output without CRC error (subsequent fw_setenv also without CRC error):

-------
bootargs=
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=3
baudrate=115200
stdin=serial,cros-ec-keyb
stdout=serial,lcd
stderr=serial,lcd
-------

I don't think this is the correct u-boot env for the armory, though, is it? Only now it's probably written at 0x60000 on my SD card. I'd rather not reboot the armory in this state...

Does this help in debug?

Raphael

[Andrej Rosano]

Hi Raphael,

You are right, the u-boot environment is corrupted right now and the
usbarmory will not boot right away. If you have a usb-serial adapter you
can stop the boot at the u-boot shell and restore the default environment:

=> env default -a
=> saveenv

At this point the environment with the correct CRC is saved and you
can now correctly access it also via the two linux userspace programs.

Otherwise, if you do not have an usb-serial adapter, you can
corrupt the u-boot environment block again, so at the next boot
u-boot will use the default (built-in) values:

# dd if=/dev/zero of=/dev/mmcblk0 seek=393216 bs=1 count=1


I hope this will solve your issue.

Cheers,
Andrej

>
> Does this help in debug?
>
> Raphael
>

> --
> You received this message because you are subscribed to the Google Groups "USB armory" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to usbarmory+...@googlegroups.com.
> To post to this group, send email to usba...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/usbarmory/77464c17-1b01-4e65-a9e7-b17927cfd33c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


--
Andrej Rosano <andr...@gmail.com>
0x7B470744 E5DF 7810 AD63 A215 2D0E AF56 53C7 A2CB 7B47 0744

[Andrea Barisani]

I apologize for this, the suggestion was discussed together by myself and Andrej as it was a procedure that worked on our installations and was deemed safe. Evidently it wasn't and we regret the error.

We will investigate this further and possibly provide a detailed guide in the wiki to get fw_printenv / fw_setenv working.

Let us know if you need further assistance.

Thanks

[Raphael]

Dear Andrea and Andrej,

thanks for the hint with writing one zero byte to 0x60000 - now the armory reboots just fine. My original issue remains unresolved, though. Let me know if there is anything I can help with. Will try to compile u-boot myself later today (with additional env variables hardcoded to suit my needs). How much of the SD card should I dd away was backup? Right up to the start of mmcblkp01?

Best,
Raphael

[Andrej Rosano]

On Tue, Jul 28, 2015 at 08:47:07AM -0700, Raphael wrote:
> Dear Andrea and Andrej,
>
> thanks for the hint with writing one zero byte to 0x60000 - now the armory
> reboots just fine. My original issue remains unresolved, though. Let me
> know if there is anything I can help with. Will try to compile u-boot
> myself later today (with additional env variables hardcoded to suit my

Did you try to access the U-boot shell via usb-serial adapter? The
procedure described in my previous mail should fix the CRC issue with
the correct default envirnment variables, so you can modify them via
Linux.

> needs). How much of the SD card should I dd away was backup? Right up to
> the start of mmcblkp01?

The exact amount depends on the used U-Boot binary, you are on the
safe side if you backup everything till the beginning of the partition.

Andrej

>
> Best,
> Raphael

[Raphael]

Dear Andrej,

Did you try to access the U-boot shell via usb-serial adapter? The
procedure described in my previous mail should fix the CRC issue with
the correct default envirnment variables, so you can modify them via
Linux.

no - I have two micro buttons soldered on the GPIO (just sticking out the enclosure - perfect fit...), hence no USB serial for now... Will experiment with my own u-boot later on and let you know,

Best,
Raphael

[Raphael]

Dear all,

a last update - I can compile and run a custom u-boot using the instructions at https://github.com/inversepath/usbarmory/wiki/Preparing-a-bootable-microSD-image (though I run it directly on the armory), When I try to modify include/configs/usbarmory.h as follows to load and use a standard debian initramfs-tools created initramfs, however, the armory is bricked - no USB device gets enlisted:

-------

#define CONFIG_BOOTCOMMAND                                              \
        "run distro_bootcmd; "                                          \
        "setenv bootargs console=${console} ${bootargs_default}; "      \
        "ext2load mmc 0:1 ${kernel_addr_r} /boot/uImage; "              \
        "ext2load mmc 0:1 ${fdt_addr_r} /boot/${fdtfile}; "             \
        "ext2load mmc 0:1 ${ramdisk_addr_r} /boot/initrd.img-4.0.2; "   \
        "bootm ${kernel_addr_r} - ${fdt_addr_r}"

#define BOOT_TARGET_DEVICES(func) func(MMC, mmc, 0)

#include <config_distro_bootcmd.h>

#define MEM_LAYOUT_ENV_SETTINGS                 \
        "kernel_addr_r=0x70800000\0"            \
        "fdt_addr_r=0x71000000\0"               \
        "scriptaddr=0x70800000\0"               \
        "pxefile_addr_r=0x70800000\0"           \
        "ramdisk_addr_r=0x73000000\0"

#define CONFIG_EXTRA_ENV_SETTINGS                               \
        MEM_LAYOUT_ENV_SETTINGS                                 \
        "bootargs_default=root=/dev/mmcblk0p2 rootwait rw\0"    \
        "fdtfile=imx53-usbarmory.dtb\0"                         \
        "initrd=0x73000000 ip=10.0.0.1::10.0.0.2:255.0.0.0::usb0:off\0"                         \
        BOOTENV

------------

I assume I will have to desolder those buttons and get a serial console running - unless you have another idea?

Curious,
Raphael

[Chris Kuethe]

You may want to order some test hooks so you can grab the serial
lines... http://www.amazon.com/gp/product/B00GM82R7I/

Or maybe a socket strip so you can plug in your switches and/or serial
console while you're still in heavy development mode..

> --
> You received this message because you are subscribed to the Google Groups
> "USB armory" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to usbarmory+...@googlegroups.com.
> To post to this group, send email to usba...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/usbarmory/1f5c8da2-57c4-4188-ac73-103eb71e9342%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

GDB has a 'break' feature; why doesn't it have 'fix' too?

[Andrej Rosano]

On Tue, Jul 28, 2015 at 11:14:20AM -0700, Raphael wrote:
> Dear all,
>
> a last update - I can compile and run a custom u-boot using the
> instructions at
> https://github.com/inversepath/usbarmory/wiki/Preparing-a-bootable-microSD-image
> (though I run it directly on the armory), When I try to modify
> include/configs/usbarmory.h as follows to load and use a standard debian
> initramfs-tools created initramfs, however, the armory is bricked - no USB

You need to verify that the relevant usb gadget modules are loaded
in the initrd image as well.

If you have an usb microsd adapter you can restore by recompiling and reflashing
the original u-boot from your host following just the "Bootloader: U-Boot 2015.04"
section of "Preparing a bootable microSD image" wiki page.

Andrej

>
> Curious,

[Raphael]

Hey Andrej,

 

You need to verify that the relevant usb gadget modules are loaded
in the initrd image as well.

I added g_ether in debian's initramfs-tools/modules, which in principle should do. Anyways, I also added a custom boot script to the initramfs which writes a file to the SD card. That file is never written, hence I assume that the initramfs is never executed. Two more things I tried:

Following https://linux-sunxi.org/Initial_Ramdisk, I converted debians' initramfs to uInitrd format - makes no difference.

Also, I found a typo in my changes to usbarmory.h quoted earlier - the initrd and ip should be added to bootargs_default and not to the u-boot env. But again: no makes no difference.

So I guess I will have to solder (or clip - thanks ckuethe) a usb-to-serial dongle to be able to see u-boot in action...

Has anybody else had any success in getting initramfs working?

Best,
Raphael