Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

PXE booting is sweet. I develop an OS (Crankshaft) for the Pi, and a lot of times it just has been waiting to write a new OS to the SD card, waiting, plugging it in, realizing I forgot to do something, so I had to repeat. Each time it was 15 minutes of waiting. Pulling the card out and putting it back in, especially with the ribbon cable on the way (and a case too) has been really painful. PXE boot is going to solve that. So I'm very, very excited for this.

In the blog, they mentioned the possibility of having a Pi3A too, so I look forward to that as well. The project I have has not much need for lots of USB ports and ethernet, so having to pay for and power a hub and an ethernet port only add to the power requirements with no added benefit. The Pi3A will be the prime target for me if they release it.

The only thing I wish they had is microphone input (we need the mic input for "OK Google") but I don't think it will happen, so that's one more thing on the wish list.



Or you can use the u-boot bootloader[1], and boot a kernel and root filesystem from TFTP, right? [1]http://www.denx.de/wiki/U-Boot


For any problem, there is always someone who could come up with a brilliant solution and makes me feel like a dummy. That is a great idea I haven't thought of!

PS: Upon further inspection, PXE netbooting is already possible on the 3B under the name of "USB booting," it's just not the default in the hardware, and there might be bugs that are fixed in the new version.


But remember you can always put the very latest bugfixed version of bootcode.bin standalone on an SD card and use that instead of the version in your Pi's bootrom. This also works for older models (Pi/Pi2) that don't have PXE support in their bootrom.


Even with the new bootcode.bin, Pi 3 firmware netbooting has been extremely unreliable for me.

And at this point, if you already use an SD card for the bootcode, might as well put the whole U-Boot onto the card (which I did)


Another possible approach would be to use the Linux kernel's ability to load another kernel and hand it control. Unsure if this works on arm64 but it seems likely. https://linux.die.net/man/8/kexec


That's generally how it's done on non-Pi boards (some of which even have onboard SPI flash that's large enough to hold u-boot). This has the advantage that the PXE code can be upgraded in the field, which is kind of important given how complex and buggy it is.


Didn't they already have pxe support on the Model 3B? This is just a bug fixed version (and enabled by default).



That documentation you've linked to is just very thorough, there's not that much to it. U-boot doesn't appear to be much simpler so I don't see the point in it, but maybe I'm missing some extra features it has?


FYI PXE booting has been possible for a while now: https://www.raspberrypi.org/documentation/hardware/raspberry...


Yep, I always thought it was just booting from the USB stick. But nonetheless, having a version that is officially supported and enabled by default is great.


It's extremely unreliable on the Pi 3. I gave up on full diskless (cardless?) boot and just put u-boot on an SD card.


Why not just use a USB microphone?


That's what I suggest people to use now. The USB microphone needs power and one more USB port. If the Pi had a microphone input, we would have absolutely no need for the second USB port. Not having to have the second USB port means we would need no chip for the 4-port hub. Having the distro supporting the Pi Zero that has 1 USB port has been something I've been dreaming about.


How about an I2S microphone [1]? Or a PDM microphone [2]? These hook up to GPIOs.

[1] https://www.adafruit.com/product/3421

[2] https://www.adafruit.com/product/3492


That's another something I don't know that I don't know!


> That's another something I don't know that I don't know!

This is something we don't do well. Situational awareness and expert consults. As a society, field, and individuals.

From grounding elite groupthink, to systematic reviews in medicine, to programming language design, to hardware acquisition, to choosing a javascript library, or crafting its api, to choosing what to eat for lunch. Existing socio-technical infrastructure is painful to use, with highly and variably suboptimal results. And the more interdisciplinary the task, the worse the costs.

Opportunities for improvement are coming. Hybrid human-computer systems, so "I'm planning to do X, can I get a sanity check?" can be addressed with a mix of automation, and AI, and stats, and custom blends of variously-skilled/expensive human expertise.

But there are existing opportunities which are often not taken advantage of. Like maintaining personal review "committees" - people of various expertise to whom you can mention what you are up to, and hope to at least get back a "sounds good"/"have you thought of instead doing X". And like watching for opportunities to mention one's work on fora like HN, to create an opportunity for feedback. :) Engineered serendipity.



If they added a TRRS connector it would be quite easy to plug an external mic that way.


They have always had a TRRS connector, just that the extra R is used for the video signal sadly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: