The Linux Thread - The Autist's OS of Choice

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
prollyanotherlurker said:
Can anyone get a screenshot of this, or something. That link just endlessly cycles through a test page. And clicking the actual x link does nothing, but show a page with the x logo.
Click to expand...

Here.
1771302715743.png

1771302783270.png


Images that were attached to Lunduke's post:

1771302931021.png

1771303004442.png

1771303033927.png

1771303071661.png
 
Why is lunduke saying plasma will force users to use systemd because plasma dm requires elogind? I know it's a systemd component but it works fine on alt inits, and artix just uses another DM so idk what the problem is
Wayland also should be usable on freebsd
Benno rice predicted this in his talk "the tragedy of systemd" where he said we shouldn't be celebrating freebsd not having a systemd, but treating that as something we're lacking
I don't use systemd and I don't use freebsd but not having developed an alternative to logind in all this time has deviated Linux from freebsd to a point where some stuff just isn't gonna run
 
Last edited:
I AM UNDOUBTEDLY FIZZED8% said:
Here.
View attachment 8571644

View attachment 8571649


Images that were attached to Lunduke's post:

View attachment 8571655

View attachment 8571659

View attachment 8571663

View attachment 8571666
Click to expand...
So core components of KDE are being/have been changed to require systemd, but that doesn’t count because you can use the rest of the rest of the DE without relying on systemd? Strange arguing from all sides here, but I’m siding against KDE.

Sidenote about Wayland on *BSDs, there is nothing inherantly stopping a Wayland compositor from running on any Unix system, but conventionally a lot of Wayland programs depend on Linux’s non-Posix extensions which would make porting things annoying at best. For example, Wayland apps conventionally make heavy use of anonymous file descriptors, and there is no simple Posix-compatible syntax for creating anonynous fds. You can bodge it by opening a shm then immediately unlinking it from its name, but unlinking doesn’t always succeed, and this shit is gay regardless. Alternatively, Linux and FreeBSD both support a function called memfd_create, which just creates a file descriptor with no extra fuss. I believe one of the BSDs supports passing a null pointer to shm_open instead of a filename. Other than that, you’re stuck with the Posix bodge.
There is also the issue of DRM, but afaik the BSDs have generally adopted DRM as their GPU API in order to be able to port over modern GPU drivers from Linux.
 
August Levasseur said:
So core components of KDE are being/have been changed to require systemd, but that doesn’t count because you can use the rest of the rest of the DE without relying on systemd? Strange arguing from all sides here, but I’m siding against KDE.

Sidenote about Wayland on *BSDs, there is nothing inherantly stopping a Wayland compositor from running on any Unix system, but conventionally a lot of Wayland programs depend on Linux’s non-Posix extensions which would make porting things annoying at best. For example, Wayland apps conventionally make heavy use of anonymous file descriptors, and there is no simple Posix-compatible syntax for creating anonynous fds. You can bodge it by opening a shm then immediately unlinking it from its name, but unlinking doesn’t always succeed, and this shit is gay regardless. Alternatively, Linux and FreeBSD both support a function called memfd_create, which just creates a file descriptor with no extra fuss. I believe one of the BSDs supports passing a null pointer to shm_open instead of a filename. Other than that, you’re stuck with the Posix bodge.
There is also the issue of DRM, but afaik the BSDs have generally adopted DRM as their GPU API in order to be able to port over modern GPU drivers from Linux.
Click to expand...
So this is specially a bsd/other unix-like vs Linux problem at this point
Alt inits on Linux have solved this by running systemd components in tandem with alt inits, but the bsds dont even have that
KDE isnt the first program to say yeah were just not gonna be cross compatible between Linux and bsd, though that isn't even the case here because it's just specific components of KDE which aren't bsd compatible. mate and other desktop environments have this too, where Linux specific tools like the sound control app don't work
 
I don't understand the argument Lunduke is making. This might be because I am retarded, or because Lunduke is retarded. I think it's much more likely for Lunduke to be retarded than me.

Both freeBSD and even openBSD (experimental still) support wayland. Obviously if you're using openBSD you're probably running Xenocara (openbsd's fork of X.org openBSD's not-a-fork of X.org) anyways otherwise you wouldn't be using openBSD. Similarly, if you're using openBSD you're probably not running plasma/KDE. But for freeBSD specifically... Nothing stops you from running Wayland KDE.
 
Last edited:
mango_reseller said:
Both freeBSD and even openBSD (experimental still) support wayland. Obviously if you're using openBSD you're probably running Xenocara (openbsd's fork of X.org) anyways otherwise you wouldn't be using openBSD. Similarly, if you're using openBSD you're probably not running plasma/KDE. But for freeBSD specifically... Nothing stops you from running Wayland KDE.
Click to expand...
He just had no idea what he was talking about. As far as I know freebsd wayland support isn't even something new. They've for sure had it for a couple years at least.
 
jeff7989 said:
In some good news, some madlad decided to fix Oxygen theme for KDE. Will be useful once SonicDE matures enough for me to install it.
Click to expand...
I would presume it's fairly stable at the moment as it's only forking the components needed for X11 support and pulling from upstream the rest. It's basically just fixing things that are broken, with the occasional new feature like Xnamespaces support of you're using Xlibre.
 
ProudSkibidiTolietAryan said:
Ok.. FINALLY. I have implemented it.. FULLY...
And ill tell you FIGURING out this shit was a pain.


The solution was a FUCKING pain but I figured out there are also MULTIPLE chekcsums within the spare area that all need to be calculated.
uint8_t fixed_oob[64]; memset(fixed_oob, 0, sizeof(fixed_oob)); memcpy(fixed_oob, oob, 64); //FIX THE OOB AREAS. People from russia and the middle east or wherever your neighborhood looks straight out of Call of duty 4 use external NAND programmers to dump the NAND. //However during acutal DMA reads these bytes are SLIGHTLY different and the NAND controller changes it. Undocumented of course because my life is never easy. if (fixed_oob[2] == 0x61){ printf("SPECIAL HANLDER!"); switch (logical_block) { default: break; } } uint8_t *checksum21000byteoffset = s->flash_data + page_start + 512; uint8_t *yesANOTHERchecksum = s->flash_data + page_start + 0x700; uint8_t *yesANOTHERANOTHERchecksum = s->flash_data + page_start + 0x300; uint8_t ecc_input[8]; uint8_t page_input[256]; uint8_t thousandbyteoffsetpageinput[256]; uint8_t yesANOTHERchecksuminput[256]; uint8_t yesANOTHERANOTHERchecksuminput[256]; memcpy(page_input, page_data, 256); memcpy(thousandbyteoffsetpageinput, checksum21000byteoffset, 256); memcpy(yesANOTHERchecksuminput, yesANOTHERchecksum, 256); memcpy(yesANOTHERANOTHERchecksuminput, yesANOTHERANOTHERchecksum, 256); printf("Calculated PAGE checksum with 1000 byte offset: %02X %02X %02X\n", checksum21000byteoffset[1], checksum21000byteoffset[2], checksum21000byteoffset[3]); //12 read_oob_data(fixed_oob, ecc_input); ecc_bytes_t stored_struct = checksum_or_ecc(ecc_input, 8); ecc_bytes_t stored_page_struct = checksum_or_ecc(page_input, 256); ecc_bytes_t stored_1000bytes_inchecksum = checksum_or_ecc(thousandbyteoffsetpageinput, 256); ecc_bytes_t yesANOTHERchecksum2 = checksum_or_ecc(yesANOTHERchecksuminput, 256); ecc_bytes_t yesANOTHERANOTHERchecksum2 = checksum_or_ecc(yesANOTHERchecksuminput, 256); printf("Calculated ECC: %02X %02X %02X\n", stored_struct.b0, stored_struct.b1, stored_struct.b2); printf("Calculated PAGE checksum: %02X %02X %02X\n", stored_page_struct.b0, stored_page_struct.b1, stored_page_struct.b2); printf("Calculated PAGE checksum with 1000 byte offset: %02X %02X %02X\n", stored_1000bytes_inchecksum.b0, stored_1000bytes_inchecksum.b1, stored_1000bytes_inchecksum.b2); printf("Other checksum: %02X %02X %02X\n", yesANOTHERANOTHERchecksum2.b0, yesANOTHERANOTHERchecksum2.b1, yesANOTHERANOTHERchecksum2.b2); printf("Start off ECC: %02X %02X %02X\n", fixed_oob[0], fixed_oob[1], fixed_oob[2]); printf("Fixed ECC: %02X %02X %02X\n", fixed_oob[36], fixed_oob[37], fixed_oob[38]); //copy stored checksum into the block fixed_oob[36] = stored_struct.b0; fixed_oob[37] = stored_struct.b1; fixed_oob[38] = stored_struct.b2; //copy page checksum to the block.(still in the ECC spare area) fixed_oob[12] = stored_page_struct.b0; fixed_oob[13] = stored_page_struct.b1; fixed_oob[14] = stored_page_struct.b2; fixed_oob[33] = yesANOTHERANOTHERchecksum2.b0; fixed_oob[34] = yesANOTHERANOTHERchecksum2.b1; fixed_oob[35] = yesANOTHERANOTHERchecksum2.b2; fixed_oob[18] = stored_1000bytes_inchecksum.b0; fixed_oob[19] = stored_1000bytes_inchecksum.b1; fixed_oob[20] = stored_1000bytes_inchecksum.b2; fixed_oob[40] = yesANOTHERchecksum2.b0; fixed_oob[41] = yesANOTHERchecksum2.b1; fixed_oob[42] = yesANOTHERchecksum2.b2; //Now also write to the PHSYICALL buffer so if it gets called via a method that is NOT just reading the spare area it will still show the correct changes. s->flash_data[page_start + 2048 + 36] = fixed_oob[36]; s->flash_data[page_start + 2048 + 37] = fixed_oob[37]; s->flash_data[page_start + 2048 + 38] = fixed_oob[38]; s->flash_data[page_start + 2048 + 12] = fixed_oob[12]; s->flash_data[page_start + 2048 + 13] = fixed_oob[13]; s->flash_data[page_start + 2048 + 14] = fixed_oob[14]; s->flash_data[page_start + 2048 + 33] = fixed_oob[33]; s->flash_data[page_start + 2048 + 34] = fixed_oob[34]; s->flash_data[page_start + 2048 + 35] = fixed_oob[35]; s->flash_data[page_start + 2048 + 18] = fixed_oob[18]; s->flash_data[page_start + 2048 + 19] = fixed_oob[19]; s->flash_data[page_start + 2048 + 20] = fixed_oob[20]; s->flash_data[page_start + 2048 + 40] = fixed_oob[40]; s->flash_data[page_start + 2048 + 41] = fixed_oob[41]; s->flash_data[page_start + 2048 + 42] = fixed_oob[42]; //IF THE SYSTEM does a FULL page read instead of just a OOB FIRST it will get the OLD checksum...
And yes that also means remaking the checksum function from the bootloader that is psudeocode from ghirda into REAL c code that we can then use. That is what the Checksum or ecc function is. And YES im aware the 1000 byte var name is actually NOT 1000 bytes and yes I was to lazy to change it. And let me tell you FIGURING all of this out on my own is fucking hard, Like I dont even really know what a ground is in electrical engineering. I was not able to read the circut diagrams or anything. Hell I barely understand binary.

My question is WHY is every checksum in the NAND for this TV repair fourm have ALMOST the correct checksum but is slightly off for every single one. Ive noticed this with MULTIPLE different ones. Which makes no sense.. How come ALL of them are slightly off. You may say that these dumpers are idiots and most likely FUCKED something up.. But then how come people have left positive reviews saying they work? How come these dumps WORK despite having WRONG checksums that are slightly off.. Because you NEED all the checksums to be right to simply BOOT UP the TV. I have a theory that MAY explain it.

When the PNX processor does a DMA transfer or direct access memory it may ADD or subtract or using a mathematical algorithm changes the stored checksum values to make it match the calculated checksum. Im assuming the way it calculates is using the hardware IDS of certain parts. Let me give you a example of my theory

So the stored checksum is 01 00 00, but the calculated checksum is 15 00 00. This is a obvious mismatch that if returned and placed into ram to compare will result in a NON match. However if the bytes sent are intercepted and changed before placed in ram to then be compared with the calculated checksum then it would work.

The processor may using the HARDWARE ids of certain parts(Lets say that the NAND id is 10 and the display is 4) to change the number to 15(in this example of course) when doing a DMA read(Not physically writing to the NAND just returning different bytes) and then place it in ram as requested. It uses the stored checksum in its calculation so that if its 02 00 00 or anything other than 01 00 00(in this simplified example of course) it wont work. This would explain WHY these dumps despite having every checksum wrong work perfectly on the TVS, because a external programmer does not follow those rules. And it makes sense WHY it would do such a thing. Its to prevent anti counterfiet parts. Or for example prevent someone who works at the docks or shipping lines from taking apart the TV, removing the high quailty parts inside of it and then putting it shitty parts and sending it back to the shipping process onto shore shelves before selling the High quailty parts. Its a Security measure, and it aligns up really well.

Because we don't know WHAT this pattern is or if this theory is even true, We have to make the DECOMPILED code of the checksum function In c and MANUALLY change every checksum requested by the tvs bootloader to match.

And I can say it passes EVERY checksum perfectly. Except for one type. There are special pages that seem to be different that I need to figure out ones that work differently and in a way that I cant understand.
1771012601256.png
You see this function. Yes I am TERRIBLE at naming things. But THIS function handles MOST of the checksums. There is a special path that fucks everything up that it can take it seems.
  1. Take the SPARE area of the page and move it to ram.
  2. Calculate the checksum of some bytes in ram and compare it against a STORED checksum in the spare area. If it does not match mark it as bad.
  3. Then scan the ENTIRE page and if the checksum generated MATCHES the stored checksum in the spare area.
  4. Do this with a few MORE stored checksums in the spared area for different parts of the file if its a SPECIAL page or holds extremely important information

    Now this is what this SPECIAL path does
  5. It takes the SPARE area of the page and moves it into ram.
  6. Then ZEROS THAT SECTION IN RAM SO THAT ITS ALL FUCKING ZERO.
  7. And then does the checksum(keep in mind its physically impossiable for the checksum function to generate a area with Pure 0s)
  8. It then takes the calculated Checksum and then compares it to the memory that is fucking ALL zeros like a stored checksum and then when it does not match it bitches.
What the HELL. Again. 00 00 00 is PHYSICALLY impossible to generate. So why would it ZERO that area in memory and then complain that it does not match the ACUTAL checksum of the page. Obviously I account for this, and I cant just CHANGE the stored Checksum data, because it fucking ZEROS it in ram.

SO what the hell am I suppose to do? What is happening?.. Well this is where I say its time for ANOTHER REVERSE ENGINEERING session. yeaahhhhh.

1771013042849.png
Alright so this is the function that it calls that ZEROS it.
1771013105288.png
(Ignore the function name that was just a guess I have no Idea what it does)
Alright so its trying to READ something in the NAND or RAM version of the NAND without spare bytes.
1771013853884.png
You see these numbers These numbers are mostly bullshit throw em out the window. Ghirda is trying to map it to a address space in the programs memory because it cant understand that the program is trying to talk to the hardware.

So what it does is UNKNOWN at this time. ill get back when I have more free time today and dissect it. But we can make a few guesses.

In the TV there are technically THREE different processor. One is the pnx 5100 which handles image output decoding and image quality adjustments like motion blur reduction and more, The first is the PNX 85xx family processor that handles the main processing and handles the actual TV and linux. And finally a 8045 1980s like processor, this is because the TV when turned off still needs to process remote control commands like Power on, and because of TV regulations stating that they must use a ABSURDLY little amount of power they use a extremely old processor to do that and turn off the other processors when put in standby mode. When a power button gets pressed it sets up everything and then turns on the pnx85xx processor which starts from the bootloader to begin executing instructions and then start up Linux,

Im betting that maybe those 00s its pulling it are data that the 16 bit 8045 processor would fill into RAM before starting the pnx85xx processor as maybe a calculation that cant be stored or maybe security feature.

OK so I found out what ZEROS that part of memory that fucks up the checksum. Its here in this function
1771093042080.png
Good thing is that with GDB we can tell it to STOP qemu when it lands exactly on this part and then see WHAT its doing. Doing that we see that its reading from a random piece of memory that is almost ALL zeros.. Which means that its suppose to be filled by the hardware with something. What that is I have no clue. We can just fill that part of memory with the checksum that would be calculated so it matches. As for if that works you will have to see because im busy with other things right now and will try it out tomorrow.
Click to expand...
Im back.


Every single one works
(When A0 and A1 Match that means the checksum function will pass)
A0 equals the STORED checksum that the algorhythm I decompiled is modifying before sending to the bootloader.
A1 equals the Calculated Checksum.
if they don't match it fails.

1737549615985o.png
Every time when they would mismatch and there was ANOTHER stored checksum that had to be recalculated i would have to.
  1. Find where those bytes in $a0 are in my hex editor by searching for the pattern of bytes and locating it.
  2. Then once I identify it I have to figure out the start and end between the start of the PAGE and the start of the bytes its wanting to calculate(Which is consistant across all)
  3. THEN after that I then update it by adding a NEW one to it using that information doing a calculation of the checksum that is taken directly from the bootloader that I reversed engineered and got working in GCC c. And then correct those 3 bytes in the area.
  4. And then it usually fails because I forgot that arrays start at 0.
  5. And then it fails because I fucked up the 4 different names
  6. And then it fails because I forgot that i needed to put INPUT not calc.
  7. And then maybe it compiles.
And then after that it would go to a NEW section of the 64 byte spare area with ANOTHER CHECKSUM that needs to be recalculated for the bootloader since we don't know the pattern in which REAL hardware affects it via DMA. Rinse and REPEAT

C: 
static void correct_spare_area(uint8_t *fixed_oob, PNXNANDState *s, uint32_t phys_dest, uint32_t page_start){
//External Nand programmers take the RAW information of a nand dump. However it seems this chip seems to MODIFY the raw information during dma transfers instead just storing it raw. So we need to RECALCULATE the information to work.

//performance wise this code sucks however
//1. for such a SMALL file size(128) its really does not matter on modern processors
//2. This code is missing SOME of the checksums that im still figuring out. Once it WORKS I will remove all the performance killers
//3. It can still correct the ENTIRE nand within 2 seconds with this code. One and done.
uint8_t *checksum21000byteoffset = s->flash_data + page_start + 512;
uint8_t *yesANOTHERchecksum = s->flash_data + page_start + 0x700;
//I thought this was the last one
uint8_t *yesANOTHERANOTHERchecksum = s->flash_data + page_start + 0x700;
//and this one
uint8_t *yesANOTHERANOTHERchecksum3data = s->flash_data + page_start + 256;
//and this one.
uint8_t *finalechecksum  = s->flash_data + page_start + 0x300;
uint8_t *finaleFINALchecksum  = s->flash_data + page_start + 0x500;
uint8_t *finaleFINALFINALchecksum  = s->flash_data + page_start + 0x600;
uint8_t *definitionofinsanity  = s->flash_data + page_start + 0x400;

        uint8_t *page_data = s->flash_data + page_start;

uint8_t ecc_input[8];
uint8_t page_input[256];
uint8_t thousandbyteoffsetpageinput[256];
uint8_t yesANOTHERchecksuminput[256];
uint8_t yesANOTHERANOTHERchecksuminput[256];
uint8_t yesANOTHERANOTHERchecksuminput3[256];
uint8_t finalechecksuminput[256];
uint8_t finaleFINALchecksuminput[256];
uint8_t finaleFINALFINALchecksuminput[256];
uint8_t definitionofinsanityinput[256];


memcpy(page_input, page_data, 256);
memcpy(thousandbyteoffsetpageinput, checksum21000byteoffset, 256);
memcpy(yesANOTHERchecksuminput, yesANOTHERchecksum, 256);
memcpy(yesANOTHERANOTHERchecksuminput, yesANOTHERANOTHERchecksum, 256);
memcpy(yesANOTHERANOTHERchecksuminput3, yesANOTHERANOTHERchecksum3data, 256);
memcpy(finalechecksuminput, finalechecksum, 256);
memcpy(finaleFINALchecksuminput, finaleFINALchecksum, 256);
memcpy(finaleFINALFINALchecksuminput, finaleFINALFINALchecksum, 256);
memcpy(definitionofinsanityinput, definitionofinsanity, 256);

printf("Calculated PAGE checksum with 1000 byte offset: %02X %02X %02X\n", checksum21000byteoffset[1], checksum21000byteoffset[2], checksum21000byteoffset[3]);

//12
read_oob_data(fixed_oob, ecc_input);
ecc_bytes_t stored_struct = checksum_or_ecc(ecc_input, 8);
ecc_bytes_t stored_page_struct = checksum_or_ecc(page_input, 256);
ecc_bytes_t stored_1000bytes_inchecksum = checksum_or_ecc(thousandbyteoffsetpageinput, 256);
ecc_bytes_t yesANOTHERchecksum2 = checksum_or_ecc(yesANOTHERchecksuminput, 256);
ecc_bytes_t yesANOTHERANOTHERchecksum2 = checksum_or_ecc(yesANOTHERANOTHERchecksuminput, 256);
ecc_bytes_t yesANOTHERANOTHERchecksum3 = checksum_or_ecc(yesANOTHERANOTHERchecksuminput3, 256);
ecc_bytes_t finalechecksumcalc = checksum_or_ecc(finalechecksuminput, 256);
ecc_bytes_t finaleFINALchecksumcalc = checksum_or_ecc(finaleFINALchecksuminput, 256);
ecc_bytes_t finaleFINALFINALchecksumcalc = checksum_or_ecc(finaleFINALFINALchecksuminput, 256);
ecc_bytes_t definitionofinsanitycalc = checksum_or_ecc(definitionofinsanityinput, 256);

printf("Calculated ECC: %02X %02X %02X\n", stored_struct.b0, stored_struct.b1, stored_struct.b2);
printf("Calculated PAGE checksum: %02X %02X %02X\n", stored_page_struct.b0, stored_page_struct.b1, stored_page_struct.b2);
printf("Calculated PAGE checksum with 1000 byte offset: %02X %02X %02X\n", stored_1000bytes_inchecksum.b0, stored_1000bytes_inchecksum.b1, stored_1000bytes_inchecksum.b2);

printf(
    "Other checksum: %02X %02X %02X\n"
    "Other Checksum actual DATA %02X %02X %02X\n",
    yesANOTHERANOTHERchecksum2.b0,
    yesANOTHERANOTHERchecksum2.b1,
    yesANOTHERANOTHERchecksum2.b2,
    s->flash_data[page_start + 256],
    s->flash_data[page_start + 256],
    s->flash_data[page_start + 256]

);
printf(
    "Other checksum2: %02X %02X %02X\n"
    "Other Checksum2 actual DATA %02X %02X %02X %02X\n",
    yesANOTHERANOTHERchecksum3.b0,
    yesANOTHERANOTHERchecksum3.b1,
    yesANOTHERANOTHERchecksum3.b2,
    yesANOTHERANOTHERchecksuminput3[0],
    yesANOTHERANOTHERchecksuminput3[1],
    yesANOTHERANOTHERchecksuminput3[2],
    yesANOTHERANOTHERchecksuminput3[3]
);
printf("Calculated Final checksum: %02X %02X %02X\n", finalechecksumcalc.b0, finalechecksumcalc.b1, finalechecksumcalc.b2);

printf("Start off ECC: %02X %02X %02X\n", fixed_oob[0], fixed_oob[1], fixed_oob[2]);

printf("Fixed ECC: %02X %02X %02X\n", fixed_oob[36], fixed_oob[37], fixed_oob[38]);

//I cant EXPLAIN what were doing. These are just the spots in the spare that contain 3 byte checksums that need fixing. WHY there at WHERE is not my place. Ask Sony why. Yes if ANY of these are a SINGLE digit off the bootloader will REFUSE to boot.
//So yes "Is it really needed" YES IT IS.
//copy stored checksum into the block
fixed_oob[36] = stored_struct.b0;
fixed_oob[37] = stored_struct.b1;
fixed_oob[38] = stored_struct.b2;
//copy page checksum to the block.(still in the ECC spare area)
fixed_oob[12] = stored_page_struct.b0;
fixed_oob[13] = stored_page_struct.b1;
fixed_oob[14] = stored_page_struct.b2;


fixed_oob[15] = yesANOTHERANOTHERchecksum3.b0;
fixed_oob[16] = yesANOTHERANOTHERchecksum3.b1;
fixed_oob[17] = yesANOTHERANOTHERchecksum3.b2;

fixed_oob[33] = yesANOTHERANOTHERchecksum2.b0;
fixed_oob[34] = yesANOTHERANOTHERchecksum2.b1;
fixed_oob[35] = yesANOTHERANOTHERchecksum2.b2;

fixed_oob[18] = stored_1000bytes_inchecksum.b0;
fixed_oob[19] = stored_1000bytes_inchecksum.b1;
fixed_oob[20] = stored_1000bytes_inchecksum.b2;

fixed_oob[21] = finalechecksumcalc.b0;
fixed_oob[22] = finalechecksumcalc.b1;
fixed_oob[23] = finalechecksumcalc.b2;

fixed_oob[27] = finaleFINALchecksumcalc.b0;
fixed_oob[28] = finaleFINALchecksumcalc.b1;
fixed_oob[29] = finaleFINALchecksumcalc.b2;

fixed_oob[30] = finaleFINALFINALchecksumcalc.b0;
fixed_oob[31] = finaleFINALFINALchecksumcalc.b1;
fixed_oob[32] = finaleFINALFINALchecksumcalc.b2;

fixed_oob[24] = definitionofinsanitycalc.b0;
fixed_oob[25] = definitionofinsanitycalc.b1;
fixed_oob[26] = definitionofinsanitycalc.b2;

fixed_oob[40] = yesANOTHERchecksum2.b0;
fixed_oob[41] = yesANOTHERchecksum2.b1;
fixed_oob[42] = yesANOTHERchecksum2.b2;

//Now also write to the PHSYICALL buffer so if it gets called via a method that is NOT just reading the spare area it will still show the correct changes.
//Btw ECC just means checksum. These people name stuff with a bunch of absurd names.
//yes this is the ONLY way qemu is going to have proper nand support for this device.
s->flash_data[page_start + 2048 + 36] = fixed_oob[36];
s->flash_data[page_start + 2048 + 37] = fixed_oob[37];
s->flash_data[page_start + 2048 + 38] = fixed_oob[38];

s->flash_data[page_start + 2048 + 12] = fixed_oob[12];
s->flash_data[page_start + 2048 + 13] = fixed_oob[13];
s->flash_data[page_start + 2048 + 14] = fixed_oob[14];

s->flash_data[page_start + 2048 + 15] = fixed_oob[15];
s->flash_data[page_start + 2048 + 16] = fixed_oob[16];
s->flash_data[page_start + 2048 + 17] = fixed_oob[17];


s->flash_data[page_start + 2048 + 33] = fixed_oob[33];
s->flash_data[page_start + 2048 + 34] = fixed_oob[34];
s->flash_data[page_start + 2048 + 35] = fixed_oob[35];

s->flash_data[page_start + 2048 + 18] = fixed_oob[18];
s->flash_data[page_start + 2048 + 19] = fixed_oob[19];
s->flash_data[page_start + 2048 + 20] = fixed_oob[20];

s->flash_data[page_start + 2048 + 21] = fixed_oob[21];
s->flash_data[page_start + 2048 + 22] = fixed_oob[22];
s->flash_data[page_start + 2048 + 23] = fixed_oob[23];

s->flash_data[page_start + 2048 + 27] = fixed_oob[27];
s->flash_data[page_start + 2048 + 28] = fixed_oob[28];
s->flash_data[page_start + 2048 + 29] = fixed_oob[29];

s->flash_data[page_start + 2048 + 24] = fixed_oob[24];
s->flash_data[page_start + 2048 + 25] = fixed_oob[25];
s->flash_data[page_start + 2048 + 26] = fixed_oob[26];

s->flash_data[page_start + 2048 + 30] = fixed_oob[30];
s->flash_data[page_start + 2048 + 31] = fixed_oob[31];
s->flash_data[page_start + 2048 + 32] = fixed_oob[32];


s->flash_data[page_start + 2048 + 40] = fixed_oob[40];
s->flash_data[page_start + 2048 + 41] = fixed_oob[41];
s->flash_data[page_start + 2048 + 42] = fixed_oob[42];
//IF THE SYSTEM does a FULL page read instead of just a OOB FIRST it will get the OLD checksum... so like if a full page read is done FIRST before a OOB read and it uses that full page read to read the OOB it will show the old page data.

        // Transfer fixed OOB data (64 bytes) to dest
        cpu_physical_memory_write(phys_dest, fixed_oob, 64);
        //kseg
        cpu_physical_memory_write(0x80a00000+phys_dest, fixed_oob, 64);
}
ProudSkibidiTolietAryan said:
I was wrong. VERY wrong. as it turns out that was NOT the case. I just made it crash EARLIER instead of further from before.
Fixing it just leads to the EXACT same error that ive been debugging and trying to get past for a month.
1769994329919.png
Click to expand...
Remember this error? Its now gotten far enough to where its MATURED.
1771428648714.png
The Other error has progressed meaning that its gotten further.
1771428678144.png

Ok so self loathing aside what is failing now. Well.. Its complicated.

The bootloader tries to set the base to something ABSURD
1771428759691.png
Which even after UPDATING the QEMU code I made I cant handle values that are literally IMPOSSIBLE.
It then tries to read OUTSIDE the NAND in invalid address space. And no im pretty sure this is INTENTIONAL by the bootloader
1771428816248.png
and then compares the checksums of values of a page that does not exist. Because it does not exist its just going to be reading the values from the last page it read thats loaded in RAM and still pass because those values are valid.

Now I do have a theory for WHY its doing this. Its checking if the NAND controller is working properly. Its reading a INVALID place in NAND that should on real hardware not return anything. Because it does not return anything and does not overwrite the last DMA read to RAM it should contain the OLD values, and since the OLD page has valid checksum data it will pass. If the NAND controller is broken and returns valid nand data then it would be at a part of nand that would be BE either random or BAD. And as such it would fail the checksum it does AFTER this and fail. Basically its checking if the NAND hardware logic is working correctly.

After that though.... Well...

Yeah you can guess failure. But I know the EXACT line that causes it.
1771429107834.png
Its THIS line right here.
1771429125088.png

Basically the register T1 is NON cleared for some reason. I have to figure out WHY now. Im assuming its because my implementation is to perfect and there is something that is acutally SUPPOSE to fail normally.. But that is just guesswork, and you can make a MILLION valid reasons and theorys for why something does not work in this stage.
 
ProudSkibidiTolietAryan said:
Basically the register T1 is NON cleared for some reason. I have to figure out WHY now. Im assuming its because my implementation is to perfect and there is something that is acutally SUPPOSE to fail normally.. But that is just guesswork, and you can make a MILLION valid reasons and theorys for why something does not work in this stage
Click to expand...
Is it possible that calling invalid memory triggers an error flag, and it's checking to ensure the error flag is there and clear it?
 
You must log in or register to reply here.
Back
Top Bottom