[solved] Linux: maximum bootable kernel size in PPC/32bit - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 12:27:20 am
content: This seems like a pretty straightforward question, but extensive experiments from kernel 4.11 to kernel 5.7.19 haven't shown a really clear, up-to-date answer.k4.11 .. k5.7.19: when the kernel size is bigger than 8 MB, the final kernel doesn't boot but rather it freezes.Why?I'm having one hell of a time compiling monolithic kernels and keeping then under 8M without leaving out some core networking and file-system features I need; for several reasons I cannot use modules.Anyway, it's not clear to me why a 32 bit processor would not be able to boot a kernel larger than 8 MB

author: PKTKS
author_rank: Super Contributor
timestamp: September 18, 2021, 11:41:22 am
content: Quote from: DiTBho on September 18, 2021, 12:27:20 amThis is far from a correct postulation.I can boot a raw 486 or 586 legacy board with 32 MEGA FPM/EDO memory.You need as well to post a whole lot more details about what you have done on kernel to have issues. Generally a minimal kernel excludes everything besides bare bones memory manager and basic kernel threads.Everything else goes via INITRD and RAMDISK_SIZE like:Code:append="initrd=isoroot.gz ramdisk_size=xxxxxxx root=/dev/ram0"Of course the base bare bones devices are also required in your isoroot image.and grub is a PIG with such options..The whole modern thing (udev/systemd/grub) will likely NOT WORK in minimal setupsa lot of tinkering and squashfs is usually done unlike bare isorootfsThis is not trivial and can not be based on these stock "modern" shit kernels.Paul

author: thinkfat
author_rank: Unknown
timestamp: September 18, 2021, 12:23:55 pm
content: This is typically a problem of relocations not being resolved properly during linking the kernel. Relative jumps end up in nirvana instead of the right target address. Watch out for linker warnings during the final stage of the kernel build

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 01:31:46 pm
content: Quote from: PKTKS on September 18, 2021, 11:41:22 amThere is no initrd or similars, the kernel mounts an hard-drive.If the kernel size is > 8MB, it doesn't boot, it doesn't show anything, it simply freezes without any clue.If the kernel size is <= 8Mbyte, it boots correctly.

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 01:35:02 pm
content: Quote from: thinkfat on September 18, 2021, 12:23:55 pmYup, this was/is a problem with ARM-classic, and it's also a problem with HPPA2 due to relative jumps. But this is something it shouldn't happen with PowerPC.Anyway, there is also a second problem: the boot-wrapper (bZimage) cannot copy the kernel to - say 0x00010000 - it must copy the kernel to 0x00000000, otherwise it won't boot.This way I cannot easily attach a serial debugger, unfortunately I don't have a jtag debugger and KGDB simply dies

author: PKTKS
author_rank: Super Contributor
timestamp: September 18, 2021, 01:41:22 pm
content: Quote from: DiTBho on September 18, 2021, 01:31:46 pmHard to make sense..You strip something from the core and it boots...So you have some shit modules being trashing the whole chain..Stripping more and more eventually will lead you to INITRD.If you can boot the minimal one why are you bothering with the larger?usually it is the other way around..we bother to increase the minimal build with as much as possible..not the other way aroundPaul

author: thinkfat
author_rank: Unknown
timestamp: September 18, 2021, 01:47:59 pm
content: I've seen relocations fail also on Arm v8, when the rootfs was linked into the kernel. But then the kernel completely failed to link.

author: Monkeh
author_rank: Super Contributor
timestamp: September 18, 2021, 02:01:29 pm
content: Quote from: DiTBho on September 18, 2021, 01:31:46 pmI'd be focusing on the bootloader. And ignoring PKTKS who can't even tell you're not dealing with an x86.An interesting experiment might be padding a bootable image to >8M.

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 02:48:40 pm
content: Quote from: PKTKS on September 18, 2021, 01:41:22 pmBecause I need several features built-in and I cannot compile them as modules.

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 03:18:33 pm
content: Quote from: Monkeh on September 18, 2021, 02:01:29 pmu-Boot-2017The booting flow is something like:u-Boot-> tftpload uImage (uncompressed)-> park the uImage at0x0010.00000x0001.0000-> bootm, unroll into binary image at 0x0080.0000 (this exposes the boot-wrapper and the elf header)-> check the elf header-> jump into the boot-wrapperKernel-> copy the kernel to 0x0000.0000 (8MByte copied from 0x0010.0000+x to 0x0000.0000)-> prepare and finalize the DTS image (flat device tree)-> copy DTS to somewhere in RAM in the kernel area-> invoke kentry(addr(dts), 0, NULL), which jumps into %entry-> boot or dieu-Boot -> unroll -> boot-wrapper -> kernel bootI added a very wild debug module, which directly uses the serial0, it's not yet initialized by the kernel, it's re-initialized in polling-mode to avoid interrupts.Code:image loaded from 0x00800000SP=0x03eb1b80kernel_size = 7411084 bytescopying 256 bytes from kernel-image at 0x0080f000 to elfheaderelf_info.loadsize = 0x00700e68elf_info.memsize = 0x0074234callocating 7611212 bytes for the new kernelcopying ...from = 0x0081f000to = 0x00000000size = 7343720flush_cache, 32Mbyte flushedcmdline: uboot bootargs overriddencmdline=[console=ttyS0,115200 root=/dev/sda2 rootfstype=ext2 rw init=/sbin/init ]Finalizing device tree... flat tree at 0xf23b80ft_addr=0xf23b80my tp1: successmy tp2: successmy tp3: successinvalidate_cache 0x00000000+0x02000000my tp4: (point of no return)calling kentry()...kernelinfo version 5.2.1kernelinfo compiled by DiTBho@minervakernelinfo compiled with gcc version 9.3.0kernelinfo build ticket #66 PREEMPT Sat Sep 18 2021maybe there is something wrong with "load_addr"when load_addr="0x00800000" the kernel bootswhen load_addr="0x00900000" the kernel doesn't boot

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 03:29:09 pm
content: Quote from: thinkfat on September 18, 2021, 01:47:59 pmThree years ago I saw it with HPPA2 kernels. Since the code density is not good, those kernels are usually 12 Mbytes in size and some of their branch instructions fail at run-time. At some point it got somehow fixed but there were no connection errors or warnings.I remember something similar with intel PXA and ARM classic, never seen before with PowerPC

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 03:43:54 pm
content: This is a 7.4 MB kernel in size, compiled withCode:load_addr="0x00900000"exec_addr="0x901b00"Code:#lsprettysize output/kernel.uImage7. 4 Mbyte output/kernel.uImageCode:image loaded from 0x00900000SP=0x03eb1b80kernel_size = 7411084copying 256 bytes from kernel-image at 0x0090f000 to elfheaderelf_info.loadsize = 0x00700e68elf_info.memsize = 0x0074234callocating 7611212 bytes for the new kernelcopying ...from = 0x0091f000to = 0x00000000size = 7343720flush_cache, 32Mbyte flushedcmdline: uboot bootargs overriddencmdline=[console=ttyS0,115200 root=/dev/sda2 rootfstype=ext2 rw init=/sbin/init ]Finalizing device tree... flat tree at 0x1023b80ft_addr=0x1023b80my tp2: successmy tp3: successinvalidate_cache 0x00000000+0x02000000my tp4: (point of no return)calling kentry()...it dies at this point, but without a debugger it's like watching something fall into a black holeEither way, it smells like something related to "load_addr"

author: Monkeh
author_rank: Super Contributor
timestamp: September 18, 2021, 03:53:08 pm
content: Quote from: DiTBho on September 18, 2021, 03:18:33 pm1M.Quote8M.Have you considered following sense and documentation and not placing your image where it will get overwritten?A little light googling also suggests there may well be an 8M limit on kernel size depending on your u-boot and kernel configurations, but I'm not feeling like diving too deep into an embedded platform I don't need.

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 04:04:32 pm
content: Quote from: Monkeh on September 18, 2021, 03:53:08 pmThere is no documentation, the board worked with the current setup until my colleague needed to update the kernel and to add more features, and for a lot of reasons we cannot use the memory above 0x00x0.0000 without modifying u-boot (again).I am working just right now to a patch to use the memory at 0x0100.0000, which is currently reserved for an on-board FPGA that shares the ram with the SoC, and to an hardware patch to install up to 256-512MB of ram dedicated to the SoC.

author: Monkeh
author_rank: Super Contributor
timestamp: September 18, 2021, 04:06:27 pm
content: Quote from: DiTBho on September 18, 2021, 04:04:32 pmu-boot comes with plenty, including a nice note about not overwriting your tftp loaded image.QuoteAh, the joys of trying to support ultra-legacy hardware hacks.

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 04:08:19 pm
content: Quote from: Monkeh on September 18, 2021, 03:53:08 pmWhere? What?

author: Monkeh
author_rank: Super Contributor
timestamp: September 18, 2021, 04:12:01 pm
content: Quote from: DiTBho on September 18, 2021, 04:08:19 pmBits and pieces like this:https://lists.denx.de/pipermail/u-boot/2016-July/261087.htmlAgain, don't feel like diving - no idea what platform, exact u-boot version you have, configuration, non-upstream hacks, yadda yadda, nigh impossible to do more than point vaguely and hope you find the right direction..Oh, and stuff like this:https://lists.denx.de/pipermail/u-boot/2016-July/261088.html...

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 04:35:33 pm
content: Quote from: Monkeh on September 18, 2021, 03:53:08 pmdouble checked, in my post I typed 0x0010.0000 but it is 0x0001.0000

author: Monkeh
author_rank: Super Contributor
timestamp: September 18, 2021, 04:42:01 pm
content: Quote from: DiTBho on September 18, 2021, 04:35:33 pmOkay, and if you're writing to 0x800000 later you're clobbering any image bigger than 0x7F0000.

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 06:59:32 pm
content: Quote from: Monkeh on September 18, 2021, 04:42:01 pmNot a problem, the last 64Kbytes are empty in every tested kernel and, just to be sure it's not the problem, the tested kernel was compiled with "space optimization" with a size of7.5 MBHowever, although the size is 7.5MB, even this kernel doesn't boot when load_addr="0x0090.0000", no matter where you tftpload it in ram, in fact, I have just modified u-boot to disable the FPGA so I reassigned its ram up to 0x0400.0000, and tftploading at 0x0100.0000 and 0x0200.0000 doesn't solve anything.this doesn't work:tftpload uImage (not compressed) -> 0x0200.0000bootm from 0x0200.0000, copies the wrapper (7.5MB) into 0x0090.0000 (load_addr)the wrapper copies the kernel into 0x0000.0000 and invokes kentrythe kernel dies immediately without showing anythingthis does work:tftpload uImage (not compressed) -> 0x0200.0000bootm from 0x0200.0000, copies the wrapper (7.5MB) into 0x0080.0000 (load_addr)the wrapper copies the kernel into 0x0000.0000 and invokes kentrythe kernel bootsHere the problem is somehow related toload_addrI also tried load_addr ={0x0081.0000 8M + 64K -> it works0x0082.0000 8M + 128K -> it works0x0084.0000 8M + 256K -> it works0x0088.0000 8M + 512K -> it works0x0090.0000 8M + 1M -> it doesn't works}

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 07:03:03 pm
content: This is the relation between thekernel sizeandlink_addrCode:# Round the size to next higher MB limitround_size=$(((strip_size + 0xfffff) & 0xfff00000))round_size=0x$(printf "%x" $round_size)link_addr=$(printf "%d" $link_address)and this is wherelink_addris involvedCode:text_start="-Ttext $link_address"

author: thinkfat
author_rank: Unknown
timestamp: September 18, 2021, 07:09:53 pm
content: Well, this is the point where you will need to spike the startup code with uart output, to see where it runs into the woods.

author: DiTBho
author_rank: Super Contributor
timestamp: September 18, 2021, 07:42:39 pm
content: Quote from: thinkfat on September 18, 2021, 07:09:53 pmAlready done, see a few posts aboveUnfortunately I am lost after kentry(), which is the point of no return in the booting code because it points and jumps into 0x0000.0000, which is the interrupt vector area in PowerPC, and I cannot add a serial debugger there (kind of gdb-stub) because the kernel is already died at that point; I would need a jtag debugger to see and track something down to the code.As temporary workaround I am forcing the load address to 0x0088.0000, so I can boot a 8. 4 Mbyte kernel, which is a good "compromise".Why is life so complex?

author: PKTKS
author_rank: Super Contributor
timestamp: September 19, 2021, 08:19:20 am
content: Quote from: Monkeh on September 18, 2021, 02:01:29 pmI always miss your pedantic insultsThey make my daysPaul

author: DiTBho
author_rank: Super Contributor
timestamp: September 21, 2021, 11:31:27 am
content: Yesterday I completed the hardware hack so I can remap the memory registers of the FPGA to 0x4000.0000 (1G), but still the SoC cannot use the ram from 0x0000.0000 to 0x1000.0000 (256MB), but only from 0x0000.0000 to 0x0800.0000 (128 MB).Not perfect, but better, and now I can park a tftpimage at 0x0800.0000Older kernels (2.4.* and 2.6.15) were simpler and smaller than current 5.*u-boot dropped support for PPC 4xx in 2017.Linux dropped support for PPC 4xx with the 5.8.0 kernel.

author: brucehoult
author_rank: Super Contributor
timestamp: September 21, 2021, 11:38:22 am
content: Quote from: DiTBho on September 21, 2021, 10:25:59 amOh! This seems to be the first mention you're using a PPC 4xx! Which one? Do you have an MMU? An FPU?It seems Debian and Ubuntu had their last releases for 32 bit PPC Macs in 2015 (Debian 8, Ubuntu 14.04)Hmm ..https://www.kernel.org/doc/html/latest/powerpc/cpu_families.htmlsays 4xx is "BookE" and has a software reloaded TLB (fine .. so do some RISC-V) and are supported ... still?I really haven't followed the PPC situation for more than 15 years since Apple switched. Used to love the things, especially from 604e and on. Wish I hadn't sold my dual 2.0 G5.

author: DiTBho
author_rank: Super Contributor
timestamp: September 21, 2021, 12:34:08 pm
content: Quote from: brucehoult on September 21, 2021, 11:38:22 amtwo boards, 405 and 440. At the moment I am working with the 405 one.Quote from: brucehoult on September 21, 2021, 11:38:22 amTLB: yesFPU: no, full kernel FPU emulationThe FPGA is memory mapped and offers fixedpoint in hw, but it's a raw hack at the momentQuote from: brucehoult on September 21, 2021, 11:38:22 amI have my custom builder, I can build 2021 stage4, even for PowerMac-G4 (PPC7450).Gcc has special flags for 40x, but basically the PPC4xx-stage is profiled like a PPC750-softfloat stage.Quote from: brucehoult on September 21, 2021, 11:38:22 amyes, I forced u-boot to start the kernel with- cache completely invalidated and flushed- TLB disabled, so the kernel-image can be copied to 0x0000.0000- PCI pre-programmed with all the devices forced into PCI native mode- serial0 programmed in polling mode so it can output useful informationQuote from: brucehoult on September 21, 2021, 11:38:22 amG5 is profiled as PPC64-BE. Its code is different; nowadays PPC64 is well supported for IBM POWER9 and POWER10.PPC32 has several "platforms" of reference. in my case it's not "Apple" but rather AMCC and Xilinx, but unfortunately they dropped the support years ago.The problem I have seems related to the Device Tree. There was no DTB in kernel 2.4 when we purchased the boards, DTS was introduced years later (>= k2.6.26), and it has always been a plague.The 2.6.26 kernel was also the first "hybrid" kernel with both the "arch/ppc" and "arch/powerpc" branches merging into the latest "arch/powerpc". And that has always meant problems, loss of files and features (e.g. all the GPIO support for 4xx stopped to work, and got removed), loss of support and regression.kernel-4.11.0: <7MB, bootskernel-4.14.246: <7MB, boots, of_irq_parse_pci failskernel-4.14.99: <7MB, boots, of_irq_parse_pci failskernel-4.4.199: <7MB, boots, of_irq_parse_pci failskernel-5.2.1: >8MB doesn't bootkernel-5.2.1: <8MB with linkaddr=0x0090.000 doesn't bootkernel-5.2.1: <8MB with linkaddr=0x0080.000 boots, of_irq_parse_pci failskernel-5.2.1: <8MB boots, of_irq_parse_pci failskernel-5.5.1: <8MB boots, of_irq_parse_pci failskernel-5.7.19: <8MB boots, of_irq_parse_pci failskernel-5.8.0: <8MB doesn't boot (4xx support dropped)(edit: all tests performed with tftpload 0x0400.0000 (64MB))I can boot modern v5 kernels (<= k5.8.0), but there is a serious problem with the maximum bootable kernel size due to a "bug" somewhere with the boot-wrapper, and it somehow looks to be related to the DTB stuff.

author: DiTBho
author_rank: Super Contributor
timestamp: September 21, 2021, 09:26:50 pm
content: Today I improved the early-console_out functions and I instrumented more code but still the kernel dies before the first message from the kernel shows up.That's a very nasty situation to debug, and it's where things like "git bisect" are really useful just to narrow things down, which isn't an option here because *every* tested kernel after 2.6.26 (so *every* DTB-kernel) dies the same way when linkaddr=0x0090.0000.There is nothing I can "git bisect". Too bad.Kernel 2.6.15 can boot with linkaddr=0x0090.0000, but kernel 2.6.15 is not a DTB-kernel, and it's also "arch/ppc", so its code is completely different regarding PCI, how to initialize things and, etc.It sounds something went bad back in 2005-2007 when "arch/ppc" was merged into "arch/powerpc", and no one ever noticed before (or no one ever cared)

author: nctnico
author_rank: Super Contributor
timestamp: September 27, 2021, 12:50:40 am
content: Late to the party... Can you hack u-boot to add a (simple) memory verification command (if that isn't already there). I'd verify whether the memory you are trying to use actually works. From your test results I start to doubt that. Alternatively it is possible that the kernel overwrites itself and may need more space allocated for itself.

author: DiTBho
author_rank: Super Contributor
timestamp: September 27, 2021, 09:29:11 am
content: Quote from: nctnico on September 27, 2021, 12:50:40 amAlready doneu-boot reserves the first and the last 1MB for its internal structures, but all the tested ram from (0+1)MB to (256-1)MB is fine.

author: DiTBho
author_rank: Super Contributor
timestamp: September 27, 2021, 09:42:11 am
content: Quote from: nctnico on September 27, 2021, 12:50:40 amYes, it is possible, just as it is possible that during the boot sequence, just before jumping into kexec(), something goes wrong and the code that has to manage the flat device tree only sees 16 Mbytes at boot, which is enough with linkaddr = 0x0080.0000, but not enough with 0x0090.0000, and in this case that code for some weird reason can't map more ram(1).That weird reason seems specific to ppc40x, a PPC750 doesn't exhibit this problem, but ... it's my speculation, and the code (assembly) is different.It's funny, because if the code passes the point of no return kexec (), then it correctly sees 256MB of ram.I mean, with linkaddr = 0x0080.0000 and a 7.5MB sized kernel, it works fine and "/proc/mem" correctly reports (256-8) MB available to the user(1) it should arise some machine_exception at this point, but ... I cannot easily track it down because I don't have a jtag debugger. I need to hack the exception tables in order to put there something like a call to my "early_puts" so I can see something on the serial monitor, otherwise the machine simply silently dies without any clue.

author: DiTBho
author_rank: Super Contributor
timestamp: September 27, 2021, 04:00:40 pm
content: SolvedI asked to a PPC40x expert and we found an error in the TLB pre-initialization.Rather PPC40x-specific.

author: Monkeh
author_rank: Super Contributor
timestamp: September 27, 2021, 04:14:21 pm
content: It wasn't something to do with systemd? The mind boggles.

author: DiTBho
author_rank: Super Contributor
timestamp: September 27, 2021, 06:35:51 pm
content: Quote from: Monkeh on September 27, 2021, 04:14:21 pmLOL

author: brucehoult
author_rank: Super Contributor
timestamp: September 28, 2021, 12:13:27 am
content: Quote from: DiTBho on September 27, 2021, 04:00:40 pmCan you explain it exactly?In RISC-V land we used to get a fairly steady stream of people whose toy OS works fine on QEMU but fails on real hardware when they try to switch from Machine mode to Supervisor (or User) mode because QEMU was more lenient about PMP  initialization (if you didn't initialize PMP then it assumed you don't have one). A few months ago QEMU changed so that just like on most real hardware there is a PMP and you must initialize it. So now people's things that used to work on QEMU suddenly don't. But it's a whole lot easier to debug it there than have real hardware that silently dies. Physical Memory Protection. A hardware unit that provides RWX protection for typically 16 memory ranges without address translation. Even small microcontrollers usually have it if they provide User mode. At reset Machine mode can access everything and Supervisor and User mode can access nothing. On Linux (etc) machines it lets Machine mode lock even the Linux kernel(s) out of certain memory ranges. It works on physical addresses, not virtual addresses like the TLB (if you have one).

author: DiTBho
author_rank: Super Contributor
timestamp: September 28, 2021, 01:32:07 am
content: Quote from: brucehoult on September 28, 2021, 12:13:27 amu-boot operates without virtual memory. The same does the first part of the kernel loader (where I attached my early_puts for debugging). From here it goes quite specific, basically the assembly code for the TLB initialization was not correct and when the pre-booter tried to move into virtual memory it completely lost all references to everything outside its window.

author: brucehoult
author_rank: Super Contributor
timestamp: September 28, 2021, 01:40:42 am
content: Quote from: DiTBho on September 28, 2021, 01:32:07 amYes I understand that.Ijust explainedhow people often have similar problems switching from using physical memory to virtual memory on RISC-V.I'm asking what, exactly, was wrong with the TLB initialisation that works on PPC750 but not 40x. The actual instructions.

author: thinkfat
author_rank: Unknown
timestamp: September 28, 2021, 07:24:39 am
content: Quote from: DiTBho on September 27, 2021, 04:00:40 pmThat would've been hard to debug even with a JTAG probe.BTW, you wouldn't necessarily have to buy an expensive probe. OpenOCD has at least some support for PPC and should allow using a simple FTDI based probe.

author: DiTBho
author_rank: Super Contributor
timestamp: September 28, 2021, 11:37:31 am
content: I am not a PowerPC expert. I worked years ago for a company that had a few PPC based products (440, 460, 8xx and e500) and I happen to have a couple of PPC40x based hobby projects, and I also like to run Linux on my mac-mini/PPCQuote from: brucehoult on September 28, 2021, 01:40:42 amNot a single instruction, but a sequence of instructions.On Linux, the critical code is segregated within a specific CPU modulePPC32PPC64PPC40xPPC44xPPC8xx...each item in the list has a dedicated assembly module with low-level exception handlers, MMU support, trap, FPU-trap (if there is no physical FPU) and interrupt dispatch.I haven't gone into the details, but PPC32 has different procedures with more support and interest. It needs to loads the BAT registers with the values set by MMU init, which for example takes care of whether we are on a 601 or not. These facilities have been exhaustively implemented with a rich set of checks, while the 40x code is poor, probably because it has less interest.PPC32 is mainly "PMAC" (PowerMac), which assumes OF+bootX, while PPC405 assumes u-boot. There are differences even here, e.g. with the CPU already has the MMU on, and there is specific code to turn it off before changing BATs (MMU's registers).PPC32 has the 1st slot of ram mapped with the bats and can map more slot on demand. Indeed when I tried to compile a 9MB kernel for my mac-mini/ppc, it correctly mapped 32MB to facilitate the kernel pre-booting. There is a procedure (in assembly) to check and manage things transparently. The PPC40x code does something similar but the procedure is different and it is simpler and less "error prone". It goes back to running unmapped so it can load up new values and change to using exception vectors. This way, all the CPU has to do is invalidate the TLB to clear the old set-TLB mappings, and to map an additional slot it requires to configure, reserve and load two entries into TLB slots. But it's not "on demand", but rather hard-coded in order to map the first 32 MBytes of memory 1:1, virtual to physical and more importantly it's how to set the cache mode.The bug was that on the hard-coded part, it reserved only one slot instead of two, so it only mapped 16MB instead of 32MB and there was no checking for that.