@Geri

This looks exactly like the picture posted with the UBoot crash. Same result. Crash in the first entry. Out of interest I wonder what the assembly language looks for that spot?

In the meantime I have a side project for a mini boot CD that runs diagnostic routines to check basic hardware for stability like memory. Once I get that working I'll link it here and consider the possibility of including it in the installer as a menu item. This would help with problems dammed is currently facing.

@Geri

Quote:

but for some reason can't find the root partition. Is the root partition really labeled as "squeeze"?

Just a note - I haven't gotten labels to work with any versions of Debian since Etch. Only UUID or /dev/hdx names work in my a1boot.conf file. Never did figure out why that was.

Scott

_________________
AmigaOne uA1-c 512M RAM - Only Amiga Makes It Possible!
Check my blog AmigaOne Computing

@scabit

I set some up and they work for me. Sorry that comment was annoying.

For example:
ROOT=LABEL=Debian
ROOT=LABEL=Ubuntu

How are yours? This is off my head. Better check that later.

@damned

Okay here's a first version of my BootCD tester. For some reaosn it can't allocate all memory it needs. But see if anything shows up. I suspect it won't for the short amount but you never know.

http://home.lizzy.com.au/dmaen/downloads/Testing/BootTest.iso

@Geri

nope..corrected the root partition entry but it stucks after 2 minutes..i will capture the serial output

_________________
--------------------------------------
Search and Destroy
---------------------------------------

@Hypex
ouch!
the new iso tell me that 'unknows sense key 03 asc 02 ascq 00'
i think my cdrom is going to die...

_________________
--------------------------------------
Search and Destroy
---------------------------------------

@damned

Could be but I got this the other day with a bad CDRW. Try another disc. BTW recommend a CDRW for reuse.

@Hypex

changed the cdrom and now works...memory test seems ok....

_________________
--------------------------------------
Search and Destroy
---------------------------------------

@damned

Quote:

damned wrote: @Geri nope..corrected the root partition entry but it stucks after 2 minutes..i will capture the serial output

Strange! I uploaded an updated kernel image with a suitable boot image here. Please install the kernel update and afterwards give the boot image a try, which should come with all necessary drivers to boot the system.

Thanks!

@all
BTW: you can subscribe to update notifications on the amigaone-linux project site, if you want to get notified on new file releases.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Geri

Still no luck...infinite blinking cursor after
74.948612 eth1: no ipv6 routers present

_________________
--------------------------------------
Search and Destroy
---------------------------------------

@Geri

Well after a test of the MemTester BootCD we know the first 14MB is okay. Or where ever it allocates 14MB from.

I need to put in a bit more work to find how much memory is in the machine. UBoot SDK would be nice, The API I see gives no visible info and I think I will need to use a fixed address. Being able to use cache would be nice.

Last edited by Hypex on 13-Jun-2013 at 09:09 AM.

@damned

Quote:

damned wrote: @Geri Still no luck...infinite blinking cursor after 74.948612 eth1: no ipv6 routers present

Can you please add initcall_debug to the boot parameters (if this isn't the case yet). That should give us a little bit more information about where it hangs.

Sorry, if I may have already asked this, but I lost overview. Do you have two SDRAM modules in your machine? If so you could try to limit the memory to the size of one module or even remove one module. Linux showed some strange behavior on my A1SE, when I tried to boot it with two different (manufacturer and size) SDRAM modules.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Hypex

Quote:

Hypex wrote: @damned Okay here's a first version of my BootCD tester. For some reaosn it can't allocate all memory it needs. But see if anything shows up. I suspect it won't for the short amount but you never know. http://home.lizzy.com.au/dmaen/downloads/Testing/BootTest.iso

Oh, is this memtester directly running as a standalone U-Boot application?

Quote:

Hypex wrote: @Geri Well after a test of the MemTester BootCD we know the first 14MB is okay. Or where ever it allocates 14MB from.

Good question. I guess U-Boot relocates itself to the top or RAM. But then I wonder why you only get 14MB!?

Quote:

I need to put in a bit more work to find how much memory is in the machine. UBoot SDK would be nice, The API I see gives no visible info and I think I will need to use a fixed address.

Are you reading out the board info structure (bd_t) to detemine the amount of memory?

Quote:

Being to use cache would be nice.

To hold the whole memtester code?

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Geri

Quote:

Oh, is this memtester directly running as a standalone U-Boot application?

Almost but not quite, it's running as a boot block. Or as a SLB. It uses the UBoot context passed to it.

I'd like to turn it into a UBoot program. That way it could be copied to a boot volume and ran from a SLB Linux menu.

Quote:

But then I wonder why you only get 14MB!?

That's what I wonder. Could be an inbuilt limit. Possibly that's all the RAM UBoot can use for a kernel before crashing.

Quote:

Are you reading out the board info structure (bd_t) to detemine the amount of memory?

That's what I intended to do but the public source files I here have no info on it and declare it as a (void *). Honestly, how do they expect you to find out simple info like installed RAM by hiding the structure?

Quote:

To hold the whole memtester code?

Sounds good yes, but to speed up the code really. I know that's inaccurate but testing 2GB of RAM is slow as!

@Hypex

Quote:

Hypex wrote: @Geri Almost but not quite, it's running as a boot block. Or as a SLB. It uses the UBoot context passed to it.

Good idea!

Quote:

I'd like to turn it into a UBoot program. That way it could be copied to a boot volume and ran from a SLB Linux menu.

Shouldn't be that hard and as far as I understand it also the Linux kernel should be U-Boot standalone application.

Quote:

That's what I wonder. Could be an inbuilt limit. Possibly that's all the RAM UBoot can use for a kernel before crashing.

Yes, it could be an internal limit. Maybe U-Boot sets up a memory mapping for the first 16MB, which would also explain, why we can't boot bigger kernel images.

Quote:

That's what I intended to do but the public source files I here have no info on it and declare it as a (void *). Honestly, how do they expect you to find out simple info like installed RAM by hiding the structure?

Well, I guess you could do it like the Linux kernel. U-Boot just hands over a pointer to the kernel's entry function, which should point to the bd_t structure.

Quote:

Sounds good yes, but to speed up the code really. I know that's inaccurate but testing 2GB of RAM is slow as!

At least the instruction cache should already be enabled within U-Boot. The data cache is another topic. First the 1.1.x versions of U-Boot (or to be more specific, I think it is the x86 emulator for the video BIOS) don't like it, if the data cache is active. Secondly I reproducibly got different memtester results for an activated or deactivated data cache. With an activated data cache memtester reported memory errors, whereas everything was fine, when the cache was disabled.

But running memtester as an U-Boot application could help in debugging a specific problem with two memory modules, for which I reproducibly get errors reported for 8 or 16 bytes of memory address range on my machines. I suppose that this address could actually be always the same physical address, but the virtual memory mapping of the Linux kernel naturally maps physical memory randomly into the virtual address space. If the standalone memtester version could setup a fixed memory mapping (maybe with BATs) for the whole RAM address space (2GB), then I could verify, if the errors are really reported for the same physical address.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Geri

i had two 1Gb sdram: os4 worked perfectly but linux refuse to boot if i don't limited the amount at 1024 in uboot, so from some years i have only one dimm installed.
i think "initcall_debug" is already present but i will check (i'm not on a1 right now)

_________________
--------------------------------------
Search and Destroy
---------------------------------------

@damned

That's a bad sign for a memory problem. When your A1 has some free time it would be good to test the whole memory.

I recommend to download memtester from OS4 Depot. Copy to your system. Then reboot into a boot shell. Now run it.

It will take a while but at least you have a cache. Best to test with all memory activated.

@Geri

Quote:

Good idea!

I thought so too. Just need to expand on it.

Quote:

Shouldn't be that hard and as far as I understand it also the Linux kernel should be U-Boot standalone application.

Yeah works the same kind of way. Except UBoot FLB starts my app as a bootloader and SLB starts Linux. Both would have to be UBoot images.

Quote:

Maybe U-Boot sets up a memory mapping for the first 16MB, which would also explain, why we can't boot bigger kernel images.

I think it does. All my tests with addresses at 0x500000, 0x1000000 or 0x10000000 all crash immediately.

At one stage I thought I had it but turned out to be a memtester bug where it doesn't initialise an alignment variable causing a bad pointer. But it doesn't crash, just makes it go on forever with flashing cursor.

Quote:

U-Boot just hands over a pointer to the kernel's entry function, which should point to the bd_t structure.

With help from the bdinfo command I was able to acertain where to look for the memory size.

Quote:

At least the instruction cache should already be enabled within U-Boot.

Should. I tried enabling it by hand. No noticable speed change.

Quote:

First the 1.1.x versions of U-Boot (or to be more specific, I think it is the x86 emulator for the video BIOS) don't like it, if the data cache is active

That would explain the instant crash when enalbing it!

Quote:

Secondly I reproducibly got different memtester results f

That's a worry. Well you can be assured in UBoot that data cache will be turned off. What about your other A1 machine?

Quote:

If the standalone memtester version could setup a fixed memory mapping (maybe with BATs) for the whole RAM address space (2GB), then I could verify, if the errors are really reported for the same physical address.

And that is beyond my measure. At this point, given the crashes and DCache behaviour, the MMU would need to be setup by custom routines and the VGA BIOS replaced as well. It would almost need another firmware or OS setup routine. Perhaps not as big as it seeems. I haven't got into low level PPC programming.

Another thing is with a context structure or board structure there are not many routines. Nothing in there to enable cache or even call other UBoot routines or commands. Very limited. Doesn't look very thought out.

Last edited by Hypex on 16-Jun-2013 at 05:25 PM.

Hello All.

I just released BootMemTester on OS4Depot.

http://os4depot.net/?function=showfile&file=utility/hardware/bootmemtester.lha

Last edited by Hypex on 07-Jul-2013 at 04:47 PM.