Chromebook USB boot - does not work with > 16GB drive?

[raumzeit]

Hi,

I have a running installation of alarm on a SanDisk Cruzer Fit 16GB attached to my Samsung Chromebook.
Since I wanted to enlarge my home directory I got two additional Cruzer Fit drives, one with 32GB and the other with 64GB. However, I can't get alarm booting on both of them. On CTRL-U the screen just turns black shortly, a beep is issued and I am back at the scary developer mode screen.
I exactly followed the instructions on the Installation page for the Samsung Chromebook, and also double checked whether the first partition has a high enough priority and is marked as successful.

Does anyone know if there is a restriction to the size of the usb drive such that it is successfully recognized by u-boot? As I stated in the first sentence, installation/booting works perfectly with the 16GB version of this drive.

Thanks

RaumZeit

[WarheadsSE]

It is possible that the 64G drive is not "spinning up" fast enough for u-boot to be properly detecting it, and this can cause this exact behavior on any device.

[raumzeit]

mmh? I dont know that much about usb thumb sticks... do they actually 'spin-up' ? If so, this may be... but even if I wait some seconds and then hit CTRL-U, it won't boot...

This is rater strange, 16GB USB stick and 16GB SDHC both work as expected. The 32/64GB USB sticks won't... Thats why I was just wondering if there are some disk parameters which u-boot wouldn't like

I also just installed (evil) Ubuntu o the 32GB device. It also doesn't boot, so probably there is noting bad with the installed alarm files

[WarheadsSE]

Most people understand "spin up" better than "initialize itself, bring up it's own state, and respond to the USB bus query for storage types in a timely fashion in accordance with the time allotments provided by the u-boot scanning of the bus."

[raumzeit]

ok... that makes sense for me

so if this is the case, how could I test the 'responsiveness' of the stick?
And I guess the only way to get u-boot scanning a little bit longer would be to patch and install it?

[raumzeit]

Here is an update:

I booted from my 16GB SDHC card with the 32GB USB stick attached to the USB2 port. On boot I kept pressing a key such that I was able to interrupt u-boot in proceeding to boot alarm on the SDHC.
I started the USB bus via $this->bbcode_second_pass_code('', 'usb start') and then scanned for devices $this->bbcode_second_pass_code('', 'usb info')
There I found that my 32GB stick was present and it even did boot on manually running $this->bbcode_second_pass_code('', 'run usb_boot').
...this is at least a partial success...

So it might indeed have something to do that the SanDisk Cruzer Fit > 16GB doesn't 'spin-up' fast enough to be recognized by u-boots initial scan.

...dammit

Any Idea what I can do about that?

edit: this procedure also works for the 64GB stick

[WarheadsSE]

You might be able to get it to run usb start 2x

[raumzeit]

Thanks,

as soon as I figure out how I might be able to do so, I'll give it a try.
Am I right that this involves tinkering with the nv-uboot-snow thingy?

[WarheadsSE]

You could tinker with it right where it is.

[raumzeit]

unfortunately, it does not work that easy

I tried several 'usb start' in non_verified_boot. Also an initial 'sleep 5' doesn't work... I mean, after saveenv all my changes are stored in spi flash, but chained loading of nv-uboot fails for the large usb sticks... the 16gb stick, however, nicely waits its time, restarts usb several times, and then starts booting

It seems that I have to flash the rom afterall, and therefore go through this whole disassemble, remove write protection mess...

... but even then: How do I change the env variables for the first u-boot then? Or is it even possible to store some variable in spi flash that gets read by vboot without touching write protection?