Thank You for your continued support and contributions!
CGU_PERI |= ((CLK_DIV(AS3525_PLLA_FREQ, AS3525_PCLK_FREQ) - 1) << 2) | 1; /* clk_in = PLLA */
#define DBOP_DIV (CLK_DIV(....))#if DBOP_DIV > 8# error "dbop clkdiv too high"#endifCGU_DBOP |= (DBOP_DIV - 1) << x
EDIT : another bug I just reminded ofFor users with 8GB and more models : don't use test builds because they could totally brick your Sansa.We don't switch banks in SD transfers when we are crossing a bank boundary, so when crossing the 4GB border, we could accidentally write to the first blocks of internal storage, which hold the Original Firmware.I noticed this problem when reading ata-sd-pp.c which has a comment line 951. (And by the way, it could be a source of the filesystem corruption the people using Sansa e200/c200 are seeing).An efficient fix should be relatively easy to do and also applied to ata-sd-pp.c, but in the meantime be careful!
For users with 8GB and more models : don't use test builds because they could totally brick your Sansa.We don't switch banks in SD transfers when we are crossing a bank boundary, so when crossing the 4GB border, we could accidentally write to the first blocks of internal storage, which hold the Original Firmware.I noticed this problem when reading ata-sd-pp.c which has a comment line 951. (And by the way, it could be a source of the filesystem corruption the people using Sansa e200/c200 are seeing).An efficient fix should be relatively easy to do and also applied to ata-sd-pp.c, but in the meantime be careful!
Can you update to last svn again, and change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000 ; and see if this fixes your problem ?
change AS3525_IDE_FREQ in firmware/target/arm/as3525/clock-target.h to 90000000
Page created in 0.063 seconds with 21 queries.