Hacking RELEASE Argon NX - Payload chainloader

[mrdude]

@mattytrog.

I embedded SXOS payload inside the Argon payload and still had some space left over, so I have my licence files embedded in the argon payload as well. Now when I boot - if I short press vol+ when I'm booting the embedded sxos payload boots. If I keep my finger on v+ Argon menu boots and I can boot another payload or generate my licence files. If the switch boots with no micro sd card into rcm - it will auto turn off again so no battery drain. If the sd card is formatted and contains no argon files, the Argon menu loads and you can generate sxos licence files + sx os payload bin on your sd card. If I want to go to sx os boot menu, when the sx logo appears - I just press v+
That's about all I can think of for now - I'm sure other stuff can be added in the future as I still have a bit of space left to play with.
What code did you edit for the touchscreen? I remember you saying you updated that code, can you post your modded file here?

 

[mattytrog]

@mattytrog.

I embedded SXOS payload inside the Argon payload and still had some space left over, so I have my licence files embedded in the argon payload as well. Now when I boot - if I short press vol+ when I'm booting the embedded sxos payload boots. If I keep my finger on v+ Argon menu boots and I can boot another payload or generate my licence files. If the switch boots with no micro sd card into rcm - it will auto turn off again so no battery drain. If the sd card is formatted and contains no argon files, the Argon menu loads and you can generate sxos licence files + sx os payload bin on your sd card. If I want to go to sx os boot menu, when the sx logo appears - I just press v+
That's about all I can think of for now - I'm sure other stuff can be added in the future as I still have a bit of space left to play with.
What code did you edit for the touchscreen? I remember you saying you updated that code, can you post your modded file here?

Cool.

Think my code is pretty similar...

However, I filled my array with 256 bytes of "SXOS"... Like this... Nice and easy.

void restore_license_dat(){
    gfx_clear_grey(&gfx_ctxt, 0x00);
    gfx_con_setpos(&gfx_con, 0, 0);
    unsigned char license_dat[256] = {"SXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOSSXOS"};
    if (!sd_mount()){
        return;
    }
    //does it exist?
    if (f_stat("license.dat", NULL) == FR_OK){
        gfx_printf(&gfx_con, "\nSXOS license.dat exists!\n\nCancelled.");
        msleep(3000);
        return;
    } else {
        gfx_printf(&gfx_con, "\nPlease wait\n\n");
    sd_save_to_file(license_dat, sizeof(license_dat), "license.dat");
        gfx_printf(&gfx_con, "Success. Written %d bytes", sizeof(license_dat));
    sd_unmount();
    msleep(3000);
    }
    return;

}

The idea was to open it in hex editor, look for the array (easy to spot), copy and paste over the "SXOS"...

Works well but frowns aplenty I`m sure...

Saves having to build from source. Just edit the bin file, copy/paste... done.

EDIT: Thinking about it, now the stack is small enough... It is well under 126296 bytes now... Stil don`t think it would be a good idea though because of the open-source purists. Did it ages ago for Simple-UF2.

EDIT:EDIT Oh, sod it. Might as well use it in Switchboot. Was going to shoehorn a couple of blz grafix in there but I`ll put this in.

So if anyone is using SXOS, has a "modchip" and can use a hex editor... Overwrite the SXOSSXOS... with the bytes from license.dat. It will fit EXACTLY. Like a jigsaw.

You can`t lose it then. Swap SDs, make a new file. Someone might use it. Fk knows...

 

[mrdude]

Yep, the code is similar, I've not used C before, only C++ on Arduino - and not much of that. I had a look at some examples of C on the net - but the way it dealt with reading/writing files is different than the code I saw in the lockpic/argon files, that's why I was having trouble getting the files to write. Also I don't know how to debug code on the Switch - so it was hit and miss wondering why line of code I was having problems with - as it compiled fine.
Still thanks for posting your code, I wasn't sure on the sleep command, but I see that in your code so that will come in handy.

I wouldn't worry too much about some people frowning, we are all adults and can make our own decisions on what we want to put on our chips/devices - I for one don't care what others think about what I do with my own property. It better to have some choices rather than no choices. I can assure you that if Hekate/Argon didn't exist - everyone would be using SXOS. It's a personal choice though, and I prefer SXOS to Atmos - far easier to set up and use and has way more features.

 

[mattytrog]

Yep, the code is similar, I've not used C before, only C++ on Arduino - and not much of that. I had a look at some examples of C on the net - but the way it dealt with reading/writing files is different than the code I saw in the lockpic/argon files, that's why I was having trouble getting the files to write. Also I don't know how to debug code on the Switch - so it was hit and miss wondering why line of code I was having problems with - as it compiled fine.
Still thanks for posting your code, I wasn't sure on the sleep command, but I see that in your code so that will come in handy.

I wouldn't worry too much about some people frowning, we are all adults and can make our own decisions on what we want to put on our chips/devices - I for one don't care what others think about what I do with my own property. It better to have some choices rather than no choices. I can assure you that if Hekate/Argon didn't exist - everyone would be using SXOS. It's a personal choice though, and I prefer SXOS to Atmos - far easier to set up and use and has way more features.

Each to their own I guess.

It has been a steep learning curve for me. After a 25 year break, I was essentially starting from scratch. Assembler (MC68000) used to be by thing with a bit of the old C for good measure.

But anyway back ontopic... Do your stuff, submit a "pull request" and maybe the author will include it. Just be mindful of the 126296 limit. It`s caught me out before.

 

[mattytrog]

Oh yeah... double-post...

You asked about the touch screen. That was easy.

touch_event_t touch_wait()
{
    i2c_send_byte(I2C_3, 0x49, 0xa1, 0);<<<<<<<<<<<<<<<<<<<<<<THIS
    touch_event_t event;
 
    do
    {
        touch_poll(&event);
    }
    while(event.type == STMFTS_EV_NO_EVENT);<<<<<<<<<<<<<<<<<<THIS
 
    return event;
}

What this does is clears the stack at every poll, giving the touch code a "clean sheet" to work from.

Helps with touch sensitivity. (If my logic and understanding of the datasheet are ind of accurate...)

@mrdude

Little challenge for you...

Should get you up to speed

RE background images.

As we know, reading an RGB bitmap to the framebuffer is incredibly slow. At the moment, so we don`t see the image build line-by-line, it relies on drawing it to a separate buffer then just swapping the buffer once the rendering is complete... Thats how the image pops up in the later versions of Argon. The early versions drew it line-by-line to the present (only) buffer and you would see this...

Heres an idea...

You still (should) have plenty of room left in the stack... (I`m shit at artwork. I cannot draw. I have ZERO art skills whatsoever, and I`ve seen yours)...

Maybe you could make something flashy (being mindful of the stack size - 32bit rgb image), compress it to a blz compressed image, copy/paste it as a c array and have the program decompress it and flush it to the fb.

It would render almost instantly, resulting in faster booting... (This is how Sept splash works).

Maybe worth a thought? Might have a go myself, but like I say, I cannot draw. Probably draw a c*ck and a pair of balls but thats about it.

Big hint... Look in logos.h in Hekate and in memloader there is a blz compression utility

 

[mrdude]

@mattytrog

Thanks, I tried your touchscreen mods - but It didn't seem to make any difference for me, that's me finished my mods now:

For some reason booting into OFW - didn't work due to the coding in the panic void - I changed it to use the same code that was in lockpic and then it worked fine.

void panic_alt(u32 val)
{
    // Set panic code.
    PMC(APBDEV_PMC_SCRATCH200) = val;
    //PMC(APBDEV_PMC_CRYPTO_OP) = 1; // Disable SE.
    TMR(TIMER_WDT4_UNLOCK_PATTERN) = TIMER_MAGIC_PTRN;
    TMR(TIMER_TMR9_TMR_PTV) = TIMER_EN | TIMER_PER_EN;
    TMR(TIMER_WDT4_CONFIG)  = TIMER_SRC(9) | TIMER_PER(1) | TIMER_PMCRESET_EN;
    TMR(TIMER_WDT4_COMMAND) = TIMER_START_CNT;
    while (1)
        ;
}

Now if the switch boots into rcm with no sd card, a message tells you that you don't have an sd card and boots into OFW instead when you press the power button. That's me done with this now - I've changed a few things, to make my chip the best way that I want to use it - if anyone wants me to post the modded files just let me know and i'll upload them.

Also @mattytrog, I was thinking to save space all 0xFF and 0x00 in the embedded sxos payload file can be generated in a loop, and then concatenated to make the payload far smaller - as a lot of space in a payload contains that data, I could save quite a lot of space and embed those into the argon payload - I'll try that with the sxos payload so the generated file will be the same, but far less bytes will be used in the argon payload and therefore no need to worry about the space used.

For example, I made this function to test creating a lot of hex bytes with the same value:

static int tool_hexgen(void* param) {

   int number = 0;
   char out[256] = ""; //size of array - number of bytes to make
   while( number < sizeof(out) ) { //number of times to loop = number of bytes to make
      number++;
          char myhex[] = "\xFF"; //put the byte here you want to generate
          strcpy(out, out);
          strcat(out, myhex);
   }
   sd_save_to_file(out, sizeof(out), "test.txt"); //create a text file to check the output.
   return 0;
}

So if you want to create xx amount of bytes - just change 256 to whatever number you want and \xFF to the bytes you want to make, so say you get a bit in a file with 400 - 0x00 next each other - you can just call this function to make those bytes - that way you can embed payloads and vastly reduce their size :-).

 

[mrdude]

Maybe you could make something flashy (being mindful of the stack size - 32bit rgb image), compress it to a blz compressed image, copy/paste it as a c array and have the program decompress it and flush it to the fb.

32bit 1280x720 BMP are always the same size (over 3 megabytes), Compressing them with blz still makes the image size over 1 megabyte, so there's not enough room to embed that in the payload. Unless I'm missing something - I don't think it's going to be possible.

 

[mattytrog]

32bit 1280x720 BMP are always the same size (over 3 megabytes), Compressing them with blz still makes the image size over 1 megabyte, so there's not enough room to embed that in the payload. Unless I'm missing something - I don't think it's going to be possible.

The simpler the picture, the better. You could possibly put it at another point in iram. I'll have a look when I get back. At the coast at the minute

 

[mrdude]

The simpler the picture, the better. You could possibly put it at another point in iram. I'll have a look when I get back. At the coast at the minute

Do you remember back in the Amiga days - you used to have old school demos? Well you could probably do something similar on the switch, Here's some source code -

https://master.dl.sourceforge.net/p...iles/The_Demo_Effects_Collection_0.6.1.tar.gz

They rely on using sdl - but the switch can run this already, you could likely do a bad ass demo, sinus scroller etc, with that - no need to worry about loading a large bitmap either as the code base is pretty small.

 

[hippy dave]

You won't be able to use SDL from the bootloader, it needs the OS/libraries loaded. You'd have to go real old-school and write directly to the framebuffer.

 

[mattytrog]

Do you remember back in the Amiga days - you used to have old school demos? Well you could probably do something similar on the switch, Here's some source code -

https://master.dl.sourceforge.net/p...iles/The_Demo_Effects_Collection_0.6.1.tar.gz

They rely on using sdl - but the switch can run this already, you could likely do a bad ass demo, sinus scroller etc, with that - no need to worry about loading a large bitmap either as the code base is pretty small.

I very much doubt we could use SDL without HOS

Framebuffer is the limit I reckon.

 

[mrdude]

Ok Matty, what about this - I've not read much about frame buffers but from what I've read it's memory for storing a bitmap in. I don't know if it refreshes x amount of times per second - but I imagine it does.

Now what about instead of loading a bitmap for the menu, you split the display into 8 squares or something, and each square can be filled with a different colour and then cycled to another colour every 60 miliseconds or so - this would give a mad effect and it probably wouldn't use all that many bytes to do. That way you don't need to be great at drawing or compress any bitmaps etc. Personally I was thinking about adding a starfield effect to my chip, and maybe a sinus scroller.

 

[Joxley192]

@mattytrog Is there a way to get Lakka to load using argon cause I like to use argon but cause I use Lakka lot I have to use Hekate

 

[mattytrog]

There certainly is. I'll build something tomorrow. Remind me!

 

[Joxley192]

@mattytrog Hey just wondering if u made something for Lakka to use on this just a reminder

 

[Joxley192]

Hey did u get lakka to work on this

 

[lordelan]

Is there a way to use this to boot L4T?

 

[designgears]

booting lakka from hekate is pointing at lakka/boot/coreboot.rom, you could try copying that out to argonx payload folder and see if it boots. If not you need something that can point to that file.

Edit: just tried, it has to boot in place, so you'd need to modify argonx to work that way.

Edit2: booting l4t is even harder since it has to boot from an image written to the sdcard, didn't realize they were different.

 

[hippy dave]

Argon got a big update today, v1.0-alpha.

 

[regnad]

Is anyone else having problems with this?

Previously I’d been using 0.3 with no problems, but with this new release the selection screen background is just black and only three of my payloads appear, all on the right side of the screen.