NXLoader

NXLoader copied to clipboard

This is a discussion about what's needed to boot Linux from NXLoader, taking TegraRcmSmash as an example.

• Be able to change or remove the relocator payload (no relocator is needed to boot Linux) (line 761)
• Be able to send "sections" through RCM (coreboot.rom file) (lines 896 to 1042)

There is no need to use imx_usb with my method of booting Linux, so I suggest we use this one and not bother with imx.

The only files needed will be cbfs.bin and coreboot.rom. As they will probably not be updated (unless we make a change in u-boot), I suggest we embed them in the app to have a one-click Linux boot.

Here are the TegraRcmSmash logs for booting Linux :

TegraRcmSmash (64bit) 1.1.0-1 by rajkosto
Wanted device not connected yet, waiting...
Looking for devices matching the pattern *VID_0955&PID_7321*
Opened USB device path \\?\usb#vid_0955&pid_7321#5&376aba2d&0&1#{ad4c1f43-4e64-41cc-bf90-95800497c853}
RCM Device with id 0081030F0000001C01532C6401101062 initialized successfully!
Uploading payload (mezzo size: 0, user size: 2364, total size: 29904, total padded size: 32768)...
Switched to high buffer
Smashing the stack!
Smashed the stack with a 0x7000 byte SETUP request!
Switching to sending of section 'CBFS'
Sending 0x00007000 bytes from offset 0x00000000
Sending 0x00000004 bytes from offset 0x000ffffc
Sending 0x00000020 bytes from offset 0x00020138
Sending 0x00000018 bytes from offset 0x00020100
Sending 0x00000020 bytes from offset 0x00020118
Sending 0x00000018 bytes from offset 0x00020180
Sending 0x00000020 bytes from offset 0x00020198
Sending 0x0000001c bytes from offset 0x000201b8
Sending 0x00005332 bytes from offset 0x000201d4
Sending 0x00100000 bytes from offset 0x00000000
Finished sending section 'CBFS' (total bytes sent: 1098722)
Win32 error 31 during post-smash read op

Worth looking at this: https://github.com/MCMrARM/switch_linux_launcher

I think it should be possible to write a fusee payload that loads coreboot.rom from SD. This, combined with your method to load the kernel etc. from SD should make this doable without any significant changes to the app. Thanks!

It should, however I'm afraid I lack the knowledge to do so. fusée gelée doesn't have a sdmmc driver yet, so it's not on our side (yet).

I was able to port some of TegraRcmSmash, Shofel2 and switch_linux_launcher code into NXLoader. Here is what I come up with (no commit since it will break my PR) : https://pastebin.com/V7rZG0MA

Don't worry about the BOOTING_LINUX constant, it will be dropped in favor to user settings.

The current code doesn't work as I never recieve the CBFS request from coreboot (I don't receive anything actually).

This can mean two things :

1. The method to read the request is wrong, or
2. The payload is not correctly executed

My guess is more on the second one. Even though the payload is of the same length as the one that the original shofel2 sends, I think that it may not be correctly sent and / or executed.

I think this has to be with the DMA buffers and the 0x7000 constant. switch_linux_launcher uses similar code to NXLoader but with 0x6C68 instead of 0x7000.

Something I also noticed is that all other implementations send the header first (first 680 bytes), and then the payload. NXLoader sends everything at once. Maybe this messes the buffer alignment up ? Other implementations have a "ensure that we are on higher buffer" (fusée gelée, TegraRcmSmash) or "sanity check / throwing more data" (shofel2, switch_linux_launcher) that we don't have here.

In my implementation, the low_buffer keeps track of the current DMA buffer.

RE the header, fusee-launcher sends the whole payload at once.

I also had a go a while back, and ran into the same issue with never recieving the CBFS string. Have you tried using switch_linux_launcher on it's own? (I haven't, no time). I'm wondering whether maybe it just won't work on some devices.

rajkosto is working on getting fusee to bootstrap linux from the SD, so tbh I'd rather just wait for that, no need to implement a feature in the app which will soon become obsolete. He reckons he might get it done in the next couple of days. (fusee already has sdmmc support btw)

If rajkosto is working on it then I agree that it's better to keep this app as minimal as possible.

I've tried switch_linux_launcher, ~~CMake was not happy with imx_usb_loader so I just removed it altogether~~ I forgot to init submodules, duh

And it works, so we must be doing something wrong here.

If I had to guess where the bug is, it's in the REAPURB part, because TBH I don't understand what it does very well.

switch_linux_launcher does things subtly differently (and probably correctly).

Would it be that NXLoader breaks the USB connection by wrongly reaping the URB and thus it can never read the CBFS signal ?

Yeah, that sounds plausible.

Actually, looking a bit more closely, my usage of REAPURB is completely broken. So yeah, that'd probably be it...

Should I bother fixing it to see if it allows us to boot Linux using CBFS ?

yes pls :) any progress on this? and cant you run a console on android? you could port the same toolchain over to android, no?

I suggest you try memloader, a fusee-launcher payload which allows to boot into Linux without sideloading anything. If it works, this issue becomes irrelevant.