Pi0 does not exec kernel.img when using -d

[ghost]

It boots to the "rainbow screen of life" but then goes no further. From what I read that indicates kernel.img is not launching.

Files are requested and loaded, changes to config.txt do cause changes in what is loaded (as should be expected). Everything appears to fully load, and no errors in my best configuration (eg failed to transfer control, "Failed : 0x..." - which I have seen in some of my failed tests mentioned below).

A list of what I have tried so far

I have tried two different Pi0s (non-W) to ensure one was not defective.

I have tried every commit with no success. Every one including the first few that did not even get to stage 2 on a Pi0.

I have tried both stock Jessie boot files as well as custom kernels and a bare metal helloworld.

I have tried with and without a usb hub (the hub does get in the way a bit).

I have tried some older start.elf/bootcode.bin files (got 8 blinks indicating they were too old).

I wrote my own bootcode.bin that just blits data to the serial port. That works. That is the only thing I can get to work. This however does not init the arm, etc so its of limited functionality.

I am running out of ideas for things I can try to rule out anything on my end, with my gear, etc. I am starting to think the problem must be in start.elf not properly jumping to where it should jump to.

[ED6E0F17]

Usbboot works perfectly for me on a Model A, a Zero 1.2 and a Zero-W, but has only ever worked once on my Zero 1.3 - I cannot begin to imagine how that could happen.

The "Failed:" message is not important, I see that when rpiboot is working normally.

You should use the latest bootcode/start/fixup files in the firmware master branch, they work perfectly well for usbboot.

The only thing I can suggest is that you keep buying more Pi Zeros until you find one that works, but you should check that your boot partition will run from sdcard.

[ghost]

I dont think "keep buying until you get one that works" is a viable solution to the problem.

The boot partition does work when its booted from an SD card.

I have used the latest firmware from the github rpi/firmware repo.

[ED6E0F17]

The board that fails for me has serial-number 56c76327. I cannot do anything to help resolve this issue until we have a start.elf that gives debug info over the serial port.

[ghost]

No resolution or comment in a week? :/

[JamesH65]

I presume that normal Raspbian on SD card boots fine? @ghollingworth Any thoughts?

[ghost]

yes it does. That same image I did (on desktop)

sudo kpartx -a jessie.img sudo mount /dev/mapper/loop0p1 /mnt rpiboot -d /mnt

and variations of using a working image as a base for my boot dir.

[ghollingworth]

Yeah, working on it...

On Tue, Mar 21, 2017 at 1:37 PM Nom-DePlume notifications@github.com wrote:

yes it does. That same image I did (on desktop)

sudo kpartx -a jessie.img sudo mount /dev/mapper/loop0p1 /mnt rpiboot -d /mnt

and variations of using a working image as a base for my boot dir.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/raspberrypi/usbboot/issues/13#issuecomment-288080133, or mute the thread https://github.com/notifications/unsubscribe-auth/AB9CHOOFagrIkDw1L8Ed3PpS9bOh1-zdks5rn9KigaJpZM4Mazoi .

--

Director of Software Engineering, Raspberry Pi (Trading) Limited t: +44 (0) 1223 322633 m: +44 (0) 7450 946289 e: gordon@raspberrypi.org w: www.raspberrypi.org

[Electron752]

@Nom-DePlume

Where did you get the information to write bootcode.bin? I was just searching the web on the boot process of the RPI. I stumbled on a few github trees, but they weren't particularly usefull.

I was actually thinking of doing things the other way around as something that could be interesting. Use the standard bootcode.bin and rewrite a custom second stage loader.

[Electron752]

You know this is a silly question, but I was wondering something. Why in the world does start.elf run in GPU mode. Why can't bootcode.bin jump to arm, load a new loader on the arm. Then if necessary possibly load the existing gpu based .elf file to get the rest of the gpu loaded.

I've always wondered why the boot process is as backward as it is. My guess is historical reasons.

I've been looking at some code in Linux, and lots of drivers load firmware fragments on demand as needed. Say like nvidea. Some of the GPU code doesn't actually get loaded until the gpu is used in accelerated mode.

[JamesH65]

Correct, historical reasons. The original SoC in the Pi was the 2835 which was, in effect, a Videocore4 with a small ARM core bolted on. The Videocore starts up running some internal first stage boot code, reading from the SD card and downloading its firmware, (bootcode.bin) and running it. Then bootcode.bin then starts the ARM core(s) and loads and runs start.elf. At least, that's what I remember.

[Electron752]

Yes, that's always seemed backwards. Sounds like bootcode.bin really needs to jump to something in arm mode. Possibly in a mode where many of the advanced features are disabled.

Then if some other gpu specific code gets loaded later, it unlocks the features.

[Electron752]

Most people in linux seem to load all the secret stuff later. After the kernel has loaded.

[ghollingworth]

No...

bootcode.bin runs on the VC4 processor (running on the L2 cache only) it then sets up the SDRAM and loads the main firmware code onto the VPU (start.elf)

start.elf then initialises and kicks off the ARM

If we implemented all the ARM starting code in bootcode.bin then it wouldn't fit into the L2 cache. Also bootcode.bin doesn't support reading from directories so you'd also have to implement that as well.

In the end yes it is largely historical but we couldn't do it any other way without completely re-writing everything

[Electron752]

What if a mini start.elf where available that just does what's absolutely needed.

[Electron752]

I'm actually interested in bootloader and if a mini start.elf where available, I think you would have lots of bare metal people interested in pounding on it. Like I said, you could document the thing and people could party on it. The idea would be that most of the advanced features are disabled.

[Electron752]

BTW, what's this loader.bin file I keep reading about on the web. It seems to have existing at one time or another.

I'm really interesting in maybe writing a bootloader for the RPI, but I don't want to deal with any GPU specific code. Just ARM. That way I could even share it out with people and such. Perhaps other people would be willing to help

[Electron752]

BTW, one more question. If bootcode.bin doesn't support reading from directories how does all the netboot does work. That sounds kind of complex and all.

Anyway, longer term I was toying with ideas on how you guys could get away from the FAT file system which is ancient and everybody hates. I've been thinking about creating a boot filesystem on some flash chips, but the information to do it doesn't seem to be documented. Would it be possible to get some documentation for that?

Ideally, I would still like to have some way to jump into ARM mode with as little of the gpu enabled as possible.

[Electron752]

Basically the idea would be to use a cheap microcontroller say like a PIC chip that that emulates one of the support boot modes. The idea would be to keep the data in the secure store by making sure that it can only be updated with a new copy that has a valid signature. I see you have several supported boot modes. USB is one option, but I would rather not go that route since RPI typically only have 1 USB port.

I guess I could start with usb device mode and test on the new RPI 0 I just bought by haven't used yet. But like I said, device boot mode doesn't seem to be documented as far as I can tell.

[Electron752]

OK, I'm about to quit.

You know when ARM64 started, it started with someone writting a stub file that got shared out. I actually had no idea how that stub worked, but it was enough to get people started. The idea was that this stub was catted onto a new boot mode. In this case arm 64.

What if a stub file was created that just contained enough GPU code to finish the job that bootcode.bin couldn't do itself. The idea is that this + custom code gets loaded at a fixed address. The head of the image contains the secret stuff to get things going which then jumps to a fixed offset in the image. Preferable in an ARM mode of some kind.

[Electron752]

We can call the the file bootcode.bin. But to make it you have to cat a special file onto the start of the new boot loader that just has enough GPU code to jump into arm mode at a fixed address. So people like me that don't want to know anything about GPU code could finish the job. The idea would be that the stub code is only what essential to starting up a single ARM cpu core.

@Nom-DePlume

Does you bootcode.bin work? How much would it take to just get it to the point that it could unreset the ARMs to run at a fixed address. What way I could possibly finish took over from where you started. The idea would be to take your image and cat it with my ARM specific stuff.

[pelwell]

What if a stub file was created that just contained enough GPU code to finish the job that bootcode.bin couldn't do itself.

That's not a stub - it's a start.elf replacement. If one has the tools and knowledge to write "enough GPU code to finish the job that bootcode.bin couldn't do itself" then you have basically replaced the firmware. Writing a replacement bootloader is more tricky (see Gordon's comment about the L2 cache usage), but significantly smaller.

[Electron752]

I might be interested in attempting that. A replacement bootcode.bin that just contains enough stuff to get the arm going at a fixed address. The arm would do the rest based on info I can get from the web and such.

I think eventually you guys would want to make as much of the GPU as optional as possible, and perhaps running as much as the boot code on the arm as possible actually makes sense long term.

[Electron752]

Sorry, I ment a replacement bootcode.bin that is built with a GPU stub at the front.

[Electron752]

You could even call the GPU code at the front, "Magic Numbers".

[Electron752]

So yes, the idea would be that the "Magic Numbers" just contains enough stuff to boot strap the ARM at a particular offset in the image. All the rest of the code would be written on the ARM including loading any other files from whatever filesystem or where it would need to be loaded from?

@Nom-DePlume

What would it take to get your bootcode.bin to be in the form of magic numbers that just initializes enough of the RPI to get the ARM to unreset at a fixed offset?

[Electron752]

Here is what I'm thinking long term here.

I take @Nom-DePlume version bootcode.bin which is a fixed size that fits in the L2 cache. This L2 cache code jumps on the ARM to a fixed offset that need not be in the L2 cache. This ARM is really just itself a stub to a stripped down Linux kernel that I compile with a custom .config. This Custom Linux kernel has all the open source drivers and file systems to run a real boot system.

This preboot system would then be able to load the legacy components from the network or whatever using standard Linux code. Which would include the existing bootcode.bin, start.elf, etc.

Like I'm not trying to replace the existing firmware. But I think a very complex bootloader could be make this way of which all of it would be open source code.

[Electron752]

Basically, just create a bootcode.bin that's a single really large file that's:

bootcode.bin(GPU only)+armstub+linux-kernel+othergoo which all gets called bootcode.bin.

That would essentually turn everything into a single big file that gets loaded from wherever. The only thing that wouldn't need to be open sourced would be the GPU stub at the front. That way all the networking code for the bootloader would be running on the ARM from open source code.

[Electron752]

Are any existing options available that would allow me to prototype something like this on my own?

It seems like the only piece I'm missing here is the stripped down firmware files(whatever this would be bootcode.bin/start.elf,etc) that I would cat onto the front of this whole system(which of course would not need to have any network code at all). Just enough to essentually jump into a standard Linux kernel image. In fact, I may not even need to write any code at all. Just a bunch of config files.

[ghost]

@Electron752 there are Videocore IV assembler tools that generate code. I forget where I got mine but everything has to be done with GPU asm because the arm part is not yet loaded, the MMU isnt initialized either so you are working with real addresses, etc. This makes it harder to accomplish great meaningful programs because you have to do some of the heavy lifting yourself.

As mentioned above you have to limit the size of bootcode.bin to the size of L2 cache. Basically if you were to write a totally open boot loader it would have to do a lot of things the same way. There are some real world constraints on why it is the way it is.

The microcode in the SoC gets the ball rolling by knowing a few things like how to read FAT file systems and do USB booting and that is what loads bootcode.bin into the L2 cache and then just executes it arbitrarily. it is not an elf file or anything else that way which means you kinda have to write it in assembler. Think of it like a .com file if you are a windows person (especially before PE binaries).

You really need to understand the VC IV system in order to go down this road with anything meaningful (my blit data to the uart is not really meaningful, I also rely on the default boot clock speed for 115.2k serial/uart and other things). It is more of a hello world type program.

[ghost]

@Electron752 I have read the last few posts you wrote now, and basically you are talking about doing exactly what the RPi boot process is.

The SoC bootrom (hardcoded microcode in the chip) loads bootcode.bin into L2 cache and JMPs to its start and executes from there.

bootcode.bin then (usually) loads the elf files and executes them. This process brings up the arm part, initializes the mmu, etc.

Lastly it will load the linux kernel. This is slightly more complicated because it will set ATAGS and some other things but meh. It then executes the kernel and from there it is linux or freebsd or whatever the kernel happens to be. The kernel itself can just be an arm executable it does not have to be an actual kernel.

If you just want to replace the kernel you may want to look into RPi bare metal as for the most part that is what that group is doing. This is also easier because there are FAR more tools for arm development than there are for VC IV development. There is a lot more information on it as well. A config.txt change is all that is required to load your arm program instead of the linux kernel. But you have to write your own schedulers and threading code (or be single threaded). You have to do a lot of the heavy lifting yourself, which may not be that difficult depending on the task. Linux does RTOS (realtime operating system) although I do not know if the RTOS extensions have been fully ported to the RPi (it should be) so really there is a lot available to a great many people.

Stand on the shoulders of giants and all that. I do not see a compelling need to replace the boot loader stuff. I understand the political side of wanting it all open fighting against the corporate side that requires certain things to not be open but I do not see that as a compelling enough reason personally. Few people care that their desktop UEFI bios isnt open (some really do though) and the boot loader here is kinda analogous to that.

[Electron752]

Hi,

I don't think this has anything to do with open and closed. Or corporate vs. free. That's a completely orthogonal issue in my opinion.

I was just thinking of were this could all be going and such. Would anything stop someone who wanted to do some heavy lifting from say just recompiling u-boot or linux with the VC compiler?

Essentially have an arch/vc directory in the Linux tree?

Ideally, I could image in the way distance future one could have actual devices drivers in such compiled with the VC compiler and have a Linux version that has somethings compiled for VC and some for ARM.

[JamesH65]

If it were possible (I'm not sure it is), I am not sure what benefit having uboot running on the Videocore would give you over running it on the ARM (There is a u-boot that people have got running on PI). In fact I suspect it would be next to useless, with no USB, no ethernet etc support. Might be possible to add those with a lot of effort and insider knowledge (I'm not able to comment as I don't know enough), but again, this already works on the ARM side, so why bother.

[pelwell]

Although the VPU is still unbeatable with specialised vector code, for standard scalar operations a single ARM core is quicker, so the loader should do as little as possible before starting the ARMs.

[ghost]

@Electron752 You can already do that. The boot loader stuff is like the BIOS, once you get to the point of the linux kernel launching you can run any flavor of linux. You may have to build the kernel to apply some patches that may not be in your distribution of choice but generally speaking any arm binary distribution should work more or less out of the box.

There is no reason to play with the bootloader stuff to accomplish that.

That is why I thought it was to have an "open BIOS" for the RPi hardware, because that is the only thing that would be gained.

Config.txt (which is loaded before the kernel is launched) can specify which kernel and some other options are loaded up at boot time. Arch is more of a function of the "partition 1" (or 5 in noobs) data than boot or "partition 0" data.

Some of the "bare metal" guys have written alternate linux kernel programs to drive their applications. Perhaps that is a better starting point than trying to deal with the boot loader. Although I got bored overnight and wrote about 80% of a functional analyzing disassembler for the VPU - yes others exist but they dont really analyze and this is handy for forensic analysis of malware should the need arise :) I plan on getting it to a more stable place in the next day or so and doing an initial commit to my github repo. BTW total PITA because of the way some instructions are done, the bitmasks of which 16, 32 or 48 bit opcode are not always as straight forward as they are on some other platforms. sigh. Stick with ARM this side of the fence is annoying :P

[Electron752]

Actually, I think u-boot is horrible. The fact that it's a hacked on old version is Linux is really, really bad.

@pelwell : Ok so recompiling the whole OS doesn't make sense then since the ARM is typlically faster.

@Nom-DePlume : I'm not really sure what the whole point of this is actually!

I think the boot process isn't that great. I think alot of the boot process could be improved, and I think u-boot which is the main alternative is really bad.

Ideally, the RPI should work just like NVIDIA, AMD, Intel, etc. They all load firmware blobs into who knows where on demand, and I would think ideally the RPI should work that way too.

What started me down this loader path was that it appears it's impossible with the current design of the firmware to actually create an open firmware without redoing the whole thing including writing some kind of loader.

[Electron752]

I was thinking, if I wanted to write a new loader yet keep compatibility with existing stuff. I would assume there is no reason this new loader couldn't have a selectable option that keeps compatibility with existing stuff, correct?

I could image some kind of menu system like grub has where one of the options is the existing system. Essentially all that would be required would be to load the standard bootcode.bin at the usual address and reset the VPU, correct?

[ghost]

@Electron752 The boot process is kinda immutable in the overall design. The chip itself has a bootrom, microcode that may not be changed and is programmed in at the time the chips are made. That is what loads a file called "firmware.bin" which its name is also hardcoded. That must be off USB or off a FAT filesystem. This is done by Broadcom.

Firmware.bin starts out on the GPU side of things, and has to initialize ram, bring up the ARM core, and do some other general set up tasks. This is required of any process that loads because none of that is done for us by the chip itself. So yes, the linux kernel could take over this job but logically it makes sense to not do this as part of the kernel. The code to do this would never be accepted upstream.

The difference between the way Intel or AMD x86 chips work is that they start out enabled. They then bring up the video second (the BIOS may bring it to a default state). This is more of the standard way things are done but with the Broadcom Soc used in RPi its backwards.

U-boot is not the only way to do things, and I think what you are getting at is you would like to see the boot loader do PXE or whatever else itself? That could be done in a "bare metal" application that would then load and switch to the kernel loaded. No need for u-boot but it would replace the u-boot part with something else and operate in a grand scheme in the same way (load and replace itself). Again, there is no reason to change the bootloader to do this as it gives you the tools to do exactly this out of the box.

The point about mentioning bare metal in my last post was to give you a pointer that may be more suitable. This thread was really about how the USBBOOT was not working with a RPi 0 1.3 and not about the larger boot process. The point about talking about the disassembler was shameless self promotion :) In part cause I want a job somewhere that pays more than the 0 I am currently earning.

[Electron752]

OK, I've move this discussion to the bare metal.

I think what's being missed here is not only do I want to replace the loader, but I also want to make an open firmware alternative available. Unfortunately, that isn't really possible by adding onto the existing system because the usually firmware is already loaded at that point. The only real option at that point is "kill" the running firmware that's already been loaded, and that's not a good design in my opinion.

[ghost]

Part of the firmware is on the chip and owned by Broadcom. The bootcode.bin, start.elf, etc uses Broadcom APIs afaik (thus the LICENSE.Broadcom file that has shipped with RPi distros since 2012 or so). That part cant be changed without doing what Compaq did in the 1980s (and it cost them $1M of 1980s money, back when $1M was a whole lot of money). One group/person has to reverse everything and write a spec. 0 coding done by that group. Another group which should be "clean" meaning they have 0 history of reversing anything, 0 history with the RPi boot process, etc would code the clean boot loader from the spec and only the spec and not ask for help or google anything (Compaq sequestered their developers while writing the IBM PC Bios clone). That is the only way it survived court challenges.

Because of HDMI keys and other stuff that is in the bootrom you can get into DMCA issues (in the US) even if you are just doing interoperability (one of the exceptions to the DMCA).

So its a gamble on a less than trivial process, and for what benefit when you can write your own "kernel" that just loads from however you want it to load. I mean how many people reflash their desktop bios to have a totally open boot loader? Especially when UEFI can be particularly nasty when it comes to malware (separate memory, processor, etc on many systems).

[Electron752]

OK, I think I understand what your saying.

It sound like what I want to really do is cause some of the components of the SOC that the RPI is based on to run a custom program chosen from the ARM. It sounds like in this case this would specifically be the VPU. The only issue is that the custom program wouldn't ever end. I'm not sure if the custom program would be linked in with the kernel image, or if it's loaded from an separate file.

Do you know if something like that is possible?

In my case, I'm specifically thinking this custom program could do a few things that can't easily be done from the ARM side such as manage power control. And it would of course use the mbox control registers for talking with the rest of my kernel.

[ghost]

I am not quite clear on what you are asking so I will offer more information in the hopes of the shotgun approach hitting your question.

The SoC microcode does the initial boot. That just loads bootcode.bin. Once it loads that file it hands off execution and basically stops running at least as a bootloader. Bootcode.bin loads start.elf and executes that (this is when the rainbow screen appears). At that point that is no longer running. Start.elf goes through its load up and initialization process and eventually it loads the linux kernel (or whatever is specified in config.txt). It then executes that and basically stops running.

While the SoC side does not ever completely 100% stop, thus the mailbox functionality, the components related to the boot process do go away for all intents and purposes once the kernel is executed. The linux kernel runs on the arm side while the other code lives in the vpu side. Mailboxes are how you bridge that gap.

When you use mailboxes to communicate between the two sides of the chip there is code that does handle that which is not open but neither is the firmware inside of your monitor :)

The kernel or whatever program you choose to run would not be linked to the SoC code. Mailboxes are used to communicate between the two (kinda like RPC calls). The kernel is loaded into memory and run - it must be free standing meaning it cannot rely on code from the system itself. It can rely on certain locations for things such as where the GPIO Function Select stuff is, or how to set the clock speed or whatever. These are defined in part in the Broadcom datasheet as well as the open release they did for some of the VPU stuff. There are also people that figured undocumented stuff out, wrote it down and that led to others being able to more easily learn it.

This is really not that different from knowing that a uart port on an x86 box was at port 0x3f8 (if memory serves). That was documented and set up by the bios to map it so that developers could have a sane, somewhat stable platform to code for. If memory addresses, ports, etc changed with each system it would ultimately mean software that works on one box would not work on another.

So if you wanted to write a custom boot loader program to replace u-boot or whatever you could. Specify that ifile n config.txt and it will be executed (on the arm side). I believe the only 3 files you will need in addition are config.txt, start.elf and bootcode.bin.

Your program can then have drivers for whatever hardware you want (ethernet, uart, etc). That can fetch the OS kernel from whatever source it can talk to (local storage, tftp/bootpc, pxi, etc). Using a similar process once you have loaded the new kernel you can just jump over to it and start executing and free the memory your bootloader used.

[Electron752]

Yes, I think we have two different issue here that have gotten mixed up. The boot progress and the custom open firmware. I think my ultimate goal here is simply to use as little of the existing stuff that gets loaded in the boot process as possible. And it sounds like as long as mbox isn't used, almost none of the existing stuff would be used.

Part of my goal here is to get the VC4 open source driver to work on the RPI3 even though the firmware is calling into the expander. I want to access the expander from the arm using the open source driver for it. I can't do that if some of the firmware is still running.

I want my kernel to be able to do power management, thermal, clock, etc. Most of which the information is all available. But I don't want to use any of the existing stuff that got loaded during the boot process.

[ghost]

You wont have a meaningful system without using mailboxes.

https://github.com/raspberrypi/firmware/wiki/Mailboxes

Mailboxes facilitate communication between the ARM and the VideoCore. This page lists the available mailboxes/channels. Each mailbox is an 8-deep FIFO of 32-bit words, which can be read (popped)/written (pushed) by the ARM and VC. Only mailbox 0's status can trigger interrupts on the ARM, so MB 0 is always for communication from VC to ARM and MB 1 is for ARM to VC. The ARM should never write MB 0 or read MB 1.

[Electron752]

Well, I guess a really simple way to accomplish what I'm looking for is to be able to set a custom handler for the unused mailbox. In this case 7. That handler could do things for my kernel from the VC side that can't or couldn't easily be done from the ARM side.

I'm still not sure how this would stop the expander access though.

Or possibly even overwrite the handlers for existing mbox functions.

[ghost]

well if you really really wanted to you could replace bootcode.bin and have it bring up the arm and run threads on it or something. But you should look at the instruction set for the VPU, I find it kinda small because it is not intended to work quite the same way as the arm side.

Here is where I got my list of opcodes for my disassembler so you can take a gander. His 2013 disassembler works but it does not do all of the code analysis that I want which is what prompted me to write my own :) Almost done with it too, but only 3 hours sleep today so I probably wont touch it again until tomorrow. http://hermanhermitage.github.io/videocore-disjs/dis.html

[ghost]

Oh you also may have issues with the broadcom license, read it - its included in the boot partition of every raspbian distro since 2012.

[Electron752]

That's the whole point. I don't really want to replace bootcode.bin. I really don't want to go in that direction, it's too difficult.

Perhaps I can simply overwrite the VPU interrupt vectors. I noticed some open source code that appears to be doing that.

Sorry you haven't gotten much sleep.

In fact, I think I saw in the open source firmware that the VPU interrupt vector base is programmable. Sounds like it could simple te set to a different base address.

But then, perhaps I'm way out in left field here.

[Electron752]

@Nom-DePlume

OK, I understand now what I need to do now. Essentially I need to completely reinitialize the entire system from the ARM.

Do you know offhand if during my initialization sequence if it's possible to initialize the VPU clock to be off? Or perhaps in my power management initialization initialize the VPU to be off?

The idea would be to keep the VPU off and thus stop any expander access period, or possibly only power it back on after swaping out it's code from under it. Kind of like what your saying with the monitor. Power down the monitor without actually assuming that it's functional.

[ghost]

You will probably get more answers on the RPi forums than here. This is for the usbboot software only, and this thread for the specific issue I raised. https://www.raspberrypi.org/forums

There may even be a thread about doing this, I havent looked.

[Electron752]

So the original topic was about usbboot. I just happen to have recently bought a PI 0-w. Is their any way I can help?

I've heard some other companies support printing debug information on JTAG if you have the correct debugging hardware. Any chance the soc supports something like that? I've read somewhere the GPU actually does have a JTAG port on the board somewhere.