(2017-01-30, 17:23)Haws Wrote: Long time user, no real problems. Thank you Matt.

Somehow messed up last update i was doing on one of my boxes. Normally just running a standalone setup. Firmware update went well.

Boots to shell command device mapping table now.

Not wanting to mess up more so figured i would ask the experts before i pushed more buttons.

Thank you in advance

(2017-01-30, 17:30)jsp1 Wrote: I tried upgrading the uefi firmware since it is supposed to offer the boot device option on install, however, this option was never presented to me. Am I missing something?

It currently defaults to usb and tries to boot my external hard drives before proceeding.

Also, is there any way we could get a custom version of the firmware that allocates more video memory (for those of us with more RAM)? Or is this a pointless or difficult endeavor?

Thanks for all the work Matt. The continued support has been amazing.

(2017-01-30, 18:21)Matt Devo Wrote:

(2017-01-30, 17:23)Haws Wrote: Long time user, no real problems. Thank you Matt.

Somehow messed up last update i was doing on one of my boxes. Normally just running a standalone setup. Firmware update went well.

Boots to shell command device mapping table now.

Not wanting to mess up more so figured i would ask the experts before i pushed more buttons.

Thank you in advance

When you install the standalone firmware via the EZ setup script, it now installs the UEFI firmware, rather than the older Legacy Boot firmware previously used. There's not a good way (read: automated) to migrate an installed OS between the two, because they use different partition layouts (MBR vs GPT) among other reasons. The easiest thing for you to do will be to boot a Linux USB, run my Firmware Utility Script, and install the Legacy Boot firmware instead. Run the script, choose 'u' to unlock all functions, choose option 3 (Install Full ROM firmware), then choose 'L' for legacy boot when prompted. When done, simply exit/reboot.

(2017-01-30, 18:21)Matt Devo Wrote:

(2017-01-30, 17:23)Haws Wrote: Long time user, no real problems. Thank you Matt.

Somehow messed up last update i was doing on one of my boxes. Normally just running a standalone setup. Firmware update went well.

Boots to shell command device mapping table now.

Not wanting to mess up more so figured i would ask the experts before i pushed more buttons.

Thank you in advance

When you install the standalone firmware via the EZ setup script, it now installs the UEFI firmware, rather than the older Legacy Boot firmware previously used. There's not a good way (read: automated) to migrate an installed OS between the two, because they use different partition layouts (MBR vs GPT) among other reasons. The easiest thing for you to do will be to boot a Linux USB, run my Firmware Utility Script, and install the Legacy Boot firmware instead. Run the script, choose 'u' to unlock all functions, choose option 3 (Install Full ROM firmware), then choose 'L' for legacy boot when prompted. When done, simply exit/reboot.

I'll be sure to update the documentation here to avoid this situation in the future.

(2017-01-30, 17:30)jsp1 Wrote: I tried upgrading the uefi firmware since it is supposed to offer the boot device option on install, however, this option was never presented to me. Am I missing something?

It currently defaults to usb and tries to boot my external hard drives before proceeding.

Also, is there any way we could get a custom version of the firmware that allocates more video memory (for those of us with more RAM)? Or is this a pointless or difficult endeavor?

Thanks for all the work Matt. The continued support has been amazing.

the UEFI firmware does not offer the option to set the boot device currently. I had briefly tested an implementation in the past, but it required me to maintain two different UEFI payloads for each device I support (which has become pretty sizable). Once the UEFI firmware supports NVRAM and has the ability to save settings, you will be able to set the boot target via the UEFI setttings, but until that time it will default to external devices first. With UEFI though, that shouldn't be an issue, as it will "fail forward" and most external drives won't have the requisite EFI bootloader/executable so should be skipped pretty much invisibly

(2017-01-30, 20:53)jsp1 Wrote: Okay thanks. I thought I read somewhere on your page that this choice was available and I had simply missed it. It has been an insignificant issue, just was cleaning up the boot process if possible.

Any word on the graphics memory? Is that a fruitless endeavor?

(2017-01-30, 22:17)smyrosnik Wrote: Hi,

I am interested in buying the following model (G072) of Chromebox. As it states it sports a 3215U processor. Is this compatible with the EZ script? In the wiki page only shows about 3205U (CN60/62 only?)

(https://www.amazon.it/ASUS-Chromebox-CHROMEBOX2-G072U-1-7GHz-3215U/dp/B01JP6YB8Q)

Thank you.

(2017-01-30, 22:29)Matt Devo Wrote:

(2017-01-30, 22:17)smyrosnik Wrote: Hi,

I am interested in buying the following model (G072) of Chromebox. As it states it sports a 3215U processor. Is this compatible with the EZ script? In the wiki page only shows about 3205U (CN60/62 only?)

(https://www.amazon.it/ASUS-Chromebox-CHROMEBOX2-G072U-1-7GHz-3215U/dp/B01JP6YB8Q)

Thank you.

some of the Broadwell models which used the Celeron 3205U were refreshed with the 3215U - there's no difference on the firmware side and they are 100% supported

(2017-01-30, 22:39)smyrosnik Wrote: Thank you for your fast response Matt.

One last question. I am trying to Google search for the past hour what is the difference between CN62 model and G072 . In the US site I can only find CN62. G072 is a rename of CN62 in Europe? I also find G081U and G084U models with no apparent differences(except RAM size, 2GB in G072 model).

Any thoughts?

Thanks again!

(2017-01-30, 22:53)Matt Devo Wrote:

(2017-01-30, 22:39)smyrosnik Wrote: Thank you for your fast response Matt.

One last question. I am trying to Google search for the past hour what is the difference between CN62 model and G072 . In the US site I can only find CN62. G072 is a rename of CN62 in Europe? I also find G081U and G084U models with no apparent differences(except RAM size, 2GB in G072 model).

Any thoughts?

Thanks again!

CN62 is the mode Asus uses for all Broadwell-based Chromeboxes regardless of configuration (the previous gen Haswell box is/was CN60). The GxxxU model number identifies a specific configuration (CPU, RAM, bundled accessories) for a specific region, so that model # will be different for you than for me in the USA (where G016U is the same config as the G072U you linked, but for North America)

(2017-01-30, 21:39)Matt Devo Wrote:

(2017-01-30, 20:53)jsp1 Wrote: Okay thanks. I thought I read somewhere on your page that this choice was available and I had simply missed it. It has been an insignificant issue, just was cleaning up the boot process if possible.

Any word on the graphics memory? Is that a fruitless endeavor?

the amount of RAM pre-allocated to the GPU (commonly referred to as DVMT) is increased to 96MB (from 32MB) in the UEFI firmware, but not in the Legacy boot (SeaBIOS) one. There's been a bit of a divergence between the two so updating the legacy firmware with that change would be a bit problematic from a CM standpoint

(2017-01-31, 02:30)jsp1 Wrote: Yes, I read the changes on your website. I was wondering however if the DVMT could be increased even more for boxes that have 4GB or more of RAM. Also if there would be any substantial performance advantage in doing so?

I assume the same would be true about needing to offer two copies of firmware for every box you support at this point though, so it is more a hypothetical question than a request.

(2017-01-31, 02:36)Matt Devo Wrote:

(2017-01-31, 02:30)jsp1 Wrote: Yes, I read the changes on your website. I was wondering however if the DVMT could be increased even more for boxes that have 4GB or more of RAM. Also if there would be any substantial performance advantage in doing so?

I assume the same would be true about needing to offer two copies of firmware for every box you support at this point though, so it is more a hypothetical question than a request.

in testing we found no appreciable difference going above 96MB, and anything above that is dynamically allocated upon request. Going above 96MB caused some issues for OSX, so we left it there